[GRASS-user] Re: [GRASS-dev] Changes to r.sun made Feb 2006 [resolved]

[Dylan Beaudette]

Hi Hamish, 
replies are in-line:

On Thursday 30 November 2006 22:13, Hamish wrote:
> Dylan Beaudette wrote:
> > PS: with even better results from r.sun:
> > http://169.237.35.250/~dylan/temp/11-yr_variation_vs_modeled.png
> >
> > when using longer term averages, the R^2 goes to 0.95 ! (right hand
> > sub-figure), but still working on optimal Linke turbidity values.
>
> Did you extract the Linke turbidity values from the app. on the EU web
> site, derive it from measured in situ values, or are you tweaking that
> variable as a calibration to get r.sun to match your measured radiation
> values?

I used the 'rural' values from the r.sun manual page as a starting point, and 
then modified according to my observations of the local climate + tweaking to 
make r.sun match the weather station: i.e. i need a more robust approach!

> I see you have a bit of sawtooth noise in your plots. FWIW to avoid
> introducing this monthly jump I wrote a little app some time ago which
> interpolated daily Linke value from the monthly Linke averages (for use
> in r.sun bash script loop) [assume monthly averages are for day 15 of
> each month and interpolate for the days in between]. I'd have to dig it
> out, & it's probably a mix of Matlab+C. Maybe something for the wiki
> add-ons.

Indeed! I am using a constant value for the entire month. this approach is a 
step in the right direction, but introduces those sawtooth artifacts. Since I 
am working in R most of the time (for numerical operations at least), I think 
that i might implement it there, and then save the results for use in a bash 
script - which invokes r.sun.

Did your code look something like this;
# define monthly averages
l <- c(5.9,5.8,5.6,5.6,5.3,5.0,4.8,5.0,5.0,5.2,5.4,5.6)
# use periodic spline interpolation to fill in the 365 days of the year
l.s <- spline(l, method="periodic", n=365)
# plot results:
plot(l, xlab="month", ylab="Linke Turbidity")
lines(l.s)

note that this is not quite correct as it interpolates from the *start* of the 
month, as opposed to the middle. Doing that would require knowing the day of 
the middle of the month- i'll cook up that example shortly.

> How to deal with cloud cover? (coefbh= and coefdh=) Use real clear-day
> measured data (find a day with a clean curve) to estimate the cloud
> attenuation factors for neighboring cloudy days (theoretical curve vs
> what actually happened), then generalize the cloudiness factor over your
> decade long dataset?  e.g. find max (midday) light for each year's day
> 90, then take the max. maybe include +/-1 day. then run a smoothing
> filter on the result. ?? probably want the coeffs to vary throughout
> the year.

Nice idea. I will hang onto this for future reference. Since we are interested 
relatively long time scales (effects of clouds goes to some constant when 
viewed by glacial vs. interglacial episodes) estimating the cloud cover might 
be overkill. However, in other regions where the orographic effect is more 
pronounced it might be a good idea.

> Another idea I've been playing with is getting cloud cover data from
> recorded PV voltage in one of our remote solar-powered weather stations
> (it lacks a real light meter). There's a pretty obvious pattern in the
> voltage signal to play with. Just a matter of calibrating it..
>

interesting. i will ask my colleagues about their solar cell voltage records.

Thanks for all the great ideas!

Cheers,

-- 
Dylan Beaudette
Soils and Biogeochemistry Graduate Group
University of California at Davis
530.754.7341