On 11/5/11 10:25 AM, Jed Brown wrote: > On Sat, Nov 5, 2011 at 11:13, Brad Aagaard <baagaard at usgs.gov > <mailto:baagaard at usgs.gov>> wrote: > > 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. > > > 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? > > > 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? > > > Yes, bs must be the same. > > 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. > > The local size of 0 should not cause a problem.
It looks like Matt is calling Sieve layout stuff in DMMeshCreateMatrix(). I don't see any calls to MatSetBlockSize. Brad
