I am trying to run code in parallel but it seems it just running 4 times. Output is
Hello I am process 0
Hello I am process 0
Hello I am process 0
Hello I am process 0
Please find MWE
from dolfin import *
from mpi4py import MPI as mpi
comm = mpi.COMM_WORLD
ip = comm.Get_rank()
print("Hello I am process ",ip)
mesh = UnitIntervalMesh(MPI.comm_world,10)
V = VectorFunctionSpace(mesh, 'CG', 1)
I cannot reproduce this behavior using the docker image:
docker run -it -v $(pwd):/home/fenics/shared -w /home/fenics/shared --rm quay.io/fenicsproject/dev:latest
which gives output
fenics@ae1d6668589f:~/shared$ mpirun -n 4 python3 test_mpi.py
Hello I am process 0
Calling FFC just-in-time (JIT) compiler, this may take some time.
Calling FFC just-in-time (JIT) compiler, this may take some time.
Hello I am process 1
Hello I am process 2
Hello I am process 3
Therefore, for anyone to help you, you need to supply more information about how you installed FEniCS, what system you are running on, etc. Follow the guidelines in: Read before posting: How do I get my question answered?
root@62a587c0e67c:/home/fenics/shared# mpirun -n 4 --allow-run-as-root python3 test_mpi.py
Hello I am process 0
Hello I am process 1
Hello I am process 2
Hello I am process 3
Calling FFC just-in-time (JIT) compiler, this may take some time.
Calling FFC just-in-time (JIT) compiler, this may take some time.
If I am not mistaken, fenics uses mpich by default.
fenics itself would use mpiexec (or mpirun) and build with mpic++ which (the command name, that is) is independent of MPI implementation. That is, both OpenMPI and MPICH provide their own version of mpirun, and /usr/bin/mpirun is a symlink to the preferred version configured for the given system. fenics will build against whichever MPI implementation has been configured.
On default Debian (and Ubuntu) systems, openmpi is configured as the preferred MPI alternative.
If a local system administrator has switched the preferred MPI to mpich then that could cause problems, since the entire numerical library stack would then need to be recompiled against mpich. It’s too much work to maintain library packages built against and available for both MPI implementations, so Debian doesn’t do that (it’s been done for some low level libraries like scalapack). The pkgconfig file dolfin.pc references the specific MPI implementation that dolfin was built against.
That said, the dolfin build scripts (FindMPI.cmake) do have a bias towards mpich in the sense of searching for libmpich.so if libmpi.so can’t be found.
I had the same problem but when running in parallel on a cluster. The issue was an mpich version conflict and since I had to run it via a singularity container mpich had to be called before the parallel command. Since you are running it on a personal Linux computer the preferred MPI implementation is OpenMPI as dparsons mentioned and it should work fine. My guess is you either have version conflicts or installation problems.
On a different note, while I had the same issue the performance was still improved. True that the communicators are spitting out nonsense but I am sure that the work was still distributed and the performance was better. I also understand that it is a drag when it comes to monitoring the efficacy of your code.