[petsc-dev] MatGetRowSum implementation
Jed Brown
jed at jedbrown.org
Fri Jul 21 16:09:58 CDT 2017
Is there any reason MatGetRowSum is implemented in terms of MatGetRow
instead of by creating a vector of ones and using MatMult? Implementing
MatGetRow is onerous for some formats including matrix-free
representations, and this is relevant for Jacobi preconditioning which
is popular for such representations.
ierr = VecGetArray(v, &array);CHKERRQ(ierr);
for (row = start; row < end; ++row) {
PetscInt ncols, col;
const PetscInt *cols;
const PetscScalar *vals;
array[row - start] = 0.0;
ierr = MatGetRow(mat, row, &ncols, &cols, &vals);CHKERRQ(ierr);
for (col = 0; col < ncols; col++) {
array[row - start] += vals[col];
}
ierr = MatRestoreRow(mat, row, &ncols, &cols, &vals);CHKERRQ(ierr);
}
ierr = VecRestoreArray(v, &array);CHKERRQ(ierr);
Note that it is currently marked Logically Collective, which is only
possible for matrices that use a typical row distribution, but not for a
MATIS or MATELEMENTAL. If we add an implementation in terms of MatMult,
it will become Neighborhood Collective. Since MatGetRow is rather slow
for MPI* matrices, would it be reasonable to replace the current
implementation or better to switch on MatHasOperation(mat,MATOP_GET_ROW)?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20170721/37ed8a0b/attachment.sig>
More information about the petsc-dev
mailing list