We state that MPI is optional but -DUSE_MPI=false fails
#17
Comments
|
Side note: apparently 1. it embeds MPI functionality, so explicitly selecting
|
|
No ok, they do not seem to be a lot, except for PARPACK, that is already handled by: In fact grep tells us that: click to see the long outputOnly So probably we just need to add an |
beddalumia
added a commit
that referenced
this issue
Oct 1, 2022
Subroutines contained in linalg_blacs_aux.f90 include the mpif.h header,
which is not available in a non-MPI environment (of course). The problem
is readily solved by constraining the compilation of the
include "linalg_blacs_aux.f90"
statement in SF_LINALG.f90 and the related interface declarations, to an
active -D_MPI flag, via suitable preprocessor directives.
------------------------------------------------------------------------
I also added yet another explicit dependency in the top level CMakeLists
file, since both ninja and parallel "make -j 8" builds were failing, due
to SF_SPECIAL being compiled before SF_INTEGRATE.
------------------------------------------------------------------------
|
Of course this was also needed: Now I manage to compile with both gfortran and ifort, so the issue appears to be solved. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
If we force plain
gfortran(instead ofmpif90) as:The build fails even if we explicitly request for not including mpi:
click to see output
click to see output
Where I want to highlight the actual fortran error:
The very same error is encountered by ninja (I first discovered it here, but then cross-checked with make)
So, having it with both, I guess it is not a build-system (dependency-related) error.
Could it come from commit d9c6758, where the incriminate source file has moved from a
USE MPIstatement toinclude mpif.h? As previously discussed in 71b8aea this is crucial to avoid version mismatches but indeed it requires thempif90wrapper, to provide its own version of thempif.hheader. Well, I'm not actually sure it would have worked with a use statement neither: what happens to theMPImodule if the compiler is not mpi-aware?I imagine that PARPACK does not raise an issue since we do not request to compile it with the
-DUSE_MPI=falseoption, but for sure we need to compilelinalg_blacs_aux.f90and there MPI is explicitly requested:https://github.com/QcmPlab/SciFortran/blob/4f49e7d81a3067c84dcaf8ee6bf9b768e7665a3e/src/SF_LINALG/linalg_blacs_aux.f90#L2-L3
I actually believe that all the work needed to carefully disentangle the MPI and non-MPI features (and somehow document what you can actually use with a non-MPI install...) would not really be rewarded by any notable benefit.[See later comments, it's easier than what I expected]The text was updated successfully, but these errors were encountered: