Data Generation: The Foundation of AI-Driven Engineering
Before AI Predicts, Data Must Be Built Right
Most AI models in engineering fail quietly, long before they ever make a prediction. The failure isn't in the algorithm. It's in the dataset nobody built properly.
Every simulation run holds a piece of the answer: how a design behaves under load, under heat, under impact. But that knowledge rarely survives past the project it was created for. It sits in scattered files, inconsistent formats, and solver outputs that were never meant to talk to each other. AI promises to turn that knowledge into prediction and foresight. It can't, unless the data behind it was generated on purpose, not assembled as an afterthought.
That raises an obvious question. If data generation matters this much, what does it actually involve?
What Is Engineering Data Generation
It starts with one validated model, not a blank page. Engineers take that baseline and introduce controlled changes, to geometry, material, thickness, connections, or loads. Each variation becomes a sample. It carries two things together: the design that was changed, and how it responded. Take a vehicle body model. Vary the panel thickness, the reinforcement geometry, the weld locations. Run each variant through the same crash condition. What comes back is a dataset that links design choices directly to outcomes, intrusion, acceleration, deformation, energy absorption. The sequence is simple. A design definition leads to a simulation setup. That setup produces a physical response. The response becomes engineering insight, something a team can actually act on.
This is what separates data generation from data storage. A folder of simulation files tells you what happened once. A properly generated dataset tells you why it happened, and what would happen if you changed something. The distinction is simple to state, but getting it right takes real discipline.
Why Engineering Data Matters
One simulation only ever answers one question, for one design, under one condition. Run a hundred of them independently, and comparing them becomes its own problem.
A structured dataset changes what's possible. Instead of asking whether one design passes or fails, a team can ask how performance shifts across an entire design space. That's a different kind of question, and it leads to different kinds of answers:
Which design variables actually move the needle on performance
Which geometric regions drive stiffness or energy absorption
Where performance turns sensitive or stops behaving linearly
Which designs balance competing goals best
None of this comes from volume alone. A hundred nearly identical models teach less than a dozen well-chosen ones. And every result needs a clear trail back to its model version and solver settings. Without that trail, a dataset is hard to trust, no matter how large it is.
So the bar is high: deliberate, traceable, varied. Meeting that bar at any real scale isn't something a small team does with spreadsheets and manual CAD edits. It takes a platform built for exactly this.
The Fix: MeshWorks and AIWorks
This is the gap DEP built its platform to close, with two tools: MeshWorks and AIWorks.
MeshWorks is the CAE foundation. It handles model preparation, meshing, parameterization, concept modelling, and CAD morphing, the groundwork that lets engineers create design variation without rebuilding every model by hand. That groundwork matters more than it sounds. If a model can't be changed in a controlled, repeatable way, a reliable design population never gets off the ground.
AIWorks takes over from there. It organizes the resulting data, runs statistical analysis, builds predictive models, and feeds them back into design optimization.
The next section looks at how MeshWorks makes hundreds of variants possible instead of a handful.
The Core Enablers of Data Generation
Generating hundreds of design variants only works if a model can be changed quickly, safely and repeatably. This is where MeshWorks earns its place. It turns a static model into something an engineer can explore, not just edit, with controlled changes to geometry, thickness, material and connections, and no rebuilding by hand. Every variant stays consistent with the validated baseline, which is what keeps the final dataset trustworthy. The capabilities behind this are:
- A validated baseline. Every dataset starts with one model that has solid mesh quality and known correlation to test data. Get this wrong, and every variant inherits the error.
- Defined design variables, with realistic limits. A thickness value might be bound by manufacturing constraints. A geometric change might be bound by packaging space.
- Parameterization, which converts a fixed model into one that responds to controlled input. Adjust a parameter, and a new variant appears automatically.
- Mesh morphing, which modifies an existing model's geometry while preserving most of its structure. It's especially useful early in concept development, before detailed CAD exists.
- Design of experiments, which decides which variants actually get built, based on variable ranges and how they interact with each other.
- Simulation automation, which sends each variant to the solver that fits the load case, such as LS-DYNA, Nastran, Abaqus, Star-CCM+ or another solver the discipline needs. It also manages submissions and checks convergence and contact behaviour before a result enters the dataset.
Each of those shortens the time it takes to go from one idea to one variant. But generating variants is only half the problem. Solving hundreds of them, fast enough to be useful, is the other half.
Reduced Order Modelling (ROM)
ROM converts a detailed, full order model into a lighter version that solves faster, without giving up the physics that matters.
The payoff shows up directly in runtime. For nonlinear problems, ROM can cut solve time from roughly two days to about one, a 2x improvement. For linear problems, converting a model into a beam-and-superelement representation can deliver up to a 10x reduction. Automated submodelling pushes this further. It isolates just the region around a critical hot spot from a detailed model that would normally take two days to run. That submodel typically solves in around twenty minutes, and engineers can iterate on it directly, without returning to the full model or back to CAD.
This is the piece that makes large-scale generation realistic. A handful of variants is easy without ROM. A few hundred, solved fast enough to matter, isn't.
From One Model to Hundreds
Put parameterization and ROM together, and the scale becomes concrete. In one program, a single baseline model generated roughly 200 structural variants. In another, one baseline vehicle model produced around 250 side-impact variants. Neither number is a coincidence. Parameterization produces variants worth building. ROM makes each one solvable fast enough that a few hundred of them takes weeks, not a full model year.
But speed only gets you variants. It doesn't tell you which 200 or 250 are actually worth generating. That takes engineering judgment, built on decades of hands-on CAE work across durability, vibration, impact, and electromagnetics. That judgment decides which parameters matter for a given load case, and whether the resulting dataset actually covers the range it needs to. So at this point, hundreds of simulations exist. What, exactly, is sitting inside them?
The Types of Data Generated
More than final numbers. A complete dataset captures the full relationship between a design and how it behaved.
- Geometry Data: CAD surfaces, finite element nodes, part boundaries, feature locations
- Mesh Data: element quality, mesh density, shell thickness, topology
- Design Data: material grades, thickness distributions, cross-section dimensions, weld locations
- Simulation Data: loads, constraints, contacts, time steps, solver settings
- Output Data: scalar values, response curves, and full spatial fields, stress, strain, displacement, pressure
- Meta Data: source model, parameter values, solver version, validation status
Stored together, this becomes an engineering record. Stored apart, it's just a pile of files with no memory of how they relate. And the same underlying principle, controlled variation producing a validated dataset, holds regardless of discipline. The challenge that remains is making sense of all this data.
Data Analysis: DEP's Patented Voxelization Methodology
To turn these datasets into meaningful comparisons, engineers need to understand how the results vary across hundreds of design combinations. Existing experimental history rarely provides enough comparable data to build this picture. Different models often use different meshes, different node numbering, different local coordinate systems. A node in one model may have no equivalent in another, especially once geometry starts to shift between variants.
Voxelisation solves this by giving every design a shared spatial language. It divides a three-dimensional region into small volume elements, called voxels, and maps geometry and engineering attributes such as stress, thickness, material and displacement into those shared locations. Different models become one common spatial representation, and that is what makes population-level comparison possible.
Scale makes this essential. A detailed crash model with around 20 million nodes can run to roughly 2 GB on its own. A detailed CFD case can involve 40 million cells and a 20 GB file, needing a machine with close to 128 GB of memory just to load it. Multiply either by a hundred variants, and comparing them by hand stops being realistic. Voxel-based analysis answers the questions that would otherwise stay buried: which regions drive stronger performance, where high- and low-performing designs actually diverge, and where the current design population is thin or missing coverage entirely.
DEP built this as patented statistical mapping technology inside MeshWorks, paired with a voxel-based approach in AIWorks. Few tools in this space offer anything comparable. It's what turns a stack of simulation results into something a team can actually trust, before a single model gets trained on it. Once the data is generated and understood, it is ready to become an AI model.
Data Analysis: DEP's Patented Voxelization Methodology
With this engineering background in place, the next challenge is AI prediction. As engineers, we have to present a study that is reliable and time-efficient. The data in hand should be enough to deliver the outcome we need.
Here's the short version: a trained model is only as good as what it was shown, and only as trustworthy as the physics it was checked against.
As these guiding principles are now clear, engineers can develop AI models that match their requirements. Before training starts, results from every solver get converted into one standardised format. That's what makes a stress result from one solver and a drag coefficient from another directly comparable, which is what lets a single model learn from all of them consistently. Before training starts, results from every solver get converted into one standardised format. That's what makes a stress result from one solver and a drag coefficient from another directly comparable, which is what lets a single model learn from all of them consistently.
Training itself balances two things. One is how closely predictions match the simulated results. The other is how well predictions obey the governing physics for that problem, the equations that describe how structures deform or fluids flow. Getting both right matters more than getting either one right alone. A model that only matches past results can still be wrong in ways that break physical sense. A model with only the physics term can drift from measured reality.
What comes out the other end are two kinds of models. Predictive models act like fast solvers, giving near-instant answers for a specific load case. Generative models work the other way. Give them a design space and a target, and they propose new geometry, closer in spirit to topology optimization, but informed by everything the dataset already taught them. Neither kind of model is possible without everything that happened earlier. The data had to be generated deliberately. It had to be understood at scale, through voxelisation, before training ever began.
Every AI model in engineering starts with the same quiet promise: it will know something a physics-based solver would have taken days to work out. That promise only holds if the data behind it was built with the same rigor as the engineering it's meant to replace. That's the thread running through all of this. Generate data on purpose. Solve it fast enough to matter. Understand it at scale before trusting it. Train on it only once all three are true. Skip any one of those, and the model at the end inherits the gap.
DEP built MeshWorks and AIWorks around that sequence, as a discipline rather than a feature list. From model preparation and variant generation to voxel-based analysis and AI model training, one platform covers every step. The model isn't the hard part anymore. The data was always the hard part, and getting it right, deliberately, traceably and at scale, is where DEP starts.
