Hard to say. Diagnosing parallel race conditions is neither easy nor entertaining.
Could be that you just need a comm.Barrier() call before the comm.bcast() calls. One possible issue is that FiPy automatically partitions the mesh when it detects that it is running in parallel, so the result of your run() routine is that phi1 gets solved only on partition 1, phi2 only on partition 2, etc. and so it may be waiting for the solutions on the other partitions that are never going to come. > On Aug 28, 2016, at 11:50 AM, ronghai wu <[email protected]> wrote: > > > Dear Fipy developers and users, > > The official parallel running way works for me, however, I would like to try > an different way shown in the attached script. When running by $time mpiexec > -n 4 python My_Fipy_Parallel.py, it gets stuck at time step 179 without any > error message pop out, four cores are full but enough memory left. The bigger > the mesh is, the sooner it will get stuck. Does any know why and how to solve > this problem? Thanks. > > Regards > Ronghai > <My_Fipy_Parallel.py>_______________________________________________ > fipy mailing list > [email protected] > http://www.ctcms.nist.gov/fipy > [ NIST internal ONLY: https://email.nist.gov/mailman/listinfo/fipy ] _______________________________________________ fipy mailing list [email protected] http://www.ctcms.nist.gov/fipy [ NIST internal ONLY: https://email.nist.gov/mailman/listinfo/fipy ]
