Skip to content

[Umbrella][Equilibrium] Qualify VEST computational-domain and grid-resolution sensitivity across EFIT, CHEASE, and TES #459

Description

@HongSik-Yun-Fusion

Context

VEST equilibrium workflows currently rely on solver-specific computational grids and domain choices that have not been systematically qualified for the device geometry.

A representative existing VEST equilibrium box is approximately:

R = 0.0 .. 1.2 m
Z = -1.5 .. +1.5 m

with a common structured-grid baseline of:

129 x 129

The present domain appears to retain generous margin around the PF-coil set. A plausible reduced VEST domain is:

R = 0.0 .. 1.0 m
Z = -1.35 .. +1.35 m

which still covers the relevant PF-coil geometry while reducing unused vacuum volume.

At the same time, the present 129 x 129 grid produces substantially different physical spacing in R and Z because the domain is much taller than it is wide. A rectangular grid such as:

129 x 257

may therefore improve effective spatial resolution and reduce directional grid anisotropy without increasing both dimensions equally.

This issue does not pre-select a new default. Its purpose is to establish the solver capability, regenerate any grid/domain-dependent numerical artifacts correctly, and quantify whether the resulting equilibrium changes are significant.

Scope

This umbrella covers EFIT, CHEASE, and TES.

The work is split into two stages:

  1. establish and, where needed, implement solver-specific support for alternate computational domains/resolutions and all dependent geometry/Green/response artifacts;
  2. perform a controlled numerical-sensitivity study for each solver.

TokaMaker is intentionally out of scope here because its unstructured finite-element discretization is not directly comparable to the structured (R, Z) grid question studied in this issue.


Phase 1 — solver capability and artifact-generation paths

Create one child issue per code. Each child must first audit the native solver contract before changing the wrapper.

1A. EFIT

Determine how VEST EFIT defines and consumes:

  • NR, NZ or their executable-equivalent controls;
  • Rmin/Rmax/Zmin/Zmax;
  • geometry / Green-function tables;
  • magnetic response matrices and any other precomputed grid-dependent artifacts.

Questions to resolve:

  • Does the installed VEST EFIT support NR != NZ?
  • Can 129 x 257 be used directly?
  • Which geometry/Green/response artifacts must be regenerated when the grid or domain changes?
  • Is artifact identity/provenance sufficient to prevent reuse of a table generated for a different grid/domain?

If needed, extend the VAFT EFIT wrapper to expose the required grid/domain controls and reproducible regeneration path.

EFIT child deliverables

  • document the actual EFIT grid/domain contract;
  • verify rectangular-grid support;
  • identify all dependent geometry/Green/response artifacts;
  • regenerate alternate-resolution artifacts reproducibly;
  • add wrapper support where required;
  • retain grid/domain provenance with generated artifacts.

1B. CHEASE

VAFT currently ties the two CHEASE box dimensions together through one nw setting, emitting conceptually:

NRBOX = nw
NZBOX = nw

Audit whether upstream CHEASE supports independent NRBOX and NZBOX values. If supported, split the VAFT configuration so that rectangular refinement/output grids can be tested explicitly.

The key comparison requested here is:

513 x 513
vs
513 x 257

CHEASE is not a diagnostic-response reconstruction code like EFIT/TES, so do not force a common "response matrix" abstraction where none exists. Instead, distinguish clearly among:

  • input GEQDSK grid;
  • CHEASE numerical/refinement grid;
  • boundary sampling/smoothing;
  • output GEQDSK grid.

CHEASE child deliverables

  • verify NRBOX != NZBOX upstream capability;
  • document the meaning of the current single nw setting;
  • split NRBOX/NZBOX in the wrapper if valid;
  • verify 513 x 513 and 513 x 257 runs;
  • record input/output/refinement-grid provenance separately.

1C. TES

TES already exposes independent structured-grid controls such as nr, nz, rmin, rmax, zmin, and zmax, so it should be the most direct reference implementation for this study.

Audit:

  • geometry generation;
  • Green/response-matrix generation;
  • cache keys and invalidation;
  • whether grid/domain changes can accidentally reuse incompatible artifacts.

TES child deliverables

  • document geometry and response-artifact generation;
  • verify cache/artifact identity includes resolution and domain;
  • generate 129 x 129 and 129 x 257 variants;
  • generate current-domain and reduced-domain variants;
  • retain full numerical provenance.

Phase 2 — controlled numerical-sensitivity study

For EFIT and TES, use the same 2 x 2 experiment wherever the solver supports it.

Case Domain Grid
A R=0..1.2 m, Z=+-1.5 m 129 x 129
B R=0..1.0 m, Z=+-1.35 m 129 x 129
C current domain 129 x 257
D reduced domain 129 x 257

Interpretation:

B - A : domain effect
C - A : resolution / cell-aspect-ratio effect
D - A : combined effect

and, where useful, quantify the interaction term rather than assuming the effects are additive.

All other physics inputs and solver settings must remain fixed within a comparison. In particular, do not mix this study with EFIT termination/configuration tuning tracked in #171.

EFIT sensitivity

Compare at minimum:

  • convergence state, iteration count, runtime;
  • magnetic-probe and flux-loop residuals;
  • chi-square / fit-quality metrics;
  • magnetic-axis position;
  • LCFS and X-point geometry where available;
  • elongation, triangularity, area, volume and wall gaps;
  • q0, q95, qmin;
  • li, beta_p, stored energy;
  • pressure, F, FF', and toroidal-current-density profiles.

The objective is not merely to obtain a visually smoother contour, but to determine whether the reconstruction changes by more than the intrinsic numerical/reconstruction uncertainty.

TES sensitivity

Run the same A-D matrix while holding fixed:

  • PF currents;
  • plasma-current target;
  • pressure/current source model;
  • limiter/wall geometry;
  • passive-current model;
  • solver tolerances.

Compare the same geometry/profile/global metrics plus synthetic diagnostic responses and solver cost.

CHEASE sensitivity

CHEASE requires two separate tests.

C1. Propagation of upstream EFIT resolution/domain changes

Compare refinement starting from alternate EFIT equilibria, e.g.:

EFIT baseline -> CHEASE
EFIT alternate grid/domain -> CHEASE

Question:

Does CHEASE fixed-boundary refinement suppress, preserve, or amplify numerical differences introduced upstream by EFIT?

C2. CHEASE-native resolution sensitivity

Hold the same EFIT input fixed and compare CHEASE itself at:

513 x 513
vs
513 x 257

If needed, add one higher-resolution point only to establish a convergence direction.


Relationship to the near-axis q0 / GEQDSK pathology

This study is also relevant to #317, which documented that the kinetic-EFIT reference becomes unreliable near the magnetic axis (psi_N <~ 0.05). In that case, the stored q profile has a strong first-point outlier (q[0] around 8 while the next values are around 2), and the inconsistency propagates into toroidal-flux / rho_tor-related quantities.

Do not assume that the q0 spike is caused by coarse resolution. Instead, use this study to separate possible sources:

solver internal resolution
vs
solver output-grid sampling
vs
GEQDSK interpolation / serialization
vs
GEQDSK -> ODS conversion
vs
derived-profile calculation

Track near-axis behavior explicitly for every alternate-resolution case.

Suggested report-only diagnostics include:

  • q[0], q[1], q[2], q[3];
  • qmin and its location;
  • a first-point q-spike metric relative to the next few nodes;
  • dV/dpsi near the axis;
  • phi(psi) / rho_tor consistency;
  • monotonicity and regularity of the first few flux surfaces.

The goal is to determine whether the pathology decreases systematically with improved numerical resolution before considering any smoothing, clipping, or import-time sanitization.


Common comparison outputs

For every solver/case, retain a machine-readable comparison record containing at least:

Category Quantities
Grid NR, NZ, dR, dZ, cell aspect ratio
Domain Rmin, Rmax, Zmin, Zmax
Geometry axis, X-points, LCFS displacement, kappa, delta, area, volume
Profiles q, pressure, F, FF', j_phi
Globals q0, q95, qmin, li, beta_p, stored energy
Near-axis q-spike metric, dV/dpsi, rho_tor consistency
Solver convergence state, iterations, residuals
Cost runtime, artifact size
Provenance solver version, grid/domain, geometry/response revision

For LCFS comparison, prefer quantitative contour metrics in addition to visual overlays, such as:

  • mean/RMS boundary displacement;
  • maximum boundary displacement;
  • Hausdorff distance.

Because VEST is small, also report absolute contour displacement in millimetres.


Execution plan

Stage 1 — infrastructure

  • create EFIT child issue;
  • create CHEASE child issue;
  • create TES child issue;
  • audit native grid/domain semantics;
  • implement missing wrapper controls only where required;
  • establish reproducible alternate geometry/response/grid artifact generation;
  • make numerical provenance explicit.

Stage 2 — one-reference-case study

Use one well-behaved VEST equilibrium slice first and complete the full matrix before broadening the scan.

  • EFIT A-D;
  • TES A-D;
  • CHEASE upstream-EFIT propagation comparison;
  • CHEASE 513 x 513 vs 513 x 257.

The priority is attribution of numerical effects, not database-scale statistics.

Stage 3 — representative regimes

Extend only after Stage 2 is understood. Candidate cases include:

  • nominal limited plasma;
  • high-current equilibrium;
  • strongly elongated plasma;
  • X-point / near-diverted topology where available;
  • a case with a strong near-axis q pathology.

Stage 4 — recommendation

Produce a solver-specific recommendation containing:

recommended domain
recommended grid/resolution
required generated artifacts
supported rectangular-grid combinations
expected numerical uncertainty
runtime/cost trade-off
known pathological regimes

Any production-default change should be a separate follow-up PR after this qualification is complete.


Related issues


Proposed child issues

  1. [EFIT] Support and validate alternate VEST computational grids and response matrices
  2. [CHEASE] Decouple NRBOX/NZBOX and validate rectangular refinement grids
  3. [TES] Generate and validate alternate-resolution VEST geometry and response artifacts
  4. [Validation] Quantify VEST equilibrium domain and resolution sensitivity across EFIT, CHEASE, and TES

The first three are infrastructure/capability work. The fourth is the cross-solver numerical study and should begin only once the solver-specific paths are reproducible.


Non-goals

Acceptance criteria

  • EFIT, CHEASE, and TES Phase-1 child issues are created and completed.
  • Each solver's computational-domain and resolution semantics are documented.
  • Alternate grid/domain-dependent geometry/Green/response artifacts can be regenerated reproducibly where applicable.
  • Numerical artifact provenance prevents incompatible reuse.
  • EFIT rectangular-grid capability is established.
  • CHEASE independent NRBOX/NZBOX capability is established and the wrapper is updated if valid.
  • TES reproduces both domains at 129 x 129 and 129 x 257.
  • Domain-only, resolution-only, and combined effects are quantified separately.
  • CHEASE upstream-EFIT propagation and native 513 x 513 vs 513 x 257 sensitivity are quantified.
  • Geometry, profiles, global quantities, convergence, fit quality, and runtime are compared quantitatively.
  • Near-axis q0 / dV/dpsi / rho_tor behavior is compared across resolution changes and explicitly related back to The kineticEfit reference ODS is not trustworthy within psi_N < 0.05 #317.
  • A justified VEST numerical-configuration recommendation is produced.
  • Any default change is deferred to a separate follow-up implementation PR.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions