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