I'm fine with just deleting it.
On Feb 18, 2013, at 3:44 PM, Jed Brown <jedbrown at mcs.anl.gov> wrote: > > On Mon, Feb 18, 2013 at 3:36 PM, Mark F. Adams <mark.adams at columbia.edu> > wrote: > 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. > > We either need to do the reduction always or make the normal code path safe > always. >> 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. >> > > It looks like we have (a) now in a debug build. > > 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. > > 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. > > I don't know if Barry has measurements from when he originally added the > feature > > https://bitbucket.org/petsc/petsc-dev/commits/4442702a5bc776781b96301ae6b1541cf7cf1fc2#chg-src/mat/impls/aij/mpi/mmaij.c > > > 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. > > 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).
