using the latest CVS, I noticed that running r.sunmaks on a relatively small
region (300x300 cells) took a very long time to run (about 15 minutes). I am
using a DEM for the location and specifying the time of day, and day of the
year. I used the following command:
using the latest CVS, I noticed that running r.sunmaks on a relatively small
region (300x300 cells) took a very long time to run (about 15 minutes). I am
using a DEM for the location and specifying the time of day, and day of the
year. I used the following command:
... because of r.sunmask slowliness...
For a fast solution, use r.sun instead.
Shadow maps
A map of shadows can be extracted from the solar incidence
angle map (incidout). Areas with
zero values are shadowed. The -s flag has to be used.
Dylan Beaudette wrote on 03/08/2007 02:25 AM:
> Hi everyone,
>
> using the latest CVS, I noticed that running r.sunmaks on a
> relatively small region (300x300 cells) took a very long time to
> run (about 15 minutes). I am using a DEM for the location and
> specifying the time of day, and day of the year. I used the
> following command:
>
> r.sunmask elev=elev_meters out=shadows_afternoon timezone=-8
> year=2007 month=3 day=31 hour=16 minute=00 second=00
>
> Any idea on why this would take so long?
>
... because of r.sunmask slowliness...
For a fast solution, use r.sun instead.
Shadow maps
A map of shadows can be extracted from the solar incidence
angle map (incidout). Areas with
zero values are shadowed. The -s flag has to be used.
any idea if this is because of the (better) SOLPOS algorithm r.sunmask
uses, or is it just inefficient structure in the r.sunmask module?
ie if/when r.sun is updated to use SOLPOS, can we expect a big slowdown
in r.sun run times?
Markus Neteler wrote:
> Dylan Beaudette wrote on 03/08/2007 02:25 AM:
> > Hi everyone,
> >
> > using the latest CVS, I noticed that running r.sunmaks on a
> > relatively small region (300x300 cells) took a very long time to
> > run (about 15 minutes). I am using a DEM for the location and
> > specifying the time of day, and day of the year. I used the
> > following command:
> >
> > r.sunmask elev=elev_meters out=shadows_afternoon timezone=-8
> > year=2007 month=3 day=31 hour=16 minute=00 second=00
> >
> > Any idea on why this would take so long?
>
> ... because of r.sunmask slowliness...
> For a fast solution, use r.sun instead.
> Shadow maps
> A map of shadows can be extracted from the solar incidence
> angle map (incidout). Areas with
> zero values are shadowed. The -s flag has to be used.
Thanks for the tips Markus. Fortunately this mini-analysis was not something I
plan to do on a regular basis. However Hamish brings up a good point:
any idea if this is because of the (better) SOLPOS algorithm r.sunmask
uses, or is it just inefficient structure in the r.sunmask module?
ie if/when r.sun is updated to use SOLPOS, can we expect a big slowdown
in r.sun run times?
... as I make heavy use of r.sun and any issues related to either
1. poor performance in SOLPOS
2. current inaccuracies in r.sun
are of interest to me. Could it be due to the on-the-fly computation of
slope/aspect within SOLPOS?
Cheers,
--
Dylan Beaudette
Soils and Biogeochemistry Graduate Group
University of California at Davis
530.754.7341
On Friday 09 March 2007 00:20, Markus Neteler wrote:
> 2. current inaccuracies in r.sun are of interest to me. Could it be due
> to the on-the-fly computation of slope/aspect within SOLPOS?
?? SOLPOS is not implemented in r.sun.
Sorry for the vague nature of this comment. I was implying that since SOLPOS
is better than the algorithm in r.sun, and seems to take longer (longer
computation time == more accurate) then r.sun is using a simpler less
accurate algorithm. This looks to not be the case, and I should have been
clearer in my question/ comment.
Dylan
--
Dylan Beaudette
Soils and Biogeochemistry Graduate Group
University of California at Davis
530.754.7341
[general comment; nothing specifically talking about the r.sun code]
That is not always correct, do not take it for granted.
Consider a less efficient approach iterating in a loop until the
accuracy is better than some threshold. A better algorithm or method
will get the job done faster, and often that will allow you to go a bit
further and increase accuracy beyond the target with little added cost.
Dylan Beaudette wrote:
> longer computation time == more accurate
[general comment; nothing specifically talking about the r.sun code]
That is not always correct, do not take it for granted.
Consider a less efficient approach iterating in a loop until the
accuracy is better than some threshold. A better algorithm or method
will get the job done faster, and often that will allow you to go a bit
further and increase accuracy beyond the target with little added cost.
Hamish
Indeed. I made the above [ass]umption without clarifying what I really meant
to say:
"Is the algorithm used in r.sunmask more accurate than that used in r.sun,
i.e. has SOLPOS been implemented in r.sun?"
Thanks for the clarification.
--
Dylan Beaudette
Soils and Biogeochemistry Graduate Group
University of California at Davis
530.754.7341