Last edited Timestamp?

Author : Gurvan Madec

Ticket : #927

Branch : 2012/dev_r3309_LOCEAN12_Ediag

---

LOCEAN .12 - Energy diagnostics

Motivation: output 3D trends of tracers, momentum, kinetic energy and potential energy.
Status : the extraction of trends terms exists, but not the 3D output of the trends
Main tasks :

(1) implement the 3D output of tracers and momentum trends using iom_put
(2) compute and output the 3D trends of PE and KE
(3) validatation + documentation

Science Reviewer: NOCS guy?
System Reviewer: NOCS guy?
Deadline: spring 2012
Priority: high
Depends on: gurvan disponibilities
Principal Investigator : Gurvan Madec and Simona Flavoni (simona.flavoni@…)

Detail of the implementation

trdmod_oce module

logical flags added in namlist namtrd which now controls what is done with the trends.
All the types of treatment of a given trend are available at the same time. The memory requirement will only increase due to the time averaged arrays defined in IOM.

   LOGICAL , PUBLIC  ::   ln_3D_dyntrd  = .FALSE.         !: (T) 3D momentum             trends or (F) not
   LOGICAL , PUBLIC  ::   ln_3D_tratrd  = .FALSE.         !: (T) 3D tracer               trends or (F) not
   LOGICAL , PUBLIC  ::   ln_PE_trd     = .FALSE.         !: (T) 3D Potential Energy     trends or (F) not
   LOGICAL , PUBLIC  ::   ln_KE_trd     = .FALSE.         !: (T) 3D Kinetic   Energy     trends or (F) not
   LOGICAL , PUBLIC  ::   ln_vor_trd    = .FALSE.         !: (T) 3D barotropic vorticity trends or (F) not
   LOGICAL , PUBLIC  ::   ln_glo_trd    = .FALSE.         !: (T) global domain averaged diag for T, T^2, KE, and PE
   LOGICAL , PUBLIC  ::   ln_ml_tratrd  = .FALSE.         !: (T) 2D tracer   trends averaged over the mixed layer 
   LOGICAL , PUBLIC  ::   ln_ml_dyntrd  = .FALSE.         !: (T) 2D momentum trends averaged over the mixed layer 

trdtra module

Add a systematic mask of the trend.
Change the comments to better describe the purpose of this module. Its purpose is:

'TRA' case: to regroup T & S trends and send them to trd_mod, with, in case of advection, transform the incoming advective fluxes into advctive trend (U.grad[T])
'TRC' case: send trend to ted_mod_trc, with, in case of advection, transform the incoming advective fluxes into advective trend
all cases : mask the trend (===>>> PROBABLY add in the module a lbc_lnk so that the trend is defined everywhere)

dynadv_cen2 and _ubs modules

change jpdyn_trd_had into jpdyn_trd_keg. Now in flux form _keg corresponds to the horizontal advection trends and _rvo to the metric terms

trdmod module

1- introduce the new logical namelist parameters
2- introduce new subroutines : trd_budget : computation of the domain averaged T,T², PE, KE trends formerly computes in trd_mod routine)
trd_3Diom: output of the 3D trends using IOM

NB problems to be solved: vvl case for tracer sad trends ; flux form case for had (keg) and zad momentum trends

Pending issues :

add separate modules for each option ...

create the momentum diag over the ML

create the 3D trends for KE and PE

---

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