Jeff Hammond <[email protected]> writes:
FWIW, even if MPI_VERSION and MPI_SUBVERSION are set correctly, there’s no guarantee that these types are available. Types are only defined based on what compiler you use. For example, if you use a C89 only compiler, these types will not be available.
Wouldn't the C89-compiled MPICH need to support these datatypes to provide interoperability with C99 code in exactly the same manner as it provides Fortran and C++ types for interoperability with code written in those languages? It is ambiguous in what context the word "use" is used here so maybe I am misinterpreting your statement.
In that case, you should configure MPICH with C99 support (or at least do not use -std=c89).
Filesystem performance is a red herring. Don't compile on the gold-plated filesystem. Use /tmp or /scratch, as suggested by https://www.alcf.anl.gov/user-guides/compiling-and-linking-faq. Every Linux login node has /tmp.
1. System headers and libraries are still often on a remote filesystem. The workflow is a lot more complicated if you mirror that locally. 2. /tmp isn't shared between login nodes, let alone compute nodes, so you have to copy back to global storage. With multiple login nodes, when you background/nohup a compilation task and log out or are disconnected, you have to remember the login node number to get back to the result. The cognitive load of doing all compilation on /tmp, especially with multiple packages, is not trivial. 3. Try teaching this to a novice. The fact is that if HPC is going to grow its user base, it has to be easier to use. If you want to take the elitist stance that expensive machines should only be used by experts, stop giving INCITE awards to people that don't know how to use compilers, debuggers, or the shell. Until then, hiccups along the way land in our lap, and a complicated workflow only serves to intimidate and to create more opportunity for human error, which again comes back in the form of support mail.