[esp-r] Re: 10 column limitation using RES

[Achim Geissler]

Hi Scott

comments as below.

Achim

On Sep 16, 2009, at 10:14 PM, Scott Bucking wrote:

> (1) The variable names in RES are quite often somewhat misleading.  
> For solar radiation, I have found it easiest / best to add a small  
> surface with absorptivity of 1.0 as "sensor" on each elevation of  
> interest.
>
> Just curious regarding your reasoning for creating a sensor versus  
> using the output from built-in variables.  Have you found certain  
> variables personally to be inaccurate with regards to incident solar  
> energy?  What is considered to be 'best practice' for extraction of  
> incident solar radiation?

The problem is not usually any inaccuracy, but that e.g. in this case  
to my knowledge no RES variable actually returns incident solar. The  
variable in RES that has this name should - as far as I remember -  
actually be called 'absorbed solar' (incident minus reflected minus  
transmitted). But it is some time ago we went through this and the  
"sensor surface" solution proved to be the most reliable for us. Also,  
as stated, the names of variables in RES are sometimes slightly  
misleading - you not always get what you would expect on the face of  
the variable name (especially, maybe, as non-native speaker).

> My main concern in using a point sensor is that some modelling  
> complexity with regards to self-shading via the insolation and  
> shading module would be ignored or moreover the sensor might be  
> placed by accident in a partially shaded area (please note that I am  
> developing an optimization procedure that auto-generates geometry,  
> and hence would require auto-sensor placement based on geometry).

Not quite sure I understand your meaning completely. But, any "solar  
entering" or "incident solar" in RES will also be affected by shading.  
I agree, however, that auto-generated geometry (sounds scary) could  
make placing a sensor a daunting task. On the other hand, quite a bit  
of information will be necessary for an auto-generated geometry, I  
would assume. Maybe that information is enough to place one or more  
sensors in appropriate positions.

> I am completely in favor, if both methods yield similar results  
> regardless of shading.
>
> (2) There is an additional output possibility: xml. If your model is  
> not too large / complex, the runtime increase when using xml output  
> is not too dire. All you need is a compile with xml support and an  
> input.xml file in the calling directory of esp-r. After a short run  
> (a few timesteps) a file "dictionary" is created. This lists all  
> available output. Then, the input.xml can be extended to whatever  
> output you require and there is no limit to columns ...
>
> I have played around a little with XML support but gave up when I  
> discovered how to use RES via scripts.   I am dealing with a lot of  
> data, hourly time steps, annual simulation with electrical, air-flow  
> networks, etc...  So time taken to write to a text file adds up  
> quickly.  I found RES to be much more streamlined as I can extract  
> specific variables from the res db file.
>
> The only option I am familiar with the output xml is the 'dump all  
> data' option.  Are there options to output specific variables?  Any  
> documentation on this?  Is XML support still considered to be  
> experimental?
>

You can choose your output in detail - each variable by itself. I do  
not know if there is any "official" documentation. However, the  
procedure is quite self-explanatory, if you look at an exemplar with  
input.xml file and the "dictionary" file from a short run. The output  
of the .xml run is then a tabulator-separated list of all variables at  
time-step level. You cannot, however, go back and extract additional  
values without running the full simulation again. Writing the actual  
text file (which is done at the end of a simulation run) does not  
really seem to be a large time-issue. The storing of values during run- 
time is what makes simulation slow for large / complex models when xml  
is activated, as far as I am aware.

The Xml output is not experimental, as far as I know (at least, not  
any more experimental than the whole of the ESP-r system).

> Scott
>
>
>
>
> On Sep 15, 2009, at 7:46 PM, Scott Bucking wrote:
>
> Hi all,
>
> I'm running a simulation that looks at incident solar energy on a  
> building surface and noticed a few things that I was hoping someone  
> could clarify.
>
> First is that 'SW incident solar' appears not to work for  
> transparent surfaces.  Should I be using 'Solar processes' and  
> select 'solar entering from outside'?  Or is this accounted for in  
> the overall building surface?
>
> Also, it appears that RES limits data output to 10 columns (anymore  
> then 10 surfaces appears to be cutoff from the GRT output file).  Is  
> it possible to recompile ESPr and change this to, say 20 columns?   
> What was the original thought in limiting it to ten?
>
> Kind Regards,
>
> Scott
> _______________________________________________
> esp-r mailing list
> esp-r at lists.strath.ac.uk
> http://lists.strath.ac.uk/mailman/listinfo/esp-r
>
> achim.geissler at intergga.ch
>
>
>
>
>
> _______________________________________________
> esp-r mailing list
> esp-r at lists.strath.ac.uk
> http://lists.strath.ac.uk/mailman/listinfo/esp-r

achim.geissler at intergga.ch




-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.strath.ac.uk/archives/esp-r/attachments/20090916/6039ca6a/attachment.html