[GRASS-dev] Re: [GRASS GIS] #498: r.sun2 commissioning trials

GRASS GIS trac at osgeo.org
Thu Aug 13 01:55:47 EDT 2009

#498: r.sun2 commissioning trials
  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):

  * summary:  r.sun2 out of sync / broken svn history => r.sun2
              commissioning trials


 ... continuing on from the last entry in the bug log ...

 # combine into hourly sums (867 input maps too many for shell)
 for HOUR in `seq 7 16` ; do
    echo " $HOUR o'clock"
    INMAPS=`g.mlist rast patt="rad1_test.${DAY}_$HOUR.??_beam" sep=,`
    r.series in="$INMAPS" out=beam_sum_$HOUR.oclock method=sum
    r.colors beam_sum_$HOUR.oclock color=bcyr

 # daily
 for HOUR in `seq 7 16` ; do
 INMAPS=`echo "$INMAPS" | sed -e 's/^,//'`

 # animate the day
 xganim $INMAPS

 # daily sum
 r.series in="$INMAPS" out=beam_sum_day.355 method=sum
 r.mapcalc "beam_irad_day.355 = beam_sum_day.355 * $STEP"

 the result is ''highly'' similar (but not exactly identical numerically)
 to the same step size (36sec; dt=0.01) Mode 2 raster as seen in the upper
 right pane of the rsun36_9sec_diff.jpg attached image. So choosing mode 1
 vs mode 2 seems to introduce no errors.

 # animate an hour
 INMAPS=`g.mlist rast patt="rad1_test.355_$HOUR.??_beam" sep=,`
 xganim $INMAPS

 here we see a big jump between runs for time = (8.45,8.46) (8.72,8.73)

 Just looking at the biggest lobe-jump (8.45,8.46) I did a few more runs at
 time=8.455, 8.45875, etc.
 Results in rsun_8oclock_jump.png (attached) detailing the moment of the
 sudden disappearance of a lobe on the south-eastern side. These lobes seem
 to be responsible for the jumpy nature of the Mode 2 output.

 I looked at the input map's (gauss) slope and curvature maps (1st & 2nd
 derivative) from r.slope.aspect; the input map seems perfectly smooth &
 error free.

 Even with this, it should be noted that the output is much cleaner than
 the old version of r.sun (as long as you don't use the aspin= and slopein=
 options, then it still hits the same bug as the old version)


Ticket URL: <https://trac.osgeo.org/grass/ticket/498#comment:13>
GRASS GIS <http://grass.osgeo.org>

More information about the grass-dev mailing list