[petsc-users] reference, copy or constant view?

[Andrew Spott]

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 <jed at jedbrown.org> wrote:

> Andrew Spott <ansp6066 at colorado.edu> 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.)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-users/attachments/20141210/15927687/attachment-0001.html>