[petsc-dev] DMGetMatrix --> DMGetMatrices?

[Dmitry Karpeev]

On Fri, Feb 10, 2012 at 6:49 PM, Jed Brown <jedbrown at mcs.anl.gov> wrote:

> Different stencil width and box/star implies different local spaces and
> different amounts of communication, so there is still need to distinguish.
>
Okay.  So, the way forward, then, is to attach (up to) two DMs to SNES or a
KSP and define DMSetJacobian() as follows:
PetscErrorCode  DMSetJacobian(DM dm,PetscErrorCode
(*f)(DM,Vec,Mat,MatStructure*))?

Dmitry.


 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/01c2a20c/attachment.html>