dolfin team mailing list archive
-
dolfin team
-
Mailing list archive
-
Message #18884
Re: [Branch ~dolfin-core/dolfin/main] Rev 4896: Add simple Stokes solver for parallel testing.
On Fri, 2010-08-06 at 20:36 +0200, Anders Logg wrote:
> 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 approach does work for data which is not partitioned. Just like with
VTK, one can read the 'master file' or the individual files.
> 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.
>
This fails when the number of files differs from the number of
processes. It's very important to support m files on n processes. We've
discussed this at length before.
Garth
> --
> Anders
Follow ups
References