[[PageOutline]]
Last edited [[Timestamp]]

[[BR]]

'''Author''' : rblod (Rachid Benshila) 

'''ticket''' : #829

'''Branch''' : [https://forge.ipsl.jussieu.fr/nemo/browser/branches/2011/dev_r2769_LOCEAN_dynamic_mem      dev_r2769_LOCEAN_dynamic_mem ] 
----

=== Description ===

Computing  aspects of dynamic memory implementation are already described there http://forge.ipsl.jussieu.fr/nemo/wiki/2011WP/2011Stream2/DynamicMemory, possible consequences  there https://forge.ipsl.jussieu.fr/nemo/wiki/2011Stream2/DynamicMemory_improvments . This branch deals with the first aspect, ie the practical implementation. [[BR]]
Dynamic memory implementation is clearly a step forward, an current implementation from branch dev_r2586_dynamic_mem; is quiet clean, with careful checks of availability of the work arrays. However:
 * Assignation of work arrays by hand leads to some difficulties considering the number of options and combinations of options available in NEMO
 * In term of memory, the number of work arrays have to be hard-coded to the maximum combination, ie we always use more memory than needed
Investigation of improvements follows the following steps:
 * Implementation of timing functionalities : this topic has been discussed within NEMO group for years, since the dynamic memory developments are impacting all the routines, implementing timing in the same time makes sense 
 * Small changes in current implementation : the work-arrays are a in list automatically incremented and decremented, no more assigned by hand. This solves limitation 1 above.
 * More radical change : the working space is build dynamically. This solves limitation 2.

==== 1- Timing ====

This functionality doesn't aim to replace advanced software used for optimisation but:
 * to give a rough idea of performance (CPU and elapsed)
 * use the same tools and format on all computers( fortran intrinsec CPU_TIME and WMPI_TIME)
It is bases on a linked chain of informations to be able to add dynamically new sections and add sub-sections[[BR]]
Implementation:
 * CALL timing_init in nemogcm_init
 * CALL timing_finalize at the end of nemoggcm
 * at the end of step, IF( kt == nit000) CALL timing_reset (once the list of varibles has been built)
 * in each routine to instrument : CALL timing_start('NAME')    CALL timing_stop('NAME')
Imbricated sub-sections are allowed and their time is then subtracted from the mother section unless the call of timing of the section is done in the following way CALL timing_start('NAME')    CALL timing_stop('NAME',section) 

==== 2- Auto-assignement ====
==== 3- Dynamic dynamic memory ====


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