Version 8 (modified by sga, 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:

nemogcm.F90

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.

step.F90

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

sbcmod.F90

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

daymod.F90

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.

stpctl.F90

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

diawri.F90

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:

sbcsas.F90

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.


Comments / ideas


Testing

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
'''NA'''

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

Eight processor linux workstation

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. ''
'''NA'''

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 '''

If any of these apply, please document the changes required here…….


Resources

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


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