On Feb 10, 2012, at 6:45 PM, Dmitry Karpeev wrote: > > > On Fri, Feb 10, 2012 at 5:24 PM, Barry Smith <bsmith at mcs.anl.gov> wrote: > > On Feb 10, 2012, at 5:14 PM, Jed Brown wrote: > > > On Fri, Feb 10, 2012 at 17:08, Dmitry Karpeev <karpeev at mcs.anl.gov> > > wrote: > > I think it's completely natural for a DM to assemble two operators -- the > > discretizations for the two are likely to be related anyway -- as soon as > > we decide that it's natural for KSP to take in two matrices and, more > > importantly, for the callback set with DMSetJacobian() to compute two > > matrices: if a DM knows how to compute two "Jacobians", > > DM doesn't/shouldn't know how to compute two Jacobians. Where did you get > that from? > > Here's the current declaration of DMSetJacobian: > PetscErrorCode DMSetJacobian(DM dm,PetscErrorCode > (*f)(DM,Vec,Mat,Mat,MatStructure*)) > This attaches (to a single DM) a callback that computes *two* matrices, just > like SNES/KSP would want.
You are right this is odd now and eventually needs some kind of fixing. I kept the two Mats to match the SNESSetJacobian(). Of course we cannot really use it since a DM can only give back one matrix. Shouldn't this be changed to the function f taking two DMs? Barry > Dmitry. > > > why wouldn't it know how to create/preallocate the two corresponding > > matrices? > > > The reason I don't like having the single DM doing this is that one could > use very different beasties to do the true Jacobian and preconditioner (not > just a simple stencil change) and shoving that stuff into a single DM is > unnatural. For example true problem is on an unstructured grid, > preconditioner problem on a simplier structured grid. > > > > > > Lots of functions get messy if the DM has multiple ways to do something. > > Should DMCreateLocalVector() use the full stencil or the preconditioning > > stencil, what should DMGlobalToLocalBegin() be updating, etc. > > > > Barry's solution of having separate DMs sounds cleaner to me, at least > > modulo needing conventions about which DM on which to PetscObjectCompose() > > things needed by certain callbacks (e.g. in the FAS with TS stuff I'm > > doing). > > Clean that up and provide a formal way to do those callbacks that don't use > kludgy PetscObjectCompose() or PetscObjectComposeFunction() > > Barry > > Yes, it will be slightly painful to pass two DM into the KSP and PC and track > them in multigrid but we do do that with the two operators already so using > two DM seems very natural. >
