On Mon, Sep 21, 2009 at 03:15:15PM -0000, Garth Wells wrote: > > logg wrote: > > On Mon, Sep 21, 2009 at 02:24:15PM -0000, Garth Wells wrote: > >> ** Changed in: dolfin > >> Milestone: None => 0.94 > > > > I think this is a feature, not a bug. > > > > I would call it a bug since it's at best ambiguous, at worst > counter-intuitive. > > Garth
There may be occasions when one will want to read an entire mesh to a processor (or each processor) when running in parallel. A good example of this is when a mesh has been partitioned before and is stored to files: mesh-0.xml mesh-1.xml mesh-2.xml mesh-3.xml ... Then file >> mesh; provides an interface that can be used for this. It would also be fairly difficult to "fix" this. As it is now, the constructor of Mesh provides a wrapper for >> and reads into LocalMeshData rather than a Mesh, and then calls the partitioning. If we were to put this into >>, then the partitioning would need to be called from within the XML parser logic. There is already a warning when doing file >> mesh in parallel which I think should be enough: "Reading entire mesh to one processor. If this is not what you intended, initialize the mesh directly from the filename." -- Anders -- Use File objects to read meshes from file fails in parallel https://bugs.launchpad.net/bugs/430040 You received this bug notification because you are subscribed to DOLFIN. Status in DOLFIN: Confirmed Bug description: The following code does not create a distributed mesh in parallel: File f("somemeshfile.xml"); Mesh mesh; f >> mesh; The following code works as expected, i.e. a distributed mesh in constructed: Mesh mesh("somemeshfile.xml"); _______________________________________________ DOLFIN-dev mailing list [email protected] http://www.fenics.org/mailman/listinfo/dolfin-dev
