Dear list,
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?
- http://grass.osgeo.org/grass64/manuals/html64_user/r.sun.html says that r.sun is a lot faster with r.horizon
- http://www.osgeo.org/pipermail/grass-user/2009-November/053313.html says that r.sun without r.horizon uses a lot less RAM
- http://www.osgeo.org/pipermail/grass-user/2012-January/063254.html says that slope and aspect maps aren’t required any more
- https://trac.osgeo.org/grass/ticket/498#comment:18 makes it look like not using slope and aspect maps could be pretty disastrous.
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.
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?
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:
The horizonstep parameter gives the angle step (in degrees) between successive azimuthal directions for the calculation of the horizon. Thus, a value of 5 for the horizonstep will give a total of 360/5=72 directions (72 rasters if used in the raster mode).
The direction 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 direction should be set to 45 and horizonstep to 180. If you only want one single direction, use this parameter to specify desired direction of horizon angle, and set the horizonstep size to 0 degrees.
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.
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.)?
Lots of questions, but I’m grateful for all answers, even if it’s only for parts of the email. Thanks a bunch!
Best,
Daniel
–
B.Sc. Daniel Lee
Geschäftsführung für Forschung und Entwicklung
ISIS - International Solar Information Solutions GbR
Vertreten durch: Daniel Lee, Nepomuk Reinhard und Nils Räder
Deutschhausstr. 10
35037 Marburg
Festnetz: +49 6421 379 6256
Mobil: +49 176 6127 7269
E-Mail: Lee@isi-solutions.org
Web: http://www.isi-solutions.org
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.
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.