On Sat, Jul 23, 2016 at 9:29 PM, Manav Bhatia <[email protected]> wrote:
> Thanks, Barry. > > This gives me a good perspective. > > Are there specific functions that need to be implemented/provided by a DM > derived object? What would be a good resource to learn about this? > We talk a lot about this in the online tutorials. Matt > Regards, > Manav > > > > On Jul 23, 2016, at 12:44 PM, Barry Smith <[email protected]> wrote: > > > > > > 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 > > > > -- What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead. -- Norbert Wiener
