dolfin team mailing list archive

[Garth Wells <gnw20@xxxxxxxxx>]

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
>

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