Version 12 (modified by gm, 9 years ago) (diff)

Last edited Timestamp?

Author : Steven Alderson

ticket : #932

Branch : dev_r3322_NOCS09_SAS

NOCS.09 — Stand alone surface module

Motivation: A standalone surface module is proposed which will allow surface elements such as sea-ice, iceberg drift and surface fluxes to be run using prescribed model state fields. For example, it can be used to inter-compare different bulk formulae or adjust the parameters of a given bulk formula
Status: Branch created
Main task (3 wk)

(1) Create new NEMO sub-directory (SAS_SRC) which will contain a cut down set of routines to read in or interpolate ocean state at any time and then run all surface routines required.
(2) Write new version of nemogcm for initialising required modules and time-stepping through them
(3) Write new routine to read in ocean state
(4) Look at most convenient form for input data and see if fldread can be modified accordingly
(5) Validation and Documentation

Deadline : September 2012
Priority: High
Science Reviewer : Gurvan Madec
System Reviewer : INGV
Principal Investigator : Steven Alderson (sga@…)

Detail of the implementation

A new copy of the model has to be compiled with a configuration based on ORCA2_SAS_LIM. However no namelist parameters need be changed from the settings of the previous run (except perhaps nn_date0). In this configuration, a few routines in the standard model are overriden by new versions.

Routines replaced are:


This routine initialises the rest of the model and repeatedly calls the stp time stepping routine (step.F90) Since the ocean state is not calculated all associated initialisations have been removed.


The main time stepping routine now only needs to call the sbc routine (and a few utility functions).


This has been cut down and now only calculates surface forcing and the ice model required. New surface modules that can function when only the surface level of the ocean state is defined can also be added (e.g. icebergs).


No ocean restarts are read or written (though the ice model restarts are retained), so calls to restart functions have been removed. This also means that the calendar cannot be controlled by time in a restart file, so the user must make sure that nn_date0 in the model namelist is correct for his or her purposes.


Since there is no free surface solver, references to it have been removed from stp_ctl.


All 3D data have been removed from the output. The surface temperature, salinity and velocity components (which have been read in) are written along with relevant forcing and ice data.

One new routine has been added:


This routine initialises the input files needed for reading temperature, salinity and velocity arrays at the surface. These filenames are supplied in namelist namsbc_sas. Unfortunately because of limitations with the iom module, the full 3D fields from the mean files have to be read in and interpolated in time, before using just the top level. Since fldread is used to read in the data, Interpolation on the Fly may be used to change input data resolution.

Test Case

A standard ORCA2 configuration is run for one year with five day mean output. The mean files are then combined into single files containing 73 means covering the globe. The SAS configuration is then run for one year with surface temperature, salinity and velocity read from this standard run. This run is started from 5th January in order to avoid interpolation between records 73 and 1 in the inputs and the resulting starting transients.

Figure 1: Mean and ± 1 standard deviation of the differences between fields in the 5-day mean files from the control and the SAS runs. Three variables are plotted: ice fraction, total radiation and solar radiation. Ocean only values are used (including the ice difference).

Figure 2: Difference between end-of-year fields in the 5-day mean files from the control and the SAS runs. Biggest discrepancies are in the expected places.

Restartability is still an issue when running SAS, because of the ice model restarting between job segments. So a SAS run has been broken down into two segments of 20 days each. The results at 40 days can then be compared when restarting from 20 days (changing nn_date0 accordingly) and when running for the full 40 days. Differences turn out to be identically zero.

Comments / ideas

Nice test case. It should be interesting to redo it with no time interpolation. In this case, the qsr should be identical but in icy area. Gurvan


Testing could consider (where appropriate) other configurations in addition to NVTK].

NVTK Tested'''NO'''
Other model configurations'''YES'''
Processor configurations tested[ ORCA2_SAS_LIM ]
If adding new functionality please confirm that the
New code doesn't change results when it is switched off
and ''works'' when switched on

For this code, running without it switched on is a null test. Results with SAS are only an approximation to the original run (see Test Case above).

NOC SGI Altix cluster running with ifort compiler.

Bit Comparability

Does this change preserve answers in your tested standard configurations (to the last bit) ?'''NA'''
Does this change bit compare across various processor configurations. (1xM, Nx1 and MxN are recommended)'''YES/NO'''
Is this change expected to preserve answers in all possible model configurations?'''NA'''
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?'''NO '''
Does your change require a change in compiler options?'''NO '''

An extra namelist is required in order to supply source data filenames for sst, sss, ssu and ssv.


''Please ''summarize'' any changes in runtime or memory use caused by this change……''

Memory and runtime are both significantly reduced by use of this configuration. Only four 3D arrays are allocated in this configuration in fld_read, Most of the stp routine is not used.

IPR issues

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

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……….

Attachments (4)

Download all attachments as: .zip