Uh oh!
There was an error while loading. Please reload this page.
Import Vacuum fortran code - #5
Conversation
Bring unit_tests up to date with the vacuum code
…test package for pull requests
Add unit tests to be merged with vacuum WIP
There was a problem hiding this comment.
Pull Request Overview
This PR adds Fortran source code for computing vacuum energy matrix in a tokamak plasma physics code. The code appears to be based on Morrell Chance's vacuum code for solving vacuum integral equations.
- Add comprehensive Fortran vacuum calculation module with main computational routines
- Add utility functions for matrix operations, I/O, and data manipulation
- Add test infrastructure with basic build tests and spline testing
Reviewed Changes
Copilot reviewed 22 out of 25 changed files in this pull request and generated 5 comments.
Show a summary per file
| File | Description |
|---|---|
| src/Vacuum/fortran/vacuum_vac.f | Main vacuum calculation routines including kernel computation, matrix eigenvalue analysis, and wall geometry handling |
| src/Vacuum/fortran/vacuum_ut.f | Utility functions for error handling, I/O operations, matrix manipulation, and formatting |
| test/runtests.jl | Test runner that can execute specific test files or run all tests |
| test/runtests_build.jl | Build test to verify Fortran compilation works correctly |
| test/runtests_spline.jl | Spline functionality tests for 1D and 2D interpolation |
Comments suppressed due to low confidence (1)
src/Vacuum/fortran/vacuum_vac.f:74
- Using bare 'stop' statements can cause abrupt program termination without proper cleanup. Consider using error codes or structured exception handling for better error management.
8050 format (/, 1x, " ier in f04aae = ", i5 )
Uh oh!
There was an error while loading. Please reload this page.
matt-pharr
left a comment
There was a problem hiding this comment.
After a few changes, this work is ready for merge.
Uh oh!
There was an error while loading. Please reload this page.
matt-pharr
left a comment
There was a problem hiding this comment.
This work is ready for merge; Julia interface for vacuum will come in a separate pull request
Uh oh!
There was an error while loading. Please reload this page.
…d assembly docs #3b anchor-sync (docs/07 §1.1): Verify.check_anchor_sync enforces the bidirectional operator<->docs sync — forward (every AbstractTerm operator is named by an 'Implemented by:' marker in numerics.md) and reverse (every marker symbol resolves to a real Islands binding). A new operator without docs, or a doc naming a deleted symbol, fails the check. Tested with negative controls. #6 as-implemented docs: numerics.md gains the Level-0 configuration-assembly section (configure_level0, the cleared wiring vs the Q5-gated families) and 'Implemented by:' markers over the operator stack. This completes the autonomous portion of M2c: #1 assembly, #2 audit, #3 docs infra (STATE dashboard + anchor-sync), #4 B-ladder scaffolding, #6 numerics.md. Remaining M2c is human-gated by design: Q5 (the un-cleared coefficient families + the QN operator structural fix) gates any Level-0 physics run and the B-ladder physics gates; the deferred sub-constants (#5) need a sign-off session. 189 islands tests green; build_docs_local.jl green. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_016pUwoFRo9a5AjF8HuwcZMr
…tion (awaiting sign-off) derivations/passing-fraction.md [DERIVED] derives the electron-closure passing fraction f_p ~= 1 - 1.46*sqrt(eps) from the effective trapped-fraction integral (Lin-Liu-Miller / Wesson) in the pinned b(theta) convention, shows the eps->0 all-passing limit analytically (B(2,1/2)=4/3), and NUMERICALLY confirms the leading coefficient c1 = 1.4624 — matching the sources' quoted 1.46 to 3 s.f. DRAFTED, NOT CLEARED: f_p stays NaN-gated in Fields.ElectronClosure (no src change); awaits human sign-off with one open reviewer item (confirm I19 Eq. 22 uses the same effective-trapped-fraction definition). The companion deferred constants <nu_ii>_u and Hirshman-Sigmar k are left escalated (QUESTIONS Q3/Q5) — each needs its specific source integrand, not derived speculatively. This is the M2c #5 deliverable (draft where rigorously possible; escalate the rest). Wired into the derivations index + nav + QUESTIONS Q5. build_docs_local.jl green. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_016pUwoFRo9a5AjF8HuwcZMr
…); benchmark still gated on Q5+Q7 benchmark_B5_york_thresholds.jl: _b5_phys no longer hand-sets York-regime numbers. It calls Configure.scenario_from_equilibrium on examples/DIIID-like_ideal_example (cached load) at the q=2 surface, so B5 uses the same DERIVED, self-consistent physical vector (eps=0.265, rho_hat_theta_i=0.075, nu_star=0.012, eta_i=2.16) as the rest of design 10. _assemble_b5 takes the matching radius from physical_domain(phys) (a fixed physical fraction of the surface, not scaled with w) and y_max from (1+eps)/(1-eps). Verified end-to-end (clean LD_LIBRARY_PATH): both :original and :improved assemble via configure_level0. Benchmark stays SKIPPED (const UNGATED=false) — it remains gated on Q5 (uncleared coefficient families -> structural-only assembly) AND Q7 (far-field extraction does not localize). So the config is now physical but the York threshold NUMBER is still blocked on the Q7 non-localization. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_016pUwoFRo9a5AjF8HuwcZMr
Adds module for calculating vacuum energy matrix wv. So far in this PR we have:
My opinion is that we should do the wrapper and jupyter notebook in a second PR so that we can roll out unit testing ASAP.