RTTOV v14 plans
RTTOV v14.0, due for release September 2024, will be a large update involving significant changes to the user interface compared to RTTOV v13. This page does not describe all planned updates, but gives an overview of some of the largest changes.
If you have any questions or comments about the plans for RTTOV v14 please let us know via the Help desk.
The RTTOV Future Plans page gives more general information on planned updates.
Features to be removed
A number of features are planned for removal:
- flexible surface (2m pressure input variable) – as described below
- solar single-scattering solver for clouds/aerosols
- MFASIS-LUT (look-up-table-based) solar solver for clouds
- HTFRTC
- The TESSEM2 and FASTEM-1 through FASTEM-4 microwave sea surface emissivity models
- The JONSWAP solar sea BRDF option (solar_sea_brdf_model=1)
- Several deprecated options will be removed and their default behaviour will remain: grid_box_avg_cloud, spacetop, reg_limit_extrap, dtau_test
Changes to input profiles
One major goal of v14 is to unify the RTTOV model with RTTOV-SCATT: in other words to enable scattering at all supported wavelengths through the main RTTOV interface. This will benefit users by no longer requiring the use of a separate RT model (RTTOV-SCATT) for microwave scattering simulations, and by improving spectral consistency in the simulations (which will be further developed in future releases).
One significant change required for this is a modification in how the atmospheric profile is provided to RTTOV. Figure 1 illustrates the existing profile representation in RTTOV and RTTOV-SCATT for v13 (and older versions), and that in RTTOV v14.
Figure 1: RTTOV v13 and earlier representation of the atmosphere in RTTOV (left) and RTTOV-SCATT (middle), and the new profile representation in RTTOV v14 (right). The VIS/IR cloud/aerosol inputs (cld, aer) in RTTOV v13 are on a different vertical grid to temperature (T), water vapour (q, and other gases), and to the hydrometeor inputs (hydro) for RTTOV-SCATT. In addition to the pressure (p), temperature, water vapour, and hydrometeor inputs, RTTOV-SCATT also requires pressure half-levels (ph) that interleave the pressure levels. The surface pressure (p2m) is arbitrary in RTTOV, while it must lie on the bottom half-level in RTTOV-SCATT. In RTTOV v14, users input pressure half-levels (p-half), and all other input variables are provided on pressure full-levels (p-full). The surface implicitly lies on the bottom half-level (i.e. there is no longer a “2m pressure” input variable).
NWP models typically provide vertical profiles of temperature, gases, and scattering particles on the same vertical grid whereas for VIS/IR scattering simulations RTTOV v13 imposes a vertical stagger between, for example, the temperature and cloud profiles. Likewise there is an inconsistency between the VIS/IR and the MW in the vertical grid used for scattering inputs
Historically, due to the gas absorption optical depth parameterisation operating on fixed “coefficient pressure levels”, RTTOV had to allow an arbitrary surface pressure input (p2m, “2m pressure”) decoupled from the input pressure levels. However, RTTOV has for many years supported input profiles on arbitrary pressure levels by implementing internal profile interpolation, and the flexible surface is not typically required for NWP model fields as the surface pressure lies at the bottom of the profile. RTTOV-SCATT has never supported this flexibility, and mandates that the surface lies on the bottom pressure half-level. From a development perspective, this flexible surface requires special treatment in the code for every solver that is implemented in RTTOV, which increases the complexity of development/maintenance and so also the likelihood of introducing errors into the code.
RTTOV v14 unifies the representation of the atmosphere, and improves consistency with NWP model/GCM fields for cloud/aerosol because these scattering inputs are now vertically aligned with the temperature and gas inputs. The user must provide the pressure half-levels: the top half-level may be at 0 hPa, and the bottom half-level implicitly lies at the surface. There is no explicit surface pressure input. All other input quantities are provided on pressure full-levels. The p-half levels correspond to ph in RTTOV-SCATT, and the p-full levels correspond to pressure levels p in RTTOV v13. All other quantities (temperature, water vapour, trace gases, scattering inputs) are input on the p-full levels. These changes imply that users will always input profiles on NWP model levels, never on RTTOV coefficient levels, and the internal RTTOV interpolator will always be used.
These changes to the atmospheric profile representation result in differences in simulated radiances. It will not be possible to replicate RTTOV v13 radiances in v14. Work is underway to evaluate the impact of these changes in operational NWP systems.
Unification of RTTOV and RTTOV-SCATT
In v14, RTTOV-SCATT will no longer exist as a separate model: the delta-Eddington and radar solvers and associated calculations related to cloud overlap and optical property interpolation will be implemented within the core RTTOV model. As noted above, enabling microwave scattering within RTTOV will improve spectral consistency in simulations. Initial improvements in v14.0 come from the unified representation of the atmosphere (described above), and from eliminating some smaller discrepancies in calculations that currently exist between RTTOV and RTTOV-SCATT. Where applicable, it will also allow the same solvers for thermal radiation to be applied across the IR and MW. It will enable input of explicit optical properties for MW scattering simulations. In future releases beyond v14.0, work is planned to offer improved consistency in hydrometeor and cloud optical properties, and to allow users more flexibility in generating optical properties for use with RTTOV for any supported sensor.
Changes to VIS/IR cloud simulations
As part of the unification with RTTOV-SCATT, the VIS/IR cloud optical properties will be made more flexible. They will operate in the same way that VIS/IR aerosols and the MW hydrometeor optical properties work in RTTOV v13 whereby the optical property (sccldcoef) files define a set of particle types, and all of these types can be included in any combination when running simulations. This is in contrast to the current model where you must select between two sets of cloud liquid water properties and between two or three sets of cloud ice properties. This will make it possible for us to create tools to allow users to generate their own VIS/IR cloud optical property files which has not been possible previously. It also allows additional hydrometeor types to be supported beyond liquid and ice cloud.
Changes to surface inputs/outputs
All emissivity/reflectance inputs/outputs and related variables will be gathered together into a new data structure. Input values for the diffuse reflectance (used by RTTOV for radiation emitted and/or scattered downwards by the atmosphere) may optionally be provided by the user, as for emissivity and BRDF.
Previously, RTTOV assumed the surface to be homogeneous: a single surface type with associated properties. RTTOV v14 will allow for heterogeneous surfaces by enabling users to specify multiple surface types per profile, each with associated near-surface, skin, and emissivity/reflectance properties. Each surface has an associated coverage fraction, and the properties are weighted by the fraction and summed before the radiative transfer equation is solved.
Improved user interface
Some aspects of the interface to RTTOV will be updated to improve clarity, consistency, and generality:
The rttov_options structure provides various options and flags to configure simulations at run-time. Options are grouped into sub-types such as opts%rt_all (general radiative transfer options), opts%rt_ir (VIS/IR-related RT options), and opts%rt_mw (MW-related RT options). These sub-groups will be revised in v14 to eliminate (as much as possible) spectral distinctions. In addition, several options will be renamed for clarity and for greater consistency.
Some data types, variables, and subroutines will be renamed to improve consistency and clarity, and unused variables will be removed.
The interfaces to various user-level subroutines will be modified to improve consistency in argument order.