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

GDAL · February 19, 2009, 4:04am

#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
Keywords: r.sun | Platform: Linux
Cpu: x86-32 |
--------------------+-------------------------------------------------------
Hi,

[6.5svn]

I was trying to figure out why r.sun was not using its short module
description label. It seemed that somewhere it was reset to null, so the
description was used regardless.
In 6.3.0 it works. module_info.keywords also seemed to be reset to null.

{{{
r.sun --tcltk | head -n 3
begin_dialog {r.sun} {
label {}
desc {Computes direct (beam), diffuse and ...
}}}

but in r.sun/main.c:
{{{
    module->keywords = _("raster");
     module->label = _("Solar irradiance and irradiation model.");
     module->description =
         _("Computes direct (beam), diffuse and ...

}}}

same for --help and --interface-description. I noticed that (eg) 'r.info
--help' reports the keyword.

When I loaded up `which r.sun` in Kdbg to follow the action live, I
noticed the source listing had the ->keywords and ->label lines missing.
wtf?!

aaaaaaahhhhhhh.... now I notice in the Kdbg title bar the full path to the
source: ..../raster/r.sun2/main.c not raster/r.sun/main.c!

Apparently r.sun2 does not contain the latest changes to r.sun even though
it has replaced it in the Makefile. As keyword support was added to
r.sun/main.c on 08/19/06, and that's a while ago now, well, much
unhappiness. not sure how far back r.sun2 goes.

attack of the out-of-sync clones & another "svn copy" related tragedy.
(granted it was added to svn some months ago, when we were all young about
these things)

Hamish

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

GDAL · February 19, 2009, 10:43am

#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 neteler):

Replying to [ticket:498 hamish]:
> Apparently r.sun2 does not contain the latest changes to r.sun even
though it has replaced it in the Makefile. As keyword support was added to
r.sun/main.c on 08/19/06, and that's a while ago now, well, much
unhappiness. not sure how far back r.sun2 goes.

In r35938, r35939, r35940 (7, 6.4.svn, 6.4.0.svn) I have merged
pre-fork updates from old r.sun into r.sun2.

> attack of the out-of-sync clones & another "svn copy" related tragedy.
> (granted it was added to svn some months ago, when we were all young
about these things)

No, the first tragedy. The "svn copy" ideal-world-solution came up
only after that. Yes, sh*t happens. Note that r.sun2 was forked years
ago and merging in changes of r.sun/GRASS took already hours. Oversights
are possible.

TODO: understand usage of
{{{
if (latin == NULL && lt == NULL && (G_projection() != PROJECTION_LL)) {
}}}

which yet differs.

Markus

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

neteler · February 19, 2009, 10:50am

On Thu, Feb 19, 2009 at 5:04 AM, GRASS GIS <trac@osgeo.org> wrote:

#498: r.sun2 out of sync / broken svn history

attack of the out-of-sync clones & another "svn copy" related tragedy.
(granted it was added to svn some months ago, when we were all young about
these things)

Defense (Changelog analysis):

TOP-20 GRASS code contributors sorted by commits:
Name #commits percentage
markus 4756 24.77
bernhard 2487 12.95
hamish 2011 10.47
martinl 1607 8.37
glynn 1461 7.61
radim 1365 7.11
michael 724 3.77
cho 574 2.99
neteler 534 2.78
barton 478 2.49
brad 415 2.16
paul 279 1.45
landa 255 1.33
jachym 208 1.08
carlos 190 0.99
soeren 146 0.76
cepicky 126 0.66
cmbarton 125 0.65
cedric 125 0.65
helena 120 0.62

OK, take out for me the initial commit in 1999 and
Bernhard's creation of a new CVS repository some
years later. Still the order remains.
Now you can calculate the signal to noise ratio

I admit to not be a SVN guru, ready to learn.

Well, back to tech-talk:
should we create a diff to r.sun, delete r.sun2
from SVN, svn copy r.sun to r.sun2 and apply the
diff to carry over the history?

Markus

GDAL · February 19, 2009, 10:58am

#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 neteler):

One more problem:

{{{
    r.sun -s elevin="pat_dtm_5m" aspin="pat_dtm_5m.as" aspect=270 slopei\
    n="pat_dtm_5m.sl" slope=0.0 linkein="linke_turbidity04" lin=3.0 alb=\
    0.2 horizon="pat5m_horangle" horizonstep=30 beam_rad="pat_beam_rad10\
    4" insol_time="pat_insol_time104" diff_rad="pat_diff_rad104" refl_ra\
    d="pat_refl_rad104" glob_rad="pat_glob_rad104" day=104 step=0.5 dist\
    =1.0 numpartitions=64
}}}

If aspin= and/or slopein= are used, aspect=270 and/or slope=0.0 should
be suppressed in the history. How to do that? Currently the history
is confusing.

Markus

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

GDAL · February 20, 2009, 12:12am

#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):

Replying to [comment:1 neteler]:
> In r35938, r35939, r35940 (7, 6.4.svn, 6.4.0.svn) I have merged
> pre-fork updates from old r.sun into r.sun2.

cheers.

> Replying to [ticket:498 hamish]:
> > attack of the out-of-sync clones & another "svn copy" related
> > tragedy. (granted it was added to svn some months ago, when
> > we were all young about these things)
MN:
> No, the first tragedy. The "svn copy" ideal-world-solution came
> up only after that. Yes, sh*t happens. Note that r.sun2 was
> forked years ago and merging in changes of r.sun/GRASS took
> already hours. Oversights are possible.

whoa, I wasn't pointing that at you personally at all. sorry if it came
across that way, it was meant as a general comment. I have spent too many
hours merging stuff by hand to be anything but humble about it, and am
certainly no svn expert at all. FWIW as the past example I was
specifically thinking about the pain to merge years of here-and-there bug
fixes between the four i.points clones some time ago.

> TODO: understand usage of
{{{
if (latin == NULL && lt == NULL && (G_projection() != PROJECTION_LL)) {
}}}
>
> which yet differs.

I will try and have a look. (just ran indent on r.sun2 to make it easier)

also I wonder about r19184. r.sun2 has the <= part, so I lightly guess the
0.5 part of the patch has been considered & dropped??

Hamish

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

Hamish · February 20, 2009, 8:12am

Markus wrote:

Well, back to tech-talk:
should we create a diff to r.sun, delete r.sun2
from SVN, svn copy r.sun to r.sun2 and apply the
diff to carry over the history?

I think we should, after we are happy that they are in sync. Having two
copies there is just asking for trouble, and that way, as you say, we
get to keep the change history.

do you see any reason to keep the old version around?

Hamish

neteler · February 20, 2009, 1:05pm

On Fri, Feb 20, 2009 at 9:12 AM, Hamish <hamish_b@yahoo.com> wrote:

Markus wrote:

Well, back to tech-talk:
should we create a diff to r.sun, delete r.sun2
from SVN, svn copy r.sun to r.sun2 and apply the
diff to carry over the history?

I think we should, after we are happy that they are in sync. Having two
copies there is just asking for trouble, and that way, as you say, we
get to keep the change history.

do you see any reason to keep the old version around?

No reason once the goodies are merged over.
So both fine for me.

Markus

neteler · March 1, 2009, 7:32pm

On Fri, Feb 20, 2009 at 9:12 AM, Hamish <hamish_b@yahoo.com> wrote:

Markus wrote:

Well, back to tech-talk:
should we create a diff to r.sun, delete r.sun2
from SVN, svn copy r.sun to r.sun2 and apply the
diff to carry over the history?

I think we should, after we are happy that they are in sync. Having two
copies there is just asking for trouble, and that way, as you say, we
get to keep the change history.

do you see any reason to keep the old version around?

Thinking about this: how 'bout diffing and update the old
directory and remove the new r.sun2 directory (which doesn't
have the history)
?

Markus

Hamish · March 2, 2009, 5:10am

Markus:

Thinking about this: how 'bout diffing and update the old
directory and remove the new r.sun2 directory (which doesn't
have the history)

oh, that's what I thought you meant to do; fine idea.

Can we now say that all bugfixes have been cross-ported & we won't lose
any?

Hamish

neteler · March 2, 2009, 8:16am

On Mon, Mar 2, 2009 at 6:10 AM, Hamish <hamish_b@yahoo.com> wrote:

Markus:

Thinking about this: how 'bout diffing and update the old
directory and remove the new r.sun2 directory (which doesn't
have the history)

oh, that's what I thought you meant to do; fine idea.

Can we now say that all bugfixes have been cross-ported & we won't lose
any?

Remains the TODO - see ticket:

TODO: understand usage of

if (latin == NULL && lt == NULL && (G_projection() != PROJECTION_LL)) {

which yet differs. Could you please take a look?

Markus

GDAL · April 22, 2009, 9:11am

#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>

GDAL · April 22, 2009, 11:23am

#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):

.. make that using day 355 for testing. more noticeable shadows to follow.

* the incidout output map needs to be modified so fully-shaded reports
NULL not 0 degrees incidence angle.

* for mode 2 I notice that I have to drop the time step to about 3
minutes to get a smooth output map (step=0.05)

H

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

GDAL · August 10, 2009, 5:30am

#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>

GDAL · August 11, 2009, 3:57am

#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>

GDAL · August 11, 2009, 8:43am

#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
real 3m1.750s
user 3m1.327s
sys 0m0.400s
#

time r.sun -s elevin=gauss day=$DAY beam_rad=rad_test.355.beamA.try4 \
aspin=guass.aspect
real 3m4.432s
user 3m4.092s
sys 0m0.364s
#

time r.sun -s elevin=gauss day=$DAY beam_rad=rad_test.355.beamS.try4 \
slopein=guass.slope
real 3m7.865s
user 3m6.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
real 1m32.279s
user 1m31.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>

GDAL · August 11, 2009, 9:33am

#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
real 3m7.571s
user 3m7.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!
real 1m20.385s
user 1m18.853s
sys 0m1.272s

# r.sun with 24x 15 deg seeds
real 0m32.185s
user 0m31.774s
sys 0m0.248s

# r.sun with 12x 30 deg seeds
real 0m29.518s
user 0m29.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>

GDAL · August 11, 2009, 1:08pm

#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>

GDAL · August 12, 2009, 10:30am

#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
real 479m0.940s
user 476m11.914s
sys 1m12.181s

time r.sun -s elevin=gauss day=$DAY \
beam_rad=rad_test.355.beam.36sec_step.try7 step=0.01
real 217m34.835s
user 217m12.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>

GDAL · August 12, 2009, 12:23pm

#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.000001 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>

GDAL · August 13, 2009, 5:55am

#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>