[GRASS-dev] [r.sun]

GRASS GIS GRASS GIS developer
1

Greetings everyone.

I use r.sun for solar radiation modelling in the Philippines. I have a few questions and clarifications and I hope you can indulge me:

  1. Aside from NCSU-OSGeoREL (whose resources on r.sun I’m very much thankful for), are there anyone else out there working on r.sun?

  2. Has the solar position algorithm in r.sun been updated or what is the solar position algorithm that it uses? SOLPOS? SPA? Will using one or the other have significant effects on the results?

  3. I also work with LiDAR and other high resolution data, is it advisable to use multi-threading with r.sun?

  4. I’m currently working on Python scripts to compute monthly average solar radiation values using using the average day of the month given by Duffie and Beckman (Solar Engineering and Thermal Processes, 1991) as well as running r.sun for large high-resolution rasters which I’d like to share with the community, if I do finish them.

  5. Lastly, is there any effort or interest out there for creating a 3D version of r.sun? One that computes for the solar radiation received by an entire building and not just its roof. I’ve read about v.sun but I don’t think it ever made it to GRASS.

Your replies and responses will be highly appreciated.

Thank you.

Regards,

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

2

On 28 April 2016 at 06:58, Ben Hur Pintor <bnhr.dev@gmail.com> wrote:

Greetings everyone.

Hi,

I use r.sun for solar radiation modelling in the Philippines. I have a few
questions and clarifications and I hope you can indulge me:

1. Aside from NCSU-OSGeoREL (whose resources on r.sun I'm very much thankful
for), are there anyone else out there working on r.sun?

For sure I used r.sun several times, I think als JRC is using it [0]

3. I also work with LiDAR and other high resolution data, is it advisable to
use multi-threading with r.sun?

r.sun use raster as input, if you have high resolution raster data it
is not a problem if you computer is able to manage it.
I run r.sun using DEM with 40/30 cm of resolution.
I think that multi-threading could be used launching several r.sun job
in different cpu/core

4. I'm currently working on Python scripts to compute monthly average solar
radiation values using using the average day of the month given by Duffie
and Beckman (Solar Engineering and Thermal Processes, 1991) as well as
running r.sun for large high-resolution rasters which I'd like to share with
the community, if I do finish them.

there are already other addons using r.sun, maybe you can take some
inspiration [1]

Thank you.

Regards,
Ben Hur

[0] http://re.jrc.ec.europa.eu/pvgis/apps4/pvest.php
[1] https://grass.osgeo.org/grass70/manuals/addons/r.sun.daily.html

--
ciao
Luca

www.lucadelu.org

3

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.

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.

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

Again, thank you.

···

On Thu, Apr 28, 2016 at 6:09 PM, Luca Delucchi <lucadeluge@gmail.com> wrote:

On 28 April 2016 at 06:58, Ben Hur Pintor <bnhr.dev@gmail.com> wrote:

Greetings everyone.

Hi,

I use r.sun for solar radiation modelling in the Philippines. I have a few
questions and clarifications and I hope you can indulge me:

  1. Aside from NCSU-OSGeoREL (whose resources on r.sun I’m very much thankful
    for), are there anyone else out there working on r.sun?

For sure I used r.sun several times, I think als JRC is using it [0]

  1. I also work with LiDAR and other high resolution data, is it advisable to
    use multi-threading with r.sun?

r.sun use raster as input, if you have high resolution raster data it
is not a problem if you computer is able to manage it.
I run r.sun using DEM with 40/30 cm of resolution.
I think that multi-threading could be used launching several r.sun job
in different cpu/core

  1. I’m currently working on Python scripts to compute monthly average solar
    radiation values using using the average day of the month given by Duffie
    and Beckman (Solar Engineering and Thermal Processes, 1991) as well as
    running r.sun for large high-resolution rasters which I’d like to share with
    the community, if I do finish them.

there are already other addons using r.sun, maybe you can take some
inspiration [1]

Thank you.

Regards,
Ben Hur

[0] http://re.jrc.ec.europa.eu/pvgis/apps4/pvest.php
[1] https://grass.osgeo.org/grass70/manuals/addons/r.sun.daily.html

–
ciao
Luca

www.lucadelu.org

–

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

4

On Thu, Apr 28, 2016 at 1:48 PM, Ben Hur Pintor <bnhr.dev@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 :slight_smile:

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

5

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@lists.osgeo.org] On Behalf Of Markus Neteler
Sent: 28. april 2016 14:12
To: Ben Hur Pintor <bnhr.dev@gmail.com>
Cc: GRASS-dev <grass-dev@lists.osgeo.org>
Subject: Re: [GRASS-dev] [r.sun]

On Thu, Apr 28, 2016 at 1:48 PM, Ben Hur Pintor <bnhr.dev@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 :slight_smile:

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@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

6

Long time back I added the SOLPOS support in r.sunmask.

···

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@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@lists.osgeo.org] On Behalf Of Markus Neteler
Sent: 28. april 2016 14:12
To: Ben Hur Pintor <bnhr.dev@gmail.com>
Cc: GRASS-dev <grass-dev@lists.osgeo.org>
Subject: Re: [GRASS-dev] [r.sun]

On Thu, Apr 28, 2016 at 1:48 PM, Ben Hur Pintor <bnhr.dev@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 :slight_smile:

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

7

On Thu, Apr 28, 2016 at 2:51 PM, Ben Hur Pintor <bnhr.dev@gmail.com> wrote:

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

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

"... The Software is being provided for internal, noncommercial
purposes only and shall not be re-distributed. ..."

Unfortunately it is non-free.

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.

Fine but be sure to not leave out shadow relevant relief in case you
are in a hilly / mountainous area.
r.viewshed can help to some extent to figure out how large the region
needs to be.

Markus

--
Markus Neteler
http://www.mundialis.de - free data with free software
http://grass.osgeo.org
http://courses.neteler.org/blog

8

On Thu, Apr 28, 2016 at 9:02 AM, Markus Neteler <neteler@osgeo.org> wrote:

On Thu, Apr 28, 2016 at 2:51 PM, Ben Hur Pintor <bnhr.dev@gmail.com> wrote:

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

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

"... The Software is being provided for internal, noncommercial
purposes only and shall not be re-distributed. ..."

Unfortunately it is non-free.

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.

Fine but be sure to not leave out shadow relevant relief in case you
are in a hilly / mountainous area.
r.viewshed can help to some extent to figure out how large the region
needs to be.

Markus

Also for the tiling approach, you might want to test GridModule, an
example for r.slope.aspect here:

import grass.script as gscript
from grass.pygrass.modules.grid import GridModule

def main(elevation):
    region = gscript.region()
    width = region['cols'] // 2 + 1
    height = region['rows'] // 2 + 1

    grd = GridModule('r.slope.aspect', elevation=elevation, slope='slope',
                     debug=False, width=width, height=height,
                     overlap=10, processes=4, overwrite=True)
    grd.run()

if __name__ == '__main__':
    elevation = 'elevation'
    gscript.run_command('g.region', raster=elevation)
    main(elevation)

Best,

Anna

--
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@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev