[petsc-dev] Domain error in SNESComputeJacobian()?

Dmitry Karpeyev karpeev at mcs.anl.gov
Thu Jun 4 16:41:53 CDT 2015


On Thu, Jun 4, 2015 at 3:15 PM Barry Smith <bsmith at mcs.anl.gov> wrote:

>
> > On Jun 4, 2015, at 3:35 PM, Dmitry Karpeyev <karpeev at mcs.anl.gov> wrote:
> >
> > We don't check for domainerror in SNESComputeJacobian(), but it may very
> well occur there. It would cost a reduction, of course, but the alternative
> is to set a Jacobian entry to Inf and wait for the nearest MatMult(),
> VecNorm() combination to propagate it.
>
>   What is the harm in this, as soon as the user sets the inf they can skip
> the rest of the Jacobian setting values on that process.
>

The "harm" is that, even though the rest of the Jacobian assembly is
skipped, at least a MatMult() (and probably a PCApply()?) is done before
the first norm is computed in KSP (unless -ksp_type none is used).

However, never mind --
I agree that letting an Inf/Nan bubble up is the right way of handling it.
For some reason I thought that setting an Inf in the snes residual (a hack
used right now), is faster than setting an Inf into the jacobian.  However,
the Inf will pop up in the norm at the same place.




>
> >
> > MOOSE right now works around that by setting an Inf into the residual  -
> >  a side effect.
>
>    Why is this any faster then doing the correct thing of setting the nan
> into the Jacobian? It will still have to wait until a reduction is done on
> the residual vector before PETSc can detect the nan and stop the ksp and
> then ones?


>
>    I don't see how one could justify having one model for the form
> function() of setting a nan in the vector and a completely different model
> for the Jacobian of having a extra reduction always in the compute jacobin
> that checks for the domain error? I thought we set on doing the nan trick
> to handle dealing with this issue, now you want to go back to not using the
> nan trick? I don't know what you want?
>
>   Barry
>
>
> >
> > Dmitry.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20150604/7daef8f2/attachment.html>


More information about the petsc-dev mailing list