[petsc-dev] DMGetMatrix --> DMGetMatrices?

[Dmitry Karpeev]

The *API* guarantees that?
Once we have more complicated reuse (e.g., between J and J_pre) it might be
trickier.
MG setup already stashes the Vec in the top-level DM to reuse it when
constructing the different levels.

Dmitry.

On Sat, Feb 18, 2012 at 5:21 AM, Jed Brown <jedbrown at mcs.anl.gov> wrote:

> The current API guarantees the FormFunction is called before FormJacobian.
> Do you have a use case where that is not satisfied?
> On Feb 17, 2012 11:13 PM, "Dmitry Karpeev" <karpeev at mcs.anl.gov> wrote:
>
>> The need for computation reuse (between J and J_pre, for example) might
>> require a change in the SNES callback model.
>> Right now each call -- FormFunction, FormJacobian -- is stateless.  It
>> takes a Vec X and computes the corresponding quantities -- residual, J,
>> J_pre -- solely from X.  Any callback that  wanted to reuse any other
>> callback's computation would have to be able to make sure the reuse is
>> safe: am I being called with the same X as this previous callback that
>> already precomputed a bunch of stuff for me?  This is only possible with a
>> costly, collective (and imprecise) vector comparison, or a fragile state
>> tracker within X.  If this is unacceptable, the callbacks must carry (and
>> share) a state, and, thus, become objects.
>>
>> That's probably undesirable within the basic SNES callback model, but may
>> be natural within the DM-based callback model: a SNES sets its DM's Vec X
>> and calls DMFunction, DMJacobian without any argument -- those calls pull
>> out X and compute whatever they need, including some common data for others
>> (e.g., PC DM) to reuse.  A new call to DMSetVec() will reset these common
>> data structures.  This way the DM can also be viewed as a "factory".
>>
>> This would probably make my interaction with libMesh a bit easier, but
>> isn't strictly necessary.  Still, it would be good to know any thoughts on
>> this.
>>
>> Dmitry.
>>
>> On Sun, Feb 12, 2012 at 10:32 AM, Dmitry Karpeev <karpeev at mcs.anl.gov>wrote:
>>
>>>
>>>
>>> On Sat, Feb 11, 2012 at 8:36 AM, Jed Brown <jedbrown at mcs.anl.gov> wrote:
>>>
>>>> On Sat, Feb 11, 2012 at 08:32, Dmitry Karpeev <karpeev at mcs.anl.gov>wrote:
>>>>
>>>>> This sounds fine to me, but what's the API for doing this? You want to
>>>>> do KSPSetDM() and PCSetDM(),
>>>>> so that the user has to explicitly pull out the PC to set its DM?
>>>>>
>>>>
>>>> The PC *always* owns both matrices anyway.
>>>>
>>>
>>> I think there is a rather natural API for handling DM grouping, code
>>> reuse and dealing with the issue of single matrix per DM:
>>>  DM should support DMGetKSPDM(), DMGetPCDM() -- similar to
>>> DMDAGetCoordinateDA() --  each of which will compute the correct matrix.
>>> These calls can return the original DM (or PETSC_NULL) by default.  SNES
>>> will pull out the KSP DM out to set it on the KSP, KSP will do the same for
>>> the PC, etc. DM already has Vec x, so all of the DMs can share x and
>>> compute their respective matrices at the same x and reuse whatever
>>> computation is reusable.  That's up to the implementation, though.
>>>
>>> Dmitry.
>>>
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20120218/c97a84c4/attachment.html>