[petsc-dev] DMGetMatrix --> DMGetMatrices?

Dmitry Karpeev karpeev at mcs.anl.gov
Fri Feb 10 16:13:38 CST 2012


On Fri, Feb 10, 2012 at 4:05 PM, Jed Brown <jedbrown at mcs.anl.gov> wrote:

> On Fri, Feb 10, 2012 at 15:59, Matthew Knepley <knepley at gmail.com> wrote:
>
>> This makes no sense to me unless the two matrices being returned have
>> different sparsity patterns, and we have no
>> good way for specifying that, or even a good rationale for doing it.
>>
>
> Preconditioning with a STAR stencil is often pretty good.
>
> Dmitry is suggesting specifying it by having two "slots" in which we can
> request a matrix.
>
> DMSetMatrixPreallocateOnly(), DMSetMatrixType(), and perhaps a couple
> others would need two arguments so the two matrices can be addressed
> separately.
>
> It's not clear to me that two is always the right number of ways to
> distinguish matrices.
>

Well, two is the number that's used in KSP and SNES.

With the current API SNES actually uses the same matrix for the Jacobian
and preconditioner, if the matrix is obtained from a DM, which is limiting.
 It is natural to have a "geometric" backend (e.g., libMesh or MOOSE)
interact with the algebraic objects (PETSc's SNES, KSP) through the DM as
much as possible, since the DM (its impl, rather) carries all of the
necessary mesh and discretization information in one place. Yet, currently
this interaction is limited as compared to the "bare" SNES/KSP interface,
in part because of the one matrix limitation.

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


More information about the petsc-dev mailing list