Version 1.0 of the editorial of the EGU (European Geosciences Union) journal,
After 2 years of experience with this revised editorial policy there are a few
required updates, refinements and clarifications, so here we present
version 1.1 of the editorial. The most significant amendments relate to the
peer-review criteria as presented in the Framework for
The changes are summarised as follows:
All manuscript types are now required to include code or data availability
paragraphs, and model code must always be made available (in the case
of copyright or other legal issues, to the editor at a minimum). The role of evaluation in Observationally derived data should normally be published in a
data journal rather than in The main changes to the Publication guide are the addition of
guidelines for editors when assessing papers at the initial review
stage. Before sending papers for peer review, editors are required
to make sure that papers comply with the Framework for A new appendix, the
Version 1.1 of the manuscript types and Publication guide are included in the appendices with changed sentences marked in bold font.
The journal
Cumulative monthly submissions to
The journal
continues to grow at a healthy rate. Figure
Evolution of impact factor through time.
Two years after the last editorial, it is now time to include some minor
updates and clarifications to the peer-review process. These are
highlighted in the abstract and discussed in the sections below. The new
Framework for
As in Editorial 1.0, throughout this editorial, “must” means that the stated actions are required, and the paper cannot be published without them; “strongly encouraged” or “should” means that we encourage the action, but papers can still be published if the criteria are not met; “may” means that the action may be carried out by the authors or reviewers, if they so wish.
Every scientific paper is different, and inclusion of new techniques and
practices can often result in papers that are difficult to
classify into any one of the
In Editorial 1.0 the requirement to make code available was introduced. In cases where legal restrictions mean that the code cannot be made publicly available, the code must still be made available to at least the editor. It must also be accessible to the reviewers if legally possible. This is clearly stated in the abstract of Editorial 1.0, but as the wording is slightly unclear in Framework 1.0, it has now been updated for version 1.1. In addition, in cases where the code is not made publicly available, the authors must grant access to the topical editor, who may reject the paper if this access is not given at some point during the peer-review process. The Publication guide has been updated to reflect this change.
What was perhaps not made so clear in Editorial 1.0 was the executive editors intention that all papers which describe model developments should make the code available, no matter what kind of “type” the manuscript falls into. In addition, papers which describe any kind of new code that may be useful to the scientific community should by default make the code available. We find that, despite Framework 1.0 already requesting authors to make code available for all manuscript types, the authors have not always considered this issue before submitting their papers. For this reason, the “Code availability” paragraph is to become mandatory for all manuscript types. For model experiment description papers or other papers where the required information is not the actual model code, the title may be changed to something more appropriate such as, “Data availability”. The code and/or data availability sections should be located at the end of the article, after the conclusions but before the appendices and acknowledgements.
Model evaluation is an important aspect of many
Given that evaluation is such an important component of almost all
Exactly what constitutes a geoscientific model is somewhat
subjective. A large variety of models are submitted to
Papers should, however, present a significant advance, and be clearly focussed. They should be written in such a way as to be accessible and potentially useful to other members of the geoscientific modelling community. Trivial, poorly written or otherwise incomprehensible papers will be rejected at the initial review stage. Development papers or papers describing model errors or version updates may contain rather small or simple extensions to existing models, but if these papers are done well, then the discussion, comparison of model versions and evaluation against data results in such papers being substantial contributions. The Publication guide is updated to reflect this issue.
Data assimilation schemes for models can be highly complex with a
substantial amount of code. For example, in the case of an adjoint-based method, the data
assimilation scheme uses a backwards running version of the model. Thus,
it is just as important that data assimilation schemes are properly
documented as the models themselves. Data assimilation papers are
already regularly published in
It has become necessary to clarify the ways in which observational data
may be published in
As part of the Copernicus Publications' review system, for each new
submission, a “similarity report” is automatically produced and made
available to the editor. As described more fully in the Publication guide,
there are two main issues for
We have
implemented some minor changes to the peer-review policy at
Much of this text is the same as that in Appendix A of Editorial 1.0. Additional or changed sentences are marked in bold.
This framework is maintained online at the
Here, “must” means that the stated actions are required, and the paper cannot be published without them; “strongly encouraged” or “should” means that we encourage the action, but papers can still be published if the criteria are not met; “may” means that the action may be carried out by the authors or reviewers, if they so wish.
Model description papers are comprehensive descriptions of numerical models
which fall within the scope of The main paper must give the model name and version number (or
other unique identifier) in the title. The publication should consist of three parts: the main paper, a
user manual, and the source code, ideally supported by some summary
outputs from test case simulations. The main paper should describe both the underlying scientific
basis and purpose of the model and overview the numerical solutions
employed. The scientific goal is reproducibility: ideally, the
description should be sufficiently detailed to in principle allow for the
re-implementation of the model by others, so all technical details
which could substantially affect the numerical output should be
described. Any non-peer-reviewed literature on which the publication
rests should be uploaded as supplementary information. The model webpage URL, the hardware and software requirements and
the license information should be given in the text. If papers are
describing subsequent development to a paper already published in The model description should be contextualised appropriately. For
example, the inclusion of discussion of the scope of applicability and
limitations of the approach adopted is expected. All papers must include a section, at the end of the paper,
entitled “Code availability”. Here, either instructions for obtaining
the code, or the reasons why the code is not available should be
clearly stated.
These papers describe technical developments relating to model improvements
such as the speed or accuracy of numerical integration schemes as well as new
parameterisations for processes represented in modules. Also included are
papers relating to technical aspects of running models and the
reproducibility of results, e.g. assessments of their performance with
different compilers, or under different computer architectures.
Model experiment description papers contain descriptions of standard
experiments for a particular type of model, such as might be used in a MIP. Configurations and overview results of
individual models can also be included as well as descriptions of the
methodology of experimental procedures such as ensemble generation. Such
papers should include the discussion of why particular choices were made in the
experiment design and sample model output. In the case of papers describing
MIPs, they should explain any specific project protocols, should highlight
differences in the application of the protocol by the different groups, and
should include sufficient descriptions/figures of model results to give an
overview of the project.
Minor version updates or correction of actual errors in a model, model development or experiment protocol should be submitted as a regular submission within one of the standard manuscript types, and authors may request that these form part of a model special issue including the previously published papers.
Corrigenda correct errors in preceding papers. The manuscript title is as follows: Corrigendum to “TITLE” published in JOURNAL, VOLUME, PAGES, YEAR. Please note that Corrigenda are only possible for final revised journal papers and not for the corresponding discussion paper. Corrigenda should only be used for correcting errors in the papers and not for those occurring in the model development being described.
The
Here, code refers to computer instructions and algorithms made available as plain text. Data is any other information that is external to the main body of the manuscript and required to either fully appreciate or reproduce the results presented in the manuscript.
All papers must include a section at the end of the paper entitled “Code
and/or data availability”:
Preferably, this section should contain the instructions for obtaining
the model code and/or data, either from the supplement or from an
archive with a DOI. Suitable repositories
can be found at the Registry of Research Data Repositories
( Although not recommended, and authors will typically be requested to
improve on this, it is also possible to provide the code
and/or data only upon request via a given point of contact. If the authors cannot or do not wish to make the code and/or data
public (e.g. copyright or licensing restrictions), the reasons must
be clearly stated. Note that, for the purpose of the review, the code and/or data
must still be made available to the editor. Access must also be granted to
the reviewers whilst preserving their anonymity, if this is legally
possible.
Although the source code and user manual will not be reviewed formally,
the reviewers are free to make general comments on any code or data, if they
so wish. During the review process, the ease of model download, compilation
and running of test cases may be assessed.
In this Publication guide, we concentrate on the points of the peer-review
process most relevant to
All authors, reviewers, and editors should make themselves aware of the
journal manuscript types (
On initial submission, the editor first reads the manuscript to check that it
is within scope and that it is of an appropriate quality to enter the
peer-review process.
The usual number of reviewers for a
In the case where a paper is well within the field of interest of the editor, they may choose to review the paper themselves but should only do so when two other reviewers are already in place or when multiple reviewer calls have failed to find a second reviewer.
The call to the reviewers goes out after the submitted manuscript is
published online, after which the paper remains in open review for 8 weeks.
During this time, the reviewers post their reviews which appear on the open-access
One idiosyncrasy with the system is that the second reviewer may read the first review and other comments before forming their own opinion, which can result in their review being largely a reaction to the discussion, rather than an independent view of the paper. This may be seen as either an advantage or disadvantage, but editors should be alert to the case of a purely reactive second review and at this point may call another reviewer, review the paper themselves or include additional comments in an editorial comment.
The review itself should focus on the clarity and rigour of the model
description or development, and the extent to which it has been tested.
Editors should make sure that someone (either a reviewer or the editor) has obtained the model or tool code. They may also attempt to compile the model, and run test cases where appropriate. In the case of other supplementary information, it should be downloaded and inspected with available software – e.g. the reviewers may open files in a NetCDF viewer.
In common with other journals, it is expected that editors will make their own comments on the manuscript and should guide the authors as to which parts of the reviews they should pay particular attention to.
Responsibility for the final decision on the manuscript rests with the assigned topical editor, but any difficulties may be referred to the executive editors.
To propose a special issue, the authors should contact the Executive Editors
in the first instance. The name of a contact person for the special issue is
required.
James Annan (former executive editor) contributed significant advice to the development of the new editorial. Topical editors Sophie Valcke, Guy Munhoven and Klaus Gierens provided helpful comments and suggestions on the manuscript.