the Creative Commons Attribution 4.0 License.
the Creative Commons Attribution 4.0 License.
| 12 Aug 2025
Review of climate simulation by simple climate models
Abstract. Simple Climate Models (SCMs) are a key tool in climate research, enabling the rapid exploration of climate responses beyond the reach of more complex models and aiding in the estimation of future climate uncertainty. Over the past two decades, the number and diversity of SCMs have expanded considerably, increasing their use but also complicating efforts to understand differences in model structure and their implications. The reduced-complexity model intercomparison project (RCMIP) has begun to address this challenge by comparing output from a wide range of SCMs. However, the need for a systematic analysis of model structure remains. Here, we complement RCMIP’s work by systematically analysing the structure, components, and development histories of the 14 SCMs participating in RCMIP. We begin with a summary of the core principles underpinning SCM-based climate simulation, then review genealogy and design choices of each model. This synthesis provides a comprehensive reference for both developers and users, clarifying the diverse approaches within the SCM landscape and supporting informed use and further development of these models.
-
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
(1058 KB)
-
The requested preprint has a corresponding peer-reviewed final revised paper. You are encouraged to refer to the final revised version.
- Preprint
(1058 KB) - Metadata XML
- BibTeX
- EndNote
- Final revised paper
Journal article(s) based on this preprint
Interactive discussion
Status: closed
-
RC1: 'Comment on egusphere-2025-2691', Anonymous Referee #1, 06 Sep 2025
Simple Climate Models (SCMs) make up a critical component of the climate model hierarchy and have been used for decades for climate assessment. Although many SCMs with varying levels of complexity exist, there have been few efforts to clarify differences in model structure. In this work, the authors review the 14 SCMs participating in the reduced-complexity model intercomparison project (RCMIP), organizing them by increasing complexity and creating a guide for developers and users.
Overall, this is a strong manuscript with a clear contribution in providing a comprehensive overview of some of the most widely used SCMs. The methodological choices of both which SCMs to include and what components to focus on (e.g. choosing structure over performance) are clear and sufficient. I have one major comment about the stated goals/conclusions of the manuscript. The rest of my questions/suggestions to improve the quality of the manuscript are relatively minor.
Specific Comments:
The paper aims to support informed use of SCMs, e.g. 1571-1572: “... while also informing about the implications of selecting one model over another.” While the detailed descriptions achieve this, the discussion could be strengthened by adding a paragraph that informs practical guidance for model selection. For example, you could briefly summarize which models are best suited for specific applications based on their features. This type of synthesis would make the paper’s thorough exploration of SCMs more accessible to the user community.
In a similar vein, there are points in the manuscript that explicitly address model advantages, but as a developer/user, I’d also love to see disadvantages/failure modes of these different models. Is there a consistent/rigorous way to define a failure mode of an SCM? If so, why have you chosen not to discuss them?
Minor:
- The historical overview of the field is comprehensive but ends somewhat abruptly around 2020, and doesn’t acknowledge the rapid rise in statistical/machine learning-based approaches. Since that isn’t the focus of the paper, it’s not a major issue, but a comprehensive review such as this should acknowledge the current state of the field.
- In a similar vein, climate emulators are referenced on line 23 in the introduction, but aren’t addressed again. For both this and the previous point consider the question: how would someone coming from the ML/emulator literature connect to your manuscript?
- 352: What is meant by ‘a higher number of layers provides the model with… an enhanced capability to reproduce non-linearities’? Unless I’m misunderstanding Equation 11 (please correct me if this is the case!), this is still a linear model, so what type of non-linearities do you mean?
- 366-367: “... they (IRFs) are not derived from fundamental physical principles but through mathematical approximations of the relationships we aim to model.” I’m not sure what is meant by this statement, as response functions are, by definition, the exact solution to the type of systems defined by Equations 9-11. You explicitly state this in lines 390-392 as well. The second statement implies they’re only approximations to the same extent that 9-11 are approximations as well. Can you be more precise in what you mean by the former statement?
- 418 (and elsewhere): the term ‘complexity’ is used with respect to models frequently, but without a rigorous definition. You seem to imply complexity is proportional to the number of physical processes represented, but can you clarify this against e.g. computational complexity?
- Figure 1: I don’t follow what ‘None’ means just from looking at the figure, consider clarifying this in the caption.
- Figure 5: Unclear what is meant by ‘Earth’ from just the figure, consider clarifying this in the figure or caption.
- You state on 250 that “...SARF should be assumed whenever radiative forcing is mentioned…”, this is probably worth highlighting in the caption for Table 2 for readers who are looking primarily at the figures/tables to summarize the review.
Technical Corrections:
- 16: ‘system’ should be capitalized
- 37: Typo - ‘downscalling’
- The signposting is very clear throughout, but inconsistent at times. E.g. The GREB signposting (4.6.X) doesn’t follow the same format as the other models.
- Some places 4.X.1 is labeled model ‘specification’ and others it’s ‘description’
- 241: Missing a second set of closing parentheses after LULCC? Also should the first letters be capitalized when the acronym is spelled out explicitly?
- 342: The ‘co2’ in the ‘1pctCO2’ experiment is typically capitalized. Consider italicizing experiment names as well to make it clear they’re separate from the models.
- 680: Typo - ‘continuos’.
- 833: Same citation listed twice.
- 941: Units are typically not italicized (should ppm be ppm?)
- Ensure consistent hyphenation of your acronyms, there’s at least one instance of “OML IRM” (no hyphen) on 1019
- 1511: Typo - ‘spacially’ (not sure if this is a valid alternate spelling, but you spell it ‘spatially’ on 1127)
- 1558: Missing word - “... a decision was made (to) exclude…”
- 1590: Typo - ‘reviwed’
Citation: https://doi.org/10.5194/egusphere-2025-2691-RC1 - AC2: 'Reply on RC1', Alejandro Romero-Prieto, 27 Nov 2025
-
CC1: 'Comment on egusphere-2025-2691', Marcus Sarofim, 25 Sep 2025
First: Kudos to the authors for pulling together a great review of existing reduced complexity model structures, components, and other factors. This will be very much appreciated by those of us who work with reduced complexity models.
Second: I have a couple minor comments:
Minor comment one regards this statement:
“Moreover, ESMs operate at finer scales, benefitting local and regional analysis, although downscalling approaches to generate regional climate emulators from SCMs have also been explored (Beusch et al., 2020; Mitchell, 2003; Mathison et al., 2025)”
I think this sentence, as written, is slightly misleading because most (all?) regional climate emulators depend on ESM data. All three cited approaches - Beusch et al (MESMER), Mitchell (pattern scaling), and Mathison et al. (PRIME) rely on ESM output in order to build their databases. I’d also recommend adding Tebaldi et al. (2022) (STITCHES) to your list of regional climate emulators (and which also relies on ESM data). Perhaps if the sentence was reframed as, “Moreover, ESMs operate at finer scales, benefitting local and regional analysis. Pattern scaling approaches that leverage ESM data to generate regional climate emulators, which can then be coupled with reduced complexity models to provide higher resolution functionality, have also been explored (citations).”
As a more general statement (and less relevant to this manuscript), I would like the ESM community to lean into the role of understanding the patterns of responses to forcing by running stylized scenarios (e.g., isolating GHG, aerosol, and land use change forcing components) rather than running scenarios produced by IAMs, which add complexity to comparing different scenarios as they differ on all 3 forcing types. Then, these various pattern scaling approaches could be coupled to reduced complexity models to project more realistic scenarios as well as important probabilistic assessments.
Minor comment two is that I would be interested in understanding in what fashion (if at all) box models and IRM approaches differ in terms of behavior. After looking at RCMIP and various other tests, I haven’t identified any fundamental differences between IRMs (as a class) and box models (as a class). Perhaps the discussion at lines 390-409 regarding mathematical equivalence is the answer to this question? If that’s true, maybe this equivalence could be emphasized even more.
Minor additional notes:
Typo: downscaling, not scalling
Figure 10 typo: atmopshere should be atmosphere
Citation: https://doi.org/10.5194/egusphere-2025-2691-CC1 - AC3: 'Reply on CC1', Alejandro Romero-Prieto, 27 Nov 2025
-
RC2: 'Comment on egusphere-2025-2691', Paolo Giani, 24 Oct 2025
I personally enjoyed reading this comprehensive and ambitious review on SCMs. I believe it will serve as a valuable cornerstone for the field, particularly for newcomers from different disciplines. I especially appreciated the synthesis presented in Tables 1–4 and Figures 1–2, as well as the historical perspective provided on both the general development of SCMs and the evolution of individual models. The authors have reviewed an impressive amount of material with great thoroughness, and I really appreciate this effort. The balance between high-level discussion and technical detail is particularly well thought of – the level of detail is sufficient to provide clear context without overwhelming the reader. I only have a few clarifications/suggestions that I’m outlining here below:
- L37: “Downscalling” might be a typo
- L98: “rather than approximations”; this is a bit nitpicky, but I would argue that also SCMs are driven by fundamental laws of physics (e.g. mass balance, energy balance), except for perhaps purely regression-based models. The difference is that loss rates for chemical species and radiative transfer for heat are highly parameterized in SCMs (first-order kinetics, linear forcing-feedback for heat) but better resolved in ESMs.
- L305: I would stress here that lambda is arguably the most important parameter in this formulation, and that is a strong control on climate sensitivity (the central quantity in climate science). I think that is mentioned later, but I wonder if the casual reader would think at this stage that lambda is basically constrained by 4\sigma*T_0^3 ~ 5 W m-2 K-1, which is actually pretty far from the real feedback (~1 W m-2 K-1 for a climate sensitivity of ~3.5K). In your formulation, that means that tuning k is a really important step for any SCM. In other words, there are lot of things that happen in SCMs but perhaps the most consequential parameter to set in an EBM is lambda (and I would probably call out here that k would need to take into account all the important climate feedbacks such as water vapor, lapse rate, clouds, albedo… and that all of that complexity is swept under the number assigned to lambda).
- L352: not sure if I follow the “reproduce non-linearities” part. Even with n-layers Equation (11) is still a linear system of ODEs. I would also call out here that adding n boxes for the ocean does not alter the equilibrium solution, which is still F/k1 for all temperatures, because at equilibrium T1=T2=...=Tn. In other words, having n boxes allow for extra flexibility in setting the time scales of response (the “transient”), but not the final surface temperature equilibrium, which is set by forcing F and feedback k1 (using the notation of Equation 11)
- Table 4 and beyond: there are a lot of github links in Table 4, and other URLs across the paper that point to model websites. I see why this is very useful for the reader interested in the code, but I worry that in the relative near future (e.g. >5 years) some of those links might be broken since they are not “permanent” repositories. Since the paper is typically a stand alone contribution that lives in eternity (hopefully :)), I wonder if the temporary http links should be added as a separate supplement that says “current links” or something along those lines. On the other hand I do see the value of having the links there in the near-term; I just wanted to flag this as a potential issue thinking longer-term.
- I really enjoyed the summary info provided by Table 1-4 and Figure 1-2, and I appreciate the authors’ efforts to summarize a large amount of literature so effectively. I wonder if maybe having an additional column/table with (1) a typical use case where the SCM has been used and (2) a specific aspect of the model that distinguishes it from others could be useful for the reader to identify straight away what model they might be interested in. Or maybe a combination of (1) and (2). For example for OSCAR, that “peculiar” thing that distinguishes it from other models would be strong focus on LULCC and carbon cycle, and if a reader is interested in studying LULCC effects they would immediately know that OSCAR is probably the first thing to look at. For MAGICC that would be the long history and the strong use in IPCC. For GREB that would be the focus on “understanding” the climate system and university teaching. Just some food for thought – Not sure if that would play out well with all the models so feel free to disregard if not.
- L785: I would point out that GREB has the sensible/latent fluxes as explicit terms because they are looking at the surface energy balance, in contrast with all other models that are looking at the energy balance from the top-of-atmosphere (hence they only have radiative fluxes F and \lambda*T and no turbulent fluxes). In other words, the “flavor” of GREB’s EBM is quite different from the typical TOA EBMs that most SCMs use, despite still balancing energy fluxes.
- L832: I think Hartin (2015) is cited twice, might be a typo
- L1015: by “this publication” do you mean Meinshausen’s or your own article? Maybe that should be clarified since it could be interpreted as both.
- L1472: Not sure if I follow this part (not familiar with ESMICON) – “tracking the distribution of heat across the system” and “heat inventories” sound like an energy balance model to me (i.e., calculate fluxes in and out of predefined boxes…). I would also add that EBMs also include all the listed feedbacks (increased OLR, increase water vapor, clouds, etc.. they just do it through a lambda parameter). Can this idea of “heat inventory” be clarified if it is completely different than traditional EBMs? In this framework, how is a CO2 perturbation added if not through extra energy (radiative forcing)?
Citation: https://doi.org/10.5194/egusphere-2025-2691-RC2 - AC1: 'Reply on RC2', Alejandro Romero-Prieto, 27 Nov 2025
Interactive discussion
Status: closed
-
RC1: 'Comment on egusphere-2025-2691', Anonymous Referee #1, 06 Sep 2025
Simple Climate Models (SCMs) make up a critical component of the climate model hierarchy and have been used for decades for climate assessment. Although many SCMs with varying levels of complexity exist, there have been few efforts to clarify differences in model structure. In this work, the authors review the 14 SCMs participating in the reduced-complexity model intercomparison project (RCMIP), organizing them by increasing complexity and creating a guide for developers and users.
Overall, this is a strong manuscript with a clear contribution in providing a comprehensive overview of some of the most widely used SCMs. The methodological choices of both which SCMs to include and what components to focus on (e.g. choosing structure over performance) are clear and sufficient. I have one major comment about the stated goals/conclusions of the manuscript. The rest of my questions/suggestions to improve the quality of the manuscript are relatively minor.
Specific Comments:
The paper aims to support informed use of SCMs, e.g. 1571-1572: “... while also informing about the implications of selecting one model over another.” While the detailed descriptions achieve this, the discussion could be strengthened by adding a paragraph that informs practical guidance for model selection. For example, you could briefly summarize which models are best suited for specific applications based on their features. This type of synthesis would make the paper’s thorough exploration of SCMs more accessible to the user community.
In a similar vein, there are points in the manuscript that explicitly address model advantages, but as a developer/user, I’d also love to see disadvantages/failure modes of these different models. Is there a consistent/rigorous way to define a failure mode of an SCM? If so, why have you chosen not to discuss them?
Minor:
- The historical overview of the field is comprehensive but ends somewhat abruptly around 2020, and doesn’t acknowledge the rapid rise in statistical/machine learning-based approaches. Since that isn’t the focus of the paper, it’s not a major issue, but a comprehensive review such as this should acknowledge the current state of the field.
- In a similar vein, climate emulators are referenced on line 23 in the introduction, but aren’t addressed again. For both this and the previous point consider the question: how would someone coming from the ML/emulator literature connect to your manuscript?
- 352: What is meant by ‘a higher number of layers provides the model with… an enhanced capability to reproduce non-linearities’? Unless I’m misunderstanding Equation 11 (please correct me if this is the case!), this is still a linear model, so what type of non-linearities do you mean?
- 366-367: “... they (IRFs) are not derived from fundamental physical principles but through mathematical approximations of the relationships we aim to model.” I’m not sure what is meant by this statement, as response functions are, by definition, the exact solution to the type of systems defined by Equations 9-11. You explicitly state this in lines 390-392 as well. The second statement implies they’re only approximations to the same extent that 9-11 are approximations as well. Can you be more precise in what you mean by the former statement?
- 418 (and elsewhere): the term ‘complexity’ is used with respect to models frequently, but without a rigorous definition. You seem to imply complexity is proportional to the number of physical processes represented, but can you clarify this against e.g. computational complexity?
- Figure 1: I don’t follow what ‘None’ means just from looking at the figure, consider clarifying this in the caption.
- Figure 5: Unclear what is meant by ‘Earth’ from just the figure, consider clarifying this in the figure or caption.
- You state on 250 that “...SARF should be assumed whenever radiative forcing is mentioned…”, this is probably worth highlighting in the caption for Table 2 for readers who are looking primarily at the figures/tables to summarize the review.
Technical Corrections:
- 16: ‘system’ should be capitalized
- 37: Typo - ‘downscalling’
- The signposting is very clear throughout, but inconsistent at times. E.g. The GREB signposting (4.6.X) doesn’t follow the same format as the other models.
- Some places 4.X.1 is labeled model ‘specification’ and others it’s ‘description’
- 241: Missing a second set of closing parentheses after LULCC? Also should the first letters be capitalized when the acronym is spelled out explicitly?
- 342: The ‘co2’ in the ‘1pctCO2’ experiment is typically capitalized. Consider italicizing experiment names as well to make it clear they’re separate from the models.
- 680: Typo - ‘continuos’.
- 833: Same citation listed twice.
- 941: Units are typically not italicized (should ppm be ppm?)
- Ensure consistent hyphenation of your acronyms, there’s at least one instance of “OML IRM” (no hyphen) on 1019
- 1511: Typo - ‘spacially’ (not sure if this is a valid alternate spelling, but you spell it ‘spatially’ on 1127)
- 1558: Missing word - “... a decision was made (to) exclude…”
- 1590: Typo - ‘reviwed’
Citation: https://doi.org/10.5194/egusphere-2025-2691-RC1 - AC2: 'Reply on RC1', Alejandro Romero-Prieto, 27 Nov 2025
-
CC1: 'Comment on egusphere-2025-2691', Marcus Sarofim, 25 Sep 2025
First: Kudos to the authors for pulling together a great review of existing reduced complexity model structures, components, and other factors. This will be very much appreciated by those of us who work with reduced complexity models.
Second: I have a couple minor comments:
Minor comment one regards this statement:
“Moreover, ESMs operate at finer scales, benefitting local and regional analysis, although downscalling approaches to generate regional climate emulators from SCMs have also been explored (Beusch et al., 2020; Mitchell, 2003; Mathison et al., 2025)”
I think this sentence, as written, is slightly misleading because most (all?) regional climate emulators depend on ESM data. All three cited approaches - Beusch et al (MESMER), Mitchell (pattern scaling), and Mathison et al. (PRIME) rely on ESM output in order to build their databases. I’d also recommend adding Tebaldi et al. (2022) (STITCHES) to your list of regional climate emulators (and which also relies on ESM data). Perhaps if the sentence was reframed as, “Moreover, ESMs operate at finer scales, benefitting local and regional analysis. Pattern scaling approaches that leverage ESM data to generate regional climate emulators, which can then be coupled with reduced complexity models to provide higher resolution functionality, have also been explored (citations).”
As a more general statement (and less relevant to this manuscript), I would like the ESM community to lean into the role of understanding the patterns of responses to forcing by running stylized scenarios (e.g., isolating GHG, aerosol, and land use change forcing components) rather than running scenarios produced by IAMs, which add complexity to comparing different scenarios as they differ on all 3 forcing types. Then, these various pattern scaling approaches could be coupled to reduced complexity models to project more realistic scenarios as well as important probabilistic assessments.
Minor comment two is that I would be interested in understanding in what fashion (if at all) box models and IRM approaches differ in terms of behavior. After looking at RCMIP and various other tests, I haven’t identified any fundamental differences between IRMs (as a class) and box models (as a class). Perhaps the discussion at lines 390-409 regarding mathematical equivalence is the answer to this question? If that’s true, maybe this equivalence could be emphasized even more.
Minor additional notes:
Typo: downscaling, not scalling
Figure 10 typo: atmopshere should be atmosphere
Citation: https://doi.org/10.5194/egusphere-2025-2691-CC1 - AC3: 'Reply on CC1', Alejandro Romero-Prieto, 27 Nov 2025
-
RC2: 'Comment on egusphere-2025-2691', Paolo Giani, 24 Oct 2025
I personally enjoyed reading this comprehensive and ambitious review on SCMs. I believe it will serve as a valuable cornerstone for the field, particularly for newcomers from different disciplines. I especially appreciated the synthesis presented in Tables 1–4 and Figures 1–2, as well as the historical perspective provided on both the general development of SCMs and the evolution of individual models. The authors have reviewed an impressive amount of material with great thoroughness, and I really appreciate this effort. The balance between high-level discussion and technical detail is particularly well thought of – the level of detail is sufficient to provide clear context without overwhelming the reader. I only have a few clarifications/suggestions that I’m outlining here below:
- L37: “Downscalling” might be a typo
- L98: “rather than approximations”; this is a bit nitpicky, but I would argue that also SCMs are driven by fundamental laws of physics (e.g. mass balance, energy balance), except for perhaps purely regression-based models. The difference is that loss rates for chemical species and radiative transfer for heat are highly parameterized in SCMs (first-order kinetics, linear forcing-feedback for heat) but better resolved in ESMs.
- L305: I would stress here that lambda is arguably the most important parameter in this formulation, and that is a strong control on climate sensitivity (the central quantity in climate science). I think that is mentioned later, but I wonder if the casual reader would think at this stage that lambda is basically constrained by 4\sigma*T_0^3 ~ 5 W m-2 K-1, which is actually pretty far from the real feedback (~1 W m-2 K-1 for a climate sensitivity of ~3.5K). In your formulation, that means that tuning k is a really important step for any SCM. In other words, there are lot of things that happen in SCMs but perhaps the most consequential parameter to set in an EBM is lambda (and I would probably call out here that k would need to take into account all the important climate feedbacks such as water vapor, lapse rate, clouds, albedo… and that all of that complexity is swept under the number assigned to lambda).
- L352: not sure if I follow the “reproduce non-linearities” part. Even with n-layers Equation (11) is still a linear system of ODEs. I would also call out here that adding n boxes for the ocean does not alter the equilibrium solution, which is still F/k1 for all temperatures, because at equilibrium T1=T2=...=Tn. In other words, having n boxes allow for extra flexibility in setting the time scales of response (the “transient”), but not the final surface temperature equilibrium, which is set by forcing F and feedback k1 (using the notation of Equation 11)
- Table 4 and beyond: there are a lot of github links in Table 4, and other URLs across the paper that point to model websites. I see why this is very useful for the reader interested in the code, but I worry that in the relative near future (e.g. >5 years) some of those links might be broken since they are not “permanent” repositories. Since the paper is typically a stand alone contribution that lives in eternity (hopefully :)), I wonder if the temporary http links should be added as a separate supplement that says “current links” or something along those lines. On the other hand I do see the value of having the links there in the near-term; I just wanted to flag this as a potential issue thinking longer-term.
- I really enjoyed the summary info provided by Table 1-4 and Figure 1-2, and I appreciate the authors’ efforts to summarize a large amount of literature so effectively. I wonder if maybe having an additional column/table with (1) a typical use case where the SCM has been used and (2) a specific aspect of the model that distinguishes it from others could be useful for the reader to identify straight away what model they might be interested in. Or maybe a combination of (1) and (2). For example for OSCAR, that “peculiar” thing that distinguishes it from other models would be strong focus on LULCC and carbon cycle, and if a reader is interested in studying LULCC effects they would immediately know that OSCAR is probably the first thing to look at. For MAGICC that would be the long history and the strong use in IPCC. For GREB that would be the focus on “understanding” the climate system and university teaching. Just some food for thought – Not sure if that would play out well with all the models so feel free to disregard if not.
- L785: I would point out that GREB has the sensible/latent fluxes as explicit terms because they are looking at the surface energy balance, in contrast with all other models that are looking at the energy balance from the top-of-atmosphere (hence they only have radiative fluxes F and \lambda*T and no turbulent fluxes). In other words, the “flavor” of GREB’s EBM is quite different from the typical TOA EBMs that most SCMs use, despite still balancing energy fluxes.
- L832: I think Hartin (2015) is cited twice, might be a typo
- L1015: by “this publication” do you mean Meinshausen’s or your own article? Maybe that should be clarified since it could be interpreted as both.
- L1472: Not sure if I follow this part (not familiar with ESMICON) – “tracking the distribution of heat across the system” and “heat inventories” sound like an energy balance model to me (i.e., calculate fluxes in and out of predefined boxes…). I would also add that EBMs also include all the listed feedbacks (increased OLR, increase water vapor, clouds, etc.. they just do it through a lambda parameter). Can this idea of “heat inventory” be clarified if it is completely different than traditional EBMs? In this framework, how is a CO2 perturbation added if not through extra energy (radiative forcing)?
Citation: https://doi.org/10.5194/egusphere-2025-2691-RC2 - AC1: 'Reply on RC2', Alejandro Romero-Prieto, 27 Nov 2025
Peer review completion
Journal article(s) based on this preprint
Viewed
| HTML | XML | Total | BibTeX | EndNote | |
|---|---|---|---|---|---|
| 2,149 | 383 | 39 | 2,571 | 32 | 39 |
- HTML: 2,149
- PDF: 383
- XML: 39
- Total: 2,571
- BibTeX: 32
- EndNote: 39
Viewed (geographical distribution)
| Country | # | Views | % |
|---|
| Total: | 0 |
| HTML: | 0 |
| PDF: | 0 |
| XML: | 0 |
- 1
Alejandro Romero-Prieto
Camilla Mathison
Chris Smith
The requested preprint has a corresponding peer-reviewed final revised paper. You are encouraged to refer to the final revised version.
- Preprint
(1058 KB) - Metadata XML