<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Thu, Nov 15, 2018 at 2:03 PM Jed Brown via petsc-dev <<a href="mailto:petsc-dev@mcs.anl.gov">petsc-dev@mcs.anl.gov</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">A user can currently get a sub-matrix of a MatNest and modify it without<br>
it updating the MatNest's state.  This may require a manual call to<br>
PetscObjectStateIncrease so that the PC knows that it needs to rebuild,<br>
but this is ugly/complicated/error-prone.  Some possible options off the<br>
top of my head:<br>
<br>
1. Insist that the user call MatNestSetSubMats() after any modification.<br>
<br>
2. Make MatNestRestoreSubMats and MatNest{Get,Restore}SubMatsRead so<br>
that mutable access is controlled.<br></blockquote><div><br></div><div>I like 2. the best. Its the most like other PETSc interfaces and most explicit. I don't</div><div>think its really any overhead from what we do now.</div><div><br></div><div>   Matt</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
3. Add a hook to PetscObjectStateGet that can traverse child objects in<br>
case its own state counter is stale.  This is the most automatic, but<br>
I'm concerned about its potential complexity.<br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div>What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead.<br>-- Norbert Wiener</div><div><br></div><div><a href="http://www.cse.buffalo.edu/~knepley/" target="_blank">https://www.cse.buffalo.edu/~knepley/</a><br></div></div></div></div></div></div></div></div>