Summary
Recent VEST EFIT studies show that strongly modified constraint weights, profile assumptions, or initialization choices can cause non-convergence or apparent branch changes. More rigorous nonlinear methods such as quasi-Newton, Newton-Krylov, SQP, or Anderson acceleration are possible in principle, but they require modification or replacement of the underlying equilibrium solver and substantially increase implementation scope.
Before taking that step, VAFT should first quantify how much of the observed EFIT non-convergence can be recovered using low-cost strategies available at the EFIT execution/orchestration layer:
- qualified initialization,
- warm starts,
- parameter/weight continuation,
- deterministic retry/fallback.
The central question is:
How much of VEST EFIT non-convergence can be recovered without changing the EFIT nonlinear solver itself?
If these inexpensive strategies recover most difficult cases, the current EFIT/Picard path can remain in place with better orchestration. If systematic failures remain, those cases become stronger evidence for investigating EFIT-specific nonlinear limitations or an alternative reconstruction solver.
Relationship to existing VAFT issues
This issue is not another independent EFIT parameter scan. It composes the results of already-separated numerical studies into one convergence-recovery workflow.
#171 — solver termination / numerical configuration
#171 owns the question of when EFIT stops, including explicit treatment of:
ERRMIN
SAICON
NXITER
MXITER
ICONVR
...
This issue should consume the explicit numerical configuration and runtime/convergence instrumentation established there.
Do not re-scan or re-optimize termination settings here.
#171
explicit termination configuration
↓
this issue
recovery workflow
#588 — first-slice seed / convergence basin
#588 studies where the first nonlinear solve starts, including the sensitivity to the configured ellipse/current seed through quantities such as:
If #588 identifies a qualified VEST first-slice seed, this issue should use it as the default cold-start fallback.
Do not repeat the seed-basin scan here.
#196 — temporal continuation (ICINIT=-12)
#196 directly owns the time-sequence warm-start problem:
previous trusted equilibrium
↓
next EFIT slice
This issue should consume the policy established by #196 rather than implement a competing temporal-continuation mechanism.
The additional continuation studied here is mainly parameter/weight continuation toward a difficult target case.
#656 — does the VEST EFIT outer iterate contract?
#656 classifies the existing EFIT iteration behavior as, for example:
monotone contraction
plateau
oscillation
It also establishes an important scope boundary: the current EFIT RELAX parameter is a convergence-test quantity, not an iterate-under-relaxation control.
Therefore this issue must not describe RELAX as Picard damping or use it as an iterate-stabilization mechanism.
If #656 finds that plateau/oscillation is rare, the need for an elaborate recovery layer may be small. If it finds reproducible difficult slices, those become natural benchmark cases here.
#663 / #664 — constraint sensitivity, identifiability, and targeted nonlinear continuation
#663 provides empirical examples where large weight changes can produce weak response, branch changes, or loss of convergence.
#664 uses Jacobian/SVD analysis plus targeted continuation to distinguish:
local sensitivity
vs
branch transition
vs
non-convergence
Its continuation is primarily an analysis tool:
#664
continuation as diagnosis
-> where does the local inverse model break down?
The continuation in this issue is an execution strategy:
this issue
continuation as recovery
-> can the requested EFIT target be reached robustly?
Difficult cases identified in #663/#664 should be reused as benchmarks where practical.
#666 — NICE cross-validation
#666 provides an algorithmically independent reconstruction path.
The intended escalation logic is:
EFIT-stage recovery succeeds
-> likely an execution / initialization / path problem
EFIT-stage recovery still fails systematically
-> stronger case for #656 / #664 / #666 investigation
A case that remains unrecoverable here is therefore a useful target for EFIT-vs-NICE comparison rather than an automatic reason to add more retry heuristics.
#139 — fit-quality and convergence infrastructure
Reuse the existing convergence/fit-quality parsing and plotting infrastructure from #139.
Do not build a parallel QA stack.
Scope
1. Define the current direct-execution baseline
For representative VEST cases, record the behavior of the current EFIT execution path with a fixed, explicit numerical configuration.
At minimum retain:
- convergence success/failure;
- iteration count;
- termination reason;
- wall-clock runtime;
- fit-quality metrics;
- final equilibrium quantities;
- initialization provenance.
2. Use qualified warm starts
Where applicable, initialize from the nearest trusted equilibrium rather than always starting independently.
Conceptually:
nearby trusted equilibrium
↓
qualified first-slice seed
↓
ordinary independent initialization
Time-axis warm-start policy should follow #196.
A failed or scientifically rejected equilibrium must not silently become the seed for a later solve.
3. Add parameter / weight continuation
For strongly modified constraints or weights, approach the requested target through intermediate cases instead of jumping directly from the baseline.
Example:
w = 1.0
↓
1.2
↓
1.5
↓
2.0
↓
target
Each converged intermediate case becomes the initial state for the next point.
The purpose is not to optimize production weights. It is to compare:
direct target solve
vs
continuation-assisted target solve
Where practical, scan both increasing and decreasing directions to expose path dependence.
4. Define a deterministic retry / fallback sequence
A failed case should follow an explicit recovery path rather than an ad-hoc repeated rerun.
Conceptually:
normal solve
↓ fail
nearest trusted warm start
↓ fail
smaller continuation step
↓ fail
qualified cold-start seed
↓ fail
record unrecovered failure
The exact ordering should follow the conclusions of #588 and #196.
The same input and configuration must produce the same retry path.
5. Preserve recovery provenance
For every case/slice, retain at least:
initialization source
continuation parent
continuation parameter/value
retry count
fallback reason
final convergence state
runtime
iteration count
The final status should distinguish at least:
converged_directly
converged_after_warm_start
converged_after_continuation
converged_after_fallback
unrecovered_failure
Benchmark set
Prefer reuse of existing EFIT numerical-study cases rather than introducing a new large shot scan.
Candidate sources:
Compare at minimum:
A. current direct execution
B. warm-start execution
C. continuation-assisted execution
D. staged recovery workflow
Metrics
Computational cost
- total wall time;
- number of EFIT executions;
- total iteration count;
- cost per successfully recovered equilibrium.
Robustness
- direct convergence fraction;
- convergence fraction after recovery;
- unrecovered failure fraction;
- recovery success rate by method.
Solution consistency
A recovered solve should not be counted as a success merely because EFIT returned a converged status.
Compare against a direct-converged reference branch where available using at least:
- magnetic-axis position;
- LCFS displacement;
- plasma area / volume;
beta_p;li;q95;- diagnostic residuals;
- relevant profile quantities.
If two paths reach materially different equilibria with comparable fit quality, record that as path/branch dependence, not as simple convergence recovery.
Interpretation
Case A — most target cases already converge directly
Keep the current EFIT workflow simple. Additional recovery machinery is unnecessary or should remain minimal.
Case B — warm start / continuation recovers most failures
There is weak justification for replacing the EFIT nonlinear solver.
The preferred architecture remains:
EFIT / current nonlinear solver
+
better initialization and orchestration
Case C — the same regime remains unrecoverable
Do not add increasingly complicated retry heuristics indefinitely.
Link the remaining cases back to #656/#664 and use #666 or a separate EFIT/VFIT nonlinear-solver study to determine whether the limitation is solver-specific or structural to the inverse problem.
Case D — different paths converge to different branches
Do not classify this as a successful robustness improvement.
This is an identifiability / branch-selection problem and belongs primarily to #664/#666.
Out of scope
This issue does not implement or require:
If these become justified by the benchmark, they should be handled in an EFIT fork, VFIT, or a separate reconstruction-solver issue.
Acceptance criteria
Completion condition
At completion, this issue should answer:
For VEST EFIT, how much of the observed non-convergence can be recovered by initialization, warm starts, continuation, and deterministic retry alone?
The result should support one of two clear next steps:
most failures recovered
↓
retain current EFIT/Picard path
+ improve VAFT execution workflow
or
systematic failures remain
↓
investigate EFIT nonlinear solver itself
or an alternative reconstruction solver
(#656 / #664 / #666 / VFIT)
The purpose of this issue is therefore not to implement a more rigorous nonlinear method, but to establish whether such a change is actually necessary before paying its computational and engineering cost.
Summary
Recent VEST EFIT studies show that strongly modified constraint weights, profile assumptions, or initialization choices can cause non-convergence or apparent branch changes. More rigorous nonlinear methods such as quasi-Newton, Newton-Krylov, SQP, or Anderson acceleration are possible in principle, but they require modification or replacement of the underlying equilibrium solver and substantially increase implementation scope.
Before taking that step, VAFT should first quantify how much of the observed EFIT non-convergence can be recovered using low-cost strategies available at the EFIT execution/orchestration layer:
The central question is:
If these inexpensive strategies recover most difficult cases, the current EFIT/Picard path can remain in place with better orchestration. If systematic failures remain, those cases become stronger evidence for investigating EFIT-specific nonlinear limitations or an alternative reconstruction solver.
Relationship to existing VAFT issues
This issue is not another independent EFIT parameter scan. It composes the results of already-separated numerical studies into one convergence-recovery workflow.
#171 — solver termination / numerical configuration
#171 owns the question of when EFIT stops, including explicit treatment of:
This issue should consume the explicit numerical configuration and runtime/convergence instrumentation established there.
Do not re-scan or re-optimize termination settings here.
#588 — first-slice seed / convergence basin
#588 studies where the first nonlinear solve starts, including the sensitivity to the configured ellipse/current seed through quantities such as:
If #588 identifies a qualified VEST first-slice seed, this issue should use it as the default cold-start fallback.
Do not repeat the seed-basin scan here.
#196 — temporal continuation (
ICINIT=-12)#196 directly owns the time-sequence warm-start problem:
This issue should consume the policy established by #196 rather than implement a competing temporal-continuation mechanism.
The additional continuation studied here is mainly parameter/weight continuation toward a difficult target case.
#656 — does the VEST EFIT outer iterate contract?
#656 classifies the existing EFIT iteration behavior as, for example:
It also establishes an important scope boundary: the current EFIT
RELAXparameter is a convergence-test quantity, not an iterate-under-relaxation control.Therefore this issue must not describe
RELAXas Picard damping or use it as an iterate-stabilization mechanism.If #656 finds that plateau/oscillation is rare, the need for an elaborate recovery layer may be small. If it finds reproducible difficult slices, those become natural benchmark cases here.
#663 / #664 — constraint sensitivity, identifiability, and targeted nonlinear continuation
#663 provides empirical examples where large weight changes can produce weak response, branch changes, or loss of convergence.
#664 uses Jacobian/SVD analysis plus targeted continuation to distinguish:
Its continuation is primarily an analysis tool:
The continuation in this issue is an execution strategy:
Difficult cases identified in #663/#664 should be reused as benchmarks where practical.
#666 — NICE cross-validation
#666 provides an algorithmically independent reconstruction path.
The intended escalation logic is:
A case that remains unrecoverable here is therefore a useful target for EFIT-vs-NICE comparison rather than an automatic reason to add more retry heuristics.
#139 — fit-quality and convergence infrastructure
Reuse the existing convergence/fit-quality parsing and plotting infrastructure from #139.
Do not build a parallel QA stack.
Scope
1. Define the current direct-execution baseline
For representative VEST cases, record the behavior of the current EFIT execution path with a fixed, explicit numerical configuration.
At minimum retain:
2. Use qualified warm starts
Where applicable, initialize from the nearest trusted equilibrium rather than always starting independently.
Conceptually:
Time-axis warm-start policy should follow #196.
A failed or scientifically rejected equilibrium must not silently become the seed for a later solve.
3. Add parameter / weight continuation
For strongly modified constraints or weights, approach the requested target through intermediate cases instead of jumping directly from the baseline.
Example:
Each converged intermediate case becomes the initial state for the next point.
The purpose is not to optimize production weights. It is to compare:
Where practical, scan both increasing and decreasing directions to expose path dependence.
4. Define a deterministic retry / fallback sequence
A failed case should follow an explicit recovery path rather than an ad-hoc repeated rerun.
Conceptually:
The exact ordering should follow the conclusions of #588 and #196.
The same input and configuration must produce the same retry path.
5. Preserve recovery provenance
For every case/slice, retain at least:
The final status should distinguish at least:
Benchmark set
Prefer reuse of existing EFIT numerical-study cases rather than introducing a new large shot scan.
Candidate sources:
Compare at minimum:
Metrics
Computational cost
Robustness
Solution consistency
A recovered solve should not be counted as a success merely because EFIT returned a converged status.
Compare against a direct-converged reference branch where available using at least:
beta_p;li;q95;If two paths reach materially different equilibria with comparable fit quality, record that as path/branch dependence, not as simple convergence recovery.
Interpretation
Case A — most target cases already converge directly
Keep the current EFIT workflow simple. Additional recovery machinery is unnecessary or should remain minimal.
Case B — warm start / continuation recovers most failures
There is weak justification for replacing the EFIT nonlinear solver.
The preferred architecture remains:
Case C — the same regime remains unrecoverable
Do not add increasingly complicated retry heuristics indefinitely.
Link the remaining cases back to #656/#664 and use #666 or a separate EFIT/VFIT nonlinear-solver study to determine whether the limitation is solver-specific or structural to the inverse problem.
Case D — different paths converge to different branches
Do not classify this as a successful robustness improvement.
This is an identifiability / branch-selection problem and belongs primarily to #664/#666.
Out of scope
This issue does not implement or require:
RELAXas iterate damping;If these become justified by the benchmark, they should be handled in an EFIT fork, VFIT, or a separate reconstruction-solver issue.
Acceptance criteria
Completion condition
At completion, this issue should answer:
The result should support one of two clear next steps:
or
The purpose of this issue is therefore not to implement a more rigorous nonlinear method, but to establish whether such a change is actually necessary before paying its computational and engineering cost.