[petsc-dev] SNES, Coloring, DM, and TS

[Dmitry Karpeev]

On Tue, Feb 28, 2012 at 1:24 PM, Jed Brown <jedbrown at mcs.anl.gov> wrote:

> On Tue, Feb 28, 2012 at 12:13, Matthew Knepley <knepley at gmail.com> wrote:
>
>> But this is what is causing the trouble. Vecs need to hold a DM to tell
>> them how to write themselves, but DMs need
>> those Vecs to pass to sovlers. These are very different jobs, and thus
>> cause loops.
>>
>
> Most possible loops are managed by deterministic ordering of destruction.
> Work vectors are counted. If the only problem we need to solve is reference
> count cycle analysis for PetscObjectCompose, we can do that.
>
>
> It sounds like at present, nobody has complained loudly about DM becoming
> the one-stop place for defining the problem to be solved (at least the
> nonlinear problem). Is that true? So do we move DMSetFunction() to
> DMSetSNESFunction() and add DMSetTSIFunction(), etc?
>

I don't understand the need for multiple function evaluation routines and
their explicit naming.
I think the situation here is completely analogous to the situation with
matrices: I thought we agreed that each DM would be capable of generating a
single matrix, the "Jacobian", rather than multiple matrices like J and
J_pre, and that the different necessary matrices (again, e.g., J and J_pre)
would instead be produced by their respective DMs -- the KSP DM and the PC
DM, so to speak.  These subDMs would be pulled out of the SNES DM and
passed to the corresponding KSP and PC objects.  Thus, a DM encapsulates a
single "problem", and if we want to get a different problem -- the "exact"
linearization of the original, for example -- we extract the KSP DM;
 likewise, PC DM is an approximate linearization, and so on.

I don't think TS is any different -- we can have the TSI DM (maybe under a
better name), which could have DMFormFunction encapsulating the IFunction
(and, incidentally, a linearization encapsulating the mass matrix), etc.
 The situation with splitting the problem into subdomains or subfields --
with DMs encapsulating these subproblems -- is completely analogous.  And
if we really wanted to eliminate the dependence on SNES, KSP, TS, etc. --
even the logical dependence in the names of the functions calls like
DMGetKSPDM --  we could resort to object composition.

In short -- I'm for each DM having one function (DMFormFunction or, better,
DMFormResidual) and one matrix (DMFormJacobian) -- *a* linearization of the
residual.  All other functions and matrices are obtained from the
corresponding subDMs.

Dmitry.


> To avoid the dependency loop, those methods would actually live in
> src/snes and src/ts, but their argument would be a DM. The actual
> evaluation context for SNES would be composed with the DM, so it wouldn't
> actually reside in _p_DM.
>
> Do we preserve SNESSetFunction() which would do SNESGetDM() and
> DMSetSNESFunction(). If no DM had been set, SNESGetDM() would create a
> dummy DM just as a place to attach its containers.
>
>  The DMComputeSNESFunction() would always be called by
> SNESComputeFunction(). If the DM was just the dummy, it would call straight
> through to the user's implementation, even forwarding the SNES along as the
> context. If the user had called DMSetSNESFunction() (or
> DMDASetLocalSNESFunction(), etc), that version would be called. (This is
> similar to current logic, but dispatch _always_ goes through some DM, even
> if it's just a dummy to hold function pointers.)
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20120228/cafcdfd5/attachment.html>