the Creative Commons Attribution 4.0 License.
the Creative Commons Attribution 4.0 License.
| 07 Mar 2024
CICERO Simple Climate Model (CICERO-SCM v1.1.1) – an improved simple climate model with a parameter calibration tool
Abstract. The CICERO Simple Climate Model (CICERO-SCM) is a lightweight, semi-empirical model of global climate. Here we present a new open-source Python port of the model for use in climate assessment and research. The new version of CICERO-SCM has the same scientific logic and functionality as the original FORTRAN version but it is considerably more flexible and open source via Github. We describe the basic structure, improvements compared to the previous FORTRAN version, together with technical descriptions of the global thermal dynamics and carbon cycle components and the emissions module, before presenting a range of standard figures demonstrating its application. A new parameter calibration tool is demonstrated to make an example calibrated parameter set to span and fit a simple target specification. CICERO-SCM is fully open source and available through GitHub (https://github.com/ciceroOslo/ciceroscm).
-
Notice on discussion status
The requested preprint has a corresponding peer-reviewed final revised paper. You are encouraged to refer to the final revised version.
-
Preprint
(3193 KB)
-
The requested preprint has a corresponding peer-reviewed final revised paper. You are encouraged to refer to the final revised version.
- Preprint
(3193 KB) - Metadata XML
- BibTeX
- EndNote
- Final revised paper
Journal article(s) based on this preprint
Interactive discussion
Status: closed
-
RC1: 'Comment on egusphere-2024-196', Anonymous Referee #1, 09 Apr 2024
In this manuscript, the authors present a new version of the CICERO-SCM, an open-source simple climate model. The authors had two main objectives: (1) to describe and document the model and (2) to present some application of CICERO-SCM. The authors presented a thorough description of the model, its implementation, and a few applications using CICERO-SCM however, I think the power of CICERO-SCM could be better demonstrated by including results from future scenarios. With minor revisions, this manuscript will be a nice addition to the RCM literature.
General Comments/Questions
- Translating the model implementations between different languages is no easy task! It seems that, at times, the authors are undervaluing this effort. Implementing the model in Python greatly increases model accessibility and readability, even if the model run time increases a bit, CICERO-SCM is still operating at a fraction of the runtime of an ESM. As it is currently written, it is unclear if/what scientific changes were made between V1.1.1 and the previous Fortran implementation.
- Figures 2, A3, A4, have the y-axis start at 0, which for some variables doesn’t seem necessary, and the scale of the y-axis makes it difficult to make examine the differences between CICERO-SCM and the comparison data. One idea would be for the authors to have a free y-axis that is not always start a 0 but near the minimum.
- It looks like there were some formatting issues, such as inconsistent spacing between paragraphs (e.g., L26, L112, L225.) and several citations incorrectly formatted inline citations (L24, L63, L189). These sorts of things are easy to do and will be caught by the copy editor so minor in the grand scheme of things.
Specific Comments/Questions
L20: missing a space between eg and the citation
L45: excellent point!!
Figure 1: use subscripts in the chemical names
L96: “dictionary” is this a Python specific term?
Table 1: Sunvolc is this a boolean parameter? If is it set to 1 does that mean that inputs for sun and volcanic radiative forcing are both required? Or could a user provide only one?
L108: what is meant by tracer components here?
L120-123 : is a tad confusing, is the model only CO2-driven between 1750-1850? If so why? Or are there non-CO2 emissions during this period that are held constant? More details on which concentrations (the species and the time frame) are needed would be helpful here. Are the required concentrations user-defined?
L180 - 190: I am having a difficult time understanding equations 6-9 and I think it stems from some confusion related to f_fer and beta. What is the difference between f_fer and beta? Are they related in some way? Some more details here would be helpful. Is f_fer typically negative?
~L220: “ This implementation is appropriate for discrete input data only, where the emissions (and concentrations) are assumed constant throughout the year. For a timestep of less than one year…” what is the time step for CICERO-SCM? Can it run on a monthly time step? If it is running in with monthly inputs are all emission inputs needed to be monthly?
L244 : Equation 9, would it be possible to add a subscript to the parameters to indicate which parameters vary with the gas species?
L240: missing a space between “CH4is”
Section started at L220: Here in 2.1.3 CH4 - emissions to concentrations, the authors describe how CICERO-SCM supports three different methods for calculating tau oh. Which option does CICERO-SCM use by default? What is the motivation for supporting these three different dynamics? Is this feature common in other SCMs? It seems like this is an opportunity for the authors to highlight one of CICERO’s unique features.
Figure 3: where did the uncertainty ribbon/envelop come from? Is it from IPCC AR6 or is it from an ensemble of CICERO runs?
L476: “twelve sub-yearly timesteps” like monthly? The discussion here and then also in L220 is confusing me. It would be helpful to have a clear discussion somewhere in the manuscript that addresses CICERO’s time step addressing the following
- If/what inputs can be sub-annual? What happens to the inputs that are not sub-annual?
- If there are sub-annual inputs, what time step? Monthly? Daily?
- How does using sub-annual inputs affect outputs?
L 494: It would be helpful to have some more details about many new tunable parameters. Are there like or 5 or 10 parameters? Are these parameters listed somewhere?
L499: “automatic tests including regression test to make sure the results from the energy balance model”, is a bit unclear, so it is this regression calculating the difference between current model behavior and the previous model behavior? What sort of regression tests are good enough to pass the automatic testing?
L 510: The change in run time seems minimal to me, yes is unfortunate but adopting Python greatly improves the readability and accessibility!
Figure 7: would it be possible to do a more robust comparison between CICERO output? Either plotting a and b on the same figure? Would is be possible to compare CICERO V1.1.1 results with the CICERO results included in AR6 7.SM.4? That could provide more evidence that the results did not change very much.
L525: Where does the parameter distribution set defined in the json-file come from? Is it generated with the calibration tools included in the CICERO repository? Would running the calibration tools result in a new set of parameters? Would the calibration tool work on any tunable parameter?
L 532: the phrase “larger the calibration space” is somewhat unclear, does this refer to the uncertainty space of the parameters? The number of parameters being tuned? The number of variables being compared? The length of the time series being used in comparison data?
L 560: Just a suggestion but I think you could drop the word significantly here…
L 575: “inclusion of temperature feedbacks into the carbon uptake” is that for the ocean carbon cycle? Or the terrestrial carbon cycle?
Caption of Figure A1: missing a space in “2014and”
Figures A1, A3, A6: Why is HCFC-123 constant at 0 over the entire period of the run?
Figures A1-8: what is the plot number for? Is that the code used by the plotter functions to make the plots?
Citation: https://doi.org/10.5194/egusphere-2024-196-RC1 -
AC2: 'Reply on RC1', Marit Sandstad, 27 May 2024
Dear Anonymous Referee #1,
Thank you for your thorough and comprehensive read and multiple helpful comments on our manuscript! Below we will try to respond to each of your specific comments and we have made amendments to our manuscript according to them. Your comments are added in Italics before each reply.
L20: missing a space between eg and the citation
Thank you, we have fixed this!
Figure 1: use subscripts in the chemical names
Figure 1: Thank you for pointing out the lack of subscript. We have updated the figure accordingly.
L96: “dictionary” is this a Python specific term?
L96: A dictionary is a data structure (in python, but also in other language) of unordered key-value pairs. We have tried to clarify this in the text and used the opportunity to elaborate a bit on what the output dictionary holds.
Table 1: Sunvolc is this a boolean parameter? If is it set to 1 does that mean that inputs for sun and volcanic radiative forcing are both required? Or could a user provide only one?
Table 1: The sunvolc parameter is not boolean, but this is mainly to conform with the previous Fortran implementation. There are default datafiles for both solar and volcanic forcing which will be used if the user does not supply data for them. The user can supply their own data for one or both of them, and if one or more of them are missing as inputs, while the sunvolc parameter is 1, whatever the user has not supplied will be taken from defaults. We have tried to elaborate a bit on this in the table.
L108: what is meant by tracer components here?
L108: Tracer components is simply a synonym for components, chemical species/components etc. We will change it to chemical components. Hopefully that is easier to understand.
L120-123 : is a tad confusing, is the model only CO2-driven between 1750-1850? If so why? Or are there non-CO2 emissions during this period that are held constant? More details on which concentrations (the species and the time frame) are needed would be helpful here. Are the required concentrations user-defined?
L120-123: This might be a bit cryptic indeed. The run is set up so that at nystart, the run start, concentrations are calculated from emissions for CO2, but for all other species concentrations are taken from prescribed user input concentrations. At emstart, the start year for emissions, concentrations for all other species will also be calculated from input emissions. We’ve tried to rewrite a bit to make this clearer.
L180 - 190: I am having a difficult time understanding equations 6-9 and I think it stems from some confusion related to f_fer and beta. What is the difference between f_fer and beta? Are they related in some way? Some more details here would be helpful. Is f_fer typically negative?
L180-190: Again, thank you for pointing out a confusing part of the text. We have tried to elaborate a bit so as to show that the f_fer is the result current fertilization added to time integrated decay of historical fertilization. This is related to the fertilization factor beta in that the current fertilization is calculated from the CO2 concentration using this fertilization factor according to equation 9. We’ve rewritten a bit around the equations in this whole sections to make things clearer, hopefully that helps.
~L220: “ This implementation is appropriate for discrete input data only, where the emissions (and concentrations) are assumed constant throughout the year. For a timestep of less than one year…” what is the time step for CICERO-SCM? Can it run on a monthly time step? If it is running in with monthly inputs are all emission inputs needed to be monthly?
~L220: Currently the model operates with only yearly input data but can handle volcanic forcing data on a monthly resolution. The carbon cycle is integrated using 24 sub yearly timesteps (where you can in principle run with a different number of sub yearly timesteps), and the upwelling diffusion model works with 12 sub yearly integration steps, for which varying monthly varying forcing could be used. However, the current model only takes in yearly data (barring volcanic forcing), and only outputs yearly data. If you wanted something else, it would need to be rewritten. We’ve tried to make this a bit clearer in the text now
L244: Equation 9, would it be possible to add a subscript to the parameters to indicate which parameters vary with the gas species?
L244: I assume this comment pertains to equations 10-14. Yes, that sounds like a good idea. We’ve tried to implement that.
L240: missing a space between “CH4is”
L240: Thank you, fixed!
Section started at L220: Here in 2.1.3 CH4 - emissions to concentrations, the authors describe how CICERO-SCM supports three different methods for calculating tau oh. Which option does CICERO-SCM use by default? What is the motivation for supporting these three different dynamics? Is this feature common in other SCMs? It seems like this is an opportunity for the authors to highlight one of CICERO’s unique features.
Section started at L220: Here in 2.1.3 CH4 - emissions to concentrations. We assume this pertains to section 2.1.3. The default lifetime mode for lifetime is TAR. This is pointed out by putting default in paranthesis, but we can see how that might be missed. The (actually 4) different methods of calculating the OH-lifetime can allow the user who is interested in methane specifically to run with different setup, highlighting this option is a good suggestion which we thank the reviewer for and which we have tried to implement in the updated version of the article.
Figure 3: where did the uncertainty ribbon/envelop come from? Is it from IPCC AR6 or is it from an ensemble of CICERO runs?
Figure 3: The uncertainty ribbon is from the IPCC ERF timeseries. We’ve tried to make this clearer in the caption now.
L476: “twelve sub-yearly timesteps” like monthly? The discussion here and then also in L220 is confusing me. It would be helpful to have a clear discussion somewhere in the manuscript that addresses CICERO’s time step addressing the following
If/what inputs can be sub-annual? What happens to the inputs that are not sub-annual?
If there are sub-annual inputs, what time step? Monthly? Daily?
How does using sub-annual inputs affect outputs?
L476: Thank you for pointing out the confusion related to various time steps and resolutions. We’ve now added a few sentences to the introduction to clarify a bit on both temporal and spatial resolution. In general, you can say that the model is yearly and global, though certain parts of the model have sub yearly timesteps to provide a more accurate numerical solution to the differential equations it solves. Only in the upwelling_diffusion_model and for forcing does this translate to an option to input monthly data.
L 494: It would be helpful to have some more details about many new tunable parameters. Are there like or 5 or 10 parameters? Are these parameters listed somewhere?
L494: We’ve now added a listing of tunable parameters from the previous version and the current one. We’ve also added a bit more on the increased flexibility of the new version.
L499: “automatic tests including regression test to make sure the results from the energy balance model”, is a bit unclear, so it is this regression calculating the difference between current model behavior and the previous model behavior? What sort of regression tests are good enough to pass the automatic testing?
L499 We’ve now elaborated on this.
L 510: The change in run time seems minimal to me, yes is unfortunate but adopting Python greatly improves the readability and accessibility!
L510: We also think this is a price worth paying for readability, however, speed is useful, so we would still like to improve the speed of the code if we can.
Figure 7: would it be possible to do a more robust comparison between CICERO output? Either plotting a and b on the same figure? Would is be possible to compare CICERO V1.1.1 results with the CICERO results included in AR6 7.SM.4? That could provide more evidence that the results did not change very much.
Figure 7: We’ve added a third panel to the plot where results for a single scenario is shown for both versions alongside the observations. Hopefully this makes the comparison easier.
L525: Where does the parameter distribution set defined in the json-file come from? Is it generated with the calibration tools included in the CICERO repository? Would running the calibration tools result in a new set of parameters? Would the calibration tool work on any tunable parameter?
L525: You can use the calibration tool to create a json-file defining a parameter ensemble, but you can also generate or have the json file from elsewhere. For instance, we have a json-file of the parameter-ensemble used in the AR6 process which we’ve used to do the runs shown in figure 7. You can use the calibration tool to generate new parameter set, and yes, you can use the calibration tools to tune whichever tunable parameter you want. We’ve expanded this a bit to clarify.
L 532: the phrase “larger the calibration space” is somewhat unclear, does this refer to the uncertainty space of the parameters? The number of parameters being tuned? The number of variables being compared? The length of the time series being used in comparison data?
L 532: By calibration space we mean both the width and dimensionality of the prior parameter space, i.e. both the number of parameters to fit and the range of their priors. We’ve added a bit to clarify this.
L 560: Just a suggestion but I think you could drop the word significantly here…
L560: We are happy to accept this suggestion.
L 575: “inclusion of temperature feedbacks into the carbon uptake” is that for the ocean carbon cycle? Or the terrestrial carbon cycle?
L575: This comment relates to both the oceanic and terrestrial carbon cycle, none of which currently have temperature feedbacks. In practice, it might also be interesting to have feedbacks to just one of the two, but both are valid options to consider for a carbon cycle update of the model.
Caption of Figure A1: missing a space in “2014and”
Caption of Figure A1: Thank you for pointing out the missing space. We’ve fixed this now.
Figures A1, A3, A6: Why is HCFC-123 constant at 0 over the entire period of the run?
Figures A1, A3, A6: Good catch. The reason is simply that the input we used didn’t have any data for HCFC-123, and hence we ran with zero emissions for this gas throughout. We’ve added a sentence on this in the captions to clarify any confusion on this point.
Figures A1-8: what is the plot number for? Is that the code used by the plotter functions to make the plots?
Figures A1-8: These plots are automatic plots that the code can output if you run with an option for that. The plots are png-files that will be sorted in a folder according to user input, but the naming scheme for each specific plot will have a part according to the topic of the plot like forc, conc, em, ohc etc, For the forcing, concentration and emissions plot, there will be more than one plot, so the number will be the rest of the file name, so forc_1.png, forc_2.png and forc_3.png.
Citation: https://doi.org/10.5194/egusphere-2024-196-AC2
-
RC2: 'Comment on egusphere-2024-196', Anonymous Referee #2, 29 Apr 2024
The authors tried to provide a modified modeling framework, CICERO-SCM, based on Python. The authors argued that CICERO-SCM provides more flexibility than the previous Fortran version and generates comparable results with significantly reduced runtime. However, I think this paper needs to address some major issues to be properly reviewed for publication.
Major comments:
1. This paper is extremely confusing to read. First of all, the completeness of almost all the equation significantly lacks. These are examples:
- (Eq1) what is the unit of Aoc
- (Eq2) what is Kg here? what is the unit of the partial pressure of the slab ocean?
- (Eq3) where is F defined? where is equation 6b?
...
- (Eq7) δf npp (t) defines the instantaneous effect of plant productivity. So, what is its unit? How could "an effect" be part of an equation? All equations are supposed to deal with either mass, energy, or momentum conservation.
...
(Eq10) what is the unit of t? is it yearly?
...
(Eq20) E_ref is the function of E(t_ref) and E(t_0) and E is noted the emission of each aerosol species. Then is E_ref still the function of time (t)? If so, why the notation of E(t) is missing in LHS?
I can point out multiple flaws in each equation, which will make readers extremely frustrated. All the units in equations must be clarified, and the notations also must be consistent if they appear in multiple equations. Morever, I found that many sentences must be improved for better readability.
2. the authors compared time series between SCM and other models' outputs. However, the mechanistic explanation of each comparison is absent. For example, the authors might add some exciting explanation about the differences/similarities of the projected surface air temperature/heat content between SCM and others.
3. To my eye, a couple of things are not clear. First, the authors said that SCM provides more flexibility than Fortran. The authors need to clarify why their old Fortran SCM is less flexible than Python even though the Fortran should have a namelist to tune the parameters, and restart files especially. Second, this is a case of "calibration for calibration" Suppose, we get a set of parameters that represents well the trend of a targeted variable. Then, do the authors think the parameters are realistic? If not, I think the utility of this kind of simplified CM lies on doing sensitivity analysis. However, this paper does not show the SCM's usability for parameter sensitivity analysis.
Citation: https://doi.org/10.5194/egusphere-2024-196-RC2 -
AC1: 'Reply on RC2', Marit Sandstad, 27 May 2024
Dear Anonymous Referee #2,
Thank you for reading and commenting on our article. We are sorry that you found our manuscript confusing. We have tried to amend the manuscript to make it more readable. Below we will respond to each of your comments and outline how we have gone about improving the manuscript to solve the issues you point out. This will hopefully improve both the article and your opinion of it. We’ve added in your comments in italics between the various responses.
- This paper is extremely confusing to read. First of all, the completeness of almost all the equation significantly lacks.
Addressing your first point we have gone through all the equations to try to make sure they are more readable, making sure units and definitions are stated even for equations to which you have made no specific comment. Below we will answer all your specific comments and explain what we have changed in the text to clarify.
- (Eq1) what is the unit of Aoc
Eq1: A_oc is the the ocean area in m2. Thank you for pointing out the lack of units for this variable. We have now added that to the text
- (Eq2) what is Kg here? what is the unit of the partial pressure of the slab ocean?
Eq2: It’s perfectly understandable that you found this confusing, and we apologize for that. We’ve added the multiplication mark to clarify that kg is a coefficient to be multiplied with and not something like a function, we’ve also added its definition to the text.
- (Eq3) where is F defined? where is equation 6b?
Eq3: “F is the polynomial approximation given in equation 6b) of (Joos et al., 1996)” means that F is defined in the paper referred to Joos et al., 1996, in equation 6b of that paper. Hopefully this is possible to understand, however we’ve added the formulation as used in our model, which is the functional form at T=18.2 °C to make this clearer.
- (Eq7) δf npp (t) defines the instantaneous effect of plant productivity. So, what is its unit? How could "an effect" be part of an equation? All equations are supposed to deal with either mass, energy, or momentum conservation.
Eq 7: We’ve rewritten a bit on the δfnpp (t) to make it more readable, and included its unit.
(Eq10) what is the unit of t? is it yearly?
Eq 10. Yes, time is measured in years here, we’ve added that to the text.
(Eq20) E_ref is the function of E(t_ref) and E(t_0) and E is noted the emission of each aerosol species. Then is E_ref still the function of time (t)? If so, why the notation of E(t) is missing in LHS?
Eq 20: E(t) is a function of time. Eref is the result of subtracting the value of this function at two specific times (tref and t0) and is hence simply a number. We’ve added a little bit on the function E(t) in the text that hopefully clarifies this.
I can point out multiple flaws in each equation, which will make readers extremely frustrated. All the units in equations must be clarified, and the notations also must be consistent if they appear in multiple equations. Morever, I found that many sentences must be improved for better readability.
We understand that you have further comments under this point, but they have been mentioned generically and not as an exhaustive list of problems to address. To deal with this, we have gone over all equations to make sure all quantities are defined, and units are stated. We have also tried to make some other clarifications where we have seen the text might benefit. Hopefully this will make the equations and text not explicitly commented on more readable.
- the authors compared time series between SCM and other models' outputs. However, the mechanistic explanation of each comparison is absent. For example, the authors might add some exciting explanation about the differences/similarities of the projected surface air temperature/heat content between SCM and others.
We are not sure exactly what is meant by this comment. While we do make some comparisons with IPCC assessments and observational bounds, these are meant mainly to demonstrate that our model can reproduce such timeseries somewhat reasonably. The main point of an SCM like the CICERO-SCM is that it’s very fast, so you can produce results, assess scenarios, and recalibrate to tune to different datasets on a timeframe that is simply not feasible for something like an Earth system model. Also, we would like to emphasize that this is primarily a model description paper, and not a model assessment or comparison paper. Hence, we show results to demonstrate the model’s ability to produce relatively realistic results, and since this is a description of a ported model, to show that its results are consistent with its predecessor model.
- To my eye, a couple of things are not clear. First, the authors said that SCM provides more flexibility than Fortran. The authors need to clarify why their old Fortran SCM is less flexible than Python even though the Fortran should have a namelist to tune the parameters, and restart files especially.
- To address the point of flexibility compared to the Fortran model, we have tried to elaborate a bit more on this but want to respond a bit here too. Though one could tune a number of parameters in the Fortran model, the Python version has more tunable parameters, we have tried to make this clearer by explicitly listing which parameters were already tunable and which are now tunable that weren’t tunable before. For instance, the carbon cycle model was previously completely fixed. In addition, the old Fortran model required a separate compiled version each to perform a run driven from emissions, compared to one driven from concentrations, compared to one where all non-CO2 greenhouse gases from concentrations. The porting of the code to Python has also separated more functionally different parts of the code into modules and smaller methods which are easier to further edit and change for new developers. Making the code publicly available, buildable as a module, installable as a library through the widely used library tool pip and equipping it with testing functionality also makes further improvements with continued trust in the results. Whilst elements of this can be done whilst keeping the code FORTRAN based, we do not have that level of FORTRAN competence and we also believe the broader community has a higher level of competence in Python. We wager that the number of people who will easily be able to interact with the Python based code described in this article, is significantly larger than the number that would have been able to do so if we shared an open version of the FORTRAN code.
Second, this is a case of "calibration for calibration" Suppose, we get a set of parameters that represents well the trend of a targeted variable. Then, do the authors think the parameters are realistic? If not, I think the utility of this kind of simplified CM lies on doing sensitivity analysis. However, this paper does not show the SCM's usability for parameter sensitivity analysis.
The calibration finds parameter values which faithfully reproduce the output data given the model structure. If the model structure is wrong, and the output is still reduced, then the parameters would implicitly compensate for any structural errors. It is reasonable to argue that the parameter set strictly makes sense for the model structure at hand: eg, the vertical diffusivity may change depending on the numbers of layers in the ocean. However, the model is shown to be able to produce a broad range of outputs for various inputs, for a given calibration, indicating that the model-parameter combinations are realistic. In any case, the model is sufficiently fast, that it is easy to perform sensitivity analysis or different calibrations and assessments of the parameter space. This is in essence the point of developing simple climate models.
To the point of sensitivity analysis, previous work has calibrated the upwelling diffusion model parameters and radiative forcing values to observed temperatures and storage of heat in the ocean (REF Skeie 2014,2018). A main limitation to the simplified calibration outlined in the manuscript and the previous work is the large uncertainties in the temporal development of the aerosol forcing (Skeie et al 2018) that we are not able to capture and constrain. Future work should address this, and a SCM is a suitable tool for such investigations. In addition, the run speed of a model such as this makes it extremely useful in future projections when large numbers of projections need to be assessed. By calibrating parameter sets to some set of observables or ESM output, we can produce ensembles that spans some distribution, and which produces global results that are consistent with observations or ESM, which in turn can be applied to very large numbers of future projections, such as the AR6 WGIII scenario database. Assessing large numbers of scenarios including ensembles to span a distribution of outcomes using full Earth System Models, or even intermediate complexity models, is unfeasible. Of course this could also be done with a pure emulation approach, but pure emulation does not provide a simplified mechanistic approach that can allow us to assess several variables simultaneously or extrapolate outside of the ensemble space. The reviewer is of course in their full right to see no or dubious value in this, if so, we are unsure whether this paper can remedy this while also fulfilling its own purpose of being a model description paper.
Citation: https://doi.org/10.5194/egusphere-2024-196-AC1
-
AC1: 'Reply on RC2', Marit Sandstad, 27 May 2024
Interactive discussion
Status: closed
-
RC1: 'Comment on egusphere-2024-196', Anonymous Referee #1, 09 Apr 2024
In this manuscript, the authors present a new version of the CICERO-SCM, an open-source simple climate model. The authors had two main objectives: (1) to describe and document the model and (2) to present some application of CICERO-SCM. The authors presented a thorough description of the model, its implementation, and a few applications using CICERO-SCM however, I think the power of CICERO-SCM could be better demonstrated by including results from future scenarios. With minor revisions, this manuscript will be a nice addition to the RCM literature.
General Comments/Questions
- Translating the model implementations between different languages is no easy task! It seems that, at times, the authors are undervaluing this effort. Implementing the model in Python greatly increases model accessibility and readability, even if the model run time increases a bit, CICERO-SCM is still operating at a fraction of the runtime of an ESM. As it is currently written, it is unclear if/what scientific changes were made between V1.1.1 and the previous Fortran implementation.
- Figures 2, A3, A4, have the y-axis start at 0, which for some variables doesn’t seem necessary, and the scale of the y-axis makes it difficult to make examine the differences between CICERO-SCM and the comparison data. One idea would be for the authors to have a free y-axis that is not always start a 0 but near the minimum.
- It looks like there were some formatting issues, such as inconsistent spacing between paragraphs (e.g., L26, L112, L225.) and several citations incorrectly formatted inline citations (L24, L63, L189). These sorts of things are easy to do and will be caught by the copy editor so minor in the grand scheme of things.
Specific Comments/Questions
L20: missing a space between eg and the citation
L45: excellent point!!
Figure 1: use subscripts in the chemical names
L96: “dictionary” is this a Python specific term?
Table 1: Sunvolc is this a boolean parameter? If is it set to 1 does that mean that inputs for sun and volcanic radiative forcing are both required? Or could a user provide only one?
L108: what is meant by tracer components here?
L120-123 : is a tad confusing, is the model only CO2-driven between 1750-1850? If so why? Or are there non-CO2 emissions during this period that are held constant? More details on which concentrations (the species and the time frame) are needed would be helpful here. Are the required concentrations user-defined?
L180 - 190: I am having a difficult time understanding equations 6-9 and I think it stems from some confusion related to f_fer and beta. What is the difference between f_fer and beta? Are they related in some way? Some more details here would be helpful. Is f_fer typically negative?
~L220: “ This implementation is appropriate for discrete input data only, where the emissions (and concentrations) are assumed constant throughout the year. For a timestep of less than one year…” what is the time step for CICERO-SCM? Can it run on a monthly time step? If it is running in with monthly inputs are all emission inputs needed to be monthly?
L244 : Equation 9, would it be possible to add a subscript to the parameters to indicate which parameters vary with the gas species?
L240: missing a space between “CH4is”
Section started at L220: Here in 2.1.3 CH4 - emissions to concentrations, the authors describe how CICERO-SCM supports three different methods for calculating tau oh. Which option does CICERO-SCM use by default? What is the motivation for supporting these three different dynamics? Is this feature common in other SCMs? It seems like this is an opportunity for the authors to highlight one of CICERO’s unique features.
Figure 3: where did the uncertainty ribbon/envelop come from? Is it from IPCC AR6 or is it from an ensemble of CICERO runs?
L476: “twelve sub-yearly timesteps” like monthly? The discussion here and then also in L220 is confusing me. It would be helpful to have a clear discussion somewhere in the manuscript that addresses CICERO’s time step addressing the following
- If/what inputs can be sub-annual? What happens to the inputs that are not sub-annual?
- If there are sub-annual inputs, what time step? Monthly? Daily?
- How does using sub-annual inputs affect outputs?
L 494: It would be helpful to have some more details about many new tunable parameters. Are there like or 5 or 10 parameters? Are these parameters listed somewhere?
L499: “automatic tests including regression test to make sure the results from the energy balance model”, is a bit unclear, so it is this regression calculating the difference between current model behavior and the previous model behavior? What sort of regression tests are good enough to pass the automatic testing?
L 510: The change in run time seems minimal to me, yes is unfortunate but adopting Python greatly improves the readability and accessibility!
Figure 7: would it be possible to do a more robust comparison between CICERO output? Either plotting a and b on the same figure? Would is be possible to compare CICERO V1.1.1 results with the CICERO results included in AR6 7.SM.4? That could provide more evidence that the results did not change very much.
L525: Where does the parameter distribution set defined in the json-file come from? Is it generated with the calibration tools included in the CICERO repository? Would running the calibration tools result in a new set of parameters? Would the calibration tool work on any tunable parameter?
L 532: the phrase “larger the calibration space” is somewhat unclear, does this refer to the uncertainty space of the parameters? The number of parameters being tuned? The number of variables being compared? The length of the time series being used in comparison data?
L 560: Just a suggestion but I think you could drop the word significantly here…
L 575: “inclusion of temperature feedbacks into the carbon uptake” is that for the ocean carbon cycle? Or the terrestrial carbon cycle?
Caption of Figure A1: missing a space in “2014and”
Figures A1, A3, A6: Why is HCFC-123 constant at 0 over the entire period of the run?
Figures A1-8: what is the plot number for? Is that the code used by the plotter functions to make the plots?
Citation: https://doi.org/10.5194/egusphere-2024-196-RC1 -
AC2: 'Reply on RC1', Marit Sandstad, 27 May 2024
Dear Anonymous Referee #1,
Thank you for your thorough and comprehensive read and multiple helpful comments on our manuscript! Below we will try to respond to each of your specific comments and we have made amendments to our manuscript according to them. Your comments are added in Italics before each reply.
L20: missing a space between eg and the citation
Thank you, we have fixed this!
Figure 1: use subscripts in the chemical names
Figure 1: Thank you for pointing out the lack of subscript. We have updated the figure accordingly.
L96: “dictionary” is this a Python specific term?
L96: A dictionary is a data structure (in python, but also in other language) of unordered key-value pairs. We have tried to clarify this in the text and used the opportunity to elaborate a bit on what the output dictionary holds.
Table 1: Sunvolc is this a boolean parameter? If is it set to 1 does that mean that inputs for sun and volcanic radiative forcing are both required? Or could a user provide only one?
Table 1: The sunvolc parameter is not boolean, but this is mainly to conform with the previous Fortran implementation. There are default datafiles for both solar and volcanic forcing which will be used if the user does not supply data for them. The user can supply their own data for one or both of them, and if one or more of them are missing as inputs, while the sunvolc parameter is 1, whatever the user has not supplied will be taken from defaults. We have tried to elaborate a bit on this in the table.
L108: what is meant by tracer components here?
L108: Tracer components is simply a synonym for components, chemical species/components etc. We will change it to chemical components. Hopefully that is easier to understand.
L120-123 : is a tad confusing, is the model only CO2-driven between 1750-1850? If so why? Or are there non-CO2 emissions during this period that are held constant? More details on which concentrations (the species and the time frame) are needed would be helpful here. Are the required concentrations user-defined?
L120-123: This might be a bit cryptic indeed. The run is set up so that at nystart, the run start, concentrations are calculated from emissions for CO2, but for all other species concentrations are taken from prescribed user input concentrations. At emstart, the start year for emissions, concentrations for all other species will also be calculated from input emissions. We’ve tried to rewrite a bit to make this clearer.
L180 - 190: I am having a difficult time understanding equations 6-9 and I think it stems from some confusion related to f_fer and beta. What is the difference between f_fer and beta? Are they related in some way? Some more details here would be helpful. Is f_fer typically negative?
L180-190: Again, thank you for pointing out a confusing part of the text. We have tried to elaborate a bit so as to show that the f_fer is the result current fertilization added to time integrated decay of historical fertilization. This is related to the fertilization factor beta in that the current fertilization is calculated from the CO2 concentration using this fertilization factor according to equation 9. We’ve rewritten a bit around the equations in this whole sections to make things clearer, hopefully that helps.
~L220: “ This implementation is appropriate for discrete input data only, where the emissions (and concentrations) are assumed constant throughout the year. For a timestep of less than one year…” what is the time step for CICERO-SCM? Can it run on a monthly time step? If it is running in with monthly inputs are all emission inputs needed to be monthly?
~L220: Currently the model operates with only yearly input data but can handle volcanic forcing data on a monthly resolution. The carbon cycle is integrated using 24 sub yearly timesteps (where you can in principle run with a different number of sub yearly timesteps), and the upwelling diffusion model works with 12 sub yearly integration steps, for which varying monthly varying forcing could be used. However, the current model only takes in yearly data (barring volcanic forcing), and only outputs yearly data. If you wanted something else, it would need to be rewritten. We’ve tried to make this a bit clearer in the text now
L244: Equation 9, would it be possible to add a subscript to the parameters to indicate which parameters vary with the gas species?
L244: I assume this comment pertains to equations 10-14. Yes, that sounds like a good idea. We’ve tried to implement that.
L240: missing a space between “CH4is”
L240: Thank you, fixed!
Section started at L220: Here in 2.1.3 CH4 - emissions to concentrations, the authors describe how CICERO-SCM supports three different methods for calculating tau oh. Which option does CICERO-SCM use by default? What is the motivation for supporting these three different dynamics? Is this feature common in other SCMs? It seems like this is an opportunity for the authors to highlight one of CICERO’s unique features.
Section started at L220: Here in 2.1.3 CH4 - emissions to concentrations. We assume this pertains to section 2.1.3. The default lifetime mode for lifetime is TAR. This is pointed out by putting default in paranthesis, but we can see how that might be missed. The (actually 4) different methods of calculating the OH-lifetime can allow the user who is interested in methane specifically to run with different setup, highlighting this option is a good suggestion which we thank the reviewer for and which we have tried to implement in the updated version of the article.
Figure 3: where did the uncertainty ribbon/envelop come from? Is it from IPCC AR6 or is it from an ensemble of CICERO runs?
Figure 3: The uncertainty ribbon is from the IPCC ERF timeseries. We’ve tried to make this clearer in the caption now.
L476: “twelve sub-yearly timesteps” like monthly? The discussion here and then also in L220 is confusing me. It would be helpful to have a clear discussion somewhere in the manuscript that addresses CICERO’s time step addressing the following
If/what inputs can be sub-annual? What happens to the inputs that are not sub-annual?
If there are sub-annual inputs, what time step? Monthly? Daily?
How does using sub-annual inputs affect outputs?
L476: Thank you for pointing out the confusion related to various time steps and resolutions. We’ve now added a few sentences to the introduction to clarify a bit on both temporal and spatial resolution. In general, you can say that the model is yearly and global, though certain parts of the model have sub yearly timesteps to provide a more accurate numerical solution to the differential equations it solves. Only in the upwelling_diffusion_model and for forcing does this translate to an option to input monthly data.
L 494: It would be helpful to have some more details about many new tunable parameters. Are there like or 5 or 10 parameters? Are these parameters listed somewhere?
L494: We’ve now added a listing of tunable parameters from the previous version and the current one. We’ve also added a bit more on the increased flexibility of the new version.
L499: “automatic tests including regression test to make sure the results from the energy balance model”, is a bit unclear, so it is this regression calculating the difference between current model behavior and the previous model behavior? What sort of regression tests are good enough to pass the automatic testing?
L499 We’ve now elaborated on this.
L 510: The change in run time seems minimal to me, yes is unfortunate but adopting Python greatly improves the readability and accessibility!
L510: We also think this is a price worth paying for readability, however, speed is useful, so we would still like to improve the speed of the code if we can.
Figure 7: would it be possible to do a more robust comparison between CICERO output? Either plotting a and b on the same figure? Would is be possible to compare CICERO V1.1.1 results with the CICERO results included in AR6 7.SM.4? That could provide more evidence that the results did not change very much.
Figure 7: We’ve added a third panel to the plot where results for a single scenario is shown for both versions alongside the observations. Hopefully this makes the comparison easier.
L525: Where does the parameter distribution set defined in the json-file come from? Is it generated with the calibration tools included in the CICERO repository? Would running the calibration tools result in a new set of parameters? Would the calibration tool work on any tunable parameter?
L525: You can use the calibration tool to create a json-file defining a parameter ensemble, but you can also generate or have the json file from elsewhere. For instance, we have a json-file of the parameter-ensemble used in the AR6 process which we’ve used to do the runs shown in figure 7. You can use the calibration tool to generate new parameter set, and yes, you can use the calibration tools to tune whichever tunable parameter you want. We’ve expanded this a bit to clarify.
L 532: the phrase “larger the calibration space” is somewhat unclear, does this refer to the uncertainty space of the parameters? The number of parameters being tuned? The number of variables being compared? The length of the time series being used in comparison data?
L 532: By calibration space we mean both the width and dimensionality of the prior parameter space, i.e. both the number of parameters to fit and the range of their priors. We’ve added a bit to clarify this.
L 560: Just a suggestion but I think you could drop the word significantly here…
L560: We are happy to accept this suggestion.
L 575: “inclusion of temperature feedbacks into the carbon uptake” is that for the ocean carbon cycle? Or the terrestrial carbon cycle?
L575: This comment relates to both the oceanic and terrestrial carbon cycle, none of which currently have temperature feedbacks. In practice, it might also be interesting to have feedbacks to just one of the two, but both are valid options to consider for a carbon cycle update of the model.
Caption of Figure A1: missing a space in “2014and”
Caption of Figure A1: Thank you for pointing out the missing space. We’ve fixed this now.
Figures A1, A3, A6: Why is HCFC-123 constant at 0 over the entire period of the run?
Figures A1, A3, A6: Good catch. The reason is simply that the input we used didn’t have any data for HCFC-123, and hence we ran with zero emissions for this gas throughout. We’ve added a sentence on this in the captions to clarify any confusion on this point.
Figures A1-8: what is the plot number for? Is that the code used by the plotter functions to make the plots?
Figures A1-8: These plots are automatic plots that the code can output if you run with an option for that. The plots are png-files that will be sorted in a folder according to user input, but the naming scheme for each specific plot will have a part according to the topic of the plot like forc, conc, em, ohc etc, For the forcing, concentration and emissions plot, there will be more than one plot, so the number will be the rest of the file name, so forc_1.png, forc_2.png and forc_3.png.
Citation: https://doi.org/10.5194/egusphere-2024-196-AC2
-
RC2: 'Comment on egusphere-2024-196', Anonymous Referee #2, 29 Apr 2024
The authors tried to provide a modified modeling framework, CICERO-SCM, based on Python. The authors argued that CICERO-SCM provides more flexibility than the previous Fortran version and generates comparable results with significantly reduced runtime. However, I think this paper needs to address some major issues to be properly reviewed for publication.
Major comments:
1. This paper is extremely confusing to read. First of all, the completeness of almost all the equation significantly lacks. These are examples:
- (Eq1) what is the unit of Aoc
- (Eq2) what is Kg here? what is the unit of the partial pressure of the slab ocean?
- (Eq3) where is F defined? where is equation 6b?
...
- (Eq7) δf npp (t) defines the instantaneous effect of plant productivity. So, what is its unit? How could "an effect" be part of an equation? All equations are supposed to deal with either mass, energy, or momentum conservation.
...
(Eq10) what is the unit of t? is it yearly?
...
(Eq20) E_ref is the function of E(t_ref) and E(t_0) and E is noted the emission of each aerosol species. Then is E_ref still the function of time (t)? If so, why the notation of E(t) is missing in LHS?
I can point out multiple flaws in each equation, which will make readers extremely frustrated. All the units in equations must be clarified, and the notations also must be consistent if they appear in multiple equations. Morever, I found that many sentences must be improved for better readability.
2. the authors compared time series between SCM and other models' outputs. However, the mechanistic explanation of each comparison is absent. For example, the authors might add some exciting explanation about the differences/similarities of the projected surface air temperature/heat content between SCM and others.
3. To my eye, a couple of things are not clear. First, the authors said that SCM provides more flexibility than Fortran. The authors need to clarify why their old Fortran SCM is less flexible than Python even though the Fortran should have a namelist to tune the parameters, and restart files especially. Second, this is a case of "calibration for calibration" Suppose, we get a set of parameters that represents well the trend of a targeted variable. Then, do the authors think the parameters are realistic? If not, I think the utility of this kind of simplified CM lies on doing sensitivity analysis. However, this paper does not show the SCM's usability for parameter sensitivity analysis.
Citation: https://doi.org/10.5194/egusphere-2024-196-RC2 -
AC1: 'Reply on RC2', Marit Sandstad, 27 May 2024
Dear Anonymous Referee #2,
Thank you for reading and commenting on our article. We are sorry that you found our manuscript confusing. We have tried to amend the manuscript to make it more readable. Below we will respond to each of your comments and outline how we have gone about improving the manuscript to solve the issues you point out. This will hopefully improve both the article and your opinion of it. We’ve added in your comments in italics between the various responses.
- This paper is extremely confusing to read. First of all, the completeness of almost all the equation significantly lacks.
Addressing your first point we have gone through all the equations to try to make sure they are more readable, making sure units and definitions are stated even for equations to which you have made no specific comment. Below we will answer all your specific comments and explain what we have changed in the text to clarify.
- (Eq1) what is the unit of Aoc
Eq1: A_oc is the the ocean area in m2. Thank you for pointing out the lack of units for this variable. We have now added that to the text
- (Eq2) what is Kg here? what is the unit of the partial pressure of the slab ocean?
Eq2: It’s perfectly understandable that you found this confusing, and we apologize for that. We’ve added the multiplication mark to clarify that kg is a coefficient to be multiplied with and not something like a function, we’ve also added its definition to the text.
- (Eq3) where is F defined? where is equation 6b?
Eq3: “F is the polynomial approximation given in equation 6b) of (Joos et al., 1996)” means that F is defined in the paper referred to Joos et al., 1996, in equation 6b of that paper. Hopefully this is possible to understand, however we’ve added the formulation as used in our model, which is the functional form at T=18.2 °C to make this clearer.
- (Eq7) δf npp (t) defines the instantaneous effect of plant productivity. So, what is its unit? How could "an effect" be part of an equation? All equations are supposed to deal with either mass, energy, or momentum conservation.
Eq 7: We’ve rewritten a bit on the δfnpp (t) to make it more readable, and included its unit.
(Eq10) what is the unit of t? is it yearly?
Eq 10. Yes, time is measured in years here, we’ve added that to the text.
(Eq20) E_ref is the function of E(t_ref) and E(t_0) and E is noted the emission of each aerosol species. Then is E_ref still the function of time (t)? If so, why the notation of E(t) is missing in LHS?
Eq 20: E(t) is a function of time. Eref is the result of subtracting the value of this function at two specific times (tref and t0) and is hence simply a number. We’ve added a little bit on the function E(t) in the text that hopefully clarifies this.
I can point out multiple flaws in each equation, which will make readers extremely frustrated. All the units in equations must be clarified, and the notations also must be consistent if they appear in multiple equations. Morever, I found that many sentences must be improved for better readability.
We understand that you have further comments under this point, but they have been mentioned generically and not as an exhaustive list of problems to address. To deal with this, we have gone over all equations to make sure all quantities are defined, and units are stated. We have also tried to make some other clarifications where we have seen the text might benefit. Hopefully this will make the equations and text not explicitly commented on more readable.
- the authors compared time series between SCM and other models' outputs. However, the mechanistic explanation of each comparison is absent. For example, the authors might add some exciting explanation about the differences/similarities of the projected surface air temperature/heat content between SCM and others.
We are not sure exactly what is meant by this comment. While we do make some comparisons with IPCC assessments and observational bounds, these are meant mainly to demonstrate that our model can reproduce such timeseries somewhat reasonably. The main point of an SCM like the CICERO-SCM is that it’s very fast, so you can produce results, assess scenarios, and recalibrate to tune to different datasets on a timeframe that is simply not feasible for something like an Earth system model. Also, we would like to emphasize that this is primarily a model description paper, and not a model assessment or comparison paper. Hence, we show results to demonstrate the model’s ability to produce relatively realistic results, and since this is a description of a ported model, to show that its results are consistent with its predecessor model.
- To my eye, a couple of things are not clear. First, the authors said that SCM provides more flexibility than Fortran. The authors need to clarify why their old Fortran SCM is less flexible than Python even though the Fortran should have a namelist to tune the parameters, and restart files especially.
- To address the point of flexibility compared to the Fortran model, we have tried to elaborate a bit more on this but want to respond a bit here too. Though one could tune a number of parameters in the Fortran model, the Python version has more tunable parameters, we have tried to make this clearer by explicitly listing which parameters were already tunable and which are now tunable that weren’t tunable before. For instance, the carbon cycle model was previously completely fixed. In addition, the old Fortran model required a separate compiled version each to perform a run driven from emissions, compared to one driven from concentrations, compared to one where all non-CO2 greenhouse gases from concentrations. The porting of the code to Python has also separated more functionally different parts of the code into modules and smaller methods which are easier to further edit and change for new developers. Making the code publicly available, buildable as a module, installable as a library through the widely used library tool pip and equipping it with testing functionality also makes further improvements with continued trust in the results. Whilst elements of this can be done whilst keeping the code FORTRAN based, we do not have that level of FORTRAN competence and we also believe the broader community has a higher level of competence in Python. We wager that the number of people who will easily be able to interact with the Python based code described in this article, is significantly larger than the number that would have been able to do so if we shared an open version of the FORTRAN code.
Second, this is a case of "calibration for calibration" Suppose, we get a set of parameters that represents well the trend of a targeted variable. Then, do the authors think the parameters are realistic? If not, I think the utility of this kind of simplified CM lies on doing sensitivity analysis. However, this paper does not show the SCM's usability for parameter sensitivity analysis.
The calibration finds parameter values which faithfully reproduce the output data given the model structure. If the model structure is wrong, and the output is still reduced, then the parameters would implicitly compensate for any structural errors. It is reasonable to argue that the parameter set strictly makes sense for the model structure at hand: eg, the vertical diffusivity may change depending on the numbers of layers in the ocean. However, the model is shown to be able to produce a broad range of outputs for various inputs, for a given calibration, indicating that the model-parameter combinations are realistic. In any case, the model is sufficiently fast, that it is easy to perform sensitivity analysis or different calibrations and assessments of the parameter space. This is in essence the point of developing simple climate models.
To the point of sensitivity analysis, previous work has calibrated the upwelling diffusion model parameters and radiative forcing values to observed temperatures and storage of heat in the ocean (REF Skeie 2014,2018). A main limitation to the simplified calibration outlined in the manuscript and the previous work is the large uncertainties in the temporal development of the aerosol forcing (Skeie et al 2018) that we are not able to capture and constrain. Future work should address this, and a SCM is a suitable tool for such investigations. In addition, the run speed of a model such as this makes it extremely useful in future projections when large numbers of projections need to be assessed. By calibrating parameter sets to some set of observables or ESM output, we can produce ensembles that spans some distribution, and which produces global results that are consistent with observations or ESM, which in turn can be applied to very large numbers of future projections, such as the AR6 WGIII scenario database. Assessing large numbers of scenarios including ensembles to span a distribution of outcomes using full Earth System Models, or even intermediate complexity models, is unfeasible. Of course this could also be done with a pure emulation approach, but pure emulation does not provide a simplified mechanistic approach that can allow us to assess several variables simultaneously or extrapolate outside of the ensemble space. The reviewer is of course in their full right to see no or dubious value in this, if so, we are unsure whether this paper can remedy this while also fulfilling its own purpose of being a model description paper.
Citation: https://doi.org/10.5194/egusphere-2024-196-AC1
-
AC1: 'Reply on RC2', Marit Sandstad, 27 May 2024
Peer review completion
Journal article(s) based on this preprint
Viewed
| HTML | XML | Total | BibTeX | EndNote | |
|---|---|---|---|---|---|
| 641 | 191 | 46 | 878 | 27 | 22 |
- HTML: 641
- PDF: 191
- XML: 46
- Total: 878
- BibTeX: 27
- EndNote: 22
Viewed (geographical distribution)
| Country | # | Views | % |
|---|
| Total: | 0 |
| HTML: | 0 |
| PDF: | 0 |
| XML: | 0 |
- 1
Marit Sandstad
Borgar Aamaas
Ane Nordlie Johansen
Marianne Tronstad Lund
Glen Peters
Bjørn Hallvard Samset
Benjamin M. Sanderson
Ragnhild Bieltvedt Skeie
The requested preprint has a corresponding peer-reviewed final revised paper. You are encouraged to refer to the final revised version.
- Preprint
(3193 KB) - Metadata XML