Restart an OpenFOAM Overset / 6DOF Case Without Resetting the Body

If you run an FSI or moving-body case with overPimpleDyMFoam, overInterDyMFoam, or any solver built on sixDoFRigidBodyMotion or rigidBodyMeshMotion, you have probably hit this: you stop the run, restart from the latest time, and the body snaps back to its starting position. The motion looks continuous up to the restart, then there is a sharp transient and the trajectory tracks a lower amplitude for the rest of the run. It is not a physics problem and it is not your mesh. It is a missing restart file. Here is what is happening and how to fix it for good.

This applies to both OpenFOAM ESI (openfoam.com) and the Foundation release (openfoam.org): the motion state mechanism is the same in both. The overset solvers named here, overInterDyMFoam and overPimpleDyMFoam, are ESI-only and have shipped since v1706. The restart issue itself is not specific to overset, it hits any moving-body case built on sixDoFRigidBodyMotion or rigidBodyMeshMotion.

By CFDpilot · Updated June 2026

1. What actually goes wrong

The 6DOF solver does not store the body's state in your fields. It keeps it in a small file inside the time directory:

• sixDoFRigidBodyMotion writes <time>/uniform/sixDoFRigidBodyMotionState
• rigidBodyMeshMotion (the rigid body dynamics library) writes <time>/uniform/rigidBodyMotionState

In parallel, that file lives under each processor: processor0/<time>/uniform/...

On restart, the solver reads that file with READ_IF_PRESENT. The key word is if present. If the file is not in your restart time directory, OpenFOAM does not warn you. It silently falls back to the centreOfMass, velocity and orientation you set in dynamicMeshDict, which are your initial conditions. That is the jump back to the start.

2. Why the body's position alone is not enough

This is the part that traps most people who try to rebuild the file by hand. The motion integrator is symplectic, so a clean restart needs more than where the body is and how fast it is going. It also needs the orientation Q and the angular momentum pi. The standard solver log prints position, orientation and velocity, but not the angular momentum or acceleration.

So if you reconstruct the state file from centreOfRotation and velocity only, the angular part restarts from zero. That is exactly the transient spike at the restart instant, followed by a different amplitude: the body is roughly in the right place, but its rotational state is discontinuous and the solver has to recover over several steps.

3. Fix 1: make the solver write the file (do this first)

In a correctly configured case the state file is written automatically, and restart is seamless with no manual steps. If it is missing, check three things:

• Your restart time is a real write time. The uniform/ folder is only written on write times. Restarting from a time that was never fully written leaves nothing to read.
• purgeWrite is not deleting it. If purgeWrite is small, the time directory and its uniform/ folder may already be gone.
• In parallel, you restart against processor*/<time>/uniform/, not a reconstructed serial copy. reconstructPar does not always carry the uniform/ motion state back, so a reconstructed case can lose it.

Once the file is genuinely present in the restart time directory, you are done. No editing required.

4. Fix 2: rebuild the state file by hand (when you cannot rewrite it)

If you are stuck with runs that never wrote the file, you can create it manually in the restart time directory, but you have to write the full state, not just position and velocity. Add the missing quantities to the solver log by printing them from the motion solver, then recompile.

For sixDoFRigidBodyMotion, in sixDoFRigidBodyMotion.C, inside the update(...) routine:

Info<< "centreOfRotation " << motionState_.centreOfRotation() << endl;
Info<< "orientation "     << motionState_.Q()   << endl;
Info<< "velocity "        << motionState_.v()   << endl;
Info<< "acceleration "    << motionState_.a()   << endl;
Info<< "angularMomentum " << motionState_.pi()  << endl;
Info<< "torque "          << motionState_.tau() << endl;

For rigidBodyMeshMotion, in rigidBodyMeshMotion.C, inside the solve() routine:

Info<< "q() "     << model_.state().q()     << endl;
Info<< "qDot() "  << model_.state().qDot()  << endl;
Info<< "qDdot() " << model_.state().qDdot() << endl;

Recompile the library, then rerun:

# recompile the rigid body motion library
cd $FOAM_SRC/sixDoFRigidBodyMotion
wmake

Now you have every quantity the integrator carries. Copy all of them into the MotionState file at your restart time. The integrator then has its complete state and the restarted curve overlays the uninterrupted one.

5. Do not forget the mesh

For overset and moving-mesh cases, the deformed point positions also have to be in your restart time directory so the geometry continues from where it stopped rather than from constant/polyMesh. If your write settings did not save the moved points, restoring the motion state alone will still leave a mismatch between the body state and the mesh. Make sure both the moved mesh and the motion state come from the same restart time.

6. How to confirm it worked

Plot the body's displacement for the restarted run on top of the uninterrupted one. If the state is fully restored, the two curves sit on top of each other with no kink at the restart time. Any spike right at the restart instant means a piece of the state, almost always the angular part, is still missing.