[petsc-dev] DMGetMatrix --> DMGetMatrices?

[Barry Smith]

On Feb 10, 2012, at 5:00 PM, Jed Brown wrote:

> On Fri, Feb 10, 2012 at 16:56, Barry Smith <bsmith at mcs.anl.gov> wrote:
> I realize that since the DMs may often share "the grid information" and only be different in the stencil width or box type or something Jed (or maybe it is Matt) is going to get all upset that their are two DMs with common information sometimes. My response is "get over it"   :-).
> 
> Lots of objects share PetscLayouts, ISLocalToGlobalMappings, etc., without forcing this sharing on users (or, in most cases, even exposing the existence of these shared objects to the user). I think DM should work the same way.

   I have no objection in principle for there being a way to construct two DMs that share most information, but have only stencil width difference and stuff like that. But I would like the result to be two first class PETSc DM objects that each can be independently passed around and used, I believe this is exactly what you are suggesting so we are in agreement.

> 
> In this case, we are interpreting Vecs as being part of both spaces. I'm less keen on that, but it's not a deal breaker.
> 
> What about DMDAFormJacobianLocal()? Should it have both matrices? How does the user manage the two DMs if they want to assemble both matrices in the same mesh traversal?

  I guess it can be changed from

 DMDAFormJacobianLocal(DM da, DMDALocalFunction1 func, Vec X, Mat J, void *ctx)

to 

 DMDAFormJacobianLocal(DM da, DM dap, DMDALocalFunction1 func, Vec X, Mat J, Mat B, void *ctx)

Barry