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

[GRASS GIS]

#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

Comment:

 ... 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
 done

 # daily
 INMAPS=""
 for HOUR in `seq 7 16` ; do
    INMAPS="$INMAPS,beam_sum_$HOUR.oclock"
 done
 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
 HOUR=8
 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)
 (8.82,8.83).

 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)


 ??,
 Hamish

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