Thanks for this Barry, it's exactly what I was looking for.
Sorry for not spotting this myself - I was looking for concepts such as
'feasibility', 'range' etc. in the API method names, so should probably
have realised that 'DomainError' could be interpreted similarly.
The suggested documentation update is a good one for us less experienced
users I think - thanks for this.
In case it is of interest, the approach that I take when trying to find
information on PETSc concepts that are new to me is to first search the
PDF manual, since that includes a lot of high-level information in one
easily searchable place. I don't think that either of these
...DomainError() methods are mentioned there
(SNESSetJacobianDomainError() does appear in a code snippet, but without
any explanation). It might be helpful for the likes of me to add a
quick mention to these methods in the PDF manual in a future update, and
also slip in the 'feasible' word if you think that others might search
on that. I appreciate that these big documents are the hardest to keep
up-to-date in a fast moving software project though, whereas the API
docs can be tweaked relatively quickly.
Best regards,
Steve
On 02/09/2019 19:03, Smith, Barry F. wrote:
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
--
Dr Steven J Benbow
Quintessa Ltd, First Floor, West Wing, Videcom House, Newtown Road,
Henley-on-Thames, Oxfordshire RG9 1HG, UK
Tel: 01491 636246 DD: 01491 630051 Web: http://www.quintessa.org
Quintessa Limited is an employee-owned company registered in England, Number
3716623.
Registered office: Quintessa Ltd, First Floor, West Wing, Videcom House,
Newtown Road, Henley-on-Thames, Oxfordshire RG9 1HG, UK
If you have received this e-mail in error, please notify priv...@quintessa.org
and delete it from your system