<br><br><div class="gmail_quote">On Fri, Feb 10, 2012 at 4:00 PM, Jed Brown <span dir="ltr"><<a href="mailto:jedbrown@mcs.anl.gov">jedbrown@mcs.anl.gov</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div class="im"><div class="gmail_quote">On Fri, Feb 10, 2012 at 15:58, Dmitry Karpeev <span dir="ltr"><<a href="mailto:karpeev@mcs.anl.gov" target="_blank">karpeev@mcs.anl.gov</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">


<div>It seems to me that the sparsity pattern (and even the type of the matrices) is up to the particular DM type,</div><div>so it is, in principle, opaque.  DMDA can control it by manipulating stencil width or widths, while FEM-oriented DM </div>




<div>types (e.g., libMesh) could control it via the element type, etc. The generic DM interface doesn't have a way to specify </div><div>the sparsity pattern. As it should be, in my opinion.</div></blockquote></div><br>


</div><div>Yes, it's fine for DM to have a way to allocate a sparser preconditioning matrix. The most common case in practice is MFFD for the true Jacobian and more compact stencil for the preconditioner. It just makes the interface and implementation a bit ugly/confusing to support both. It would be nice to have a more elegant way to state it.</div>

</blockquote><div> </div><div>No uglier than having SNES/KSP take in two matrices, in my view. </div><div><br></div><div>Dmitry.</div></div><br>