I would like to use the r.sun module to produce a map of montly solar
radiation for a certain area. I would like to incorporate cloud cover
data into the calculations, as well as information on local topography
(i.e. aspect and slope). I was wondering whether you could help me to
solve two problems: i) I have not quite yet understood what I should
do to specify a raster containing data on cloudiness when using the
module
eg. r.sun elevin=altmap aspin=aspmap slopein=slopemap + cloudmap?? ii)
I am interested in a montly average of daily sum of solar radiation,
and I only have montly cloud cover data. I suspect that this is not
ideal when calculations by r.sun are done on daily basis. Do you
confirm? Is there a way around this?
I would like to use the r.sun module to produce a map
of montly solar
radiation for a certain area. I would like to incorporate
cloud cover
data into the calculations, as well as information on local
topography
(i.e. aspect and slope).
slope and aspect are automatically taken into
account even if you don't use the slope and aspect
input map options.
just use the -s shading flag and the rest will
happen automatically.
I was wondering whether you could
help me to
solve two problems: i) I have not quite yet understood what
I should
do to specify a raster containing data on cloudiness when
using the module
eg. r.sun elevin=altmap aspin=aspmap slopein=slopemap +
cloudmap??
from the help page:
Besides clear-sky radiations, the user can compute a real-sky
radiation (beam, diffuse) using coefbh and coefdh input
raster maps defining the fraction of the respective clear-sky
radiations reduced by atmospheric factors (e.g. cloudiness).
The value is between 0-1. Usually these coefficients can be
obtained from a long-terms meteorological measurements pro-
vided as raster maps with spatial distribution of these coef-
ficients separately for beam and diffuse radiation (see Suri
and Hofierka, 2004, section 3.2).
I've now updated the module in trunk and devbr6 to
(a little) better explain that.
ii)
I am interested in a montly average of daily sum of solar
radiation,
and I only have montly cloud cover data. I suspect
that this is not
ideal when calculations by r.sun are done on daily basis.
Do you confirm? Is there a way around this?
If it's all you have to work with, it's all you have
to work with & you'll have to pretend like every
day is like the climactic average.
some LiCOR light data or even battery voltage from an installed
solar panel at a weather station can give you an
idea about which days are cloudy, and by how much.
Simone wrote:
> I would like to use the r.sun module to produce a map
> of montly solar
> radiation for a certain area. I would like to incorporate
> cloud cover
> data into the calculations, as well as information on local
> topography
> (i.e. aspect and slope).
slope and aspect are automatically taken into
account even if you don't use the slope and aspect
input map options.
> I was wondering whether you could
> help me to
> solve two problems: i) I have not quite yet understood what
> I should
> do to specify a raster containing data on cloudiness when
> using the module
> eg. r.sun elevin=altmap aspin=aspmap slopein=slopemap +
> cloudmap??
from the help page:
> Besides clear-sky radiations, the user can compute a real-sky
> radiation (beam, diffuse) using coefbh and coefdh input
> raster maps defining the fraction of the respective clear-sky
> radiations reduced by atmospheric factors (e.g. cloudiness).
> The value is between 0-1. Usually these coefficients can be
> obtained from a long-terms meteorological measurements pro-
> vided as raster maps with spatial distribution of these coef-
> ficients separately for beam and diffuse radiation (see Suri
> and Hofierka, 2004, section 3.2).
I've now updated the module in trunk and devbr6 to
(a little) better explain that.
> ii)
> I am interested in a montly average of daily sum of solar
> radiation,
> and I only have montly cloud cover data. I suspect
> that this is not
> ideal when calculations by r.sun are done on daily basis.
> Do you confirm? Is there a way around this?
If it's all you have to work with, it's all you have
to work with & you'll have to pretend like every
day is like the climactic average.
some LiCOR light data or even battery voltage from an installed
solar panel at a weather station can give you an
idea about which days are cloudy, and by how much.