Normalize wing section order to +y → -y

[1-Bart-1]

Problem

Panel y_airf and z_airf are derived from the order a wing's sections are stored in (y_airf = normalize(bound_1 - bound_2), bound_1 from section i, bound_2 from section i+1). That order was never an invariant:

• refine!'s sort (_section_sort_key, rev=true) was the only normalization anywhere, and it is skipped whenever a caller passes sort_sections=false — which is what building a particle wing does.
• A geometry file written -y → +y therefore travelled unmodified into BodyAerodynamics and inverted every panel normal.
• Worse, a wing whose sections are replaced after its panels were built (a structural remesh) inverted them mid-run, one panel at a time as each crossed spanwise_direction.

Panel.reinit! compensated by re-deriving a flip from live geometry on every call. That is what produced the observed chatter — measured on a V3 particle lattice, tracking dot(z_now, z_prev) per panel per step:

step 1–50 : dot = 1.0            normals do not move at all
step 61   : dot = -0.99   FLIPPED [17, 18]
step 62   : dot = -0.999  FLIPPED [17, 18, 22, 23, 24]
step 63   : dot = -0.985  FLIPPED [19, 20, 21]
step 67   : FLIPPED 40 panels

180° in a single step, neighbouring panels disagreeing at the same step. AeroPressure builds its frozen traction pattern on z_airf, so a flipped panel's aero force reverses with it.

Every scheme that samples the order fails, because the order legitimately changes: per panel (neighbours disagree under deformation), at construction (the sections are replaced afterwards), cached in a struct field (it serializes into model bins and goes stale).

Change

Normalize instead of compensate. normalize_span_order! puts sections in +y → -y at the boundaries:

• on YAML load, before any structural pairing exists, so a reversed file is fixed on arrival;
• in refine!, for wings assembled through add_section!. Gated on recompute_mapping, so the per-step call that only updates positions still never reorders. sort_sections stays for a genuinely scrambled list.

obj_to_yaml and surfplan_to_aero_yaml emit +y → -y as well. Not breaking — files of either order load identically now.

With the order canonical, nothing has to decide a flip from live geometry. BodyAerodynamics drops the span_flip field it cached, and reinit! reads wing_span_flip directly as a guard for a hand-built wing.

+y → -y is the convention already in use: SurfPlan exports it (SK100 aero_geometry.yaml, +8.03 → −8.03), cfd_aero_geometry.yaml (+4.11 → −4.11), the V3 structural geometry (2.873 → −3.892) and refine!'s own sort all agree. It is also the kite seen from the front, so spanwise distribution plots now put +y on the left — via one span_axis helper replacing nine repeated Axis constructions.

Verification

V3 beam wing, whose aero geometry file is the one written the wrong way round:

	inverted normals after init!	after relax_bridle!
before	72 of 72	56
after	0	0

Sections also stay monotonic through relaxation now, where they did not before. The V3 particle lattice, already correctly ordered, is unchanged (0 both before and after).

Both section orderings give identical aero with the flip branch exercised:

order fwd: min dot(y_airf, +y) = 1.0 | CL = 0.40954 | CD = 0.008288
order rev: min dot(y_airf, +y) = 1.0 | CL = 0.40954 | CD = 0.008288

Also included

The shrink_wrap rolling-ball rewrite, the obj_to_yaml wingtip fix, the read_node_table speedup, the named-window plotting change, and the V3_neuralfoil / ram_air_kite example updates that were already in the tree.

reinit!(panel, …) loses its spanwise_direction positional argument and takes flip::Bool instead. That method takes internal panel_props slices and is not user-facing, so it is not a breaking change; test/panel/test_panel.jl is updated.

🤖 Generated with Claude Code

[codecov]

Codecov Report

❌ Patch coverage is 81.11111% with 17 lines in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
ext/VortexStepMethodMakieExt.jl	52.94%	16 Missing ⚠️
src/wing_geometry.jl	94.11%	1 Missing ⚠️

📢 Thoughts on this report? Let us know!