You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Traditionally, the Python processes spawned from an mpicasa call split their roles when casampi.private.start_mpi is executed: rank 0 becomes the MPIclient, while non-rank 0 processes are placed in a holding pattern as MPIServers.
It appears that builds using conda-forge mpi4py>=4.0+openmpi=5.0.4 alter this behavior, as non-rank 0 processes no longer assume their server roles after the casampi.private.start_mpi call. I have confirmed that this issue arises solely due to the mpi4py version bump in both CASA version 6.6.1 and 6.6.6.
Traditionally, the Python processes spawned from an
mpicasa
call split their roles whencasampi.private.start_mpi
is executed: rank 0 becomes the MPIclient, while non-rank 0 processes are placed in a holding pattern as MPIServers.It appears that builds using conda-forge
mpi4py>=4.0
+openmpi=5.0.4
alter this behavior, as non-rank 0 processes no longer assume their server roles after thecasampi.private.start_mpi
call. I have confirmed that this issue arises solely due to the mpi4py version bump in both CASA version 6.6.1 and 6.6.6.As an interim solution, we should continue using
mpi4py<4
+openmpi=5.0.3
for the time being.The text was updated successfully, but these errors were encountered: