On Jul 25, 2012, at 5:12 PM, Matthew Knepley wrote: > On Wed, Jul 25, 2012 at 5:04 PM, Jed Brown <jedbrown at mcs.anl.gov> 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 > > Yes, but what in PETSc code could possibly create these NaNs?
Shell MatMult or PC :-) > > Matt > > > > > 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 > > > > > > > > -- > What most experimenters take for granted before they begin their experiments > is infinitely more interesting than any results to which their experiments > lead. > -- Norbert Wiener
