Version 4 (modified by timgraham, 7 years ago) (diff)

Last edited Timestamp?

Author : Tim Graham

ticket : #1306



Add a module to calculate and output the maximum CFL number during a model run. This can be used to inform users if they are close to exceeding CFL stability criterion.

The code exists in a local branch at NEMO3.4 and minimal changes should be required to implement this in the latest NEMO version.

The changes will consist of adding one new module and a single call to it in step.F90. The output is written to an ascii file. In order to implement it as an option without using a cpp key a new namelist parameter (nn_diacfl) has been added to the namctl namelist.


The code will be SETTE tested. This required a small bug fix to be implemented as described in ticket #1363 so that ORCA2OFFPIS runs successfully. AGRIF test currently fails to run but does not work in the trunk before this change has been implemented (i.e. trunk revision 4650).

A 5 time step run of ORCA2LIMPIS has been run with time step level output. The CFL diagnostics were then calculated in Python and agree with the output from the model run.

ORCA025 has also been run with this code included.

SETTE Tested '''YES
Other model configurations '''YES
Processor configurations tested Standard SETTE configs and ORCA025 32x12
If adding new functionality please confirm that the
New code doesn't change results when it is switched off
and ''works'' when switched on

(Answering UNSURE is likely to generate further questions from reviewers.)

Bit Comparability

Does this change preserve answers in your tested standard configurations (to the last bit) ? '''YES
Does this change bit compare across various processor configurations. (1xM, Nx1 and MxN are recommended) '''YES
Is this change expected to preserve answers in all possible model configurations? '''YES
Is this change expected to preserve all diagnostics?
,,''Preserving answers in model runs does not necessarily imply preserved diagnostics. ''

If you answered '''NO''' to any of the above, please provide further details:

  • Which routine(s) are causing the difference?
  • Why the changes are not protected by a logical switch or new section-version
  • What is needed to achieve regression with the previous model release (e.g. a regression branch, hand-edits etc). If this is not possible, explain why not.
  • What do you expect to see occur in the test harness jobs?
  • Which diagnostics have you altered and why have they changed?Please add details here……..

System Changes

Does your change alter namelists? '''YES
Does your change require a change in compiler options? '''NO

A new namelist option (nn_diacfl) has been added to the namctl namelist. This is set to 0 if CFL diagnostic output is not required or 1 if it is.


A very small increase in runtime in ORCA025 test (2 seconds extra to run 5 days) and total memory use increased from 173223 Mb to 175494 Mb (as extra 3D arrays are required).

IPR issues

Has the code been wholly (100%) produced by NEMO developers staff working exclusively on NEMO? '''YES/ NO '''

If No:

  • Identify the collaboration agreement details
  • Ensure the code routine header is in accordance with the agreement, (Copyright/Redistribution? etc).Add further details here if required……….