New issue 952: loading hierarchy before parallel_objects causes barrier mismatch https://bitbucket.org/yt_analysis/yt/issue/952/loading-hierarchy-before-para... smoh: Loading hierarchy before entering parallel_objects causes barrier mismatch and the process hangs indefinitely. Everything goes well when all cpus are running the operation, but this happens when some of the cpus are idle. Here's the minimal example that produces the problem in yt 2.6 when run with -np 2. Out of three objects, the process hangs when the third projection is finished and a barrier is opened. ``` from yt.config import ytcfg ytcfg['yt', 'loglevel'] = '1' from yt.mods import * import numpy as np cs = np.random.rand(3, 3) def do(c, pf): cube = pf.h.region(c, c-0.1, c+0.1) proj = pf.h.proj(2, 'Density', source=cube) def do_parallel(pf): pf.h for c in parallel_objects(cs): do(c, pf) if __name__ == '__main__': pf = load('../../enzo_tiny_cosmology/DD0046/DD0046') do_parallel(pf) ``` Looking at the log, it seems that the number of barriers opened is very different depending on whether pf.h is called before parallel_objects or not. If it is called, a barrier is opened many times, and always opened after one projection is finished. If not, it is only called once on each cpu when all objects allocated to it is processed (which seems natural) _______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org