[petsc-users] KSP no longer returning NaNs?

[Barry Smith]

  Ok. The goal with those changes was to allow the user to detect the problem as soon as possible in the code instead of delaying knowing where the NaN appeared.

   Exceptions would be one way of handling this, but we bagged exceptions in PETSc. 

    We can add a nasty global and a PETSc option to indicate if they want immediate failure on NaN (in inner products, norms etc) or if they want the code to continue. I thought about this but never got around to it.

   Barry

   
On Jul 25, 2012, at 5:04 PM, Jed Brown wrote:

> On Wed, Jul 25, 2012 at 4:58 PM, Barry Smith <bsmith at mcs.anl.gov> wrote:
> 
>   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.
> 
>    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.,
> 
> This is probably the main complaint:
> 
> http://petsc.cs.iit.edu/petsc/petsc-dev/rev/7d6f5cbe67bc
> 
>  
> 
> 
>      Barry
> 
> On Jul 25, 2012, at 4:35 PM, Kirk, Benjamin (JSC-EG311) wrote:
> 
> > Hello -
> >
> > I've been using PETSc 3.1 for quite a while now and have been hesitant to
> > upgrade because of some new behavior I found in 3.2.  Let me explain...
> >
> > In petsc-3.1, if the KSP encountered a NaN it would return it to the
> > application code.  We actually liked this feature because it gives us an
> > opportunity to catch the NaN and attempt recovery, in our case by decreasing
> > the time step and trying again.
> >
> > It seems in petsc-3.2, however, that PETSc itself aborts internally, so we
> > are unable to recover from the situation.
> >
> > Is there any way to get the old behavior back?
> >
> > Thanks,
> >
> > -Ben
> >
> 
>