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

[Jed Brown]

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? 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/1443eb0d/attachment.html>