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>