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
