Andrew Spott <[email protected]> writes: > In the slepc and petsc docs, is there a way to tell if a function is going to > copy, modify, or just “look” at a petsc object that is a parameter? > > > Specifically there are two examples that I’m curious about (I’m trying to > chase down a bug): > > > EPSSetOperators(EPS, Mat, Mat) > > > I know the first argument is changed, but are the two later arguments > modified? It appears that they are destroyed when EPSSetOperators is > called a second time (in STSetOperators), but this isn’t clear in the > API. After looking at the source, I assume that if I’m running an > eigensolve on the same Operator Matrix, but the matrix values have > changed, then I shouldn’t do another EPSSetOperators (or > EPSSetProblemType, EPSSetTarget, EPSSetDimensions, etc?). Is this > correct?
Actually, do call ESPSetOperators so that EPS knows the matrix has
changed. The "destroy" you see is just decrementing the reference
count (it won't drop to zero because you have an extra reference).
> VecDot(Vec,Vec,*PetscScalar)
>
>
> I assume that the two Vectors will not be changed, however it is hard
> to tell even from the source (it calls a function pointer which I
> don’t know how to find the source of).
I recommend using GNU Global, etags, or similar (see users manual for
more). Then you can tab-complete VecDot_MPI, for example. If you don't
know the types, one option is to break in the debugger and check the
function pointer.
> ps. what does “collective on {EPS,Mat,Vec,etc.}” mean?
It's MPI terminology, indicating that all processes on the given
communicator must call the function together. Usually that means
communication happens (or may happen). We say "logically collective" if
there is no communication, but parallel consistency requires a
collective call. (We might double-check for collective calls when
running in debug mode.)
signature.asc
Description: PGP signature
