Version 2 (modified by gm, 5 years ago) (diff)

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