New URL for NEMO forge!   http://forge.nemo-ocean.eu

Since March 2022 along with NEMO 4.2 release, the code development moved to a self-hosted GitLab.
This present forge is now archived and remained online for history.
ticket/0932_Standalone_SBC – NEMO
wiki:ticket/0932_Standalone_SBC

Version 18 (modified by sga, 12 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. This is achieved by creating a new sub-directory SAS_SRC which includes copies of new versions of routines. By specifying the order in which sub-directories are included in the build (i.e. SAS_SRC after OPA_SRC in cfg.txt), files with the same name in SAS_SRC are preferentially used over those in OPA_SRC.

Routines in SAS_SRC 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).

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. The surface velocity is now also written into the mean files as a 2D field.

The internal workings of one routine have been completely replaced (which means that sbcmod does not have to be modified):

sbcssm.F90

This routine now initialises the input files needed for reading temperature, salinity, velocity and sea surface height arrays at the surface. These filenames are supplied in namelist namsbc_ssm. Unfortunately because of limitations with the iom module, the full 3D velocity fields from the mean files have to be read in and interpolated in time, before using just the top level. However an option is included to read 2D velocity fields if they are available in the input file, but ln_3d_uv must be explicitly set to be false in the namelist for the code to be able to use them. Since fldread is used to read in the data, Interpolation on the Fly may be used to change input data resolution.

Routines in OPA_SRC changed:

sbcssm.F90

Initialisation on the first time step has been replaced by initialisation before the first time step in a new subroutine sbc_ssm_init called from sbc_init.

sbcmod.F90

Subroutine sbc_init now includes a call to sbc_ssm_init to mirror its introduction in SAS_SRC/sbcssm. This allows the SAS code to switch off non-relevant options before they are acted upon.


Further Discussion

Some of the above changes has implications for other parts of the code (and therefore outside the remit of this branch):

  • daymod currently includes a call to open the ocean restart file for writing. The offline code (OFF_SRC) modifies this with the lk_offline key and replaces control of nitrst with code in trcrst.F90. I wonder if control functionality for all restarts should be in its own routine and removed from restart.F90, daymod.F90 and trcrst.F90. This would mean the above SAS_SRC daymod is unnecessary.
  • There are now three copies of nemogcm with repeat non-overlapping code. I think this part of these files should be moved into a separate file so there is no danger of divergence when the original OPA_SRC copy of nemogcm is modified.

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). Differences are reasonable, except perhaps near the beginning and around 150 days.

Figure 2: Difference between end-of-year fields in the 5-day mean files from the control and the SAS runs. Reasonably small differences. But a large discrepancy near Kamchatka Peninsula.

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

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

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

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


Resources

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