Verification of ESAS-Light demonstration version - Task 4

During the ESASLight study two completely new algorithms are developed: one is for the calculation of Raman scattering, the other is for the computation polarization using the Monte Carlo method. These new algorithms are carefully validated.

We have collected published results that can serve as benchmark for validation. Furthermore we have defined several test cases for solver intercomparisons as well as for physical consistency tests. We also compare the simulations of polarized radiances to measurements and take part in a model intercomparison study for models including polarization.

Details are given in the verification plan and the verification report.

Raman scattering

Testing and verification of the Raman option include checking of the individual terms in the Raman source of the Raman radiative transfer equation, WP5100 report, Eqs. 34-35 , and comparison of final results with published results.

Status: closed

Polarization

Comparison against benchmark results by Coulson, 1960

Seven test cases have been defined for the verification of the implementation of polarization in MYSTIC. The following figure shows the result of one case as an example:

Test case 6

In general there is a very good agreement between the results by Coulson et al. (1960) and MYSTIC. The small differences are due to Monte Carlo noise and could further be reduced by using more photons. The error bars correspond to two standard deviations (2σ). The noise is larger where the polarized radiance is very small (close to 0). In all test cases there is a systematic difference of about 1% between Coulson et al. (1960) and polradtran.

Status: closed

Test reciprocity principle for realistic 1D atmospheres with molecules, aerosols, and clouds

Realistic simulations in spherical atmospheres including molecules, aerosols, and clouds have been simultated. The computations have been performed in the solar principal plane for a solar zenith angle of 60° at 350 nm wavelength. All simulations were done in forward and backward tracing mode. This test shows that the reciprocity principle (von Helmholtz, 1867) is fullfilled in MYSTIC.

Status: closed

Intercomparison between libRadtran radiative transfer solvers

In order to test the consistency of the various solvers that are available in libRadtran, we performed polarized calculations using the Monte Carlo solver MYSTIC and the doubling-and-adding solver polradtran. The intensity results have also been compared with the well tested discrete-ordinate solver DISORT2.

Three aerosol types of the OPAC database have be used:

  • water soluble (consists of various kinds of sulfates, nitrates, and other, also organic, water-soluble substances
  • soot (absorbing black carbon)
  • sea salt accumulated mode

For each aerosol type the radiation field for two aerosol optical thicknesses has been calculated: 0.05 (very low aerosol content) and 0.4 (very high aerosol content).

aerosol tau=0.4 Result for the high aerosol content. For soot (small particles), MYSTIC and polradtran agree well for I and Q. I in DISORT is different because polarization can not be considered. For larger particles (water soluble and sea salt) with enhanced forward scattering polradtran intensities are not correct in the forward scattering region. Here MYSTIC and DISORT agree well. The agreement for Q between MYSTIC and polradtran is quite good, even for sea salt aerosol. The difference due to neglecting the forward scattering peak (by delta-scaling) is 5% at maximum.

Status: closed

Efficiency tests

To test the efficiency of the new code, MYSTIC has been run for different atmospheric conditions on a Intel Pentium processor with 2.8 GHz. The computational (CPU) times has been measured for scalar and vector calculations to see directly the difference. The computation time does not increase much for vector calculations compared to salar calculations. The increase depends on the atmospheric conditions, but it is generally below about 20%. This increase is due to additional matrix multiplications and setting up the phase matrix instead of the phase function. The same cases have also been computed using the solvers polradtran (vector and scalar) and DISORT (only scalar) on the same processor. For polradtran the computation time increase when considering polarization is immense, about a factor of 10 when 3 Stokes components are considered. Computation times for polradtran and MYSTIC are comparable. For small optical thicknesses (pure Rayleigh scattering) MYSTIC is faster than polradtran. For scalar calculations DISORT is clearly the most efficient solver.

Status: closed

Comparison to measurements

Ground-based polarized radiance measurements have been conducted by Blumthaler et al. (2008). The measurements are performed at three wavelengths in the ultra-violet region of the spectrum and cover the solar principal plane as well as the almucantar plane. The Stokes components I, Q, and U are measured from which the degree of polarization can be derived. The measurements are performed in clear-sky conditions at several locations (Greece, New Zealand, Tenerife). The aerosol conditions are totally different: In Greece the measurements were performed in the polluted city Thessaloniki with high aerosol optical thickness. In Tenerife the measurements were performed on the top of a mountain at 2367 m altitude where the aerosol optical thickness is very small. These measurements are very well suited to validate the implementation of the OPAC database in libRadtran as well as the implementation of polarization in MYSTIC.

Status: closed

Model intercomparison study

An intercomparison study between radiative transfer codes that consider polarization has been initiated by A. Kokhanovsky (University of Bremen). Three test cases have been defined: Rayleigh, aerosol, and cloud scattering. The respective phase matrices are provided. So far three models take part:

  • SCIAPOL (Rozanov and Kokhanovsky, 2006)
  • 3DMCPOL (Cornet and Labonnote, submitted 2009)
  • MYSTIC

All test cases are for a 1D layer without surface reflection, because SCIAPOL can not handle more complex cases.

Status: closed

3D test for simple step cloud

Cornet and Labonnote (submitted 2009) performed simulations for a simple step cloud in order to investigate 3D effects. Similar calculations have been performed with MYSTIC and the obtained results also look similar. Particularly interesting is the fact that the polarized radiance converges after a few numbers of multiple scattering events. This is because when a photon is scattered multiple times its polarization is arbitrary (the mean of all multiple scattered photons is zero).

Status: closed

Test suite

The previous sections deal with the verification of the new algorithms that are implemented during the ESASLight study. Since further extensions are expected, it is important to have a verification tool that is always used when new code is added to the package. libRadtran alreadly includes a script that runs examples (currently about 60) delivered with the package. The script compares the results with pre-calculated values and outputs the differences. Small differences are acceptable because of the numerical accuracy which results in slightly different results for different compilers or different processors. The testing of the examples is always done when new code is committed to libRadtran. The 60 examples can not cover all possible combinations of input options. Currently libRadtran has about 250 input options which can be more or less arbitrarily combined. This yields millions of combinations and it is impossible to test all of them. We plan to include in addition to the example tests three test suites. The first one (testsuite A) tests the setup of optical properties. This should run relatively fast, because it does not require any expensive radiative transfer calculations. All of the tests defined in testsuite A should be run regularly, ideally each time, when new code is commited to the libRadtran package. The second one (testsuite B) should check the radiative transfer simulations. This will be an extremely extensive testsuite which should run continuously. There might be thousands of test cases for each solver. The order of the tests will be random to assure that, e.g., not only one solver is tested on one day. The third one (testsuite C) should generate random input files and run these input files with the development version and the latest stable release of libRadtran. The test should assure that the development version is consistent with the last stable libRadtran version. In the course of the ESASLight study we will set up the first test suites. Setting up a “complete” test suite is a long term project and it will not be finished within ESASLight.

So far we have started to create a script that generates the input files for testsuite A. There will be a vast number of tests (>100000) since there is a vast number of possible combinations of options. Therefore the input files can not be generated manually but should be generated automatically.

Status: ongoing

 
task4.txt · Last modified: 2010/03/11 09:23 by claudia     Back to top