[petsc-dev] DMGetMatrix --> DMGetMatrices?

[Dmitry Karpeev]

On Fri, Feb 10, 2012 at 5:00 PM, Jed Brown <jedbrown at mcs.anl.gov> 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.
>
> 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 think it's completely natural for a DM to assemble two operators -- the
discretizations for the two are likely to be related anyway -- as soon as
we decide that it's natural for KSP to take in two matrices and, more
importantly, for the callback set with DMSetJacobian() to compute two
matrices: if a DM knows how to compute  two "Jacobians", why wouldn't it
know how to create/preallocate the two corresponding matrices?

Dmitry.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20120210/dc2fcc1c/attachment.html>