r.sun (mode 1): data are not timestamped correctly

[fabriziosossan]

While comparing the output of r.sun (mode 1) with experimentally measured data from a pyranometer, we noticed that the produced global horizontal irradiance data are not correctly timestamped.

The problem was given by a wrong sign in the code. Please see the attached patch.

[fabriziosossan]

Patch for the file grass-6.4.5/raster/r.sun2/main.c

[wenzeslaus]

Formally it looks good to me. Can you please comment on it, so we can put it to the source code with explanation?

And slightly related to that, are you willing to share some of your results? There are many options how to do that depending on your methods, but a very interesting one is an actual Python code which does the comparison.

For those who are in doubts: r.sun2 in 6.4 branch is r.sun in 7.0 branch.

[neteler]

Ticket retargeted after milestone closed

[neteler]

Ticket retargeted after 7.0.3 milestone closed

[fabriziosossan]

Hi,

This is our logic explanation for changing the time offset sign from positive to negative.

It should be noted first that there is no agreed convention for the sign of the Equation of Time (EoT in the following) and can appear in both the forms shown in [1] and [2]. The EoT implemented in the code is as former, where positive y values denotes that a wall clock is slower than a sundial, and vice-versa. For example, assuming to be i) at greenwich latitude ii) on the 1st January (when EoT is approx. -3 minutes) and iii) with the sun exactly at south (solar noon), a wall clock would appear faster and would mark 12:03 of civil time. Therefore the additive offset to pass from the solar time to civil time should be positive, namely the EoT expression should be with inverted sign.

Inverting the EoT sign in order to obtain, for example, a positive offset for the 1st of January, is coherent with the correction that is applied for the longitude displacement later in code:

longitTime = -longitude / 15.

In this case, when moving eastwise from the greenwich meridian (this means progressively increasing positive values of the longitude), the sun position will move in the sky to west: in this case the clock would appear slower than a sundial and the offset, conversely to the previous case, should be indeed strictly negative.

Finally, one might wonder if later in the code the signs of the discussion expressions are changed: this is not the case as these two contributions are summed up together.

[1] ​https://en.wikipedia.org/wiki/Equation_of_time#/media/File:Equation_of_time.svg [2] ​https://en.wikipedia.org/wiki/Equation_of_time#/media/File:Tijdvereffening-equation_of_time-en.jpg

[martinl]

Is there any plan for backport? It's noted in wiki:Grass7Planning#a7.0.4tobebackported and we are close to RC1 (15/4)...

[neteler]

Thanks for testing r.sun and the patch, applied in r68253 in releasebranch_6_4.

Compare also the equivalent alternative GRASS GIS 7 fix suggested in #2941 (commented on in cited email in ​https://lists.osgeo.org/pipermail/grass-dev/2016-April/079789.html).

Closing.