Map a refined panel midway between two sections to the outboard one

[1-Bort-1]

TL;DR

compute_refined_panel_mapping! gave an exact tie to the first section, so a mirror-symmetric three-section wing mapped its two midway panels to the same side and yawed with no deformation. A tie now goes to the section farther from the middle of the span, so mirror panels map to mirror sections.

What was wrong

Each refined panel maps to the unrefined section whose centre is nearest, with a strict <. Three sections at y = 1, 0, −1 and ten LINEAR panels put panel 3 (centre y = 0.5) and panel 8 (y = −0.5) exactly midway between two sections. Both ties went to the lower index, giving [1, 1, 1, 2, 2, 2, 2, 2, 3, 3]: panel 3 to the left tip, panel 8 to the centre.

It surfaced in OpenSourceAWE/SymbolicAWEModels.jl#397. There the 2-plate particle kite, perfectly mirror-symmetric, gets its point forces from this mapping. With the lopsided map its flat case yaws with Mz = 2.15 N·m where 0 is right, and test_aero_modes' yaw antisymmetry and pose-sweep checks fail. On SymbolicAWEModels main the same kite passes only because its last-digit rounding happened to break both ties outward. #397 changes those digits, and the mapping flips.

The change

Sections within 1e-9 of the nearest distance, relative, count as tied. A tie goes to the section whose centre is farther from the middle of the span, measured along spanwise_direction. Without a tie nothing changes. The three existing mapping testsets, which rebuild the nearest section by hand, pass unchanged. The span positions are summed by hand rather than through generators, so the mapping allocates nothing.

Verification

• test/wing_geometry/test_wing_geometry.jl "a panel midway between two sections maps outboard": red on v6.0.0 (Int16[1, 1, 1, 2, 2, 2, 2, 2, 3, 3]), green after (302 + 1 passed). Run in SymbolicAWEModels' juliaserver session with this branch developed in.
• SymbolicAWEModels test_aero_modes.jl with this mapping: direct particle yaw Mz(±d) = ∓0.581, flat 5.8e-9, the same as SymbolicAWEModels main.
• test/bench.jl "Refinement Allocation Tests": the first push (1d6fb24) took LINEAR refine! to 133 allocations against a limit of 70, red in this PR's CI. That was 64 allocations inside the mapping, from a generator sum and extrema. With scalar arithmetic the mapping makes 0 and refine! makes 69 / 69 / 92 / 4 / 132 (LINEAR, COSINE, SPLIT_PROVIDED, UNCHANGED, BILLOWING; limits 70 / 70 / 100 / 5 / 140). bench.jl plus test_wing_geometry.jl: 324 of 324 pass, in this repo's test environment.
• test/solver/test_unrefined_dist.jl (40) and test/test_refinement_validation.jl (15): 55 of 55 pass, same environment.
• Not run: this repo's full suite locally. The docs build is green in CI.
• Risk: a wing whose unrefined sections are not symmetric about the middle of their span can see a formerly tied panel move to the other section.

Scope

+58 / −8 in src/wing_geometry.jl, its test, private_functions.md and the changelog. SymbolicAWEModels#397 needs it released before its CI can pass.

Opened by 1-Bort-1, an AI agent working for @1-Bart-1.
From OpenSourceAWE/SymbolicAWEModels.jl#376 · task SymbolicAWEModels.jl-376

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

[1-Bart-1]

Wouldn't it be better to do a weighted mapping with two weights to the two nearest ones? Or does that break upstream?

[1-Bort-1]

Yes, it would be better physically, but not in this PR, because it breaks what reads the mapping. refined_panel_mapping is one Int16 per panel, and three places use it as "the one parent section":

• VSM's solver.jl:498: the *_unrefined_dist arrays sum each panel into one section and divide by a count.
• SAM's distribute_panel_forces_to_points! (vsm_refine.jl:355): each panel's whole corner-node force goes onto the LE/TE points of one section.
• SAM's set_section_va! (aero_modes/common.jl:1979): each panel takes the apparent wind of one section.

Two weights per panel means a new pair of fields, like the refined_section_left_idx / refined_section_weight VSM already keeps for sections, and all three readers moving to it. Every particle-kite force in SAM would shift, and so would the unrefined distributions, which were count averages. That is a breaking change across both packages. #407 only makes an exact tie symmetric, and a mapping without ties is unchanged.

A weighted split also has no ties: a panel midway gives 50/50 and stays symmetric with no rule needed. So I'd merge #407 as the fix for #397 and do the weighted mapping as its own VSM issue, with the SAM side following. Shall I open it?