Version 3 (modified by smasson, 6 weeks ago) (diff)

Name and subject of the action

Last edition: 01/06/20 11:58:22 by andmirek

The PI is responsible to closely follow the progress of the action, and especially to contact NEMO project manager if the delay on preview (or review) are longer than the 2 weeks expected.

  1. Summary
  2. Preview
  3. Tests
  4. Review


This development is part of IMMERSE project.

a) Extend use of XIOS to read/write restart for SI3 and TOP

b) Use XIOS to read configuration data

Robustness of the functionality:

  • Update one of the SETTE tests to use this read/write restart via XIOS to keep this functionality tested


Since the preview step must be completed before the PI starts the coding, the previewer(s) answers are expected to be completed within the two weeks after the PI has sent the request to the previewer(s).
Then an iterative process should take place between PI and previewer(s) in order to find a consensus

Possible bottlenecks:

  • the methodology
  • the flowchart and list of routines to be changed
  • the new list of variables wrt coding rules
  • the summary of updates in literature

Once an agreement has been reached, preview is ended and the PI can start the development into his branch.


Once the development is done, the PI should complete the tests section below and after ask the reviewers to start their review.

This part should contain the detailed results of SETTE tests (restartability and reproducibility for each of the reference configuration) and detailed results of restartability and reproducibility when the option is activated on specified configurations used for this test

Regular checks:

  • Can this change be shown to produce expected impact (option activated)?
  • Can this change be shown to have a null impact (option not activated)?
  • Results of the required bit comparability tests been run: are there no differences when activating the development?
  • If some differences appear, is reason for the change valid/understood?
  • If some differences appear, is the impact as expected on model configurations?
  • Is this change expected to preserve all diagnostics?
  • If no, is reason for the change valid/understood?
  • Are there significant changes in run time/memory?


Some years ago, when we created iom.F90, the idea was to be able to use different IO libraries as transparently as possible…

This was still the case in NEMO 3.6. In that version, you could find 3 different IO libraries: nf90, ioipsl and dimg. the choice between theses libraries was done in iom_def.F90 (lines 30 to 37)

The iom routines where therefore organized in a 2 stages modules.

  • The first stage is iom.F90 that contains all public subroutines, prepare all the IO work but do the IO work.

All the idea was iom.F90 is the common interface for all IO libraries.

  • The second stage is called by iom.F90 subroutines and consist in 3 different IO routines

The fork toward the different libraries was done in iom.F90, with case statements. See for example iom_rstput interface in this version of iom.F90 (from line 1046)

We think that the use of xios to read/write restarts should try follow this same logic.

→ reintroduce case in iom to be able to switch from native netcdf (nf90) to xios library
→ Ideally, the use of xios for restarts should not be visible somewhere else, no?
→ once the interface is done it is directly usable for all restarts

We know that the reality is more complex that this simple description and developing such interface wont be so easy… We think a good stating point is to follow what is done for nf90 restarts that are performed in 2 steps:

1) 1 time step before restart: define all the restart file using a specific context (so xios_context_initialize and xios_close_context_definition cand be done anytime)
2) fill the file when is it restart time step.

Sebastien and Clement