On Tue, May 26, 2009 at 2:10 PM, Jed Brown <jed at 59a2.org> wrote: > 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 > map. > > 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?
I am fine with this too, which is option 1 in my original mail. However, this means that when users preallocate, they must understand the column layout. I guess this is better than changing the code unless I can think of a case where is plainly does not apply. Matt > > Jed > > -- What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead. -- Norbert Wiener -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20090526/1c505c8b/attachment.html>