DGTLENG 106: Computational Techniques and AI in Engineering
DGTLENG 106 · Lesson 1 of 5

The Computational Landscape

Every Computation Answers a Question

Engineering computation is not monolithic. It is a collection of methods, each built to answer a specific class of question. The practitioner's job is not to master every solver — it is to know which question each method answers, what it costs, and where it fails. That knowledge determines whether you reach for a finite element model, a Monte Carlo simulation, or a machine learning surrogate — and whether the answer you get is worth the time and money you spent getting it.

The landscape organizes around five questions.

"Will It Break?" — Structural Analysis and Fatigue

Finite Element Analysis (FEA) for structural problems is the most mature computational method in engineering. You define geometry, material properties, boundary conditions, and loads. The solver discretizes the domain into elements, assembles a system of equilibrium equations, and solves for displacements, stresses, and strains. It is conceptually straightforward and computationally well-understood.

What it costs. Setup time dominates for complex assemblies — meshing, defining contact, applying realistic boundary conditions. A skilled analyst can spend weeks preparing a model that solves in hours. The compute cost scales with element count: a million-element linear static analysis runs in minutes on a workstation; a multi-million-element nonlinear contact problem might need a cluster and days of wall time. Fatigue analysis layers additional cost, requiring load history definitions and cycle-counting that multiply the setup effort.

Where it fails. FEA assumes you know the loads, the materials, and the boundary conditions. When any of these are uncertain or poorly characterized — which is common in early design — the output carries that uncertainty whether or not the analyst acknowledges it. Multi-scale problems (predicting macroscopic failure from microstructural features) remain computationally prohibitive for routine use. Real-time applications are impossible with traditional solvers.

"How Will Fluid Flow?" — CFD and Thermal Analysis

Computational Fluid Dynamics solves the Navier-Stokes equations on a discretized domain. It predicts pressure distributions, velocity fields, temperature distributions, and derived quantities like drag, lift, and heat transfer coefficients.

What it costs. CFD is notoriously expensive. Turbulence — the chaotic, multi-scale behavior of most engineering flows — cannot be resolved directly except for simple geometries at low Reynolds numbers. Practitioners use turbulence models (RANS, LES, DES) that approximate turbulent effects, each with different fidelity-cost trade-offs. A RANS simulation of external aerodynamics might run in hours. A wall-resolved LES of the same geometry might take weeks. Mesh sensitivity is severe: CFD results can change significantly with mesh refinement in ways that structural FEA results typically do not.

Where it fails. Turbulence modeling is an open problem in physics, not just in computation. No universal turbulence model exists. A model validated for attached boundary layers may fail for separated flow. A model tuned for low-speed flow may be inappropriate at transonic conditions. The practitioner must know which turbulence model is appropriate for their flow regime — and must validate against experimental data when possible.

"What's the Best Design?" — Optimization

Every engineering design is an optimization problem, whether or not it is formalized. You have objectives (minimize weight, maximize stiffness, minimize cost), constraints (stress limits, manufacturing feasibility, regulatory compliance), and design variables (dimensions, materials, topology). Optimization methods search this space systematically.

What it costs. The cost depends on the objective function evaluation. If each evaluation requires a full FEA or CFD run, and the optimizer needs hundreds or thousands of evaluations, the total cost is the product — and it gets large fast. Gradient-based methods are efficient (tens of evaluations) but require smooth, convex landscapes. Evolutionary algorithms handle rugged landscapes but need thousands of evaluations. The expertise cost is in problem formulation: defining the right objectives, constraints, and variables is harder than running the optimizer.

Where it fails. Optimization finds the best solution within the space you define. If you define the wrong space — wrong variables, wrong constraints, wrong objective — the optimizer will efficiently find the wrong answer. Multi-objective problems produce Pareto frontiers, which require engineering judgment to navigate. The optimizer does not tell you which trade-off to make.

"How Uncertain Are We?" — Monte Carlo and DOE

Deterministic analysis gives a single answer for a single set of inputs. Uncertainty quantification asks: given that the inputs are uncertain, how uncertain is the output? Monte Carlo simulation answers this by sampling input distributions and running the model thousands of times to build output distributions. Design of Experiments (DOE) provides structured sampling strategies to extract maximum information from minimum runs.

What it costs. Monte Carlo is embarrassingly parallel but requires large sample sizes for convergence — typically thousands to tens of thousands of evaluations. If each evaluation is a full-fidelity simulation, the total cost is often prohibitive. DOE methods (Latin hypercube, Sobol sequences, factorial designs) reduce sample count but require careful design and may miss nonlinear interactions if the sampling is too sparse.

Where it fails. Monte Carlo requires that you know the input distributions. If you assume a normal distribution when the real input is bimodal, the output distribution is wrong regardless of sample size. DOE assumes you know which inputs matter — screening designs can identify main effects, but higher-order interactions require exponentially more samples.

"What Does the Data Tell Us?" — Regression, Classification, Clustering

Data-driven methods learn input-output relationships from observed data rather than from physics equations. Regression predicts continuous outputs. Classification assigns categorical labels. Clustering discovers natural groupings in data without labels.

What it costs. The dominant cost is data, not compute. Training a regression model is cheap. Acquiring the labeled, validated, representative training data is expensive. In engineering, data is often sparse, high-dimensional, and expensive to generate (each data point may be a physical test or a high-fidelity simulation). The expertise cost is in feature selection, validation, and knowing when the model is being asked to extrapolate beyond its training domain.

Where it fails. Data-driven models are interpolation machines. They perform well within the training distribution and poorly outside it — often without warning. A model trained on normal operating conditions will not predict failure modes it has never seen. Overfitting to small datasets is endemic in engineering applications where sample sizes are measured in dozens, not millions.

The Trade-Off Triangle

Every computational method negotiates a three-way trade-off: fidelity (how accurately does it represent the physics), speed (how fast does it produce an answer), and generality (how broadly does it apply across problem types and conditions).

You get two. Not three.

High-fidelity CFD is accurate and general but slow. Lookup tables are fast and accurate within their domain but not general. Data-driven surrogates are fast and can be general but sacrifice fidelity guarantees.

How AI shifts this triangle. The fundamental contribution of AI to computational engineering is relaxing this constraint — partially. Surrogate models trained on high-fidelity simulation databases deliver speed without sacrificing as much fidelity, within their training domain. Transfer learning allows a model trained in one domain to bootstrap performance in a related domain, adding generality. Physics-informed neural networks embed governing equations as constraints, improving fidelity even with sparse training data.

The key qualifier is "within the training domain." AI does not eliminate the trade-off triangle. It shifts the frontier outward — but the frontier still exists, and extrapolation beyond it remains dangerous.

Test your understanding of each method category. Flip each card to compare your mental model with the summary. Pay particular attention to the failure modes — knowing where a method fails is more valuable than knowing where it works.

Assessment

Question 1 of 3Score: 0

A design team needs to evaluate 500 candidate geometries for aerodynamic drag. Each full CFD simulation takes 8 hours. They have one week of compute time available (roughly 168 hours). Which combination of methods would allow them to evaluate all 500 candidates within the time constraint? (Select all viable approaches)

Select all that apply

Choose an engineering product or system you are familiar with. Identify three distinct computational questions that arise during its design or operation, and map each to the most appropriate method category (structural/FEA, fluid/CFD, optimization, uncertainty quantification, or data-driven). For each mapping, explain: (1) why that method category is the right fit, (2) what the primary cost driver would be (setup, compute, data, or expertise), and (3) where the method might fail or produce misleading results for your specific application.