KineticForces - Read the kinetic file's zeff dataset

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

维护者通常 3 天内回复

还没有人认领这个 Issue。

评估

难度
5/5
预计耗时
一周以上
新手友好度
22/100
Issue 类型
功能
描述清晰度
基本清楚
活跃度
活跃
领域
data

调研方向

Start with resolve_ntv_species and the [KineticForces] zimp and mimp settings, then trace how zpitch and multi_ion_composition consume Zeff. The first step is a design decision: record what a supplied Zeff means for zpitch when Zeff is at or above zimp, and for the impurity density and collision frequencies. Done means the NTV path reads the file's zeff under that rule, logs its source, and is covered by a test with and without the dataset, with docs/src/kinetic_forces.md updated.

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

描述

The kinetic profile file can carry an optional zeff dataset, which the SLAYER layer and the resistive-layer overlap scan prefer to their own closure (PR #298). The NTV path does not read it: resolve_ntv_species always derives Zeff from quasi-neutrality with one impurity ([KineticForces] zimp, mimp). One run can therefore use two Zeff profiles: the file's in the tearing analysis and the closure's in the NTV torque.

Why this is more than a one-line change:

  • In the NTV path Zeff comes with the pitch-angle factor zpitch and the impurity density from multi_ion_composition, and the collision frequencies use all three. Overriding Zeff alone would leave them inconsistent.
  • zpitch has a pole at Zeff = zimp, so a supplied Zeff above zimp needs a defined behaviour.
  • The impurity charge is set twice, as [KineticForces] zimp (integer) and [SLAYER] zimp (float). They should become one setting, or be documented as deliberately separate.

Done when:

  • A rule is recorded for what a supplied Zeff means for zpitch, the impurity density and the collision frequencies.
  • The NTV path uses the file's zeff under that rule and logs which source it used.
  • A test covers a file with and without the dataset.
  • docs/src/kinetic_forces.md states the precedence for both paths.

🤖 Generated with Claude Code

主要语言
Julia
星标
11
派生
7
平均合并
4 天 3 小时
30 天内合并 PR
70

环境准备

  • 没有 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 摘要。