[[PageOutline]] Last edited [[Timestamp]] [[BR]] '''Author''' : Gurvan Madec '''Ticket ''' : #927 '''Branch''' : [https://forge.ipsl.jussieu.fr/nemo/browser/branches/2012/dev_r3309_LOCEAN12_Ediag 2012/dev_r3309_LOCEAN12_Ediag ] ---- === '''LOCEAN .12 - Energy diagnostics''' === ''' Motivation: ''' output 3D trends of tracers, momentum, kinetic energy and potential energy.[[BR]] ''' Status :''' the extraction of trends terms exists, but not the 3D output of the trends [[BR]] ''' Main tasks :''' [[BR]] (1) implement the 3D output of tracers and momentum trends using iom_put [[BR]] (2) compute and output the 3D trends of PE and KE [[BR]] (3) validatation + documentation [[BR]] ''' Science Reviewer:''' NOCS guy? [[BR]] ''' System Reviewer:''' NOCS guy? [[BR]] ''' Deadline:''' spring 2012 [[BR]] ''' Priority:''' high [[BR]] ''' Depends on:''' gurvan disponibilities [[BR]] ''' Principal Investigator : ''' Gurvan Madec and Simona Flavoni (simona.flavoni@locean-ipsl.upmc.fr) [[BR]] [[BR]] === ''' Detail of the implementation''' === '''trdmod_oce''' module[[BR]] logical flags added in namlist namtrd which now controls what is done with the trends. [[BR]] 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_trd_d = .FALSE. !: (T) 3D momentum trends or (F) not LOGICAL , PUBLIC :: ln_3D_trd_t = .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_trd_t = .FALSE. !: (T) 2D tracer trends averaged over the mixed layer LOGICAL , PUBLIC :: ln_ML_trd_d = .FALSE. !: (T) 2D momentum trends averaged over the mixed layer }}} [[BR]] '''trdtra''' module[[BR]] Add a systematic mask of the trend.[[BR]] Change the comments to better describe the purpose of this module. Its purpose is: [[BR]] '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])[[BR]] 'TRC' case: send trend to ted_mod_trc, with, in case of advection, transform the incoming advective fluxes into advective trend [[BR]] all cases : mask the trend ('''===>>> PROBABLY add in the module a lbc_lnk so that the trend is defined everywhere''') [[BR]] '''dynadv_cen2 and _ubs''' modules[[BR]] 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[[BR]] [[BR]] '''dynnxt''' module[[BR]] add the output using mom of the total den trend (except asselin time filter) ("utrd_tot", "vtrd_tot") and of the asselin time filter trend ("utrd_atf", "vtrd_atf") but with a shift by one time step[[BR]] [[BR]] '''trdmod''' module[[BR]] 1- introduce the new logical namelist parameters[[BR]] 2- introduce new subroutines : '''trd_budget''' : computation of the domain averaged T,T^2^, PE, KE trends formerly computes in trd_mod routine)[[BR]] ''' trd_3Diom''': output of the 3D trends using IOM [[BR]] [[BR]] '''NB''' problems to be solved: vvl case for tracer sad trends ; flux form case for had (keg) and zad momentum trends[[BR]] [[BR]] '''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 [[BR]]New code doesn't change results when it is switched off [[BR]]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? [[BR]]!,,!''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..........