Changes between Version 8 and Version 9 of 2019WP/HPC-12_Mocavero_mpi3

Timestamp:

2019-11-29T17:12:59+01:00 (4 years ago)

Author:

andmirek

Comment:

--

2019WP/HPC-12_Mocavero_mpi3

@@ -40 +40 @@
 
 == Review
+Coding standard OK.
+
+No need for changes in documentation.
+
+
+The development is using mpi3 collective neighbours communications functionality for halo exchange. It has been implemented for the case without land suppression and in one routine- traadv_fct.F90 only. I think this is much needed development. Initial results are very encouraging. I see two major issues with the current implementation.
+
+1)      Is MPI3 standard common now and all centres/users of NEMO will be able to compile and run the model (looks it was introduced in 2012, but I'n not sure if it’s implemented in all recent MPI distributions),
+
+2)      Because the implementation is limited to only one routine it will be difficult to test impact on performance, moreover in the case of problems debugging of the code will be difficult because for one routine different approach to exchange messages will be used.
+
+
+Those two issues should be raised with the whole system team for discussion and potentially all centres should test if the code compiles/runs without any issues, BEFORE the decision to merge this development into the trunk is made. This is a change to a major component of NEMO and not only SETTE tests and test cases, but also operational configurations used in the Centres should be tested if possible.
+
+
+I personally would propose a different strategy, which requires more development before merging this change into the trunk, but avoids potential problem outlined in point 1 and addresses point 2.
+
+
+After implementing exchange for land suppression, a key_mpi3 should be introduce. If defined collective neighbours communications will be used for hallo exchange if not, what we have now will be used. There would be no need to name the newly added routines differently, on preprocessing stage exchange method will be set. My understanding is that the argument list in lbc_lnk will be exactly the same for both (new/old) cases. We would have two different approaches for halo exchange depending on the key key_mpi3 (in the same way XIOS1 and XIOS2 interfaces existed together in the past).  By doing that number of changes in source code will be limited to files in LBC only. And if we are not happy with the performance of MPI3 we can continue using old approach until mpi3 (or newer standard) performs sufficiently good. If we are happy with the performance, we can just remove old method and key_mpi3 (after warning users about the change in advance).
 
 {{{#!box help
-[[Include(wiki:Developers/DevProcess#review)]]
 }}}