Latest revision as of 07:46, 2 April 2024

This guide, which was largely inspired from Earth IPSL climate models wiki page, provides good practices to reduce as much as possible the environmental footprints of simulations performed with our GCMs. We encourage you to go through the whole list of good practices below:

Which model is needed to answer your research question ?

Is a full 3D climate model needed to answer your research question? Could a simple, less computationally-expensive model (such as 1D versions of the model, namely rcm1d or kcm1d) provide you the answer?

Are there simulations that already exist to answer your research question?

We encourage you to use the IPSL Planeto slack, or directly contact experienced developers/users of the model, to ask whether such simulations exist. Maybe available simulations are not exactly what you need but their preliminary analysis can speed up and narrow down the design of your new set of simulations.

Is your experimental design well thought through?

Which effect/mechanism/signal/etc. are you looking for in your simulations? Have you done a literature review to ensure that your numerical experiments are well designed to do so?

Talk with experienced developers/users

We encourage you to discuss with experienced developers/users before running new model configurations. This will ensure that your study is well thought through and prepared.

Consider the necessary diagnostics

You should check that you have all the diagnostics you expect will be needed to analyze the results later on. As high-frequency diagnostics slow down the model and use a lot of mass storage, you should limit the high-frequency diagnostics to what is required. It may be appropriate to output diagnostics at a high-frequency resolution only for a sub-period of the simulation.

Check everything before launching the production run

First, run short simulations to check that you have all the diagnostics you need and that the model is doing what you expect it to do.

If you plan to launch an ensemble of simulations: start with only one member, wait to have outputs and check them before starting all other members. Indeed it is easier and less consuming to clean and redo a short simulation instead of a full ensemble.

Two pairs of eyes are better than one

If in doubt, you may ask a colleague to double check your experimental setup with you.

Don't wait for the end of the simulation before checking

Your model experiments are now running.

You may check during the run that the simulations are doing what you expect them to do. You may also check that their computational cost is in line with what you expect. If the computational cost is beyond what you expect (i.e., simulations run much slower than expected), and if you didn't add many diagnostics, it may be that you introduced a not-so-well-optimized new piece of code, or that you did not optimize well enough the choices of timesteps.

For example, the radiative transfer is usually the slowest part of the model, so you can potentially significantly accelerate simulations by reducing the frequency at which you call radiative transfer (by increasing the value of "iradia" in callphys.def).

Note: If despite all your attention, your experiments turn out to be bugged, the experimental design was inappropriate or some diagnostics are missing ==> these things happen, do not blame yourself too much, analyze your errors and you may rerun the simulations with the corrected experimental design or setup! High research quality remains what we aim for.

Share your results with other researchers

Your model experiments are done and it is time to analyze them.

When it comes to analyzing your results, you may avoid duplicating the output.

When you have finished the analysis, it is a good idea to keep only the part of the model outputs that has been useful or may be useful in the future. You may delete test simulations that are obsolete and archive the rest (using cc_pack, tar, zip) on the storedir to diminish the environmental impact of mass storage.

Last, there are many online repositories (zenodo, IPSL, etc.) that you can use to publicly share the final outputs of your GCM simulations, for further uses by the community.