<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Apr 25, 2012, at 7:15 PM, Jed Brown wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div class="gmail_quote">On Wed, Apr 25, 2012 at 17:58, Mark F. Adams <span dir="ltr"><<a href="mailto:mark.adams@columbia.edu">mark.adams@columbia.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
The blocks are not always dense, so by what appears to be your definition of block size it is not (always) a 'column block size'. But I think that it is semantically a blocked matrix and hence it has a column block size.</blockquote>
</div><br><div>I think we shouldn't try to encode the near-null space being sparse. For elasticity, we would only reduce the 18 matrix entries to 12, which is only about break-even on storage since the dense null space can use fewer column indices (this is ignoring the dense case also being more efficient).</div>
</blockquote></div><br><div>Its worse than that in aggregation MG, I think, because P is not the null space but Q in a QR decomposition of the rigid body modes ... that might still have some sparsity, not sure.</div></body></html>