Add STRIDE benchmark scans for LAR tokamak (β and epsilon)#251
Conversation
Adds docs/scans/ with equilibria (geqdsk + gpeckf kinetic files), STRIDE namelists, run scripts, and plotting for pressure_factor (42 pts) and epsilon (56 pts, downsampled with full resolution near Delta' pole) scans. CSV results include 2/1 and 3/1 Delta' values plus delta-W energy components. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
There was a problem hiding this comment.
Pull request overview
Adds STRIDE benchmark scan artifacts for the LAR tokamak to support baseline comparisons and future Julia GPEC development, including runnable scan scripts, input namelists, plotted visualizations, and committed CSV summaries for β (pressure factor) and ε (inverse aspect ratio) scans.
Changes:
- Add STRIDE scan runners for β (pressure factor) and ε, including namelist patching and CSV result aggregation.
- Add plotting utilities for scan summaries and for visualizing equilibria/kinetic profiles across scans.
- Add scan inputs/outputs scaffolding (namelists, README files, CSV summaries, and example equilibrium/kinetic data files).
Reviewed changes
Copilot reviewed 18 out of 217 changed files in this pull request and generated 5 comments.
Show a summary per file
| File | Description |
|---|---|
| docs/scans/run_stride_epsilon_scan.py | New runner for ε scan; iterates equilibria, runs STRIDE, collects Δ′/δW into CSV. |
| docs/scans/run_stride_beta_scan.py | New runner for β (pressure factor) scan; runs STRIDE and writes summary CSV. |
| docs/scans/plots/plot_scan_results.py | New plotting script for scan summary CSVs (β/ε/both). |
| docs/scans/plots/plot_scan_equilibria.py | New plotting script for overlaid equilibria + kinetic profiles across scan points. |
| docs/scans/outputs/epsilon_scan/README.md | Documents how ε scan output directory is populated and what to expect. |
| docs/scans/outputs/epsilon_scan/epsilon_scan_summary.csv | Committed ε scan summary results (Δ′ + δW components + q_edge). |
| docs/scans/outputs/beta_scan/README.md | Documents how β scan output directory is populated and what to expect. |
| docs/scans/outputs/beta_scan/pressure_factor_scan_summary.csv | Committed β (pressure factor) scan summary results (Δ′ + δW components + q_edge). |
| docs/scans/outputs/.gitignore | Ignores regenerated STRIDE NetCDF outputs (*.nc) under outputs/. |
| docs/scans/inputs/epsilon_scan/vac.in | STRIDE/DCON vacuum/shape inputs for ε scan runs. |
| docs/scans/inputs/epsilon_scan/stride.in | STRIDE control/params tuned for ε scan (incl. higher singular order). |
| docs/scans/inputs/epsilon_scan/equil.in | Equilibrium reader settings for ε scan; runner overwrites eq_filename. |
| docs/scans/inputs/epsilon_scan/dcon.in | DCON configuration used alongside STRIDE for ε scan setup. |
| docs/scans/inputs/beta_scan/vac.in | STRIDE/DCON vacuum/shape inputs for β scan runs. |
| docs/scans/inputs/beta_scan/stride.in | STRIDE control/params for β (pressure factor) scan. |
| docs/scans/inputs/beta_scan/equil.in | Equilibrium reader settings for β scan; runner overwrites eq_filename. |
| docs/scans/inputs/beta_scan/dcon.in | DCON configuration used alongside STRIDE for β scan setup. |
| docs/scans/equilibria/TJ_epsilon_scan_0.66.gpeckf | Example kinetic profile file in GPEC format for a scan equilibrium. |
| docs/scans/convert_tj_to_gpeckf.py | Utility script to convert TJ equilibrium NetCDF profiles into .gpeckf format. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| 0.65625, 0.6575, 0.65875, 0.66, 0.66125, | ||
| ] | ||
|
|
||
| EPSILONS_TEST = [0.2495, 0.4072, 0.595] |
There was a problem hiding this comment.
EPSILONS_TEST includes 0.595, but there is no corresponding equilibrium file (docs/scans/equilibria/TJ_epsilon_scan_0.595.geqdsk). As a result, --test mode will always skip that point. Update the test list to values that exist in EPSILONS / equilibria directory (e.g., 0.59225 or 0.59775).
| parser.add_argument( | ||
| '--gpechome', default=os.environ.get('GPECHOME', str(SCRIPT_DIR.parents[1])), | ||
| help='Path to GPEC installation (default: $GPECHOME or inferred)') |
There was a problem hiding this comment.
The inferred default for --gpechome resolves to SCRIPT_DIR.parents[1] (the docs/ directory), but this repo’s example runner expects binaries under <repo>/bin (see install/run_examples.sh). With the current default, gpechome/bin/stride will typically not exist and the script exits. Consider defaulting to the repo root (SCRIPT_DIR.parents[2]) or requiring $GPECHOME explicitly.
| '--gpechome', default=os.environ.get('GPECHOME', str(SCRIPT_DIR.parents[1])), | ||
| help='Path to GPEC installation (default: $GPECHOME or inferred)') | ||
| parser.add_argument( |
There was a problem hiding this comment.
The inferred default for --gpechome resolves to SCRIPT_DIR.parents[1] (the docs/ directory), but this repo’s example runner expects binaries under <repo>/bin (see install/run_examples.sh). With the current default, gpechome/bin/stride will typically not exist and the script exits. Consider defaulting to the repo root (SCRIPT_DIR.parents[2]) or requiring $GPECHOME explicitly.
| Expected outputs: | ||
| - `stride_output_beta_<value>.nc` - STRIDE NetCDF output for each beta value | ||
| - `beta_scan_summary.csv` - Aggregated delta-prime and delta-W values |
There was a problem hiding this comment.
The expected output names here don’t match what run_stride_beta_scan.py actually writes. The script produces stride_output_pf_<value>.nc and pressure_factor_scan_summary.csv (and the plotting script reads that CSV), not stride_output_beta_<value>.nc / beta_scan_summary.csv. Please update the README (or rename the generated outputs for consistency).
| import glob | ||
| import os | ||
| import struct | ||
| import sys |
There was a problem hiding this comment.
Unused import: struct is imported but never referenced in this script. Removing it avoids lint warnings and keeps dependencies clear.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
|
@matt-pharr @jhalpern30 @parkjk what are your thoughts on this? Adding 217 files is definitely a significant departure from our previous approach of a handful of examples (i.e. a10, solovev, and DIIID-like). Do we need these? Is it confusing bloat for new users or a helpful example of how to run scans? We've historically not included static plots. These run the risk of quickly becoming out of date, which then could cause confusion if/when some innocent user pulls the png, runs their updated code version, and gets a different result. The only solution to this is to run the whole scan in a github CI for all PRs, but that seems like a slippery slope of creating super long tasks that slow down PRs. Thoughts on this? Should we start including plots in the examples? I'm inclined to be conservative in the fortran repo and say we just keep the existing examples that already provide examples of how to run stride and RDCON for Δ' calculations. I am more open to including something like this in the julia repo I suppose, as we do have "benchmarks" in addition to "examples" in that repo. This (awesomely thorough) scan forces a larger discussion of how we plan to handle benchmarks in Julia GPEC: Should we include all these files directly? Or include self contained bundles of (inputs, run scripts, plotting scripts) as git submodules folks can optionally pull but that do not bloat the main repo? It could be cool to have start a culture in which folks submit their paper plots as benchmark bundles and these get accumulated with proper readme documentation of the papers they correspond to. Issues there are (a) inputs of actual data (e.g. DIII-D data) can't be open sourced and (b) the run scripts will likely become out of date as we are not maintaining backward compatibility yet. At some point, of course, we will make an effort to maintain backwards compatibility and I doubt there will be too many such bundles before then. Thoughts? Other options? |
|
@logan-nc this sort of thing is what inspired the results database idea which was boiled down eventually to be the test harness which had far lighter planning requirements. I think we could still do something like a results database, and it would make sense to combine the Fortran and Julia for something like that. The direction I would go is some MySQL type thing. Not sure whether GitHub is the right place to host it, but we can explore it. The results should be classified by input, by commit hash, by Fortran/julia. Would be nice as a way people could share their scans with the community but would have to be sensitive to data agreements with institutions. Open to thoughts on this. |
|
The main tension here is definitely data agreements. Regardless, my current thoughts are this:
Thoughts? |
|
The submodules are all hosted by the authors github accounts, right? Is it straightforward to include non-open source submodule in our results archive in such a way that a user attempting to pull it ends up essentially "requesting access" from the owner? Proposal:
|
|
@logan-nc hmm no, my idea was to have a single git repository that is a submodule in both fortran and julia that contains versioned scans and such that people update as they run. Sort of harvest-esque, but with full input/output tracking? Not sure. I am worried about overhead for anyone who wants to submit something if we require each individual make a github repo for their scans. |
Adds docs/scans/ with equilibria (geqdsk + gpeckf kinetic files), namelists, run scripts, and plotting for TJ's pressure factor ("pc") across β (42 pts) and epsilon (56 pts, downsampled with full resolution near Delta' pole) scans. CSV results include 2/1 and 3/1 Delta' values plus delta-W energy components. These can serve as baseline cases for Julia GPEC development.