[petsc-dev] MatGetRowSum implementation

Barry Smith bsmith at mcs.anl.gov
Fri Jul 21 16:28:09 CDT 2017

  I don't see any problem with changing it to using MatMult() or better to add it to the matrix function table and use MatMult() if no function is provided. This way you'll get the no communication cost for MPI*AIJ matrices once they are coded.


> On Jul 21, 2017, at 4:09 PM, Jed Brown <jed at jedbrown.org> wrote:
> 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)?

More information about the petsc-dev mailing list