<div class="gmail_quote">On Mon, Jun 6, 2011 at 23:23, Barry Smith <span dir="ltr"><<a href="mailto:bsmith@mcs.anl.gov">bsmith@mcs.anl.gov</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div id=":g4">They do need to because of SNESComputeFunction().<br></div></blockquote><div><br></div><div>It might be worth incrementing it here redundantly.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div id=":g4">
<br>
Since VecRestoreArray() increases the state one could argument that we should remove all the state increase calls in the Vec base classes and Mat and always rely on VecRestoreArray(). And hence require all other Vec implementations to manage the state completely themselves?</div>
</blockquote></div><br><div>That would be logically consistent, but it's fragile so it would need a very good test suite. Incrementing the state redundantly is not expensive. Incrementing state when it has not been modified is expensive. If the user computes a norm inside their FormResidual() evaluation, it can't be reused if state is incremented outside. If it's pre-incremented, then (hypothetically) a CFL check or constraint satisfaction computed in advance by the nonlinear solver would not be available inside.</div>
<div><br></div><div>It's just a matter of how much norm-like stuff the user might reasonably be expected to do in their FormResidual().</div>