On Apr 25, 2012, at 6:10 PM, Barry Smith wrote: > > On Apr 25, 2012, at 4:58 PM, Jed Brown wrote: > >> On Wed, Apr 25, 2012 at 16:41, Barry Smith <bsmith at mcs.anl.gov> wrote: >> I admit MatSetVirtualColumnBlockSize() is clunky and would be happy to hear >> alternatives. >> >> 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. > > Mark told me in a earlier email that the "column block size" isn't really > the column block size (except in some cases), since it is not really a column > block size I don't want the matrix to list it as the column block size (hence > my virtual column block size thing).
The blocks are not always dense, so by what appears to be your definition of block size it is not (always) a 'column block size'. But I think that it is semantically a blocked matrix and hence it has a column block size. > > If it is truly a column block size then great, P is given the column block > size with MatSetColumnBlockSize() or MatSetBlockSizes(mat,col,row) and PtAP > automatically uses that column block size for the resulting matrix block size. > I think this solution is the best (eg, no 'virtual'). Column block size is a fundamental property of a blocked matrix. PETSc's current implementations do not exploit or accommodate this but since it is a fundamental property I do not mind cluttering up Mat with yet another parameter. You deal with rectangular matrices, and blocked matrices, why not rectangular blocks? You also have row block size on AIJ matrices that do not have dense blocks so why not column block size? Mark > So Mark I ask you again, in GAMG is it truly a column block size? > > Barry > > >
