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? 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 >
