the Creative Commons Attribution 4.0 License.
the Creative Commons Attribution 4.0 License.
| 20 Mar 2026
Stochastic perturbation of inputs to parametrisation schemes machine-learnt from high-resolution model variability
Abstract. Stochastic parametrisation schemes represent sources of uncertainty in atmospheric model and several types of these schemes are in widespread use in general circulation models across a variety of temporal and spatial resolutions. We introduce a new stochastic scheme for use in global atmospheric models, which uses a machine learning model trained on high-resolution convection-permitting simulation data to estimate properties of the distribution of subgrid variability in potential temperature. This then informs the profile of stochastic perturbations being applied to the inputs of traditional parametrisation schemes. This scheme is tested in single column model experiments over the tropical west Pacific and is shown to improve model performance in this case.
- Preprint
(3026 KB) - Metadata XML
- BibTeX
- EndNote
Status: final response (author comments only)
-
CEC1: 'Comment on egusphere-2025-6312', Juan Antonio Añel, 28 Mar 2026
-
AC1: 'Reply on CEC1', Helena Reid, 30 Mar 2026
Have uploaded these to Zenodo. The GitHub references can be revised to use https://doi.org/10.5281/zenodo.19331887 and https://doi.org/10.5281/zenodo.19331816 for ENNUF and LFRic respectively.
Citation: https://doi.org/10.5194/egusphere-2025-6312-AC1
-
AC1: 'Reply on CEC1', Helena Reid, 30 Mar 2026
-
RC1: 'Comment on egusphere-2025-6312', Anonymous Referee #1, 20 Apr 2026
The authors present a novel approach that leverages machine learning (ML) to generate perturbed inputs for a suite of physical parameterizations. Using output from several limited-area model simulations, the proposed method emulates subgrid-scale variability in key thermodynamic variables. The resulting framework, referred to as PAPILLON, produces stochastic perturbations that are then applied to the inputs of conventional physical parameterizations.
The ML emulator is evaluated in a single-column model configuration against the ERA-5 dataset, based on a single test case. The results suggest that using PAPILLON to perturb the inputs leads to slightly improved performance compared to an ensemble generated using the SPT perturbation scheme.
I appreciate the originality of the proposed approach. The framework introduced here provides an interesting way to combine machine learning with existing physical parameterizations. However, the conclusions would be strengthened by the inclusion of additional test cases to assess the robustness of the results.
While the manuscript is generally well written, I found parts of it difficult to follow. In particular, the level of detail provided in some sections tends to obscure the main message. Streamlining the presentation and improving the overall structure, e.g. by introducing additional subsections and clearer signposting, would significantly enhance readability.
General comments
- The introduction contains a substantial amount of useful background information. However, I found it somewhat difficult to follow, and the main line of reasoning is not always clear. Clarifying or simplifying the introduction would strengthen the argument.
- The manuscript would benefit from substantial restructuring to improve clarity and focus. At present, the content is somewhat diffuse, with a level of detail in places that tends to obscure the main message. Streamlining the text and emphasizing the key ideas more directly would significantly improve readability.
- It is not entirely clear to me why perturbations are applied only to potential temperature. While the introduction highlights the importance of this variable for convection, it is presented more as an example than as a justification for this specific choice. The authors are encouraged to clarify this point more explicitly. It may also be more appropriate to move this discussion to the Methods section.
- Although I understand that running a large number of limited-area model simulations is computationally expensive, I wonder whether sampling variability over only one month is sufficient to ensure robustness. Some discussion of this limitation would be helpful.
- It would be useful to include a brief description in the main text of the numerical implementation in the single-column model (SCM), in particular regarding the use of ENNUF.
Specific comments
- l. 141-142: Was the model trained using randomly selected samples across all spatial domains and timesteps? To improve independence between training, validation, and test datasets, the authors might consider leaving out entire simulations (e.g. some LAM runs) or contiguous time periods.
- l. 270: How is the height of the troposphere diagnosed?
- Figure 8: When either the length scale or the time parameter is varied, what value is used for the other parameter that is held fixed?
Citation: https://doi.org/10.5194/egusphere-2025-6312-RC1 -
AC2: 'Reply on RC1', Helena Reid, 27 May 2026
We thank the reviewer for their time and valuable comments, which we address point by point in turn as follows:
General comments:- The introduction contains a substantial amount of useful background information. However, I found it somewhat difficult to follow, and the main line of reasoning is not always clear. Clarifying or simplifying the introduction would strengthen the argument.
The manuscript would benefit from substantial restructuring to improve clarity and focus. At present, the content is somewhat diffuse, with a level of detail in places that tends to obscure the main message. Streamlining the text and emphasizing the key ideas more directly would significantly improve readability.- We have moved the parts of the introduction discussing cases in which stochastic perturbations that are linear (or similar) w.r.t. parametrisation scheme outputs are unable to capture uncertainty (approx. lines 60 to 90 and figure 1) to a new subsection “motivation” at the start of the methods section. The introduction can then go directly from an overview of stochastic schemes present in the literature to a brief description of the key differences in the stochastic scheme that will be presented in this paper, leaving detailed justification for these choices to a later subsection rather than in the introduction. This restructuring should hopefully help the flow of the paper.
- It is not entirely clear to me why perturbations are applied only to potential temperature. While the introduction highlights the importance of this variable for convection, it is presented more as an example than as a justification for this specific choice. The authors are encouraged to clarify this point more explicitly. It may also be more appropriate to move this discussion to the Methods section.
- We have rephrased the presentation of the examples in an attempt to present them as more of a justification. Our reasoning about the examples mentioned (the triggering and vertical extent of convection) was that while we certainly do not expect these to be the only cases in which the uncertainty in the effects of the subgrid state on the gridscale state does not scale linearly with the predicted parametrised tendency, they already seem justification enough to try out a stochastic scheme that permits more complicated relationships between the uncertainty and the stochastic perturbation, to check whether relaxing this requirement on that relationship is beneficial in practice. We will include some discussion of why potential temperature was chosen, and give an explanation here too. From a naïve parcel theory examination of convection (that is, in the absence of entrainment), the main variables to consider when estimating the height and vigour of convection are the potential temperature and (except for dry convection) the humidity of the initial parcel, generally near the surface, and the vertical profile of potential temperature. We’d thus expect a convection scheme to be very sensitive to perturbations in the near-surface values of both of these variables, and also sensitive to perturbations in the vertical profile of potential temperature, so we narrowed our choices to these. If we were to perturb both humidity and temperature, we would need to make additional choices in the structure of our scheme, namely, how to correlate perturbations in both of these variables (should a cooling perturbation always be paired with a drying one? The inverse? Should they be independent? Something in between?), and each would need its own scaling factors, which would all need tuning to values that produce sensible model behaviour, necessitating more experiments. To avoid this, we chose to perturb only one of the two, and because we hypothesised the impact from perturbing potential temperature aloft might be greater than perturbing humidity aloft, we chose to perturb potential temperature. A different choice would still have been a valid thing to investigate, and indeed the effects of a scheme which chooses to perturb surface humidity instead is discussed in Tomkins and Berner 2008 (https://doi.org/10.1029/2007JD009284).
- Although I understand that running a large number of limited-area model simulations is computationally expensive, I wonder whether sampling variability over only one month is sufficient to ensure robustness. Some discussion of this limitation would be helpful.
- We will include some discussion of this limitation, as it is indeed a limitation. We do not have good evidence that the machine learning model’s training data covers a sufficient variety of states that it will still perform well in all possible unseen conditions, nor do we know how much data is required for this particular problem to allow a model to predominantly be interpolating when given unseen data rather than extrapolating. That said, we do not believe that this limitation detracts from the overall conclusions of the paper, firstly because we only show that the inclusion of the ML model in the scheme is beneficial in this specific test case (which is correct regardless of whether poor generalisability makes it detrimental in other cases, something which could be true but is beyond the scope of the paper), and secondly because the proposed type of scheme is shown to still be beneficial even if the ML model is removed entirely (albeit less so). Running more kilometre-scale simulations similar to the ones used here would be computationally prohibitive, though there are existing datasets which could be drawn from to create a larger dataset (though differences in resolution between datasets would need addressing), e.g. the DYAMOND project, and we are happy mention this in the conclusions of the paper. If in future work examining less idealised cases or further examples of idealised cases it is found that the ML model performs poorly in different regions, times, or weather conditions, then this limitation may be responsible, so it is important to be wary of that possibility at this stage and we thank the reviewer for this point.
- It would be useful to include a brief description in the main text of the numerical implementation in the single-column model (SCM), in particular regarding the use of ENNUF.
- When we say ENNUF translated the neural network which we trained in python using tensorflow/keras to Fortran, we mean that ENNUF contains Fortran code for components of a neural network (dense layers, convolutional layers, etc) and it can automatically generate a subroutine which calls those components in the correct order (which may be more complex than a sequential structure) with the correct arguments and with the correct weights. The weights are printed into the Fortran subroutine as constants, and the files containing this subroutine and the neural network components can then be placed in, and called in the appropriate place, within the Fortran project of your choice, in our case the “fast physics” section of the timestep of the LFRic SCM.
Specific comments:
- l. 141-142: Was the model trained using randomly selected samples across all spatial domains and timesteps? To improve independence between training, validation, and test datasets, the authors might consider leaving out entire simulations (e.g. some LAM runs) or contiguous time periods.
- Yes, it was. This is a fair point, the analysis of the performance of the ML model on the test data (Fig. 5) may give the model’s R2 score as higher than it would be on test data more substantially different to that in the training data. This has a similar effect on the conclusions of the paper to the point made above concerning whether this dataset is sufficient to allow the ML model to be robust to the wider variety of conditions it might see if deployed in a global model. That is, we don’t know how well it might perform on any data other than what we’ve tested it against here, and this could mean the beneficial effects of the ML model on the scheme are reduced or nullified in less idealised or other test cases. We can amend the wording so that the answer to this question is clear. Our result that this scheme is beneficial may not continue to hold when deployed in a global model, and these points about the ML model’s ability to generalise may be the cause if that turns out to be so. Our results are an encouraging sign that the effect of the scheme in other scenarios seems worth investigating.
- l. 270: How is the height of the troposphere diagnosed?
- It is not, this was not made clear in the text. The perturbations are actually multiplied by a constant which is reduced linearly in height from 1 at model level 45 (about 14km) to 0 at model level 50 (about 18km). Saying “no perturbations in the stratosphere” is thus only approximately true. The model top is at 80km, so perturbations are zero from 18km to 80km, which covers most or all of the stratosphere, depending on the exact height of the tropopause, which could be above 18km in the tropics, but we do not actually diagnose it. This linear tapering is something that is done for the existing SPPT-type stochastic scheme in LFRic, and we included it in our scheme for similar reasons – that if there ought to generally be little to no tendency from parametrised convection and boundary layer processes at these altitudes, and this is thought to be correct w.r.t reality, then all random perturbations are able to do is make things worse, by very occasionally introducing erroneously inflated tendencies. We could have left this out and it probably wouldn’t have changed anything in this test case, because the chances of a random perturbation accidentally causing say, moist convection that rises well above the tropopause is extremely unlikely (or maybe even impossible, since we cap perturbations to no more than three times the predicted standard deviation of potential temperature). The chance of detrimental impacts may be more significant when the scheme is called more frequently, since in a global model the scheme could easily be called ~10^6 times per timestep. We have rephrased this part of the text to state that a linear in height taper was used, rather than saying perturbations above the tropopause were removed.
- Figure 8: When either the length scale or the time parameter is varied, what value is used for the other parameter that is held fixed?
- 10km and 6 hours respectively. These values are given on line 220, but we have now repeated this information in the figure 8 caption so that the reader doesn’t have to refer back to the text to check this while interpreting the figure.
In addition, the reviewer points out that the evidence in favour of the use of this scheme may be strengthened by additional test cases beyond the ensembles ran over the 1 month period in the tropical west Pacific presented here. This particular test case was chosen for the frequent convective activity in the region (which means we ought to see a measurable effect from our stochastic perturbations to the convection scheme) and the quantity and quality of observations in this time and place (which makes the comparison to reanalysis more meaningful), but other idealised test cases could also fulfil these criteria.
Although the scheme might benefit from using extra training data, it is not clear how much would be required to ensure that all possible scenarios have been covered. Similarly, it is not clear how many additional single-column location would need to be simulated before wondering how this scheme would perform in a 3d model. It is very much our plan to deploy and test this scheme in a 3d climate model in the future.
Citation: https://doi.org/10.5194/egusphere-2025-6312-AC2 - The introduction contains a substantial amount of useful background information. However, I found it somewhat difficult to follow, and the main line of reasoning is not always clear. Clarifying or simplifying the introduction would strengthen the argument.
-
RC2: 'Comment on egusphere-2025-6312', Anonymous Referee #2, 07 Aug 2026
General Comments
This manuscript develops a stochastic component for subgrid-scale parameterizations based on the machine learning (ML)-predicted variability of potential temperature variance. The work is novel, interesting, and has strong potential utility for modern parameterization development.
However, the manuscript requires some revisions before publication. Specifically, the methodology and its justification need further clarification, and several formulations and textual descriptions would benefit from refinement. Below is a detailed list of suggestions for improvement.
Major Comments
- Please clarify the rationale for focusing on predicting and implementing potential temperature perturbations rather than perturbations in humidity or wind speed. What is the physical or methodological justification for this choice?
- It is currently unclear which specific parameterizations within the PAPILLON runs are modified by the ML-predicted variance of potential temperature. That could be clarified on lines 167–170.
- (CRPS) for both deterministic and stochastic models. Please explain the exact methodology used for this comparison. While CRPS is designed for evaluating probabilistic forecasts, detailing exactly how it was formulated here to evaluate deterministic versus stochastic outputs will aid reproducibility and clarity.
- My main concern is whether the improvements observed in the Single Column Model (SCM) using the ML-predicted scheme will translate effectively into a full 3D model. This skepticism arises because the "spt" parameterization (which is presumably intended to improve 3D simulation results) actually demonstrates a degradation in the SCM model. The authors should address this discrepancy and discuss the implications for a future 3D implementation.
Specific / Technical Corrections
- Line 20: Please provide appropriate citations to support the claim that “...deterministic mapping has been criticised.”
- Line 59: The phrasing “An example of source of uncertainty that cannot be represented in this way is not given” is confusing. Please rewrite for clarity.
- Line 75: Avoid using vague terminology like “some” (e.g., “The data are from some kilometer scale…”). Please specify the exact scale or rephrase for scientific precision.
- Figure 1 caption: The final sentence is awkwardly phrased and needs to be rewritten for clarity.
- Line 126: Should q be denoted as a vector?
- Equation 1: It is unclear whether this equation predicts variance strictly at the surface, at a specific atmospheric level, or for the entire vertical profile vector. If it is level-dependent, I would expect the depth/height of that level to be a necessary predictor. Please clarify.
- Line 140: Please include a standard reference for the Adam optimizer (e.g., Kingma and Ba, 2014).
- Line 144: The LFRic model is introduced here without prior explanation. Please provide a brief description and the relevant reference upon its first mention in the text.
- Lines 167–170: This section would be the ideal place to explicitly state which schemes are modified with the perturbed potential temperature.
- Line 256: Please define “NN” or correct here and in the remainder of the paper if it should be ML.
Citation: https://doi.org/10.5194/egusphere-2025-6312-RC2 -
AC3: 'Reply on RC2', Helena Reid, 04 Sep 2026
We thank the reviewer for their time and comments and address them in turn below.
Major Comments
Please clarify the rationale for focusing on predicting and implementing potential temperature perturbations rather than perturbations in humidity or wind speed. What is the physical or methodological justification for this choice?
We justify the choice of only perturbing a single variable on methodological grounds; and the choice of potential temperature specifically was physically motivated but other choices were possible.
Here, we had to make a choice of variable(s) to perturb. Perturbing more than one variable adds an additional component to the scheme - how does one determine the
correlations between perturbations of different variables? Choosing to perturb a single variable reduces the number of structural choices necessary in the creation
of the scheme, and as one might want to investigate the effects of changing those choices
(e.g. by having three sets of experiments in which perturbations of two variables were independently sampled, maximally correlated, or maximally anticorrelated)
this would make analysis of the scheme more complex as well.It was then a question of which variable. We wished to perturb the convection scheme
due to its strong influence in global simulations and the proposed mechanisms in the paper by which a stochastic scheme of this form might change convective
tendencies. In a simple parcel theory analysis of convection, the convection is determined first by the near-surface temperature and humidity
(which determines the properties of the parcel of air that rises) and the profile of temperature (which determines its buoyancy at each altitude),
while the profile of humidity has a secondary influence via its effect on the virtual potential temperature, and a complicated influence determined by the
parameterization of entrainment (which will be more specific to a given convection scheme). Winds, likewise, we expect to have a smaller influence on convective
tendencies than temperature or moisture, and indeed in some convective parameterizations they are neglected as inputs altogether.
From this simplistic picture we expect the most influential variables on the convective tendencies to be temperature at higher altitudes and humidity at lower ones,
and indeed this is similar to what was seen in Lopez & Moreau's 2005 work (https://doi.org/10.1256/qj.04.69) which looked at the sensitivity of a convection scheme to its inputs.
Wanting only to perturb one variable, it came down to a choice between these two, and we chose (potential) temperature. This was partly because
we were interested in investigating the impact of vertical correlations in stochastic perturbations (which are often neglected in stochastic parameterization),
and the above thoughts made it seem like a better candidate for this than humidity (in which the effect of different choices of vertical correlations may be quite small compared to the choice of how to perturb the near-surface layers), but ultimately the choice is somewhat arbitrary and the question of what effects a scheme
like this would have were different choices made remains an interesting one open to future investigation.It is currently unclear which specific parameterizations within the PAPILLON runs are modified by the ML-predicted variance of potential temperature. That could be clarified on lines 167–170.
We will clarify this in the text. It was the parameterizations of convection and of boundary layer turbulence.
(CRPS) for both deterministic and stochastic models. Please explain the exact methodology used for this comparison. While CRPS is designed for evaluating probabilistic forecasts, detailing exactly how it was formulated here to evaluate deterministic versus stochastic outputs will aid reproducibility and clarity.
Here we have a 25 5-day long periods, and in each of these we have an ensemble of SCM runs (that is, simulations of the same location and time period which are identical but for perturbed initial conditions).
We used the following software package to compute CRPS scores for each variable for each 5-day period.
The mean was then taken of the resulting 25 CRPS scores obtained for each variable to produce a measure of the performance on that variable over the entire month.@software{zanetta_scoringrules_2024,
author = {Francesco Zanetta and Sam Allen},
title = {scoringrules: a python library for probabilistic forecast evaluation},
year = {2024},
url = {https://github.com/frazane/scoringrules}
} (citation should be added to paper)We used the `crps_ensemble` function, described by the documentation thus:
```
For a forecast :math:`F` and observation :math:`y`, the CRPS is formally defined as:.. math::
\mathrm{CRPS}(F, y) &= \int_{-\infty}^{\infty} (F(x)
- \mathbf{1}\{y \le x\})^{2} dx \\\
&= \mathbb{E} | X - y | - \frac{1}{2} \mathbb{E} | X - X^{\prime} |,where :math:`X, X^{\prime} \sim F` are independent. When :math:`F` is the empirical
distribution function of an ensemble forecast :math:`x_{1}, \dots, x_{M}`, the CRPS
can be estimated in several ways. Currently, scoringrules supports several
alternatives for ``estimator``:- the energy estimator (``"nrg"``),
- the fair estimator (``"fair"``),
- the probability weighted moment estimator (``"pwm"``),
- the approximate kernel representation estimator (``"akr"``).
- the AKR with circular permutation estimator (``"akr_circperm"``).
- the integral estimator (``"int"``).
- the quantile decomposition estimator (``"qd"``).
```
Where we had used the default choice of quantile decomposition estimator.
My main concern is whether the improvements observed in the Single Column Model (SCM) using the ML-predicted scheme will translate effectively into a full 3D model. This skepticism arises because the "spt" parameterization (which is presumably intended to improve 3D simulation results) actually demonstrates a degradation in the SCM model. The authors should address this discrepancy and discuss the implications for a future 3D implementation.This work has followed a strategy whereby the new scheme is tested in an idealised model first. This provides two key benefits. Firstly, the simpler system allows the simulations to be understood, and bugs can be found, without needing to consider the complex feedback that occur in a fully interactive 3D model. Secondly, the SCM is much cheaper allowing a greater variety of configurations to be tested.
The use of SCMs in this way has a long history (e.g. Betts & Miller 1986), however the reviewer's concern that the results may not generalise to 3D is a concern very much shared by the authors going forward.
It is always possible that results using idealised models do not continue to hold in more realistic simulations and we will draw more attention to this in the conclusions of the paper, as future work will be needed to ascertain this.Note that while we found results that do not generalise to less idealised simulations for SPT,
this was not the case for other experimental configurations with known effects in 3D - for example, the PC2 cloud scheme
used as default here had different, overall better behaviour in our experiments compared to the Smith 1990 scheme, which is what
one might expect, given both the results in Wilson et al 2008 (https://doi.org/10.1002/qj.332) and that the Smith scheme was largely
supplanted by the PC2 scheme in Met Office Unified Model configurations after PC2's development. Something similar may be said about the
use of the Lambert Lewis convection scheme versus the 6a scheme used as default in our experiments.
Specific / Technical CorrectionsLine 20: Please provide appropriate citations to support the claim that “...deterministic mapping has been criticised.”
Will add appropriate citations. To begin with, a lot of papers cited elsewhere in this work make this criticism (e.g. Palmer 2019, Weisheimer & Corti 2014),
so they can be cited in this sentence too.Line 59: The phrasing “An example of source of uncertainty that cannot be represented in this way is not given” is confusing. Please rewrite for clarity.
Will replace
```
However, certainly \emph{all} uncertainty cannot be represented this way. An example of a source of uncertainty that cannot be represented in this way is now given.
```
with
```
However, not \emph{all} uncertainty can be represented in this way. An example of such a source of uncertainty is now given.
```
which is hopefully clearer.Line 75: Avoid using vague terminology like “some” (e.g., “The data are from some kilometer scale…”). Please specify the exact scale or rephrase for scientific precision.
Changed `The data are from some km-scale simulations described in the next section.` to `The data are from convection-permitting (grid box side lengths ~1.5km) simulations described in the next section.`
Figure 1 caption: The final sentence is awkwardly phrased and needs to be rewritten for clarity.
can change
```
The dataset these were taken from is described in section 2 and is the same region used in fig. 3.
```
to
```
These data are from the convection-permitting simulations described in section 2, and are from the same region of the world as the data in fig. 3.
```Line 126: Should q be denoted as a vector?
Yes, used bold to indicate vectors elsewhere but accidentally used an overbar here, will correct the notation to be consistent throughout.
Equation 1: It is unclear whether this equation predicts variance strictly at the surface, at a specific atmospheric level, or for the entire vertical profile vector. If it is level-dependent, I would expect the depth/height of that level to be a necessary predictor. Please clarify.
The entire vertical profile. Will change the text to make this clear.
Line 140: Please include a standard reference for the Adam optimizer (e.g., Kingma and Ba, 2014).
Will add this.
Line 144: The LFRic model is introduced here without prior explanation. Please provide a brief description and the relevant reference upon its first mention in the text.
We will add a citation to https://doi.org/10.1016/j.jpdc.2019.02.007 and briefly describe the model.
Lines 167–170: This section would be the ideal place to explicitly state which schemes are modified with the perturbed potential temperature.
Will add this (boundary layer & convection)
Line 256: Please define “NN” or correct here and in the remainder of the paper if it should be ML.
Missed defining this as "neural network", though it is often used in this paper interchangeably with the more generic phrase "ML model", so changing the text to stick to one term may also be appropriate here.
Citation: https://doi.org/10.5194/egusphere-2025-6312-AC3
Data sets
CRMML Cyril Morcrette https://doi.org/10.5281/zenodo.13332843
Model code and software
LFRic atmospheric model UK Met Office https://github.com/MetOffice/lfric_apps/
ENNUF machine learning translator Helena Reid, Theano Xirouchaki, Joana Rodrigues, and Cyril Morcrette https://github.com/MetOffice/ennuf
Viewed
| HTML | XML | Total | BibTeX | EndNote | |
|---|---|---|---|---|---|
| 775 | 236 | 70 | 1,081 | 64 | 68 |
- HTML: 775
- PDF: 236
- XML: 70
- Total: 1,081
- BibTeX: 64
- EndNote: 68
Viewed (geographical distribution)
| Country | # | Views | % |
|---|
| Total: | 0 |
| HTML: | 0 |
| PDF: | 0 |
| XML: | 0 |
- 1
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.html
You 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. Therefore, the current situation with your manuscript is irregular. Please, publish your code 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.
In addition, 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 Editor