[petsc-users] Proper way to abort/restart SNESSolve due to exceptions

Barry Smith bsmith at mcs.anl.gov
Fri Mar 31 16:45:36 CDT 2017


   PETSc doesn't use C++ exceptions. If a catastrophic unrecoverable error occurs each PETSc routine returns a nonzero error code. All the application can do in that case is end.

  If a solver does not converge then PETSc does not use a nonzero error code, instead you obtain information from calls to SNESGetConvergedReason() (or KSPGetConvergedReason()) to determine if there was a convergence failure or not. If there was a lack of convergence PETSc solvers still remain in a valid state and there is no "cleanup" on the solver objects needed.

   We have improved the PETSc handling of failed function evaluations, failed linear solvers etc in the past year so you MUST use the master branch of the PETSc repository and not the release version.

   So your code can look like 

       SNESSolve()
       SNESGetConvergedReason(snes,&reason);
       if (reason < 0) dt = .5*dt;
       else no_converged = false;


   Note that the PETSc TS time-stepping object already manages stuff like this as well as providing local error estimate controls so it is better to use the PETSc TS rather than using SNES and having to manage all the time-stepping yourself.

   Barry

> On Mar 31, 2017, at 10:28 AM, Zou, Ling <ling.zou at inl.gov> wrote:
> 
> Hi All,
> 
> I have done some researching in the PETSc email archive, but did not find a decent way to do it. Assume that, during a SNESSolve, something unphysical happening and a C++ exception is send,  and now I want to stop the SNESSolve and let it try a smaller time step.
> Here are some pseudo code I have:
> 
> while(no_converged)
> {
>   try
>   {
>     SNESSolve(...);
>     if (SNESSolve converged)
>       no_converged = false;
>   }
>   catch(int err)
>   {
>     /* do some clean work here? */
>     dt = 0.5 * dt;
>   }
> }
> 
> It seems to me that it is not a good way to do, as if an exception is thrown during SNESSolve, the code go to the error catching, changing time step, and immediately do SNESSolve again. I would expect that there should be some clean work needed before another SNESSolve call, as I commented in the code.
> 
> I found two related email threads:
> http://lists.mcs.anl.gov/pipermail/petsc-users/2014-August/022597.html
> http://lists.mcs.anl.gov/pipermail/petsc-users/2015-February/024367.html
> 
> But I don't see a clear answer there.
> Any comments on this issue?
> 
> Best,
> 
> Ling



More information about the petsc-users mailing list