[GRASS-dev] Re: [GRASS GIS] #498: r.sun2 out of sync / broken svn history

GRASS GIS trac at osgeo.org
Tue Aug 11 09:08:11 EDT 2009


#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:
 real    0m45.418s
 user    0m44.895s
 sys     0m0.464s

 with 72x 5 deg horizon maps, 'r.sun -s' runs in:
 real    0m38.214s
 user    0m37.822s
 sys     0m0.368s

 with 45x 8 deg horizon maps, 'r.sun -s' runs in:
 real    0m34.099s
 user    0m33.806s
 sys     0m0.296s

 with 36x 10 deg horizon maps, 'r.sun -s' runs in:
 real    0m34.072s
 user    0m33.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
 real    24m34.998s
 user    24m32.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
 real    4m45.455s
 user    4m44.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>


More information about the grass-dev mailing list