[petsc-dev] DMGetMatrix --> DMGetMatrices?

[Dmitry Karpeev]

On Fri, Feb 10, 2012 at 12:11 AM, Jed Brown <jedbrown at mcs.anl.gov> wrote:

> On Fri, Feb 10, 2012 at 00:02, Dmitry Karpeev <karpeev at mcs.anl.gov> wrote:
>
>> Yes. And, by the way, preallocation for J and P could be different (e.g.,
>> mass matrix vs lumped mass matrix for projection problems).  As could be
>> the preferred MatType.
>
>
> This is not easy to encode in a DM, the user should do the allocation in
> this case (maybe another hook is needed).
>

The DM is the user here, or a proxy for the user. DM actually has all of
the mesh connectivity data necessary for preallocation, so doing it any
other way would basically involve passing the DM implementation as the user
context anyway.  It appears much more natural to have this as a DM method.
Of course, it is always possible to create
new matrices and allocate differently during a call to
SNESDMComputeJacobian, but then what is the purpose of DMGetMatrix?


I think returning two matrices is natural in the KSP context at any rate:
we always want a matrix and an approximation
to it to form the preconditioner.  It's the same in the SNES context -- the
Jacobian and an approximation.
I'm we could add something like DMGetOperators(DM dm, MatType jtype, Mat
*J, MatType ptype, Mat *P),
which mirrors the ultimate use of these matrices in KSPSetOperators.

Dmitry.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20120210/9c2a5c60/attachment.html>