The plans outlined below may be subject to change in light of newly identified user requirements.
Nominal release schedule:
RTTOV v13.1 – October 2021
RTTOV v13.2 – September 2022
RTTOV v14.0 – March 2024
RTTOV v14.1 – March 2025
RTTOV v14.2 – March 2026
RTTOV v15.0 – September 2027
Developments planned or under consideration for future RTTOV releases
- UV simulation capability (v13 minor release)
- Unify RTTOV and RTTOV-SCATT – including implementing the RTTOV-SCATT approach to levels/layers in RTTOV (v14)
- Fully polarised simulations (v14)
- New physical MW emissivity model to replace FASTEM (v14)
- Investigate further improvements to the gas optical depth parameterisation based on v13 predictors
- Investigate HDO as a variable gas species
- Investigate improvements to MFASIS including aerosol simulation capability
- Implement aerosol optical properties in terms of particle size (to enable retrieval of aerosol particle size)
- Implement alternative (more efficient) cloud overlap option(s) for visible/IR scattering simulations
- Investigate inclusion of 3D effects in MW, visible and IR scattering simulations
- Improved tools for generating scattering property files for use with RTTOV at all wavelengths
- Further development of the HTFRTC capabilities
On-going general developments
- Keep up to date with latest spectroscopy and LBL models
- Updates to the RTTOV GUI to support new capabilities
- Updates to the Python/C++ wrapper to support new capabilities
- Code optimisation to increase speed and reduce memory usage
We have had requests for the following capabilities/updates, but we currently do not plan to implement them for reasons of complexity and/or prioritisation of resources:
Making coefficient generation software available to users
This software is complex and would require considerable resources to support users in running it which we feel would be better spent developing RTTOV itself. We also prefer to be able to retain control over the official RTTOV coefficients that are available in order to maintain consistent quality among them. The NWP SAF is responsive to all user requests for new coefficients. This includes coefficients for theoretical instruments which may involve multiple variations of channel specifications: we are actively supporting a number of users in this regard currently.
Use of NetCDF rather than HDF5 for large coefficient files and emissivity/BRDF atlases
We want to minimise the number of external library dependencies of RTTOV and the core of RTTOV now has only one: the HDF5 library. HDF5 was chosen because RTTOV had a lot of pre-existing infrastructure based on HDF5 including an extensive set of HDF5 I/O subroutines for reading/writing many RTTOV data structures. The GUI, for example, makes extensive use of these. It would require a significant development effort to switch to an alternative format such as NetCDF. Furthermore the NetCDF4 library is based on HDF5 so the latter must be installed in any case if NetCDF4 is installed.
Simulation of ground-based sensors
Clear-sky simulations of ground-based MW sensors are possible using the RTTOV-gb package. The NWP SAF does not develop or maintain this package.
Simulation of airborne sensors
This was investigated and proved to be impractical with the current optical depth parameterisation used by RTTOV. This could be revisited in the future if an alternative optical depth parameterisation is implemented.
Implement RTTOV wrapper for language X
Currently the wrapper allows much RTTOV capability (direct and Jacobian model clear-sky and scattering simulations including use of land surface emissivity/BRDF atlases) to be called from C, C++ or Python code. The current wrapper capability will be maintained in future versions and will be extended to support new RTTOV capabilities. However the implementation of the wrapper for a given language requires a significant development effort with additional effort required for maintenance as RTTOV develops. Therefore we do not plan to support additional languages in the wrapper.
Support for the RTTOV TL/AD models in the Python/C++ wrapper
These would require considerable development effort to implement and maintain. If required the TL and AD can be computed from the Jacobian (K) model wrapper, though this is less efficient than computing them directly.