the Creative Commons Attribution 4.0 License.
the Creative Commons Attribution 4.0 License.
| 06 Nov 2023
An improved and extended parameterization of the CO2 15 µm cooling in the middle/upper atmosphere
Abstract. The radiative infrared cooling of CO2 in the middle atmosphere, where it emits under non-Local Thermodynamic Equilibrium (non-LTE) conditions, is a crucial contribution to the energy balance of this region and hence to establishing its thermal structure. The non-LTE computation is too CPU time-consuming to be fully incorporated in climate models and hence it is parameterized. The most used parameterization of the CO2 15 μm cooling for the Earth's middle and upper atmosphere was developed by Fomichev et al. (1998). The valid range of this parameterization with respect to CO2 volume mixing ratios (VMR) is, however, exceeded by the CO2 of several scenarios considered in the Coupled Climate Model Intercomparison Projects; in particular, the abrupt-4xCO2 experiment. Therefore, an extension, as well as an update, of that parameterization is both needed and timely. In this work, we present an update of the parameterization developed by Fomichev et al. (1998), which now covers CO2 volume mixing ratios in the lower atmosphere from ~0.5 to over 10 times the CO2 pre-industrial value of 284 ppmv (i.e., 150 ppmv to 3000 ppmv). Furthermore, it is improved by using a more contemporary CO2 line list and collisional rates that affect the CO2 cooling rates. Overall, accuracy is improved when tested against reference line-by-line calculations and by using measured global temperature profiles of the middle atmosphere. On average the errors are below 0.5 K day-1 for the present-day and lower CO2 VMRs. The errors increase to ~1–2 K day-1 at altitudes between 100–120 km for CO2 concentrations of two to three times the preindustrial values. For very high CO2 concentrations (four to ten times the pre-industrial abundances) the errors are below ~1 K day-1 for most regions and conditions, except at 110–120 km where the parameterization overestimates them by ~1.5 %. When applied to a large dataset of global (pole-to-pole and four seasons) measured temperature profiles, the errors of the parameterization are generally below 0.5 K day-1, except between 5⋅10-3 hPa and 3⋅10-4 hPa (~85–95 km), where they can reach biases of 1–2 K day-1. However, for elevated stratopause events, it underestimates the cooling rates by 3–7 K day-1 (~10 %) at altitudes of 80–100 km and the parameterized cooling rates show a large spread when compared to reference calculations.
- Preprint
(5331 KB) - Metadata XML
- BibTeX
- EndNote
Status: closed
-
RC1: 'Evaluation of an updated CO2 radiative cooling parameterization: unraveling challenges, addressing accuracy issues, and assessing applicability to GCMs', Anonymous Referee #1, 03 Dec 2023
The reviewed manuscript discusses an update to a well-known parameterization of the CO2 radiative cooling applicable to the middle and upper atmosphere of Earth. Infrared emission in 15-micron CO2 band is the dominant cooling mechanism in the Earth’s mesosphere and lower thermosphere and these layers affect the lower ones through so-called «downward control», so their including to General Circulation Models (GCM) becomes more and more common.
A pivotal challenge in calculating the cooling rate profiles is linked to the fact that the vibrational level populations of second vibrational mode levels of CO2 molecule are not in local thermodynamic equilibrium with the surrounding atmospheric volume (non-LTE). In other words, one cannot take a local temperature and estimate the vibrational level population needed to calculate the cooling rates. Instead, one has to find these populations in the course of the calculations, which involve two-way radiative transfer in the atmosphere and collisional population and depopulation of the said vibrational levels. These calculations are computationally expensive, and different groups working in the field of non-LTE seek the ways to accelerate them without losing the quality.
From the perspective of a GCM modeler, a streamlined routine for promptly and accurately calculating radiative cooling profiles is always welcomed, with any enhancements in accuracy being commendable.
All this said and acknowledging the usefulness of these routines, I see a number of issues with the present manuscript, which must be resolved prior to its publishing in the journal. I explain it in more details in General comments below. The minor comments and technical corrections section should be also addressed in the next version of the manuscript.
General comments:
- In my opinion, the manuscript tries to cover too many topics despite the fact that the title states that this is an update to existing parameterization. Well, it doesn’t hurt to recall the main milestones of the previous work, but the manuscript in its current form is “unfocused”. If it is intended to be a text-book chapter on non-LTE in the CO2 bands, then the same information could be found in the first authors’ book (Lopez-Puertas and Taylor, 2001). If it is supposed to be a technical paper then it should put more stress on technical aspects like the accuracy, interfacing, and so on. In addition, the text is overloaded with figures. I counted more than a hundred (!) of individual panels in the main part that consists of 41 pages. This is definitely an overkill and one can tell the same story in a much more concise way. I suggest the authors to shorten the manuscript and to keep only the essential parts. For example, all the inputs can be gathered on one two-panel plot, where the left-hand side would be occupied by the reference temperatures and the right-hand side would show the profiles of CO2 (only one is needed) and atomic oxygen, which is crucial for the estimate of the cooling rate. The first figure is not informative at all and can be easily omitted. The large number of panels in figures like Fig. 5 does not add much to the understanding of the principle of the radiative cooling or its calculation, and so on. Overall, I would reduce the number of non-essential figures to a minimum and put more efforts to a description of the routine itself, its implementation to a GCM and its limitations.
- Regarding the routine, I did not see any reference or repository for it provided along with the manuscript. As far as I understand, this is now a requirement for EGUsphere journals, so I wonder when and how did the authors plan to publish the routine. Besides a general conformity with the journal’s rules, it would be advisable to get a self-consistent compilable code with the cooling rate parameterization routine called from the main code with some standard atmospheric profile, which could be replaced with a test profile by the user. In the next paragraph, I explain the current problem I see with the accuracy of the updated parameterization, and I guess the GCM-modelers would have liked to test it themselves prior to implementing it to the model. Summarizing this point, the authors must provide a ready-to-use code and provide an instruction for its compiling and running both as a standalone routine and as a part of the test code, that might be useful not only for GCM-modelers, but for other researchers wanting to get a quick estimate of non-LTE cooling profile for a given atmosphere.
- The authors show that the routine works fairly well for the multitude of atmospheric profiles they use in the tests. This is quite impressive given a large variability of CO2 concentrations used in the study. Still, I cannot consider these tests to be fully representative because the real atmospheric temperature profiles are far from those shown in Fig. 2 of the manuscript in terms of vertical variability. Moreover, they are even worse than the ones shown in Fig. 20 because the averaging kernels of MIPAS instrument in the middle atmosphere are broad (e.g. Dinelli et al., 2021) and, therefore, this instrument cannot capture any wave shorter than 5-7 km. In addition, MIPAS is a limb measuring instrument, so it washes out horizontal inhomogeneities and this further reduces its vertical resolution. At the same time, the gravity waves (GWs) are known to be composed of several waves of different wavelengths and their amplitude increases with height up to the top of the “wave-turbopause” layer at 90-110km (e.g. Offerman et al., 2007; Ge et al., 2022), which overlaps with the non-LTE-affected area. I believe, the MIPAS profiles used in the study do not represent a full picture of a gravity-wave perturbed temperature profiles, so the tests performed with them show only a partial truth. Moreover, large RMS values presented in Fig. 24 even for these, partially smoothed, profiles make me think that the real accuracy of the parameterization is far from 1−2 K/day as it is stated in the abstract (I do not consider the specific case of elevated stratopause, which is addressed; I’m talking about the accuracy of “regular” profiles). If the tests I suggest below do not disprove my suspicions, this wouldn’t cancel the suggested parameterization. But, the GCM modelers will have a clear picture of what they will use and act accordingly if their models produce lifelike GW-perturbed temperature profiles.
- Here is the test I believe is necessary to conduct in order to properly estimate the accuracy of the suggested parameterization. Instead of using the MIPAS profiles and showing the averaged effects, I ask the authors to use the individual temperature profile coming from a ground-based lidar (e.g. Spitsbergen (78°N, 15°E), ALOMAR at Andøya (69°N, 16°E), Kühlungsborn (54°N, 12°E), Boulder (40°N, 105°W), Fort Collins (41°N, 105°W), Logan (42°N, 112°W), Arecibo (18°N, 293°E), Cerro Pachon (30°S, 71°W), or McMurdo (78°S, 167°E).) Since these lidars do not cover the whole atmospheric profile, in the lower atmosphere one can take a corresponding smooth profile from the reanalysis or from any other model. Among the profiles provided by the lidar teams, one has to pick up the ones, which clearly show the GW-signature (at least, the wave of +/- 10 K amplitude at 100km), and perform the exact and parameterized calculations of radiative cooling rate for these profiles. It would be also interesting to see how different wavelengths affect the accuracy, because the non-LTE effects are different in the case of a short-and large-scale perturbations. I have to stress here that due to a nonlinear nature of temperature perturbation effects on non-LTE cooling rates, these results cannot be replaced with the ones obtained for averages.
Minor comments and technical corrections
Lines 4 and 41: this statement is too general. In fact, there are ways of including the non-LTE calculations to GCMs. For example, this was done for Martian GCM (Hartogh et al., 2005) and I don’t see why this can’t be done for Earth. The corresponding manuscript is still in discussion in the same journal, so it can’t be referenced, but the authors claim that the same approach works for the Earth’s atmosphere.
Line 11: since the atomic oxygen is a variable component and the reaction 1c is directly linked to it, it would be good to have it as a variable parameter, see the second general comment
Line 17: the measured profiles themselves is not a ground truth because of the vertical resolution, see the third general comment. Moreover, one cannot average the results for individual runs and present this difference as an error, because the GCMs accumulate the error due to non-linearity of the processes.
Line 58: Figure 1 is not informative, see the first general comment
Lines 120-150: I guess, the readers will be confused here. It looks like GRANADA non-LTE code cannot work in LTE mode whereas normally it requires one line or one flag to calculate LTE populations. Could you, please, explain?
Line 125: I didn’t find any mention of line mixing effects here. Are they not important?
Line 135: I didn’t get the phrase about the “oscillations in RFM results”. Could you, please, clarify?
Line 145: And what about the results without this additional iteration?
Line 171: I recall that the difference is about 2-3K, and I wouldn’t call this a small change, so one should not neglect the daytime vs nighttime differences. This is addressed in Sect. 8, so the wording has to be changed here
Lines 200-215: all these descriptions are correct, but I doubt that they add something to the understanding of the routine or its accuracy, see the first general comment on the scope and focus of the manuscript.
Lines 220-225 (see also the comment to lines 437-462): if we assume that the k(CO2-O) used in the models is equal to 3 x 1e-12 cm3 s-1, then this experiment shows the effects of quadrupling the atomic oxygen mixing ratio. In addition, the reader might be misled by switching from atomic oxygen to k(CO2-O) and back. It would be enough to present this numerical experiment as the one performed for doubled (or quadrupled) atomic oxygen.
Lines 248-395: in fact, this deserves a general comment, but I cannot suggest to modify the general approach, it is what it is, and it works for smooth profiles for a current atmosphere. But what if the atmosphere changes some day and the LTE/NLTE1,2,3,4 regions become different? Let’s imagine that a modeler wants to calculate cooling rates for an Earth-like atmosphere, but with a different vertical temperature structure. How can he/she tell the limits of applicability of this parameterization?
Line 304: this is just one of the examples of the problem outlined in the previous comment. The error introduced by this “implicit assumption” depends on the atmospheric profile and is hidden deep in this module. It is small for the current atmospheres, but it is not guaranteed that it will remain small for some unusual temperature profile.
Lines 437-462: this is another potential candidate for a general comment. The problem is that there are three values of this rate coefficient, k(CO2-O): the first one is measured in the lab and is about 1.5−2.0 x 1e-12 cm3 s-1 (e.g. Castle et al., 2012), the second one is about 6.0-9.0 x 1e-12 cm3 s-1 retrieved from space-borne observations of 15-micron CO2 emissions, and the third one, 3.0 x 1e-12 cm3 s-1 was suggested for using in the GCMs. This paradox has not been resolved over the decades of its study, but it shouldn’t matter for the parameterization itself, because it is supposed to calculate cooling rate with any given k(CO2-O).
Line 455: how do you explain that the errors obtained for a smaller k(CO2-O) are larger? Usually, the larger the quenching rate, the larger the cooling rate, and the magnitude of this error is linked to cooling, as in the case of enhanced CO2.
Line 462: Fig. 20 is barely readable. Please, provide only a couple of profiles coming from a different source (see general comment 4) and show the errors for the corresponding cooling rate profile on the right-hand side panel.
References used in the text
- Castle, K. J., L. A. Black, M. W. Simione, and J. A. Dodd, Vibrational relaxation of CO2(n2) by O(3P) in the142–490 K temperature range, J. Geophys. Res.,117, A04310, doi:10.1029/2012JA017519, 2012
- Ge, W.; Sheng, Z.; Huang,Y.; He, Y.; Liao, Q.; Chang, S. Different Influences on “Wave Turbopause” Exerted by 6.5 DWs and Gravity Waves. Remote Sens. 2023, 15,800. https://doi.org/10.3390/rs15030800, 2022.
- Hartogh, P., A.S. Medvedev, T. Kuroda, R. Saito, and G. Villanueva; A.G. Feofilov and A.A. Kutepov, U. Berger, "Description and climatology of a new general circulation model of the Martian atmosphere", J. Geophys. Res., 110, (E11), doi: 10.1029/2005 JE002498, 2005.
- López-Puertas, M. and Taylor, F.W., “Non-LTE Radiative Transfer in the Atmosphere”. World Scientific Publishing Co, River Edge, NJ, 504pp, 2001.
- Offermann, D.; Jarisch, M.; Schmidt, H.; Oberheide, J.; Grossmann, K.U.; Gusev, O.; Iii, J.M.R.; Mlynczak, M.G. The “Wave Turbopause”. J. Atmos. Sol. Terr. Phys., 69, 2139–2158, 2007.
Citation: https://doi.org/10.5194/egusphere-2023-2424-RC1 -
AC3: 'Reply on RC1', Manuel López-Puertas, 03 Feb 2024
The comment was uploaded in the form of a supplement: https://egusphere.copernicus.org/preprints/2023/egusphere-2023-2424/egusphere-2023-2424-AC3-supplement.pdf
-
CC1: 'Comment on egusphere-2023-2424', Alexander Kutepov, 03 Dec 2023
The comment was uploaded in the form of a supplement: https://egusphere.copernicus.org/preprints/2023/egusphere-2023-2424/egusphere-2023-2424-CC1-supplement.pdf
-
AC5: 'Reply on CC1', Manuel López-Puertas, 03 Feb 2024
The comment was uploaded in the form of a supplement: https://egusphere.copernicus.org/preprints/2023/egusphere-2023-2424/egusphere-2023-2424-AC5-supplement.pdf
-
AC5: 'Reply on CC1', Manuel López-Puertas, 03 Feb 2024
-
EC1: 'Request from the handling editor', Tatiana Egorova, 07 Dec 2023
Dear authors,
please make sure that your code and data are available on-line because you have submitted the manuscript as a development and technical paper. Also, please note because this is an update of the existing parameterization, the name and the version number must be included in the title of the paper.
Editor
Tatiana Egorova
Citation: https://doi.org/10.5194/egusphere-2023-2424-EC1 -
AC1: 'Reply on EC1', Manuel López-Puertas, 25 Jan 2024
Dear Editor,
Thank you for your comment and sorry for taking that long to reply.
The preliminary version of the parameterization (written in python) is available from: https://zenodo.org/records/10547027, with DOI: 10.5281/zenodo.10547027. The final version will be made available in Fortran 90 and expected to be much faster.
Although it is based in a previous software distributed in the community, this is not "formally" an update of a previous parameterization. Actually, although based on the same concept, it has been built from scratch. Its name and version is "CO2 cool-v1", and it is licensed under GPL3.
Best regards,
Manuel Lopez PuertasCitation: https://doi.org/10.5194/egusphere-2023-2424-AC1 -
AC6: 'Reply on EC1', Manuel López-Puertas, 03 Feb 2024
Dear Editor,
We have now sent replies to the two referees and to the community user comments of A. Kutepov.
Just a remark with respect to our previous reply is that the most recent version of the parameterization can be found in:
https://zenodo.org/doi/10.5281/zenodo.10547026. It is still in Python. The final version in Fortran will be made available together (if the case) with the revised version of the manuscript. Its performance in terms of accuracy will be the same, just that will be faster.
Best regards, Manuel
Citation: https://doi.org/10.5194/egusphere-2023-2424-AC6
-
AC1: 'Reply on EC1', Manuel López-Puertas, 25 Jan 2024
-
CEC1: 'Comment on egusphere-2023-2424', Juan Antonio Añel, 20 Dec 2023
Unfortunately, after checking your manuscript, it has come to our attention that it does not comply with our "Code and Data Policy".
https://www.geoscientific-model-development.net/policies/code_and_data_policy.htmlYou do not provide a public repository for the code you use and develop for your manuscript. This is mandatory for manuscripts submitted to Geosci. Model Dev., and it must be available at submission time, open and available to the community. Therefore, this must be fixed, or we will have to reject your manuscript for publication.
In this way, you have to reply to this comment as soon as possible with the link and DOI of a repository containing the above mentioned code relevant for your work. The repository must be one listed in our policy as acceptable.
Also, in any potential reviewed version of your manuscript you must include the new 'Code and Data Availability' section, with the DOI of the code. Also, note that if you have to include a license for the code, otherwise it continues to be your property and it can not be used by others. Therefore, when uploading the model's code to the repository, you could want to choose a free software/open-source (FLOSS) license. We recommend the GPLv3. You only need to include the file 'https://www.gnu.org/licenses/gpl-3.0.txt' as LICENSE.txt with your code. Also, you can choose other options that Zenodo provides: GPLv2, Apache License, MIT License, etc.
Please, reply as soon as possible to this comment with the link for it so that it is available for the peer-review process, as it should be.Juan A. Añel
Geosci. Model Dev. Executive Editor
Citation: https://doi.org/10.5194/egusphere-2023-2424-CEC1 -
AC2: 'Reply on CEC1', Manuel López-Puertas, 25 Jan 2024
Dear Editor-in-Chief,Thank you for your comment and sorry for not being followed the journal policy. We thought that could be done during/after the review process, not at the time of the submission.
The preliminary version of the parameterization (written in python) is available from: https://zenodo.org/records/10547027, with DOI: 10.5281/zenodo.10547027.
The final version (expected to be about a factor 10 faster) will be made available in Fortran 90 under GLP3 license soon. Likely before finalizing the review process, in case it is accepted.Although it is based in a previous software distributed in the community, this is not "formally" an update of a previous parameterization. Its name and version is "CO2 cool-v1", and the license is GPL3.
Further, we will make sure to include the DOI of the code in the new 'Code and Data Availability’ section of the revised manuscript.
Thanks again for your comments.
Best regards, Manuel López PuertasCitation: https://doi.org/10.5194/egusphere-2023-2424-AC2
-
AC2: 'Reply on CEC1', Manuel López-Puertas, 25 Jan 2024
-
RC2: 'Comment on egusphere-2023-2424', Anonymous Referee #2, 23 Dec 2023
As the developer of an LTE radiation scheme used in a GCM, my review is from the point of view of a potential user of the code who would want to improve representation of the upper atmosphere in their code. There is certainly a strong case for a revised non-LTE parameterisation that can handle much larger concentrations of CO2, and therefore the contribution from this paper is welcome. But as I am not an expert on non-LTE effects I can't comment on the scientific details of this particular parameterisation. Naturally I would expect the code to be available at the time of submission to GMD and I expect the authors to rectify this.The algorithm is presented as a complete radiation code, but the LTE part described in section 5.1 is quite crude for tropospheric radiative transfer since it doesn't represent scattering or cloud overlap and heterogeneity. I imagine that most GCM developers (like myself) would want to use their existing radiation scheme in place of the algorithm described in section 5.1 for the LTE region from 0 to 70 km, and then to add on NLTE regions 1-4 described in section 5.2-5.4. It would therefore be helpful to describe how to do this: can I simply replace the cooling rates from my code with the cooling rates from the non-LTE parameterisation above 70 km, even though my bands are different? Do I need to provide any upwelling fluxes at 70 km to feed the treatment of the regions above? The description of how one region is coupled to the one above is not clearly described in the text. Is the vertical resolution of the parameterisation fixed or can I run it on my own vertical grid? Do I need to simulate all regions or can I omit the uppermost 1, 2 or 3 regions if I am not interested in modelling temperatures above a particular height? Has the parameterisation been coded in Fortran or C (needed for a GCM) or in an interpreted language like Python? What is its computational cost? How large is the dataset that needs to be read in (e.g. the various look-up tables that are used to populate the Curtis matrices)?SPECIFIC COMMENTS1. Abstract: it would help to mention the magnitude of LTE heating rate errors (i.e. LTE minus non-LTE), in order to put into perspective the magnitude of the errors in the parameterisation of non-LTE effects (i.e. parameterised non-LTE minus accurate non-LTE).2. There is an excessive number of figures, and they are sometimes referenced out of order. My suggestion is to select one (or at most two) of the test atmospheres and then when you have a 6-panel figure with a separate panel for each atmosphere, reduce it to just one panel in the main body of the text, and then combine figures together when it is useful to have panels next to each other. For example, combine Figs. 6a and 7 into a 2-panel figure, since they show the same thing for the same atmosphere, just on a different scale. Then put the other five atmospheres in Supplementary Material (not in appendices) and refer to them sparingly. I suggest that Fig. 1 is removed as it is not needed, and Fig. 2 is replaced by Fig. 11 (the latter shows the same as the former but with more information). There are plenty of other opportunities for the authors to cut down the number of figures.3. Lines 102, 200 and elsewhere - please refer to profiles #3 and #6 as "present day" and "4x pre-industrial" so the reader doesn't need to flip back to remind themselves what these numbers refer to, and similarly for the other hash-numbered profiles. Also Fig. 9 could state the factor multiplying the pre-industrial figure surface value for each point somewhere on the figure.4. Line 219: "pointing" -> "role in determining"?5. The equations are largely taken from Fomichev et al. (1998), but it would be useful to improve clarity in several places. For example, Equation 1 is simply a matrix-vector multiplication - why not present it as such? The equations for "a" and "b" on lines 264 and 265 are presented as if they define the element the Curtis matrix (via the equation on line 261), but they themselves contains the elements of the Curtis matrix on the right hand side as a scaling for the terms involving the band strengths. So one is left wondering how the actual value of the elements of the Curtis matrix are determined.6. Line 404: remind the reader that by "both" parameterisations you mean Fomichev's original one, and the one in this paper.Citation: https://doi.org/
10.5194/egusphere-2023-2424-RC2 -
AC4: 'Reply on RC2', Manuel López-Puertas, 03 Feb 2024
The comment was uploaded in the form of a supplement: https://egusphere.copernicus.org/preprints/2023/egusphere-2023-2424/egusphere-2023-2424-AC4-supplement.pdf
-
AC4: 'Reply on RC2', Manuel López-Puertas, 03 Feb 2024
Status: closed
-
RC1: 'Evaluation of an updated CO2 radiative cooling parameterization: unraveling challenges, addressing accuracy issues, and assessing applicability to GCMs', Anonymous Referee #1, 03 Dec 2023
The reviewed manuscript discusses an update to a well-known parameterization of the CO2 radiative cooling applicable to the middle and upper atmosphere of Earth. Infrared emission in 15-micron CO2 band is the dominant cooling mechanism in the Earth’s mesosphere and lower thermosphere and these layers affect the lower ones through so-called «downward control», so their including to General Circulation Models (GCM) becomes more and more common.
A pivotal challenge in calculating the cooling rate profiles is linked to the fact that the vibrational level populations of second vibrational mode levels of CO2 molecule are not in local thermodynamic equilibrium with the surrounding atmospheric volume (non-LTE). In other words, one cannot take a local temperature and estimate the vibrational level population needed to calculate the cooling rates. Instead, one has to find these populations in the course of the calculations, which involve two-way radiative transfer in the atmosphere and collisional population and depopulation of the said vibrational levels. These calculations are computationally expensive, and different groups working in the field of non-LTE seek the ways to accelerate them without losing the quality.
From the perspective of a GCM modeler, a streamlined routine for promptly and accurately calculating radiative cooling profiles is always welcomed, with any enhancements in accuracy being commendable.
All this said and acknowledging the usefulness of these routines, I see a number of issues with the present manuscript, which must be resolved prior to its publishing in the journal. I explain it in more details in General comments below. The minor comments and technical corrections section should be also addressed in the next version of the manuscript.
General comments:
- In my opinion, the manuscript tries to cover too many topics despite the fact that the title states that this is an update to existing parameterization. Well, it doesn’t hurt to recall the main milestones of the previous work, but the manuscript in its current form is “unfocused”. If it is intended to be a text-book chapter on non-LTE in the CO2 bands, then the same information could be found in the first authors’ book (Lopez-Puertas and Taylor, 2001). If it is supposed to be a technical paper then it should put more stress on technical aspects like the accuracy, interfacing, and so on. In addition, the text is overloaded with figures. I counted more than a hundred (!) of individual panels in the main part that consists of 41 pages. This is definitely an overkill and one can tell the same story in a much more concise way. I suggest the authors to shorten the manuscript and to keep only the essential parts. For example, all the inputs can be gathered on one two-panel plot, where the left-hand side would be occupied by the reference temperatures and the right-hand side would show the profiles of CO2 (only one is needed) and atomic oxygen, which is crucial for the estimate of the cooling rate. The first figure is not informative at all and can be easily omitted. The large number of panels in figures like Fig. 5 does not add much to the understanding of the principle of the radiative cooling or its calculation, and so on. Overall, I would reduce the number of non-essential figures to a minimum and put more efforts to a description of the routine itself, its implementation to a GCM and its limitations.
- Regarding the routine, I did not see any reference or repository for it provided along with the manuscript. As far as I understand, this is now a requirement for EGUsphere journals, so I wonder when and how did the authors plan to publish the routine. Besides a general conformity with the journal’s rules, it would be advisable to get a self-consistent compilable code with the cooling rate parameterization routine called from the main code with some standard atmospheric profile, which could be replaced with a test profile by the user. In the next paragraph, I explain the current problem I see with the accuracy of the updated parameterization, and I guess the GCM-modelers would have liked to test it themselves prior to implementing it to the model. Summarizing this point, the authors must provide a ready-to-use code and provide an instruction for its compiling and running both as a standalone routine and as a part of the test code, that might be useful not only for GCM-modelers, but for other researchers wanting to get a quick estimate of non-LTE cooling profile for a given atmosphere.
- The authors show that the routine works fairly well for the multitude of atmospheric profiles they use in the tests. This is quite impressive given a large variability of CO2 concentrations used in the study. Still, I cannot consider these tests to be fully representative because the real atmospheric temperature profiles are far from those shown in Fig. 2 of the manuscript in terms of vertical variability. Moreover, they are even worse than the ones shown in Fig. 20 because the averaging kernels of MIPAS instrument in the middle atmosphere are broad (e.g. Dinelli et al., 2021) and, therefore, this instrument cannot capture any wave shorter than 5-7 km. In addition, MIPAS is a limb measuring instrument, so it washes out horizontal inhomogeneities and this further reduces its vertical resolution. At the same time, the gravity waves (GWs) are known to be composed of several waves of different wavelengths and their amplitude increases with height up to the top of the “wave-turbopause” layer at 90-110km (e.g. Offerman et al., 2007; Ge et al., 2022), which overlaps with the non-LTE-affected area. I believe, the MIPAS profiles used in the study do not represent a full picture of a gravity-wave perturbed temperature profiles, so the tests performed with them show only a partial truth. Moreover, large RMS values presented in Fig. 24 even for these, partially smoothed, profiles make me think that the real accuracy of the parameterization is far from 1−2 K/day as it is stated in the abstract (I do not consider the specific case of elevated stratopause, which is addressed; I’m talking about the accuracy of “regular” profiles). If the tests I suggest below do not disprove my suspicions, this wouldn’t cancel the suggested parameterization. But, the GCM modelers will have a clear picture of what they will use and act accordingly if their models produce lifelike GW-perturbed temperature profiles.
- Here is the test I believe is necessary to conduct in order to properly estimate the accuracy of the suggested parameterization. Instead of using the MIPAS profiles and showing the averaged effects, I ask the authors to use the individual temperature profile coming from a ground-based lidar (e.g. Spitsbergen (78°N, 15°E), ALOMAR at Andøya (69°N, 16°E), Kühlungsborn (54°N, 12°E), Boulder (40°N, 105°W), Fort Collins (41°N, 105°W), Logan (42°N, 112°W), Arecibo (18°N, 293°E), Cerro Pachon (30°S, 71°W), or McMurdo (78°S, 167°E).) Since these lidars do not cover the whole atmospheric profile, in the lower atmosphere one can take a corresponding smooth profile from the reanalysis or from any other model. Among the profiles provided by the lidar teams, one has to pick up the ones, which clearly show the GW-signature (at least, the wave of +/- 10 K amplitude at 100km), and perform the exact and parameterized calculations of radiative cooling rate for these profiles. It would be also interesting to see how different wavelengths affect the accuracy, because the non-LTE effects are different in the case of a short-and large-scale perturbations. I have to stress here that due to a nonlinear nature of temperature perturbation effects on non-LTE cooling rates, these results cannot be replaced with the ones obtained for averages.
Minor comments and technical corrections
Lines 4 and 41: this statement is too general. In fact, there are ways of including the non-LTE calculations to GCMs. For example, this was done for Martian GCM (Hartogh et al., 2005) and I don’t see why this can’t be done for Earth. The corresponding manuscript is still in discussion in the same journal, so it can’t be referenced, but the authors claim that the same approach works for the Earth’s atmosphere.
Line 11: since the atomic oxygen is a variable component and the reaction 1c is directly linked to it, it would be good to have it as a variable parameter, see the second general comment
Line 17: the measured profiles themselves is not a ground truth because of the vertical resolution, see the third general comment. Moreover, one cannot average the results for individual runs and present this difference as an error, because the GCMs accumulate the error due to non-linearity of the processes.
Line 58: Figure 1 is not informative, see the first general comment
Lines 120-150: I guess, the readers will be confused here. It looks like GRANADA non-LTE code cannot work in LTE mode whereas normally it requires one line or one flag to calculate LTE populations. Could you, please, explain?
Line 125: I didn’t find any mention of line mixing effects here. Are they not important?
Line 135: I didn’t get the phrase about the “oscillations in RFM results”. Could you, please, clarify?
Line 145: And what about the results without this additional iteration?
Line 171: I recall that the difference is about 2-3K, and I wouldn’t call this a small change, so one should not neglect the daytime vs nighttime differences. This is addressed in Sect. 8, so the wording has to be changed here
Lines 200-215: all these descriptions are correct, but I doubt that they add something to the understanding of the routine or its accuracy, see the first general comment on the scope and focus of the manuscript.
Lines 220-225 (see also the comment to lines 437-462): if we assume that the k(CO2-O) used in the models is equal to 3 x 1e-12 cm3 s-1, then this experiment shows the effects of quadrupling the atomic oxygen mixing ratio. In addition, the reader might be misled by switching from atomic oxygen to k(CO2-O) and back. It would be enough to present this numerical experiment as the one performed for doubled (or quadrupled) atomic oxygen.
Lines 248-395: in fact, this deserves a general comment, but I cannot suggest to modify the general approach, it is what it is, and it works for smooth profiles for a current atmosphere. But what if the atmosphere changes some day and the LTE/NLTE1,2,3,4 regions become different? Let’s imagine that a modeler wants to calculate cooling rates for an Earth-like atmosphere, but with a different vertical temperature structure. How can he/she tell the limits of applicability of this parameterization?
Line 304: this is just one of the examples of the problem outlined in the previous comment. The error introduced by this “implicit assumption” depends on the atmospheric profile and is hidden deep in this module. It is small for the current atmospheres, but it is not guaranteed that it will remain small for some unusual temperature profile.
Lines 437-462: this is another potential candidate for a general comment. The problem is that there are three values of this rate coefficient, k(CO2-O): the first one is measured in the lab and is about 1.5−2.0 x 1e-12 cm3 s-1 (e.g. Castle et al., 2012), the second one is about 6.0-9.0 x 1e-12 cm3 s-1 retrieved from space-borne observations of 15-micron CO2 emissions, and the third one, 3.0 x 1e-12 cm3 s-1 was suggested for using in the GCMs. This paradox has not been resolved over the decades of its study, but it shouldn’t matter for the parameterization itself, because it is supposed to calculate cooling rate with any given k(CO2-O).
Line 455: how do you explain that the errors obtained for a smaller k(CO2-O) are larger? Usually, the larger the quenching rate, the larger the cooling rate, and the magnitude of this error is linked to cooling, as in the case of enhanced CO2.
Line 462: Fig. 20 is barely readable. Please, provide only a couple of profiles coming from a different source (see general comment 4) and show the errors for the corresponding cooling rate profile on the right-hand side panel.
References used in the text
- Castle, K. J., L. A. Black, M. W. Simione, and J. A. Dodd, Vibrational relaxation of CO2(n2) by O(3P) in the142–490 K temperature range, J. Geophys. Res.,117, A04310, doi:10.1029/2012JA017519, 2012
- Ge, W.; Sheng, Z.; Huang,Y.; He, Y.; Liao, Q.; Chang, S. Different Influences on “Wave Turbopause” Exerted by 6.5 DWs and Gravity Waves. Remote Sens. 2023, 15,800. https://doi.org/10.3390/rs15030800, 2022.
- Hartogh, P., A.S. Medvedev, T. Kuroda, R. Saito, and G. Villanueva; A.G. Feofilov and A.A. Kutepov, U. Berger, "Description and climatology of a new general circulation model of the Martian atmosphere", J. Geophys. Res., 110, (E11), doi: 10.1029/2005 JE002498, 2005.
- López-Puertas, M. and Taylor, F.W., “Non-LTE Radiative Transfer in the Atmosphere”. World Scientific Publishing Co, River Edge, NJ, 504pp, 2001.
- Offermann, D.; Jarisch, M.; Schmidt, H.; Oberheide, J.; Grossmann, K.U.; Gusev, O.; Iii, J.M.R.; Mlynczak, M.G. The “Wave Turbopause”. J. Atmos. Sol. Terr. Phys., 69, 2139–2158, 2007.
Citation: https://doi.org/10.5194/egusphere-2023-2424-RC1 -
AC3: 'Reply on RC1', Manuel López-Puertas, 03 Feb 2024
The comment was uploaded in the form of a supplement: https://egusphere.copernicus.org/preprints/2023/egusphere-2023-2424/egusphere-2023-2424-AC3-supplement.pdf
-
CC1: 'Comment on egusphere-2023-2424', Alexander Kutepov, 03 Dec 2023
The comment was uploaded in the form of a supplement: https://egusphere.copernicus.org/preprints/2023/egusphere-2023-2424/egusphere-2023-2424-CC1-supplement.pdf
-
AC5: 'Reply on CC1', Manuel López-Puertas, 03 Feb 2024
The comment was uploaded in the form of a supplement: https://egusphere.copernicus.org/preprints/2023/egusphere-2023-2424/egusphere-2023-2424-AC5-supplement.pdf
-
AC5: 'Reply on CC1', Manuel López-Puertas, 03 Feb 2024
-
EC1: 'Request from the handling editor', Tatiana Egorova, 07 Dec 2023
Dear authors,
please make sure that your code and data are available on-line because you have submitted the manuscript as a development and technical paper. Also, please note because this is an update of the existing parameterization, the name and the version number must be included in the title of the paper.
Editor
Tatiana Egorova
Citation: https://doi.org/10.5194/egusphere-2023-2424-EC1 -
AC1: 'Reply on EC1', Manuel López-Puertas, 25 Jan 2024
Dear Editor,
Thank you for your comment and sorry for taking that long to reply.
The preliminary version of the parameterization (written in python) is available from: https://zenodo.org/records/10547027, with DOI: 10.5281/zenodo.10547027. The final version will be made available in Fortran 90 and expected to be much faster.
Although it is based in a previous software distributed in the community, this is not "formally" an update of a previous parameterization. Actually, although based on the same concept, it has been built from scratch. Its name and version is "CO2 cool-v1", and it is licensed under GPL3.
Best regards,
Manuel Lopez PuertasCitation: https://doi.org/10.5194/egusphere-2023-2424-AC1 -
AC6: 'Reply on EC1', Manuel López-Puertas, 03 Feb 2024
Dear Editor,
We have now sent replies to the two referees and to the community user comments of A. Kutepov.
Just a remark with respect to our previous reply is that the most recent version of the parameterization can be found in:
https://zenodo.org/doi/10.5281/zenodo.10547026. It is still in Python. The final version in Fortran will be made available together (if the case) with the revised version of the manuscript. Its performance in terms of accuracy will be the same, just that will be faster.
Best regards, Manuel
Citation: https://doi.org/10.5194/egusphere-2023-2424-AC6
-
AC1: 'Reply on EC1', Manuel López-Puertas, 25 Jan 2024
-
CEC1: 'Comment on egusphere-2023-2424', Juan Antonio Añel, 20 Dec 2023
Unfortunately, after checking your manuscript, it has come to our attention that it does not comply with our "Code and Data Policy".
https://www.geoscientific-model-development.net/policies/code_and_data_policy.htmlYou do not provide a public repository for the code you use and develop for your manuscript. This is mandatory for manuscripts submitted to Geosci. Model Dev., and it must be available at submission time, open and available to the community. Therefore, this must be fixed, or we will have to reject your manuscript for publication.
In this way, you have to reply to this comment as soon as possible with the link and DOI of a repository containing the above mentioned code relevant for your work. The repository must be one listed in our policy as acceptable.
Also, in any potential reviewed version of your manuscript you must include the new 'Code and Data Availability' section, with the DOI of the code. Also, note that if you have to include a license for the code, otherwise it continues to be your property and it can not be used by others. Therefore, when uploading the model's code to the repository, you could want to choose a free software/open-source (FLOSS) license. We recommend the GPLv3. You only need to include the file 'https://www.gnu.org/licenses/gpl-3.0.txt' as LICENSE.txt with your code. Also, you can choose other options that Zenodo provides: GPLv2, Apache License, MIT License, etc.
Please, reply as soon as possible to this comment with the link for it so that it is available for the peer-review process, as it should be.Juan A. Añel
Geosci. Model Dev. Executive Editor
Citation: https://doi.org/10.5194/egusphere-2023-2424-CEC1 -
AC2: 'Reply on CEC1', Manuel López-Puertas, 25 Jan 2024
Dear Editor-in-Chief,Thank you for your comment and sorry for not being followed the journal policy. We thought that could be done during/after the review process, not at the time of the submission.
The preliminary version of the parameterization (written in python) is available from: https://zenodo.org/records/10547027, with DOI: 10.5281/zenodo.10547027.
The final version (expected to be about a factor 10 faster) will be made available in Fortran 90 under GLP3 license soon. Likely before finalizing the review process, in case it is accepted.Although it is based in a previous software distributed in the community, this is not "formally" an update of a previous parameterization. Its name and version is "CO2 cool-v1", and the license is GPL3.
Further, we will make sure to include the DOI of the code in the new 'Code and Data Availability’ section of the revised manuscript.
Thanks again for your comments.
Best regards, Manuel López PuertasCitation: https://doi.org/10.5194/egusphere-2023-2424-AC2
-
AC2: 'Reply on CEC1', Manuel López-Puertas, 25 Jan 2024
-
RC2: 'Comment on egusphere-2023-2424', Anonymous Referee #2, 23 Dec 2023
As the developer of an LTE radiation scheme used in a GCM, my review is from the point of view of a potential user of the code who would want to improve representation of the upper atmosphere in their code. There is certainly a strong case for a revised non-LTE parameterisation that can handle much larger concentrations of CO2, and therefore the contribution from this paper is welcome. But as I am not an expert on non-LTE effects I can't comment on the scientific details of this particular parameterisation. Naturally I would expect the code to be available at the time of submission to GMD and I expect the authors to rectify this.The algorithm is presented as a complete radiation code, but the LTE part described in section 5.1 is quite crude for tropospheric radiative transfer since it doesn't represent scattering or cloud overlap and heterogeneity. I imagine that most GCM developers (like myself) would want to use their existing radiation scheme in place of the algorithm described in section 5.1 for the LTE region from 0 to 70 km, and then to add on NLTE regions 1-4 described in section 5.2-5.4. It would therefore be helpful to describe how to do this: can I simply replace the cooling rates from my code with the cooling rates from the non-LTE parameterisation above 70 km, even though my bands are different? Do I need to provide any upwelling fluxes at 70 km to feed the treatment of the regions above? The description of how one region is coupled to the one above is not clearly described in the text. Is the vertical resolution of the parameterisation fixed or can I run it on my own vertical grid? Do I need to simulate all regions or can I omit the uppermost 1, 2 or 3 regions if I am not interested in modelling temperatures above a particular height? Has the parameterisation been coded in Fortran or C (needed for a GCM) or in an interpreted language like Python? What is its computational cost? How large is the dataset that needs to be read in (e.g. the various look-up tables that are used to populate the Curtis matrices)?SPECIFIC COMMENTS1. Abstract: it would help to mention the magnitude of LTE heating rate errors (i.e. LTE minus non-LTE), in order to put into perspective the magnitude of the errors in the parameterisation of non-LTE effects (i.e. parameterised non-LTE minus accurate non-LTE).2. There is an excessive number of figures, and they are sometimes referenced out of order. My suggestion is to select one (or at most two) of the test atmospheres and then when you have a 6-panel figure with a separate panel for each atmosphere, reduce it to just one panel in the main body of the text, and then combine figures together when it is useful to have panels next to each other. For example, combine Figs. 6a and 7 into a 2-panel figure, since they show the same thing for the same atmosphere, just on a different scale. Then put the other five atmospheres in Supplementary Material (not in appendices) and refer to them sparingly. I suggest that Fig. 1 is removed as it is not needed, and Fig. 2 is replaced by Fig. 11 (the latter shows the same as the former but with more information). There are plenty of other opportunities for the authors to cut down the number of figures.3. Lines 102, 200 and elsewhere - please refer to profiles #3 and #6 as "present day" and "4x pre-industrial" so the reader doesn't need to flip back to remind themselves what these numbers refer to, and similarly for the other hash-numbered profiles. Also Fig. 9 could state the factor multiplying the pre-industrial figure surface value for each point somewhere on the figure.4. Line 219: "pointing" -> "role in determining"?5. The equations are largely taken from Fomichev et al. (1998), but it would be useful to improve clarity in several places. For example, Equation 1 is simply a matrix-vector multiplication - why not present it as such? The equations for "a" and "b" on lines 264 and 265 are presented as if they define the element the Curtis matrix (via the equation on line 261), but they themselves contains the elements of the Curtis matrix on the right hand side as a scaling for the terms involving the band strengths. So one is left wondering how the actual value of the elements of the Curtis matrix are determined.6. Line 404: remind the reader that by "both" parameterisations you mean Fomichev's original one, and the one in this paper.Citation: https://doi.org/
10.5194/egusphere-2023-2424-RC2 -
AC4: 'Reply on RC2', Manuel López-Puertas, 03 Feb 2024
The comment was uploaded in the form of a supplement: https://egusphere.copernicus.org/preprints/2023/egusphere-2023-2424/egusphere-2023-2424-AC4-supplement.pdf
-
AC4: 'Reply on RC2', Manuel López-Puertas, 03 Feb 2024
Viewed
| HTML | XML | Total | BibTeX | EndNote | |
|---|---|---|---|---|---|
| 330 | 107 | 32 | 469 | 12 | 14 |
- HTML: 330
- PDF: 107
- XML: 32
- Total: 469
- BibTeX: 12
- EndNote: 14
Viewed (geographical distribution)
| Country | # | Views | % |
|---|
| Total: | 0 |
| HTML: | 0 |
| PDF: | 0 |
| XML: | 0 |
- 1