[petsc-users] using DM constructs

[Barry Smith]

   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 <bhatiamanav at gmail.com> 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 <bsmith at mcs.anl.gov> 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 <bhatiamanav at gmail.com> 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
>> 
>