<div dir="ltr">Here's the first crack at it: <a href="https://bitbucket.org/petsc/petsc/branch/karpeev/ksp-diverged-on-matmult-nanorinf">https://bitbucket.org/petsc/petsc/branch/karpeev/ksp-diverged-on-matmult-nanorinf</a>.<br>Messier than I had expected (GMRES only for now).</div><br><div class="gmail_quote">On Fri, May 1, 2015 at 8:06 PM Dmitry Karpeyev <<a href="mailto:dkarpeev@gmail.com">dkarpeev@gmail.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_quote">On Fri, May 1, 2015 at 7:32 PM Barry Smith <<a href="mailto:bsmith@mcs.anl.gov" target="_blank">bsmith@mcs.anl.gov</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
> On May 1, 2015, at 6:43 PM, Jed Brown <<a href="mailto:jed@jedbrown.org" target="_blank">jed@jedbrown.org</a>> wrote:<br>
><br>
> Barry Smith <<a href="mailto:bsmith@mcs.anl.gov" target="_blank">bsmith@mcs.anl.gov</a>> writes:<br>
>>   1) This simplifies the needed code since we won't need to put<br>
>>   checks all over the place on returns about failure nor do we need<br>
>>   to worry about propagating errors from one process to another<br>
>>   (since the Nan/Inf get moved by the MPI_Allreduce()).<br>
><br>
> My concern is that -fp_trap will become a lot less useful.<br>
<br>
  I agree there is a tradeoff; but under "normal" circumstances where there are no Nan or Inf around (which I think is most of the time) -fp_trap will be just as useful as now. For the other cases the user will have to have some idea where (and when) in the code to turn on the trapping to catch the "true" problems.<br>
<br>
   Barry<br>
<br>
  The only other way I see to do it is carry a validity flag around with each vector and reduce that flag in all the vector reductions; but this alone is not enough we would also have to have some propagation code for things like zero pivot, for example setting a validity flag in the Mat factor (saying the factor is not valid) and propagating up those flags. We get all these things "for free" with the Inf Nan approach.<br></blockquote></div></div><div dir="ltr"><div class="gmail_quote"><div>There is an additional benefit: the validity flag would have to be cleared by the caller to avoid "false positives" on subsequent calls.  That's an opportunity for bugs.  With NaN the "error condition" (i.e., the NaN entry) gets cleared automatically by a subsequent successful vector operation. </div><div><br></div><div><br></div><div>What exactly caused the NaN would have to be signaled "out-of-band" as the saying goes. One way to "signal" it is by the code path that led to the error condition: that's why calling through KSP_MatMult() is useful.  It's not ideal, but covers the cases of immediate interest.</div><div>Dmitry.</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
><br>
<br>
</blockquote></div></div></blockquote></div>