[petsc-dev] TSComputeIFunction(): User or PETSc responsible for setting residual vector to zero?

[Jed Brown]

Brad Aagaard <baagaard at usgs.gov> writes:

> The PETSc manual pages do not mention whether or not the user is 
> responsible for setting the entries in the function vector to zero in 
> the user-defined ifunction and rhsfunction.

It's exactly like SNES; nothing is zeroed.

> In looking at the code it is clear TSComputeIFunction() does not set the 
> function vector entries to zero. For the function to be computed 
> correctly with the current code, the user must zero the function Vec 
> passed in to both the ifunction and rhsfunction. This seems like a bug 
> to me, because TSComputeIFunction() could potentially use a single 
> global Vec in computing the function from the ifunction and rhsfunction, 
> so a user zeroing the entries would result in incorrect values.
>
> It seems to be the code should behave like:
>
> TSComputeIFunction calls VecSet(residual, 0.0) BEFOERE calling ifunction 
> and rhsfunction.
>
> User ifunction calls scatter with ADD_VALUES
> User rhsfunction calls scatter with ADD_VALUES
>
> This way the user code is agnostic as to whether TSComputeIFunction() 
> passes in separate vecs to ifunction and rhsfunction or the same vec 
> with the proper -1 scaling done in between.

FD methods often just set the local entries in the global vector
directly so there is no scatter.  Yeah, it means the Vecs need to be
distinct and the implementation sums them later, but that isn't a big
deal and the confusion of expecting users to always add would be a major
source of bugs.  Semantics are identical to SNES.

> Whether or not TSComputeIFunction() is changed to zero out the function 
> Vec, I think the manual page should be updated to indicate to the user 
> whether the user function or PETSc function is responsible for zeroing 
> the function Vec.
>
> Thanks,
> Brad