Last edited Timestamp?

Author : James Harle

ticket : #1299

Branch : 2014/dev_r4621_NOC4_BDY_VERT_INTERP

---

Description

Implement an on-line vertical interpolation of BDY inputs needed to allow easy switching between vertical coordinate systems without the need to alter input boundary files.

Files affected:

• fldread.F90
• bdydta.F90
• bdyini.F90
• bdy_oce.F90
• iom_nf90.F90
• iom.F90

Testing carried out on the AMM12 configuration in the trunk code. Six experiments were carried out to check the consistency of the code. These were:

1. Constant T/S boundary conditions on original vertical grid, with nb_jpk_bdy = 51 (first sanity test)
2. Constant T/S boundary conditions on staggered vertical grid, with nb_jpk_bdy = 51 (gdept(jpk = [1 51] ) same as native grid all depths in-between offset from native grid, second sanity test)
3. Realistic boundary conditions on original vertical grid, with nb_jpk_bdy = -1 (i.e. should be the identical to trunk code)
4. Realistic boundary conditions on original vertical grid, with nb_jpk_bdy = 51 (i.e. should be the identical to trunk code within rounding errors in interpolation routine)
5. Realistic boundary conditions on staggered vertical grid, with nb_jpk_bdy = 51 (gdept(jpk = [1 51] ) same as native grid all depths in-between offset from native grid)
6. Realistic boundary conditions on a reduced z-level staggered vertical grid, with nb_jpk_bdy = 31

The datasets for the offset and reduced level input data where generated using the interp routine in matlab.

Results from the tests:

Outstanding issues:

How best to handle the baroclinic velocities in the case of a bathymetry mismatch between input data and native grid:

1. Set velocities to zero in depths on native grid deeper than bathymetry in input file
2. Down fill velocities for missing data

in all cases a barotropic correction has to applied. At present a conservative remapping option does not exist. This should be a straight forward addition of a subroutine in fldread.F90

---

Testing

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

NVTK Tested	'''YES/NO'''
Other model configurations	'''YES/NO'''
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.......

An addition to nambdy is required to activate the BDY interpolation on the fly (nb_jpk_bdy). This sets the number of vertical levels in the BDY input files. If this value is set to -1 the bdy interpolation on the fly subroutine is by-passed and it is assumed that the input files are on the native grid.

---

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