Remarks and known problems

• LAM-MPI with the spawn approach

  The usage of MPI_Comm_Spawn_Multiple is the most portable way if MPI processes shall be dynamically spawned on multiple hosts. Therefore, there is a reserved predefined key "host" for the info argument, which specifies the value of the host name, in the MPI2 standard. Nevertheless this is currently not supported by LAM-MPI. Therefore, to use LAM-MPI, it is required to use the CPP key PRISM_LAM. In this case, LAM-MPI MPI_Comm_Spawn_Multiple fills the processors according to the list given in the lam.config file used by the lamboot process (see example in https://oasistrac.cerfacs.fr/browser/trunk/prism/dev_ex/examples/simple-mg), using always all processors on a given node. For example, 1 Driver/Transformer process and 4 processes for the ocean and the atmosphere models would be scheduled on three 4-CPU hosts like the following: the Driver/Transformer would be on host 1, the ocean model would have 3 processes on host1 and 1 process on host 2, and the atmosphere model would have 3 processes run on host 2 and 1 on host 3, which of course is not optimal.

  With MPI_Comm_Spawn , LAM-MPI would be more more flexible regarding the spawning of processes. For OASIS4 this is not an option since MPI_Comm_Spawn_Multiple is required for

  -

  starting multiple binaries (not several applications); this may be required for an heterogenous cluster;

  -

  starting same binary with a multiple set of arguments;

  -

  placing multiple binaries in the same MPI_COMM_WORLD. It is intended here to place the MPI processes of an application into a MPI_COMM_WORLD which is different for each application (as in this case, the applications are not required to change the application internal communicators).

  Therefore, the spawn approach is not recommended with LAM-MPI. The not_spawn approach (see sections 4.1) should be prefered if possible.

• MPICH

  Since MPI1 is not designed for 64 Bit architectures the default MPICH.1.2.* implementation will not work on 64 Bit systems for OASIS4 and PSMILe. It could work on IA64 if there was no use of functions with INTEGER arguments representing an address or a displacement as is the case in OASIS4 (on IA64 architectures these integers must be 64 bits or ``long'' in C language; they are ``int'' in MPICH) .

• Portland Group Compiler

  The Portland Group Compiler Version 5.2 produces an internal compiler error for the main routine of OASIS4.

  For the Portland Group Compiler Version 6.0, the debug option (-g) must be used. No particular option is needed for version 6.1 .

  The Portland Group C compiler produces an error. In particular, with PGCC 8.0.5 and 9.0.4, an error was observed when compiling parser.h included in the C routine for XML reading sasa_c_xml.c. Use of GNU C compiler gcc is recommended instead (see CC in
  oasis4/util/make_dir/make.xxx files.

• Intel Fortran Compiler

  To successfully compile OASIS4, Intel Fortran Compiler version 11.1.046 or higher is required (a problem with pointers pointing on pointers was detected with previous versions).