[petsc-users] [EXT] Re: TSAdapt minimum step and exact final time

[Barry Smith]

> On Apr 21, 2022, at 8:52 AM, Phlipot, Greg <Greg.Phlipot at jhuapl.edu> wrote:
> 
> I wish I could give you an definitive reason why, but I can't. Before
> TS gets into this situtation where it needs to take a tiny time step,
> TS takes time steps of ~1.0, and the shift in TSSetIJacobian is ~1.0.
> Then it gets really close to the max time and the time step drops to
> ~1e-12 and the shift in TSSetIJacobian becomes ~1e12.
> 
> When this happens, my ILU-preconditioned gmres linear solve converges
> in a single interation, and the backtracking line search in my newton
> solver fails.

  This is worth investigating. You can run with -ksp_monitor_true_residual -ksp_converged_reason -snes_linesearch_monitor (preferably if you can rig the code to "restart" near the end of the time interval so you don't have to spew this stuff out for many time-steps). 

  A tiny time-step generally produces a well-conditioned linear system (and nonlinear I would think also) so it may be peculiar to your ILU and tolerances that are causing this situation.

  I am bothered by the sudden absurdly small time step (not being an ODE expert) and would hope that the adaptor could, for example, when it realizes a tiny step would be next back up one step and do that one step again with a modestly smaller time-step so that the last time-step is reasonably sized. 

Barry



> 
> Thank you,Greg
> 
> 
> On Thu, 2022-04-21 at 00:57 +0000, Zhang, Hong wrote:
>> APL external email warning: Verify sender hongzhang at anl.gov before
>> clicking links or attachments 
>> 
>> 
>> 
>>> On Apr 20, 2022, at 3:58 PM, Phlipot, Greg <Greg.Phlipot at jhuapl.edu
>>>> wrote:
>>> 
>>> Hello,
>>> 
>>> When using TS with the option TS_EXACT_FINALTIME_MATCHSTEP to force
>>> TS
>>> to stop at the final time, I'm seeing the adaptive step controller
>>> choose smaller time steps than the minimum time step that is set
>>> with
>>> TSAdaptGetStepLimits. For my problems, this leads to solutions that
>>> won't converge due to numerical issues.
>> 
>> Can you please elaborate a bit on why the solution diverges when
>> using a small step size?
>> 
>> Thanks,
>> Hong (Mr.)
>> 
>>> It seems like this might be due to the fact that TSAdaptChoose (
>>> https://petsc.org/main/src/ts/adapt/interface/tsadapt.c.html#TSAdaptChoose
>>> ) uses a tolerance of 10*PETSC_MACHINE_EPSILON to compare whether
>>> the
>>> candidate time step is close to the final time. For me,
>>> 10*PETSC_MACHINE_EPSILON is much smaller than my smallest time step
>>> so
>>> the adaptation scheme occasionally chooses a time step that results
>>> in
>>> a time much closer to the max time than the minimum time step. The
>>> subsequent time step is therefore forced to be smaller than the
>>> minimum
>>> time step.
>>> 
>>> Does anyone have an idea of a workaround (without changing the
>>> source
>>> code) where I would be able to modify this logic to use the minimum
>>> time step instead of 10*PETSC_MACHINE_EPSILON? E.g. with Pre/Post
>>> stage
>>> callbacks and manually modifying the time step?
>>> 
>>> Thank you,
>>> Greg