[GRASS-dev] [r.sun]

Blumentrath, Stefan Stefan.Blumentrath at nina.no
Thu Apr 28 05:35:28 PDT 2016


Hi Ben,

In case you are interested in some more parallel r.sun examples you may have a look here:
https://github.com/NINAnor/sentinel4nature/blob/master/r_sun_parallel.sh

The shell script (based on the content from the GRASS wiki) basically uses the tiling approach Markus was suggesting and applies r.sun (and r.horizon) in parallel using xargs...

Since my DEM has a lot of NoData within it`s bounding box I droped all tiles not covered by the DEM and used v.mkgrid for the tiling (instead of splitting the DEM itself (but now I see that r.tile might have been more efficient).

BTW, are overlapping tiles required, when r.horizon considers a user-defined distance outside of the current region?

Cheers,
Stefan

-----Original Message-----
From: grass-dev [mailto:grass-dev-bounces at lists.osgeo.org] On Behalf Of Markus Neteler
Sent: 28. april 2016 14:12
To: Ben Hur Pintor <bnhr.dev at gmail.com>
Cc: GRASS-dev <grass-dev at lists.osgeo.org>
Subject: Re: [GRASS-dev] [r.sun]

On Thu, Apr 28, 2016 at 1:48 PM, Ben Hur Pintor <bnhr.dev at gmail.com> wrote:
> Thanks for the response. I've seen a lot of literature and uses of 
> r.sun which is one of the reasons why I chose it as my model aside 
> from the fact that it's open-source. However, most of the uses are 
> European setting which I understand since r.sun is based on ESRA. I 
> wanted to see how well r.sun performs in a more tropical setting and 
> from my initial findings and studies, it seems to be doing pretty well.
>
> r.sun and r.sunmask both seem to use the SOLPOS algorithm, the SPA
> (http://www.nrel.gov/docs/fy08osti/34302.pdf) is a more recent solar 
> positioning algorithm by NREL and is much more precise than SOLPOS so 
> I wondered if using SPA instead of SOLPOS might provide better results.

Long time back I added the SOLPOS support in r.sunmask.
Do you have a pointer to the SPA source code? Because implementing it from a 40 pages PDF is expensive :-)

> With regards to using LiDAR-derived raster data, my machine can 
> actually handle it but it just takes a lot of time. I have a 1m 
> resolution LiDAR of a
> 500 sq km area (~5GB) and it really just takes a lot of time and disk 
> space
> -- specially for horizon rasters. I'm looking into parallel processing 
> to remedy this issue.

You may consider to tile the data (r.tile) with sufficient overlap, then process these tiles in parallel.

> Lastly, I would also like to go into 3D urban solar energy modelling 
> which is why I asked about v.sun or any other attempts in GRASS to 
> develop a model for solar radiation received by 3D objects (i.e. 
> buildings including facades and roofs).

Yes, here some pointers:

Hofierka and Zlocha, 2012
A New 3-D Solar Radiation Model for 3-D City Models http://onlinelibrary.wiley.com/doi/10.1111/j.1467-9671.2012.01337.x/abstract

3-D city modeling for sustainable energy applications http://web.science.upjs.sk/hofierka/projekty/vega2_results.html

Hope this helps for a start,
Markus

--
Markus Neteler
http://www.mundialis.de - free data with free software http://grass.osgeo.org http://courses.neteler.org/blog _______________________________________________
grass-dev mailing list
grass-dev at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev


More information about the grass-dev mailing list