Thanks for the help regarding etags. I used to have them set up, I’ll have to reconfigure them.
>Actually, do call ESPSetOperators so that EPS knows…. Unfortunately this just confused me more. Am I reading this correctly in that doing: EPSSetOperators(eps, *A, PETSC_NULL); EPSSetProblemType(eps, EPS_HEP); EPSSetType(eps, EPSKRYLOVSCHUR); EPSSetWhichEigenpairs(eps, EPS_TARGET_REAL); EPSSetTarget(eps, -0.903801); EPSSetDimensions(eps, 1000, PETSC_DEFAULT, PETSC_DEFAULT); EPSSetInitialSpace(eps,1,&eigenvector); EPSSolve(eps); Won’t actually change *A? What about VecDot? Thanks again, -Andrew On Wed, Dec 10, 2014 at 10:30 AM, Jed Brown <[email protected]> wrote: > 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.)
