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

Aperta
  • Qualcosa non va?
#423 1 commento 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 3 giorni

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
25/100
Tipo di issue
Funzionalità
Chiarezza
Abbastanza chiara
Stato di attività
Tranquilla
Stack tecnologico
julia
Ambito
backend

Direzione di ricerca

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.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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

Lingua principale
Julia
Stelle
11
Fork
7
Merge medio
3g 22h
PR unite (30g)
70

Preparare l'ambiente

  • Nessun Dockerfile né file Docker Compose
  • Ha un modello di pull request
  • Nessuna guida per i contributori

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di OpenFUSIONToolkit/GPEC

Tutte le issue di OpenFUSIONToolkit/GPEC

Issue simili

Altre issue su Julia

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.