<div class="gmail_quote">On Wed, Jul 25, 2012 at 4:58 PM, Barry Smith <span dir="ltr"><<a href="mailto:bsmith@mcs.anl.gov" target="_blank">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">
<br>
  As always a COMPLETE error report is useful. There are a million ways you could see this change in behavior but we can't spend time guessing.  At a minimum please send the entire error output.<br>
<br>
   I note in 3.3 the KSPDefaultConverged() still checks for NAN and returns a negative converged reason (not an error) so I can only guess why you are getting different behavior without more information.,<br></blockquote>
<div><br></div><div>This is probably the main complaint:</div><div><br></div><div><a href="http://petsc.cs.iit.edu/petsc/petsc-dev/rev/7d6f5cbe67bc">http://petsc.cs.iit.edu/petsc/petsc-dev/rev/7d6f5cbe67bc</a></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>
     Barry<br>
<div class="HOEnZb"><div class="h5"><br>
On Jul 25, 2012, at 4:35 PM, Kirk, Benjamin (JSC-EG311) wrote:<br>
<br>
> Hello -<br>
><br>
> I've been using PETSc 3.1 for quite a while now and have been hesitant to<br>
> upgrade because of some new behavior I found in 3.2.  Let me explain...<br>
><br>
> In petsc-3.1, if the KSP encountered a NaN it would return it to the<br>
> application code.  We actually liked this feature because it gives us an<br>
> opportunity to catch the NaN and attempt recovery, in our case by decreasing<br>
> the time step and trying again.<br>
><br>
> It seems in petsc-3.2, however, that PETSc itself aborts internally, so we<br>
> are unable to recover from the situation.<br>
><br>
> Is there any way to get the old behavior back?<br>
><br>
> Thanks,<br>
><br>
> -Ben<br>
><br>
<br>
</div></div></blockquote></div><br>