I would rather see then hierarchy change. I think it is natural for the operator<br>(Mat) to depend on the space (DM) on which it is discretized. Just because<br>shortsightedness in the past has confined us to really simple spaces (R^N)<br>
does not mean we can't change that.<br><br>  Matt<br><br><div class="gmail_quote">On Fri, Jan 1, 2010 at 1:19 PM, Jed Brown <span dir="ltr"><<a href="mailto:jed@59a2.org">jed@59a2.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Mat does not normally depend on DM, but a couple implementations do,<br>
<br>
  $ grep -rl DAGet petsc/src/mat/impls<br>
  petsc/src/mat/impls/hypre/mhyp.c<br>
  petsc/src/mat/impls/adic/nladic.c<br>
  petsc/src/mat/impls/adic/matadic.c<br>
<br>
So when these are enabled, all the Mat examples fail to link because<br>
PETSC_MAT_LIB does not include PETSC_DM_LIB.  This is especially<br>
annoying to me because the PETSc builds I use have Hypre enabled,<br>
meaning that I need to keep more special testing builds (without Hypre)<br>
just to be able to run the Mat tests.<br>
<br>
Is the HYPREStruct stuff destined to eventually move out of Mat?<br>
<font color="#888888"><br>
Jed<br>
</font></blockquote></div><br><br clear="all"><br>-- <br>What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead.<br>-- Norbert Wiener<br>