Question on adding matrix rows and columns

[Barry Smith]

    Because the default PETSc matrix formats AIJ, BAIJ, SBAIJ are row  
oriented accessing by row is easy (and reasonably efficient) but  
accessing
by column is NOT.

    First think about the operation you need to perform at the highest  
level of abstraction (Hint that is not a set of MatGetRow() calls).
Second you might just write the code that does whatever this is using  
the specific data structures of the sparse matrices, NOT through a  
bunch of calls to MatGetRows()
etc.  There is nothing that says you should never work directly with  
the matrix data structures.

> A bit weired workaround would be to transpose A each time a column  
> needs to be accessed and use MatGetRow() etc. again and retranspose  
> afterwards. Or copying the transpose of A into another matrix  
> meaning twice the amount of data in the RAM which I would like to  
> avoid.

    This may not be totally weird. Some kind of processing of the data  
into another form that makes what you need to access easy is sometime  
the way to go.

    Barry


On Feb 28, 2009, at 10:58 AM, Tobias Neckel wrote:

> Hello,
>
> I need to weight and add a certain number of rows and columns from  
> one matrix (A) into another one (B) where I just know the  
> corresponding row and column indices, but not the indices of the  
> entries inside one row or one column.
>
> For the rows, I managed to do so by calling MatGetRow() (and  
> MatRestoreRow()) on A, getting the corresponding column indices and  
> values to work with and add into B.
>
> For the columns, however, I just found MatGetColumnIJ() and  
> MatGetColumnVector() in the online manual.
> The first seems to give access to columns and corresponding indices,  
> but I am not sure if n corresponds to the total number of columns or  
> just all non-zero columns.
> The latter (besides the warning of possibly being slow) seems to  
> return the complete vector of values, but no indices. Is my  
> interpretation correct so far?
>
> A bit weired workaround would be to transpose A each time a column  
> needs to be accessed and use MatGetRow() etc. again and retranspose  
> afterwards. Or copying the transpose of A into another matrix  
> meaning twice the amount of data in the RAM which I would like to  
> avoid.
>
> What would you suggest to do?
>
> Thanks and best regards
> Tobias
>
> -- 
> Dipl.-Tech. Math. Tobias Neckel
>
> Institut für Informatik V, TU München
> Boltzmannstr. 3, 85748 Garching
>
> Tel.:   089/289-18602
> Email:  neckel at in.tum.de
> URL:    http://www5.in.tum.de/persons/neckel.html