Chris: I think you got this backwards? What Johan has done is to fix a bug in jit when the mesh is distributed on a group only, which means that jit is not called on all processes. Nothing has changed for normal use cases. What you're talking about could be useful but that's a new feature.
Martin 26. nov. 2014 10:27 skrev "Chris Richardson" <[email protected]>: > On 26/11/2014 09:13, Martin Sandve Alnæs wrote: > >> Chris: when jit is called on a subset of processors, the others >> obviously cannot participate. The check for rank 0 within the group is >> exactly to stop all the other participating processors from writing to >> disk simultaneously. So if the instant cache is in a shared directory, >> there's no more disk usage here. >> >> Of course if you have two groups doing exactly the same operations, >> then rank 0 from each group will race for copying into the instant >> cache. In that case we don't have mpi communication between the racing >> processors because they are on different groups, and we'll need the >> file locking in instant to work. Which I guess is still a problem with >> NFS... >> > > > Actually, this could work quite well for some HPC systems, which have /tmp > mounted locally (e.g. in memory) on each node. > In that case, if the instant cache is set up in /tmp, the nodes don't > touch the filesystem at all. > All we would need to do, is to be able to construct MPI groups based on > which processes share a compute node. > > Chris > >
_______________________________________________ fenics mailing list [email protected] http://fenicsproject.org/mailman/listinfo/fenics
