PE toroidal torque changes sign under grid refinement while its magnitude stays stable to ~1%
メンテナーはふだん 3 日以内に返信
まだ誰も着手していません。
評価
調査の方向性
Start with the reproduction in examples/DIIID-like_ideal_example, then trace how perturbed_equilibrium/energies/toroidal_torque is computed and compare it with the tracked quantity in regression-harness/cases/diiid_n1.toml. Run the stated grid-refinement cases and inspect the torque output in gpec.h5; done means the torque sign is consistent across the reported grids without losing its stable magnitude.
索引モデルが issue の本文から書いたものです。
説明
Summary
perturbed_equilibrium/energies/toroidal_torque on the DIII-D-like ideal example changes sign under small, benign changes to the discretization, while its magnitude stays stable to about 1%. Radial refinement, poloidal refinement, and (independently reported) a dependency update all flip it. A physical torque should not behave this way: the sign is being set by something arbitrary rather than by the physics.
Measured after #350, so the coil-forcing fixes in that PR (b2ec04c3, 8dab0ed9) do not resolve it.
Evidence
All runs use examples/DIIID-like_ideal_example unchanged except for the grid controls named.
Radial refinement on a fixed ldp grid, post-#350 (grid_type="ldp", mpsi as shown; mpsi=0 is the deck's auto grid):
| grid | torque |
|---|---|
| auto (561 knots) | +0.050865 |
| ldp 512 | +0.050892 |
| ldp 1024 | −0.050645 |
| ldp 2048 | +0.050876 |
Same scan before #350:
| mpsi | 128 | 256 | 512 | 1024 | 2048 |
|---|---|---|---|---|---|
| torque | −0.0507289 | −0.0506007 | +0.0508128 | −0.0510857 | +0.0509140 |
Poloidal refinement at fixed mpsi = 1024 (pre-#350) — changing only mtheta:
| mtheta | torque |
|---|---|
| 256 | −0.0510857 |
| 512 | +0.0513171 |
Across every configuration above the magnitude sits in 0.0506–0.0513, a spread of ~1.4%, while the sign takes both values.
It is deterministic, not noise
Re-running mpsi = 1024 and 2048 with the Euler-Lagrange tolerance tightened from 1e-10 to 1e-12 reproduces each value — including its sign — to 1.8e-10 or better:
| quantity | mpsi | el_tol=1e-10 |
el_tol=1e-12 |
rel diff |
|---|---|---|---|---|
pe_torque |
1024 | −0.051085748 | −0.051085748 | 4.6e-11 |
pe_torque |
2048 | +0.0509139592 | +0.0509139592 | 1.8e-10 |
So the sign is a reproducible function of the grid, not run-to-run instability, and not integration error.
Independent report of the same symptom
In #338, @matt-pharr reported a set of package updates that "flip the sign of the torque in the d3d ideal example". That is a third, unrelated trigger producing the same signature — sign inverts, magnitude survives.
Why this looks like a convention rather than a convergence problem
A quantity that is converging would show its magnitude settling and its sign fixed. Here the magnitude is already stable to ~1% across an 8× radial refinement, a 2× poloidal refinement, and a code change — while the sign is not stable under any of them. That pattern fits a sign carried by something with an arbitrary choice in it (an eigenvector phase or normalization convention, or a branch selection somewhere in the torque assembly) rather than a physical quantity that has not yet converged.
Worth checking whether the torque is computed from an expression that is genuinely phase-invariant. Quantities built as Im(a* b) are invariant to a global phase on the mode; anything effectively linear in the eigenvector's sign is not.
Why it matters now
The regression harness tracks this quantity (pe_toroidal_torque in regression-harness/cases/diiid_n1.toml, noise_threshold = 1e-12). Any run that lands on the other sign reports a ~200% regression — which is exactly the 200.47% torque "regression" quoted in #338's original table. Until this is resolved the quantity cannot carry a golden value, and it will keep generating false regressions whose cause is invisible to whoever is reading the report.
Reproducing
# in a copy of examples/DIIID-like_ideal_example, set Equilibrium.grid_type="ldp"
# and Equilibrium.mpsi to each of 512, 1024, 2048, then:
julia --project=. -e 'using GeneralizedPerturbedEquilibrium; GeneralizedPerturbedEquilibrium.main(["<deck>"])'
# read perturbed_equilibrium/energies/toroidal_torque from gpec.h5
- 主要言語
- Julia
- スター
- 11
- フォーク
- 7
- 平均マージ
- 4日 3時間
- マージ済み PR(30日)
- 70
環境構築
- Dockerfile・Docker Compose ファイルなし
- プルリクエストのテンプレートあり
- コントリビューションガイドなし
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
OpenFUSIONToolkit/GPEC のほかの issue
-
難易度 1/5 1時間未満 初心者へのやさしさ 82/100
OpenFUSIONToolkit/GPEC#644 ·
メンテナーはふだん 3 日以内に返信
-
難易度 4/5 3〜5日 初心者へのやさしさ 35/100
OpenFUSIONToolkit/GPEC#643 ·
メンテナーはふだん 3 日以内に返信
-
PerturbedEquilibrium - FEATURE - Complete the resistive perturbed-equilibrium workflow from Galerkin and matched results対応中かも @matt-pharr が 1 日前に担当しました。 オープンfeature
OpenFUSIONToolkit/GPEC#635 · コメント 1 件 · 担当者 1 名 ·
メンテナーはふだん 3 日以内に返信
-
test
難易度 4/5 3〜5日 初心者へのやさしさ 25/100
OpenFUSIONToolkit/GPEC#633 · コメント 2 件 ·
メンテナーはふだん 3 日以内に返信
-
Tearing - FEATURE - Add a general modified Rutherford equation for island evolution対応中かも @StuartBenjamin が 1 日前に担当しました。 オープンfeature
OpenFUSIONToolkit/GPEC#630 · 担当者 1 名 ·
メンテナーはふだん 3 日以内に返信
OpenFUSIONToolkit/GPEC の issue をすべて見る
似ている issue
-
`ShallowWaterModel` allocates ~9 KiB per grid point per RK3 stage on the CPU対応中かも @ali-ramadhan が今日担当しました。 オープンperformance 🏍️
難易度 2/5 1〜3時間 初心者へのやさしさ 62/100
CliMA/Oceananigans.jl#6421 · リアクション 1 件 ·
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 62/100
NCAR/musica#1118 · コメント 1 件 · リアクション 1 件 ·
メンテナーはふだん 1 日以内に返信
-
`AMSGrad` state starts at `epsilon` instead of zero, so zero gradients move parameters and small gradients are damped対応中かも @parth-patel010 が今日担当しました。 オープン
難易度 2/5 1〜3時間 初心者へのやさしさ 72/100
FluxML/Optimisers.jl#247 · コメント 1 件 ·
-
README should say that row and column order must match対応中かも @SAUMYARSH が今日担当しました。 オープン
難易度 1/5 1時間未満 初心者へのやさしさ 84/100
-
難易度 2/5 1〜3時間 初心者へのやさしさ 78/100
メンテナーはふだん 1 日以内に返信