[GRASS5] r.sun parameter descriptions

Hi,

the following change improved the r.sun parameter descriptions somewhat:

grass6/raster/r.sun/main.c
  http://grass.itc.it/pipermail/grass-commit/2005-March/016953.html

but left many option desciptions ending with "[-]" (e.g. albedo).

Should these be replaced with [0-1] ?

add to opt->options or (0 <= x <= 1) checks in the C code?

Anyone have plans or thoughts about migrating to the SOLPOS algorithm?
What sort of improvement would this bring? i.e. is the difference large
enough to matter in a practical sense or is it more an academic matter
of making the model as correct as it can be?

thanks,
Hamish

Hamish wrote:

Hi,

the following change improved the r.sun parameter descriptions somewhat:

grass6/raster/r.sun/main.c
  http://grass.itc.it/pipermail/grass-commit/2005-March/016953.html

but left many option desciptions ending with "[-]" (e.g. albedo).

Should these be replaced with [0-1] ?

add to opt->options or (0 <= x <= 1) checks in the C code?

A hyphen in the brackets explains that the parameter has no units. Albedo is within <0-1> range but Linke turbidity factor has no strict limits. It typically ranges between 3 (clear skies) to 7 (heavily polluted skies).

Anyone have plans or thoughts about migrating to the SOLPOS algorithm?
What sort of improvement would this bring? i.e. is the difference large
enough to matter in a practical sense or is it more an academic matter
of making the model as correct as it can be?

As far as I know nobody is working on this. Thomas Huld from JRC in Ispra has made several changes and improvements for a shadowing algorithm, but it's not ready for a CVS upload. We have some discussions on some issues and it needs more testing.

Jaro

thanks,
Hamish

> Anyone have plans or thoughts about migrating to the SOLPOS
> algorithm? What sort of improvement would this bring? i.e. is the
> difference large enough to matter in a practical sense or is it more
> an academic matter of making the model as correct as it can be?

As far as I know nobody is working on this.

What I was getting at was: is this was worth me spending time on or not
in the future? How much would it improve the model? Would the effort
make any real difference to the answer or is it negligible?

Hamish

There was a discussion on this a couple of years ago between me, Markus and Marcel Suri. The reason for this is that the SOLPOS algorithm is already implemented in r.sunmask. So, implementing SOLPOS in r.sun would eliminate a need for r.sunmask or unify solar algorithms used in both modules. So far, I haven't done any tests and comparisons between r.sunmask and r.sun regarding computed sun parameters. The differences should be small, but it depends on application and accuracy requirements. There are many approximation formulas that are all correct. Maybe Markus can help on this too.

Jaro

Hamish wrote:

Anyone have plans or thoughts about migrating to the SOLPOS
algorithm? What sort of improvement would this bring? i.e. is the
difference large enough to matter in a practical sense or is it more
an academic matter of making the model as correct as it can be?

As far as I know nobody is working on this.

What I was getting at was: is this was worth me spending time on or not
in the future? How much would it improve the model? Would the effort
make any real difference to the answer or is it negligible?

Hamish