[petsc-dev] Integrating PFLOTRAN, PETSC & SAMRAI

[Boyce Griffith]

On 6/6/11 4:59 PM, Jed Brown wrote:
> On Mon, Jun 6, 2011 at 22:49, Boyce Griffith <griffith at cims.nyu.edu
> <mailto:griffith at cims.nyu.edu>> wrote:
>
>     I stash a pointer to the SAMRAI vector object in the PETSc Vec as
>     vec->data.
>
>
> Great, somewhere in your FormResidual(), you access this data. Otherwise
> there would be no way for you to change the output data (unless you did
> some sort of hidden sharing which would be super fragile). So why not
> have that API increment the state? For example, VecRestoreArray()
> increments state for PETSc vectors. Since everyone accesses the vector
> through this API, they never have to call PetscObjectStateIncrease()
> themselves.

I never call VecGetArray() / VecRestoreArray() --- it doesn't really 
make sense here because there is no single array associated with the 
data.  In fact, the wrapper class sets ops->getarray to PETSC_NULL.

> Why not have your accessor manage the state? This would be the logically
> consistent way to do it.

I agree --- right now, I have a getVector() method but no 
restoreVector() method.  Probably the right thing to do is to have a 
restoreVector() function that updates the state.

>     At least when this stuff was first written, the only way to
>     interface the SAMRAI vector class with PETSc was to make a new
>     "subclass" of Vec.
>
>
> This is still a good way as long as SAMRAI is storing the Vec data
> non-contiguously. If it's stored contiguously, then a normal Vec could
> use it. You could use PetscObjectCompose() to attach your SAMRAI
> structure for when you need the "extra" information. Either SAMRAI or
> PETSc could "own" the pointer.

Sadly, SAMRAI data are not contiguous.

-- Boyce