One name per apparent-wind quantity: `va`, `v_a`, `_va` and `va_*`...

[1-Bort-1]

One name per apparent-wind quantity: va, v_a, _va and va_* made consistent

Third of the three parts of #147 (Refactoring part III). Stack it on #336 (*_array → vector/matrix names).

The convention agreed on #147: ufechner7 proposed va for the scalar norm, va_vec for the vector, and va_dist for the per-panel norms, with _vec as the suffix for any 1D vector. Bart accepted it as long as it holds everywhere, and on 2026-09-16 asked for consistent, readable naming across the package.

Ask Bart before writing code. The convention collides with public API that already uses va for the vector:

• set_va!(body, va)
• BodyAerodynamics(...; va=)
• reinit!(...; va=)
• the Panel.va field
• the BodyAerodynamics.va property

The plotting keywords are v_a= for the scalar: plot_polars, plot_combined_analysis and generate_polar_data. Linearize has va_idxs=.

Following the convention literally is a BREAKING rename of those keywords and that field. The alternative keeps the public names and applies the convention to everything else. Those two produce materially different code.

Survey of main at 2b312ea:

• 54 identifiers and 674 occurrences.
• Fields mix _va, has_distributed_va, v_a_dist (1D norms, on BodyAerodynamics and LoopResult), VSMSolution._va_dist (P×3 matrix), va_unrefined_dist, and va_norm_dist/va_unit_dist on BaseResult.
• Locals include va_norm, va_unit, va_ref_vector, va_ref_mag, va_panel_mag, va_input, va_distribution, va1..3, dva_1/2, and delta_va (a positional argument of the exported section_pitch_rate).
• Examples, tests and docs also call the same quantity vel_app (21), v_app (9, including settings docs) and Uinf (the thesis test port).
• Unrelated: va/vb in src/obj_adapter/obj_slice.jl:253-260 mean vertex a/b.

[1-Bort-1]

Going with A, first of two PRs on main (#336 merged): the internal apparent-wind names (locals, internal fields and arguments, tests, examples, docs prose) move to va scalar, va_vec vector, va_dist per-panel norms. No public API change here. The breaking rename of va=, v_a=, Panel.va, body_aero.va, va_idxs= and v_app is queued as its own stacked PR. obj_slice.jl's va/vb (vertices) stay.

[1-Bort-1]

Question from VortexStepMethod.jl-337

Should the va convention (va scalar, va_vec vector, va_dist per-panel norms) also rename the public API, as a breaking change?

Right now these public names say the opposite: va= in BodyAerodynamics(...) and reinit!, set_va!'s argument, Panel.va and body_aero.va are all the vector. v_a= in plot_polars, plot_combined_analysis and generate_polar_data is the scalar, and so is VSMSettings.v_app, which is also a YAML key.

A) Breaking, in two stacked PRs. First the internals, tests, examples and docs, with no API change. Then the public names: va= -> va_vec=, Panel.va / body_aero.va -> va_vec, v_a= -> va=, va_idxs= -> va_vec_idxs=, and v_app -> va in the settings and YAML. That one gets a BREAKING changelog entry and can wait for v6. SymbolicAWEModels and RamAirKite need a follow-up.
B) Keep every public name and apply the convention only inside. Nothing breaks, but va means the vector at the API and the scalar inside, so it is not consistent everywhere.
C) Like A, but the old keywords and property still work for one release with a depwarn. That adds shim code to remove later.

My recommendation: A. You asked for consistency everywhere, and splitting it keeps the breaking part small and lets you decide when it merges.

[1-Bart-1]

Go with A

[1-Bort-1]

Done as A. The first half, internal names, tests, examples and docs with no API change, is fc3daab..524103b on agent/337-one-name-per-apparent-wind-quantity-va-v; its PR opens with this turn. The breaking public rename is #348, stacked on it.