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

[Jed Brown]

I'm getting lost with too many ways to do the same thing. The DM has only
one slot for a residual function, I'm not wild about having TS overwrite
that. So TS uses SNESSetFunction(), but now I need it on levels and I want
coloring to work. But the coloring setup code is inside DMComputeJacobian()
and I'd rather not duplicate it in SNES

if (snes->ops->computefunction && !snes->ops->computejacobian && snes->dm
&& !snes->dm->ops->function) {
  /* set up coloring using DM, but apply using snes->ops->computefunction */
}

or some such nastiness.

I would like to either _always_ use DM (possibly created implicitly by
TS/SNES/KSP and just used to hold function pointers) or _never_ use DM.

The problem with never using DM is that we need a way for the user to
decide to implement different physics on coarse levels. They currently do
this by implementing DMCoarsen() or using DMCoarsenHookAdd(). If the
function pointers are stored in SNES and TS, the hook would have to be able
to access them somehow.

The problem with always using DM is that we effectively create a dependency
loop because the user is telling DM about a nonlinear or transient problem
even though that concept is not part of the DM interface.


As a related matter, I'm stuck with a reference counting loop where I want
to attach special Vecs to a DM. I can wrap them in a PetscContainer to
circumvent the code that checks for reference cycles, but that makes
freeing them delicate. We could make a named cache similar to DM work
vectors, but where restored Vecs are not available for reuse.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20120227/00303a3c/attachment.html>