KineticForces - FEATURE - Rotation prediction: a momentum-balance module fed by tabulated torque surfaces
Maintainers usually reply within 3 days
@logan-nc is already working on this.
Since Sep 13, 2026.
Assessment
This issue has not been assessed yet.
Description
Why
Several questions we want the code to answer are the same computation seen from different sides:
- What steady-state rotation do we predict if these 3D fields are on, and what if they are switched off? Today the answer stops at "the NTV torque at the given rotation profile".
- What is the true neoclassical offset rotation profile for a given perturbation, rather than the rough
~2·ω_*Testimate? - How much error field can a correction coil cancel before its own non-resonant torque costs the rotation that keeps the penetration threshold up (the NTV-limits analysis in
ErrorFields; its current form assumes torque ∝ rotation far from the offset and a positive torque). - Profile-consistent critical resonant field (
Tearing.CriticalResonantField, #415, #371, #416): the layer's rotation should come from a momentum balance that includes the 3D-field torques, not only from the unperturbed profile. - Soon: the resonant J×B torque from the resistive perturbed equilibrium as a second torque source (#401, #370, #333 track its sign and Hermiticity problems).
All of these are a momentum balance with torque sources that depend on the rotation they act on. The torque sources are expensive (a kinetic torque evaluation is minutes); the balances are cheap. If a transport or balance solver calls the kinetic solve at every iteration or time step the whole thing is unusable, so the framework has to separate the two from the start.
Principle: torque surfaces, evaluated once, consumed by any solver
Every torque source publishes the same object:
TorqueSurface
psi :: Vector # kinetic ψ_N grid the profile is resampled onto
rotation :: Vector # rotation-shift grid Δω (rad/s), adaptive, contains 0
torque :: Matrix # cumulative torque T(ψ, Δω) [N·m], per unit perturbation amplitude²
dtorque_dpsi :: Matrix # torque density
source, method, perturbation label, amplitude normalization, sign convention
built once per perturbation by scanning the rotation with an adaptive sampler (the NTV torque has sharp features: the superbanana-plateau resonance near ω_E ≈ 0, bounce-harmonic resonances, the offset crossing; a fixed grid misses them or wastes evaluations). Solvers interpolate the surface and never call the physics kernel. Sources add: NTV now, resonant EM later, each its own surface with the same contract. Amplitude scaling is quadratic, so a surface per unit current serves any current.
The kinetic torque already returns the ψ-resolved cumulative torque (torque_profile) and the KineticProfileSplines container has a vector constructor, so a rigid shift of ω_E with the diamagnetic terms held fixed is a few lines; that is the scan variable for NTV (braking changes E×B, not ω_*). The sign convention between T_φ and the rotation it acts on must be a named constant with a runtime check (a restoring torque has negative slope at its zero crossing), never an assumption.
Proposed home
A new module after KineticForces and Tearing and before Analysis, working name MomentumBalance (or Transport; naming is open). It owns the balance solvers and the TorqueSurface type; it does not compute torques. Pieces that belong elsewhere:
Utilities.AdaptiveSampling: the generic adaptive 1-D sampler (vector-valued function, initial grid, refinement on curvature and sign change, deterministic, point cap). Reusable for every rotation scan and for any other sharp-feature scan.Equilibrium.KineticProfiles:shift_exb_rotation(profiles, Δ).- Momentum inputs: the kinetic HDF5 schema already carries
omega_tor,chi_e,chi_phi, and #415 addedviscous_input_type/viscous_input(profile, scalar, or Prandtl number) to the Tearing control, with reviewers asking for a scalar τ_φ interface. Propose one resolver shared byTearing.CriticalResonantFieldandMomentumBalance: profile column → scalar χ_φ → scalar τ_φ (converted to a flat χ_φ from the momentum content) → fallback to χ_e, so both consumers see the same χ_φ(ψ). - Outputs under a
MomentumBalance/group ingpec.h5(predicted rotation profiles, offset profile, the torque surfaces with their provenance), annotated per the HDF5 conventions.
Initial capabilities, ranked
- 0-D balance from a torque surface (in progress on the ErrorFields NTV-limits branch):
Δ·T_0/ω_ref = T(Δ)·I²solved for the rotation shift; threshold scaling with an exponent; loss of the root as the braking bifurcation. Acceptance: reduces exactly to the linear-budget model when the torque is constant; the DIII-D error-field example shows the torque crossing zero inside the scanned span. - Neoclassical offset profile: the zero of
T′(ψ, Δ)in Δ at each ψ, with the rough~2·ω_*Testimate reported next to it. Acceptance: the offset lies inside the scan span everywhere the torque density is non-negligible. - Steady 1-D momentum balance:
−(1/V′) d/dψ [V′ n m ⟨R²⟩ χ_φ |∇ψ|² dω/dψ] = Σ sourceswith the NTV surface as source, χ_φ from the shared resolver, sources from an input torque profile or the unperturbed rotation, and the edge rotation as boundary condition. Outputs the predicted ω(ψ) with and without the 3D field. Acceptance: with zero 3D field it returns the input profile; with a surface that is linear in Δ it matches the analytic solution. - Profile-consistent b_crit: feed the balanced rotation at each rational surface to
CriticalResonantField. - Resonant EM torque surface from the resistive PE, same contract, added as a second source; needs #401/#370/#333 settled first.
- Time-dependent balance (ramps, bifurcation dynamics) once 3 exists; still interpolating the surfaces, never re-evaluating the kernel per step.
Open questions
- Which rotation is the balance variable: rigid shift of ω_E with ω_* fixed (proposed), or a scale factor, or ω_φ with the diamagnetic terms re-derived from the balanced profiles?
- ω_ref for the 0-D friction term: momentum-weighted mean of ω_φ (proposed) versus the rotation at the dominant rational surface.
- Boundary condition and edge/SOL treatment for the 1-D solve (#315 is the NTV edge bound).
- The resonant torque depends on rotation through the layer response, not through a rigid shift; its scan variable may differ.
- Should the surfaces be per unit current (ErrorFields use) or per unit boundary field amplitude (general use)? Both are one scaling away.
Related: #415, #371, #416, #423 (ψ-resolved torque response profiles), #315, #401, #370, #333.
- Dominant language
- Julia
- Stars
- 11
- Forks
- 7
- Avg merge
- 4d 3h
- Merged PRs (30d)
- 70
Getting set up
- No Dockerfile or Docker Compose file
- Has a pull request template
- No contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from OpenFUSIONToolkit/GPEC
-
Difficulty 1/5 Under an hour Newbie friendliness 82/100
OpenFUSIONToolkit/GPEC#644 ·
Maintainers usually reply within 3 days
-
Difficulty 4/5 3-5 days Newbie friendliness 35/100
OpenFUSIONToolkit/GPEC#643 ·
Maintainers usually reply within 3 days
-
PerturbedEquilibrium - FEATURE - Complete the resistive perturbed-equilibrium workflow from Galerkin and matched resultsPossibly taken @matt-pharr claimed this 1 day ago. Openfeature
OpenFUSIONToolkit/GPEC#635 · 1 comment · 1 assignee ·
Maintainers usually reply within 3 days
-
test
Difficulty 4/5 3-5 days Newbie friendliness 25/100
OpenFUSIONToolkit/GPEC#633 · 2 comments ·
Maintainers usually reply within 3 days
-
Tearing - FEATURE - Add a general modified Rutherford equation for island evolutionPossibly taken @StuartBenjamin claimed this 1 day ago. Openfeature
OpenFUSIONToolkit/GPEC#630 · 1 assignee ·
Maintainers usually reply within 3 days
All issues in OpenFUSIONToolkit/GPEC
Similar issues
-
`ShallowWaterModel` allocates ~9 KiB per grid point per RK3 stage on the CPUPossibly taken @ali-ramadhan claimed this today. Openperformance 🏍️
Difficulty 2/5 1-3 hours Newbie friendliness 62/100
CliMA/Oceananigans.jl#6421 · 1 reaction ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 62/100
NCAR/musica#1118 · 1 comment · 1 reaction ·
Maintainers usually reply within 1 day
-
`AMSGrad` state starts at `epsilon` instead of zero, so zero gradients move parameters and small gradients are dampedPossibly taken @parth-patel010 claimed this today. Open
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
FluxML/Optimisers.jl#247 · 1 comment ·
-
README should say that row and column order must matchPossibly taken @SAUMYARSH claimed this today. Open
Difficulty 1/5 Under an hour Newbie friendliness 84/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
Maintainers usually reply within 1 day