On Mon, Jun 6, 2011 at 23:23, Barry Smith <bsmith at mcs.anl.gov> wrote:
> They do need to because of SNESComputeFunction(). > It might be worth incrementing it here redundantly. > > 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? > 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. It's just a matter of how much norm-like stuff the user might reasonably be expected to do in their FormResidual(). -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20110606/2a96f38e/attachment.html>
