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

[Steve]

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 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
>>
>>
-- 
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 privacy at quintessa.org and delete it from your system