Changes between Version 2 and Version 3 of 2021WP/HPC-03_Mele_Comm_Cleanup

Timestamp:

2021-03-15T09:05:52+01:00 (3 years ago)

Author:

epico

Comment:

--

2021WP/HPC-03_Mele_Comm_Cleanup

@@ -21 +21 @@
 
 === Description
-
-{{{#!box width=25em help
-Describe the goal of development and the methodology, \\
-add reference documents or publications if relevant.
-}}}
-
-''...''
+ 
+This action aims at completing what was stared in 2020. Due to the halo=2 most of the lbc_lnk communications can be removed or moved earlier in the code. A careful analysis of the DO LOOP ranges leads the removal of the useless lbc_lnk calls as well. 
 
 === Implementation
 
-{{{#!box width=35em help
-Describe flow chart of the changes in the code. \\
-List the Fortran modules and subroutines to be created/edited/deleted. \\
-Detailed list of new variables to be defined (including namelists), \\
-give for each the chosen name and description wrt coding rules.
-}}}
+The implementation (or better the rationalization) of the lbc_lnk calls will start from DYN and ZDF modules (the TRA modue was completed in 2020). Because we decided to support halo=1 execution, we put the lbc_lnk call inside of an IF statement condition whenever needed. 
 
-''...''
+The movement of a communication earlier in the code (in the case of halo=2) often leads to a difference in the outputs when compared with the halo=1 run. This is due to the north folding algorithm. In the attached document we analysed the problem and found that, due to the north fold, some expressions are evalauted correctly but with a different order of the floating point operations with respect the halo=1 case.
+
+In order to preserve the bit comparion of the results between the cases halo=1 and halo=2, we have to "force" the order of the floating point operations in both cases by introducing round brackets whith the interested expressions.
+
+We propose to insert the round brackets in the expressions where needed directly into the trunk. This will cause a version of the trunk which is not bit comparable with the previuos one, but the differences will be only due to the changes in the order of the floating point operations, hence they should be acceptable.
+
 
 === Documentation updates