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<div>
<br></div><div>if (snes->ops->computefunction && !snes->ops->computejacobian && snes->dm && !snes->dm->ops->function) {</div><div>  /* set up coloring using DM, but apply using snes->ops->computefunction */</div>
<div>}</div><div><br></div><div>or some such nastiness.</div><div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div><br></div><div>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.</div>