Changes between Version 6 and Version 7 of 2011WP/2011Stream2/DynamicMemory

Timestamp:

2010-12-14T09:38:44+01:00 (13 years ago)

Author:

epico

Comment:

--

2011WP/2011Stream2/DynamicMemory

@@ -437 +437 @@
 
 
+== S2-4 : Italo E.  comments ==
+
+
+Hi all, I have just a couple of comments.
+
+Re the opa_partition routine and the policy for choosing the "best" partition, I suggest to set jpni and jpnj such that the local subdomain is as much "square" as possible. Indeed the "best" performance, with the current domain decomposition, is reached when the local subdomain has a square shape.
+I suggest to modify the opa_patition as follows
+{{{
+...
+
+    CALL factorise(ifact, nfactmax, nfact, mppsize, ierr)
+
+
+    IF(nfact <= 1)THEN
+       WRITE (numout, *) 'WARNING: factorisation of number of PEs failed'
+       WRITE (numout, *) '       : using grid of ',mppsize,' x 1'
+       jpnj = 1
+       jpni = mppsize
+    ELSE
+
+       ! Search through factors for the pair that are closest in value
+       mindiff = 1000000
+       imin    = 1
+       DO i=1,nfact-1,2
+          idiff = ABS(jpjglo/ifact(i) - jpiglo/ifact(i+1))
+          IF(idiff < mindiff)THEN
+             mindiff = idiff
+             imin = i
+          END IF
+       END DO
+       jpnj = ifact(imin)
+       jpni = ifact(imin + 1)
+    ENDIF
+...
+}}}
+
+Re the allocation of work arrays.
+The sharing of work arrays among different routines gives us the possibility to save relevant memory space; so the idea to have a module such as wrk_nemo could be useful. However the usage of those arrays could introduce several contraindications: 1. the code could be less readable; 2. when I write a new routine that calls some other already available, I must be sure that I will not use the same work arrays.
+
+Some actions can be adopted in order to reduce the dangerously of such work arrays, but I would avoid to use routine arguments for passing work arrays. Typically the usage of work arrays is strictly related to the kind of implementation of the routine; on the other hand, the routine prototype should be as stable as possible during the refinement/optimization/modification of the routine implementation. The maintenance of the code becomes very heavy if updating the implementation of one routine implies also the modification of its prototype.
+
+For those routines, at lower level, I suggest to declare locally their work allocatable arrays with the SAVE attribute 
+
+----
+
+
 == S2-x : XXX'  comments ==