Changes between Version 17 and Version 18 of 2011WP/2011Stream2/Dynamic Memory


Ignore:
Timestamp:
2011-03-09T16:48:50+01:00 (10 years ago)
Author:
rblod
Comment:

Legend:

Unmodified
Added
Removed
Modified
  • 2011WP/2011Stream2/Dynamic Memory

    v17 v18  
    44[[PageOutline]] 
    55 
    6  
    76As a first step the dynamical allocation is introduced in all components of NEMO and then put in the trunk as the 3.3.1 (see the discussion below) 
    87 
     
    109 
    1110The following link [https://forge.ipsl.jussieu.fr/nemo/wiki/2011Stream2/DynamicMemory_improvments DynamicMemory_improvments] provides some idea of things that can be done to further improve the dynamic memory of NEMO. 
    12  
    1311 
    1412== S2-1 : Andrew P.  : opening of the discusion == 
     
    532530---- 
    533531== S2-8 : Gurvan's 2nd comments == 
    534 I don't thing having many 2D work arrays is a problem. 21 2D arrays are still much smaller than a single 3D array (jpk is usually between 30 and 70).[[BR]]As a starting point, I prefer the solution in which we define as many 2D and 3D allocatable working arrays as necessary in the worth case. [[BR]]In a first step this will be much more simple. In a second stage, if the large number of work arrays is only for a few modules that are not systematically used, then we can decide to only systematically allocate let say 10 work arrays and in those module allocate the additional one (obviously testing before whether they are already allocated or not). 
     532I don't thing having many 2D work arrays is a problem. 21 2D arrays are still much smaller than a single 3D array (jpk is usually between 30 and 70).[[BR]]As a starting point, I prefer the solution in which we define as many 2D and 3D allocatable working arrays as necessary in the worth case. [[BR]]In a first step this will be much more simple. In a second stage, if the large number of work arrays is only for a few modules that are not systematically used, then we can decide to only systematically allocate let say 10 work arrays and in those module allocate the additional one (obviously testing before whether they are already allocated or not). 
    535533 
    536534For jpk, it is true that jpk will not be changed at run-time, BUT with AGRIF the mother and child can have a different jpk (this is a new feature planned to be introduced this year). Therefore jpk MUST be considered as a run-time variable together with jpi and jpj. 
    537535 
    538 About the computation of jpni, jpnj at run-time or in namelist....  the problem I have in mind is the suppression of land-only processor. For the moment the user give the i and j processor cuting AND the number of really used processor (jpnij). It is unclear for me how this can be chosen at run-time... 
     536About the computation of jpni, jpnj at run-time or in namelist.... Â the problem I have in mind is the suppression of land-only processor. For the moment the user give the i and j processor cuting AND the number of really used processor (jpnij). It is unclear for me how this can be chosen at run-time... 
    539537 
    540538---- 
    541539== S2-x : XXX'  comments == 
    542  
    543 ---- 
    544 == S2-testing  == 
    545 RB:  ORCA2LIM, GYRE standard, ORCA2_LIM_AGRIF with gfortran and ifort 
    546 AP: 
    547 KM: ORCA1 on IBM SP6, in addition compilation of ORCA1 with key_coupled 
     540---- 
     541== S2-testing == 
     542RB:  ORCA2LIM, GYRE standard, ORCA2_LIM_AGRIF with gfortran and ifort  
     543 
     544AP:  
     545 
     546KM: ORCA1 on IBM SP6, in addition compilation of ORCA1 with key_coupled  
     547 
    548548CE: 
    549 ---- 
     549 
     550----