the Creative Commons Attribution 4.0 License.
the Creative Commons Attribution 4.0 License.
| 31 Aug 2026
Ent Köppen-Geiger v1.0, a software tool for generating Earth System Model global vegetation boundary conditions for alternative climates
Abstract. We used the Köppen-Geiger biome-climate classification scheme to produce a software tool for predicting global maps of vegetation boundary conditions (VBCs) (soil and plant type cover fractions, canopy heights, annual maximum and monthly leaf area index) for Earth System Model (ESM) simulations of vegetation-atmosphere coupling in alternative climates. A modern Köppen-Geiger biome map derived from observed mean monthly climatology (2001–2010) was used as a mask to characterize statistics of contemporaneous satellite-observed VBCs categorized into the 12 plant functional types (PFTs) of the Ent Terrestrial Biosphere Model. A lookup table (LUT) of these VBCs was then constructed tabulating VBCs for each Köppen-Geiger class. For paleo-vegetation back to the Cretaceous, additional algorithms were designed to replace grasses and deciduous trees with time-relevant cover types. To evaluate the efficacy of the lookup table and paleo-vegetation algorithms, we conducted both modern and Cretaceous climate simulations with the NASA Goddard Institute for Space Studies ESM ModelE-2.1 and its generalized planetary version. Climate simulations for the modern, 2001–2010, using the LUT-generated VBCs showed simulated climate to have no significant difference from using the original satellite-derived VBCs. For the Cretaceous Thermal Maximum, given a preliminary simulated climate having bare soil for the land surfaces, predicted maps of cover types largely capture the vegetation type patterns compared to fossil reconstructions, while reflecting a high latitude cold bias of the simulated climate. The "Ent Köppen-Geiger" v1.0 software tool is made available for community updates and studies with asynchronous vegetation-climate model coupling for past to future climates.
- Preprint
(2442 KB) - Metadata XML
-
Supplement
(71738 KB) - BibTeX
- EndNote
Status: open (until 03 Nov 2026)
-
CEC1: 'Comment on egusphere-2026-4262 - No compliance with the policy of the journal', Juan Antonio Añel, 22 Sep 2026
reply
-
AC1: 'Reply on CEC1', Nancy Kiang, 22 Sep 2026
reply
We can change the section named "Data sets and codes" to "Codes and data availability".
Could you please clarify why Zenodo is not considered an appropriate repository? Are you looking at the last version of the manuscript that was approved by one of your editors for submission? It contained in that section: "The data sets and scripts for generating the Köppen-Geiger-based lookup tables of VBCs are archived at zenodo.org, doi: 10.5281/zenodo.17917285 (Kiang et al., 2026). "
All codes and data sets necessary to reproduce the paper results are in that Zenodo link, with README files on what packages of R and python to install.
Citation: https://doi.org/10.5194/egusphere-2026-4262-AC1 -
AC2: 'Reply on AC1', Nancy Kiang, 22 Sep 2026
reply
In addition, all codes in that Zenodo link can be used by any user to apply for their own purposes. Is it user-ready.
Citation: https://doi.org/10.5194/egusphere-2026-4262-AC2 -
CEC2: 'Reply on AC1', Juan Antonio Añel, 23 Sep 2026
reply
Dear authors,
Unfortunately, your reply does not address the outstanding issues. The Zenodo repository that you have provided does not contain essential code and data used in your work, or at least I have not found it there. For example, it does not include the exact version of the NASA GISS model used, neither the ERA5 data. Also, the NASA sites that you cite in your document to get access to the data are not acceptable repositories according to the policy of the journal.
Juan A. Añel
Geosci. Model Dev. Executive Editor
Citation: https://doi.org/10.5194/egusphere-2026-4262-CEC2 -
AC3: 'Reply on CEC2', Nancy Kiang, 23 Sep 2026
reply
These are the items in Zenodo that you are looking for:
S11_ModelE_code_rundecks.tar.gz - The NASA GISS ESM ModelE codes and rundecks used.
S12_ROCKE3D_code_rundeck.tar.gz - The ROCKE-3D codes and rundeck used.
They appear for me when I search on "doi: 10.5281/zenodo.17917285" that was given in the manuscript:
Citation: https://doi.org/10.5194/egusphere-2026-4262-AC3 -
AC4: 'Reply on AC3', Nancy Kiang, 23 Sep 2026
reply
I see we neglected to include the ERA5 data. However, these data are publicly available. Do you still need up to upload those data?
Citation: https://doi.org/10.5194/egusphere-2026-4262-AC4 -
CEC3: 'Reply on AC4', Juan Antonio Añel, 23 Sep 2026
reply
Dear authors,
First of all, I would like to ask you to do not use the Discussions system to post several independent replies to the same comment, which complicate the process of evaluating the situation with your manuscript. It would be good if you could post a single reply addressing all the issues raised in a comment.
Regarding the NASA GISS model code: Thanks for pointing to the right file containing it. From the documentation you shared it was not obvious that the repository contained it, but I can confirm that it is included, and therefore the lack of the GISS model code is not an issue for lack of compliance with the code policy of the journal. However, I would encourage you to curate a new version of the repository where the file names and the documentation clearly reflect what is contained there, and to share strictly only the material necessary to comply with the policy of the journal. Please, be aware that the material shared is for evaluation, and therefore, as other parts of your work (as the manuscript) have to be adequately presented, and easy to assess.
Regarding the ERA5 data, I think that the policy of the journal (I would like to refer you to it again) makes clear that all the code and data necessary to replicate a manuscript must be published in acceptable repositories at the submission time. I would like to request you to double-check if your submission complies with this requirement. Here you do not provide one for the ERA5 data, and the sites serving ERA5 data, such as the Copernicus Data Store are not valid repositories, but services to provide data which do not ensure long-term availability. Therefore, you need to provide a repository containing the specific ERA5 data you have used.
Also, the sites that you cite under NASA servers do not comply with our policy, and do not serve the purpose of the code and data policy of the journal to ensure long-term replicability and provenance of the results presented. Therefore, for essential documentation necessary to replicate your work, you should include it in repositories that we can accept. That said, GMD's policy does not enforce sharing documentation related to the code presented.
I hope this helps.
Juan A. Añel
Geosci. Model Dev. Executive Editor
Citation: https://doi.org/10.5194/egusphere-2026-4262-CEC3 -
AC6: 'Reply on CEC3', Nancy Kiang, 23 Sep 2026
reply
Dear Editor,
Regarding finding the codes and data in the Supplementary Material, the first document, S1_Köppen-Geiger VBCs_SupplementaryMaterial_2026-07-14.pdf, was provided as a guide to all of the Supplementary Material. It contains a listing of all of the file names, S1*, S2*, ...S13*, and their contents. Also, the Supplementary Material file names are fairly explicit in what their contents are, e.g. S11_ModelE_code_rundecks.tar.gz contains the ModelE code and rundecks. If S1_Köppen-Geiger VBCs_SupplementaryMaterial_2026-07-14.pdf is not clear, please let us know how it can be made more clear.
Regarding mention of the NASA data portal, we cannot find any mention of this in the manuscript. If you are seeing it mentioned there, could you please paste that sentence here so that we can locate it and remove it. In S1_Köppen-Geiger VBCs_SupplementaryMaterial_2026-07-14.pdf, it is stated that the data are available in two (2) places, one of which is Zenodo, which is a valid repository, as well as the NASA data portal. Therefore, the reader always has access to a valid repository. Do you still need us to remove all mention of the NASA repository in S1?
Regarding the ERA5 data, this is the only item missing, correct? Please let us know our exact next steps to rectify our submission:
If no change is needed to the current Zenodo material, only the addition of the ERA5 data, shall we create a new Zenodo submission of the entire complete Supplementary Material under a new doi? Or shall we retain the current Zenodo submission and create just a new one for the ERA5 data only under another doi?
For the manuscript, shall we submit a revision with an update to the Zenodo citation(s)?
Citation: https://doi.org/10.5194/egusphere-2026-4262-AC6 -
AC7: 'Reply on CEC3', Nancy Kiang, 02 Oct 2026
reply
Dear Editor,
We have uploaded an updated version of the Supplementary Material (SM) to a new Zenodo.org doi: 10.5281/zenodo.23021770, accessible through this link:
https://zenodo.org/records/23021770
This revised Supplementary Material contains the following changes to the previous Zenodo.org archive:
S1_Köppen-Geiger VBCs_SupplementaryMaterial_2026-10-02.pdf is revised to have a more helpful Table of Contents listing all file names in the SM and with improved descriptive section headings. The mention of the NASA data portal has been removed, except as optional for files in S9_kglut_data.tar.gz where the same data are provided in the Zenodo archive. Therefore, the user always has access to the Zenodo repository for these files.
S11_ModelE_code_rundecks_inputs.tar.gz has, in addition to the code and rundeck that were previously provided, added all boundary condition input files (e.g. topography, aerosols, greenhouse gases, etc.) needed to run the model besides the vegetation boundary condition (VBC) files that were generated by the EntKGLUT tool, which were provided in S10_kglut_fc9fd9b_2025-07-14.tar.gz.
S12_ROCKE3D_code_rundeck_inputs.tar.gz has,in addition to the code and rundeck that were previously provided, added all boundary condition input files (e.g. topography, aerosols, greenhouse gases, etc.) needed to run the model besides the vegetation boundary condition (VBC) files that were generated by the EntKGLUT tool, which were provided in S10_kglut_fc9fd9b_2025-07-14.tar.gz.
S15_ERA5_MERRA2_data.tar.gz is an additional SM file containing the observational surface temperature and precipitation data used in evaluating the ModelE modern simulations. We note that we also caught an error in the text in which ERA5 was cited for both the temperature and precipitation. ERA5 was only used for the temperature, while MERRA2 was used for the precipitation.
We thank the editor for catching the missing items and for informing the Reviewers of the new Zenodo link and use of MERRA2 data.
Nancy Kiang
Citation: https://doi.org/10.5194/egusphere-2026-4262-AC7 -
CEC5: 'Reply on AC7', Juan Antonio Añel, 04 Oct 2026
reply
Dear authors,
Thanks for your reply, and your work to bring your manuscript in compliance with the policy of the journal. First of all, dismiss a previous comment a few minutes ago in a different thread in this conversation, as it does not correspond to your last reply, the one here. I did not realize that you had replied here, and visually in the webpage of Discussions the other thread looks like if was more recent than this one.
Thanks for providing the new information and the repositories. However, I would like to note that we do not deal with code and data as "supplementary" material to a manuscript, but they are integral part of the manuscript, and part of the evaluation.
We would like to request you a reply to this comment with the text for a new "Code and Data Availability" section policy that complies with the policy of the journal by providing repositories that contain all the code and data used in your manuscript. If the data mentioned to be obtained from the NASA servers are included in the mentioned repositories, please, make it explicit, and point to the repositories. The goal of the code and data policy is not only about provenance of the data, which is cited in the main text, but to make clear where the data could be obtained over years and decades to come.
Also, it is my understanding that at least you have not solved the pending issues with the ERA data. The files that you provide only contain four data points. In this case, for example, your Fig. 5 refers to annual data, not decadal data. I would like to point out that we are not requesting you the data plotted in the figures, but the original data. If you have downloaded from an ERA5 source monthly data, despite you have performed calculations on them, we expect that you share the source data used in your work.
I hope this helps.
Juan A. Añel
Geosci. Model Dev. Executive Editor
Citation: https://doi.org/10.5194/egusphere-2026-4262-CEC5 -
AC8: 'Reply on CEC5', Nancy Kiang, 07 Oct 2026
reply
Dear Editor,
Thank you again for your careful scrutiny of our submission and revised Supplementary Material.
Regarding the ERA5 (and MERRA2) data:
- We will revise the text lines 412-414 to state:
"Figure 5 shows observed decadal climatologies for 2000-2009, comparing reanalysis observations of surface air temperature from the Fifth generation European Centre for Medium-Range Weather Forecasts (ECMWF) Atmospheric Reanalysis (ERA5) (Hersbach et al., 2020; C3S, 2023) (Figure 5a) and precipitation from the Modern-Era Retrospective Analysis for Research and Applications, Version 2 (MERRA-2) (Gelaro et al., 2017; GMAO, 2015) (Figure 5d), to experiment E0 (Figure 5b,d) and the difference of experiments of E1-E0 (Figure 5c,f)."
-The additional citations are:
Gelaro, R., McCarty, W., Suárez, M. J., Todling, R., Molod, A., Takacs, L., Randles, C. A., Darmenov, A., Bosilovich, M. G., Reichle, R., Wargan, K., Coy, L., Cullather, R., Draper, C., Akella, S., Buchard, V., Conaty, A., da Silva, A. M., Gu, W., Kim, G.-K., Koster, R., Lucchesi, R., Merkova, D., Nielsen, J. E., Partyka, G., Pawson, S., Putman, W., Rienecker, M., Schubert, S. D., Sienkiewicz, M., and Zhao, B.: The Modern-Era Retrospective Analysis for Research and Applications, Version 2 (MERRA-2), Journal of Climate, 30, 5419–5454, https://doi.org/10.1175/JCLI-D-16-0758.1, 2017.GMAO: MERRA-2 tavgU_2d_flx_Nx: 2d,diurnal,Time-Averaged,Single-Level,Assimilation,Surface Flux Diagnostics V5.12.4, Goddard Earth Sciences Data and Information Services Center (GES DISC) Accessed: [01-SEP-2015] [dataset], 10.5067/LUHPNWAKYIO3, 2015.
C3S: ERA5 monthly averaged data on single levels from 1940 to present, Copernicus Climate Change Service (C3S) Climate Data Store (CDS) [dataset], DOI: 10.24381/cds.f17050d7 (Accessed on 04-DEC-2022), 2023.
Regarding the model codes:
-In the Supplementary Material, we provided the exact copies of the clones of the models that we used. In the "Code and Data Availability" section, we will add instructions where to obtain the codes from the NASA GISS website.
-In the Supplementary Material, we provided all of the boundary condition input files. These are available for download at the NASA NCCS data portal, which the editors did not deem a reliable repository (https://portal.nccs.nasa.gov/GISS_modelE/modelE_input_data/). Also, there are many variations available for each of these input files, so for the convenience of the reader, the exact subset of input files are provided in the Zenodo Supplementary Material.-The section named "Data sets and code" will be renamed to "Codes and data availability." That section will be revised as:
"5 Codes and data availability
The codes, data sets, and scripts for generating the Köppen-Geiger-based lookup tables of VBCs and conducting the climate modeling experiments are archived at zenodo.org, doi: 10.5281/zenodo.23021770 (Kiang et al., 2026). A repository for community contributions is available on github at https://github.com/ent-tbm/ent_kglut.git. We welcome community contributions to add variations on the algorithms for generating the modern LUT and especially to add to and refine the paleo-vegetation algorithms, for which there can be numerous versions addressing debates and new discoveries.
The exact clones of the ModelE and ROCKE-3D codes, rundecks, and boundary condition input files used in this study are included in the zenodo.org archive. The ModelE and ROCKE-3D codes are also available for download at: https://www.giss.nasa.gov/. For ModelE, navigate to the Software page, select GCM Model E, go to the nightly snapshots, and select "modelE2.1.tgz - the version E2.1 of Model E code." This version is the frozen ModelE2.1 physics described in Kelley et al. (2020) as used in this study. We note that the ModelE-2.1 still obtain updates for additional diagnostic outputs and optional physics, but the default physics are frozen and the same as that used in this study. The boundary condition input files may also be downloaded from the NASA Center for Climate Simulation (NCCS) data portal at:
https://portal.nccs.nasa.gov/GISS_modelE/modelE_input_data/
The ROCKE-3D code may be downloaded from the ModelE nightly snapshots at https://www.giss.nasa.gov/. Select "modelE2_planet_2.0.tgz - version 2.0 of ROCKE-3D model." This version is the frozen ROCKE-3D planet 2.0 physics described in (Tsigaridis et al., 2025) as used in this study. The ROCKE-3D input files used in this study should be obtained from the zenodo archive.
The ERA5 source data for surface temperature may be downloaded from the Climate Data Store of the Copernicus Climate Change Service (C3S) at: https://cds.climate.copernicus.eu/. The surface temperature data used in this study were decadal averages and regrids of the "ERA5 monthly averaged data on single levels from 1940 to present", "Monthly averaged reanalysis", 2 m temperature field (2019-04-18 published version).
The MERRA2 source data for precipitation may be downloaded from the NASA Goddard Earth Sciences (GES) Data and Information Services Center (DISC). The total precipitation used in this study was from the M2TUNXFLX (or tavgU_2d_flx_Nx) data product, of time-averaged 2-dimensional monthly diurnal means (Gmao, 2015; Gelaro et al., 2017)."We note that the NCCS data portal is the only site where all ModelE input files are provided for download. If this site is considered an unreliable long-term repository, and because in general GCM experiments can involve many variations in boundary condition input files, we expect the zenodo repository to be the more acceptable archive for the input files in this study. ROCKE-3D input files are generally archived on zenodo with each study.
Please let us know if you request further revision.Nancy Kiang
on behalf of the authors
Citation: https://doi.org/10.5194/egusphere-2026-4262-AC8 -
AC9: 'Reply on AC8', Nancy Kiang, 07 Oct 2026
reply
Apologies, the GMAO citation did not fully output. Here is the full citation spelling out the acronym:
GMAO: MERRA-2 tavgU_2d_flx_Nx: 2d,diurnal,Time-Averaged,Single-Level,Assimilation,Surface Flux Diagnostics V5.12.4, Global Modeling and Assimilation Office (GMAO), Goddard Earth Sciences Data and Information Services Center (GES DISC) Accessed: [01-SEP-2015] [dataset], 10.5067/LUHPNWAKYIO3, 2015.
Citation: https://doi.org/10.5194/egusphere-2026-4262-AC9 -
CEC6: 'Reply on AC9 - No compliance with the policy of the journal', Juan Antonio Añel, 07 Oct 2026
reply
Dear authors,
Thanks for your last reply. However, I must insist that we cannot accept the Copernicus Data Store as a repository for the ERA5 data, nor the NCCS on NASA servers, or the NASA Goddard Earth Sciences (GES) Data and Information Services Center (DISC) for accessing the MERRA2 data. Therefore, you must store the data that you have downloaded and used for your work in an acceptable repository according to the policy of the journal.Also, I encourage you to move your statement beginning with "We welcome community contributions..." to a different part of the manuscript, for example, the Conclusions. The goal of the Code and Data Availability section in GMD manuscripts is to ensure provenance and long-term availability of the assets used in a manuscript, not promotional.Therefore, your manuscript remains non-compliant with the policy of the journal and, as it is, can not be considered for publication. Please reply to this comment with a new Code and Data Availability section that complies with the policy of the journal.Juan A. Añel
Geosci. Model Dev. Excecutive Editor
Citation: https://doi.org/10.5194/egusphere-2026-4262-CEC6 -
AC10: 'Reply on CEC6', Nancy Kiang, 08 Oct 2026
reply
Dear Editor,
Per the Editor's request, we have moved the statement, "We welcome community contributions..." from the Code and data availability section to the Conclusions.
Regarding the ERA5 and MERRA2 data, the sources we cite are the same as cited in the Data availability statements in previous publications found in GMD. Reanalysis data necessarily comes from those publicly available sources for data downloads and there are no other repositories. These are often extremely large data sets. Could you please doublecheck to make quite sure that these original sources are not acceptable to GMD, since they have been accepted in previous GMD publications?
For example, these papers cite the same source for ERA5 in their Code and Data Availability sections as https://cds.climate.copernicus.eu/:
https://gmd.copernicus.org/articles/13/4159/2020/
https://gmd.copernicus.org/articles/19/8673/2026/
These papes give the same source for MERRA2 in their Data availability sections as
https://gmd.copernicus.org/articles/19/9395/2026/
which cites: https: //gmao.gsfc.nasa.gov/gmao-products/merra-2
This article: https://gmd.copernicus.org/articles/16/535/2023/
which cites the new host site to which all NASA Earth Science data products have transitioned, which is the same site we cite at Goddard Earth Sciences Data Information Services Center (GES DISC; http://disc.sci.gsfc.nasa.gov/mdisc/overview, GMAO, 2015). For long-term continuity, the site https: //gmao.gsfc.nasa.gov/gmao-products/merra-2 merely directs to the GES site for data access. We can cite either url if the Editor deems one more acceptable.
These are all long-term repositories maintained for community users for not only those data products but others as well.
There are also numerous GISS ModelE papers published in GMD that cite the GISS website nightly snapshots for publicly available model codes. The GISS nightly snapshots have been maintained for decades and will continue to be a long-term repository as long as NASA exists. For example:
https://gmd.copernicus.org/articles/19/1405/2026/
https://gmd.copernicus.org/articles/18/5825/2025/
https://gmd.copernicus.org/articles/17/3487/2024/
The NCCS data portal is not typically cited for ModelE input files, since these input files are typically tailored to the experiments in the particular scientific paper. We request that we be allowed to follow the practice of previous ModelE papers to provide the input files in zenodo only and not cite any other repository.
The previous GMD publications are inconsistent about posting the last access date (which appears to correspond to the date of publication acceptance). Given that codes and data sets generally have version numbers to freeze the version, we request guidance from the Editor on whether to include access dates. The previous publications also do not all cite the repository url in the bibliography but mostly cite the url in the text. Given the examples of those papers, and their brevity, may we revise our Code and Data Availability section as below.
Code availability
The code clones, rundecks, and scripts for generating the Köppen-Geiger-based lookup tables of VBCs and conducting the climate modeling experiments and analyses are archived at zenodo.org, at doi: 10.5281/zenodo.23021770 (Kiang et al., 2026). A repository for community contributions is available on github at https://github.com/ent-tbm/ent_kglut.git. The ModelE and ROCKE-3D codes are publicly available at: https://simplex.giss.nasa.gov/snapshots/.
Data availability
All data sets and model input boundary condition files are archived at the same doi as the codes at zenodo.org, doi: 10.5281/zenodo.23021770 (Kiang et al., 2026). For the ModelE analyses, the ERA5 source data for surface temperature are publicly available from the Climate Data Store of the Copernicus Climate Change Service (C3S) at: https://cds.climate.copernicus.eu/ (2019-04-18 published version). The MERRA2 source data for precipitation are publicly available from the NASA Goddard Earth Sciences (GES) Data and Information Services Center (DISC) at http://disc.sci.gsfc.nasa.gov.
Citation: https://doi.org/10.5194/egusphere-2026-4262-AC10 -
CEC7: 'Reply on AC10', Juan Antonio Añel, 08 Oct 2026
reply
Dear authors,
Thanks for your reply. I must insist, as it is said in my previous comment, that the mentioned sites do not comply with the policy of the journal. Namely, they do not appear to have a published policy for data preservation over many years or decades (some flexibility exists over the precise length of preservation, but the policy must exist). If we have missed a published policy which does in fact address this matter satisfactorily, please post a response linking to it. If you have any questions about this issue, please post them in a reply. We could study an exception to this if the size of each individual dataset is too big to be stored elsewhere (usually in the range of hundreds of GB).
Also, I would like to note that code and data availability sections from previous published manuscripts can not be used as a guide to what is expected for the compliance of a given submission, but the policy is always of application. Perceptions of previous non-compliance can respond to evaluations case by case, or even oversights by editors. Therefore, it is not possible to ask for an exception to the compliance with the policy based on your perception of the evaluation of published papers in the journal.
Therefore, please, reply to this comment with a new Data Availability section that complies with the policy of the journal.
Juan A. Añel
Geosci. Model Dev. Executive Editor
Citation: https://doi.org/10.5194/egusphere-2026-4262-CEC7 -
AC11: 'Reply on CEC7', Nancy Kiang, 09 Oct 2026
reply
Dear Editor,
1) For the ERA5 data, which is produced by ECMWF, we found this statement:
https://www.ecmwf.int/en/about/media-centre/focus/2026/mars-exabyte-scale-meteorological-data
This statement emphasizes long-term archiving. It has a link to this site for retrieving archived data:
https://www.ecmwf.int/en/forecasts/access-forecasts/access-archive-datasets
This site points to the Climate Data Store.The citation for the data set as posted in the earlier Comment is:
C3S: ERA5 monthly averaged data on single levels from 1940 to present, Copernicus Climate Change Service (C3S) Climate Data Store (CDS) [dataset], doi: 10.24381/cds.f17050d7 (Accessed on 04-DEC-2022), 2023.The doi registered to this data set should by definition maintain it in perpetuity.
2) NASA Earthdata has this data preservation policy page:
https://www.earthdata.nasa.gov/about/esdis/esco/standards-practices/nasa-earth-science-data-preservation-content-specification
This describes what is done to preserve data and documentation and the standards that all the NASA Earth Science DAACs use, including the new DISC server that we cited. The earthdata page doesn't explicitly say a timeline, but 'in perpetuity' is consistent with the U.S. National Archives and Records Administration requirements.Each MERRA-2 data file collection has a registered doi, which by definition preserves it in perpetuity. The policy is stated here.
https://gmao.gsfc.nasa.gov/gmao-products/merra-2/citing-merra-2-data_merra-2/The citation for this data set as posted in the earlier Comment is:
GMAO: MERRA-2 tavgU_2d_flx_Nx: 2d,diurnal,Time-Averaged,Single-Level,Assimilation,Surface Flux Diagnostics V5.12.4, Goddard Earth Sciences Data and Information Services Center (GES DISC) Accessed: [01-SEP-2015] [dataset], doi:10.5067/LUHPNWAKYIO3, 2015.This also has a doi, which should maintain it in perpetuity.
3) For the NASA GISS website hosting snapshots of ModelE and ROCKE-3D, since we have archived our clones of the codes on Zenodo, we can remove reference to this site in the paper; however, since it is optional to obtain the code there, please let us know if you approve to keep the reference to https://www.giss.nasa.gov/tools/modelE/, because this page has helpful information on running the model.
Please let us know if the Editor accepts this revised text for the Code and Data availability sections:
Code availability
The code clones, rundecks, and scripts for generating the Köppen-Geiger-based lookup tables of VBCs and conducting the climate modeling experiments and analyses are archived at zenodo.org, at https://doi.org/10.5281/zenodo.23021770 (Kiang et al., 2026). A repository for community contributions is available on github at https://github.com/ent-tbm/ent_kglut.git. The ModelE-2.1 (Kelley et al. 2020) and ROCKE-3D 2.0 (Tsigaridis et al. 2025) codes are otherwise publicly available at: https://www.giss.nasa.gov/tools/modelE/.
Data availability
All data sets and model input boundary condition files are archived at the same doi as the codes at zenodo.org, https://doi.org/10.5281/zenodo.23021770 (Kiang et al., 2026). For the ModelE analyses, the ERA5 source data for surface temperature are publicly available at: https://doi.org/10.24381/cds.f17050d7 [last accessed 2022-DEC04]. (Copernicus Climate Change Service, 2023). The MERRA2 source data for precipitation are publicly available from the NASA at https://doi.org/10.5067/LUHPNWAKYIO3 (GMAO, 2015) [last accessed 01-SEP-2015].
Regards,
Nancy Kiang
on behalf of the authors
Citation: https://doi.org/10.5194/egusphere-2026-4262-AC11 -
CEC8: 'Reply on AC11', Juan Antonio Añel, 10 Oct 2026
reply
Dear authors,
Thanks for your reply. The mentioned statements for the ERA and NASA hosted data have been evaluated in the past. Unfortunately, they do not comply with the requirements of the policy. The ECMWF and the Copernicus Data service have deleted data in the past. For example, it is not longer possible to access some of the old ECMWF reanalyses. Also, the policy of the NASA servers does not mention a retaining period and over the last few years the NASA has deleted many webpages with datasets despite their policy, so we are not in a position to consider them.
We must insist on requesting you to store the original data used in your manuscript in a suitable repository, and a new Data Availability section that complies with the policy of the journal.
Juan A. Añel
Geosci. Model Dev. Executive Editor
Citation: https://doi.org/10.5194/egusphere-2026-4262-CEC8 -
AC12: 'Reply on CEC8', Nancy Kiang, 10 Oct 2026
reply
Dear Editor,
Thank you for informing us of this experience.
With regard to the data files that have a doi, does this mean that the doi has not continued to follow the location of the data? NASA data hosts get reorganized with different urls, but the doi should follow them to their new location. For ECMWF, we cannot confirm, so if it the case that the dataset is not tracked with the doi, then we will archive a copy of the ERA5 source data at zenodo.
Best regards,
Nancy Kiang
on behalf of the authors
Citation: https://doi.org/10.5194/egusphere-2026-4262-AC12 -
AC13: 'Reply on CEC8', Nancy Kiang, 10 Oct 2026
reply
Dear Editor:
Could the Editor please confirm the number of years a data archive must commit to to be acceptable for GMD policy?
Nancy Kiang
on behalf of the authors
Citation: https://doi.org/10.5194/egusphere-2026-4262-AC13 -
CEC9: 'Reply on AC13', Juan Antonio Añel, 10 Oct 2026
reply
Dear authors,
The fact that a dataset has a DOI does not mean that the site where they are deposited is assured to work in the future. Therefore, having a DOI or another kind of permanent handler is a necessary requirement for the datasets used for your work, but is not enough. The repository must comply with the requirements of an explicit policy making clear that the authors can not remove the data when it is published, and having a long-term commitment to preserve the datasets. We do not have a minimum to comply with the policy, but the repositories mentioned in examples, and the ones used normally for publication in GMD have funding and commitments assured for periods beyond 20 years. In special cases, we could accept sites with published policies for shorter periods, such as 10 years. However, having repositories that comply with the requirements of our policy, such cases should be exceptions.
To finish this discussion, and solve the situation regarding the lack of compliance of your manuscript, I strongly recommend you to use one of the usual repositories used by most of the submissions to the journal, such as Zenodo, PANGAEA or FigShare.
Juan A. Añel
Geosci. Model Dev. Executive Editor
Citation: https://doi.org/10.5194/egusphere-2026-4262-CEC9 -
AC14: 'Reply on CEC9', Nancy Kiang, 11 Oct 2026
reply
Dear Editor,
We will upload the ERA5 and MERRA-2 source data to Zenodo, but under a second Zenodo doi to avoid having the duplicate the contents of the first. Is this acceptable?
Regarding MERRA-2 and all NASA data, NASA Earthdata does have this statement of commitment to maintaining doi's:
https://www.earthdata.nasa.gov/engage/submit-data/doi-process
"Because DOIs are fixed, the data products can be found throughout their lifetime, even if their location on the web changes. Each DOI links to a public landing page. NASA’s data archive centers (often referred to as Distributed Active Archive Centers, or DAACs) have a commitment to ensure that those landing pages are present online and actively maintained."
Therefore, if one has the doi or version number of NASA data sets archived on a NASA DAAC, one should always be able to find those data sets even if the url for the landing page changes, since NASA is committed to this.
Regarding the ECMWF, we prefer to use the ERA5 data for surface temperature, because it is considered more accurate than MERRA-2. Since the CDS is not reliable in maintaining landing pages for earlier data set versions, we will comply with the editor's request to upload the source data.
We note that we did already include the regridded versions of the ERA5 and MERRA-2 data in our Zenodo archive. Please explain why these are not acceptable. If regridded, temporally averaged versions of reanalysis data are not acceptable, that means that these data sets that are used by numerous papers will burden Zenodo with many duplicate copies of these source data. In our case, the source data are not terribly high resolution spatially or temporally, so this is not a great problem. But many NASA Earth datasets are extremely large and high resolution and for Earth modeling must necessarily be regridded to coarser resolutions with great computational effort. To upload these source data sets to Zenodo could exceed Zenodo's limit of 100 file at 50 GB each. Therefore, we suggest the Editor to reconsider his rejection of NASA's Earthdata statement of commitment to long-term storage. Please read their DOI commitment statement, which does not mention years of storage, because the commitment is in perpetuity.
Best regards,
Nancy Kiang
on behalf of the authors
Citation: https://doi.org/10.5194/egusphere-2026-4262-AC14 -
AC15: 'Reply on CEC9', Nancy Kiang, 11 Oct 2026
reply
Dear Editor,
We will upload the ERA5 and MERRA-2 source data to Zenodo, but under a second Zenodo doi to avoid having the duplicate the contents of the first. Is this acceptable?
Regarding MERRA-2 and all NASA data, NASA Earthdata does have this statement of commitment to maintaining doi's:
https://www.earthdata.nasa.gov/engage/submit-data/doi-process
"Because DOIs are fixed, the data products can be found throughout their lifetime, even if their location on the web changes. Each DOI links to a public landing page. NASA’s data archive centers (often referred to as Distributed Active Archive Centers, or DAACs) have a commitment to ensure that those landing pages are present online and actively maintained."
Therefore, if one has the doi or version number of NASA data sets archived on a NASA DAAC, one should always be able to find those data sets even if the url for the landing page changes, since NASA is committed to this.
Regarding the ECMWF, we prefer to use the ERA5 data for surface temperature, because it is considered more accurate than MERRA-2. Since the CDS is not reliable in maintaining landing pages for earlier data set versions, we will comply with the editor's request to upload the source data.
We note that we did already include the regridded versions of the ERA5 and MERRA-2 data in our Zenodo archive. Please explain why these are not acceptable. If regridded, temporally averaged versions of reanalysis data are not acceptable, that means that these data sets that are used by numerous papers will burden Zenodo with many duplicate copies of these source data. In our case, the source data are not terribly high resolution spatially or temporally, so this is not a great problem. But many NASA Earth datasets are extremely large and high resolution and for Earth modeling must necessarily be regridded to coarser resolutions with great computational effort. To upload these source data sets to Zenodo could exceed Zenodo's limit of 100 file at 50 GB each. Therefore, we suggest the Editor to reconsider his rejection of NASA's Earthdata statement of commitment to long-term storage. Please read their DOI commitment statement, which does not mention years of storage, because the commitment is in perpetuity.
Best regards,
Nancy Kiang
on behalf of the authors
Citation: https://doi.org/10.5194/egusphere-2026-4262-AC15 -
CEC10: 'Reply on AC15', Juan Antonio Añel, 12 Oct 2026
reply
Dear authors,
Thanks for your reply. We can accept your proposed solution to store the original ERA5 and MERRA2 data used in Zenodo. Please, reply to this comment with the information for such repositories as soon as you have it, so we can evaluate the compliance of your manuscript with the Code and Data policy again.
Regarding your question, we can not accept processed data alone, but the provenance and open long-term availability of the original data must be ensured to comply with replicability of the presented work, and therefore the scientific method. Regarding all the issues you mention in your last reply for the ECMWF and NASA sites, we are well aware of them, and of the consequences that their limitations for long-term availability have. Unfortunately, it does not solve the situation regarding to compliance with our policy.
Juan A. Añel
Geosci. Model Dev. Executive Editor
Citation: https://doi.org/10.5194/egusphere-2026-4262-CEC10 -
AC16: 'Reply on CEC10', Nancy Kiang, 13 Oct 2026
reply
Dear Editor,
We are reading GMD's "Archive standards" on this page:
https://www.geoscientific-model-development.net/policies/code_and_data_policy.html
These are the requirements stated:
Third-party archives must have the following:
- institutional support providing reasonable confidence that the material will remain available for many years/decades
- mechanisms preventing the depositor of the material from unilaterally removing it from the archive
- mechanisms for identifying the precise version of the material referred to in a persistent way. This will usually be a DOI.
The NASA Earthdata DOI Process statement is a commitment in perpetuity (https://www.earthdata.nasa.gov/engage/submit-data/doi-process) , and would seem to satisfy all 3 criteria above. Again, website url's change, but NASA is committed to maintaining all doi links. If the Editor does not have reasonable confidence in NASA's commitment from the above statement, could GMD post an example statement with exact wording that would be acceptable to GMD for published date preservation policy? For example, the GMD language currently does not specify that the institution hosting the archive must have a published statement, and it does not specify how many years the archive must state they will commit to. Making this explicit will make it clear to institutions what kind of policy statement would be acceptable to journals, and would make it easier for authors to know the criteria they must comply with. It would also make sense to distinguish when a data preservation policy was implemented, so that past experience prior to the policy is not used to judge current policy.
Citation: https://doi.org/10.5194/egusphere-2026-4262-AC16 -
CEC11: 'Reply on AC16', Juan Antonio Añel, 13 Oct 2026
reply
Dear authors,
Thanks for your reply. As you can understand, it is not necessary that you point us to the policy of the journal. We know it, as we have redacted it. The policy of the journal is written as is for a reason. Please understand that we do not modify our policy at the request of an individual or group, but it is the result of a large and reflexive process.
At this point, I think the requirements for complying with the data policy have been made clear to you. To be clear, we will not continue debating this in this thread; it would not make sense. If you do not reply with a Code and Data Availability section that includes suitable repositories with the required data, as explained and requested several times in this thread, we can not continue the peer review of your manuscript. As a result, if you feel that you are not in a position to share the data as it has been requested of you, you should withdraw your manuscript from consideration for publication in the journal, or we will have to proceed to reject it.
Juan A. Añel
Geosci. Model Dev. Executive Editor
Citation: https://doi.org/10.5194/egusphere-2026-4262-CEC11
-
AC16: 'Reply on CEC10', Nancy Kiang, 13 Oct 2026
reply
-
CEC10: 'Reply on AC15', Juan Antonio Añel, 12 Oct 2026
reply
-
AC14: 'Reply on CEC9', Nancy Kiang, 11 Oct 2026
reply
-
CEC9: 'Reply on AC13', Juan Antonio Añel, 10 Oct 2026
reply
-
AC12: 'Reply on CEC8', Nancy Kiang, 10 Oct 2026
reply
-
CEC8: 'Reply on AC11', Juan Antonio Añel, 10 Oct 2026
reply
-
AC11: 'Reply on CEC7', Nancy Kiang, 09 Oct 2026
reply
-
CEC7: 'Reply on AC10', Juan Antonio Añel, 08 Oct 2026
reply
-
AC10: 'Reply on CEC6', Nancy Kiang, 08 Oct 2026
reply
-
CEC6: 'Reply on AC9 - No compliance with the policy of the journal', Juan Antonio Añel, 07 Oct 2026
reply
-
AC9: 'Reply on AC8', Nancy Kiang, 07 Oct 2026
reply
-
AC8: 'Reply on CEC5', Nancy Kiang, 07 Oct 2026
reply
-
CEC5: 'Reply on AC7', Juan Antonio Añel, 04 Oct 2026
reply
-
AC6: 'Reply on CEC3', Nancy Kiang, 23 Sep 2026
reply
-
CEC3: 'Reply on AC4', Juan Antonio Añel, 23 Sep 2026
reply
-
AC4: 'Reply on AC3', Nancy Kiang, 23 Sep 2026
reply
-
AC5: 'Reply on CEC2', Nancy Kiang, 23 Sep 2026
reply
The NASA sites are not necessary to access the data, since the data are included in the Zenodo repository.
However, we document that users can download these same data if they wish to have just the code and only obtain the data as necessary. We can remove mention of the NASA repository if necessary.
Citation: https://doi.org/10.5194/egusphere-2026-4262-AC5 -
CEC4: 'Reply on AC5', Juan Antonio Añel, 04 Oct 2026
reply
Dear authors,
Thanks for your reply. We would like to request you a reply to this comment with the text for a new "Code and Data Availability" section policy that complies with the policy of the journal by providing repositores that contain all the code and data used in your manuscript. If the data mentioned to be obtained from the NASA servers are included in the mentioned repositories, please, make it explicit. Also, it is my understanding that at least you have not solved the pending issues with the ERA data. I would like to insist that a repository with a clear README file or specific and clear names for each part of code and dataset would make the evaluation and clearance of the compliance with the policy of the journal easier.
Juan A. Añel
Geosci. Model Dev. Executive Editor
Citation: https://doi.org/10.5194/egusphere-2026-4262-CEC4
-
CEC4: 'Reply on AC5', Juan Antonio Añel, 04 Oct 2026
reply
-
AC3: 'Reply on CEC2', Nancy Kiang, 23 Sep 2026
reply
-
AC2: 'Reply on AC1', Nancy Kiang, 22 Sep 2026
reply
-
AC1: 'Reply on CEC1', Nancy Kiang, 22 Sep 2026
reply
Data sets
Ent Köppen-Geiger LUT Tool v1.0 Nancy Y. Kiang, Cheuk Yin James Lui, Linda Sohl, Scott Guzewich https://doi.org/10.5281/zenodo.17917285
Model code and software
Ent Köppen-Geiger LUT Tool v1.0 Nancy Y. Kiang, Cheuk Yin James Lui, Linda Sohl, Scott Guzewich https://doi.org/10.5281/zenodo.17917285
Viewed
| HTML | XML | Total | Supplement | BibTeX | EndNote | |
|---|---|---|---|---|---|---|
| 336 | 127 | 86 | 549 | 60 | 46 | 48 |
- HTML: 336
- PDF: 127
- XML: 86
- Total: 549
- Supplement: 60
- BibTeX: 46
- EndNote: 48
Viewed (geographical distribution)
| Country | # | Views | % |
|---|
| Total: | 0 |
| HTML: | 0 |
| PDF: | 0 |
| XML: | 0 |
- 1
Dear authors,
Unfortunately, after checking your manuscript, it has come to our attention that it does not comply with our "Code and Data Policy".
https://www.geoscientific-model-development.net/policies/code_and_data_policy.html
First, your manuscript does not contain a "Code and Data Availability" section. Instead, in the current version of your manuscript you have included a section 5 called "Data sets and code", which does not provide suitable repositories for all the code and data used in your work, which includes all the training and output data, code developed and used, and the GISS Model.
I am sorry, but this is something forbidden by our policy, and your manuscript should have never been accepted for Discussions and peer review given such non compliance with it. Our policy clearly states that all the code and data necessary to replicate a manuscript must be published openly and freely to anyone before submission in a suitable repository. The GMD review and publication process depends on reviewers and community commentators being able to access, during the discussion phase, the code and data on which a manuscript depends, and on ensuring the provenance of replicability of the published papers for years after their publication. Please, therefore, publish your code and data in one of the appropriate repositories and reply to this comment with the relevant information (link and a permanent identifier for it (e.g. DOI)) as soon as possible. We cannot have manuscripts under discussion that do not comply with our policy.
Later, if the Topical Editor decides to continue with the review or publication process of your manuscript and you are requested to upload a new version of it, then The 'Code and Data Availability’ section of your manuscript must also be modified to cite the new repository locations, and corresponding references added to the bibliography.
I must note that if you do not fix this problem, we cannot continue with the peer-review process or accept your manuscript for publication in GMD.
Juan A. Añel
Geosci. Model Dev. Executive Editor