[petsc-dev] DMMG without libpetscsnes?

[Barry Smith]

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.

    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