[petsc-users] Handling infeasible solution iterates in TS/SNES

[Smith, Barry F.]

   Steve,

      There are two levels at which "out of domain" (infeasible)  errors can/should be indicated: 

1)   First call TSSetFunctionDomainError(). TS calls your provided function when candidate solutions are generated, if the new solution is not feasible, as indicated by this function, it will cut the time-step.

2)   Next, in your function evaluations (provided with TSSetIFunction() or TSSetRHSFunction()) call SNESSetFunctionDomainError() whenever an infeasible state is provided. Use  TSGetSNES() to access the SNES object from the TS.  If you call this function the SNES solver will try cutting the length of the search direction in the nonlinear solver, still striving to solve the nonlinear system. If this fails the TS will cut the time-step. 

     Not a naive question at all, our documentation on this is not as extensive or as clear as it should be. I have tried to improve it a bit https://gitlab.com/petsc/petsc/merge_requests/2001

     Good luck, and please let us know if this support can be improved in any way.

   Barry

Yes, the names of the the two functions TSSetFunctionDomainError() and SNESSetFunctionDomainError() are a bit inconsistent since the first one takes a user provided function while the second one indicates the current solution point is not feasible. 

The PETSc error codes are all "hard" errors that end the program. We manage "exception" type errors that can be recovered from through additional APIs such as SNESSetFunctionDomainError().  I tried once to add a recoverable exception type mechanism for the PETSc error codes but found it was too cumbersome in C.



> On Sep 2, 2019, at 11:22 AM, Steve via petsc-users <petsc-users at mcs.anl.gov> wrote:
> 
> Hello,
> 
> I have another beginner's PETSc question.  Apologies if the solution is obvious, but I've looked around the manual and the API and haven't yet spotted a solution.
> 
> I'm solving a nonlinear problem using the BDF TSP (although the same issue arises if I use BEULER and other TS - it's not specific to BDF).  The issue that I have is that during the SNES iterations for a timestep it's possible for the solution iterates to wander into an infeasible region when evaluating the TS IFunction.  In the particular instance I have this is resulting in an exp overflow, so it is both physically and computationally infeasible.
> 
> The problem arises because of the highly nonlinear nature of the problem.  I have a hand-coded DAE solver that also suffers with the same issue, but which spots that the situation had arisen in the evaluation of the residual, and then rejects the timestep and takes a smaller one, which is usually sufficient for the Newton iterates to remain feasible and for timestepping to proceed.  I would like to take the same approach with PETSc.
> 
> Currently I return a non-zero PetscErrorCode from my IFunction to indicate that the solution iterate is infeasible, but this results in an immediate (but graceful) exit from PETSc.
> 
> Ideally I guess I would like to call a function like TS/SNESSetIterateIsInfeasible(...) from within my IFunction and then return zero, to indicate to PETSc that the Newton iterations have gone awry but that nothing fatal has happened, or (better?) would return a specific non-zero error code from my IFunction and handle the particular error code by reducing the timestep.  The crucial thing is that I can't return a new residual from my IFunction when this happens, due to the infeasibility of the input, and so PETSc should not use the value of the residual itself to infer divergence.
> 
> Are either of these approaches possible?  Or is there an alternative/better approach that I can use with PETSc to handle such situations?  (I've seen SETERRQ in the API but this only appears to allow tailored error messages to be set rather than providing a method to handle them - but perhaps I have misunderstood.)
> 
> Again, apologies if this is a naive question, and thanks in advance for any suggestions.
> 
> Steve
> 
>