Further improvments for dynamic memory

Last edited Timestamp?

Last edited Timestamp?


CPP key

At the origin, the CPP key where defined to minimize the memory requirement of the code.

Apart from a few exceptions, a key control an option of the system that require additional arrays in in core memory. Now that we have switched to dynamical allocation, most of the key can be removed, and the option would be simply controlled via a namelist parameter.

This can be done throughout the code starting from the vertical physics (key_zdf tke, kpp, cst, gls, ric, tmx) and then the other


avt versus avs

For the key_zdfddm, its suppression can be done in a more clever way, defining avs one for all as a pointer and either pointing on avt is not ddm physics, or pointing to an avs2D arrays that is allocated is ddm is used


memory requirement in terms of workspace arrays

The now-aday demand in terms of number of 2D 3D and 4D arrays should be checked and minimised as much as possible. In particular, a given low number of wrk3D and wrk4D arrays should be allocated and in the module that require more arrays, a test can be added to allocate additional arrays only is this module is effectively used.


creation of a key_no_workspace_check

wrk_in_use and wrk_not_released simply return .FALSE. when this key is defined. ==⇒ done

This should be useful to speed up production runs.

In addition, a inlining compilation option can be added or documented. =⇒ to be done?


wrk array size check

when a huge number of tracer is used (jptra> jpk) the model simply stop. This should be problematic with BFM for example… Another solution should be found… At this stage we first use allocatable array within the routine. For example in zpshde.F90

      REAL(wp), ALLOCATABLE, DIMENSION(:,:,:) ::   zti, ztj    ! interpolated value of tracer
      ! Allocate workspaces whose dimension is > jpk
      ALLOCATE( zti(jpi,jpj,kjpt) )
      ALLOCATE( ztj(jpi,jpj,kjpt) )    
      -----bla, bla, bla-----
      DEALLOCATE( zti )
      DEALLOCATE( ztj )

reduce the number of required work arrays

The number of work array is significant. We can try to reduce it… For example, the 32 2D arrays needed in sbcblk_core is due to a wrong coding of TURB_CORE_1Z subroutine: use of arrays instead of local scalars. Changing ths will also reduce the memory acces and so speed up this routine.


Last modified 9 years ago Last modified on 2011-03-12T14:44:43+01:00