<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Feb 18, 2013 at 3:36 PM, Mark F. Adams <span dir="ltr"><<a href="mailto:mark.adams@columbia.edu" target="_blank">mark.adams@columbia.edu</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div>The logic here is messed up.  Valid input could result in a non-collectiv result.  So this DEBUG code should be a real check here.  I think the logic is OK to detect a blocked garray locally … but some processors could be proper and others not as Jed pointed out.</div>
</blockquote><div><br></div><div style>We either need to do the reduction always or make the normal code path safe always.</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div class="im"><blockquote type="cite"><div dir="ltr"><div><div class="gmail_extra"><div class="gmail_extra">It seems to me that we should either (a) explicitly disallow matrices with a block size to be built when the blocks are not filled or (b) when the user requests blocks, pad blocks so that we can always use an ISBlock.</div>

</div></div><div><div class="gmail_extra"><div><br></div></div></div></div></blockquote><div><br></div></div><div>It looks like we have (a) now in a debug build.  </div></blockquote><div><br></div><div style>Well, only indirectly because this check will fire. We still have (a) in optimized mode in the sense that some procs will call ISCreateGeneral while others call ISCreateBlock, leading to a crash or deadlock.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div>I'm  not wild about (b), this is only used to use blocked IS for efficiency and we have never measure that this is useful.</div>
</blockquote><div><br></div><div style>I don't know if Barry has measurements from when he originally added the feature</div><div style><br></div><div style><a href="https://bitbucket.org/petsc/petsc-dev/commits/4442702a5bc776781b96301ae6b1541cf7cf1fc2#chg-src/mat/impls/aij/mpi/mmaij.c">https://bitbucket.org/petsc/petsc-dev/commits/4442702a5bc776781b96301ae6b1541cf7cf1fc2#chg-src/mat/impls/aij/mpi/mmaij.c</a></div>
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div><br></div><div>So I will comment out the whole 'useblockis' business and let Garth move along.  We could do an all reduce to see if everyone is blocked and then, and only then, use th blocked ISs. This would cost an alreduce.  Not sure what would be better, but for now we can just disable this.</div>
</blockquote></div><br>This is clearly wrong in the release too. I'm inclined to delete the entire useblockis code path since it seems like it will need to be implemented completely differently (if it matters for performance).</div>
</div>