Problem with rectangular matrices

Jed Brown jed at
Tue May 26 14:10:55 CDT 2009

Matthew Knepley wrote:

> Yes, I want to go into the code and every place we query the diagonal
> block, replace cMap by rMap. This is the only thing that makes sense
> to me. By my definitions, diagonal blocks are disjoint, so they must
> be square. Since we normally own rows, it makes sense to use row
> blocking to define them.

This seems very wrong to me.  The diagonal block is the part of the
matrix that is applied to a local part of the vector.  In other words,
it's the A part of Mat_MPIAIJ and the off-diagonal part is the B part.
It doesn't make any sense to me to redefine these based only on the row

Maybe I'm misunderstanding you though.  In any case, the actual diagonal
of a non-square matrix has very little to do with the distribution (it's
not in the A block), and I don't see where it's terribly useful.  What
specifically are you suggesting to change?

> I think there is an inconsistency in our definitions. If you create a matrix which
> is 4x8 on 2 procs, then you end up with a row and column map like this:
>     rowMap           colMap
>   [0..2) [2..4)      [0..4) [4..8)
> However, we use the column map for queries which then give nonsense. The most
> damaging is in MatSetValues(). If I give a value for (2,2) on proc 1, then since
> 2 < cstart = 4, this value is considered "off-diagonal"

I think this is correct.  When we apply to a vector, entry 2 (owned by
rank 0) must be gathered, thus it is in mpiaij->B (the diagonal block is
mpiaij->A).  Setting (2,4) on proc 1 should go in the diagonal block.
Is this usage inconsistent?


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 260 bytes
Desc: OpenPGP digital signature
URL: <>

More information about the petsc-dev mailing list