Use File objects to read meshes from file fails in parallel

[Skavhaug]

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

[Anders Logg (logg)]

One option would be to keep operator>> as it is (reading the entire mesh on each processor).
It might be desirable to do so in some applications. So it could be a feature and not a bug. If we
issue a suitable warning that should be enough.

[Anders Logg (logg)]

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.

--
Anders

[Garth Wells (garth-wells)]

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

> --
> Anders
>

[Anders Logg (logg)]

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

[Garth Wells (garth-wells)]

logg wrote:
> 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."
>

It may be better to remove ">>" and add an explicit option to the Mesh
constructor. I don't like the above type of warning messages - I would
prefer to remove the ambiguity.

Garth

> --
> Anders
>

[Anders Logg (logg)]

Yes, that would be ok. In that case, we could make >> for Mesh private in the File class, and make Mesh a friend so
that it can be used from the Mesh constructor.