Allow advance(dt) with dt > time_window_size

[BenjaminRodenberg]

Please describe the problem you are trying to solve.

Sometimes we run into a situation where the time step size defined in the config file does not exactly fit into the desired end time. Especially, if this is due to round-off errors this can lead to tricky situations.

Example: We want to reach T=5 with dt=0.01. This results in 500 time steps of roughly 0.01 and a 501st time step around 10e-14:

t = 0
T = 5
for i in range(500):
     t += 0.01

print(T-t)

This last time step is problematic, because the solver might not be able to handle such a small time step. We already had some discussions about similar situations recently (e.g. in #1788). We also know some strategies that we can apply, if the last substep inside of a window becomes too small (i.e. precice_dt > solver_dt, but precice_dt - solver_dt is very small, see here). Now, the situation is different because we always use the actual dt = precice_dt = time_window_size. But we would actually like to use dt = time_window_size + 10e-14 in the 500th time step to avoid having to perform a 501st timestep with dt = 10e-14.

Describe the solution you propose.

Currently, the adapter cannot perform a time step dt > precice_dt - even, if it knows about the future problem in the 501st time step. advance(dt) prohibits this for good reasons. I think we need some additional logic such that getMaxTimeStepSize() returns precice_dt = time_window_size + 10e-14 in the 500th time step.

Describe alternatives you've considered

advance could also accept a dt > time_window_size up to a certain margin. This, however, leads to a synchronization problem with the other adapters that might not know about one adapter performing a slightly larger time step.

Additional context
This problem is relatively easy to reproduce with the solverdummy.

[BenjaminRodenberg]

To resolve the situation described above we agreed to implement a more exact summation algorithm for the time tracking inside preCICE. In combination with adaptive time stepping we might still need to reconsider the issue described above. However, until we are able to reproduce any concrete problem I would consider this issue not a bug but just a possible enhancement with low priority.

[fsimonis]

Worthy of note: If the adapter can guarantee that the time-window size is always fixed, then it can count time windows instead and avoid the aggregation error originating from t += Dt.

T = 5
Dt = 0.01
n = 500
t = n * Dt
print(T-t)