FAQ

The project, which is funded by the BMBF until 2025, aims to develop a joint national ESM strategy. More about the goals and underlying structures can be found on our homepage.

Explore the white paper on our strategy! Delve into our vision, mission, technical criteria, and strategic direction that shape the future of Earth system modeling: Click here to access the paper.

If you work in the field of earth system modeling, we would be happy to have you become part of the ESM community, please send an email to info@nat-esm.de to subscribe to our newsletter. The past newsletters can be read here.

To view past workshop documents, have a look on our workshop and training sessions.

Useful insights e.g. lessons learned as well as FAQ are continuously added and we look forward to your input.

The natESM support team believes that science must be as open as possible. Results from this publicly funded project must be published Open Access, all relevant data must be made available as Open Data and software as Open Source. Exceptions may arise, for example, in the case of a data set that is sensitive under data protection law or the necessary use of protected software.

We do not claim intellectual property rights (IPR) to the jointly developed code, but assume no liability for the work performed. Intellectual property rights to the code remain with the applicant institution, but the natESM support team reserves the right to use the results in other/further support services. This is to implement the idea of the collaborative natESM strategy.

The work done for each individual support request will be documented and workshops will be organized to disseminate the best practices. We also add useful insights e.g. lessons learned as well as FAQ about sprints, model developments and more on the website. 

Applications for sprints can be submitted by mail at any time. It will be reviewed for their technical and scientific feasibility - and you will receive feedback on whether your request was successful after a few weeks.

Information about the application process can be found here. If you would also like to receive up-to-date news about the natESM initiative, please send an email to info@nat-esm.de.

The sprint timeline should take into account a realistic initial time for the RSE to get familiar with the code or the part of the code which needs to be targeted during the sprint. Then, it is appreciated a well defined timeline for the following months (after the initial period) with realistic steps and intermediate goals.

In order to start the work efficiently, the RSE needs access to the source code (if not open source) and some meaningful benchmarks/testcases which show the main characteristics of the model that need to be investigated for further development.

In principle no, because the idea behind the natESM initiative is to improve a model through some active development so that the outcome can then be available for the whole community.

Access to the model code and, if applicable, the documentation must already be available for the technical assessment of the application. It is advisable - but not mandatory - to contact the natESM support team in advance. This exchange before submitting a request can facilitate the process for both sides.

Although the engineers will work largely remotely, we expect the applicant's research group to make appropriate efforts to ensure cooperation with sufficient support for the RSE. When RSEs visit the applicant's institute, the applicant is responsible for providing the RSEs with a suitable, safe and healthy working environment.

It is expected to have a basic infrastructure for remote software development ready. This includes a version control system, as well as a platform for tracking issues, progress and discussions. Likewise, representative test cases are necessary to monitor the numerical results and performance of the model.

It must be made clear that the necessary computing time to carry out the support service is not part of this project and must be provided by the applicant.

Formulation of realistic goals for the requested time Software perspective and impact (i.e. long-term goals of the model). Compliance with formal technical requirements (i.e. documentation, standardization methods, version control, portability, ...). Existing scaling plots or research studies on existing HPC systems are positively included in the evaluation.

The entire process runs in parallel in two stages (technical and scientific) and should normally be completed within 4 weeks with a decision of the steering committee.

Under certain circumstances, however, the decision-making process may take up to 8 weeks longer if all resources have just been exhausted.

Queries from the reviewers are possible and should be answered promptly via mail, phone or, if necessary, video conference.

If the work is not completed within the planned time frame, it must be decided on a case-by-case basis whether an extension is possible. In principle, however, a follow-up application should be considered so that other requests can also be processed.

Revision:
Please contact the technical lead on the project and discuss in detail where rework needs to be made to your model in order to resubmit the sprint. After the revision, you can always resubmit a request - this will be completely re-evaluated.

Rejection:
Unfortunately, your submitted sprint does not meet the technical and/or scientific criteria to be further developed as part of the natESM project. If you have any questions about this, please contact us.

The applicant (together with support team colleagues and the natESM coordinator) writes a short report describing the progress made through the collaboration, the impact on the performance or transferability of the code and the impact on the scientific use cases. This report is due within 3 months after the end of the support period. There is a specific format for this summary report and it should clearly indicate what successes or failures have occurred. It will be posted on nat-esm.de/services/documentation after submitting. Also some leassons learned will be reported on the website from the support team.

If the sprint results in a new need for a sprint, a new request must be submitted and the selection process begins again.