[petsc-dev] DMMG without libpetscsnes?

Matthew Knepley knepley at gmail.com
Thu Jan 7 10:10:57 CST 2010

On Thu, Jan 7, 2010 at 9:12 AM, Barry Smith <bsmith at mcs.anl.gov> wrote:

>  Let's get this dang PETSc release out the door and then fix up the solvers
> by properly merging DMMG into KSP and SNES

1) What do we need for the release?

2) It seems that what you want is the Builder paradigm for PC (MG), KSP,
SNES where builders take a DMMG, or the
    builder is part of DMMG. Does this seem right to you?


>   Barry
> On Jan 7, 2010, at 8:34 AM, Barry Smith wrote:
>>  DMMG used to be split up (as you note from the stale comment). I ended up
>> merging them because it wasn't worth the effort and complication to keep
>> them in two parts.
>>  I would not like to see them split up again. Rather I would like to see
>> the linear part of DMMG put into KSP/PC/DMMG somehow (not exactly sure how)
>> so it can be properly nested and composed just like other preconditioners.
>> I'm sure you are doing something slightly cumbersome now to put your DMMG
>> inside the Schur fieldsplit. For linear DMMG I think the design is all wrong
>> as it is now.
>>  Here is how I see it: DMMG's job is to "fill up" the appropriate fields
>> in the KSP, PC, MG objects, then when solving those fields are used. I would
>> like (somehow) the KSP, PC, MG objects to have the mechanism that you can
>> provide a DM to them and they can then "fill up" their fields. But it is
>> important we get this right and compossible so I have hesitated to ever try
>> it. The starting point might be having an (optional) KSPSetDM() that would
>> propagate the DM into the PC and subPCs and subsubPCs etc where they would
>> be used to fill the slots if provided.
>>  Going to the basic design motto of PETSc, "only a single way to do each
>> action", it is obvious that DMMG is totally wrong since there is a
>> KSPSolve() and a DMMGSolve()! Someday I want this fixed.
>>  Barry
>> On Jan 7, 2010, at 7:13 AM, Jed Brown wrote:
>>  I'm using a DMMG inside of a Schur fieldsplit, but I have to create it
>>> before PCSetUp because the hierarchy is generated by refinement.  It
>>> doesn't make sense to call DMMGSetKSP before PCSetUp because that matrix
>>> would be worthless, but I want to be able to view the DMMG even if only
>>> to inspect the hierarchy.  While putting in a check for NULL snes in
>>> DMMGView, I noticed these lines in damg.c
>>>    /* use of PetscObjectView() means we do not have to link with
>>> libpetscsnes if SNES is not being used */
>>>    ierr =
>>> PetscObjectView((PetscObject)dmmg[nlevels-1]->snes,viewer);CHKERRQ(ierr);
>>> This appears to be stale because damg.c *is* part of libpetscsnes.  In
>>> fact, all of damg.c can be moved to ksp/ksp/utils after
>>> currently has a real dependency on SNES due to SNESGetKSP's special
>>> treatment of DMComposite+PCFieldSplit.
>>> Is there value in having DMMG usable in the absence of libpetscsnes
>>> (i.e. DMMGSetUp's dependency on SNES will be broken)?
>>> Jed

What most experimenters take for granted before they begin their experiments
is infinitely more interesting than any results to which their experiments
-- Norbert Wiener
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20100107/269d7a3d/attachment.html>

More information about the petsc-dev mailing list