[petsc-dev] Integrating PFLOTRAN, PETSC & SAMRAI

[Boyce Griffith]

On 6/6/11 5:38 PM, Barry Smith wrote:
>
> 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).

This is what I am currently doing, albeit in a much uglier fashion than 
via a VecGetData/VecRestoreData function/macro.

But if the model is that the Vec implementation is responsible for 
updating the state, then would it be better if PETSc did NOT increase 
the state, e.g., in calls to VecAXPY, or MatVecMult?  It seems like it 
might be better if it did not, so that if one has a non-"compliant" 
implementation, one finds out more quickly that their code is broken.

-- Boyce