Changes between Version 17 and Version 18 of 2011WP/2011Stream2/DynamicMemory
- Timestamp:
- 2011-03-09T16:48:50+01:00 (13 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
2011WP/2011Stream2/DynamicMemory
v17 v18 4 4 [[PageOutline]] 5 5 6 7 6 As 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) 8 7 … … 10 9 11 10 The 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 13 11 14 12 == S2-1 : Andrew P. : opening of the discusion == … … 532 530 ---- 533 531 == 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. 532 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). 535 533 536 534 For 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. 537 535 538 About the computation of jpni, jpnj at run-time or in namelist.... 536 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... 539 537 540 538 ---- 541 539 == 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 == 542 RB: ORCA2LIM, GYRE standard, ORCA2_LIM_AGRIF with gfortran and ifort 543 544 AP: 545 546 KM: ORCA1 on IBM SP6, in addition compilation of ORCA1 with key_coupled 547 548 548 CE: 549 ---- 549 550 ----
