Version 4 (modified by rblod, 10 years ago) (diff)

Last edited Timestamp?

Author : rblod (Rachid Benshila)

ticket : #829

Branch : dev_r2769_LOCEAN_dynamic_mem


Computing aspects of dynamic memory implementation are already described there, possible consequences there . This branch deals with the first aspect, ie the practical implementation.
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

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

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

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


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

Attachments (1)

Download all attachments as: .zip