> I assume I'll have to use one of the above formulas with r.mapcalc to > create the Linke layer from the SODA data & a local DEM for delta-z. But > that just makes me wonder if turbidity really belongs in a 3D voxel grid, > not a 2D coverage map? i.e. I can derive a value for Linke at the > ground-surface for each raster cell in the DEM easily enough using the > above formulas, but isn't the important Linke value(s) what the beam > encounters on it's path through the atmosphere high above the ground, > not just the value at ground level at the beam's terminus?
You have to think on the Linke turbidity as an integrated value from top of the atmosphere to the level you want the solar irradiance. That means you dont need to worry about 3D voxel grids at all. If you retrieve Linke values from Soda Service (www.soda-is.com) what I propose is to extract values for sea level, for example, and then applied the pressure-correction formula to shift vertically to your elevation grid. Note that the extracted values will represent the integrated atmospheric attenuation on the solar beam from top of the atmosphere to the sea level. You can find useful information about the derivation of the Linke database in the Soda Service in this link (http://www.helioclim.net/publications/ises2003_linke.pdf). Particularly, note that eq. (9) is the pressure-correction I proposed bellow. A somehow similar approach can be found in http://www.ing.unitn.it/~grass/conferences/GRASS2002/proceedings/proceedings/pdfs/Hofierka_Jaroslav.pdf or in the paper úri M., Hofierka J., 2004. A New GIS-based Solar Radiation Model and Its Application for Photovoltaic Assessments. Transactions in GIS, 8, 2, 175-190 > If it helps, I do have quite a bit of PAR light meter data we collected > at sea level throughout the region over full years; and do know the air > is nearly as clear as it gets. What instrumentation could I add to our > met stations to get a better record? Deploying light loggers on mountain > peaks for the summer months may be an option (granite is beautiful stuff > to climb :). I dont understand what you mean with better record. It depends what you want/need. If you really need a good characterization of the atmosphere you would need spectral measurements but the instrumentation is expensive and require very expertise knowledge. A good alternative is measuring beam irradiance with a pyrheliometer (mounted in a sun-tracker). Using eqs (6-7) in http://www.helioclim.net/publications/ises2003_linke.pdf you could calculated the equivalent Linke turbidity from these direct measurements. But even the pyrheliometers are somehow expensive and difficult to maintain. A less accurate approach, but easier to operate and maintain, could be the use of a shaded pyranometer to measure the diffuse irradiance and another unshaded to measure the global (broadband) one. Then, you could derive direct irradiance and calculate TL. I hope this helps, Jose > > Hamish: >>> I have worried about r.sun's Linke Turbidity factor values in areas >>> with >>> big changes in elevation. Is turbidity value heavily dependent on >>> altitude? > > Jose: >> Linke turbidity is certainly height-dependent given the higher optical >> path length at lower elevations. A simple approximated pressure >> correction >> might be applied if the turbidity at a given altitude z' is known: >> >> TL(z) = TL(z') exp( -(z-z') / 8435.2) > > Dylan: >> It should, as it is based on a measure of optical thickness (air mass): >> m = \frac{1}{sin(\alpha) + 0.15(\alpha + 3.885)^{-1.253}} e^{-0.0001184 >> \timesA} > > (yay LyX, ctrl-m, paste selection, view PostScript) > > buraq wrote: >> I took the turbidity values from soda-is.com. I entered no altitude >> value for the latitude and longitude. > > > I did the same, I attempted to match their model grid (approx 1x1-deg > IIRC) > for an array of lat/lon extractions over my study area, then v.surf.rst to > produce a Linke layer for r.sun. I can't recall off the top of my head if > we entered an altitude or not, I think not. > > I work in fjords with >1000m vertical drops (including one of the top > 10 tallest waterfalls in the world). With little idea of the elevation > values used for the SODA data, I just guess that it will be very rough > and subject to a somewhat arbitrary sampling error. > > I assume I'll have to use one of the above formulas with r.mapcalc to > create the Linke layer from the SODA data & a local DEM for delta-z. But > that just makes me wonder if turbidity really belongs in a 3D voxel grid, > not a 2D coverage map? i.e. I can derive a value for Linke at the > ground-surface for each raster cell in the DEM easily enough using the > above formulas, but isn't the important Linke value(s) what the beam > encounters on it's path through the atmosphere high above the ground, > not just the value at ground level at the beam's terminus? > > If it helps, I do have quite a bit of PAR light meter data we collected > at sea level throughout the region over full years; and do know the air > is nearly as clear as it gets. What instrumentation could I add to our > met stations to get a better record? Deploying light loggers on mountain > peaks for the summer months may be an option (granite is beautiful stuff > to climb :). > > > hope that makes sense, > Hamish > > > ps- If anyone is interested, at one point I wrote a little C program > that fit a sine curve to the monthly data and gave you a per-day value > from per-month data, avoiding big jumps at the month changes. The same > could in theory be adapted to work with r.mapcalc to get daily maps from > the monthly raster layers, at considerable computational cost. (but you > just need to run it once(ie x365) in a dedicated mapset) > > > > > > _______________________________________________ > grass-user mailing list > [email protected] > http://lists.osgeo.org/mailman/listinfo/grass-user > -- José A. Ruiz-Arias Solar Radiation and Atmosphere Modelling Group http://www.ujaen.es/investiga/tep220 Physics Department, University of Jaén Campus Lagunillas, Building A3 066 23071 Jaén Spain Tlf: +34 953 212 474 Fax: +34 953 212 838 _______________________________________________ grass-user mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-user
