Last edited Timestamp?

Author : Gurvan Madec

ticket : #1608

Branch : 2015/dev_r5786_CNRS9_NOC3_LDF

WP2015 Action : CNRS-9 and NOC-3

---

Description

Development branch related to CNRS-9 and NOC-3 actions of 2015 work plan :
• ZDF: simplify and improve the vertical physics in NEMO/OPA (remove CPP keys ;remove avmu & avmv ; reduce the number of lvc_lnk call)
• TRP: add in LDF a module computing the effective transport used by both TRA and TRC

Others possible additions:

• remove all remaining hard coded parts specific to a configuration (especially ORCA2)

• vertical scale factors defined systematically in vvl case (no more domzgr_substitute.h90)

• remove most of the remaining CPP keys (key_trabbl, key_zdf...)

....

---

Strategy

I. ZDF simplification

(I.1) zdfddm (double diffusion)
- systematic allocation of avs. Allow the suppression of zdfddm_substitute.h90 and the removal of key_zdfddm
- addition of an namelist parameter to control the activation of zdfddm (ln_zdfddm)

(I.2) zdfphy (manager of the vertical physics)
- zdfphy.F90 contains two things: zdf_phy_init a subroutine that initializes the vertical physics (formerly zdf_init routine found in zdfini.F90) and zdf_phy a subroutine (called by step) that contains all the step.F90 lines associated with vertical physics update at each time step.
- zdf_phy subroutine becomes the only place where lbc_lnk ==>>> suppression of all lbc_lnk in zdf_xx.F90 modules

(I.3) zdfxxx (all the modules of vertical physics)
- replace all CPP keys associated with vertical physics (key_zdfxxx) and their corresponding logicals (lk_zdfxxx) by namelist logicals (ln_zdfxxx)
- keep only avm, avt and avs : remove avmu, avmv from all zdfxxx.F90 modules (also avmu_k and avmv_k in zdfgls.F90 and zdftke.F90)
-

(I.4) zdftke & zdfgls 
- remove from both TKE and GLS the computation of shear production and destruction by stratification (terms which depends on the temporal and spatial discretization of the ocean model), add a routine that compute them called in both zdf_tke and zdf_gls

Specific points:
zdftke : remove C1D diag from zdftke.F90
zdftke :remame apdlr into a more explicit name: r1_Prt (=1/(Prandtl number) )
zdftke & zdfgls : add the allocation of common arrays (en, avt_k, avm_k)
zdftke & zdfgls : initialization part, set avt_k and avm_k, NOT avt & avm
zdftke & zdfgls : move the call to tie_rst and gls_rst from step into their respective subroutine (zdf_tke and zdf_gls)

II.

(II.1)

(II.2) —

(II.3) — Miscellaneous :

...

Pending issues :

• GLS and agrif: need of implementing modifications similar to those introduced by Seb in TKE case

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/NO '''
Does your change require a change in compiler options?	'''YES/NO '''

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

---

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