the Creative Commons Attribution 4.0 License.
the Creative Commons Attribution 4.0 License.
CESM2/CARMA Cloud and CARMA Aerosol Model Descriptions
Abstract. The Community Aerosol and Radiation Model for Atmospheres (CARMA) is a sectional microphysical model widely used to understand the formation of aerosols and clouds. This paper is an updated description of the CARMA model algorithms since Toon et al 1988, with examples from the newly developed CARMA Cloud model. This paper describes the general algorithms and solvers for nucleation, condensation/evaporation, coagulation, and sedimentation shared among all CARMA aerosols and clouds models; specific microphysical processes needed for water droplet and ice; how the CARMA Cloud is set up and how it interacts with other processes inside the Community Earth System Model.
Status: final response (author comments only)
-
CEC1: 'Comment on egusphere-2026-1185', Astrid Kerkweg, 01 Apr 2026
-
AC1: 'Reply on CEC1', Yunqian Zhu, 01 Apr 2026
Dear Editor, thank you for the comments.
1. the CARMA version is version 4, which will be add to the title during the revision.
2. We created a new permanent doi to archive the model code:
NCAR CARMA Group, & Owen Brian Toon Research group. (2026). Community Aerosol and Radiation Model for Atmospheres (CARMA) standalone 4.11 code. University of Colorado Boulder. https://doi.org/10.25810/SNMH-NW733. And the data for the output are achived at: Zhu, Y. (2026). CARMA Cloud model standalone test results [Data set]. Zenodo. https://doi.org/10.5281/zenodo.19373048
Citation: https://doi.org/10.5194/egusphere-2026-1185-AC1
-
AC1: 'Reply on CEC1', Yunqian Zhu, 01 Apr 2026
-
RC1: 'Comment on egusphere-2026-1185', Parker Case, 06 Apr 2026
This paper is an impressive description of a highly complex and detailed microphysical model. The paper represents a triumph in moving forward the CESM model. For the most part the paper is well written, technically correct, and ready for publication. Below I outline a few general comments as well as smaller "in-line" comments. The primary issue with the manuscript as is is that the naming conventions for the various models is inconsistent and unclear. Once the below comments are rectified, this manuscript should be published.
General comments
What is the name of the overall model you are presenting? Does CARMA Cloud Model refer to the CESM2 configuration or just the configuration of CARMA?
Make sure it is clear, for each of the given experiments (sedimentation, coagulation, etc.) what the model is you’re using. Is it the box-model? Is it the 1-d column model?
Throughout the paper, CARMA Cloud is, I think, being contrasted with other CESM2 modules. I’ve made line-specific comments below about this but in general, make it clear when you are contrasting a something to your novel CARMA Cloud model.
Some processes (contact nucleation, for example) are mentioned but either not implemented in the CARMA Cloud codebase or not turned on. An explanation as to why these design choices were made would clarify the paper significantly.
1 Introduction:
Line 60-76: The second sentence of this paragraph seems to be restating something that is clear from the first sentence. I suggest removing it.
There is some amount of confusion about the naming of the different configurations you are considering here as well. At the beginning of the paragraph, you refer to “CESM2 CARMA Cloud” but later say “this paper links CARMA Cloud with the MAM4 model aerosol model”. Are these referring to the same thing? Make sure it is clear when you are talking about a full model configuration (like a configuration of CESM2) versus the individual components (like CARMA or MAM4).
Line 90-91: For readability, this sentence should read, “CARMA has also been developed and applied to study planetary atmospheres”
Line 96-98: The final sentence of this paragraph means nothing to someone who doesn’t use CESM2—I don’t know what the namelist is. Could it be removed?
2 General Model Structure
Lines 122-134: Processes, like “When ice particles fall, they redistribute dust and sulfate,” should be in the body of the paper, not the figure description. Make sure that all of the colors and symbols in the figure are described.
Lines 136-137: Model naming conventions: here it seems that “CARMA Cloud model” is actually referring to a configuration of CESM2 that includes the cloud-enabled version of CARMA.
Lines 169-170: Does the extra size information from CARMA improve the representation of the optical properties for ice/graupel or are the same assumptions made as MG?
Line 184: Should be RRTMG, not RRTGM
Lines 190-233: This is an excellent overview of the CARMA module and routines!
Lines 247-263: This description of the number concentration element/numerical problem should be its own paragraph, not attached to the discussion of grids above.
3 CARMA Continuity Equation Algorithms and Solvers
Lines 309-313: Is the cldfrc scaling used only when converting CARMA-calculated values to CESM2? Or do you scale the values inside CARMA?
Lines 324-325: Wording, I suggest, “Coagulation is expensive to compute and slow, therefore it is often time split.”
Line 324-335: Are you using coalescence and coagulation interchangeably here? It might be good to be consistent or to define the difference explicitly.
Line 414: These sedimentation tests are done in the standalone, 1-d CARMA? It might be good to explicitly mention this.
Line 510: “Avoid” should be “Avoids”
Lines 519-520: This sentence is confusingly worded. I suggest “To conserve mass between the vapor and particle phases, particles are not allowed to grow out of the largest mass bin”
Lines 539-542: “In Nature” should be “In nature”. Additionally “lead to broadening the size distribution or make it multimodal” could be simplified for clarity to “broaden the size distribution or make it multimodal”.
Lines 549-558: How often does the sub stepping happen? i.e. for a given time-step, how much of the global grid is sub stepping?
Lines 564-566: The parenthetical on this sentence is hard to understand—what does it mean to “setup the convergence criteria to do that”?
Lines 571-585: Are there physical inconsistencies in the way that CLUBB treats the bulk variables that CARMA passes it during this process? In other words, does CLUBB make its own size assumptions for any processes that are different than the size information inside of CARMA?
Lines 608-609: Is Ak=1 and g1 = 0 okay because of the size? Could you explain these choices?
Lines 633-636: Some additional information is needed in this caption about what each frame of the figure means, especially (j) and (k).
Lines 687-689: How were these parameters chosen?
Line 715: This shows the same experiment as Figure 11, just with different parameters, correct? This sentence makes it sound like it is entirely separate.
Lines 738-739: This sentence does not make sense, “The model uses 100 vertical levels resolutions in a Cartesian coordinate system.” Perhaps remove “resolutions”?
4 Physical Process Equations
Lines 780-782: “at every time” should be “at every tilmestep”.
Lines 782-785: This sentence is unclear. Are these the options in CESM/CARMA? The third option (where everything except coagulation is updated) is complex and maybe warrants its own sentence.
Lines 789-791: There’s certainly a more recent version of Seinfeld and Pandis than 1998—it seems preferable to cite a more recent/updated version.
Figure 16: Why not include the Beard (1976) values on the right panel?
Lines 853-854: “Oddly, this term is not discussed in textbooks when coalescence is considered despite being dominant in some size ranges”. This is not clear from Figure 18. “cbr” does not seem to be dominant in any of the size ranges shown.
Lines 862-864: “The collision efficiencies of liquid cloud, ice, and raindrops based on the table in (Hall, 1980) can be used in CARMA Cloud since they are widely used in other models”. This is a poor reason. Maybe “they have been widely validated in other models”? Similar for the “Ecoalescence” value a few sentences later.
Lines 890-893: This comment, I assume, is about the non-CARMA cloud models in CESM2. This should be made explicit.
Lines 942-947: The Gettleman and Morrison model is not used if CARMA Cloud is being used, correct? Is this meant to contrast with CARMA Cloud?
Lines 989-991: How common is this process? How big of a problem is it that CARMA Cloud does not return the sulfate in melting ice particles to liquid droplets?
Line 1042: “That model uses” should be “Those models use,” referring to both Bardeen’s model and M&G.
Lines 1053-1057: “We’ve comment out these nucleation processes”. The verb tenses don’t make sense. I think it should be “We’ve commented out”.
5 Conclusions
Line 1088: “Cloud sized particle” should be “cloud sized particles”.
Line 1099: “MG” has not been defined up to this point, it has previously been referred to as Gettelman and Morris or Morris and Gettelman.
Citation: https://doi.org/10.5194/egusphere-2026-1185-RC1 -
RC2: 'Comment on egusphere-2026-1185', Anonymous Referee #2, 28 Apr 2026
First, I apologize to the editor and the authors for the delay.
I like this manuscript and I recommend it for prompt publication after some minor improvements here and there. I have some comments below that will hopefully improve the manuscript, but none should be treated as blocking — all optional. I would love to read a paragraph discussing if the added complexity and cost end up actually worthwhile. I say that as someone who goes between wanting more realism on the one hand but fearing for lost interpretability on the other hand.
One meta comment is that the paper is not very well written and can be significantly improved. At the very end, I wrote what I would do if I were you…
General
- I am not a fan of inserting code jargon into the main text — stuff like "the radius is defined in setupbins" — so for better readability the authors should figure out a way to describe this without resorting to mixing regular language with code_blocks. See next comment.
- All equations and figures can be improved substantially. There's a better way to write pseudo-code or a pseudo-equation that doesn't look like rmass of bin i = rmassmin × rmrat^(i-1), which frankly doesn't look good, and reflects badly on an otherwise esteemed list of authors. At a minimum, code identifiers should be monospaced and equations should be set in math font. Equation (5) in particular is, as written, essentially unreviewable — please render it properly with aligned terms and consistent subscripting.
- The manuscript oscillates between really detailed (and at times tedious) descriptions of algorithms and growth bookkeeping, and barely addressing entire sections from 4.4 onward. The model description appears to lose steam right where the physics gets interesting (nucleation, immersion freezing, contact freezing, mixed-phase). It reads like the authors ran out of time. The same uneven density also makes Section 2 feel like it belongs in a code reference manual rather than a GMD paper.
Specific comments I wrote while (re)reading the manuscript
- L 33: "the code is flexible and extensible" jumps out of nowhere with no evidence. Either remove or dedicate a paragraph to actually substantiating it — the following sentence is about runtime options, which is not really what "code flexibility and extensibility" means.
- L 56: to get this right, all these people cited above use CARMA but nobody has ever described it? It seems that's what the authors are suggesting, or maybe what they mean is that they're putting all the descriptions in one place. Either way, situate this manuscript in context of prior descriptions more clearly, and make explicit what is new here vs. updated vs. consolidated.
- L 96: can these be combined? Did all the users in the previous paragraph contribute their code back to the main CARMA codebase, or are there many divergent forks? This affects what "the CARMA model" even refers to in this paper.
- L 99: the authors keep saying "the code has been updated" (and derivatives) and it's a bit jarring because there is zero evidence about what the updates actually were. The previous paragraph started with the same line. Is this a code paper? If so, framing should be different — and in any case, "updated" and "improved" without specifics should be replaced with concrete deltas relative to prior works.
- L 105–107: delete. The manuscript is already long, and listing what each section will discuss adds zero value when readers can just look at the section titles.
- Fig 1: any story behind 48 bins for everything? 48 appears six times in the figure with different ranges — is this a coding artifact (e.g., aligning with NBIN as a compile-time constant), a memory/throughput optimization, or a physically motivated choice? A sentence would help.
- Fig 3 and the associated discussion: if I were the authors, I would move this to the supplement. A few-sentence paragraph describing the run flow suffices in the main text.
- Eq 1 and Eq 2: the format changes between the two equations, which feeds into the general disarray of the math typesetting. Please make consistent.
- L 303: "a mixing ratio" of what units? kg-substance / kg-air? Better explain this.
- L 304: concentration in what units? Number per cm³? Per cm² per scaled z? The text introduces both within a few lines without saying which.
- L 307: "ρ = ρ_z times z_met" — does this mean ρ = ρ_z · z_met, or something else? Use a multiplication symbol.
- L 382–383: to be clear, this paragraph is only about vertical movement, right? Say that here.
- Eq 5: as noted in the General comments, this is essentially unreviewable as typeset. Please render with aligned terms and consistent subscripting; I cannot say whether the equation is correct in its present form.
- Fig 5: hard to parse as a single figure
- Eq 6: the form ∂C/∂t = ∂(g_m C)/∂m reads as if it has the same sign on both sides — i.e., the opposite of the analogous flux-divergence form in Eq. (1). I assume this is a typesetting issue, but please verify.
- L 492: be careful with the word "flux" — g_m × C in Eq. (6) is the flux across the mass coordinate (in the continuum sense), so reusing the word for the bin-edge fluxes can confuse.
- L 501: does this implicit solver have a name? It looks like a backward-Euler step on a linear loss term — if there's a textbook reference, cite it.
- L 526: all true, but the presentation makes dr/dt ∝ 1/r seem trivially known. Cite or explain — there is plenty of literature deriving how g_m scales with r (gets messy at very small r, but that's not the issue here). Also: are we talking about aerosols here, or cloud and rain droplets? The paragraph slides between them. And while you're at it, remind readers why the mean free path is being introduced (continuum vs. kinetic regimes).
- L 543: "vapor concentration" needs unpacking — available vapor mass per unit volume? Above some saturation reference? It's used as if obvious.
- L 590–593: dropping every activated aerosol into bin 4 (~0.56 µm) is a tuning that throws away activation-size information. What is the sensitivity of CDNC, autoconversion, and rainfall to carma_dropact_bin?
- L 601: please cite.
- Eq 9: please cite — this is the Smoluchowski binary coagulation equation.
- Eq 12: please cite, and use notation consistent with K_c. Also: do the authors consider effects of turbulence (e.g., turbulent enhancement of collision rates inside convection) to be part of c_gr, c_cd, or absent? The next equation answers this implicitly, but it should be stated explicitly here.
- Eq 14: answers the previous comment — but please state directly that turbulence-enhanced collision is not represented.
- L 863: "can be used in CARMA Cloud since they are widely used in other models" is a poor justification.
- L 888: please cite the coalescence-kernel literature. Also, the fact that the data are forty to fifty years old is an observation, not a justification.
- L 942–947: the Gettelman & Morrison model is not used when CARMA Cloud is on, correct? Is this paragraph meant as a contrast? If so, say so.
- L 1083–1084: "modified Slingo scheme" without a Slingo citation.
- L 1132 (disclosure): good to see the disclosure. In revision, I would actually recommend feeding both the PDF of this manuscript as well as reviewer comments straight into an LLM to help triage them — many of the surface-level complaints above are easily addressable that way, and the authors' time is better spent on the substantive scientific points.
Citation: https://doi.org/10.5194/egusphere-2026-1185-RC2
Viewed
Since the preprint corresponding to this journal article was posted outside of Copernicus Publications, the preprint-related metrics are limited to HTML views.
| HTML | XML | Total | BibTeX | EndNote | |
|---|---|---|---|---|---|
| 684 | 0 | 5 | 689 | 0 | 0 |
- HTML: 684
- PDF: 0
- XML: 5
- Total: 689
- BibTeX: 0
- EndNote: 0
Viewed (geographical distribution)
Since the preprint corresponding to this journal article was posted outside of Copernicus Publications, the preprint-related metrics are limited to HTML views.
| Country | # | Views | % |
|---|
| Total: | 0 |
| HTML: | 0 |
| PDF: | 0 |
| XML: | 0 |
- 1
Dear authors,
in my role as Executive editor of GMD, I would like to bring to your attention our Editorial version 1.2: https://www.geosci-model-dev.net/12/2215/2019/
This highlights some requirements of papers published in GMD, which is also available on the GMD website in the ‘Manuscript Types’ section: http://www.geoscientific-model-development.net/submission/manuscript_types.html
In particular, please note that for your paper, the following requirement has not been met in the Discussions paper:
Please provide the version number of CARMA in the title of your revised manuscript.
As GitHub is not a persistent archive, please provide a persistent release for the exact source code versions for CARMA and CESM/CARMA used for the publication in this paper. As explained in https://www.geoscientific-model-development.net/about/manuscript\_types.html the preferred reference to this release is through the use of a DOI which then can be cited in the paper. For projects in GitHub a DOI for a released code version can easily be created using Zenodo, see https://guides.github.com/activities/citable-code/ for details. Finally note, that according to our new Editorial (v1.2) all data and analysis / plotting scripts should be made available.
Additionally, the part of the model output on which the results of your paper are based need to be made pupblicly available.
Yours,
Astrid Kerkweg