the Creative Commons Attribution 4.0 License.
the Creative Commons Attribution 4.0 License.
CLEO: The Numerical Methods of a New Superdroplet Model including a Droplet Breakup Algorithm
Abstract. The numerical methods of conventional Eulerian models have obscured our fundamental understanding of cloud microphysics and introduced artificial uncertainties. In contrast, the Super-Droplet Model (SDM) provides a transparent link between model and theory, and remedies the numerical artifacts that hindered decades of cloud modelling. In light of its numerous advantages we’ve created a novel SDM for warm-cloud microphysics called CLEO, with the goal of making it feasible to run Large-Eddy Simulations (LES) with SDM in domains large enough to resolve shallow mesoscale cloud organisation O(100 km). Here we document the microphysics grounding CLEO and how it is translated into numerical methods, with the intention of assisting the physical interpretation of future LES and comparison with observations. We highlight subtle but important points where we differ from existing SDMs: in how we model the ventilation effect on evaporation, and how we account for uncertainty in our knowledge of droplet collisions. As well as modelling collision-coalescence we propose a low-cost extension to the original SDM algorithm which adds both collisional rebound and breakup. We demonstrate CLEO’s capabilities with known test-cases for condensation/evaporation, collisions between droplets, and droplet motion, including an integrated test using the 1-D Kinematic Driver framework. CLEO can therefore now be used stand-alone, one-way coupled for piggybacking, or two-way coupled for LES, as a fully-functioning SDM capable of representing all the main microphysical processes driving warm-clouds.
- Preprint
(12110 KB) - Metadata XML
- BibTeX
- EndNote
Status: open (until 29 Dec 2025)
-
RC1: 'Comment on egusphere-2025-4399', Emily de Jong, 24 Nov 2025
reply
The comment was uploaded in the form of a supplement: https://egusphere.copernicus.org/preprints/2025/egusphere-2025-4399/egusphere-2025-4399-RC1-supplement.pdfReplyCitation: https://doi.org/
10.5194/egusphere-2025-4399-RC1 -
RC2: 'Comment on egusphere-2025-4399', Anonymous Referee #2, 04 Dec 2025
reply
The comment was uploaded in the form of a supplement: https://egusphere.copernicus.org/preprints/2025/egusphere-2025-4399/egusphere-2025-4399-RC2-supplement.pdf
-
CEC1: 'Comment on egusphere-2025-4399 - No compliance with the policy of the journal', Juan Antonio Añel, 08 Dec 2025
reply
Dear authors,
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 have archived your code on GitHub. However, GitHub is not a suitable repository for scientific publication. GitHub itself instructs authors to use other long-term archival and publishing alternatives, such as Zenodo. Also, you have archived the data used and produced in your work in Edmond; however, we can not accept Edmond as a platform to publish your data.
Therefore, the current situation with your manuscript is irregular. Please, publish your code and data in one of the appropriate repositories and reply to this comment with the relevant information (link and a permanent identifier for it (e.g. DOI)) as soon as possible, as we can not accept manuscripts in Discussions that do not comply with our policy.
Also, you must include a modified 'Code and Data Availability' section in a potentially reviewed manuscript, containing the information of the new repositories.
I must note that if you do not fix this problem, we cannot continue with the peer-review process or accept your manuscript for publication in our journal.
Juan A. Añel
Geosci. Model Dev. Executive EditorCitation: https://doi.org/10.5194/egusphere-2025-4399-CEC1 -
CC1: 'Reply on CEC1', Bjorn Stevens, 10 Dec 2025
reply
This comment follows and summarizes some offline discussions. First I want to express my appreciation for the journals efforts to promote open science. My concern is that an overly principled approach becomes artificial and creates a false sense of openness with out addressing the real problems, which are cultural. First I would address this point in general, and then more specifically for the manuscript at hand.
For the general issue: a strict and formal approach to this issue creates a bureaucratic solution (or attempted solution) to a cultural problem. The cultural problem is open science. Using frozen repos to provide snapshots of an implementation only creates the appearance of reproducibility. Worse is that it puts the onus on the implementation rather than the idea. I say 'appearance of reproducibility' because most complex codes only run on the machines they were developed on. We estimated that we spent a good person year porting a version of ICON that ran on NV GPUs (P100s) on Piz Daint, to Juwels Booster which used A100s and a different software stack. We estimated we spent 15 person years to get ICON to run on a different architecture (chip vendor and compiler) on LUMI. So for all practical matters, for the complex codes, where really implementing an idea one's self is difficult, posting the code snapshot to a repo becomes a bureaucratic act that often is a misleading waste of time and energy.
Meaningful reproducibility is a manuscript that describes the methods well enough that someone can reproduce the results. Here the results are not the exact numbers that the author produces, but the ideas that the numbers are used to advance. Ideas should not depend on the details of the implementation and if they are then they are not robust, and this sort of testing is something the scientific process is designed to sort out. Simply posting code snapshots, if they run at all, confuses the implementation with the idea, and there is a real scientific interest in having them separated.
Furthermore having code as part of a living repo, for instance as a tagged version in an open development on GitHub (or similar), provides a much more organic connection between the developers and eventual users of a code, as the users can then contribute, incorporate bug fixes and so on. If a bug fix changes the numbers but not the conclusions of a study it isn't something that should imply an addendum and comment in the journal, but it might change the conclusions of a different study that someone else does, and if so they should be rather directed by the manuscript to the open development as the reference on record.
How we share our science is a cultural issue. GMD would do itself and the community a great favor by revisiting its policies, something that could be initiated by through an open discussion. In revisiting this I would rather look for ways to communicate best practices, by highlighting authors and reviewers who practice them. In the end however, we don't want to restrict the field of ideas by saying that we don't want contributions that only present the idea but not the implementation. If our policies become overly prescriptive we effectively make assumptions that have the effect of making science less open.
As for the more specific issue. The concern with EDMOND seems to be that the authors can retain editing rights and hence delete their repo after posting it. Why not simply ask the authors to say that they won't delete the code on the repo. I understand that moving the trust issue from the authors to the maintainers of the repo seems to give an additional layer of protection, but we also know there are many cases where data is deleted from public repos accidentally by the maintainers. We also know that institutions that maintain repos will go out of business, so why do we emphasize institutional trust rather than personal trust and behavior. All the more so why this singular focus on the implementation of an idea (the code) which in the end is supplementary. Maybe this distinction is more clear if we recognize that no one would envision that every implementation of the same idea merits publication. The idea not the implementation is the contribution.
In the present case a practical solution would be to work with repositories to give them more options to support good practice. All the more so if the repositories are funded by major underwriters of the journal, as is the case here with MPDL being a major supporter of the Copernicus journals. I ask the chief editors to take these points into consideration and review their policies, and also let the manuscript proceed through review as they do so. In the end if they decide not to revise the policies, or if a satisfactory solution cannot be worked out with EDMOND, then we as authors would be faced with the decision to comply (upload a snapshot to zenodo) before final publication.Citation: https://doi.org/10.5194/egusphere-2025-4399-CC1 -
CEC2: 'Reply on CC1', Juan Antonio Añel, 12 Dec 2025
reply
Dear authors,
Regarding the compliance of the manuscript, considering the communication offline via email, given that Edmond is capable of removing the permissions for modification from the authors of a deposited asset, we could accept Edmond to publish the assets of your manuscript if the managers of Edmond confirm us that they have removed the mentioned permissions for authors. Therefore, we would kindly ask you to contact Edmond managers to that they can do it, and they reply to this comment with the confirmation of it, ideally providing some kind of evidence of such modification.
Juan A. Añel
Geosci. Model Dev. Executive Editor
Citation: https://doi.org/10.5194/egusphere-2025-4399-CEC2 -
CC2: 'Reply on CEC2', Clara Bayley, 15 Dec 2025
reply
Copy of Bjorn Stevens' comment on 13th December 2025 (https://doi.org/10.5194/egusphere-2025-4398-CC3) from same discussion on companion to this manuscript:
Dear Editor Team,
thanks for this constructive and pragmatic decision.
Certainly I appreciate the problems with more of our intellectual property somehow being managed by a private sphere, which is one of the main reasons for supporting journals like the EGU family of journals, and (the new Tellus), which are not only scholarly run and edited, but also work with presses that share the same values, e.g., Copernicus and Ubiquity.On the longer term, I very much that GMD takes on the challenge to continually revisit policies and mechanisms to improve the culture and practice of open access.
Citation: https://doi.org/10.5194/egusphere-2025-4399-CC2 -
CC3: 'Reply on CEC2', David Walter, 16 Dec 2025
reply
Dear editor,
I hereby confirm that I have removed all write permissions for the Edmond dataset https://doi.org/10.17617/3.SDN0NX, meaning that the author can no longer make any changes to the dataset or remove data. If any further update should be needed in the dataset (e.g. updating the reference to the paper by adding the final paper DOI), that would be done by us (Edmond management team) in a new dataset version (same DOI), while keeping the current dataset version 3.0 unchanged. For any questions you can contact us via edmond@mpdl.mpg.de.
Kind regards,
David----------------------------------------------------------------
David Walter
Research Data Management | Collections | rdm.mpdl.mpg.de
Edmond service lead | https://edmond.mpg.de
Max Planck Digital Library (MPDL) | www.mpdl.mpg.de
Landsberger Straße 346, 80687 München, Deutschland
E-Mail: d.walter@mpdl.mpg.de
----------------------------------------------------------------Citation: https://doi.org/10.5194/egusphere-2025-4399-CC3 -
CEC3: 'Reply on CC3', Juan Antonio Añel, 17 Dec 2025
reply
Dear authors,
Many thanks for this confirmation. We can consider now your manuscript in compliance with the policy of the journal.
Juan A. Añel
Geosci. Model Dev. Executive Editor
Citation: https://doi.org/10.5194/egusphere-2025-4399-CEC3
-
CEC3: 'Reply on CC3', Juan Antonio Añel, 17 Dec 2025
reply
-
CC2: 'Reply on CEC2', Clara Bayley, 15 Dec 2025
reply
-
CEC2: 'Reply on CC1', Juan Antonio Añel, 12 Dec 2025
reply
-
CC1: 'Reply on CEC1', Bjorn Stevens, 10 Dec 2025
reply
Viewed
| HTML | XML | Total | BibTeX | EndNote | |
|---|---|---|---|---|---|
| 327 | 153 | 36 | 516 | 18 | 14 |
- HTML: 327
- PDF: 153
- XML: 36
- Total: 516
- BibTeX: 18
- EndNote: 14
Viewed (geographical distribution)
| Country | # | Views | % |
|---|
| Total: | 0 |
| HTML: | 0 |
| PDF: | 0 |
| XML: | 0 |
- 1