r.sun and r.horizon

[Jonathan Greenberg]

I saw some posts by Markus about getting r.horizon and r.sun "synced"
(such that the output files of r.horizon correspond to the time steps of
r.sun)-- I was wondering if there are any conclusions on how best to use
r.horizon and r.sun together so they most closely mimic using the -s
shadow flag, specifically with daily integrations.  We're about to start
doing some MASSIVE r.sun processing (input DEM ~ 80gb) so we'd like to
know how to pre-calculate the horizon info to speed this up.  Thanks!

--j

--
Jonathan A. Greenberg, PhD
Postdoctoral Scholar
Center for Spatial Technologies and Remote Sensing (CSTARS)
University of California, Davis
One Shields Avenue
The Barn, Room 250N
Davis, CA 95616
Cell: 415-794-5043
AIM: jgrn307, MSN: [hidden email], Gchat: jgrn307

_______________________________________________
grass-user mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-user

[Markus Neteler]

On Fri, Nov 6, 2009 at 8:41 PM, Jonathan Greenberg
<[hidden email]> wrote:
> I saw some posts by Markus about getting r.horizon and r.sun "synced" (such
> that the output files of r.horizon correspond to the time steps of r.sun)--

[ that was from Hamish ]

> I was wondering if there are any conclusions on how best to use r.horizon
> and r.sun together so they most closely mimic using the -s shadow flag,
> specifically with daily integrations.  We're about to start doing some
> MASSIVE r.sun processing (input DEM ~ 80gb) so we'd like to know how to
> pre-calculate the horizon info to speed this up.  Thanks!

I have done such calculations last week. From all the tests done by Hamish
I got the conclusion that it is *currently* the best to not use r.horizon but
to calculate the horizon within r.sun.

Here what I used:

# step=0.05: 3 minutes time step alias 1deg sun movement
# horizonstep=1 to match step

r.sun -s elevin=$DEM day=$DOY horizonstep=1 step=0.05 \
         linkein=linke_turbidity${month} \
         insol_time=${PREFIX}_insol_time.$DOY

Advantage: without the r.horizon output maps the RAM consumption
is much lower. See formula in
http://grass.osgeo.org/grass64/manuals/html64_user/r.sun.html
where 'horizonsteps' refers to the r.horizon output maps.

Some notes (and multi-core parallelization trick) have been collected at
http://grass.osgeo.org/wiki/R.sun
but a new section of "Recommendations" should be added there.
Contributions welcome.

Markus
_______________________________________________
grass-user mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-user

[hamish-2]

Jonathan Greenberg wrote:
> > I was wondering if there are any conclusions on how best to use
> > r.horizon and r.sun together so they most closely mimic using
> > the -s shadow flag, specifically with daily integrations.

so if you use pre-calc'ed r.horizon maps you should not use the -s flag?


> > We're about to start doing some MASSIVE r.sun processing (input
> > DEM ~ 80gb)

how many cells? have you done trials with a subset of the data?
home much computer & time do you have to throw at the problem?


Markus:
> # step=0.05: 3 minutes time step alias 1deg sun movement
> # horizonstep=1 to match step

(fwiw I simplified a bit: actually 4 minute timestep is 1 deg (4*15=60),
but 3 min is a nice round step= so I used that as "better than 1deg")


> Some notes (and multi-core parallelization trick) have been
> collected at http://grass.osgeo.org/wiki/R.sun
> but a new section of "Recommendations" should be added
> there.

see also trac #498 linked from the above wiki page.


> Contributions welcome.

(this is a big of a group learning exercise)


Hamish




_______________________________________________
grass-user mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-user