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 <gn...@cam.ac.uk> > > > > 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 _______________________________________________ Mailing list: https://launchpad.net/~dolfin Post to : dolfin@lists.launchpad.net Unsubscribe : https://launchpad.net/~dolfin More help : https://help.launchpad.net/ListHelp
