Equilibrium - g-file reader differentiates FPOL and PRES and discards FFPRIM and PPRIME, putting rounding noise on Δ′

未关闭
  • 哪里不对？
#504 3 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

维护者通常 3 天内回复

还没有人认领这个 Issue。

  • #506 来自 @d-burg —— 已关闭，未合并

评估

难度
5/5
预计耗时
一周以上
新手友好度
25/100
Issue 类型
缺陷
描述清晰度
基本清楚
活跃度
停滞
技术栈
julia
领域
backend

调研方向

Start by reading read_efit and the in-repo examples/DIIID-like_ideal_example/TkMkr_D3Dlike_Hmode.geqdsk file to understand how FPOL, FFPRIM, PRES, and PPRIME are handled. Compare the reported Δ′ results when using the file’s derivative arrays, paying particular attention to the end-node caveats and cases where pressure arrays disagree. Done means a fix has an explicit end-node treatment and its effects on the cited regression cases are understood.

由索引模型根据 Issue 内容生成。

描述

bug

Summary

For eq_type = "efit", read_efit parses FFPRIM and PPRIME and discards them. F′ and p′ then come from cubic splines of FPOL and PRES. F′ enters the Euler-Lagrange matrices directly (jtheta = -F′), and Δ′ depends on how F′ varies across each rational surface. F changes by only a few percent across the plasma, so rounding noise in FPOL leaves F′ nearly right in value (0.04 % rms) but wrong in slope at the node scale: the error in dF′/dψ grows as roughly 1/(h²δ) (h = node spacing, δ = fractional variation of F). On 257-node g-files written in single precision this puts noise of a few units on Δ′(2/1).

Evidence

Static, in-repo file. examples/DIIID-like_ideal_example/TkMkr_D3Dlike_Hmode.geqdsk (257 nodes; every FPOL value is exactly a single-precision number). The spline F′ matches FFPRIM/F to 0.04 % rms, but its slope scatters about the FFPRIM-derived slope by up to 37 % near q = 2. No F″ is formed explicitly; the slope enters through the ψ-variation of the splined coefficient matrices:

Image

Same state, two g-files. Five pairs of g-files of one equilibrium state (inputs agree to 1e-5) gave Δ′(2/1) differing by up to 6.2 (rms 3.7). The gap is unchanged on develop, on an identical fixed ψ grid, and with #398, #480 and #491 applied. Swapping only the FPOL block between the two files moves 82–101 % of the gap with it. Rebuilding FPOL as the integral of the file's own FFPRIM closes it (rms 0.17).

Noise ladder. Seeded relative noise on FPOL shifts Δ′(2/1) linearly, about 9e7 × noise: 0.15 at 1e-9, 2.1 at single precision (2.4e-8). The same experiment on FFPRIM is about 900 times less sensitive.

Image

Ten g-files of different provenance. Δ′(2/1), n = 1, Riccati, auto grid:

writer, nodes, precision of FPOL as written F from FFPRIM F and P from FFPRIM, PPRIME
TokaMaker 257, single (the in-repo example above) 9.21 7.27 7.29
TokaMaker 257, single 5.89 6.25 6.11
TokaMaker 257, single 16.48 14.40 14.52
TokaMaker 257, single 9.43 9.12 9.10
TokaMaker 257, single (near a Δ′ pole) −29.1 −0.03 −39.0
EFIT 257, double −1.56 −1.42 −1.40
kinetic EFIT 257, single −10.10 −6.83 −5.46
EFIT 129, single 2.76 2.93 2.96
kinetic EFIT 129, single 3.03 2.86 3.00
EFIT 65, double −3.981 −3.974 −3.974

The effect grows with g-file resolution and with single precision: negligible at 65 nodes, about ±0.2 at 129, units at 257 single precision. Rebuilding P as well changes 2/1 by ≤ 0.14 on eight of ten files.

Caveats for a fix

  • FFPRIM is not clean at the end nodes of TokaMaker files (axis-node spike, last-node drop). The 2/1 result is insensitive to how these are integrated (12.35 spline quadrature, 12.50 trapezoid), but an edge 4/1 entry is not (13 as written, 35 or 50 rebuilt). A fix needs an explicit end-node treatment.
  • For P the question is consistency, not noise: where PRES and PPRIME disagree the result moves (kinetic EFIT 257 above, and outer surfaces), and these tests do not say which array is right.
  • Every efit-type result will move, including the regression cases built on the in-repo example.

Notes

  • Upstream: TokaMaker's gs_save_eqdsk writes every array as REAL(x,4). Writing doubles would reduce the noise to the 9-digit print limit (about ±0.1 here), but would not help existing files or single-precision EFIT output.
  • The Fortran reader has the same behaviour, and its CHEASE reader already builds P by integrating the file's dp/dψ.
  • Runs: commit 1b385a504; read_efit is unchanged on develop 57ec7e16a. Settings: psilow = 0.01, psihigh = 0.998, mtheta = 512, delta_mlow = delta_mhigh = 8, qlow = 1.02, dmlim = 0.2, sing_order = 6.
主要语言
Julia
星标
11
派生
7
平均合并
4 天 1 小时
30 天内合并 PR
68

环境准备

  • 没有 Dockerfile 或 Docker Compose 文件
  • 有 Pull Request 模板
  • 没有贡献指南

从这里开始

  1. 先读完整个 Issue，再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库，在一个分支上完成修改。
  4. 提交 Pull Request，并在描述里引用这个 Issue 编号。

OpenFUSIONToolkit/GPEC 的其他 Issue

查看 OpenFUSIONToolkit/GPEC 的全部 Issue

相似的 Issue

更多 Julia Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。