Hi Barry, It happens to all of us. ;) So probably you're right about MatGetArray, I would be happy to check it if not another error I got on MatGetArrayF90... I sent it as a separate branch.
Thanks a lot for clarification. Regards, Alexander On 17.06.2011 01:17, Barry Smith wrote: > I am afraid that Jed gave you some misinformation on this response that > led you guys off the trail a bit. This is the first mistake I've seen Jed > make in the three years I've known him (as opposed to Matt and I who make > mistakes everyday :-)) so don't be too hard on him. > > MatGetArray() on dense matrices returns a pointer to the entire local > matrix stored in column major order (Fortran style), thus you can call > MatGetArray() and then muck with all the local entries very efficiently since > you are just doing direct array access. > > Hope I am right (and this is not my daily mistake) and this helps you, > > > Barry > > Dang proposal issues most of the day so not able to read email until now. > > > On Jun 16, 2011, at 6:10 AM, Jed Brown wrote: > >> On Thu, Jun 16, 2011 at 12:59, Alexander Grayver<agrayver at gfz-potsdam.de> >> wrote: >> ! store transformed elements >> call >> MatSetValues(A,1,rowidx,nvals,cols,transformedvals,INSERT_VALUES,ierr);CHKERRQ(ierr); >> call MatRestoreRow(A,i,nvals,cols,vals,ierr);CHKERRQ(ierr); >> >> You can't mix these because MatGetRow() needs an assembled matrix, and >> MatSetValues() makes the matrix be unassembled. >> >> What do you want the parallel semantics to be during this transformation? >> >> The MatGetArray() for MPIDense just gives you access to the "diagonal" block. >> >> What is the high-level description of the operation you're trying to do? Is >> this "matrix" actually being used as a linear operator, or is it a grid of >> values?
