dolfin team mailing list archive

[logg <logg@xxxxxxxxx>]

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");