dolfin team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

On Fri, Aug 06, 2010 at 04:55:44PM +0100, Garth N. Wells wrote:
> On Fri, 2010-08-06 at 08:42 -0700, Johan Hake wrote:
> > On Friday August 6 2010 08:16:26 you wrote:
> > > ------------------------------------------------------------
> > > revno: 4896
> > > committer: Garth N. Wells <gnw20@xxxxxxxxx>
> > > branch nick: dolfin-all
> > > timestamp: Fri 2010-08-06 16:13:29 +0100
> > > message:
> > >   Add simple Stokes solver for parallel testing.
> > >
> > >   Other Stokes demos don't run in parallel because MeshFunction io is not
> > >   supported in parallel.
> >
> > Does anyone have an overview of what is needed for this to be fixed. I
> > couldn't find a blueprint on it.
> >
>
> Here it is:
>
>     https://blueprints.launchpad.net/dolfin/+spec/parallel-io
>
> > I am interested in getting this fixed :)
> >
>
> Me too! We need to look at all the io since much of it is broken in
> parallel.
>
> We need to settle on how to handle XML data. I favour (and I know Niclas
> Janson does too) the VTK approach in which we have a 'master file' that
> points to other XML files which contain portions of the vector/mesh,
> etc. Process zero can read the 'master file' and then instruct the other
> processes on which file(s) they should read in.

This only works if the data is already partitioned. Most of our demos
assume that we have the mesh in one single file which is then
partitioned on the fly.

The initial plan was to support two different ways of reading data in parallel:

1. One file and automatic partitioning

DOLFIN gets one file "mesh.xml", each process reads one part of it (just
skipping other parts of the file), then the mesh is partitioned and
redistributed.

2. Several files and no partitioning

DOLFIN get multiple files and each process reads one part. In this
case, the mesh and all associated data is already partitioned. This
should be very easy to fix since everything that is needed is already
in place; we just need to fix the logic. In particular, the data
section of each local mesh contains all auxilliary parallel data.

This can be handled in two different ways. Either a user specifies the
name of the file as "mesh*.xml", in which case DOLFIN appends say

  "_%d" % MPI::process_number()

on each local process.

The other way is to have a master file which lists all the other
files. In this case, I don't see a need for process 0 to take any kind
of responsibility for communicating file names. It would work fine for
each process to read the master file and then check which file it
should use. Each process could also check that the total number of
processes matches the number of partitions in the file. We could let
process 0 handle the parsing of the master file and then communicate
the file names but maybe that is an extra complication.

--
Anders

Attachment: signature.asc
Description: Digital signature