#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>
_______________________________________________ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev