That is, after finishing an adaptive mesh refinement, all the processors need to call METIS for repartitioning. How to guarantee the identical repartitioning mesh is obtained in each processor, the same parameters setup? Whether can the element distribution be guaruateed after adaptive mesh refinement?
Truly parallel mesh is a difficult problem, especially with the increase of mesh data. Is there a better method to solve it?
On 8/28/07, Derek Gaston <firstname.lastname@example.org> wrote:
So.... ParMetis is for partitioning a mesh that is already split up
and each piece _only_ lives on one processor. So if you have 4
elements and you are running on 2 processors... each processor only
has a copy of 2 elements. So repartitioning the mesh is a difficult
problem because no one processor holds an entire copy of the mesh.
This is what ParMetis is good at.
In libMesh this isn't the case. In the example above each processor
actually holds a copy of all 4 elements. This means that each
processor calls METIS when the mesh changes and they all repartition
their own copy of the mesh in exactly the same way. There is no
parallel communication necessary to repartition the mesh
This is why we prefer using METIS right now... because it's fast...
and it works for the way we have our mesh setup. But like I mentioned
we are planning on transitioning to a mesh that is "truly parallel" in
that each processor only has a copy of a couple of elements and no one
processor owns a full copy of the mesh.... and when we do so we'll
have to switch over to using parmetis.
I hope that clears things up.
On 8/28/07, Yujie <email@example.com> wrote:
> Dear John:
> "Up to this time, the ParMetis code has gone largely untested. That would
> be my only qualm against making it a default. As long as we don't have a
> truly parallel mesh, there really is no reason to use it anyway."
> You mean that ParMETIS have been thoroughly tested by its authors or you?
> Why do you mention "As long as we don't have a
> truly parallel mesh"? You mean what the truly parallel mesh is?
> Thanks a lot.
> On 8/28/07, John Peterson <firstname.lastname@example.org> wrote:
> > Roy Stogner writes:
> > > On Tue, 28 Aug 2007, Yujie wrote:
> > >
> > > > Roy told me that METIS can work well in libmesh and ParMETIS can't
> > > > well.
> > >
> > > I didn't say that ParMETIS can't work well, just that I thought it
> > > wasn't used by default.
> > >
> > > > I want to know whether the problem has been solved. If not, where is
> > > > the key problem?
> > >
> > > In src/mesh/mesh_base.C, we build a MetisPartitioner object, and there
> > > doesn't seem to be an easy way for the user to choose a
> > > ParmetisPartitioner or something else without having to edit library
> > > code. We ought to add an API to MeshBase to let users supply their own
> > > instance of a Partitioner subclass.
> > The old way was to build a Partitioner p outside the Mesh and call
> > p.partition(mesh,10);
> > This isn't sufficient in general since as you mentioned the Mesh
> > repartitions itself during each call to prepare_for_use(). I agree
> > the Mesh should contain AutoPtr<Partitioner> and by default this will
> > be a MetisPartitioner. Do you think that would work?
> > -J
> > > > In addition, I want to confirm that libmesh will call METIS for mesh
> > > > partitioning after libmesh reads the mesh data.
> > >
> > > The partitioner is called in MeshBase::prepare_for_use(), which gets
> > > called as soon as the mesh has been fully generated or loaded from a
> > > file.
> > > ---
> > > Roy
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems? Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> Libmesh-users mailing list