Version 12 (modified by mathiot, 9 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 pure 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 (initial commit):
- contains 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.
- Have an error in compilation about the name of one subroutine
- Need to be compile in 2 dime because of error in dependencie
ALL this issue are solved in the commit rXXXX > r5598.
Testing
Testing could consider (where appropriate) other configurations in addition to NVTK].
NVTK Tested | '''YES/NO''' |
Other model configurations | ISOMIP+ EXP 2 and 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 |
Is this change expected to preserve all diagnostics? ,,''Preserving answers in model runs does not necessarily imply preserved diagnostics. '' | YES |
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......''
The call of these routines is done only during the restart step. I described below the change of the istate routines timing as well as the memory:
- With coupling after modification: istate = XXXX
- Without coupling after modification: istate = XXXX
- Without coupling before modification: istate = XXXX
- Overall timing before modification (ORCA2-LIM3 SETTE config): XXXXs/XXXXGb
- Overall timing after modification (ORCA2-LIM3 SETTE config): XXXXs/XXXXGb
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..........