<div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Apr 25, 2012 at 4:58 PM, Jed Brown <span dir="ltr"><<a href="mailto:jedbrown@mcs.anl.gov" target="_blank">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 Wed, Apr 25, 2012 at 16:41, Barry Smith <span dir="ltr"><<a href="mailto:bsmith@mcs.anl.gov" target="_blank">bsmith@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">


 I admit MatSetVirtualColumnBlockSize() is clunky and would be happy to hear alternatives.</blockquote></div><br></div><div>What about having a separate row and column block size? The BAIJ and MAIJ formats can continue to store data using bs=gcd(rowbs,colbs), but those row and column block sizes indicate that redundancy exists in the data structure, so it can be utilized by appropriate operations.</div>

</blockquote><div>I agree.</div><div>In fact, P's "column block size" (cbs) has exactly that meaning in the GAMG code (e.g., formProl0() in gamg/agg.c) -- it sets matrix values in adjacent multiples of cbs within each row. MatPtAP() could easily impart that block size (cbs = rbs, in this case) to its result.  This way the meaning of "column block size" and "row block size" are meaningful for any matrix and not just within some particular context.</div>

<div><br></div><div>Dmitry.</div></div><br></div>