The current implementation of MatMult_Scatter and MatMultTranspose_Scatter do not actually have matrix semantics unless the index sets are permutations. For example, it's generally desirable that
MatMult(A,x,y); agrees with VecZeroEntries(y); MatMultAdd(A,x,y,y); Similarly for MatMultTranspose. In addition, MatMultTranspose should actually be the transpose of MatMult. Consider the scatter defined by scatter : x -> y isx = [0 0] isy = [0 1] where x has length 1 and y has length 2. This forward scatter is equivalent to a 2x1 matrix A = [1;1] Indeed A*[1] = [1;1] but A'*[1;1] = [2] where as MatMultTranspose_Scatter(A,y=[1;1],x) gives x=[1]. This can be corrected by changing the body of MatMultTranspose_Scatter from ierr = VecScatterBegin(scatter->scatter,x,y,INSERT_VALUES,SCATTER_REVERSE);CHKERRQ(ierr); ierr = VecScatterEnd(scatter->scatter,x,y,INSERT_VALUES,SCATTER_REVERSE);CHKERRQ(ierr); to ierr = VecZeroEntries(y);CHKERRQ(ierr); ierr = VecScatterBegin(scatter->scatter,x,y,ADD_VALUES,SCATTER_REVERSE);CHKERRQ(ierr); ierr = VecScatterEnd(scatter->scatter,x,y,ADD_VALUES,SCATTER_REVERSE);CHKERRQ(ierr); and similarly for MatMult_Scatter. Unfortunately, these modifications roughly double the cost of typical sequential scatters and could be much worse (scattering from a small vector to a very large one). I think that correctness is more important here and users would typically not use MatScatter when this would have significant impact or when INSERT_VALUES semantics are desired. Of course some performance can be recovered by having MatScatter use INSERT_VALUES when the destination index set is a permutation. Also, what is the ssh url for the repo? I've tried some variations on ssh://petsc at petsc.cs.iit.edu/petsc/petsc-dev without success. Jed -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20090330/e5fffb2a/attachment.pgp>