Each panel takes its own wing's spanwise direction in calc_forces! and calculate_results

[1-Bort-1]

TL;DR

calc_forces! and calculate_results now use each panel's own wing's spanwise_direction where every panel used wings[1]'s. That direction sets the panel's drag direction, and on a fin next to a wing main turned the fin's drag into lift. solve also takes wing_span and aspect_ratio_projected from all wings. Both gave wrong numbers with no error, and #355 passes the same directions on to linearize's Jacobians.

How the directions are built

spanwise_direction is a field of each Wing, a unit vector along its span given by the user (default [0, 1, 0]). A horizontal wing spans y; a vertical fin should be built with spanwise_direction = [0, 0, 1]. Each wing keeps its own; nothing here merges them.

For each panel, three directions come out of panel_force_directions:

• lift: normal to the panel's local inflow, in the plane of its own airfoil section (cross(inflow, y_airf), from the panel's geometry). It never used spanwise_direction, so it was already right per panel on main: up on a wing, sideways on a fin.
• drag: cross(spanwise, lift). This is where the span direction enters. With the panel's own span it points downstream. On main a fin panel crossed the wing's y with a lift that is itself along ±y, and what was left pointed along ∓z.
• In calculate_results, the cl/cd/cs_distribution split of each panel's force uses the same span: lift normal to inflow and span, side normal to lift and inflow.

The body-level numbers take one frame, the first wing's: the body's lift/drag/side sums project every panel's force onto the lift and side directions of wings[1]'s span, and wing_span/aspect_ratio_projected measure all wings along that span. For a wing with a fin, lift is the vertical force and side the lateral one, fin included.

The figures: a 6 m × 1.5 m wing at 4° plus a fin of the same size 6 m behind it, deflected 5°, symmetric polar with cd = 0.02, va = 20 m/s along x. Left: looking downstream, the span direction each wing's panels use (green) and the panel lift (blue), the same in both. Right: from the side, the panel drag direction (red), taken from the solved forces as normalize(F − L·dir_lift). The fin's drag, 0.02 × 245 Pa × 9 m² = 44 N, goes into −Fz on main instead of Fx.

The test

The test builds a wing along y and an identical wing turned 90° about x, placed 1000 m away along y so the two do not induce on each other. Inflow is along x, which the rotation leaves unchanged. On main, the turned wing's panels come out with Fx = 1.52 N where the one-wing result, rotated, gives 5.93 N. Its cl_distribution is −0.020 against 0.176–0.283, and its cs_distribution is −0.18 to −0.29 against 0. The lift and drag magnitudes (lift_dist, drag_dist) already agreed; only the directions were wrong.

What changed

• calc_forces! and calculate_results loop wing → panel_range(body_aero, wing_idx) and use wing.spanwise_direction. panel_range is new, next to unrefined_section_range, and both are now one sum over the preceding wings. The unrefined-section accumulation in calc_forces! uses it too, which drops its hand-kept panel_idx counter and the else branch that skipped wings.
• In calculate_results the prescribed-va split is one helper, prescribed_va_directions(va, spanwise). It is used three times: for the reference directions, and twice per panel. The per-panel cl/cd/cs_distribution use the panel's own wing. The body's lift/drag/side sums still decompose each panel in the reference frame (wings[1]'s span). Decomposing a fin panel in its own frame and then projecting lift onto lift and side onto side would drop the fin's side force from the body's side. With inflow along x, the test checks lift == Fz, side == Fy and drag == Fx on the two-wing body. For a single wing all three sums are the same arithmetic as before.
• calculate_span(wings, spanwise_direction): a new method of the exported function, giving the extent of all wings' sections along a direction. It is hi - lo of spanwise_extent(wings, spanwise_direction), the helper Start ELLIPTIC circulation on each wing's own ellipse, so multi-wing bodies solve #366 added for one wing, now taking several wings, so the projection exists once. Start ELLIPTIC circulation on each wing's own ellipse, so multi-wing bodies solve #366's elliptic loop walks the wings with panel_range instead of its own offset counter. wing_span and aspect_ratio_projected in solve now use calculate_span along wings[1]'s span. Two touching 6 m wings give 12 m and AR 8; on main they give 6 m and AR 2.

Where I would push back

• The body's reference span direction is still wings[1]'s: it sets the body's lift/side axes and now its span. The first wing has to be the main wing. Nothing checks this, but the only alternative is a body-frame setting nobody has asked for.
• The projected span uses the extent along that direction, so a centreline fin adds nothing, and wings side by side or in tandem add up the way projected_area already does. Two wings far apart count the gap as span too, just as a planform would.
• The per-panel cl/cs_distribution of a panel whose inflow runs along its own wing's span come out NaN, with no error; the reference directions throw on the same case. main has the same gap with wings[1]'s span. Turning that NaN into an error is a behaviour change, so it is not in here.
• stability_derivatives (new from stability_derivatives gives roll, pitch and yaw rate derivatives about solver.reference_point #356) scales dp and dr by b = wings[1].span. For a wing with a fin that is the right span, but for wings side by side it is not the wing_span that solve now reports. Switching it to calculate_span(wings, wings[1].spanwise_direction) is one line, but it would change the rate derivatives of multi-wing bodies in a function that just landed, so it is not in here.

Verification

• Reproduced first: the numbers above, test/solver/test_wing_directions.jl on main's src: 5 of 9 failed; the aspect-ratio testset alone: 0 of 2
• test/solver/test_wing_directions.jl green after, 14/14 (juliaserver, Julia 1.13)
• After merging origin/main at 46adf3d (Start ELLIPTIC circulation on each wing's own ellipse, so multi-wing bodies solve #366, elliptic circulation per wing), whose spanwise_extent conflicted with this branch's calculate_span: test_wing_directions 14, test_body_aerodynamics 4909 (with Start ELLIPTIC circulation on each wing's own ellipse, so multi-wing bodies solve #366's two-wing elliptic tests), test_results 30, test_solver 50, test_wing_geometry 302, test_settings 39, test_stability 27, test_forwarddiff 10, test_unrefined_dist 40, all passing (juliaserver, Julia 1.13). Earlier merges (BREAKING: name the public apparent wind va, va_vec and va_dist, with no deprecation aliases #368 va_vec rename, Spread sliced sections evenly over the span, not over leading-edge arc length #350/stability_derivatives gives roll, pitch and yaw rate derivatives about solver.reference_point #356/Take the flap hinge heights from where the contour crosses the crease line #370) conflicted in calculate_results and the changelog and were checked the same way
• Docs build clean after the merge (only the existing size-threshold warnings) · no REUSE in this repo
• Local CI mirror (Pkg.test(), Julia 1.13) on d066ca6: PASS (5 min) · GitHub CI on d066ca6: PASS, all five jobs. On b3ce084 Julia 1.12 windows had failed test/solver/test_forwarddiff.jl:100 (LOOP, POLAR_MATRICES), the flake of test_forwarddiff.jl's POLAR_MATRICES check flakes at ~4%, and the oper #287 and Flaky POLAR_MATRICES forwarddiff test on Windows / Julia 1.12 (knot-proximity in piecewise-linear polar interpolation) #360 that also fails on main's own push runs
• Figures: rendered from main's src (46adf3d) and this branch's, same script, inputs and axes
• Benchmark: n/a. calc_forces! stays zero-alloc, the per-panel work is unchanged, and the loop only gains an outer loop over the wings
• Risk: cl/cd/cs_distribution of a second wing whose span differs from the first's change sign or meaning. That is the fix, but a plot or script that read them in the first wing's frame will now show different numbers.

Scope

+148 / −64 ignoring whitespace (+212 / −128 plain, since the two loops gain one indent level). src/ is +66 / −64, flat, while adding the per-wing loops and the multi-wing span; the rest is the new 74-line test, one runtests.jl line, two docs entries and the changelog. Searched for wings[1], spanwise_direction and .span in src/: the other wings[1] read is stability_derivatives' b, above. For the test wing I searched test/ for function .*wing( and add_section! builders: inviscid_wing (test_body_aerodynamics.jl), flat_plate_wing (test_solver.jl) and build_flat_wing (test_billowing.jl) are file-local flat wings, none of them rotatable or carrying a polar table. The new rectangular_wing is a fourth; folding all four into one keyword-driven builder in test/test_data_utils.jl rewrites three test files this PR does not otherwise open, so it is a cleanup: PR of its own.

Closes #358 · task VortexStepMethod.jl-358

[1-Bort-1]

Independent review (advisory)

Verdict: APPROVE WITH COMMENTS · 2 inline, 0 off the diff

Good

• The fix matches the card: both loops go wing → panel_range and use wing.spanwise_direction. The body sums still use wings[1]'s span, as the card says (solver.jl:445-479, body_aerodynamics.jl:950-1001).
• For a single wing, calculate_span(body_aero.wings, reference_spanwise) gives the same number as the old wings[1].span. span is a virtual property that calls calculate_span(w) (wing_geometry.jl:1755), and that is now calculate_span((wing,), wing.spanwise_direction).
• panel_range replaces the hand-kept panel_idx counter and the else branch that only skipped panels. The unrefined-section accumulation (solver.jl:526-573) now indexes panels the same way as the force loop.
• The body-sum decomposition still uses the reference frame, so a fin's lift still shows up in the body's side. The test pins this: side ≈ Fy for the pair, where the fin's lift points along −y.
• The test reproduces the bug. The rotated wing's F, cl, cd and cs must equal the solo wing's rotated results, and the card reports 5 of 9 failing on main's src.
• The card's claim that src/ gets shorter checks out. The only other wings[1] read is body_aerodynamics.jl:517, in the elliptical initial distribution, which throws for more than one wing and is tracked as #357.
• prescribed_va_directions and panel_range are documented in private_functions.md. The docstring of the new calculate_span method is shared with the existing one.

Not good

• test/solver/test_wing_directions.jl:11 — rectangular_wing is a fourth near-copy of the flat two-section test wing, next to inviscid_wing (test_body_aerodynamics.jl:18) and flat_plate_wing (test_solver.jl:244). It differs only in rotation, offset and polar. Extending one of those with keyword arguments would keep a single builder (§2).
• src/body_aerodynamics.jl:944 — The guard computes norm(cross(va_ref_vec, reference_spanwise)) and then throws that result away. Line 947 computes the same cross product and normalises it again inside prescribed_va_directions. The degeneracy check and the direction now have two sources three lines apart.
• body_aerodynamics.jl:976 introduces panel_va, but line 985 still reads dot3(panel.va, va_ref_unit). The same loop reads the vector two ways.
• The per-panel prescribed_va_directions(panel_va, spanwise_unit) has no degeneracy guard. A panel whose wing lies along its inflow gets NaN cl/cs_distribution without any error, where the reference directions throw.
• In test_wing_directions.jl, the aspect-ratio testset passes a literal 4 for the section count, while the testset above uses 2length(body_aero.wings) for the same thing.
• The card lists what was searched in src/ but not which test helpers were checked before writing a new wing builder (§2 'say what you searched for').

_{claude, rubric CLEAN_CODE.md. A different lab from the implementer
on purpose: a reviewer sharing its blind spots would not flag its mistakes.}

[1-Bort-1]

MINOR: rectangular_wing is a fourth near-copy of the flat two-section test wing, next to inviscid_wing (test_body_aerodynamics.jl:18) and flat_plate_wing (test_solver.jl:244). It differs only in rotation, offset and polar. Extending one of those with keyword arguments would keep a single builder (§2).

[1-Bort-1]

Not here: inviscid_wing, flat_plate_wing and build_flat_wing are each local to a test file this PR does not open, so merging them into one builder in test_data_utils.jl means rewriting three other test files. That belongs in its own cleanup: PR. The card now says what I searched.

[1-Bort-1]

MINOR: The guard computes norm(cross(va_ref_vec, reference_spanwise)) and then throws that result away. Line 947 computes the same cross product and normalises it again inside prescribed_va_directions. The degeneracy check and the direction now have two sources three lines apart.

[1-Bort-1]

Fixed in f3c2339: the guard now checks the reference_dirs it builds, so the cross product is taken once.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

[1-Bort-1]

Local full suite: PASS (5 min, Julia 1.13.0, one cell of the matrix)

[1-Bart-1]

I don't fully understand how this works yet. Some figures in the PR body would help. And more explanation on what the spanwise directions are, and how the lift direction is now determined with multiple wings, and what spanwise becomes with multiple wings.

[1-Bort-1]

Rewrote the PR description: a new section, 'How the directions are built', with before/after figures of a wing plus a deflected fin, rendered from main's src and d066ca6. In short: each Wing keeps its own spanwise_direction. A panel's lift comes from its own section geometry and never used it. The span direction sets the panel's drag, cross(spanwise, lift), and on main a fin's drag came out along -z, 44 N of lost lift in the figure. The body's lift/side sums and wing_span stay in the first wing's frame, as before.