Manav,
Each DM classes has two distinct interfaces:
One interface that is common to all DM which "speaks linear algebra
(algebraic solvers)", for example DMCreateGlobalVector()
One interface that is specific to a particular DM (for example DMDA, or
DMPlex or DMNetwork) it speaks in the language of the mesh/discretization model
of the DM. So for example DMDA routines which are for structured grids speak in
the language of structured grids and so you have things like DMDAGetCorners()
which tells you the corners of the "box" of the structured grid you own. DMPlex
speaks in a particular language of unstructured grids, DMNetwork speaks in the
language of computations on networks (graphs) such as power grids where you
have vertices and edges connecting vertices). DMForest speaks the languages of
quad-tree and oct-tree grids.
The DM is PETSc's approach for communicating between mesh/discretization
data and algebraic solvers. It is suppose to handle all the busywork of
coordinating the interactions of the mesh/discretization data and algebraic
solvers for the application developer so they don't need to do it themselves.
For example with geometric multigrid the DMXXX object can fill up all the
vectors and matrices that are needed for each level without requiring the user
to loop over the levels and put the vectors and matrices themselves into the
PCMG data structures.
IS are lower level basic data structures, often used by DMs. So one does not
replace the use of IS with DM but one collects all the mesh/discretization
interactions into a DMXXX and implements the DM operations (for example
DMCreateGlobalVector()) using the data from DMXXX object.
In some sense libMesh is a DM for unstructured meshes with finite elements
but it was written before we came up with the concept of DMs and so naturally
doesn't use the DM interfaces. So one would not write libMesh using DMDA or
DMPlex or something rather you would write DMlibMesh or write a new DMlibMesh2
by refactoring the libMesh interfaces to match the DM paradigm.
So if you are using libMesh and it satisfies your needs you should
definitely not just switch to some DMXXX unless you have a good reason. Each
DMXXX is for a particular class of problems/algorithms and you pick the DMXXX
to use based on what you are doing. So use DMForest if you wish to use
oct-trees, etc.
Barry
> On Jul 23, 2016, at 11:50 AM, Manav Bhatia <[email protected]> wrote:
>
> Hi,
>
> I am new to the DM constructs. I am curious if there is a compelling reason
> to move from handling IS sets to DM data structures.
>
> My applications are built on top of libMesh. They used IS sets for a long
> time, and in recent years I have seen DM constructs in the library. However,
> I do not know why this is beneficial or necessary. The Petsc manual discusses
> DMDA for structured mesh, and I see reference to DMForest in the code (for
> unstructured mesh?) which is not discussed in the manual.
>
> Is there a document that might provide the necessary background for DM and
> how best to derive from it, like in the libMesh source?
>
> Any guidance would be appreciated.
>
> Regards,
> Manav
