DrivAerNet++: A 39 TB CFD Car Dataset and What It Actually Costs to Use

The gap DrivAerNet++ fills: labelled 3D car geometry with CFD attached

Aerodynamic surrogate modelling has a data problem that is not about volume. Wind tunnel and full CFD campaigns produce a handful of shapes per study, and the shapes are usually proprietary. A graph neural network or a point-cloud network needs thousands of labelled geometries before its error curves mean anything, and public car datasets tend to supply either geometry without flow fields or flow fields for one or two bodies. DrivAerNet++ targets that gap directly: 8,150 car designs, each modelled with high-fidelity CFD, covering fastback, notchback and estateback configurations. The intended audience is researchers and engineers building data-driven surrogates for drag, lift and moment prediction, plus anyone working on semantic segmentation or automated meshing who needs per-part labels on real car surfaces. The README frames diversity as the point: a wide range of shapes and configurations is what lets a model generalize rather than memorize a single body style. That framing is honest about the design of the dataset. It is a benchmark corpus first, and a design tool second.

Ten modalities, one geometry, and why the pairing matters

The dataset exposes the same 8,150 designs through ten representations. Parametric models give the 26 scalar parameters that fully describe each shape. Volumetric fields carry full 3D CFD output for pressure, velocity and turbulence. Surface fields carry coefficient of pressure and wall shear stress. There are streamlines, dense and sparse point clouds, high-resolution surface triangulations, aerodynamic coefficients (drag, lift, moment), per-part semantic annotations across 29 labels, photorealistic renderings, and hand-drawn style sketches generated with Canny edge and CLIPasso. The multi-representation layout is what makes cross-modal work possible: sketch-to-design, rendering-to-parameter regression, or point-cloud-to-pressure-field prediction all become the same kind of task because every modality is indexed to the same geometry. The 29 semantic labels (wheels, side mirrors, doors and so on) are the part that most CFD datasets skip, and they are what make segmentation and automated meshing experiments feasible without hand-labelling. The README also lists a Coming Soon block: 2D slices, signed distance fields for occupancy modelling, and deformation outputs. Treat those as unavailable. Anything you build now must rest on the ten modalities that exist.

The 26-parameter design space and its boundaries

Each geometry is parametrized with 26 parameters that the README says completely describe the design. The parameter ranges were chosen deliberately, and the README states the reason: to avoid values that are difficult to manufacture or not aesthetically pleasing. That is a reasonable choice for a dataset meant to resemble real cars, and it is also the single most important constraint to understand before adopting it. A surrogate trained on DrivAerNet++ learns a mapping defined over that bounded region. Ask it to score a shape with a parameter combination outside the sampling range and you are extrapolating, with no evidence in the repository about how the model behaves there. The same applies to shape families the dataset does not cover. The README says the dataset covers all conventional car designs and spans both internal combustion engine and electric vehicle configurations through underbody and wheel variation, but it does not claim coverage of trucks, buses, or motorsport bodies. If your target is a heavy vehicle, this is the wrong corpus. The parameter ranges themselves are not reproduced in the README text, so the first thing to check on the Dataverse record is the actual bounds before you assume your design of interest falls inside them.

Getting the data: Dataverse, Globus, and a 39 TB decision

The dataset lives on Harvard Dataverse, split into subsets: 3D Meshes, Pressure, Wall Shear Stress, and Full CFD Domain. Total size is stated as 39 TB. The README directs users to Globus for efficient download, which is the practical route at that scale: Globus handles resumable, high-throughput transfers between endpoints, and pulling tens of terabytes through a browser is not realistic. The aerodynamic coefficients are published separately. The README's performance data table lists drag values as a CSV hosted on Dropbox, which means the lightweight part of the dataset (the scalar targets) is reachable without touching the bulk archive. That split is useful: you can prototype a tabular drag model from the CSV and the parametric models, then decide whether the volumetric and surface fields justify a multi-terabyte transfer. The README does not give per-subset sizes, so you cannot estimate transfer time from the repository alone. Check the Dataverse file listing for the subset you want. There is no pip package, no conda recipe, and no released version in the material provided, so there is no install step to document here. The repository is a dataset and benchmark distribution, not a library.

Licence: CC BY-NC 4.0 on the data, nothing declared on the code

The dataset is published under CC BY-NC 4.0, and the README states this both in the badge row and in the access section. The NonCommercial clause is the operative restriction: commercial use of the data is not permitted under those terms. For an academic group or a research lab this is usually workable with attribution. For anyone building a product, a consulting deliverable, or an internal tool at a company, it is a blocker that needs to be resolved before any engineering work starts, not after. Separately, the repository's licence field reports NOASSERTION, meaning no recognizable licence file was detected for the code itself. That is a different question from the data licence, and it is unresolved in the material available. If you intend to reuse scripts from the repository rather than just the data, ask the maintainer directly. None of this is legal advice; the point is that two separate permissions are in play and only one of them is stated clearly.

Benchmarks, leaderboards, and the maintenance picture

DrivAerNet++ was presented at NeurIPS 2024, and the README points to a leaderboard for submitting models and comparing results. The same maintainer has since released CarCrashNet, a crash simulation dataset, and CarBench, described as a unified benchmark for high-fidelity 3D car aerodynamics and generalization testing. The last push to the repository is dated 2026, so the project is active rather than frozen. That activity cuts both ways. A moving benchmark is more useful than a static one, but it also means numbers reported against an earlier state of the leaderboard may not be directly comparable later. There are no retrieved releases, so there is no versioned artifact to pin. If you need reproducibility for a paper, record the commit hash you used and the date you pulled the data, because neither the dataset nor the benchmark appears to carry a version number in the material provided. The Coming Soon modalities are a second moving part: if 2D slices or signed distance fields ship, the set of viable experiments changes, and a model trained on today's ten modalities will not automatically exploit them.

Where the approach breaks down, and what to use instead

The clearest failure mode is scale mismatch. A team that wants to predict drag for a small set of in-house shapes does not need 39 TB of volumetric CFD; it needs a few hundred well-chosen simulations and a regression model, or a commercial solver run directly. DrivAerNet++ is the wrong tool when the geometry you care about sits outside the 26-parameter space, when you cannot accept a non-commercial licence, or when your compute budget cannot absorb training on volumetric fields. There is also a subtler issue: the parameter ranges were filtered for manufacturability and aesthetics, so the dataset under-represents the extreme shapes where aerodynamic behaviour is most nonlinear. A surrogate trained here may look accurate on the benchmark and degrade on the unconventional designs the README says the dataset enables exploration of. As an alternative, consider running your own CFD campaign with OpenFOAM, which the repository lists as a topic and which is the solver family behind this kind of data. The difference in approach is fundamental: DrivAerNet++ gives you breadth and fixed labels at the cost of control over the design space and a restrictive licence, while a self-run OpenFOAM campaign gives you exactly the geometries and boundary conditions you need at the cost of simulation time and meshing effort. For a narrow design question, the second is often cheaper than downloading and filtering 39 TB.

Editorial conclusion

Adopt DrivAerNet++ if you are training or evaluating a neural surrogate for car aerodynamics and your work is non-commercial, since the CC BY-NC 4.0 terms on Harvard Dataverse rule out commercial use and the repository carries no code licence file at all. Do not adopt it if you need a small dataset, a fast download, or a surrogate that predicts drag for a geometry family outside the 26-parameter space it was generated from. Before committing, verify three things on the actual Dataverse record: the licence metadata as stored there, the size of the subset you intend to pull, and whether the aerodynamic coefficient CSV covers every design you need, because the README lists drag values as a separate Dropbox download rather than as part of the main archive.

Official sources

1. Issues
2. Mohamedelrefaie/DrivAerNet on GitHub
3. README