(app_non_inertial_reference_frame)=
# 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.

## Reference-Frame Definitions

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

```{math}
\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

```{math}
\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.

## Velocity Relation Between Inertial And Non-Inertial Frames

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

```{math}
\vec{v}_I = \vec{V}_{cg} + \vec{v} + \vec{\Omega}\times\vec{r}.
```

Equivalently,

```{math}
\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

```{math}
\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,

```{math}
\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

```{math}
\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

```{math}
\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.
:::

## 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

```{math}
\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.

## Momentum Equation In The Non-Inertial Frame

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

```{math}
\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.

## Code-Facing Form Used In Loci-Stream

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

```{math}
\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

```{math}
\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.

## 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.

## 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.