the Creative Commons Attribution 4.0 License.
the Creative Commons Attribution 4.0 License.
| 28 Sep 2023
PyRTlib: an educational Python-based library for non-scattering atmospheric microwave Radiative Transfer computations
Domenico Cimini
Donatello Gallucci
Saverio Teodosio Nilo
Filomena Romano
Abstract. This article introduces PyRTlib, a new standalone Python package for non-scattering line-by-line microwave Radiative Transfer simulations. PyRTlib is a flexible and user-friendly tool for computing down and up-welling brightness temperatures and related quantities (e.g., atmospheric absorption, optical depth, opacity, mean radiating temperature) written in Python, a language commonly used nowadays for scientific software development especially by students and early career scientists. PyRTlib allows simulating observations from ground-based, airborne, and satellite microwave sensors in clear sky and in cloudy conditions (under non-scattering Rayleigh approximation). The intention for PyRTlib is not to be a competitor for state-of-the-art atmospheric radiative transfer codes that excel for speed and/or versatility (e.g., ARTS, RTTOV). The intention is to provide an educational tool, completely written in Python, to readily simulate atmospheric microwave radiative transfer from a variety of input profiles, including predefined climatologies, global radiosonde archives, and model reanalysis. The paper presents quick examples for the built in modules to access popular open data archives. The paper also presents examples for computing simulated brightness temperature for different platforms (ground-based, airborne, and satellite), using various input profiles, showing how to easily modify other relevant parameters, such as observing angle (zenith, nadir, slant), surface emissivity, and gas absorption model. PyRTlib can be easily embedded in other Python codes needing atmospheric microwave radiative transfer (e.g., surface emissivity models and retrievals). Despite its simplicity, PyRTlib can be readily used to produce present-day scientific results, as demonstrated by two examples showing (i) absorption model comparison and validation with ground-based radiometric observations and (ii) uncertainty propagation of spectroscopic parameters through the radiative transfer calculations following a rigorous approach. To our knowledge, the uncertainty estimate is not provided by any other currently available microwave radiative transfer code, making PyRTlib unique for this aspect in the atmospheric microwave radiative transfer code scenario.
- Preprint
(2805 KB) - Metadata XML
- BibTeX
- EndNote
Salvatore Larosa et al.
Status: final response (author comments only)
-
RC1: 'Comment on gmd-2023-171', Anonymous Referee #1, 04 Oct 2023
The comment was uploaded in the form of a supplement: https://gmd.copernicus.org/preprints/gmd-2023-171/gmd-2023-171-RC1-supplement.pdf
-
AC1: 'Reply on RC1', Salvatore Larosa, 06 Oct 2023
The comment was uploaded in the form of a supplement: https://gmd.copernicus.org/preprints/gmd-2023-171/gmd-2023-171-AC1-supplement.pdf
-
AC1: 'Reply on RC1', Salvatore Larosa, 06 Oct 2023
-
RC2: 'Comment on gmd-2023-171', Anonymous Referee #2, 15 Oct 2023
This manuscript introduces a new microwave forward model implemented in Python, PyRTlib. The tool has a relatively narrow scope compared to some existing radiative transfer programs and is brought forward as an educational tool. On the other hand, it has some unique features that are of scientific interest.
As a start, I would suggest putting less emphasis on “educational” (is an educational tool even inside the scope of GMD?). If having education as the main aim, it should be shown that the tool has pedagogical advantages, i.e. how it facilitates learning compared to what can be achieved with other software. As far as I can see, educational is here more or less equal to the second aim of being user-friendly (page 7).
There are two possible target audiences: the students and younger scientists, the “newbies” expected to be the users of PyRTlib, or the teachers and advisers of those users (and there could even be old scientists that master Python and would use PyRTlib in their work!). The manuscript in its present form seems to have both audiences in mind but is not meeting the full expectations of any of them. It could be possible to handle both audiences in parallel, but it is probably best to target one of them. The most reasonable choice seems to prioritise teachers, advisers and scientific use. Targeting newbies would likely result in a too low scientific level for a journal article, and they will primarily look for information in the user guide. However, I fully understand that it is not possible, or even preferred, to have a strict separation between “science” and documentation. Here, a pragmatic approach must be allowed. To be useful, the journal article must contain aspects of documentation, but it should be on a relatively high level, such as the general principles of the software’s design.
The choice of units is an example of general principles. The only way to determine the chosen units is if the example codes clarify them. Please add a table or explain if they are found in the user guide. If the units are selected according to some guidelines (using the ones typically found in atmospheric models?), that would be helpful to know. Further, is there a strategy when importing data? Are the units kept from the original data source or converted to standard units? Taking the function IGRAUpperAir as an example, where do I find out what variables it returns and their unit? The example codes show that the user must employ unit conversions. This is error-prone, and I question whether this aligns with a user-friendly tool.
It would be helpful to explain the organisation of the documentation. Where do I look for different types of documentation? The existence of a user guide should be mentioned in the introduction and referred to in the text.
Another missing piece of information is how altitude and observation angle are specified. Please note that it needed to specify an altitude for satellite observations if Eq. 7 is applied. It is the radius of the instrument that sets the constant.
I suggest using some tables for better clarity. It is mentioned that “intermediate RT variables” can be accessed, but the exact set is unclear. This information would be suitable for a table, then including units of these variables. A table would also help get a quick overview of the absorption models. Here, I recommend including the reference matching the implementation to avoid confusion.
The results in Figure 7 give confidence in PyRTlib, at least for the two absorption models used. Has there been any comparison between PyRTlib and other forward models? Or internally, comparing the different absorption models? This provides no validation against reality but is the fastest way to detect possible bugs.
Section 5 outlines extensions. This brings up the issue of the software version. The manuscript must be linked to a specific version. This likely requires a plan to “versionify” the software and document changes between each version.
Exploring the modelling uncertainty is novel and highly useful and should be better covered by the manuscript. Some open questions here:
- Is there an uncertainty estimate for exactly all parameters affecting absorption cross-sections? If not, what parameters are covered?
- Is it possible to extract these uncertainties and their covariance?
- How are the parameter uncertainties mapped to Tb uncertainty? Just perturbations or a more advanced approach? Can the full covariance matrix of Tb uncertainty (the information required for OEM retrievals) be obtained?
I have not tried to install and run PyRTlib. Neither have I cared about minor language issues in detail.
Various comments:
- Why is radiative transfer written with capital R and T in the title? Even if alluding to PyRTlib, this causes more confusion than help.
- The review of forward models is nice but makes the Introduction long. Place in an appendix?
- Line 152: AMSUTRAN is only used for the microwave region, not all fast parameterisations.
- Line 156: Geer et al (2017) not the best reference here; better is gmd.copernicus.org/articles/14/7497/2021/gmd-14-7497-2021.html
- Line 194: Not all observation geometries are handled by a plane-parallel model; limb sounding can not be represented.
- Line 231: As Eq 2 is written, s is the distance from the observation point, not the propagation distance.
- Eq 4: Not correct to use = here. Consider this also for Eq 5.
- Line 268: The value 99% is irrelevant (with this thinking, nitrogen should be the dominating absorber).
- Line 291: It is not very clear what has actually been implemented.
- Lines 291-292: Why is this model optional? This implies that the other models are mandatory. Is this model just applied at freezing temperatures?
- Eq. 7: Does including refraction for a plane-parallel model make sense? Is it not more important to include the Earth’s curvature than refraction? Is including Eq. 7 actually an improvement when applied in a plane-parallel model?
- Eqs 8-12: Why this level of detail here? Sticks out compared to other parts. And refraction is of relatively minor concern for the model.
- Sec 3.1: Are there any issues with quality and missing data when reading from the Wyoming archive?
- Around here, it becomes clear that the radiative transfer part takes RH as input. Is this a good choice? For freezing temperatures, RH can also be defined with respect to ice. There is a lack of agreement between parameterisations of RH with respect to liquid for freezing temperatures. A user can think that if she/he imports data in RH all is fine, but there is an uncertainty in the mapping from RH to absolute humidity due to two points raised above.
- Example codes: One or two example codes are motivated to exemplify how the program is used in practice. The extra examples contribute relatively little (basic things such as the import of packages and plotting get repeated, taking unnecessary space). For the rest, refer to the user documentation.
- Line 556: “Nicely” is vague, and not really true (there are apparent deviations from the 1-1 line).
- Fig. 7: PyRTlib does not apply any bandpass. Can this not be relevant for this comparison?
The manuscript is relevant for GMD but requires revision before publication. The text needs better to introduce the actual forward model and its documentation. On the other hand, the background and overall motivation for developing PyRTlib could be shortened (not to extend the length of the manuscript). Some of my comments question design choices. Take these comments as input for discussion and reflection, and not as a demand for making changes to the code at this point.
Citation: https://doi.org/10.5194/gmd-2023-171-RC2 -
CC1: 'Comment on gmd-2023-171', Philipp Hochstaffl, 25 Oct 2023
Thank you for considering Py4CAtS in the list of popular RT codes.
Please note that the latest Py4CAtS version incorporates continuum-induced absorption and simple single scattering. It also models aerosol optical depth using simple power law (Angstrom coefficient) and Rayleigh extinction.
Furthermore, the current version incorporates advanced line profiles which take into account effects such as the speed-dependence of pressure broadening, collisional narrowing as well as line mixing in the description of the spectral absorption.
Please also consider to mention that Py4CAtS is available as a Python wheel file from its homepage which allows for an easy installation via the Python package installer pip.
References:
- https://doi.org/10.1016/j.jqsrt.2020.107385 (available at arxiv.org number 2010.09804)
- https://doi.org/10.1016/j.jqsrt.2016.08.009 (available at elib.dlr.de number 106199)
- see documentation in tarball file
Citation: https://doi.org/10.5194/gmd-2023-171-CC1 -
AC2: 'Reply on CC1', Salvatore Larosa, 14 Nov 2023
The comment was uploaded in the form of a supplement: https://gmd.copernicus.org/preprints/gmd-2023-171/gmd-2023-171-AC2-supplement.pdf
-
AC2: 'Reply on CC1', Salvatore Larosa, 14 Nov 2023
-
RC3: 'Comment on gmd-2023-171', Anonymous Referee #3, 27 Oct 2023
This paper documents a new, Python-based radiative transfer model. This is a welcome addition to the radiation modelling toolkit that is indispensable for weather/climate modelling and remote sensing applications. I would recommend the authors address the following issues, mostly minor, in revision.
A main comment is that as the model is advertised for education, the model package and the paper can be configured to present more diverse and illuminating examples. Currently it’s focused/limited to radiance (brightness temperature). Instead of (or in addition to) the input processing, which the paper has talked much about, it would be of more pedagogic value to have examples of computation and diagnosis of different quantities, such as Jacobians, optical depth, weighting function, etc. One heuristic case to showcase the ability of the model may be the logarithmic dependence of monochromatic radiance (Huang & Bani, https://doi.org/10.1002/2014JD022466), which would involve radiance simulation and differencing to verify the phenomenon (log dependence) and involve optical depth and weighting function to understand/explain the phenomenon.
Eq 2-5: better to formulate and explain the equations for a slant path, to disclose more fully the parameters that need to be set for the model to run. It would also be better to include necessary description for limb view cases, which the model is said to handle too.
Eq. 6: this concerns the treatment of path inhomogeneity, which is a very general problem in radiative modelling. Better to have some reference and discussion of the rationale of the weighting choice made, i.e., based on transmission, optical depth, or mass.
Line 277: parameterization of absorption is core to any radiation model, which is probably covered too briefly here. For education in particular, such essence as state (temperature, pressure, etc.) dependences of line strength and broadening should be reviewed for the concepts as well as for related computing modules.
Line 286: this is another place where I find the information is too brief. It would also be good to outline plans for cloud property parameterization and multiple scattering radiative transfer solver.
The paper can use some editing assistance for English, e.g., Line 56: “allow to” => allows consideration of …; “dishomogeneity” => inhomogeneity
Citation: https://doi.org/10.5194/gmd-2023-171-RC3 -
CC2: 'Comment on gmd-2023-171', Mario Mech, 19 Nov 2023
I thank the authors for including PAMTRA in the list of publically available models. However, I must comment on some points concerning the model's description.
PAMTRA includes a variety of gas absorption models where the default selection is the one of Rosenkranz (2015, https://doi.org/10.1109/TGRS.2014.2339015) with various corrections after Turner (2009, https://doi.org/10.1109/TGRS.2009.2022262) and not MPM as mentioned.
line 115: please correct PAMTRAM to PAMTRA
line 116-118: What is meant by "relative moments" in "regarding radar measurements instead, the active forward model yields Doppler spectra and relative moments, e.g. reflectivity, mean Doppler velocity, skewness, and kurtosis."?
line 121-122: Although PyRTlib focuses on non-scattering applications, we would appreciate it if the authors mention that PAMTRA implements the self-similar Rayleigh–Gans approximation (Hogan et al., 2018; https://doi.org/10.1002/qj.2968) for both active and passive applications, a unique feature to our knowledge.Citation: https://doi.org/10.5194/gmd-2023-171-CC2 -
AC3: 'Reply on CC2', Salvatore Larosa, 23 Nov 2023
The comment was uploaded in the form of a supplement: https://gmd.copernicus.org/preprints/gmd-2023-171/gmd-2023-171-AC3-supplement.pdf
-
AC3: 'Reply on CC2', Salvatore Larosa, 23 Nov 2023
Salvatore Larosa et al.
Model code and software
A python package for non-scattering line-by-line microwave Radiative Transfer simulations. Salvatore Larosa, Domenico Cimini, Donatello Gallucci, Saverio Teodosio Nilo, and Filomena Romano https://doi.org/10.5281/zenodo.8219145
Salvatore Larosa et al.
Viewed
| HTML | XML | Total | BibTeX | EndNote | |
|---|---|---|---|---|---|
| 490 | 70 | 13 | 573 | 3 | 2 |
- HTML: 490
- PDF: 70
- XML: 13
- Total: 573
- BibTeX: 3
- EndNote: 2
Viewed (geographical distribution)
| Country | # | Views | % |
|---|
| Total: | 0 |
| HTML: | 0 |
| PDF: | 0 |
| XML: | 0 |
- 1