Unfortunately they are muddled up in the include files and source. That is functions that you need to implement are mixed in with functions in the base class. I cut and pasted below the basic ones from petscdm.h and removed the ones you do not need to implement.
PETSC_EXTERN PetscErrorCode DMView(DM,PetscViewer); PETSC_EXTERN PetscErrorCode DMLoad(DM,PetscViewer); /* very useful but doesn't need to be implemented PETSC_EXTERN PetscErrorCode DMDestroy(DM*); PETSC_EXTERN PetscErrorCode DMCreateGlobalVector(DM,Vec*); PETSC_EXTERN PetscErrorCode DMCreateLocalVector(DM,Vec*); PETSC_EXTERN PetscErrorCode DMGetLocalToGlobalMapping(DM,ISLocalToGlobalMapping*); /* isn't always needed PETSC_EXTERN PetscErrorCode DMGetBlockSize(DM,PetscInt*); /* often doesn't mean anything, like for mixed methods PETSC_EXTERN PetscErrorCode DMCreateColoring(DM,ISColoringType,ISColoring*); /* not needed by very useful for automatically computing Jacobians via differencing PETSC_EXTERN PetscErrorCode DMCreateMatrix(DM,Mat*); PETSC_EXTERN PetscErrorCode DMSetMatrixPreallocateOnly(DM,PetscBool); PETSC_EXTERN PetscErrorCode DMCreateInterpolation(DM,DM,Mat*,Vec*); /* following are needed if you wish to use geometric multigrid; they don't necessarily make sense for all DM implementations. PETSC_EXTERN PetscErrorCode DMCreateRestriction(DM,DM,Mat*); PETSC_EXTERN PetscErrorCode DMRefine(DM,MPI_Comm,DM*); PETSC_EXTERN PetscErrorCode DMCoarsen(DM,MPI_Comm,DM*); PETSC_EXTERN PetscErrorCode DMRefineHierarchy(DM,PetscInt,DM[]); PETSC_EXTERN PetscErrorCode DMCoarsenHierarchy(DM,PetscInt,DM[]); PETSC_EXTERN PetscErrorCode DMSetFromOptions(DM); > On Jul 23, 2016, at 2: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? > > 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 >> >
