PE - FEATURE - Port Fortran sing_spot / use_res_spot for the resonant jump radius (and try layer-width spots for kinetic cases)
维护者通常 3 天内回复
@matt-pharr 已经在做这个了。
开始于 2026年8月22日。
评估
这个 Issue 还没有评估数据。
描述
Problem
The PE singular-coupling jump is evaluated at ψ_s ± spot_psi with a hard-coded numerator (SingularCoupling.jl:378):
spot_psi = 5e-4 / (abs(nn) * abs(sing_surf.q1))
annotated "spot = 5e-4 matches Fortran default singfac_min". That annotation is wrong on both counts: the Fortran quantity is sing_spot, its own namelist knob (default 5e-4, gpec.f:123), unrelated to singfac_min. So the Julia port reproduces the Fortran default but drops the knob — and drops a second capability entirely.
What Fortran actually does
gpec.f:486-508 builds a per-surface sing_spots(ising) array:
- default:
sing_spots(ising) = sing_spot(5e-4); - with
use_res_spot = .TRUE.(requiresgal_flag):sing_spots(ising) = sing_resspot·(n·|q′|)·sfac^(−1/3) + sing_spot, i.e. the matching radius is set by the resistive resonant-layer width (the S^(−1/3) scaling fromsingtype(ising)%restype), floored atsing_spot.
Consumed as lpsi/rpsi = respsi ∓ spots(ising)/(nn·|q1|) (gpout.f:598-603, and the same in gpout_singfld:1658-1663). The netCDF output even ships them as sing_spots ("Sweet spots used for calculating resonant jump quantities").
Proposed work
- Baseline fidelity: expose
sing_spotas a control ([PerturbedEquilibrium]), replace the literal, and fix the misleading annotation. Default 5e-4 keeps current behaviour bit-identical. - Per-surface resistive spot: port the
use_res_spotbranch — matching radius from the resistive layer width per surface, floored atsing_spot. The ingredients exist on the Julia side (ForceFreeStates/Resist.jl, the Galerkin Δ′ path, the inner-layer solvers). - New work — kinetic cases: try a resonant-layer-width-based spot for kinetic runs, where the relevant layer is not the resistive one. Motivation from issue #376 (
handoff/issue376/RESULTS.md§36): on a DIII-D kinetic-calculated case, the resonant-layer surface term is ~20% of the total NTV torque and the PE-vs-NTV comparison agrees to 0.8% only once that layer window is excluded — so the choice of matching radius is not cosmetic there. Related: #375 (Riccati + kinetic) and #423 (torque cross-check).
Also worth noting: a matching-radius bias of exactly this kind was already found and fixed on the Riccati side (#412), which is precedent that the radius choice materially moves Δ′-family numbers.
- 主要语言
- Julia
- 星标
- 11
- 派生
- 7
- 平均合并
- 4 天 3 小时
- 30 天内合并 PR
- 70
环境准备
- 没有 Dockerfile 或 Docker Compose 文件
- 有 Pull Request 模板
- 没有贡献指南
从这里开始
- 先读完整个 Issue,再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库,在一个分支上完成修改。
- 提交 Pull Request,并在描述里引用这个 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 今天认领。 未关闭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 个 reaction ·
维护者通常 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 条评论 ·
-
难度 2/5 1-3 小时 新手友好度 78/100
维护者通常 1 天内回复
-
难度 1/5 1 小时以内 新手友好度 62/100
SciML/DataDrivenDiffEq.jl#694 ·
-
难度 2/5 1-3 小时 新手友好度 76/100
JuliaLang/LinearAlgebra.jl#1834 ·
维护者通常 1 天内回复