MODULE 01
Flow core
Transonic through hypersonic. Adaptive Cartesian mesh, shock fitting, and a wall model that holds boundary-layer separation within three percent of tunnel data.
subsonic → Mach 8 · 4.2M cells/s/GPU
Future Flight Test Division
Blackstock AeroSpace
Future Wind Tunnel Software
A software wind tunnel for the aircraft that have not been drawn yet. Coupled CFD, real-time aeroelastic feedback and test-article orchestration, running as one continuous simulation from concept sketch to Mach 5 trim.
Free stream
Mach 0.84 SET
Reynolds
12.4M /M
Solver state
Converged 1e-7
Wall clock
00:00:00
Test section 07 · live streamline field · 1:42 scale model
01 / Platform
One tunnel, every flight regime
The suite pairs a lattice-Boltzmann core for fast iteration with a high-order finite-volume solver for final substantiation. Geometry, instrumentation maps and test intent live in the same model, so a change to the wing planform propagates to the run matrix, the balance calibration and the certification report without a single hand-off spreadsheet.
MODULE 02
Aeroelastic loop
Structure and flow co-simulated at the same time step. Flutter onset is searched instead of stumbled into, and the margin is reported with the trim state attached.
FSI coupled · 240 Hz feedback
MODULE 03
Test orchestration
Instrumentation maps, balance calibrations and run matrices authored once, versioned, and pushed to the physical tunnel or the cluster with the same signed manifest.
signed manifests · full run provenance
MODULE 04
Aeroacoustics
Community and cabin noise predicted from the same pressure field, so a quieter high-lift configuration does not cost lift you cannot explain.
1/3 octave · flyover and cabin
MODULE 05
Digital twin
Every physical run is absorbed into the model as a correction. The twin gets closer to the aircraft with each entry, and disagreement is flagged instead of averaged away.
continuous assimilation
MODULE 06
Certification pack
Traceable from requirement to result: each number carries its geometry revision, solver build, mesh study and test comparison into the compliance document.
requirement-linked evidence
02 / The tunnel
Test sections that exist only in software
The tunnel model is not a viewer. It is the authority. Section geometry, contraction ratio, turbulence screens and model support interference are part of the solved domain, so a simulated entry produces data a test engineer can defend in a design review.
- Closed and open return circuits, Mach 0.1 to 8, with real wall interference modelled rather than corrected afterwards.
- Model support, sting and blade mount drag included in the force budget, so tare is a number instead of an adjustment.
- Instrumentation placement suggested from the predicted gradients, not from habit.
- Runs replay deterministically: same manifest, same result, months later.
A wind tunnel is a promise that the air will behave the same way twice. This software keeps
that promise without building the tunnel.
Design note · Future Flight Test Division
03 / Case 001
The tunnel runs a real case
Case 001 is not a rendering. It is an OpenFOAM case generated from the same duct definition the solver uses: a 100 × 50 × 50 mm test volume, a 5 mm background cell, and the imported STL placed by the saved 4×4 transform so mesh and film see the same article in the same spot. The geometry below is the actual model.stl from the case directory, drawn from its 4,388 facets.
model.stl
case 001 · triSurface · binary STL · 214 KB
Facets
4,388 tris
Envelope
34.6 × 36.2 × 5.1 mm
Surface area
13.91 cm²
Solid volume
1.07 cm³
Duct
100 × 50 × 50 mm
Background mesh
2,000 hex cells
Case manifest · case/
domain0.10 × 0.05 × 0.05 m
background cell5.0 mm
triSurfacemodel.stl
placement+40.75 / +26.94 / +20.21 mm
blockMeshwritten
snappyHexMeshsurface refinement
mesh qualitydict emitted
placement sourcemodel_transformations.json
generatoropenfoam_case.py
geometry helperfluid_volume_model.py
04 / Program
Built for the aircraft after next
The program is scoped in three phases: prove the solver against archival tunnel data, run a coupled aeroelastic campaign on a live configuration, then put the certification evidence chain under configuration control. Each phase ends with something measurable, not a demo.
PHASE I
Substantiate the core
Blind comparison against three legacy tunnel entries, published delta table, no tuning between cases.
exit criteria: within 3% on lift and drag
PHASE II
Fly the coupled loop
Aeroelastic campaign on a transonic wing, flutter boundary searched and matched against available test data.
exit criteria: repeatable margin prediction
PHASE III
Close the evidence chain
Every compliance number traceable to geometry revision, solver build and test comparison inside one signed pack.
exit criteria: audit with no manual reconciliation
05 / Access
Request tunnel time
Access is granted by program, not by seat. Bring a configuration and a question; the software brings the tunnel. Evaluations run against your own geometry under NDA, on isolated compute, and every run stays yours.