VLIDORT User's Guide

In earlier versions of LIDORT and VLIDORT, the converged diffuse field was established first,with the TMS exact scatter term applied afterwards as a correction. Following discussions withMick Christi, it is apparent that an improvement in Fourier convergence can be obtained byapplying TMS first and including I SSexact right from the start in the convergence testing. Therationale here is that the overall field has a larger magnitude with the inclusion of the I SSexactoffset, so that the addition of increasingly smaller Fourier terms will be less of an influence onthe total. This feature has now been installed in VLIDORT (Versions 2.1 and higher).It turns out that a similar consideration applies to the direct beam intensity field (the direct solarbeam reflected off the surface, with no atmospheric scattering). For a non-Lambertian surfacewith known BRDF functions, VLIDORT will calculated the Fourier contributions from theBRDF terms, and (for the upwelling field) deliver the Fourier components of the post-processeddirect-beam reflection as well as the diffuse and single scatter contributions. The completeFourier-summed direct beam contribution is necessarily truncated because of the discreteordinate process. It is possible to compute an exact BRDF contribution (no Fourier component)for the direct beam, using the original viewing angles, and this I DBexact term will then replacethe truncated contribution I DBtrunc .This feature has now been installed in Versions 2.1 and higher in VLIDORT and functions in thesame way as the TMS correction. The truncated form I DBtrunc is simply not calculated and theexact form I DBexact is computed right from the start as an initial correction, and included in theconvergence testing along with the TMS contribution. For sharply peaked strong BRDF surfacecontributions, this “DB correction” can be significant, and may give rise to a substantial savingin Fourier computations, particularly for situations where the atmospheric scattering may bequite well approximated by a low number of discrete ordinates.3.3.7 Enhanced efficiency for observational geometry outputIn 'operational' environments such as satellite atmospheric or surface retrieval algorithms, thereis a common requirement for radiative transfer output at specific “solar zenith angle, viewingangle, relative azimuth angle” observational geometry triplets. Although VLIDORT has longhad the capability for multi-geometry output, this facility (in previous versions) was not efficientfor generating output at geometry triplets. For example, if there are 4 triplets, then previouslyVLIDORT was configured to generate 4x4x4=64 output radiation fields, that is, one RT outputfor each of the 4 solar zenith angles, each of the 4 viewing angles, and each of the 4 relativeazimuth angles. One may view this as computing a “4x4x4 lattice cube of solutions”, and this isfine for building a look-up table (LUT). However, out of these 64 values, we require thesolutions along the diagonal of the above “lattice cube of solutions” (i.e. 4 instead of 64, one foreach triplet) for observational output; the other 60 solutions are not needed.To enhance computational performance, VLIDORT has been given an observational geometryfacility. This is configured with a Boolean flag, a specific number of geometry triplets and thetriplet angles themselves, and in this situation, a single call to VLIDORT will generate thediscrete-ordinate radiation fields for each solar zenith angle for a given triplet, and then carry outpost-processing only for those viewing zenith and relative azimuth angles uniquely associatedwith the triplet solar zenith angles. One of the big time savings here is with the internal geometryroutines in VLIDORT - in our example, we require 4 calls instead of 64.Tables 3.3-3.5 indicate the improved efficiency gained by using this observational geometryfeature (“ObsGeo”) for a set of geometries, in lieu of doing a “Lattice” computation for the sameset of geometries. The efficiency in each entry is given as the ratio (ObsGeo time / Lattice50