[yt-dev] Issue #952: loading hierarchy before parallel_objects causes barrier mismatch (yt_analysis/yt)

[smoh]

New issue 952: loading hierarchy before parallel_objects causes barrier mismatch
https://bitbucket.org/yt_analysis/yt/issue/952/loading-hierarchy-before-parallel_objects

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 at lists.spacepope.org
http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org