<div class="gmail_quote">On Sat, Nov 5, 2011 at 11:13, Brad Aagaard <span dir="ltr"><<a href="mailto:baagaard@usgs.gov">baagaard@usgs.gov</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div id=":zf">The error is in our inner solve (associated with computing the adjustment to the solution based on the friction criterion) for cases where not all processors have points on the fault. On processors without points on the fault the block size is -1 and the local size is 0. For processors with points on the fault, the block size is 3.<br>
</div></blockquote><div><br></div><div>How is this happening? MatSetBlockSize_MPISBAIJ raises an error if you try to change the block size. Are you messing with the PetscLayout directly or something?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div id=":zf">
<br>
I tried altering DMMeshCreateMatrix so that it uses a block size of 1 if bs==-1, but I still get the error. Does the block size need to be consistent across all processors, even those a local size of 0? Alternatively, is the local size of 0 causing problems?</div>
</blockquote></div><div><br></div>Yes, bs must be the same.<div><br><div>Since bs must be set for PetscLayoutSetUp() to succeed, the fact that you have bs=-1 means that function wasn't called. It could be memory corruption or it could be some manual fiddling with the PetscLayout. Somehow, you have bypassed several guards in the code that are supposed to cause errors with invalid input like this.</div>
<div><br></div><div>The local size of 0 should not cause a problem.</div></div>