Dear Alex,
thank you for the answers and suggestions. I checked what you suggested
(the saga forum also) and the only thing left is how to avoid the latitude
definition in case when in.latitude.grid is specified.
At 19:48 28.11.2011, Alexander Brenning wrote:
Dear Melita,
I will try to answer your questions, but you will likely get better
feedback from the SAGA pros if you post them to the SAGA user forum on
sourceforge, see
http://sourceforge.net/projects/saga-gis/support
Dear saga and rsaga users and developers (Olaf, Alex, Victor..)<br><br>
I ran a small piece of code, testing the rsaga.pisr function for
calculation of potential solar radiation.<br><br>
<ul>
<li>Question is: if I calculate the rsaga.pisr for April 1th till April
4th, day by day, sum those and compare it with the rsaga.pisr calculated
for the range of days April 1-4th, there is an unexpected difference
ranging from (4.821417, 6.996113)kWh/m2. Can you help me to fix or
explain this?
Solar radiation was likely only calculated until April 3rd. I haven't
tried this out with rsaga.pisr, but some time ago in an earlier version I
found this in rsaga.solar.radiation, i.e. a different SAGA modules that
takes similar arguments:
In SAGA 2.0.2, solar radiation sums calculated for a range of days, say
days=c(a,b) actually calculate radiation only for days a,...,b-1 (in
steps of day.step - I used day.step=1 in this example). The setting a=b
however gives the same result as b=a+1, and indeed b=a+2 gives twice the
radiation sums and potential sunshine duration that a=b and b=a+1 both give.
This might explain your problem, but if you want to be sure you'd better
examine this in more detail by looking at different time spans, especially
one versus two days (does radiation increase by a factor of 2?)
Thanks for the confirmation. That is what I also assumed.
But it seams it does not include the first but the last day of the range of
days in the calculation. I checked the calculation for the April 1st and
April 2nd individually. Insolation for the range of days 1-2 April equals
to pisr for the April 2nd. The difference of those grids are 0 everywhere.
And actually it writes in the R session:
initialising gradient...
day 92(91-92), local time 05:00
day 92(91-92), local time 08:00
day 92(91-92), local time 11:00
day 92(91-92), local time 14:00
day 92(91-92), local time 17:00
day 92(91-92), local time 20:00
day 92(91-92), local time 23:00
and that is April 2nd.
It is not so perfect if I compare several (4) days. Most of the cells have
0 difference but some diff. are larger. But not so large that I couldn't
work with that.
<li>Second question is a technical one: when the R script calls
rsaga.pisr I can not have the SAGA gui opened since it crashes down. Is
that expected?
no it isn't, and I haven't experienced this problem with SAGA 2.0.7 on
Windows.
I also run SAGA 2.0.7 on Windows.
It seems the problem was with the available working memory. I ran the
example on a large grid. When I made a smaller selection, it didn't crash
any more.
Thanks again.
<li>Considering the latitude=user defined, why do we need it since the
latitude grid is defined?
not all the arguments are mandatory. you would specify either latitude or
in.latitude.grid
I tried the command with in.latitude.grid specified and
1. without latitude in the command. I got an error:
Error in latitude >= -90 : 'latitude' is missing
2. vith latitude=NULL
but than also latitude grid was neglected
3. I have no idea what else to try. I will put latitude=45 instead.
So this seems the only unsolved question. Not bad at all! Thanks.
<li>And finally, there is a comment concerning the units in the
rsaga.pisr when you chose kJ/m2. If I'm not mistaken, the resulting grid
is actually in MJ/m2.
sorry I cannot confirm this, but it should be possible to determine that
by comparing average hourly PISR with the solar constant times 1 hour,
which will be higher but of the same order of magnitude as PISR if in the
same units. If that doesn't help, please follow up in the SAGA GIS forums
to find out if that's an error and issue a bug report if necessary.
I can explain this.
If pisr is calculated with the option: unit=c("kJ/m2") it is exactly 3.6
times larger compared to one calculated with the option: unit=c("kWh/m2")
but:
kW h = [h=3600s] = 3600 kWs = [W = J/s] = 3600 kJ = 3.6 MJ
So calculation is OK, only for the calculated grid the units should be:
"units=MJ/m2".
Smaller example is on http://radar.dhz.hr/~melita/
Kind regards,
Melita.
I hope this helps
Alex
</ul>The R script and input grids are provided in
<a href="http://radar.dhz.hr/~melita"; eudora="autourl">
http://radar.dhz.hr/~melita<br><br>
<br>
</a>Thank you for the help and a nice tools that we can all use and
benefit from it.<br><br>
Regards,<br><br>
Melita Percec Tadic<br><br>
Date: Fri, 25 Nov 2011 16:52:57 +0100
From: Melita Percec Tadic <[email protected]>
To: [email protected]
Subject: [R-sig-Geo] rsaga, radiation, rsaga.pisr
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
An HTML attachment was scrubbed...
URL:
<https://stat.ethz.ch/pipermail/r-sig-geo/attachments/20111125/2faacf51/attachment-0001.html>
--
Alexander Brenning
[email protected] - T +1-519-888-4567 ext 35783
Department of Geography and Environmental Management
University of Waterloo
200 University Ave. W - Waterloo, ON - Canada N2L 3G1
http://www.environment.uwaterloo.ca/geography/faculty/brenning/
__________ NOD32 6667 (20111128) Information __________
This message was checked by NOD32 antivirus system.
http://www.eset.com
_______________________________________________
R-sig-Geo mailing list
[email protected]
https://stat.ethz.ch/mailman/listinfo/r-sig-geo
