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

[Emil Constantinescu]

On 4/21/22 8:06 AM, Barry Smith wrote:

>
>> 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 is correct, BDFs are subject to instability if two consecutive 
points in time are either too far or too close relative to the rest. I 
think BDF2 is insensitive to decrease in time step, so try to limit the 
BDF to order 2 if that is an option for you. Alternatively, try one-step 
multistage methods (ARKIMEX, but use only the implicit part). While this 
may not address directly the issue Greg is describing above, it's easy 
to try out.

Emil

> 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

-- 
Emil M. Constantinescu, Ph.D.
Computational Mathematician
Argonne National Laboratory
Mathematics and Computer Science Division

Ph: 630-252-0926
http://www.mcs.anl.gov/~emconsta