[GRASS-dev] Re: [GRASS GIS] #498: r.sun2 out of sync / broken svn history
#498: r.sun2 out of sync / broken svn history
-+--
Reporter: hamish | Owner: hamish
Type: defect | Status: assigned
Priority: major | Milestone: 6.4.0
Component: Raster | Version: svn-develbranch6
Resolution: |Keywords: r.sun
Platform: Linux | Cpu: x86-32
-+--
Comment (by hamish):
I built and tried the old r.sun, there slopein= and aspin= are required
and it has the same problems as rsun_aspslp.png's lower right pane.
I ran the test case with step=0.0025 (9 sec) and step=0.01 (36 sec).
They, together with a differences map between them are in the attached pic
rsun36_9sec_diff.png. Note the inner eastern wing in the 9sec image has a
rather crisp edge- it would appear to be missing some near-sunset
iterations??
setup:
{{{
time r.sun -s elevin=gauss day=$DAY \
beam_rad=rad_test.355.beam.9sec_step.try6 step=0.0025
real479m0.940s
user476m11.914s
sys 1m12.181s
time r.sun -s elevin=gauss day=$DAY \
beam_rad=rad_test.355.beam.36sec_step.try7 step=0.01
real217m34.835s
user217m12.742s
sys 0m23.561s
r.colors -e col=bcyr map=...
r.mapcalc diff36_9sec = \
rad_test.355.beam.36sec_step.try7 - rad_test.355.beam.9sec_step.try6
r.colors.stddev -z diff36_9sec
}}}
{{{
plot_stuff()
{
r.colors $MAP -e color=bcyr
d.rast $MAP
d.vect gauss_200m_contours color=180:180:180
echo $1 | d.text color=black
eval `r.univar -g $MAP`
echo sum: $sum | d.text color=black at=1,5
d.legend $MAP range=1300,1500
}
###
d.mon x2
d.resize w=1024 h=768
d.split.frame 4
#
d.frame uno
MAP=rad_test.355.beam.9sec_step.try6
plot_stuff dt=0.0025 hr (9 sec), day 355
#
d.frame dos
MAP=rad_test.355.beam.36sec_step.try7
plot_stuff dt=0.01 hr (36 sec), day 355
#
d.frame tres
MAP=diff36_9sec
d.rast $MAP
d.legend $MAP
echo difference between dt=9,36 sec maps | d.text color=black
#
d.frame cuatro
MAP=rad_test.355.beam.3min_step.try6
plot_stuff dt=0.05 hr (3 minutes), day 355
###
d.frame full_screen
#d.out.file out=rsun36_9sec_diff format=png
}}}
Hamish
--
Ticket URL: https://trac.osgeo.org/grass/ticket/498#comment:11
GRASS GIS http://grass.osgeo.org
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Re: [GRASS GIS] #498: r.sun2 out of sync / broken svn history
#498: r.sun2 out of sync / broken svn history
-+--
Reporter: hamish | Owner: hamish
Type: defect | Status: assigned
Priority: major | Milestone: 6.4.0
Component: Raster | Version: svn-develbranch6
Resolution: |Keywords: r.sun
Platform: Linux | Cpu: x86-32
-+--
Comment (by hamish):
r.sun2 seems safe to background without worrying if it will clobber the
region settings, so a poor-man's multi-threading script is used to help
speed things up on the quad-core.
The next tests are summing a whole bunch of Mode 1 steps with r.series +
r.mapcalc and see how it compares to the Mode 2 daily sum map. Trying with
a time step of 0.01 from sunrise to sunset on day 355:
{{{
r.info from Mode 2 beam_rad map:
Sunrise time min-max (hr.): 7.68
Sunset time min-max (hr.): 16.32
}}}
{{{
### mode 1 loop ###
SUNRISE=7.67
SUNSET=16.33
STEP=0.01
# | wc -l 867
CORES=4
for TIME in `seq $SUNRISE $STEP $SUNSET` ; do
echo time=$TIME
CMD=r.sun -s elevin=gauss day=$DAY time=$TIME \
beam_rad=rad1_test.355_${TIME}_beam --quiet
# poor man's multi-threading for a multi-core CPU
MODULUS=`echo $TIME $STEP $CORES | awk '{print $1 % ($2 * $3)}'`
if [ $MODULUS = $STEP ] ; then
# stall to let the background jobs finish
$CMD
sleep 2
else
$CMD
fi
done
for TIME in `seq $SUNRISE $STEP $SUNSET` ; do
r.colors rad1_test.355_${TIME}_beam col=rules --quiet EOF
0 white
0.01 blue
33.333% cyan
66.667% yellow
100% red
EOF
done
}}}
... in progress ...
Hamish
--
Ticket URL: https://trac.osgeo.org/grass/ticket/498#comment:12
GRASS GIS http://grass.osgeo.org
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Re: [GRASS GIS] #498: r.sun2 out of sync / broken svn history
#498: r.sun2 out of sync / broken svn history
-+--
Reporter: hamish | Owner: hamish
Type: defect | Status: assigned
Priority: major | Milestone: 6.4.0
Component: Raster | Version: svn-develbranch6
Resolution: |Keywords: r.sun
Platform: Linux | Cpu: x86-32
-+--
Comment (by hamish):
Replying to [comment:7 hamish]:
Q2) am I using aspin= correctly? should that be a map
created by r.slope.aspect? Using it the processing speeds
up by 3x, but the results seem a bit weird -- to the south
of the mound is a depression in the light which while possible
for reflected light seems that it would be upstream
incorrect for beam_rad.
defining a slopein= map (from r.slope.aspect result) doesn't
change the processing time appreciably. I haven't tested for
its effect on the output map yet.
correction: using aspin=`r.slope.aspect` doesn't speed things up, but
slope+aspect does. Using slopein= causes differences (missing south west
butterfly wing), but slope+aspect makes it really bad.
test script:
{{{
time r.sun -s elevin=gauss day=$DAY beam_rad=rad_test.355.beam.try4
real3m1.750s
user3m1.327s
sys 0m0.400s
#
time r.sun -s elevin=gauss day=$DAY beam_rad=rad_test.355.beamA.try4 \
aspin=guass.aspect
real3m4.432s
user3m4.092s
sys 0m0.364s
#
time r.sun -s elevin=gauss day=$DAY beam_rad=rad_test.355.beamS.try4 \
slopein=guass.slope
real3m7.865s
user3m6.444s
sys 0m0.612s
#
time r.sun -s elevin=gauss day=$DAY beam_rad=rad_test.355.beamAS.try4 \
aspin=guass.aspect slopein=guass.slope
real1m32.279s
user1m31.686s
sys 0m0.240s
#
r.contour in=gauss out=gauss_200m_contours step=200
plot_stuff()
{
MAP=rad_test.355.beam${MAPEXT}.try4
d.rast $MAP
d.vect gauss_200m_contours color=180:180:180
echo $1 | d.text color=black
eval `r.univar -g $MAP`
echo sum: $sum | d.text color=black at=1,5
d.legend $MAP
}
###
d.mon x1
d.resize w=640 h=480
d.split.frame 4
#
d.frame uno
MAPEXT=
plot_stuff Std.
#
d.frame dos
MAPEXT=A
plot_stuff w/Aspect map
#
d.frame tres
MAPEXT=S
plot_stuff w/Slope map
#
d.frame cuatro
MAPEXT=AS
plot_stuff w/Aspect and Slope maps
###
d.frame full_screen
#d.out.file out=rsun_aspslp format=png
}}}
results in the attached image (rsun_aspslp.png).
Hamish
--
Ticket URL: https://trac.osgeo.org/grass/ticket/498#comment:8
GRASS GIS http://grass.osgeo.org
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Re: [GRASS GIS] #498: r.sun2 out of sync / broken svn history
#498: r.sun2 out of sync / broken svn history
-+--
Reporter: hamish | Owner: hamish
Type: defect | Status: assigned
Priority: major | Milestone: 6.4.0
Component: Raster | Version: svn-develbranch6
Resolution: |Keywords: r.sun
Platform: Linux | Cpu: x86-32
-+--
Comment (by hamish):
Q1) how small must the horizonstep be to recreate the beam_rad
output map effectively as good as e.g. seen in the r.sun wiki
page example?
trials showing differences between no horizon steps; trying to find the
ideal sweet spot compromise between time and quality.
note that none are perfect. Standard r.sun with no horizon inputs is
slightly clipped in lower east wing; the 360x 1 degree horizon map has
slightly uneven width between inner east west bands.
note2 color tables are not constant between maps.
see attached screenshot (rsun_horizons.png)
test script:
{{{
for DEG in 1 15 30 ; do
# can take a while to create all maps
r.horizon elev=gauss horizonstep=$DEG dist=0.7 horizon=horangle$DEG
time r.sun -s elevin=gauss day=$DAY horizon=horangle$DEG \
horizonstep=$DEG beam_rad=rad_test.355.beam.Hz${DEG}deg.try5
done
# r.sun with no horizon seeds
real3m7.571s
user3m7.444s
sys 0m0.060s
# r.sun with 360x 1 deg seeds
# sits quite a while at 0% due to loading sheer number of horizon maps!
real1m20.385s
user1m18.853s
sys 0m1.272s
# r.sun with 24x 15 deg seeds
real0m32.185s
user0m31.774s
sys 0m0.248s
# r.sun with 12x 30 deg seeds
real0m29.518s
user0m29.382s
sys 0m0.120s
#
}}}
{{{
plot_stuff()
{
r.colors $MAP -e color=bcyr
d.rast $MAP
d.vect gauss_200m_contours color=180:180:180
echo $1 | d.text color=black
eval `r.univar -g $MAP`
echo sum: $sum | d.text color=black at=1,5
d.legend $MAP range=1300,1500
}
###
d.mon x2
d.resize w=1024 h=768
d.split.frame 4
#
d.frame uno
MAP=rad_test.355.beam.try5
plot_stuff Std.
#
d.frame dos
MAP=rad_test.355.beam.Hz1deg.try5
plot_stuff w/ 1 degree horizon seeds
#
d.frame tres
MAP=rad_test.355.beam.Hz15deg.try5
plot_stuff w/ 15 degree horizon seeds
#
d.frame cuatro
MAP=rad_test.355.beam.Hz30deg.try5
plot_stuff w/ 30 degree horizon seeds
###
d.frame full_screen
#d.out.file out=rsun_horizons format=png
}}}
next I will try std and 1deg horizons with a r.sun time step of 3 min
instead of 30 minutes. (sun travels ~1deg of sky in 4min)
Hamish
--
Ticket URL: https://trac.osgeo.org/grass/ticket/498#comment:9
GRASS GIS http://grass.osgeo.org
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Re: [GRASS GIS] #498: r.sun2 out of sync / broken svn history
#498: r.sun2 out of sync / broken svn history
-+--
Reporter: hamish | Owner: hamish
Type: defect | Status: assigned
Priority: major | Milestone: 6.4.0
Component: Raster | Version: svn-develbranch6
Resolution: |Keywords: r.sun
Platform: Linux | Cpu: x86-32
-+--
Comment (by hamish):
first four more step sizes to add to previous 1,15,30 deg.
{{{
with 120x 3 deg horizon maps, 'r.sun -s' runs in:
real0m45.418s
user0m44.895s
sys 0m0.464s
with 72x 5 deg horizon maps, 'r.sun -s' runs in:
real0m38.214s
user0m37.822s
sys 0m0.368s
with 45x 8 deg horizon maps, 'r.sun -s' runs in:
real0m34.099s
user0m33.806s
sys 0m0.296s
with 36x 10 deg horizon maps, 'r.sun -s' runs in:
real0m34.072s
user0m33.666s
sys 0m0.244s
}}}
see attached rsun_horizons3_5_8_10.png
interestingly 36x 10 degree horizon maps is seemingly the most consistent.
I wonder if the trick is to match the horizon angle frequency with the
r.sun time step= option?
-
next I will try std and 1deg horizons with a r.sun time step of
3 min instead of 30 minutes. (sun travels ~1deg of sky in 4min)
3 minute setup:
{{{
time r.sun -s elevin=gauss day=$DAY \
beam_rad=rad_test.355.beam.3min_step.try6 step=0.05
real24m34.998s
user24m32.680s
sys 0m2.488s
time r.sun -s elevin=gauss day=$DAY \
beam_rad=rad_test.355.beam.3min_step.Hz1deg.try6 \
step=0.05 horizon=horangle horizonstep=1
real4m45.455s
user4m44.054s
sys 0m1.320s
}}}
plotting setup:
{{{
plot_stuff()
{
r.colors $MAP -e color=bcyr
d.rast $MAP
d.vect gauss_200m_contours color=180:180:180
echo $1 | d.text color=black
eval `r.univar -g $MAP`
echo sum: $sum | d.text color=black at=1,5
d.legend $MAP range=1300,1500
}
###
d.mon x2
d.resize w=1024 h=768
d.split.frame 4
#
d.frame uno
MAP=rad_test.355.beam
plot_stuff dt=30min; no horizon seeds
#
d.frame dos
MAP=rad_test.355.beam.Hz1deg.try5
plot_stuff dt=30min; 1 degree horizon seeds
#
d.frame tres
MAP=rad_test.355.beam.3min_step.try6
plot_stuff dt=3min; no horizon seeds
#
d.frame cuatro
MAP=rad_test.355.beam.3min_step.Hz1deg.try6
plot_stuff dt=3min; 1 degree horizon seeds
###
d.frame full_screen
#d.out.file out=rsun_horizon_dt format=png
}}}
see attached rsun_horizon_dt.png.
hmmm... are the lower lobes for 1 degree r.horizon seeds real?
maybe that 10 degree step size is actually the worst case. Again this is
for the winter solstice so the sun should never get into the NE,NW.
I suspect the standard r.sun @ 3min steps without horizon seeds is in fact
the most accurate result.
I suppose the way to test that is to run r.sun in Mode 1 for a loop
over the day and then run r.series to sum them and see if the pattern
matches. But that's a job for later or someone else, it's the end of the
day here. I'll set it up to run overnight with a 0.0025 timestep (9sec)
no horizon seeds.
hoping this is useful,
Hamish
--
Ticket URL: https://trac.osgeo.org/grass/ticket/498#comment:10
GRASS GIS http://grass.osgeo.org
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Re: [GRASS GIS] #498: r.sun2 out of sync / broken svn history
#498: r.sun2 out of sync / broken svn history
-+--
Reporter: hamish | Owner: hamish
Type: defect | Status: assigned
Priority: major | Milestone: 6.4.0
Component: Raster | Version: svn-develbranch6
Resolution: |Keywords: r.sun
Platform: Linux | Cpu: x86-32
-+--
Comment (by hamish):
I have been doing some experiments with r.sun + a simple gaussain mound as
the elevation:
{{{
g.region -d # spearfish dataset region
r.surf.volcano gauss method=gaussian # module from addons
DAY=355 # longest shadows
}}}
I have looked at the effect of using r.horizon and slope/aspect maps.
setup:
{{{
r.horizon elev=gauss horizonstep=30 dist=0.7 horizon=horangle
r.slope.aspect elevation=gauss aspect=guass.aspect slope=guass.slope
}}}
Q1) how small must the horizonstep be to recreate the beam_rad output map
effectively as good as e.g. seen in the r.sun wiki page example?
http://grass.osgeo.org/wiki/r.sun
By using a 30deg angle step are we trading time/maps for accuracy?
For some reason the lower east wing of the butterfly pattern is stunted
using that.
Running tests with horizonstep=1 degree now.
Q2) am I using aspin= correctly? should that be a map created by
r.slope.aspect? Using it the processing speeds up by 3x, but the results
seem a bit weird -- to the south of the mound is a depression in the light
which while possible for reflected light seems that it would be upstream
incorrect for beam_rad.
defining a slopein= map (from r.slope.aspect result) doesn't change the
processing time appreciably. I haven't tested for its effect on the output
map yet.
?
Hamish
--
Ticket URL: https://trac.osgeo.org/grass/ticket/498#comment:7
GRASS GIS http://grass.osgeo.org
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Re: [GRASS GIS] #498: r.sun2 out of sync / broken svn history
#498: r.sun2 out of sync / broken svn history -+-- Reporter: hamish | Owner: hamish Type: defect | Status: assigned Priority: major | Milestone: 6.4.0 Component: Raster | Version: svn-develbranch6 Resolution: |Keywords: r.sun Platform: Linux | Cpu: x86-32 -+-- Changes (by hamish): * cc: grass-dev@lists.osgeo.org (added) * owner: grass-dev@lists.osgeo.org = hamish * status: new = assigned -- Ticket URL: https://trac.osgeo.org/grass/ticket/498#comment:6 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Re: [GRASS GIS] #498: r.sun2 out of sync / broken svn history
#498: r.sun2 out of sync / broken svn history
-+--
Reporter: hamish | Owner: grass-dev@lists.osgeo.org
Type: defect | Status: new
Priority: major | Milestone: 6.4.0
Component: Raster | Version: svn-develbranch6
Resolution: |Keywords: r.sun
Platform: Linux | Cpu: x86-32
-+--
Comment (by hamish):
fyi, my setup for testing r.sun will now be:
{{{
#spearfish
g.region -d
r.surf.volcano out=gauss method=gaussian
DAY=180
r.sun '-s' # shading calc ON
}}}
it is much easier with a standardized hill which is simple enough that you
can intuitively understand the result.
Hamish
--
Ticket URL: https://trac.osgeo.org/grass/ticket/498#comment:4
GRASS GIS http://grass.osgeo.org
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
