[petsc-dev] Integrating PFLOTRAN, PETSC & SAMRAI

[Barry Smith]

On Jun 6, 2011, at 4:23 PM, Boyce Griffith wrote:

> 
> 
> On 6/6/11 5:11 PM, Jed Brown wrote:
>> On Mon, Jun 6, 2011 at 23:09, Boyce Griffith <griffith at cims.nyu.edu
>> <mailto:griffith at cims.nyu.edu>> wrote:
>> 
>>    Oh, right, except that getVector() is called even on Vec's that are
>>    not modified.
>> 
>> 
>> What comes out of getVector()? Is it an object that can keep track of
>> whether it is modified?
> 
> Not without hacking up SAMRAI itself (effectively duplicating all of the state tracking stuff that is handled by PETSc).

  Boyce,


   The point would be that the wrapper code would never access vec->data directly. Instead have two macros

    #define VecGetSAMRAIData(vec)   (SAMRAI caste needed) (vec->hdr.state++,vec->data)      and

   #define VecGetSAMRAIDataRead(vec)      (SAMRAI caste needed)  (vec->data)     

no changes to SAMRAI needed at all. And it always increases the state when needed and does not when not needed.

   Barry
 
We should document this business somewhere.


> 
> One somewhat unappealing option would be to punt this to the user --- and to require them to know whether or not the thing that came out of getVector() has been modified.
> 
>> If your programming model uses RAII, the destructor can also be used to
>> propagate state.
> 
> Destructors don't get called within calls to KSPSolve()/SNESSolve() (unless called via PETSc internals).
> 
> -- Boyce