cdadt

A certification-driven aircraft design tool.

cdadt sizes and optimizes an aircraft against an explicit certification basis. The sizing itself – balanced-field takeoff, climb, cruise, descent, 14 CFR Part 25 reserves and loiter – is performed by an OpenConcept analysis used as a black box: cdadt sets its inputs, converges it, and reads its outputs.

cdadt size cases/b738.yaml
cdadt optimize cases/b738_optimization.yaml
cdadt inspect cases/b738.yaml

What it is

Four claims, each of which is enforced by the test suite rather than asserted here:

OpenConcept is a black box, and one package may open it. The sizing analysis is named in the case file as module:ClassName and loaded at run time, so for most of cdadt there is no OpenConcept class to subclass, no component to re-wire and no physics to quietly reimplement. cdadt.adapter is the single exception, and it exists for one reason: installing cdadt’s own aerodynamics into OpenConcept’s mission means composing OpenConcept’s propulsion and weight blocks around it, which cannot be done from outside. That exemption is one package wide and is checked. See The OpenConcept black box.

The aerodynamics can be cdadt’s, and it is checkable against the codes it drives. A case file names an AerodynamicLoads, and three ship: a parabolic polar, an openavl vortex lattice, and OpenConcept’s own OpenAeroStruct lattice. The two lattices are independent codes solving the same wing, which is what turns “the lattice says 0.99” from a claim into a measurement – compared like for like they agree to 0.67%. Geometry derivatives are exact, from jax.jacrev through openavl’s own differentiable rebuild and from OpenMDAO’s totals through OpenAeroStruct’s. See Supplying your own aerodynamics and, for what each result is checked against, What is checked against what.

Every discipline is a class. Geometry, aerodynamics, propulsion, stability, structures, weights and performance are classes with encapsulated state, and each owns exactly one slice of the black box’s interface: which variables its domain sets, and which responses its domain reports. Ownership is total and disjoint, checked against the live model. See Architecture.

A study is a file. Every design variable, everything written into the box before it is converged, the continuation ladder, the driver, the objective and the certification constraints are all declared in one YAML case file, laid out block for block like OpenConcept’s own run scripts. Two studies that ask different questions of the same aeroplane differ only in data. See The case file.

What it produces

Sizing the shipped B738 case reproduces OpenConcept’s own published example to better than 1e-6 relative, with the reference run in the test rather than quoted:

Maximum takeoff weight

78,345.6 kg

Operating empty weight

41,748.3 kg

Block fuel

15,977.1 kg

Fuel with reserves

18,597.3 kg

Balanced field length

5,247.8 ft

Optimizing it against 14 CFR 25.113, 25.121(b) and the engine deck’s throttle band, over the wing planform and the engine rating, cuts fuel with reserves by 11.8% and maximum takeoff weight by 7.7%. The climb throttle band is the active constraint; neither certification constraint binds.

The same study on a vortex lattice reaches 12.0% (openavl) and 12.3% (OpenAeroStruct), and reaches a different aeroplane: with transonic drag rise modelled, quarter-chord sweep goes to 31.4 and 31.6 degrees, where optimizing on OpenConcept’s own polar drives it to its lower bound. That polar has no drag rise anywhere and cannot be given any, so sweep is a variable it can only lose by.

All three of those are optimizations. The reference analysis holds sweep fixed at the real 737-800’s 25 degrees and has no design variables and no bounds, so a value sitting on a bound is always an optimizer result and never something OpenConcept’s own example does. See Optimization and, for what is not established, Validation.

Getting started

How it works

Verification and validation

Reference

Indices