Version 7 (modified by mathiot, 5 years ago) (diff)

Last edited Timestamp?


Author : Mathiot

ticket : XXXX

Branch : dev_r5589_is_oce_cpl


Description

Purpose

Allow NEMO to restart with a new geometry beneath the ice shelf (grounding line migration, i.e advance or retreat as well as calving front migration). This branch allow to test ice sheet/ocean coupling at each restart time step through netcdf file exchange.

Limitation

  • It is not suitable if high frequency coupling is needed. Because the model need to be stop each time you want to couple ocean/ice sheet.
  • It not a conservative method (NEMO is creating/losing volume/mass/salt/heat at the coupling time step if the geometry change). I.e., under a pur dynamics ice sheet advance, your mean ssh will stay constant.

Method

notation: bt = barotropic transport, if not precise, U/V/T/S mean properties of the top wet cell.

  • Thin/enlarge a top cell : T/S/SSH are unchanged, U/V in the top cell are corrected to keep bt_b = bt_n (useful to improve stability)
  • 'Dry a cell' case: set mask = 0, T/S = 0, U/V = 0, bt is corrected to keep bt_b = bt_n and ssh_b = ssh_n
  • 'Dry a column' case: set mask = 0, T/S = 0, U/V = 0 and ssh = 0
  • 'Wet a cell' case: set mask to 1, T/S = MEAN(T(ji+1,jj), T(ji-1,jj), T(ji,jj+1), T(ji,jj-1)) (if no neighbour along i/j axis check along the k axis), SSH unchanged, U/V = 0
  • 'Wet a column' case: set mask to 1, T/S = MEAN(T(ji+1,jj), T(ji-1,jj), T(ji,jj+1), T(ji,jj-1)) (if no neighbour along i/j axis check along the k axis), SSH unchanged, U/V = 0

As the before and now fields are not really compatible (modification of the geometry), the restart time step is prescribed to be an euler time step instead of a leap frog and fields_b = fields_n (only if coupling between ice sheet and ocean).

An option is available to keep trend due to unconservation of Vol./heat/salt to 0 using what is done for runoff with specified T/S. I.e the location and the amount of extra/loss vol./heat/salt is diagnosed, saved and used to come back to a acceptable level of conservation before the next restart time step. The vol./heat/salt is removed/added as close as possible to the source/sink location using the techniques used in sbcrnf to prescribed a source of volume/heat/salt in the runoff. This option is only suitable for global ocean modeling. It has only been tested in the ISOMIP+ 3 and 4 experiments during 5 coupling steps. Only 5, because afterward the sea level was going ridiculously high.

Added routines

  • iscplini.F90: read namelist, allocation …
  • iscplrst.F90: restart extrapolation
  • iscplhsb.F90: compute the volume/heat/salt correction (if asked)

Modified routines

  • istate.F90: call iscpl routine
  • divcur.F90: apply volume correction
  • trasbc.F90: apply heat/aslt correction
  • lib_fortran.F90: at this stage, need all of these to diagnose all is OK. HAVE to be removed before or during review process.
  • lbclnk.F90: add a routine to add correction term over the halo and afterward set the halo to 0. (Need to set a flag because not done for north fold but as the north fold do nut cut the Greenland, it is OK)
  • domngb.F90: I add an optional argument to be able to do this beneath the ice shelf (i.e. at level jk instead of 1).
  • + small modifications in order to have dev_r5589_is_oce_cpl branch compatible to dev_r5151_UKMO_ISF. Could leads to some issue during the merge of these 2 branches (modification of umask_i by ssumask …).

Extra comments

Version r5598 contain many hard coded stuff related to ISOMIP+ (modified some physct, add a dmp file different to the one used in the initial condition … All of them should has been removed from the branch after in revision XXXX.


Testing

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

NVTK Tested'''YES/NO'''
Other model configurationsISOMIP+ EXP 2 qnd 3
Processor configurations tested[ Enter processor configs tested here ]
If adding new functionality please confirm that the
New code doesn't change results when it is switched off
and ''works'' when switched on
'''YES/NO/NA'''

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

'Please add further summary details here'

  • Processor configurations tested
  • etc——

Bit Comparability

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

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

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

&namrun        !   parameters of the run
!-----------------------------------------------------------------------
...
   ln_iscpl    = .false.    !  cavity evolution forcing or coupling to ice sheet model
...
/
!-----------------------------------------------------------------------
&namsbc_iscpl  !   land ice / ocean coupling option
!-----------------------------------------------------------------------
   rn_fiscpl = 7440     ! (number of time step) conservation period (maybe should be fix to the coupling frequencey of restart frequency)
   ln_hsb    = .true.   ! activate conservation module (conservation exact after a time of rn_fiscpl)
/

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