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/0937 – NEMO
wiki:ticket/0937

Version 10 (modified by cbricaud, 11 years ago) (diff)

--

Last edited Timestamp?

Author : Clément Bricaud, Jérôme Chanut, Guillaume Reffray

ticket : #937

Branch : BRANCH_NAME


Description

This task dealt with:

  • The replacement of the existing tidal package (from MetOffice?) by Mercator's version. Add linear ramp on tidal forcing.
  • The improvement of the "bdy" package. This is a continuation of the progressive transition to a single open boundary package in NEMO:
  • New schemes are available: tracers/velocities' relaxation, Neumann boundary conditions.
  • Inverse barometer can be added to open boundary data
  • Open boundaries tidal harmonic data can be read from 2d data files (ie given on global data domain). This is aimed to ease model re-localisation.
  • Various corrections in particular with user defined analytical segments: new definition of segments is more restrictive than in previous version to avoid errors in segments locations and crossings. This prevents, for instance, from updating some boundary points twice in case of overlapping FRS zone as it was the case in previous version. We allowed for structured (2d, ie normal/tangential directions to bdy) open boundary data in that case to ease open boundary data extraction from an other model simulation, visualization,...

Testing

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

Apart from NVTK tests, developments have been checked with AMM12 configuration with a 8 x 4 processor layout.

Bit Comparability

Does this change preserve answers in your tested standard configurations (to the last bit) ? NO
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? NO
Is this change expected to preserve all diagnostics?
,,''Preserving answers in model runs does not necessarily imply preserved diagnostics. ''
NO

If key_bdy and key_tide are not activated, modifications do not change either answers or results of standard configurations. Thus results changes only concern AMM12 standard configuration. These changes only come from the completely different tidal module implemented. Thus, there are not induced by the modifications of bdy package alone as long as the same options are used. Keeping new and previous tidal modules would have make the code and namelist interface much heavier so that we preferred to keep the new one.

Note that some issues with overlapping analytical segments have been fixed in bdy package. It is now possible to obtain identical results with user defined "analytical" open boundary segments bounding the domain (ie identical to the case where a single unstructured segment is read from a netcdf file). As a consequence, diagnostics in AMM12 change although no change in the diagnostics themselves has been introduced.


System Changes

Does your change alter namelists? YES
Does your change require a change in compiler options? NO
  • namelist changes:
    • nam_tide: Simplifications in the definition of tidal waves. Add a flag and time_scale to activate linear ramping of tidal motions.
    • nambdy_tide: Add a new option to read tidal boundary data from 2d file given on data domain.
    • nambdy: Add new options for bdy: Flags and times cales to apply relaxation on tracers and baroclinic velocities.
    • nambdy_index: Simplify definition of analytical segments.
    • namsbc_apr: Flag to add inverse barometer at open boundaries. Options to set reference pressure to a constant value or to the domain average.
  • About compiler options: Code update does not require any change in compiler options. Yet, we noticed that results are not reproductible unless the lowest level of optimization is used.

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