RTTOV v11 resources

There is a bug which prevents the GUI running with matplotlib v1.5. This can be fixed by downloading this file and replacing the existing version in gui/rview/

The Python/C++ wrapper will seg fault when initialising the BRDF atlas for use with multiple instruments. There is no problem if initialising the atlas for a specific instrument.

A code fix is available: download this file to the src/wrapper/ directory and recompile RTTOV.

There is a problem with the aggregate particle shape parameterisation (profile%ish = 2) when used with any of the four parameterisations for ice particle effective diameter (profile%idg = 1-4) or when the effective diameter is input explicitly in profile%icede. This results in erroneous simulations in the range 10-12 microns. This does not affect the hexagonal particle shape (profile%ish = 1) or the new Baran ice particle scheme. More details are available in this forum post which illustrates the impact on simulated BTs.

Users are recommended to use the Baran ice particle scheme for cloudy IR simulations. RTTOV v11.2 introduced an updated parameterisation which is selected by setting profile%ish = 4. It is planned to retire the older ice parameterisations based on effective diameter in RTTOV v12.

There is a bug in the calculated surface emissivity AD and K output in simulations where the calcemis(:) input array contains both TRUE and FALSE values. In this case this emissivity AD and K will be incorrect for surface sensitive channels for which calcemis(:) was set to FALSE. There is no problem if every element of calcemis(:) is TRUE or every element is FALSE.

A code fix is available: download this tar file, extract in the src/main/ directory and recompile RTTOV.

There is a bug in the land surface BRDF atlas which causes all BRDF values to be artificially capped at 1/pi.

A code fix is available: download mod_brdf_atlas.F90, replace the copy in the src/brdf_atlas/ directory and recompile RTTOV.

There is a minor bug which can affect cases with profile interpolation when apply_reg_limits is TRUE and the surface lies above the bottom of the input profile: it is possible that the regression limits are not applied to the coefficient level(s) just below the surface. These levels can contribute to the interpolated optical depths, and this may impact the TOA radiance. Whether this bug has any effect on radiances depends on the relative positions of the coefficient and user levels with respect to the surface pressure. To have an effect the input profile must also fall outside the regression limits in the near-surface levels. For cases where this does have an impact on TOA radiances, the size of the impact depends on how far beyond the regression limits the input profile variables are. However, the impact on BT would typically not be more than a few hundredths of a Kelvin for surface-sensitive channels. The coefficient regression limits can be seen in these tables.

A code fix is available which also includes the bug fix dated 13/10/2014 below: download this gzipped tar file, extract in the src/main/ directory and recompile RTTOV.

In the case when interpolation modes 4 or 5 are used and the top level of the input profile is low enough in the atmosphere that significant absorption occurs above this level for a given channel, the simulated radiance for this channel may exhibit very large errors (larger than for the other interpolation modes - see below for more details). If the input pressure profile fully spans the weighting functions of the channels being simulated this bug has no significant impact. A code fix is available: download this gzipped tar file, extract in the src/main/ directory and recompile RTTOV.

Note that even when the top pressure level is sufficiently high the updated code can result in small differences in simulated radiances and in the TL/AD/K output for some channels. The magnitude of the differences depends on the amount of absorption occurring above the top of the input profile, but where the amount of absorption above the top level is very small, the magnitudes are negligible compared to other errors. For example, if the top level is close to but not exactly 0.005hPa (the top level used in the optical depth regression) the differences in forward model radiances are of the order of 0.001% or less.

Some further explanation: in general the pressure levels of the input atmospheric profile should cover the full range of the atmosphere to which the channels being simulated are sensitive. In other words, the top of the input profile should lie above the channel weighting functions and the bottom of the profile should be at or below the surface pressure. If the top of the input profile is too low (so that there is significant absorption above the top level) then when opts%interpolation%spacetop is TRUE (the default) RTTOV will mitigate the resulting error by setting the optical depth of the top level to zero. This effectively stretches the top layer of the input profile to encompass the whole atmosphere between the second level and the space boundary, and both emission and absorption are taken into account for this layer in the integration of the RT equation (albeit without accurate information about the temperature of this layer). For input profiles with a sufficiently high top level this action of "spacetop" has a negligible impact on the simulations. If the spacetop option is FALSE (not generally recommended) then only absorption is accounted for above the top of the input profile (no emission). Naturally it is strongly recommended to supply an adequate input profile which fully spans the weighting functions of all simulated channels rather than to rely on the mitigating action of spacetop.

There is a bug in the TL model due to an uninitialised array which may cause a run-time error in cases where opts%rt_ir%addclouds is TRUE and profiles(i)%cfrac(:) = 0. for any input profile i (i.e. running cloudy simulations with a clear profile). A code fix is available: download rttov_cldstr_tl.F90 to the src/main/ directory and recompile RTTOV.

If opts%interpolation%reg_limit_extrap is TRUE and opts%config%do_checkinput is TRUE and the top-most interpolated value in one of the temperature or trace gas profiles lies below the minimum regression limit, it is possible that the internal rttov_checkinput subroutine will spuriously report a fatal error due to the extrapolated values. To avoid the possibility of this occurring you can set opts%config%do_checkinput to FALSE. This turns off RTTOV's internal checking for unphysical profile values and values outside the regression limits (NB by doing this the extrapolated values outside the regression limits will be reset to the limits: it will not result in unphysical extrapolated profile values being used). If you want to guard against unphysical profile values you can check your input profiles before calling RTTOV using the rttov_user_profile_checkinput subroutine (see user guide Annex N) which provides an alternative to the internal profile checking.

In addition there is a bug which results in errors in the top level of the temperature, water vapour and ozone profile and PC score Jacobians when running the PC-RTTOV K model with opts%interpolation%reg_limit_extrap set to TRUE.

A code fix is available which also includes the bug fix dated 23/04/2015 above: download this gzipped tar file, extract in the src/main/ directory and recompile RTTOV.

There is a bug in the rttov_checkinput.F90 subroutine which means that RTTOV is not throwing fatal errors in the case where an element of an input temperature, water vapour or trace gas profiles exceeds the hard profile limits: the simulation instead proceeds with unphysical values and does not report the error. To fix the bug download this version of src/main/rttov_checkinput.F90 and recompile.

When calling rttov_read_coefs to read HDF5-formatted coefficients the code may fail because the HDF5 library has not been initialised. This can occur in user-created software which calls RTTOV. To fix this download these files: src/main/rttov_hdf_mod.F90 (place in src/hdf/) and src/main/rttov_read_coefs.F90 (place in src/coef_io/) and recompile RTTOV.

Fix rarely-occurring bug which can result in small errors in simulated radiances, reflectances and BTs (and also in TL/AD/K output) for solar-affected channels. Occurs under the following conditions:

• calling RTTOV via parallel interface with multiple threads
• passing multiple profiles into RTTOV in a single call
• solar radiation enabled in simulations
• profile dates contain a mixture of leap years and non-leap years.

Whether or not any errors occur depends on the order in which the threads are executed so the bug manifests intermittently. This is unlikely to affect users as it is rare for profiles pertaining to different years to be passed into RTTOV in a single call. To fix the bug download this version of src/main/rttov_calc_solar_spec_esd.F90 and recompile. This has no impact on the test reference data in the v11.1 package.

For NLTE simulations the bias correction was applied to the rad%clear and rad%total direct model radiances. For consistency it should also have been applied to the rad%cloudy radiance which represents the 100% overcast cloudy radiance for the simple cloud scheme. This omission means that when the simple cloud scheme is being used (i.e. profiles%cfraction > 0), rad%cloudy, rad_tl%cloudy, rad_tl%total and rad_tl%bt are in error, as are the values of profiles_ad/k%cfraction. The size of the errors increase as profiles%cfraction increases. Note that the NLTE bias correction is applied independently of the cloud scheme and is added to the TOA radiances after the effects of cloud have been calculated. This bug is not expected to cause problems for users since cloud effects are unlikely to be considered in the high-peaking NLTE-affected channels, but it can be fixed by downloading this tarball rttov_nlte_bias_correction.tar.gz, extracting it in src/main/, and recompiling. This does not affect the test reference data contained in the official release.

The TL radiances and surface emissivities and the AD/K 10m wind u and v components and wind fetch may be in error for PC calculations. This affects cases when either the wind u or v component is exactly zero in which case the AD/K component corresponding to the non-zero u/v component has the incorrect sign. To fix the bug download this tarball rttov_calcemis_ir.tar.gz, extract in src/main/, and recompile. This does not affect the test reference data contained in the official release.

The TL radiances and surface reflectance and the AD/K 10m wind u and v components and wind fetch may be in error for solar simulations. This affects cases when either the wind u or v component is exactly zero (in which case the AD/K component corresponding to the non-zero u/v component has the incorrect sign) and cases where the sun zenith angle is large, the satellite zenith angle is small, the relative azimuth is small and the wind speed is large (exact specifications of "small" and "large" are difficult because multiple factors interact). To fix the bug download this tarball rttov_refsun.tar.gz, extract in src/main/, and recompile. This does not affect the test reference data contained in the official release.

Solar simulations may be in error when the profile month is set to January. This bug affects the calculation of the Earth-sun distance which is used to modify the top-of-atmosphere solar irradiance according to the time of year. To fix the bug download this version of src/main/rttov_calc_solar_spec_esd.F90 and recompile. This fix is included in the optional update listed above.

For visible/near-IR channels (i.e. wavelengths less than 3 microns for which RTTOV ignores thermal emission) this bug has no impact on simulated reflectances (radiance%refl_clear, radiance%refl). VIS/NIR radiances for profiles where the date is set to January may be in error (larger or smaller) by at most a factor of 1.071 which is ratio of the squared maximum/minimum Earth-sun distances. For channels with both a thermal and solar contribution the simulated radiances, reflectances and BTs may all be in error. The size of the error in radiances will never exceed that for VIS/NIR channels and will decrease as wavelength increases and thermal emission dominates the solar contribution. By default RTTOV initialises the profile date to 1/1/1950: for this and any earlier date (and for an invalid date) the Earth-sun distance is taken as 1 AU and the bug has no impact. This has no impact on the test reference data in the v11.1 package.

Division by zero is possible with solar simulations when 10m u wind speed is exactly zero and 10m v wind speed is negative. This fix is included in the optional update listed above and also in the bug fix listed above dated 15/11/2013.

Array bounds errors can occur under certain conditions when reading PC coefficients. To fix the bug download these versions of src/coef_io/rttov_read_ascii_pccoef.F90 and src/coef_io/rttov_read_binary_pccoef.F90 and recompile. This fix is included in the optional update listed above.

Running an NLTE simulation for IASI channel 7021, AIRS channel 2122 and CrIS channel 1245 (i.e. the channels immediately following the block of NLTE-affected channels for each instrument) causes an array bounds error. To fix the bug download this version of src/coef_io/rttov_init_coef.F90 and recompile. This fix is included in the optional update listed above.

The Windsat coefficient file sensor ID was incorrectly set to "mw" instead of "po" resulting in erroneous values for simulated radiances. The MW coefficient file tarball available on the RTTOV v11 coefficients page contains the corrected file. The new file results in different output for the test_fwd.sh and test_rttov11.sh scripts: updated test reference data is available here which should be unzipped/untarred within the rttov_test/ directory.

This bug results in spurious radiances and BTs in Windsat channels 5, 6, 10, 11, 15 and 16 (i.e. those with polarisation ID 5 and 6 as defined in the coefficient file which correspond to the 3rd and 4th Stokes parameters).

In user guide Annex A the optional logical switch arguments to rttov_conv_coef.exe for HDF5 coefficient conversion (i.e. --hdf5-reals32, --all-in-one and --compress) should be supplied on their own, rather than with the additional " = flag" as stated in the user guide. Also note that there should be no "=" between the option and the input argument. For example:

$ ./rttov_conv_coef.exe --coef-in rtcoef_noaa_18_avhrr.dat --format-out HDF5 --hdf5-reals32 --coef-out rtcoef_noaa_18_avhrr.h5