<div class="gmail_quote">On Mon, Jun 6, 2011 at 22:49, Boyce Griffith <span dir="ltr"><<a href="mailto:griffith@cims.nyu.edu">griffith@cims.nyu.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div id=":3df"> I stash a pointer to the SAMRAI vector object in the PETSc Vec as vec->data.<br></div></blockquote><div><br></div><div>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.</div>
<div><br></div><div>Why not have your accessor manage the state? This would be the logically consistent way to do it.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div id=":3df">
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.</div></blockquote></div><br><div>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.</div>