[GRASS-dev] [r.sun]

Thu Apr 28 05:51:17 PDT 2016

> 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 :-)

Sorry about that. Hahaha. Here's the actual C code:
https://www.nrel.gov/midc/spa/

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

I was choosing between r.tile or simply setting smaller computational
regions. If I use r.tile and process the tiles in parallel, I assume I
would need to set a different computational region per tile? The workflow
would go something like this: Per tile (in parallel) set the computational
region using the tile -> run r.horizon -> run r.sun

Also, do you think I should compute the horizon rasters per tile or as a
whole? I tested it once and it was faster when I called r.horizon per tile.

> 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

I'll look into this, thank you.

> 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).

Thank you for this. Do you think I can do the same in Python? I don't mind
working in bash but most of those I work with aren't really familiar with
shell scripting.

Again, thank you all for the help.

Cheers,
Ben Hur

--
*Engr. Ben Hur S. Pintor*
*Research Associate*
Phil-LiDAR 2 Project 5: REMap
UP Training Center for Applied Geodesy and Photogrammetry

*Juris Doctor*
College of Law
*University of the Philippines Diliman*
Quezon City 1101, PHL

On Thu, Apr 28, 2016 at 8:35 PM, Blumentrath, Stefan <
Stefan.Blumentrath at nina.no> wrote:

> 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
>

-- 

*Engr. Ben Hur S. Pintor*
*Research Associate*
Phil-LiDAR 2 Project 5: REMap
UP Training Center for Applied Geodesy and Photogrammetry

*Juris Doctor*
College of Law
*University of the Philippines Diliman*
Quezon City 1101, PHL
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/grass-dev/attachments/20160428/672a18bf/attachment-0001.html>