7. Non-Inertial Reference-Frame Formulation#

This appendix summarizes the non-inertial reference-frame terms used in the solver and separates two ideas that are easy to mix together:

  • the kinematic relation between inertial-frame and solver-frame velocities,

  • the additional source terms that appear in the solver-frame momentum equation.

The goal here is not to reproduce a long classical derivation. Instead, the appendix gives a compact map from the moving-frame kinematics to the equation forms that are actually assembled in the code.

7.1. Reference-Frame Definitions#

Let the inertial-frame position of a fluid parcel be written as

(7.1.1)#\[\vec{x} = \vec{x}_{cg}(t) + \vec{r},\]

where \(\vec{x}_{cg}(t)\) is the origin or rotation center of the non-inertial frame and

(7.1.2)#\[\vec{r} = \vec{x} - \vec{x}_{cg}\]

is the parcel position relative to that frame origin.

The reference-frame quantities used below are:

  • \(\vec{V}_{cg} = d\vec{x}_{cg}/dt\): translational velocity of the frame origin.

  • \(\vec{a}_{cg} = d^2\vec{x}_{cg}/dt^2\): translational acceleration of the frame origin.

  • \(\vec{\Omega}(t)\): angular velocity of the frame.

  • \(\dot{\vec{\Omega}}(t) = d\vec{\Omega}/dt\): angular acceleration of the frame.

In this appendix, \(\vec{v}\) denotes the fluid velocity as represented in the solver’s non-inertial frame, while \(\vec{v}_I\) denotes the inertial-frame velocity.

7.2. Velocity Relation Between Inertial And Non-Inertial Frames#

The inertial-frame and non-inertial-frame velocities are related by

(7.2.1)#\[\vec{v}_I = \vec{V}_{cg} + \vec{v} + \vec{\Omega}\times\vec{r}.\]

Equivalently,

(7.2.2)#\[\vec{v} = \vec{v}_I - \vec{V}_{cg} - \vec{\Omega}\times\vec{r}.\]

This relation is often the most important one to keep in mind when setting or interpreting initial conditions.

It also explains why a translational frame velocity does not appear as an additional governing-equation source term. A uniform shift to a frame moving with constant translational velocity is a Galilean transformation: it changes the reported velocity variable, but it does not introduce a new apparent body force. Only the translational frame acceleration

(7.2.3)#\[\vec{a}_{cg} = \frac{d\vec{V}_{cg}}{dt}\]

enters the non-inertial source term.

For example, suppose the fluid is initially at rest in the inertial frame,

(7.2.4)#\[\vec{v}_I(\vec{x},0)=0,\]

and suppose also that the reference-frame origin has no translational velocity at that instant, so \(\vec{V}_{cg}(0)=0\). If the solver frame is rotating with angular velocity \(\vec{\Omega}_0\) at \(t=0\), then the corresponding velocity field seen in the rotating frame is

(7.2.5)#\[\vec{v}(\vec{x},0) = -\vec{\Omega}_0\times\left(\vec{x}-\vec{x}_{cg,0}\right).\]

So the sign is negative in this “inertial rest viewed from the rotating frame” case.

Note

This kinematic transformation should not be confused with the optional rigid-body rotational velocity initializer in the code. When the initial-condition block is given through rotSpeed, rotAxis, and rotCenter, the current implementation constructs the field

(7.2.6)#\[\vec{v}_{ic} = \vec{\Omega}\times\vec{r}_{\perp},\]

where \(\vec{r}_{\perp}\) is the component of \(\vec{r}\) perpendicular to the rotation axis. That is a prescribed rigid-body rotational velocity field in the solver variable. It is not the same as transforming an inertially stationary flow into the rotating-frame velocity variable.

7.3. Apparent Acceleration In The Moving Frame#

Let \(\vec{a}_{rel}\) denote the fluid-particle acceleration as measured in the non-inertial frame. The inertial-frame particle acceleration is then

(7.3.1)#\[\vec{a}_I = \vec{a}_{cg} + \vec{a}_{rel} + 2\vec{\Omega}\times\vec{v} + \dot{\vec{\Omega}}\times\vec{r} + \vec{\Omega}\times\left(\vec{\Omega}\times\vec{r}\right).\]

Rearranging Newton’s second law into the non-inertial frame moves the frame-motion terms to the right-hand side as apparent body-force terms.

7.4. Momentum Equation In The Non-Inertial Frame#

Using \(\vec{v}\) as the solver-frame velocity, a convenient continuum form of the momentum equation is

(7.4.1)#\[\frac{\partial (\rho \vec{v})}{\partial t} + \nabla\cdot(\rho\vec{v}\otimes\vec{v}) = -\nabla p + \nabla\cdot\boldsymbol{\tau} + \vec{f}_{\mathrm{phys}} - \rho\left[ \vec{a}_{cg} + 2\vec{\Omega}\times\vec{v} + \dot{\vec{\Omega}}\times\vec{r} + \vec{\Omega}\times\left(\vec{\Omega}\times\vec{r}\right) \right].\]

Here \(\vec{f}_{\mathrm{phys}}\) stands for any additional physical body-force terms such as gravity, buoyancy, porous-media resistance, or other model-dependent sources.

The non-inertial contribution therefore consists of four pieces:

  • translational-acceleration term: \(-\rho \vec{a}_{cg}\),

  • Coriolis term: \(-2\rho \vec{\Omega}\times\vec{v}\),

  • Euler or angular-acceleration term: \(-\rho \dot{\vec{\Omega}}\times\vec{r}\),

  • centripetal term: \(-\rho \vec{\Omega}\times(\vec{\Omega}\times\vec{r})\).

This is the form that should be compared mentally against the code.

7.5. Code-Facing Form Used In Loci-Stream#

In the implementation, the non-inertial body-force density is

(7.5.1)#\[\vec{f}_{ni} = -\rho\left[ \vec{a}_{cg} + 2\vec{\Omega}\times\vec{v} + \dot{\vec{\Omega}}\times\vec{r} + \vec{\Omega}\times\left(\vec{\Omega}\times\vec{r}\right) \right].\]

For the standard cell-centered source assembly, the discrete momentum contribution added to a control volume is

(7.5.2)#\[\vec{F}_{ni,c} = \vec{f}_{ni,c} V_c.\]

This is the source pattern assembled in the cell-centered nonInertialSourceTerm path before it is added to the momentum source accumulation.

The code also supports a conservative face-based assembly path for these same terms. In that form, the Coriolis and angular-acceleration pieces, and separately the translational and centripetal pieces, are converted into face contributions using neighboring cell densities. The continuum physics is unchanged; only the discrete source assembly strategy differs.

7.6. Where Else The Same Terms Enter#

The same non-inertial combination is not confined to the cell momentum right-hand side.

  • In the pressure-correction pathway, the starred face-flux assembly also uses the same combination of \(\vec{a}_{cg}\), \(\vec{\Omega}\), \(\dot{\vec{\Omega}}\), \(\vec{r}\), and \(\vec{v}\) when forming the non-inertial contribution to the predicted mass flux.

  • In the total-energy and total-enthalpy pathways, the corresponding work term enters as \(\vec{f}_{ni}\cdot\vec{v}\).

So, when a non-inertial frame is active, the frame-motion terms influence both the momentum update and the coupled scalar or pressure-based updates that depend on that momentum source.

7.7. Implementation Notes For The Reference-Frame Data#

The user-facing setup details are documented in the user guide. For theory-guide purposes, the important implementation facts are:

  • In the constant-input form, the code stores \(\vec{\Omega} = \omega_{rot}\,\hat{e}_{rot}\) and assumes \(\dot{\vec{\Omega}}=0\).

  • In the file-based form, the input history provides time, translational acceleration, frame center, and angular velocity. The code computes \(\dot{\vec{\Omega}}\) from the angular-velocity history using a forward difference at the first point and a backward difference thereafter.

  • For time-dependent input, the frame center, translational acceleration, angular velocity, and angular acceleration are linearly interpolated in time before being used in the governing-equation assembly.

  • In the time-marching implementation, the frame data at level {n} are sampled at stime{n}, while the initial nonlinear state {n,it=0} samples them at stime{n}+dt{n}.

  • Because \(\vec{\Omega}(t)\) and the derived \(\dot{\vec{\Omega}}(t)\) are then interpolated independently, the resulting continuous fields are not guaranteed to satisfy \(\dot{\vec{\Omega}} = d\vec{\Omega}/dt\) exactly within each interval. In other words, the current implementation uses a practical discrete reconstruction of angular acceleration, not an exact kinematic enforcement of the \(\vec{\Omega}\) history between tabulated time points.

These details matter because they explain why the governing equations involve both \(\vec{\Omega}\) and \(\dot{\vec{\Omega}}\) even though only \(\vec{\Omega}(t)\) is supplied directly in the time-history file.