On Jun 6, 2011, at 4:33 PM, Boyce Griffith wrote:
>
>
> On 6/6/11 5:23 PM, Barry Smith wrote:
>>
>> Jed,
>>
>> Though VecRestoreArray() does increase the Vector state, we also have
>> our base Vec class methods (and MatMult and friends) ALSO increase the state
>> on appropriate Vec arguments (so for built-in Vec classes like VECSEQ the
>> state is increased twice) . So for all of those routines there is no reason
>> for an alternative Vec class to manage the state itself. Thus is it not
>> completely unreasonable for Boyce (and people in similar situations) to ask
>> that they never need to manage the state themselves. They do need to
>> because of SNESComputeFunction().
>
> I don't mind managing state per se --- it just seems confusing to have to
> know/remember that FormFunction() needs an state increase but, e.g.,
> MatVecMult doesn't.
>
> E.g., looking at the wrapper code a few years down the road, I will probably
> have forgotten the details of this email thread, and I might be tempted to
> remove PetscObjectStateIncrease from FormFunction because I don't see it used
> in any other parts of the wrapper, which may or may not be a mistake.
>
> I guess that my point is that right now, there does not seem to be a good way
> to find out where one needs to call PetscObjectStateIncrease() other than
> asking petsc-dev at mcs.anl.gov. :-)
Any vector that you change the values in you need to increase the state.
Using the "macros" I sent you is a consistent way to manage that. (Now for
whatever historical reason we also increase the state automatically in all
appropriate Vec and Mat operations so you do not always need to increase the
state but the model is that you should always).
Barry
>
> -- Boyce
