Wing Geometry Generator Design

This document defines the intended design of the Buffalo Wings wing geometry generator.

Goal

The wing generator should accept a validated wing definition, construct panel-local upper and lower NURBS surface patches from airfoil-based section geometry, enforce explicit C0 and G1 joins between compatible patches, and provide queryable geometry for downstream analysis and meshing workflows.

The public wing API should live in the buffalo_wings.wing subpackage.

Responsibilities

The wing generator should:

  • accept validated wing definitions from the user-facing schema,

  • evaluate spanwise geometric distributions,

  • resolve airfoil inputs into normalized section geometry,

  • construct 3D wing sections from airfoil geometry and spanwise distributions,

  • construct NURBS surface patches for wing panels,

  • enforce user-specified patch-join continuity,

  • provide queryable curves, surfaces, and sampled outputs,

  • and preserve deterministic behavior for a given validated input.

The wing generator should not:

  • define the internal mathematics of airfoil families,

  • replace the airfoil library with wing-specific airfoil logic,

  • require raw NURBS control points for routine use,

  • generate CFD or structural meshes directly,

  • or attempt to solve full aircraft-level geometry composition in the initial implementation.

Non-Goals

The initial wing generator design is not intended to:

  • support every possible lifting-surface topology,

  • expose all internal NURBS-fitting controls to end users,

  • implement full mesh-generation workflows,

  • repair every invalid join configuration automatically,

  • or support tip caps, trailing-edge caps, or wing-body fairings in the first implementation.

User-Facing Concept Model

The user-facing model consists of:

  • a wing definition,

  • a set of named airfoil definitions,

  • one or more spanwise panels,

  • and explicit join definitions between panel-local NURBS patches.

The wing definition specifies global symmetry, span, reference-axis conventions, and the ordered list of panels. Each panel defines a spanwise interval, spanwise geometric distributions, and the airfoil information needed to generate section geometry. Airfoil definitions are specified separately and referenced by name from panels. Join definitions specify continuity requirements between patch boundaries.

The user-facing schema should remain focused on preliminary design concepts rather than raw NURBS internals. Exact field definitions belong in the user-facing wing schema.

Coordinate Conventions And Core Geometry Math

The global frame is:

  • x forward,

  • y right,

  • and z up.

For symmetric wings, the generator may construct only the positive-y half-wing and apply symmetry as needed.

The spanwise coordinate is parameterized by eta in [0, 1]. The physical spanwise location is y = eta * half_span for a half-wing definition. Each panel defines an eta_range = [eta0, eta1] that maps a local spanwise interval into the global half-span parameter space.

The reference-axis position is defined by spanwise distributions such as x_ref(eta) and z_ref(eta). The chord distribution is c(eta). The twist distribution is theta(eta).

A normalized 2D airfoil section is interpreted in local chord coordinates before placement in 3D. The wing generator places each section in 3D by scaling by local chord, rotating about the chosen twist axis by local twist, and translating to the local reference-axis location.

The mapping from normalized airfoil coordinates to 3D section coordinates should be implemented in one canonical place.

Airfoil Resolution And Blending

Airfoil definitions are resolved into normalized section geometry before wing-section placement. A panel may reference a single airfoil definition or a spanwise-varying airfoil specification as allowed by the schema.

If spanwise airfoil blending is requested, the source airfoils should first be resolved independently. The resulting sampled geometry should then be converted into compatible fitted curve representations. Blending should occur on those fitted curve representations rather than by blending arbitrary airfoil-definition families directly.

This approach provides a uniform blending mechanism across heterogeneous airfoil families and avoids requiring every airfoil representation family to implement pairwise blending behavior.

Internal Architecture

The implementation should separate validated user input, canonical evaluated geometry, fitted surfaces, and query or export paths.

Key Internal Objects

  • WingSpec for the validated user-visible wing definition.

  • PanelSpec for validated per-panel geometric and NURBS-construction settings.

  • JoinSpec for validated panel-join continuity specifications.

  • WingCanonical for the evaluated wing representation before final NURBS fitting.

  • PanelNurbs for the upper and lower NURBS patches of a single panel.

  • WingNurbsModel for the final constrained NURBS geometry and query-ready surfaces.

Processing Pipeline

The intended processing pipeline is:

  1. Parse and validate the user-facing specification.

  2. Construct validated WingSpec, PanelSpec, and JoinSpec objects.

  3. Evaluate the canonical spanwise geometry and resolved section curves into WingCanonical.

  4. Fit or skin initial panel-local upper and lower NURBS surfaces.

  5. Enforce patch joins according to the join specifications.

  6. Freeze the resulting surfaces into a WingNurbsModel.

  7. Expose geometry queries and sampled outputs for downstream uses.

These stages should remain cleanly separated so validation, geometry generation, fitting, and query or export paths are testable in isolation.

NURBS Representation Strategy

Each geometric panel should be represented by one upper surface patch and one lower surface patch. The initial implementation should focus on one upper and one lower patch per panel unless later extensions require more local subdivision.

The parameter directions should be defined consistently across all panels. One direction should correspond to chordwise variation over a section curve. The other should correspond to spanwise progression across panel stations.

Panel-local NURBS settings such as degrees, control-point counts, and fitting method may be user-tunable through the schema, but safe defaults should exist.

Surface-Construction Policy

The implementation should distinguish between:

  • geometric constraints that are expected to be represented exactly,

  • and sampled source geometry that is approximated through fitting.

Leading-edge and trailing-edge boundary behavior should be defined explicitly. The chosen parameterization should avoid unnecessary kinks, discontinuous edge progressions, and distortion that would make downstream sampling unreliable.

Join Model

Users explicitly specify continuity requirements at interfaces between NURBS patches. The initial continuity levels are C0 for positional continuity and G1 for tangent-plane continuity.

Continuity Definitions

C0 continuity means the two patch boundaries coincide geometrically along the interface. G1 continuity means the two surfaces share a common tangent plane along the interface, possibly up to a tangent scaling factor.

Control-Point Interpretation

For tensor-product spline surfaces, C0 continuity can be enforced by matching the control points on the shared boundary. G1 continuity can be interpreted through relations between the first control rows on either side of the join together with an optional tangent scaling factor.

The exact implementation may use direct control-row constraints, constrained least-squares fitting, or another equivalent formulation.

Compatibility Requirements

For G1 continuity, the participating patch edges should be compatible in:

  • degree in the join-normal parameter direction,

  • knot vector along the shared edge direction,

  • and control-point count along the shared edge.

If two patches are not compatible for the requested join, the implementation should either apply an explicit compatibility-repair strategy or raise a clear validation error.

Join Enforcement Strategy

The join model and the enforcement strategy should be treated as separate concerns.

Direct Enforcement

The simplest implementation path is direct control-point enforcement when patch compatibility is already satisfied. This is a good starting point for deterministic initial implementations and debugging the continuity model.

Constrained Least Squares

A more flexible implementation may treat joins as weighted constraints during fitting or refitting. This may be useful when panels are constructed from noisy or nonuniform sampled geometry or when compatibility adjustments are required.

Export And Query Model

The final WingNurbsModel should be the single source of truth for geometry queries and export operations. This package should expose queryable curves and surfaces rather than generating analysis meshes directly.

Query interfaces and exporters should sample the final fitted and constrained NURBS geometry rather than reconstructing the wing from intermediate inputs.

The initial output targets are:

  • section-curve queries,

  • surface-point and surface-derivative queries,

  • sampled surface geometry for downstream tools,

  • and diagnostic section cuts.

Mesh generation for CFD, VLM, or other analysis workflows should be handled by downstream packages such as BuffaloMesh.

Validation Requirements

The implementation should validate:

  • required top-level schema fields,

  • panel eta_range coverage and ordering,

  • monotonicity and validity of spanwise distributions,

  • consistency between airfoil references and defined airfoils,

  • compatibility of reference-axis and twist-axis conventions,

  • compatibility of join definitions with the addressed patch boundaries,

  • degree, knot-vector, and control-point compatibility for joins that require G1,

  • and positivity and supported mode values for export-sampling settings.

Validation errors should be explicit, localized, and actionable. The implementation should prefer clear failures over silent fallback behavior when geometry assumptions are violated.

Defaults

The initial implementation should provide safe defaults so routine wing definitions do not require low-level NURBS tuning.

Recommended defaults include:

  • piecewise-linear spanwise distributions,

  • one upper and one lower patch per panel,

  • panel-local NURBS degrees and control-point counts suitable for smooth subsonic wing geometry,

  • deterministic default sampling and query settings,

  • deterministic fitting settings,

  • and explicit errors for incompatible joins unless compatibility repair has been intentionally implemented.

Roadmap Extensions

Future extensions may include:

  • additional spanwise distribution families,

  • more advanced section-curve fitting strategies,

  • automatic knot refinement and degree elevation for join compatibility,

  • tip or trailing-edge cap surfaces,

  • support for more complex lifting-surface topologies,

  • and richer geometry-query and export paths for downstream tools.

These extensions should not complicate the first implementation unnecessarily.

Acceptance Criteria

The initial wing generator design is complete when:

  • a validated wing specification can be converted into a canonical internal representation,

  • resolved airfoil inputs can be transformed into consistent 3D section geometry,

  • panel-local upper and lower NURBS patches can be generated deterministically,

  • user-specified C0 and G1 joins can be enforced for compatible panel boundaries,

  • invalid join configurations produce clear validation errors,

  • the final wing model provides consistent queries for curves, surfaces, and section diagnostics,

  • sampled geometric outputs are repeatable and geometrically consistent,

  • the resulting parameterizations are smooth and usable for downstream meshing tools,

  • and the math core, join logic, and key query or export paths are covered by tests.