Vacuum - API! - Make no wall an absent Wall section with per-shape WallSettings

[jhalpern30]

Release note

• Audience: users
• Numerical impact: none (harness not yet run; direct develop vs. branch comparison of the DIII-D ideal example gave bit-identical values for every HDF5 dataset except the wall point cloud)
• Migration: Delete the [Wall] section from no-wall decks. In decks that keep a wall, drop parameters the shape does not use (e.g. aw, bw, cw, dw, tw under conformal), and write file walls as shape = "file" with file = "wall.dat".

No wall is now spelled by omitting [Wall] instead of shape = "nowall". A [Wall] section names a shape and only that shape's parameters, and keys the shape does not use are ignored with a warning. A missing required parameter, such as file for a file wall, is an error. In no-wall runs, SurfaceGeometries/Wall/{x,y,z} is now empty rather than points at the origin.

Regression report

Not yet run. To do before merge (commit already pushed):

git fetch && git checkout develop && git merge --ff-only origin/develop
regress --cases diiid_n1 --refs develop,refactor/optional-wall

Notes for reviewers

• No wall is nothing everywhere (ForceFreeStatesInternal.wall_settings, EulerLagrangeProblem.wall, compute_vacuum_response(inputs, nothing)), matching match::Union{Nothing,ResistiveMatch}. The nowall::Bool fields on WallGeometry/WallGeometry3D are gone.
• WallShapeSettings is replaced by WallSettings with one type per shape (ConformalWall, EllipticalWall, DeeWall, ModDeeWall, FileWall). parse_wall is the single deck-to-wall entry point and replaces the copied (Symbol(k) => v ...) lines.
• The per-shape if shape == ... chain in WallGeometry became wall_contour methods. Contours are bit-identical to develop for all four built-in shapes, with and without equal_arc_wall.
• The 2D WallGeometry(plasma_surf, wall) no longer takes inputs; it only supplied mtheta, which is already length(plasma_surf.x).
• The nfp > 1 on an axisymmetric boundary guard moved from WallGeometry3D into the 3D vacuum solve, so it also covers no-wall runs.
• The JuliaFormatter hook reformatted a few untouched lines in benchmarks/ and test/runtests_parallel_integration.jl, which is the expected first-edit churn.
• Tests run locally: vacuum, solve API, full runs, rerun-from-h5, Riccati, Euler-Lagrange.

[github-actions]

This pull request is missing a reviewer.

If you are not ready to name them, mark this pull request as a draft.
docs/development/contributors.md suggests lead developers to ask.
Merging is not blocked here, but no pull request may be merged without human review.

[github-actions]

This pull request is missing a reviewer.

If you are not ready to name them, mark this pull request as a draft.
docs/development/contributors.md suggests lead developers to ask.
Merging is not blocked here, but no pull request may be merged without human review.

[jhalpern30]

@matt-pharr / @logan-nc would you approve of a change like this making it in before v2.0? I realized the other day when figuring out how to do FUSE integration the way we do walls in the TOML is annoying. This change is essentially:

• If no [WALL] section exists in the TOML, the user wants no wall
• If it is there, it should include the wall type, and any parameters specific to that wall type. The user is warned if they included an ignored wall parameter (i.e. passing tw into a conformal wall) and receives an error if they don't provide an essential parameter
• WallShapeSettings now becomes WallSettings, which has various members for each type of wall that have their own docstring documenting what each input means in that context and holding only their own parameters
• Instead of gating on type = "no wall" throughout the code, we gate on if WallSettings is nothing or not to determine what to compute/write to output
• As part of this, I will overhaul the example files. No wall examples lose their [WALL] section, and wall examples lose all non-needed variable inputs for that type of wall (we only use conformal walls in the examples, and many of them "set" tw, cw, aw, etc.

What I'm asking here is basically - I think this is a good change and would be an annoying fix down the line for backwards compatibility since it changes inputs, but is it worth the time to review and merge while other more important changes might demand more attention? Note that the code as-is is all AI - I would take the time to clean it up for an actual review if this is deemed worth it

[logan-nc]

Sure, I am fine with this. Better to get the API where we want it now than to wait.

Please just make sure the website docs clearly lay out what parameters are needed for each available wall type. The main motivation of having the section with the nowall type was to make it easy for a user to inherit a nowall toml and turn on the wall. If it's missing, they'll need good docs instructing them how to add a wall.

[logan-nc]

Be sure to assign a reviewer when marking as not a draft