[petsc-dev] Error checking on input only vectors

[Barry Smith]

On Jul 16, 2013, at 9:34 AM, Matthew Knepley <knepley at gmail.com> wrote:

> On Tue, Jul 16, 2013 at 9:15 AM, Karl Rupp <rupp at mcs.anl.gov> wrote:
> Hey,
> 
>     As an extra error checking on user code we could save the Vec state of read only input Vecs and check it on exit of the routine to insure the user has not changed the Vec. This could be done in PCApply_Shell(), functions provided to SNES and TS etc.
> 
> we could do that, but I think this would slow the debug build down by quite a substantial amount (VecGetArrayRead() is used quite a lot internally as well), resulting in users to go with optimized builds during the development phase more often. Also, since VecGetArrayRead() returns a pointer to const, a user needs to cast away the const in order to manipulate entries, which already serves as an indication of doing something evil.
> 
> I think Barry is only suggesting we save the state integer.

   Yes, extremely fast.

   Barry

> 
>    Matt
>  
> What about a second debug level instead, something like 'PETSC_DEBUG_EXTRA', which enables additional, more expensive checks like the one you suggested? We could do similar valgrind-like checks for matrices, etc. there.
> 
> Best regards,
> Karli
> 
> 
> 
> On Jul 16, 2013, at 8:08 AM, Rémi Lacroix <remi.lacroix at inria.fr> wrote:
> 
> Hello,
> 
> I'm currently developing a preconditioner using PETSc. I have a small question about the PCApply function.
> 
> Is it safe to destroy the content of the input vector x while applying the preconditioner or should I make a copy of it and work on that?
> 
> Best regards,
> 
> --
> Rémi Lacroix
> Équipe ALPINES
> Inria Paris-Rocquencourt / Laboratoire Jacques Louis Lions, UPMC
> 
> 
> 
> 
> 
> 
> -- 
> What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead.
> -- Norbert Wiener