[petsc-dev] DMGetMatrix --> DMGetMatrices?

[Jed Brown]

Different stencil width and box/star implies different local spaces and
different amounts of communication, so there is still need to distinguish.
On Feb 10, 2012 6:43 PM, "Dmitry Karpeev" <karpeev at mcs.anl.gov> wrote:

>
>
> On Fri, Feb 10, 2012 at 5:14 PM, Jed Brown <jedbrown at mcs.anl.gov> wrote:
>
>> On Fri, Feb 10, 2012 at 17:08, Dmitry Karpeev <karpeev at mcs.anl.gov>wrote:
>>
>>> 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?
>>
>>
>> Lots of functions get messy if the DM has multiple ways to do something.
>> Should DMCreateLocalVector() use the full stencil or the preconditioning
>> stencil, what should DMGlobalToLocalBegin() be updating, etc.
>>
>
> As you yourself point out, the Jacobian and the preconditioning matrix
> should operate between the same spaces, so there is no ambiguity regarding
> the vectors and the LocalToGlobal/GlobalToLocal mappings for them.
>
>>
>> Barry's solution of having separate DMs sounds cleaner to me
>>
>
> Okay.  I think what saves us here is the assumption that the operators
> that go into SNES (and KSP) act on a single space (i.e., the input and
> output spaces are the same).  Yes, to be able to solve equations we have to
> have spaces
> of the same dimension, and, sure, it's natural to assume they have the
> same PetscLayout, but it's not at all clear they should have the same local
> form (i.e., ISLocalToGlobal for the row and column spaces).  If we did
> allow different local forms, does that mean that we should have two
> different DMs describing the intput and output spaces of *each* J and
> J_pre?  That would mean 4 DMs per SNES/KSP.  This is rhetorical, I guess,
> since we do assume identical input/output spaces, and 2 DMs seems okay to
> me.
>
> Dmitry.
>
>> , at least modulo needing conventions about which DM on which to
>> PetscObjectCompose() things needed by certain callbacks (e.g. in the FAS
>> with TS stuff I'm doing).
>>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20120210/6c802a2f/attachment.html>