Restarting a moving immersed boundary is not force-continuous

[sbryngelson]

What happens

Restarting a run with a moving immersed boundary restores the prescribed kinematics exactly, but the force on the body does not continue smoothly. It takes several steps to re-settle, with jumps one to two orders of magnitude larger than the ordinary step-to-step variation.

A six-wingbeat flapping-wing run chained as four segments, with seams at steps 20649, 34649 and 48649. Around the seam at 48649, Fz:

step 48646   -0.489259
step 48647   -0.481829
step 48648   -0.474675   <- last step of the previous segment
step 48650   -0.123459
step 48651   +0.147261
step 48652   +0.343488

That is a step of 0.27 against a typical step-to-step change of 0.005 nearby -- roughly 50x. The other two seams show the same shape, milder. The transient decays over a handful of steps.

It is not the kinematics

Across every seam the prescribed motion restores to five decimals -- wx is unchanged through the restart (+0.49348 either side at 20649), and vz and zc march smoothly with no discontinuity. So the body is in exactly the right place moving at exactly the right rate; what re-settles is the flow-side reconstruction.

The likely site is the immersed boundary's ghost- and image-point state. On restart it is rebuilt from the restart field in s_ibm_setup rather than carried across, so the first few steps after a restart reconstruct it from a field that was itself produced with the previous reconstruction in place.

Why it matters

• A long run split into segments by a queue's walltime limit -- which is how any multi-hour case on a capped system has to run -- carries one of these per seam. Here that is three transients in one six-wingbeat trace.
• Any workflow that treats a restart as continuing the same realization inherits it. For an ensemble where realizations are chained, the seams are a systematic perturbation applied at the same points in every member.
• It is invisible unless you look for it: the run completes normally, ICFL stays healthy (0.42-0.57 over the affected segment), and nothing is reported.

Reproducing

Any moving_ibm case with ib_state_wrt run in two segments instead of one, comparing Fx/Fy/Fz in restart_data/ib_state_<step>.dat on either side of the seam against the local step-to-step variation.

Note on scope

Measured on a build carrying #1846 and #1847. Those add the per-step force output that made the transient visible at step resolution, but they do not create it -- the quantity is patch_ib%force from s_compute_ib_forces, and the restart path being discussed is in master. A separate, smaller defect seen alongside this one (a row of identically zero force written at t_step_start) is in #1846 and is being fixed there, not here.

Investigated with Claude Code.

https://claude.ai/code/session_01HMJ7cycfo7kTFSFq5yhHLG