Port gpout_dw / gpout_dw_matrix (psi-resolved torque response profiles and matrices) as the grid-logic diagnostic

Open
  • Is something wrong?
#423 1 comment 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 3 days

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
25/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Quiet
Tech stack
julia
Domain
backend

Research direction

Start by reading gpec/gpout.f routines gpout_dw (lines 2579–2650) and gpout_dw_matrix (2655–2891), then review handoff/issue376/RESULTS.md §32 for the motivating case. The work is complete when the ψ-resolved profile, running integral, and response-matrix profiles are available in gpec.h5 and the integrated torque is tracked against fgar in a regression case; scalar boundary-torque grid sensitivity is a separate investigation.

Written by the indexing model from the issue text.

Description

Summary (revised after fortran-physics-reviewer consultation)

We need to port the ψ-resolved torque response machinery from gpec/gpout.f — gpout_dw (lines 2579–2650) and gpout_dw_matrix (2655–2891) — and use it as the standing grid-logic diagnostic.

The Julia PE currently outputs only the scalar boundary torque Energies/toroidal_torque = −2n·Im(⟨Φ_tot, Λ⁻¹Φ_tot⟩/4). A physics review against the Fortran confirms this scalar is a faithful port of gpout.f:1195–1201 (identical quadratic form, /4 normalization, total-flux argument, torque factor). But it is a boundary quadratic form of the inductance matrix — not the volume-resolved quantity:

  • gpout_dw: ψ-resolved torque/energy density from the actual self-consistent EL solutions, dW(ψ) = Σ conj(u1)·u2 / 2 / (2μ₀) · 2n·i per step, splined; Re of the running ψ-integral = torque (N·m), Im = 2nδW.
  • gpout_dw_matrix: the mpert×mpert response-matrix generalization per ψ step (dwks/dwk/gind/gres/gindp/gresp; normalized by ξ, Φ_boundary, Φ_x, and coordinate-independently).

Neither has a Julia equivalent (grep confirms). The ψ-integrated gpout_dw torque is the true apples-to-apples comparator for the grid-free KineticForces/fgar NTV torque — the comparison that in Fortran exposed ldp-grid inadequacy.

Measured data motivating the port (DIII-D kinetic-calculated, suppression on)

run PE scalar torque [N·m] fgar torque [N·m] PE/KF
rot factor 1.0, auto grid (290) 0.1831 0.7241 0.25
rot factor 1.0, fixed 1024 0.0830 0.7281 0.11
rot factor 0.2, auto grid (305) 0.0946 0.1282 0.74
rot factor 0.2, fixed 1024 0.0950 0.1286 0.74

Per the review, the scalar-vs-fgar gap is not by itself a bug — the two are different constructions — so these rows are motivation, not defect evidence. Two genuine flags remain:

  1. The scalar's grid instability at rot=1.0 (0.183 → 0.083 doubling the grid, while fgar holds to 0.5%) is a red flag on wt0/plasma_inductance convergence — 92% of the physical torque lives at ψ>0.9 where the ω_E sign flip sits within ~one grid cell and the Δ′ rational brackets clear knots. Worth its own investigation, independent of the port.
  2. Until gpout_dw is ported, no volume-integral cross-check exists — the sharpest grid diagnostic from the Fortran workflow is missing from the Julia code.

Proposed work

  1. Port gpout_dw (ψ-resolved torque/energy profile from solutions; the u1†u2 bilinear with the 2n/2μ₀ energy→torque factor) — output as a ψ profile (and its running integral) in gpec.h5.
  2. Port gpout_dw_matrix (ψ × m × m torque/energy response matrix profiles).
  3. Adopt ψ-integrated gpout_dw torque vs fgar torque as a tracked regression-harness quantity (a DIII-D kinetic-calculated case) — the designated referee for any kinetic grid logic.
  4. Separately: investigate the scalar boundary torque's grid sensitivity (wt0 convergence near the pedestal ω_E crossing).

Full record: handoff/issue376/RESULTS.md §32 (experiment branch). Evidence h5s: ~/scratch_issue376/d3dkin/tx_*.

🤖 Generated with Claude Code

https://claude.ai/code/session_01LzbLFQKyuRE5DYZmLokKmk

Dominant language
Julia
Stars
11
Forks
7
Avg merge
3d 22h
Merged PRs (30d)
70

Getting set up

  • No Dockerfile or Docker Compose file
  • Has a pull request template
  • No contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from OpenFUSIONToolkit/GPEC

All issues in OpenFUSIONToolkit/GPEC

Similar issues

More Julia issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.