[petsc-dev] DMGetMatrix --> DMGetMatrices?

[Dmitry Karpeev]

On Fri, Feb 10, 2012 at 7:02 PM, Barry Smith <bsmith at mcs.anl.gov> wrote:

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

I think SNES should make two callbacks -- one for each DM -- to have the
"user" (or an FEM library) compute J and J_pre.

Dmitry.

>
>   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.
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20120210/11b73b81/attachment.html>