[petsc-dev] DMMG without libpetscsnes?

[Matthew Knepley]

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

>
> On Jan 7, 2010, at 10:10 AM, Matthew Knepley wrote:
>
>  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?
>>
>
>  Not exactly. In the same way that in PETSc a Mat is also a factory for
> matrices I want KSP/PC to be "builders" for themselves. So there is no DMMG
> at all, its "builder" functionality is properly put into KSP/PC.
>

These ideas are not orthogonal. KSP could build part of itself, and DMMG
build another part, or rebuild something.

  Matt


>   Barry
>
>
>
>>   Matt
>>
>>  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
>> s.PETSCSNES_DLLEXPORT.PETSCKSP_DLLEXPORT., but DMMGSetUp (in damgsnes.c)
>> 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 lead.
>> -- Norbert Wiener
>>
>
>


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