The plans outlined below may be subject to change in particular in light of newly identified user requirements
RTTOV v13 (due for release Q3 2020)
- Investigate improvements to the gaseous optical depth parameterisation
- Improved treatment of Rayleigh scattering in visible simulations
- UV simulation capability
- 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
- Capability to simulate active MW sensors in RTTOV-SCATT
- Improvements to the RTTOV-SCATT optical property file generation code
- New physical MW emissivity model to replace FASTEM
- Further development of the HTFRTC capabilities
On-going general developments
- Keep up to date with latest visible, IR and MW 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 (for scalar architectures) 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 RTTOV v12 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.
Fully polarised simulations for RTTOV or RTTOV-SCATT
This would require very significant development effort and we feel it is currently better to focus resources on other capabilities. This may be reconsidered in the future depending on user requirements.
Simulation of ground-based sensors
Clear-sky simulations of ground-based MW sensors are possible using the RTTOV-gb package. The NWP SAF do 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.