[petsc-dev] DMMG without libpetscsnes?

[Barry Smith]

On Jan 7, 2010, at 10:32 AM, Matthew Knepley wrote:

> 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.

    My point is that if KSP/PC has this builder capability then there  
is no reason for DMMG to exist. Of course, one could keep DMMG but it  
would be redundant (and there would be two ways to do things hence  
confusion), so by Barry's PETSc Law, DMMG would be tossed into the  
trash bin of history as a slight misstep on the road to PETSc  
perfection :-)

    Barry

>
>   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