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@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
>
>
