Fixed RK convergence

[danieljvickers]

We have apparently had a long-standing bug in the IBM RK integrator that was causing the IBs to only propagate with 1st order accuract. I have fixed this by rearranging the RK coefficients to their intended values.

A brief check with a 1D oscillator confirms:

Scheme	Energy drift
New RK2	+6.0e-05
New RK3	−2.0e-05
Old RK2	−2.7e-01
Old RK3	−3.7e-01

Fixes #2025

[github-actions]

Claude Code Review

Head SHA: 3b1eb2b

Files changed:

• 1
• src/simulation/m_time_steppers.fpp

Findings:

• medium src/simulation/m_time_steppers.fpp: For moving_ibm == 1 with a user mib_analytical() velocity, the position/angle update now uses the pre-blend patch_ib(i)%vel and angular_vel, and the analytic override runs after the update. Previously the position used the post-analytic velocity. The centroid therefore lags the analytic velocity by one stage, and any analytic case's trajectories and golden files change. The comment ("from the current-stage velocities, before they are overwritten") shows this is deliberate for the force-driven path. Please confirm it is also intended for analytic motion. If not, call @:mib_analytical() before the position update, or document the change. Confidence: moderate.
• medium src/simulation/m_time_steppers.fpp: The diff swaps the RK blend weights for velocity, angle and centroid. They were coef1*step_* + coef2*current and are now coef1*current + coef2*step_*. The new order matches the fluid update (coef1*q_cons_ts(1) + coef2*q_cons_ts(stor)), so it looks like a correctness fix. It changes results for every moving IB under RK2/RK3, so the PR needs verification and regenerated golden files. Also, moving_ibm == 2 became >= 2. Check that no other moving_ibm value exists that should not take the two-way path. Confidence: moderate.

[github-actions]

Lines of Code

File	Lines	Diff
src/simulation/m_time_steppers.fpp	910	+4

Directory	Lines	Diff
simulation	28507	+4
total	47518	+4

[sbryngelson]

feel free to mark ready to review if it is @danieljvickers