Dear Colleagues, you receive this eMail because you are either a user of the radiative transfer package libRadtran or because we think that you might be interested in this information. Should you not be interested in receiving further information, please let us know. Should you know of anybody who might be interested in libRadtran and whose name is not on the distribution list, please let us also know as well. Attached to this eMail is the third libRadtran Newsletter. The main issue of this Newsletter is to announce the new version, *** libRadtran 1.0-beta-2 *** And now, we wish you all a happy and successful new year! Bernhard Mayer and Arve Kylling. ------------------------------------------------------------------ Dr. Bernhard Mayer Bernhard.Mayer_at_dlr.de Deutsches Zentrum fuer Luft- und Raumfahrt (DLR) Institut fuer Physik der Atmosphaere, Oberpfaffenhofen, D-82234 Wessling, Germany. Phone: +49 8153 282568, Fax: +49 8153 281841, Homepage: http://www.bmayer.de ------------------------------------------------------------------ /*---------------------------------------------------------------- * libRadtran Newsletter No. 3 * * December 31, 2003 * * Bernhard Mayer (bernhard.mayer_at_dlr.de) * Arve Kylling (arve.kylling_at_nilu.no) * * ### More info: http://www.libradtran.org ### *----------------------------------------------------------------*/ Welcome to the third libRadtran Newsletter! The main issue of this Newsletter is the announcement of *** libRadtran 1.0-beta-2 *** Dear libRadtran users, in an "old" tradition, a new version of libRadtran is released at the end of the year. Since the last major release (December 23, 2002) some new options have been added, but the main work has concentrated on making the existing ones consistent. As in the previous years, several bugs have been identified with your help, and we want to thank you for your constructive comments! Luckily, the identified errors again did not lead to wrong model results but only to segmentation faults (with about 200 input options not all combinations can be tested and there is always a chance that some may interfere infavorably). The introduction of the vertical redistribution feature in 1.0-beta (December 23, 2002) has been a major step, and we would again like to direct your attention to this feature which probably has been one of the major advancements of libRadtran to simplify our work. "Vertical redistribution" means that you may specify completely different grids in different input files (e.g. atmosphere_file, wc_file, aerosol_tau_file, ...) and uvspec automatically takes care of the vertical regridding. In earlier versions the z-grid of e.g. wc_file had to equal the z-grid defined in the atmosphere_file. The side effect was that, e.g. in order to define a cloud between 0.5 and 0.8km one had to manually insert these layers into the atmosphere_file and into all other vertical profiles. And, the corresponding wc_file had to contain all layers defined in atmosphere_file, even though only one was cloudy. Since 1.0-beta, a simple wc_file 0.8 0 0 0.5 0.1 10 will do the job, if one defines "wc_file ..." and "wc_layer" in the uvspec input. Please note that the first line is necessary (even though it does not contain a cloud) because otherwise the cloud would extend all the way to the top of the atmosphere. Following is a list of all important changes. For completeness, the CVS log is also attached (2003.cvslog) which contains a complete description of everything that happened to the code during 2003 (you probably are not really interested in this one, unless you work on the code). Finally, a comment on "serious errors" produced by the self check ("make check"): libRadtran is developed under Linux, on INTEL PCs. When it is tested on the same kind of machine, the deviation from the test runs is actually 0.000000%. We use these tests for quality control, to make sure that no bugs are introduced when new features are implemented. To find out how good your machine reproduces the results, try a "make verbosecheck". However, when the self check is run on a different system, differences become larger. This is already true for an INTEL-compatible AMD machine, or even for a new version of the compiler (e.g. gcc 3.3 instead of 2.95)! These differences are usually due to rounding errors and sometimes to numerical instabilities, mostly in the solvers. Hence, these differences become more pronounced when the model is run on a 64 bit machine instead of 32 bit. Sometimes you may encounter an extremely large difference of e.g. 994%. Such differences occur usually for very small results, e.g. the diffuse downward irradiance in a Rayleigh atmosphere in the infrared. Although we try to capture and avoid such things, they still occur. If you encounter such a "serious difference", you should have a closer look if it is really serious for your application. Most test examples may be run manually, e.g. the "correlated-k [Kato et al., 1999], twostr" test can be run from the examples directory, "../tools/uvspec < UVSPEC_KATO.INP", and the output should then be compared to UVSPEC_KATO.OUT. If you encounter a really serious bug (which is not noise of a small number etc) please let us know. And again, please let us know if you wrote any publications using libRadtran. We will add it to the References list on the libRadtran homepage. **************************************************************** Major changes between libRadtran 1.0-beta (23 December 2002) and libRadtran 1.0 beta-2 (31 December 2003): o Fixed several bugs which caused SEGMENTATION faults under certain combinations of input options o Made libRadtran compile under Macintosh OSX; this required several changes which (hopefully) made the code more POSIX compliant. o The independent pixel options were re-introduced; they had been disabled during the introduction of the vertical redistribution feature (introduced December 2002). The following options now work with redistribution: wc_cloudcover wc_ipa_files wc_ipa ic_ipa_files o Cox and Munk sea surface BRDF: Model is now forced to use at least 16 streams when ocean BRDF is used; the wind speed U10 is forced to be at least 1m/s - otherwise artifacts will result, caused by the Legendre expansion of the phase function. o "correlated_k KATO2" is a new version of the correlated_k tables provided by Seiji Kato which is much faster than the original KATO because much less grid points are used. KATO2.96 is the same thing but based on HITRAN96, rather than HITRAN2k. Added some more documentation of the various Kato options, KATO, KATO2, and KATO2.96; added a figure (doc/figure3.pdf) which shows a comparison of the uvspec Kato results with Figure 3 from Kato et al. [1999]; results are not really consistent but reasonable; implications are discussed in the documentation: do not use Kato to calculate single wavelength bands but rather use it to calculate integrated shortwave radiation o Changed SBDART version from 1.5 to 2.2. Citing from the SBDART documentation: * fixed treatment of 3-term LOWTRAN k-distribution parameters in the long-wave spectral region. Old version tried to rescale k-distribution transmission function to match LOWTRAN's double-exponential transmission function along the solar beam direction. However, the rationale for this modification was weak; the solar input is negligiable in the longwave spectral region, so the solar beam direction is not particularly significant. The new version uses the unmodified LOWTRAN k-distribution parameters and produces predictions of thermal IR that are independent of solar zenith angle. It should be noted that more accurate estimates of longwave radiative transfer are available using high spectral resolution k-distribution optical depths read from disk with the KDIST=-1 option. The change required translating the code from Fortran 90 to Fortran 77 which required many manual changes. Testing showed perfect agreement in the absorption coefficients between SBDART 2.2 and libRadtran/SBDART (better than 1% between 250 and 20000 nm for the transmission, down to values of 1e-6). Gases included are O2, O3, CO2, CH4, N2O, NH4, and NO2. Also included is O4 absorption. o Improved treatment of output grid: The documentation defines three wavelength grids used by uvspec: The input grid (various wavelength grids, on which the model input is defined, e.g. albedo_file); the internal grid, used for the radiative transfer calculation; and the output grid. IF YOU ARE NOT FAMILIAR WITH THOSE, PLEASE READ THE UVSPEC DOCUMENTATION. Until now, the output grid was explicitely defined by the "solar_file" which had some strange side-effects: E.g. one had to specifiy a "solar_file" even if only thermal wavelengths were considered. From now on, a solar_file is no longer required for the the following cases: - thermal calculations ("source thermal") - transmittance and reflectivity calculations ("transmittance", "reflectivity") In these cases, the output grid will equal the internal grid. In addition, line-by-line calculations have been simplified even more: here the transmittance_wl_file is no longer required when a molecular_tau_file has been defined. o Added option "wvn_index" which allows to define those wavelengths which are actually required (rather than fiddling around with the wvn's. Very useful in combination with the correlated_k options, in particular those where usually only some of the wavelengths are required like the AVHRR parameterization. o Added two new options to simplify the use of tabulated Mie optical properties for clouds: wc_properties_interpolate and ic_properties_interpolate; if defined together with "wc_properties " or "ic_properties " then the optical properties are read from filename.???.mie(.cdf) (as before) and automatically interpolated to the internal wavelength grid. This allows to define a standard set of optical properties which are then automatically interpolated to the required wavelengths. Such a set is available at http://www.libradtran.org. The wavelength grid was chosen so that the interpolated optical properties do not deviate more than 1% from a high-resolution calculation. Be careful using this new feature: - the option might consume a lot of memory, in particular if the internal wavelength grid has many wavelength grid points; consider that the moments of the scattering phase function (up to several 1000) are interpolated to the internal wavelength grid in full detail. For quick checks and one-time calculations these features are ok. For processing and production it is still recommended to prepare Mie files specifically for the required wavelength grid (to increase speed and to reduce memory consumption). - this is a more general comment: Ice clouds do not consist of spherical ice-balls but comprise a variety of particle shapes for which a Mie calculation does usually provide a very bad approximation. For real ice cloud studies, use one of "ic_properties yang56" or "ic_properties fu" or provide your own data with "ic_properties filename" or ic_files. o "output integrate" implemented, for automatical wavelength integration of the model output. (Please note that, in order to calculate e.g. integrated solar irradiance with one of the k-distributions, you have to "output sum", rather than "output integrate"). o simplified some examples: e.g. the calculation of satellite radiances with "correlated_k AVHRR_KRATZ" is greatly simplified; have a look at UVSPEC_AVHRR_SOLAR_CH1.INP etc. No postprocessing is required anymore to directly calculate satellite radiances and brightness temperatures with uvspec. Added filter_function_file's and thermal_band_file's to data/correlated_k/kratz so that AVHRR channels can now simply be calculated using "filter_function_file" and "output sum" in the input file. o Fixed a small but significant inconsistency in the documentation of tools/mie: the calculated extinction coefficient is actually not per unit liquid water content but per unit concentration (cm3 / m3). For water this equals the liquid water content because the density of water is 1 g/cm3. However, for ice, aerosols, etc where the density is different from 1 the difference can be significant. o solar zenith angle calculation (zenith, sza2time): replaced Spencer [1957] algorithm with a newer, more accurate algorithm by Blanco-Muriel et al., Solar Energy, 70(5), 431-441, 2001. The old algorithm is still available via a command line option. o Small addition to the documentation: explanation how to re-direct stderr and stdout, to separate diagnostic and error messages from usvpec output. Very useful for all users who learned to appreciate the "verbose" output (by the way, "verbose" is highly recommended whenever new input files are prepared; the libRadtran authors make heavy use of this feature because it helps to diagnose if the model does what the user wants it to do). o Added Thekaekara extraterrestrial spectrum from http://rredc.nrel.gov/solar/spectra/am0/special.html (data/solar_files/Thekaekara.dat); added new extraterrestrial spectrum by Gueymard, NewGuey2003.dat. Source: http://rredc.nrel.gov/solar/spectra/am0/special.html (see file headers for more information) o Added the TZS solver, implemented by Luca Bugliaro. TZS allows to calculate thermal TOA radiances analytically, for non-scattering atmospheres. Is generally a good approximation in the thermal region whenever scattering can be neglected. Advantage: very fast! o Modified the AERO_FILES test using the vertical redistribution features inreoduced in the last release and added support for empty layers, examples/NULL.LAYER. o Small bug fix: if surface_temperature was not set, the surface temperature was set to z=0 rather than z=altitude. Now the temperature at the surface is used. The latest version is available at http://www.libradtran.org, as usual. And now, have fun! Bernhard Mayer (bernhard.mayer_at_dlr.de) Arve Kylling (arve.kylling_at_nilu.no)