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 >