[petsc-dev] Mat/DM dependency

[Dmitry Karpeev]

Sorry for jumping in late.
PDE discretizations and solvers many geometric decompositions of the
linear space
they ultimately operate on.  However, many of these decompositions can
be expressed
rather naturally in linear algebraic terms (e.g., "factorization" of
the stiffness matrix into
a "sum" of element matrices in FEM).  The gather-scatter matrices that
glue together
the element matrices are largely independent of the operator and
encode the decomposition
of the global function space into elementwise pieces.  This is merely
a linear algebraic
form of the underlying partition of unity and, again, can be cast in
purely algebraic terms
as a decomposition of the identity operator:  I = \sum_i R_i P_i
where P_i is the projector onto the ith piece and R_i is the injection
back into the larger space.
This is formalism that a lot of BDDC is built around (e.g., J. Mandel,
C. Dohrmann,
Numer. Linear Algebra Appl. 2003; 10:639–659).

Automating decomposition/assembly of operators relative to a
decomposition of identity (doi)
would, in my opinion, go a long way towards decoupling Mat from DM.
DM would then convert
their geometric data into a corresponding doi and Mat wouldn't need to
know about DMs directly.
That's what I'm trying to do with MatFwk -- a framework for general
block decompositions of matrices,
but that's been moving rather slowly.  One particularly interesting
aspect is the need to deal with
dual-primal decompositions that require elimination of constraints or
introduction of Lagrange multipliers.
Mortar elements are a relatively simple example of that.

Incidentally, there are similar Mat/DM dependence problems with
wavelet(-like) transforms, including
USFFT, that we've been trying to introduce into PETSc.

Dmitry.




On Sat, Jan 2, 2010 at 12:48 PM, Matthew Knepley <knepley at gmail.com> wrote:
> On Sat, Jan 2, 2010 at 12:44 PM, Barry Smith <bsmith at mcs.anl.gov> wrote:
>>
>> On Jan 1, 2010, at 7:12 PM, Jed Brown wrote:
>>
>>> On Fri, 1 Jan 2010 14:50:33 -0600, Matthew Knepley <knepley at gmail.com>
>>> wrote:
>>>>
>>>> That is definitely a problem.
>>
>>  I am not convinced yet that this is a problem. The dependency is only in
>> one specific Mat implementation that should not require pulling in the DM
>> library unless that specific Mat implementation is specifically used. Since
>> that specific Mat implementation is not used in the Mat examples it should
>> not require pulling in the DM library.
>
> If it is not a practical problem, I still believe it is a conceptual
> problem.
>
>   Matt
>
>>
>>   Barry
>>
>>
>>>> It makes me think we need an R^N part just
>>>> like we have now, and then a more general part with operators on fiber
>>>> bundles.
>>>
>>> The question is whether it is important to separate that stuff (which
>>> depends on both Vec and DM) from DM (which already depends on Vec).
>>>
>>> Jed
>>
>
>
>
> --
> What most experimenters take for granted before they begin their experiments
> is infinitely more interesting than any results to which their experiments
> lead.
> -- Norbert Wiener
>