<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Thu, Jun 4, 2015 at 3:15 PM Barry Smith <<a href="mailto:bsmith@mcs.anl.gov">bsmith@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"><br>
> On Jun 4, 2015, at 3:35 PM, Dmitry Karpeyev <<a href="mailto:karpeev@mcs.anl.gov" target="_blank">karpeev@mcs.anl.gov</a>> wrote:<br>
><br>
> 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.<br>
<br>
  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.<br></blockquote><div><br></div><div>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).</div><div><br></div><div>However, never mind -- </div><div>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.</div><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
><br>
> MOOSE right now works around that by setting an Inf into the residual  -<br>
>  a side effect.<br>
<br>
   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?</blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<br>
   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?<br>
<br>
  Barry<br>
<br>
<br>
><br>
> Dmitry.<br>
<br>
</blockquote></div></div>