[petsc-dev] [petsc-users] Multigrid with defect correction

[Barry Smith]

> On Mar 6, 2017, at 10:03 AM, Jed Brown <jed at jedbrown.org> wrote:
> 
> Barry Smith <bsmith at mcs.anl.gov> writes:
>>> The DMSNES and friends are the parts that are solver specific, since a given DM can be associated with several solvers.
>> 
>>   No, that is not the reason they exist. Every DM actually contains its DMKSP, DMSNES, and DMTS so at any point in time a DM can actually have only one DMXXX. We had arguments over sharing DM with multiple solvers but I think that is a goofy optimization.
> 
> libpetscdm.so does not depend on solvers.  The DMKSP, DMSNES, are
> basically private DM plugins that are packaged with their respective
> solvers.  The old DMMG used void* to avoid a source-level dependency,
> but was more limited in capability and much less safe.  (Remember that
> the DMSNES design was a replacement for DMMG, simplifying a complicated
> and brittle interface with messy dependencies, not some complexity that
> was just added to SNES.)
> 
>>> That is why the resolution-dependent information can go there. You could have stuck all that info in the solver I guess, but perhaps Jed has a good reason not to do that (maybe to make it easier to pass around, or maybe extensible to different DMs).
> 
> We had lots of functions that needed to be forwarded for nonlinear
> preconditioning and the like.
> 
>>   Hmm, since PC/KSP/SNES/TS know about DM why don't we just stick that information in the solver. Seems simpler, there must be some reason.
> 
> That information would need to be forwarded to sub-solvers (nonlinear
> preconditioners, nonlinear DD subdomain solvers, FAS).  It is very
> useful to have reference counting and to minimize order-dependence.
> 
>>> I am not against deprecation there, but we have to preserve an easy way for people to just feed there crap in, meaning no creating a DMSHELL or other setup.
>>> 
>>>   Matt
>>> 
>>> Perhaps we need to revisit what DM is? Looking at the struct _p_DM is rather scary.
> 
> I'm more suspicious about the sections and constraints than about the
> coarsen and subdomain hooks.

   Me too :-) Fortunately using etags I can find and destroy all PetscSection stuff in the solvers and DMs very quickly :-) I cannot do that with DMSNES without breaking everything.

> 
> I know you're skeptical of the DMSNES design, but I think it is highly
> susceptible to second system syndrome so let's not leap to conclusions
> about its replacement.

  Jed,

   If you had a clean slate to design something today, including the user facing API, how would it be different, if at all, from the current code?