Dear list,<br><br>I'm trying to plan some scripts that will perform r.sun iteratively for every day in a year. I've found some info that's confused me a bit though, perhaps somebody could tell me what's right?<br>
<br>- <a href="http://grass.osgeo.org/grass64/manuals/html64_user/r.sun.html">http://grass.osgeo.org/grass64/manuals/html64_user/r.sun.html</a> says that r.sun is a lot faster with r.horizon<br>- <a href="http://www.osgeo.org/pipermail/grass-user/2009-November/053313.html">http://www.osgeo.org/pipermail/grass-user/2009-November/053313.html</a> says that r.sun without r.horizon uses a lot less RAM<br>
- <a href="http://www.osgeo.org/pipermail/grass-user/2012-January/063254.html">http://www.osgeo.org/pipermail/grass-user/2012-January/063254.html</a> says that slope and aspect maps aren't required any more<br>- <a href="https://trac.osgeo.org/grass/ticket/498#comment:18">https://trac.osgeo.org/grass/ticket/498#comment:18</a> makes it look like not using slope and aspect maps could be pretty disastrous.<br>
<br>My experience with using r.sun with slope and aspect maps is positive,
has this bug been resolved or am I perhaps wasting computing time by
making the maps beforehand? The bug report makes me want to be very cautious about not making them.<br>
<br>
If I remember correctly, r.sun used to not be able to partition maps without r.horizon maps, which is the original reason that I wanted to use r.horizon. However, using 6.4.2 I took a look in the GUI and noticed that it doesn't seem to require a horizon map to partition now. Does that mean that I can partition without the horizon maps? And if I do so, will I have shadowing errors at the edges of partitions? I can imagine that if the partitions overlap (which would make sense to avoid such artefacts) that it could eventually mean using MORE memory, or am I mistaken? Does anyone have any experience with that?<br>
<br>In addition, if I DO use r.horizon (which I intuitively think must be faster than using only r.sun), I notice that I can enter horizon steps and a horizon prefix. What if I'm only wanting to use the horizon maps as an input for r.sun? Do I have to compute all horizons? Or could I write a script that only makes the maps that I'm interested in? Concretely, from what direction are the maps made (from north like many programs, or from east like r.sun, etc.), and in which order (clockwise or counterclockwise)? How does r.sun know which horizon map to use? Does it get it out of the metadata or from the filename (it asks for a map prefix)? Here's kind of what's really confusing me, from the r.horizon manual:<br>
<div style="margin-left:40px"><p>The <i>horizonstep</i> parameter gives the angle step (in degrees)
between successive azimuthal directions for the calculation of the
horizon. Thus, a value of 5 for the <i>horizonstep</i> will give a total of
360/5=72 directions (72 rasters if used in the raster mode).
</p><p>The <i>direction</i> parameter gives the initial direction of the
first output. This parameter acts as an direction angle offset. For
example, if you want to get horizon angles for directions 45 and 225
degrees, the <i>direction</i> should be set to 45 and <i>horizonstep</i> to
180. If you only want one single direction, use this parameter to
specify desired direction of horizon angle, and set the <i>horizonstep</i>
size to 0 degrees.
</p></div>Alright, I understand that, but what would I do if I wanted all horizons from 45°-225° in e.g. 5° steps? Or does that not work at all? In any case, I'd really like to know what direction r.horizon is producing the rasters from.<br>
<br>And, last but not least, what is the low memory version of r.sun? Do I have any disadvantages by using that (precision, speed, etc.)?<br><br>Lots of questions, but I'm grateful for all answers, even if it's only for parts of the email. Thanks a bunch!<br>
<br>Best,<br>Daniel<br clear="all">
<p style="margin-top:0px;margin-bottom:0px;margin-left:0px;margin-right:0px;text-indent:0px"><span style="font-family:arial,sans-serif;font-size:13px;background-color:rgb(255,255,255)"></span></p><p>--<br></p><p>B.Sc. Daniel Lee<br>
Geschäftsführung für Forschung und Entwicklung<br>ISIS - International Solar Information Solutions GbR<br>Vertreten durch: Daniel Lee, Nepomuk Reinhard und Nils Räder<br></p><p>Deutschhausstr. 10<br>35037 Marburg<br>Festnetz: <a value="+4964213796256" style="color:rgb(28,81,168)">+49 6421 379 6256</a><br>
Mobil: <a value="+4917661277269" style="color:rgb(28,81,168)">+49 176 6127 7269</a><br>E-Mail: <a href="mailto:Lee@isi-solutions.org" style="color:rgb(28,81,168)" target="_blank">Lee@isi-solutions.org</a><br>Web: <a href="http://www.isi-solutions.org/" style="color:rgb(28,81,168)" target="_blank">http://www.isi-solutions.org</a></p>
<p>ISIS wird gefördert durch die Bundesrepublik Deutschland, Zuwendungsgeber: Bundesministerium für Wirtschaft und Technologie aufgrund eines Beschlusses des Deutschen Bundestages, sowie durch die Europäische Union, Zuwendungsgeber: Europäischer Sozialfonds.<br>
Zusätzliche Unterstützung erhält ISIS von dem Entrepreneurship Cluster Mittelhessen, der Universität Marburg, dem Laboratory for Climatology and Remote Sensing und dem GIS-Lab Marburg.</p><p></p>