<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Hi Scott<div><br></div><div>comments as below.</div><div><br></div><div>Achim</div><div><br><div><div>On Sep 16, 2009, at 10:14 PM, Scott Bucking wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left-width: 1px; border-left-style: solid; border-left-color: rgb(204, 204, 204); margin-top: 0pt; margin-right: 0pt; margin-bottom: 0pt; margin-left: 0.8ex; padding-left: 1ex; position: static; z-index: auto; ">(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.<br> <br></blockquote><div>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?<br></div></div></blockquote><div><br></div>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). </div><div><br><blockquote type="cite"><div class="gmail_quote"><div>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).  <br></div></div></blockquote><div><br></div><div>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.</div><br><blockquote type="cite"><div class="gmail_quote"><div>I am completely in favor, if both methods yield similar results regardless of shading.<br> </div><blockquote class="gmail_quote" style="border-left-width: 1px; border-left-style: solid; border-left-color: rgb(204, 204, 204); margin-top: 0pt; margin-right: 0pt; margin-bottom: 0pt; margin-left: 0.8ex; padding-left: 1ex; position: static; z-index: auto; "> (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 ...<br> <br></blockquote><div>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.<br> <br>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?<br> <br></div></div></blockquote><div><br></div><div>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.</div><div><br></div><div>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).</div><br><blockquote type="cite"><div class="gmail_quote"><div>Scott<br>  </div><blockquote class="gmail_quote" style="border-left-width: 1px; border-left-style: solid; border-left-color: rgb(204, 204, 204); margin-top: 0pt; margin-right: 0pt; margin-bottom: 0pt; margin-left: 0.8ex; padding-left: 1ex; position: static; z-index: auto; "><div><div></div><div><br> <br> <br> On Sep 15, 2009, at 7:46 PM, Scott Bucking wrote:<br> <br> </div></div><blockquote class="gmail_quote" style="border-left-width: 1px; border-left-style: solid; border-left-color: rgb(204, 204, 204); margin-top: 0pt; margin-right: 0pt; margin-bottom: 0pt; margin-left: 0.8ex; padding-left: 1ex; position: static; z-index: auto; "><div><div></div><div> Hi all,<br> <br> 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.<br> <br> 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?<br> <br> 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?<br> <br> Kind Regards,<br> <br> Scott<br></div></div> _______________________________________________<br> esp-r mailing list<br> <a href="mailto:esp-r@lists.strath.ac.uk" target="_blank">esp-r@lists.strath.ac.uk</a><br> <a href="http://lists.strath.ac.uk/mailman/listinfo/esp-r" target="_blank">http://lists.strath.ac.uk/mailman/listinfo/esp-r</a><br> </blockquote> <br> <a href="mailto:achim.geissler@intergga.ch" target="_blank">achim.geissler@intergga.ch</a><br> <br> <br> <br> <br> </blockquote></div><br> _______________________________________________<br>esp-r mailing list<br><a href="mailto:esp-r@lists.strath.ac.uk">esp-r@lists.strath.ac.uk</a><br>http://lists.strath.ac.uk/mailman/listinfo/esp-r</blockquote></div><br><div apple-content-edited="true"> <span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0; "><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><a href="mailto:achim.geissler@intergga.ch">achim.geissler@intergga.ch</a></div><div><br></div><div><br></div></div></span><br class="Apple-interchange-newline"> </div><br></div></body></html>