What is the truly parallel mesh?
Currently, is it difficult to realize the truly parallel mesh in libmesh?
In the paper about ParMETIS, the partitionning speed is improved because of the parallel utilization. In addition, dynamic repartitioning is another key problem to call ParMETIS in libmesh, I think.
On 8/28/07, Derek Gaston <email@example.com> wrote:
The deal is that the mesh isn't truly parallel in libMesh.... it is
actually copied to every node and only the calculations are actually
done in parallel.
Because of this there isn't much difference between using METIS and
PARMETIS. I have used some of the parmetis partitioners in libMesh
when I was doing some testing... and if I remember correctly didn't
find any difference between them and METIS for libMesh.
We are now looking at parallelizing the mesh in libMesh at which point
we will have to switch to using PARMETIS... and taking advantage of
things like Adaptive Repartitioning... but right now there is no
On 8/28/07, Yujie <firstname.lastname@example.org> wrote:
> Dear Roy:
> I am very sorry for misunderstanding what you said. However, it is likely
> difficult to call ParMETIS in libmesh? Whether will it affect the
> implementation of dynamic repartitioning in adaptive mesh refinement. I have
> found that a function (ParMETIS_V3_AdaptiveRepart) in ParMETIS is used to
> deal with the adaptively refined mesh. METIS uses the methods (coarsen,
> partition and refine) to partition the mesh, which most likely affects the
> element distribution. I don't confirm this. Could you give me some
> information about it?
> thanks a lot.
> On 8/28/07, Roy Stogner <email@example.com
> > On Tue, 28 Aug 2007, Yujie wrote:
> > > Roy told me that METIS can work well in libmesh and ParMETIS can't work
> > > 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.
> > > 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