Documentation: remove old part and add MPIX section

doc/source/limitations.rst

@@ -28,3 +28,22 @@ Other constants
 ---------------
 
 Since other constants are either for information (type, window and communicator's name, processor name and library version string) or with only a portable subset (datarep of file views), their truncation is less at risk of provoking issues in their uses.
+
+Support of MPIX_ Functions
+==========================
+
+MPIX_ functions represent experimental or extended features that are not part of the
+official MPI standard. These functions are provided by some MPI implementations to explore
+new capabilities or optimizations that may be considered for future inclusion in the MPI
+standard. However, the availability and behavior of MPIX_ functions can vary significantly
+between different MPI implementations, leading to potential portability and compatibility
+issues.
+
+Wi4MPI is designed to provide a high degree of portability and interoperability between
+different MPI implementations, facilitating the development and execution of MPI
+applications across a diverse range of HPC environments. To maintain this level of
+compatibility and to ensure a stable and predictable behavior of MPI applications, **Wi4MPI
+does not fully support MPIX_ functions**; this support is provided on a case-by-case basis.
+At momment, **MPIX_Query_cuda_support** is supported. The support of other functions will
+be evaluated on demand.
+

doc/source/user_guide.rst

@@ -157,51 +157,6 @@ Example
 
 In this example wi4mpi understand that mpi_hello.exe is a binary file compiled with OpenMPI, which is run under IntelMPI.
 
-TGCC integration
-----------------
-
-WI4MPI is available on the TGCC via its module environment. All the
-environment settings detailed in the next section is hide by a system of
-flavor and features specific to the center. The flavor indicates the
-kind of the installation chosen by the users, on the other hand, the
-features are used to set one of the chosen conversion we highlight in
-the previous section.
-
-(Flavors et features are modulefiles) Concerning the flavors:
-
-::
-
-    - flavor/wi4mpi/{installation_type} : {installation_type} can be debug or standard
-
-Concerning the features:
-
-::
-
-    - feature/wi4mpi/to/{MPI}/{version} : indicates the desired MPI version for the runtime ({MPI} can take two value OpenMPI or IntelMPI).
-    - feature/wi4mpi/from/{MPI}/{version} : indicates the MPI version used to compiled the binary ELF file ({MPI} can take two value OpenMPI or IntelMPI). This features is not prerequisites, if not loaded (which is the default behaviour), the user is using WI4MPI in the interface.
-
-Default behavior example:
-
-::
-
-    $ module load mpi/wi4mpi/%version
-    load module flavor/wi4mpi/standard (wi4mpi flavor)                                                  #Default installation is standard
-    load module feature/wi4mpi/to/openmpi/1.8.8 (WI4MPI feature to openmpi 1.8.8)                       #Default conversion is Interface -> OpenMPI/1.8.8 (since no module feature/wi4mpi/from is loaded, the wi4mpi mode is interface)
-    load module feature/wi4mpi/mpi_compiler/intel (Wi4MPI compiler feature)                             #Default compiler use by mpi wrapper (mpicc,mpicxx,mpif90,...) within WI4MPI are Intel compilers
-    load module wi4mpi/3.3.0 (Wi4MPI with openmpi/1.8.8)
-
-    In this example, WI4MPI assume that the application is compiled with its own library libmpi.so
-
-    To simply change the conversion "module switch feature/wi4mpi/to/intelmpi/2017"
-
-To activate the preload mode example:
-
-::
-
-    $ module load mpi/wi4mpi/%version
-    $ module load feature/wi4mpi/from/intelmpi/2017
-    load module feature/wi4mpi/from/intelmpi/2017 (WI4MPI feature from intelmpi 2017)
-
 Environment settings
 --------------------