← Back to branch summary

~ubuntu-branches/ubuntu/vivid/grass/vivid-proposed

« back to all changes in this revision

Viewing changes to raster/r.sun2/description.html

  • Committer: Package Import Robot
  • Author(s): Bas Couwenberg
  • Date: 2015-02-20 23:12:08 UTC
  • mfrom: (8.2.6 experimental)
  • Revision ID: package-import@ubuntu.com-20150220231208-1u6qvqm84v430b10
Tags: 7.0.0-1~exp1
* New upstream release.
* Update python-ctypes-ternary.patch to use if/else instead of and/or.
* Drop check4dev patch, rely on upstream check.
* Add build dependency on libpq-dev to grass-dev for libpq-fe.h.
* Drop patches applied upstream, refresh remaining patches.
* Update symlinks for images switched from jpg to png.

Show diffs side-by-side

added added

removed removed

Lines of Context:
raster/r.sun2/description.html
1
 
<h2>DESCRIPTION</h2>
2
 
 
3
 
<b>r.sun</b> computes beam (direct), diffuse and ground reflected solar
4
 
irradiation raster maps for given day, latitude, surface and atmospheric
5
 
conditions. Solar parameters (e.g. time of sunrise and sunset, declination,
6
 
extraterrestrial irradiance, daylight length) are stored in the resultant maps'
7
 
history files. Alternatively, the local time can be specified to compute solar
8
 
incidence angle and/or irradiance raster maps. The shadowing effect of the
9
 
topography is optionally incorporated. This can be done either by calculating
10
 
the shadowing effect directly from the digital elevation model or using rasters
11
 
of the horizon height which is much faster. The horizon rasters can be
12
 
constructed using  <a href="r.horizon.html">r.horizon</a>.
13
 
<p>
14
 
For latitude-longitude coordinates it requires that the elevation map is in meters.
15
 
The rules are:
16
 
<ul>
17
 
<li> lat/lon coordinates: elevation in meters;
18
 
<li> Other coordinates: elevation in the same unit as the easting-northing coordinates.
19
 
</ul>
20
 
 
21
 
<p>
22
 
The solar geometry of the model is based on the works of Krcho (1990), later
23
 
improved by Jenco (1992). The equations describing Sun &#8211; Earth position as
24
 
well as an interaction of the solar radiation with atmosphere were originally 
25
 
based on the formulas suggested by Kitler and Mikler (1986). This component 
26
 
was considerably updated by the results and suggestions of the working group
27
 
co-ordinated by Scharmer and Greif (2000) (this algorithm might be replaced
28
 
by SOLPOS algorithm-library included in GRASS within <a href="r.sunmask.html">
29
 
r.sunmask</a>
30
 
 command). The model computes all three components of global radiation (beam, 
31
 
diffuse and reflected) for the clear sky conditions, i.e. not taking into 
32
 
consideration the spatial and temporal variation of clouds. The extent and
33
 
spatial resolution of the modelled area, as well as integration over time,
34
 
are limited only by the memory and data storage resources. The model is built
35
 
to fulfil user needs in various fields of science (hydrology, climatology,
36
 
ecology and environmental sciences, photovoltaics, engineering, etc.) for
37
 
continental, regional up to the landscape scales. 
38
 
<p>As an option the model considers a shadowing effect of the local topography. 
39
 
The r.sun program works in two modes. In the first mode it calculates for the set 
40
 
local time a solar incidence angle [degrees] and solar irradiance values [W.m-2].
41
 
In the second mode daily sums of solar radiation [Wh.m-2.day-1] are computed
42
 
within a set day. By a scripting the two modes can be used separately or
43
 
in a combination to provide estimates for any desired time interval. The
44
 
model accounts for sky obstruction by local relief features. Several solar
45
 
parameters are saved in the resultant maps' history files, which may be viewed
46
 
with the <a href="r.info.html">r.info</a> command.
47
 
 
48
 
<p>
49
 
The solar incidence angle raster map <i>incidout</i> is computed specifying 
50
 
elevation raster map <i>elevin</i>, aspect raster map <i>aspin</i>, slope 
51
 
steepness raster map <i>slopin,</i> given the day <i>day</i> and local time
52
 
<i>time</i>. There is no need to define latitude for locations with known
53
 
and defined projection/coordinate system (check it with the <a href="g.proj.html">
54
 
g.proj</a>
55
 
 command). If you have undefined projection, (x,y) system, etc. then the latitude
56
 
can be defined explicitly for large areas by input raster map <i>latin</i>
57
 
 with interpolated latitude values. All input raster maps must
58
 
be floating point (FCELL) raster maps. Null data in maps are excluded from
59
 
the computation (and also speeding-up the computation), so each output raster
60
 
map will contain null data in cells according to all input raster maps. The
61
 
user can use <a href="r.null.html">r.null</a>
62
 
 command to create/reset null file for your input raster maps. <br>
63
 
The specified day <i>day</i> is the number of the day of the general year
64
 
where January 1 is day no.1 and December 31 is 365. Time <i>time</i> must
65
 
be a local (solar) time (i.e. NOT a zone time, e.g. GMT, CET) in decimal system,
66
 
e.g. 7.5 (= 7h 30m A.M.), 16.1 = 4h 6m P.M.. 
67
 
<p>
68
 
Setting the solar declination <i>declin</i> by user is an option to override
69
 
the value computed by the internal routine for the day of the year. The value
70
 
of geographical latitude can be set as a constant for the whole computed
71
 
region or, as an option, a grid representing spatially distributed values
72
 
over a large region. The geographical latitude must be also in decimal system
73
 
with positive values for northern hemisphere and negative for southern one.
74
 
In similar principle the Linke turbidity factor (<i>linkein</i>, <i>lin</i>
75
 
) and ground albedo (<i>albedo</i>, <i>alb</i>) can be set. 
76
 
<p>
77
 
Besides clear-sky radiations, the user can compute a real-sky radiation (beam,
78
 
diffuse) using <i>coefbh</i> and <i>coefdh </i>input raster maps defining
79
 
the fraction of the respective clear-sky radiations reduced by atmospheric
80
 
factors (e.g. cloudiness). The value is between 0-1. Usually these
81
 
coefficients can be obtained from a long-terms meteorological measurements
82
 
provided as raster maps with spatial distribution of these coefficients separately
83
 
for beam and diffuse radiation (see Suri and Hofierka, 2004, section 3.2).
84
 
<p>
85
 
The solar irradiation or irradiance raster maps <i>beam_rad</i>, <i>diff_rad</i>,
86
 
<i>refl_rad</i> are computed for a given day <i>day,</i> latitude <i>latin</i>,
87
 
elevation <i>elevin</i>, slope <i>slopein</i> and aspect <i>aspin</i> raster maps.
88
 
For convenience, the output raster given as <i>glob_rad</i>
89
 
will output the sum of the three radiation components. The program uses 
90
 
the Linke atmosphere turbidity factor and ground albedo coefficient. 
91
 
A default, single value of Linke factor is <i>lin</i>=3.0 and 
92
 
is near the annual average for rural-city areas. The Linke
93
 
factor for an absolutely clear atmosphere is <i>lin</i>=1.0. See notes below
94
 
to learn more about this factor. The incidence solar angle is the angle between
95
 
horizon and solar beam vector. 
96
 
<p>
97
 
The solar radiation maps for a given day are computed by integrating the
98
 
relevant irradiance between sunrise and sunset times for that day. The
99
 
user can set a finer or coarser time step used for all-day radiation
100
 
calculations with the <i>step</i> option. The default value of <i>step</i> is
101
 
0.5 hour. Larger steps (e.g. 1.0-2.0) can speed-up calculations but produce
102
 
less reliable (and more jagged) results. As the sun moves through approx.
103
 
15&deg of the sky in an hour, the default <i>step</i> of half an hour will
104
 
produce 7.5&deg; steps in the data. For relatively smooth output with the
105
 
sun placed for every degree of movement in the sky you should set the
106
 
<i>step</i> to 4 minutes or less. <i>step</i><tt>=0.05</tt> is equivalent
107
 
to every 3 minutes. Of course setting the time step to be very fine
108
 
proportionally increases the module's running time.
109
 
<p>
110
 
The output units are in Wh per squared meter per given
111
 
day [Wh/(m*m)/day]. The incidence angle and irradiance/irradiation maps can
112
 
be computed without shadowing influence of relief by default or they can
113
 
be computed with this influence using the flag <i>-s</i>. In mountainous areas
114
 
this can lead to very different results! The user should be aware that taken
115
 
into account the shadowing effect of relief can slow
116
 
down the speed of computing especially when the sun altitude is low.
117
 
 When considering shadowing effect (flag <i>-s</i>) speed and precision computing
118
 
can be controlled by a parameter <i>dist</i> which defines the sampling density
119
 
at which the visibility of a grid cell is computed in the direction of a
120
 
path of the solar flow. It also defines the method by which the obstacle's
121
 
altitude is computed. When choosing <i>dist</i> less than 1.0 (i.e. sampling
122
 
points will be computed at <i>dist</i> * cellsize distance), r.sun takes
123
 
altitude from the nearest grid point. Values above 1.0 will use the maximum
124
 
altitude value found in the nearest 4 surrounding grid points. The default
125
 
value <i>dist</i>=1.0 should give reasonable results for most cases (e.g.
126
 
on DEM). <i>Dist</i> value defines a multiplying coefficient for sampling
127
 
distance. This basic sampling distance equals to the arithmetic average of
128
 
both cell sizes. The reasonable values are in the range 0.5-1.5.  The values
129
 
below 0.5 will decrease and values above 1.0 will increase the computing
130
 
speed. Values greater than 2.0 may produce estimates with lower accuracy
131
 
in highly dissected relief. The fully shadowed areas are written to the output
132
 
maps as zero values. Areas with NULL data are considered as no barrier with
133
 
shadowing effect .
134
 
<p>The maps' history files are generated containing the following listed 
135
 
parameters used in the computation: <br>
136
 
- Solar constant 1367 W.m-2 <br>
137
 
- Extraterrestrial irradiance on a plane perpendicular to the solar beam [W.m-2] <br>
138
 
- Day of the year <br>
139
 
- Declination [radians] <br>
140
 
- Decimal hour (Alternative 1 only) <br>
141
 
- Sunrise and sunset (min-max) over a horizontal plane <br>
142
 
- Daylight lengths <br>
143
 
- Geographical latitude (min-max) <br>
144
 
- Linke turbidity factor (min-max) <br>
145
 
- Ground albedo (min-max) 
146
 
<p>The user can use a nice shellcript with variable
147
 
day to compute radiation for some time interval within the year (e.g. vegetation
148
 
or winter period). Elevation, aspect and slope input values should not be
149
 
reclassified into coarser categories. This could lead to incorrect results. 
150
 
 
151
 
 
152
 
<h2> OPTIONS</h2>
153
 
<p>Currently, there are two modes of r.sun.
154
 
In the first mode it calculates solar incidence angle and solar irradiance
155
 
raster maps using the set local time. In the second mode daily sums of solar
156
 
irradiation [Wh.m-2.day-1] are computed for a specified day. 
157
 
 
158
 
<h2>NOTES</h2>
159
 
 
160
 
Solar energy is an important input parameter in different models concerning 
161
 
energy industry, landscape, vegetation, evapotranspiration, snowmelt or remote
162
 
sensing. Solar rays incidence angle maps can be effectively used in radiometric
163
 
and topographic corrections in mountainous and hilly terrain where very accurate
164
 
investigations should be performed. 
165
 
<p>
166
 
The clear-sky solar radiation model applied in the r.sun is based on the
167
 
work undertaken for development of European Solar Radiation Atlas (Scharmer 
168
 
and Greif 2000, Page et al. 2001, Rigollier 2001). The clear sky model estimates
169
 
the global radiation from the sum of its beam, diffuse and reflected components.
170
 
The main difference between solar radiation models for inclined surfaces
171
 
in Europe is the treatment of the diffuse component. In the European climate
172
 
this component is often the largest source of estimation error. Taking into
173
 
consideration the existing models and their limitation the European Solar
174
 
Radiation Atlas team selected the Muneer (1990) model as it has a sound theoretical
175
 
basis and thus more potential for later improvement. 
176
 
<p>
177
 
Details of underlying equations used in this program can be found in the
178
 
reference literature cited below or book published by Neteler and Mitasova: 
179
 
Open Source GIS: A GRASS GIS Approach (published in Kluwer Academic Publishers 
180
 
in 2002). 
181
 
<p>
182
 
Average monthly values of the Linke turbidity coefficient for a mild climate
183
 
(see reference literature for your study area): 
184
 
 
185
 
<table border="1">
186
 
<tr><th>Month</th><th>Jan</th><th>Feb</th><th>Mar</th><th>Apr</th><th>May</th><th>Jun</th><th>Jul</th><th>Aug</th><th>Sep</th><th>Oct</th><th>Nov</th><th>Dec</th><th>annual</th></tr>
187
 
<tr><td>mountains</td><td>1.5</td><td>1.6</td><td>1.8</td><td>1.9</td><td>2.0</td><td>2.3</td><td>2.3</td><td>2.3</td><td>2.1</td><td>1.8</td><td>1.6</td><td>1.5</td><td>1.90</td></tr>
188
 
<tr><td>rural</td><td>2.1</td><td>2.2</td><td>2.5</td><td>2.9</td><td>3.2</td><td>3.4</td><td>3.5</td><td>3.3</td><td>2.9</td><td>2.6</td><td>2.3</td><td>2.2</td><td>2.75</td></tr>
189
 
<tr><td>city</td><td>3.1</td><td>3.2</td><td>3.5</td><td>4.0</td><td>4.2</td><td>4.3</td><td>4.4</td><td>4.3</td><td>4.0</td><td>3.6</td><td>3.3</td><td>3.1</td><td>3.75</td></tr>
190
 
<tr><td>industrial</td><td>4.1</td><td>4.3</td><td>4.7</td><td>5.3</td><td>5.5</td><td>5.7</td><td>5.8</td><td>5.7</td><td>5.3</td><td>4.9</td><td>4.5</td><td>4.2</td><td>5.00</td></tr>
191
 
</table>
192
 
 
193
 
 
194
 
<p>
195
 
Planned improvements include the use of the SOLPOS algorithm for solar 
196
 
geometry calculations and internal computation of aspect and slope.
197
 
 
198
 
<h3>Solar time</h3>
199
 
 
200
 
By default r.sun calculates times as true solar time, whereby solar noon is
201
 
always exactly 12 o'clock everywhere in the current region. Depending on where 
202
 
the zone of interest is located in the related time zone, this may cause
203
 
differences of up to an hour, in some cases (like Western Spain) even more.
204
 
On top of this, the offset varies during the year according to the Equation
205
 
of Time.
206
 
<p>
207
 
To overcome this problem, the user can use the option <em>civiltime=&lt;timezone_offset&gt;</em>
208
 
in r.sun to make it use real-world (wall clock) time. For example, for Central 
209
 
Europe the timezone offset is +1, +2 when daylight saving time is in effect.
210
 
<p>
211
 
<!-- WE DON'T KNOW, check source code:
212
 
If the user use the <em>civiltime</em> parameter, also the longitude needs to
213
 
be supplied as a raster map with the <em>longin</em> parameter. Within a
214
 
latlon location, such a map can be easily made with:
215
 
 
216
 
<div class="code"><pre>
217
 
r.mapcalc lon_raster='x()'
218
 
</pre></div>
219
 
 
220
 
END OF WE DON'T KNOW 
221
 
-->
222
 
 
223
 
<h3>Shadow maps</h3>
224
 
A map of shadows can be extracted from the solar incidence angle map
225
 
(incidout). Areas with zero values are shadowed. The <em>-s</em> flag
226
 
has to be used.
227
 
 
228
 
<h3>Large maps and out of memory problems</h3>
229
 
 
230
 
With a large number or columns and rows, <b>r.sun</b> can consume
231
 
significant amount of memory. While output raster maps are not
232
 
partitionable, the input raster maps are using the <em>numpartitions</em>
233
 
parameter.
234
 
 
235
 
In case of out of memory error (<tt>ERROR: G_malloc: out of memory</tt>), the
236
 
<em>numpartitions</em> parameter can be used to run a segmented calculation
237
 
which consumes less memory during the computations.
238
 
 
239
 
The amount of memory by <b>r.sun</b> is estimated as follows:
240
 
 
241
 
<div class="code"><pre>
242
 
# without input raster map partitioning:
243
 
#  memory requirements: 4 bytes per raster cell
244
 
#  rows,cols: rows and columns of current region (find out with g.region)
245
 
#  IR: number of input raster maps without horizon maps
246
 
#  OR: number of output raster maps
247
 
memory_bytes = rows*cols*(IR*4 + horizonsteps + OR*4)
248
 
 
249
 
# with input raster map partitioning:
250
 
memory_bytes = rows*cols*((IR*4+horizonsteps)/numpartitions  + OR*4)
251
 
</pre></div>
252
 
 
253
 
<h2>EXAMPLE</h2>
254
 
 
255
 
<!-- still troubles with r.horizon
256
 
Spearfish example (considering also cast shadows):
257
 
<div class="code"><pre>
258
 
g.region rast=elevation.dem -p
259
 
 
260
 
# calculate horizons
261
 
# (we put a bufferzone of 10% of maxdistance around the study area)
262
 
r.horizon elevin=elevation.dem horizonstep=30 bufferzone=200 horizon=horangle dist=0.7 maxdistance=2000
263
 
 
264
 
# slope + aspect
265
 
r.slope.aspect elevation=elevation.dem aspect=aspect.dem slope=slope.dem
266
 
 
267
 
# calculate global radiation for day 180 at 14:00hs
268
 
r.sun -s elevation.dem horizon=horangle horizonstep=30 aspin=aspect.dem \
269
 
          slopein=slope.dem glob_rad=global_rad day=180 time=14
270
 
</pre></div>
271
 
<p>
272
 
-->
273
 
 
274
 
Calculation of the integrated daily irradiation for a region in North-Carolina
275
 
for a given day of the year at 30m resolution. Here day 172 (i.e., 21 June
276
 
in non-leap years):
277
 
 
278
 
<div class="code"><pre>
279
 
g.region rast=elev_ned_30m -p
280
 
 
281
 
# considering cast shadows (-s)
282
 
r.sun -s elev_ned_30m lin=2.5 alb=0.2 day=172 \
283
 
      beam_rad=b172 diff_rad=d172 \
284
 
      refl_rad=r172 insol_time=it172
285
 
 
286
 
d.mon x0
287
 
# show irradiation raster map [Wh.m-2.day-1]
288
 
d.rast.leg b172
289
 
# show insolation time raster map [h]
290
 
d.rast.leg it172
291
 
</pre></div>
292
 
 
293
 
 
294
 
<h2>SEE ALSO</h2>
295
 
 
296
 
<em>
297
 
<a href="r.horizon.html">r.horizon</a>,
298
 
<a href="r.slope.aspect.html">r.slope.aspect</a>,
299
 
<a href="r.sunmask.html">r.sunmask</a>,
300
 
<a href="g.proj.html">g.proj</a>,
301
 
<a href="r.null.html">r.null</a>,
302
 
<a href="v.surf.rst.html">v.surf.rst</a>
303
 
</em>
304
 
 
305
 
<h2>REFERENCES</h2>
306
 
 
307
 
<ul>
308
 
<li> Hofierka, J., Suri, M. (2002): The solar radiation model for Open source
309
 
GIS: implementation and applications. International
310
 
GRASS users conference in Trento, Italy, September 2002.
311
 
(<a href="http://skagit.meas.ncsu.edu/~jaroslav/trento/Hofierka_Jaroslav.pdf">PDF</a>)
312
 
<li>
313
 
Hofierka, J. (1997). Direct solar radiation modelling within an open GIS
314
 
environment. Proceedings of JEC-GI'97 conference in Vienna, Austria, IOS
315
 
Press Amsterdam, 575-584. 
316
 
<li>
317
 
Jenco, M. (1992). Distribution of direct solar radiation on georelief and
318
 
its modelling by means of complex digital model of terrain (in Slovak). Geograficky
319
 
casopis, 44, 342-355. 
320
 
<li>
321
 
Kasten, F. (1996). The Linke turbidity factor based on improved values of
322
 
the integral Rayleigh optical thickness. Solar Energy, 56 (3), 239-244. 
323
 
<li>
324
 
Kasten, F., Young, A. T. (1989). Revised optical air mass tables and approximation
325
 
formula. Applied Optics, 28, 4735-4738. 
326
 
<li>
327
 
Kittler, R., Mikler, J. (1986): Basis of the utilization of solar radiation 
328
 
(in Slovak). VEDA, Bratislava, p. 150. 
329
 
<li>
330
 
Krcho, J. (1990). Morfometrick&aacute; analza a digit&aacute;lne modely georeli&eacute;fu
331
 
(Morphometric analysis and digital models of georelief, in Slovak).
332
 
VEDA, Bratislava.
333
 
<li>
334
 
Muneer, T. (1990). Solar radiation model for Europe. Building services engineering
335
 
research and technology, 11, 4, 153-163. 
336
 
<li>
337
 
Neteler, M., Mitasova, H. (2002): Open Source GIS: A GRASS GIS Approach, Kluwer
338
 
Academic Publishers. (Appendix explains formula;
339
 
<a href="http://www.grassbook.org/">r.sun script download</a>)
340
 
<li>
341
 
Page, J. ed. (1986). Prediction of solar radiation on inclined surfaces. Solar
342
 
energy R&amp;D in the European Community, series F &#8211; Solar radiation data,
343
 
Dordrecht (D. Reidel), 3, 71, 81-83. 
344
 
<li>
345
 
Page, J., Albuisson, M., Wald, L. (2001). The European solar radiation atlas:
346
 
a valuable digital tool. Solar Energy, 71, 81-83. 
347
 
<li>
348
 
Rigollier, Ch., Bauer, O., Wald, L. (2000). On the clear sky model of the
349
 
ESRA - European Solar radiation Atlas - with respect to the Heliosat method.
350
 
Solar energy, 68, 33-48. 
351
 
<li>
352
 
Scharmer, K., Greif, J., eds., (2000). The European solar radiation atlas,
353
 
Vol. 2: Database and exploitation software. Paris (Les Presses de l&#8217; &Eacute;cole
354
 
des Mines).
355
 
<li>
356
 
Joint Research Centre: <a href="http://re.jrc.ec.europa.eu/pvgis/">GIS solar radiation database for Europe</a> and 
357
 
<a href="http://re.jrc.ec.europa.eu/pvgis/solres/solmod3.htm">Solar radiation and GIS</a>
358
 
</ul>
359
 
 
360
 
<h2>AUTHORS</h2>
361
 
 
362
 
Jaroslav Hofierka, GeoModel, s.r.o. Bratislava, Slovakia <br>
363
 
                                                                        
364
 
Marcel Suri, GeoModel, s.r.o. Bratislava, Slovakia <br>
365
 
 
366
 
Thomas Huld, JRC, Italy <br>
367
 
 
368
 
&copy; 2007, Jaroslav Hofierka, Marcel Suri. This program is free software under the GNU General Public License (&gt;=v2)
369
 
<address>
370
 
<a href="MAILTO:hofierka@geomodel.sk">hofierka@geomodel.sk</a>
371
 
<a href="MAILTO:suri@geomodel.sk">suri@geomodel.sk</a>
372
 
</address>
373
 
 
374
 
<p><i>Last changed: $Date: 2013-06-16 05:08:46 +0200 (Sun, 16 Jun 2013) $</i>