# Solar irradiation calculation using r.sun

I am trying to compute the global solar irradiation for a region and the run times seem to be a bit too high.

I have as inputs a Digital Surface Model with the buildings and a Digital Terrain Model for the surrounding area.

The PROJ_INFO is

```name       : Lat/Lon
proj       : ll
datum      : wgs84
ellps      : wgs84
```

The PROJ_UNITS are

```unit       : degree
units      : degrees
meters     : 1.0
```

The DSM has 8020 Rows, 8782 Columns and 70431640 Total Cells. The resolution of the DSM is 0:00:00.03303.

The DTM has 1080 Rows, 1476 Columns and 1594080 Total Cells with a resolution of 0:00:00.28913.

These are the steps I did for the r.sun calculation

1. Set the region to the area covered by the DTM and the resolution to the resolution of the DSM

`g.region rast=DTM@PERMANENT res=0:00:00.03303`
2. Overlay the DSM and the DTM to get a high resolution elevation map using r.series

`r.series input=DSM,DTM output=Overlay method=maximum`
3. From the Overlay map I generate slope and aspect maps

`r.slope.aspect elevation=Overlay slope=Slope aspect=Aspect`
4. I run r.sun on using the following command

`r.sun -s elevin=DSM aspin=Aspect slopein=Slope glob_rad=GlobalRad day=262`

The whole process ran on a system with two Intel Xeon l5430 CPU @ 2.66 GHz with 8 GB of RAM and it took 15 hours to finalize 55% of the process.

What am I doing wrong?

Am I missing something, is it normal to run this long?

Help me understand how should I compute solar irradiation starting from two elevation maps, a Digital Surface Model that contains the buildings and a Digital Terrain Model for the area that surrounds the Digital Surface Model.

• Did you mean to use the DSM as elevin, or the Overlay map? – Micha Sep 19 '13 at 10:16
• I am using the DSM as elevin. The Overlay map is used to compute slope and aspect maps. Don`t know if I am doing this right. I don`t even know how should I compute solar data starting with a city as a DSM file and the area around the city as DTM. – levi.fuksz Sep 19 '13 at 11:17
• I changed the way I do the solar calculation a bit. I calculate horizon from the DTM. Generate slope and aspect from the DSM. Run r.sun using the DSM as the elevation map, the slope and aspect maps and the horizon data obtained from the DTM. Is this approach a correct one? – levi.fuksz Sep 19 '13 at 12:11
• I'm not familiar with r.sun but two comments might help: you probably should create a horizon map and use it in the r.sun command. Also try adding either the time= parameter (to get irradiance only for a certain hour) or the step= parameter to limit the number of hours that are calculated thru theday. That might give you an idea why the full day calculation is taking so long. – Micha Sep 19 '13 at 17:47
• It seems that computing reflected and diffuse radiation is the cause of high running times. When I only compute direct beam radiation everything runs in a reasonable time – levi.fuksz Sep 20 '13 at 5:40

In case somebody would be interested I did the test in GRASS GIS NC sample location using the raster map `elevation` (DTM) and GRASS GIS 7.

Look at elevation raster map using

``````r.info elevation
``````

which gives

``````...
|   Rows:         1350                                                       |
|   Columns:      1500                                                       |
|   Total Cells:  2025000
...
``````

Set the computational region to the raster map (in this case using raster map extent and resolution but we don't have to):

``````g.region rast=elevation
``````

Check what is the actual number of cells used for computation using

``````g.region -p
``````

In my case the same as for elevation raster map:

``````...
nsres:      10
ewres:      10
rows:       1350
cols:       1500
cells:      2025000
``````

Then run `r.sun` computation:

``````r.sun elevation=elevation beam_rad=elevation_sun_beam diff_rad=elevation_sun_diffuse refl_rad=elevation_sun_reflected glob_rad=elevation_sun_global day=262
``````

On average laptop with Ubuntu it took no more than two minutes. It does not seem that there is any significant difference at this scale in computations with and without diffuse and reflected parts.

In general, if the computation is unexpectedly slow with particular type of data, projection or operating system, please report this as a bug (http://trac.osgeo.org/grass/) or at least write about it on mailing list (http://lists.osgeo.org/pipermail/grass-user/). Additionally, try also re-projecting the data (r.proj, http://grass.osgeo.org/grass70/manuals/m.proj.html) to non-lat/lon projection (GRASS location).

If this answer is acceptable to you please accept it, so we lower the number of old still open questions.