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

[Jed Brown]

On Tue, Feb 28, 2012 at 13:52, Dmitry Karpeev <karpeev at mcs.anl.gov> wrote:

> 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.
>

I'm concerned that this becomes insanity. A single TS might need
RHSFunction, IFunction, and IJacobian. They might also partition terms
differently for the functions and the Jacobian. Having different DMs seems
awfully confusing.

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.
>

The interface is actually different for these (compare TSIFunction, a
transient residual, to SNESFunction)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20120228/f8d060d1/attachment.html>