[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