Newton’s laws describe motion. Conservation of mass describes how material moves through a system. Conservation of energy constrains thermal and mechanical processes. Maxwell’s equations describe electromagnetic behavior. The Navier–Stokes equations describe fluid motion. Constitutive laws describe how materials respond to stress, strain, temperature and other variables.

These laws are extraordinarily successful.

Yet an engineer can know the governing equations, solve them with a sophisticated computer, use high-quality material data and still be unable to state with certainty exactly what a real structure, machine, river, aircraft, vehicle or process will do at some future instant.

That is not a contradiction. The fundamental mistake is to confuse knowledge of the governing law with knowledge of every quantity required to apply that law to a particular real system.

Consider the basic equation of motion: F=ma. The equation itself is not uncertain in the ordinary engineering sense. But suppose an engineer wants to determine the future position of a vehicle.

The calculation requires more than the law:

x(t) = x₀ + v₀t + ½at²

Now the engineer needs:

the initial position (x_0),
the initial velocity (v_0),
the acceleration (a),
the time (t),
and the assumption that the acceleration model remains appropriate.

Each of those quantities may contain uncertainty.

The equation has not failed.

The information supplied to the equation is incomplete.

This distinction becomes even more important in complex systems. A structural model requires geometry, loads, material properties, support conditions, imperfections and deterioration assumptions. A hydraulic model requires rainfall or flow inputs, terrain, roughness, cross-sections, boundary conditions and assumptions about the hydraulic regime. A traffic model requires demand, route choice, vehicle behavior, signal operation and network conditions.

The governing physics may be well established while the particular state of the system is only partially known.

This is why engineering prediction should never be interpreted as simply:

Physics → Answer

A more realistic chain is:

Physics → Model → Inputs → Computation → Prediction

Every arrow introduces opportunities for uncertainty.

The distinction is recognized explicitly in modern engineering practice. ASME’s verification, validation and uncertainty-quantification framework, for example, treats the credibility of computational predictions as something that must be demonstrated for a particular context of use rather than assumed merely because the underlying equations are physically meaningful.

The uncomfortable conclusion is simple:

Knowing the laws of physics tells us what can happen under specified conditions. It does not guarantee that we know the conditions well enough to predict exactly what will happen in reality.

The Four Layers of Engineering Reality

A useful way to understand engineering uncertainty is to separate four concepts that are often unconsciously merged.

Law

A law expresses a physical relationship believed to hold under defined conditions.

Examples include:

Q = AV

σ = Eε

∇·u = 0

for appropriate physical contexts and assumptions.

The law constrains reality. It does not automatically specify the complete state of a particular engineering system.

Model

A model is an engineering representation of reality.

A real bridge is a three-dimensional physical object containing material variability, construction tolerances, connections, residual stresses, corrosion, cracks, temperature gradients and interaction with foundations and soil.

The analytical model might instead contain:

beam elements,
idealized supports,
nominal dimensions,
representative material properties,
idealized load combinations,
simplified connections.

The model is not the bridge.

It is a controlled approximation of the bridge.

Prediction

A prediction is an estimated future or unobserved state generated from the model, inputs and computational method.

For example:

R̂ = f(x, θ, M)

where:

R̂ = predicted response,
x = system inputs,
θ = parameters,
M = model formulation.

Reality

Reality is the actual behavior of the physical system. It is revealed through observation, measurement and experience — and sometimes through failure.

The relationship can therefore be represented as:

Layer	Fundamental question	Example
Law	What physical relationship governs the system?	Conservation of momentum
Model	How do we represent the real system?	Finite-element model
Prediction	What does the model say will happen?	Maximum displacement = 18 mm
Reality	What actually happens?	Measured displacement = 21 mm

The gap between prediction and reality does not automatically mean the physics was wrong.

The discrepancy may result from inaccurate loads, material variability, support conditions, geometry, environmental effects, measurement error, neglected mechanisms or limitations of the model.

This distinction is central to modern computational engineering. ASME VVUQ guidance explicitly focuses on communicating the evidence supporting the use of computational models for a particular context of use.

That phrase matters. A model may be highly credible for one question and unsuitable for another. A structural model validated for elastic displacement under static loading cannot automatically be assumed equally reliable for fracture, fatigue, impact or progressive collapse.

Likewise, a hydraulic model that reproduces historical flood levels reasonably well is not automatically guaranteed to predict an unprecedented future flood under changed land use and climate conditions.

Where Uncertainty Enters an Engineering Problem

Engineering uncertainty is not one thing. It is a collection of different mechanisms that enter at different stages of the prediction process.

A simplified uncertainty chain is:

Initial State → Measurements → Parameters → Model → Numerical Solution → Future Inputs

Each stage can introduce uncertainty.

Major sources

Source	Engineering example	Typical consequence
Initial conditions	Initial velocity, temperature, stress state	Different subsequent trajectories
Measurement uncertainty	Sensor, survey or laboratory error	Uncertain input values
Material variability	Concrete strength, soil stiffness, steel fatigue properties	Scatter in response
Boundary conditions	Actual support restraint or groundwater level	Different system behavior
Environmental conditions	Temperature, wind, moisture, corrosion	Changing system properties
Model simplification	Beam instead of full 3-D structure	Missing mechanisms
Turbulence	Unresolved fluid fluctuations	Uncertain instantaneous behavior
Numerical approximation	Mesh, time step, solver tolerance	Numerical error
Human behavior	Driver, operator, maintenance response	Variable system input
Future inputs	Traffic growth, rainfall, energy demand	Uncertain future state

These categories should not be casually added together as though they were interchangeable.

For example, measurement uncertainty is fundamentally different from uncertainty caused by not knowing which physical model is appropriate.

NIST’s measurement framework distinguishes and quantifies components of measurement uncertainty and provides methods for propagating uncertainty through measurement equations.

That distinction matters because better measurement can reduce measurement uncertainty but cannot necessarily reduce model-form uncertainty. If an engineer measures temperature to six decimal places but uses an inappropriate heat-transfer model, the extra digits do not make the prediction more truthful.

This leads to one of the most important engineering lessons:

More precise inputs ≠ More accurate prediction

Precision and accuracy are related, but they are not the same thing. A prediction can be numerically precise while physically inaccurate.

Initial and Boundary Conditions: The Problem Starts Before the Calculation

One of the least appreciated sources of engineering uncertainty is the state of the system before the calculation begins. Mathematical equations frequently require initial and boundary conditions.

For a dynamic system: f(x, t), and the future state depends on the starting state: x(t₀)

If the initial state is not known exactly, the future prediction inherits that uncertainty. This becomes especially important in nonlinear systems.

Suppose two simulations begin with: x₀ and x₀ + Δx₀ where Δx₀ is very small.

For some systems, the resulting trajectories remain close. For others, the difference can grow rapidly. This is not necessarily a failure of deterministic physics. It is a property of the system’s dynamics.

Boundary conditions create a similar problem

Consider a structural member.

The textbook model may assume:

perfectly fixed support,
perfectly pinned support,
uniform material,
exact geometry.

A real connection may have:

finite rotational stiffness,
bolt slip,
weld flexibility,
contact effects,
construction tolerances,
local deformation.

The difference may alter the load path. The same problem appears in geotechnical engineering.

A foundation calculation may require assumptions about:

q = f(B, L, D, γ, c, φ, E_s, …)

But soil is spatially variable.

The value of cohesion (c), friction angle (\phi), stiffness (E_s), density and groundwater conditions may change from one location to another.

The engineer is therefore not dealing with a single perfectly known soil property. The engineer is dealing with a field of uncertain properties inferred from limited observations. Hydrology provides an especially clear example. The USGS notes that flood-frequency analysis inherently contains risk and uncertainty and that statistical analysis alone cannot completely define the flood potential of a particular watershed. The issue is not that the equations of fluid mechanics suddenly stop working during a flood. The issue is that the engineer does not possess perfect knowledge of the watershed, future rainfall, catchment response and statistical behavior of extreme events.

The practical implication

A calculation should therefore never begin with: “What equation should I use?”

It should begin with:

“What must be known for this equation to produce a trustworthy result, and how well do I actually know it?”

That is a much more mature engineering question.

Materials, Measurements, and Environmental Variability

Real materials are not mathematical constants. A steel grade may have a specified yield strength, but individual specimens do not necessarily possess exactly that value. Concrete strength varies between batches and specimens. Soil properties vary spatially. Asphalt properties depend on temperature, aging, loading history and composition. Composite materials can contain manufacturing variability, voids, fiber misalignment and defects.

Even when a property is measured accurately, the measured specimen may not perfectly represent the full engineering system.

Consider Young’s modulus:

σ = Eε

The equation may be simple.

But what value of (E) should be used? A laboratory value? A design value? A temperature-dependent value? A value representing the actual material after aging? A local value? A statistical lower percentile?

The answer depends on the engineering question.

Measurement uncertainty

Suppose a sensor measures: x=100.0, with uncertainty: u_x=0.5

The result is not simply “100.0.” It represents an estimate accompanied by a statement about uncertainty.

For a derived quantity,

y = f(x₁, x₂, …, xₙ)

uncertainty in the inputs can propagate into uncertainty in (y).

For small, approximately independent uncertainties, a common first-order expression is:

u_y² ≈ Σᵢ₌₁ⁿ (∂f/∂xᵢ)² u_{xᵢ}²

with covariance terms added where inputs are correlated.

NIST provides formal guidance for evaluating, expressing and propagating measurement uncertainty, including both Type A and Type B evaluations.

Environmental uncertainty

Engineering systems also operate in environments that change.

Temperature affects:

material stiffness,
thermal expansion,
viscosity,
equipment performance,
pavement behavior,
battery performance.

Moisture affects:

soil strength,
concrete durability,
corrosion,
pavement performance,
electrical insulation.

Wind affects:

structural loads,
vehicle stability,
crane operation,
aircraft behavior.

Time itself changes the system. A structure does not necessarily have the same properties at: t=0, and t = 30 years, because deterioration, fatigue, corrosion, creep, shrinkage and damage may alter its state.

The FAA’s fatigue and damage-tolerance framework illustrates this directly: aircraft structural safety involves repeated loading, environmental effects, material behavior, inspection, maintenance and life-cycle management rather than a single static strength calculation.

Thus, a prediction should often be written conceptually as:

R(t) = f[load history, material, environment, damage, time]

rather than simply:

R = f(load)

The second expression is easier. The first is closer to reality.

Models Are Necessary — and Never the Whole Reality

There is an uncomfortable truth at the center of engineering:

A model becomes useful precisely because it leaves things out.

A model that included every molecule, defect, turbulence fluctuation, human action, environmental change and microscopic interaction would be computationally impossible for almost any practical engineering system. So engineers simplify.

A beam becomes one-dimensional element. A soil deposit becomes homogeneous layer. A traffic stream becomes q=kv. A turbulent flow becomes a set of averaged quantities plus a turbulence closure model. A complex structure becomes thousands or millions of finite elements. Simplification is not a weakness. It is how engineering becomes possible. The problem arises when the approximation is forgotten after the calculation is complete.

Model-form uncertainty

Suppose reality behaves according to:

R = f_real(X)

but the engineer uses:

R_model = f_model(X)

The difference

f_real(X) − f_model(X)

is not necessarily caused by inaccurate measurements.

It may arise because the model does not represent some physical mechanism adequately. This is called model-form uncertainty.

Examples include:

assuming linear elasticity when plasticity becomes important,
assuming steady flow when transient behavior matters,
assuming two-dimensional flow when three-dimensional effects dominate,
ignoring soil-structure interaction,
assuming stationary climate statistics,
neglecting thermal gradients,
treating a connection as perfectly rigid,
representing turbulence through an imperfect closure approximation.

The USGS discussion of flood inundation provides a useful practical example: uncertainty can enter through hydrologic data, topographic data and the hydraulic model itself, while assumptions such as steady flow can affect the predicted inundation boundary.

The danger of model confidence

A sophisticated model can create a dangerous psychological effect.

Engineers see:

millions of elements,
highly refined meshes,
nonlinear solvers,
detailed graphics,
decimal-level outputs.

The result looks authoritative.

But computational sophistication does not automatically imply physical completeness. A model can be numerically elaborate and conceptually wrong. This is why verification and validation must be separated.

Verification asks:

Did we solve the mathematical model correctly?

Validation asks:

Does the model adequately represent the physical system for the intended application?

ASME explicitly treats verification and validation as distinct elements of computational credibility and incorporates experimental uncertainty into validation assessment. That distinction is fundamental. A perfectly solved wrong model is still wrong.

Turbulence, Nonlinearity, and Sensitivity to Small Changes

Some engineering systems are particularly resistant to precise prediction because their dynamics amplify small differences. Fluid turbulence is the classic example.

The Navier–Stokes equations provide the governing framework for viscous fluid motion, but practical turbulent flows contain enormous ranges of spatial and temporal scales. Engineers therefore introduce turbulence models, averaging procedures and numerical approximations.

The difficulty is not that fluid mechanics lacks governing equations. The difficulty is that the complete instantaneous turbulent state is enormously complicated and cannot generally be represented directly at engineering scales.

Nonlinearity changes everything

For a linear relationship: y=ax, a small change in (x) produces a proportional change in (y).

But nonlinear systems can behave very differently: y=f(x), where the sensitivity

S_x = (ΔR/R) / (Δx/x)

may vary dramatically with operating condition.

Near a critical threshold, a small parameter change may cause a disproportionately large response.

Examples occur in:

buckling,
fracture,
structural instability,
fluid transitions,
combustion,
control systems,
traffic breakdown,
geotechnical failure,
electrical grid stability.

Conceptual sensitivity picture

Response
  ^
  |                         /
  |                      _/
  |                   __/
  |                __/
  |______________/
  +----------------------------> Input
                 ^
          small input change
          can cause large
          response change

This is why engineering safety cannot be based solely on the statement:

“The expected input is below the calculated limit.”

The engineer must also ask:

How sensitive is the system near that limit?
How uncertain is the input?
How uncertain is the resistance?
Is there a failure mode not represented by the model?
What happens if several unfavorable conditions occur simultaneously?

Chaos is not ignorance

This distinction is important. A deterministic system can be extremely difficult to predict over long horizons even when its governing equations are known. In such systems, uncertainty in the initial state can grow with time.

That means:

small initial uncertainty → larger future uncertainty

The correct response is not to declare the physics unreliable. It is to recognize that predictability has limits even within deterministic physical systems. The IPCC provides a large-scale example. Its assessment separates uncertainty associated with internal variability, model response and future scenarios; the relative importance changes with region, variable and time horizon.

For regional climate projections, chaotic atmospheric variability can remain an important source of uncertainty, particularly at smaller spatial scales. The engineering lesson extends well beyond climate science:

Determinism of the governing equations does not imply unlimited predictability of a particular future state.

Numerical Simulation Does Not Remove Uncertainty

Modern engineering increasingly relies on computational simulation. Finite-element analysis. Computational fluid dynamics. Multibody dynamics. Computational electromagnetics. Digital twins. Monte Carlo simulation. Machine-learning surrogates. Optimization algorithms.

These tools are immensely powerful. But the computer does not calculate reality. It calculates a numerical representation of a model. A numerical result can therefore contain several distinct error and uncertainty components.

A useful conceptual decomposition is:

Input Uncertainty + Parameter Uncertainty + Model Uncertainty + Numerical Error + Scenario Uncertainty

This is not a universal equation for literally adding these quantities; the components can interact and must be treated according to their statistical and physical relationships.

Numerical error

Even with the correct mathematical model, numerical calculations approximate the governing equations.

For example:

spatial discretization,
temporal discretization,
iterative convergence,
floating-point effects,
solver tolerances,
interpolation,
extrapolation.

Mesh refinement may reduce discretization error. Smaller time steps may improve temporal resolution. Tighter solver tolerances may improve convergence. But none of these automatically corrects an incorrect physical model.

This creates a critical hierarchy:

Question	What it addresses
Is the equation physically appropriate?	Model selection
Is the mathematical problem formulated correctly?	Formulation
Is the numerical implementation correct?	Verification
Is the model representative of reality?	Validation
Are the inputs realistic?	Input uncertainty
Is the prediction sensitive to assumptions?	Sensitivity analysis
Is the uncertainty acceptable for the decision?	Risk/reliability

The order matters.

There is little value in reducing numerical error from (2%) to (0.2%) if uncertainty in the physical parameters is (30%).

The false precision problem

Suppose a simulation reports: R=17.4382916
An engineer may instinctively interpret this as a highly accurate result. But if the combined engineering uncertainty is: R = 17.4 ± 3.0, then reporting seven decimal places creates an impression of certainty that the physical evidence does not support. The extra digits are computational output, not additional knowledge. This is the central danger of false precision.

A useful rule is:

Numerical resolution ≠ physical certainty

Modern engineering standards increasingly recognize this problem. ASME’s V&V framework explicitly addresses the relationship between computational solution accuracy and uncertainty in experimental data rather than treating simulation output as inherently authoritative.

From Prediction to Reliability and Risk

If perfect prediction is impossible, how can engineering design anything safely?

The answer is that engineering does not fundamentally require perfect prediction. It requires controlled uncertainty. This is the difference between prediction and reliability. A structural engineer does not need to know the exact future load on every beam. A bridge designer does not need to know the exact axle position of every vehicle over the next 100 years. A flood engineer does not need to know the exact rainfall sequence decades into the future.

Instead, engineering establishes:

representative actions,
resistance models,
statistical distributions,
safety factors,
reliability targets,
inspection requirements,
redundancy,
robustness,
monitoring,
maintenance strategies.

From one number to a distribution

Instead of saying: R=100, the engineer may represent resistance as a random variable: R ~ f_R(r), and load as: S ~ f_S(s).

Failure occurs when: S>R. Therefore, the engineering question becomes: P(S>R), rather than: “What is the exact load?”

This is a profound shift. The objective is no longer to eliminate uncertainty. It is to ensure that the probability and consequences of unacceptable performance remain within an appropriate engineering framework. The Eurocodes explicitly incorporate structural reliability into the basis of design, including safety, serviceability, durability, time dependence and uncertainty.

Safety factors are uncertainty management

A safety factor is sometimes presented as though it were simply an arbitrary margin. It is better understood as part of a broader uncertainty-management framework.

Conceptually:

Design Resistance < Nominal Resistance

and

Design Action vs Nominal Expected Action

may be used to provide separation between uncertain demand and uncertain capacity.

The precise reliability framework varies by discipline and code, but the underlying engineering principle is consistent:

Uncertainty → Reliability requirement → Design margin

Probabilistic risk assessment

For complex systems, engineers can go further.

The U.S. Nuclear Regulatory Commission’s probabilistic risk assessment framework, for example, uses event trees, fault trees, human reliability analysis and Monte Carlo techniques where appropriate to evaluate combinations of events and uncertain contributors to system outcomes. This is particularly important because accidents rarely arise from one perfectly isolated variable.

They may result from a chain:

initiating event → system response → component failure → human response → secondary consequence

The engineering problem is therefore not merely: “Can this component fail?”

It is:

“Under what combinations of conditions can the system enter an unacceptable state, how likely are those pathways, and what barriers prevent them?”

That is a far more realistic concept of prediction.

The Engineering Response: Design for Uncertainty, Not Against It

The deepest lesson of engineering uncertainty is not that engineers should become pessimistic. It is that engineers should become more explicit about what they know, what they assume, and what they do not know.

The wrong response to uncertainty is: “We cannot know everything, so prediction is impossible.”

The opposite extreme is equally dangerous: “The equations are correct, therefore the prediction is certain.”

Both are wrong. The correct engineering position lies between them.

1. Separate laws from assumptions

Write down what comes from established physical principles and what comes from engineering assumptions. For example:

Governing Equation + Constitutive Assumption + Boundary Condition + Parameter Estimate

is much more informative than presenting the final number alone.

2. Quantify what can be quantified

Measurement uncertainty, parameter variability and statistical uncertainty should be estimated where meaningful.

NIST’s uncertainty methodology provides a formal framework for doing exactly this for measurement results.

3. Challenge the model

Ask:

What physical mechanism has been omitted?
Is the model valid for the operating regime?
Has it been validated against independent observations?
Does it remain valid outside the calibration range?

This is where verification and validation become essential.

4. Perform sensitivity analysis

If:

R = f(x₁, x₂, …, xₙ)

then determine which inputs dominate the uncertainty.

A parameter that contributes almost nothing to output uncertainty does not deserve the same investigative effort as one that dominates the result.

In conceptual form:

S_x = (ΔR/R) / (Δx/x)

A high-sensitivity parameter deserves attention.

5. Treat future scenarios honestly

A future traffic volume, rainfall intensity, energy demand or climate condition is not an ordinary measured input. It is a scenario.

The IPCC’s treatment of climate projections demonstrates why different future pathways, model responses and internal variability can produce different outcomes even when the underlying physical science is strong.

The same logic applies to infrastructure. A road designed for today’s traffic is not automatically designed for tomorrow’s traffic. A drainage system designed from historical rainfall statistics may face a different design environment if the underlying climate or catchment changes. A building designed for a specified occupancy cannot assume that actual future use will remain identical.

6. Design for robustness

A robust system is not one that works perfectly under one predicted condition. It is one that remains acceptably safe when reality deviates from the prediction.

That can mean:

redundancy,
ductility,
drainage capacity,
protective barriers,
conservative detailing,
fail-safe mechanisms,
inspection,
monitoring,
maintainability,
adaptive operation.

This is perhaps the most important transition from traditional calculation to modern engineering thinking.

The Final Engineering Hierarchy:

A mature engineering workflow can therefore be represented as:

                 PHYSICAL LAWS
                       │
                       ▼
                 ENGINEERING MODEL
                       │
             ┌─────────┴─────────┐
             ▼                   ▼
        INPUT DATA          ASSUMPTIONS
             │                   │
             └─────────┬─────────┘
                       ▼
                COMPUTATIONAL
                   ANALYSIS
                       │
                       ▼
                  PREDICTION
                       │
             ┌─────────┴─────────┐
             ▼                   ▼
       UNCERTAINTY            VALIDATION
        ANALYSIS              & EVIDENCE
             │                   │
             └─────────┬─────────┘
                       ▼
                RELIABILITY /
                   RISK
                       │
                       ▼
                 ENGINEERING
                   DECISION
                       │
                       ▼
                    REALITY

The objective is therefore not to force reality to behave like the model. The objective is to understand how far the model can be trusted, where it can fail, and how the engineering system should respond when reality inevitably differs from the prediction.

Conclusion: Engineering Is Not the Science of Knowing the Future

The greatest misconception in engineering may be the belief that a sufficiently sophisticated calculation can eventually eliminate uncertainty. It cannot.

Better physics reduces uncertainty caused by incomplete understanding of physical mechanisms. Better experiments reduce uncertainty in parameters. Better sensors reduce measurement uncertainty. Better models reduce model-form limitations. Better numerical methods reduce computational error. Better data improve calibration. Better monitoring reveals changing system conditions.

But none of these creates perfect knowledge of the future. There will always be quantities that cannot be known exactly before the event. There will be initial states that are imperfectly measured. There will be material variability. There will be environmental changes. There will be uncertain boundary conditions. There will be model limitations. There will be nonlinear behavior. There will be turbulent fluctuations. There will be numerical approximations. There will be human decisions.

And there will be future inputs that simply do not exist yet. This does not make engineering weak. It explains why engineering has developed reliability theory, safety factors, probabilistic design, sensitivity analysis, verification and validation, monitoring, inspection, redundancy, robustness and risk assessment.

The mature engineer therefore does not ask only:

“What will happen?”

The better questions are:

“What do we know?”

“What are we assuming?”

“What could make the prediction wrong?”

“How sensitive is the outcome to those uncertainties?”

“What happens if reality is worse than our central estimate?”

And finally:

“Can we design the system so that uncertainty does not become failure?”

That is the real uncertainty principle of engineering. Physics tells us what reality permits. Models tell us how we choose to represent it. Calculations tell us what follows from those models and assumptions. Evidence tells us how much confidence we should place in them. And engineering design exists in the space between the prediction and the physical world. The strongest engineer is therefore not the one who produces the most precise prediction. It is the one who knows exactly where precision ends, where uncertainty begins, and how to build safely beyond that boundary.

Selected references

IPCC AR6 — Chapter 1: Framing, Context and Methods — treatment of confidence, likelihood, internal variability, model response and scenario uncertainty.
IPCC AR6 — Chapter 8: Water Cycle Changes — detailed treatment of model, scenario and internal-variability contributions to uncertainty.
IPCC AR6 Figure 8.23 — Sources of uncertainty in precipitation projections — particularly useful for the article’s “cascade of uncertainty” concept.
NIST — Guidelines for Evaluating and Expressing Measurement Uncertainty — formal measurement-uncertainty framework.
NIST — Simple Guide for Evaluating and Expressing the Uncertainty of Measurement Results — practical uncertainty evaluation and propagation.
ASME — VVUQ 1: Verification, Validation and Uncertainty Quantification Terminology — computational-model credibility and context of use.
ASME — V&V 20: Computational Fluid Dynamics and Heat Transfer — verification, validation and experimental uncertainty.
European Commission JRC — Reliability Background of the Eurocodes — uncertainty and reliability in structural design.
USGS — Bulletin 17C: Guidelines for Determining Flood Flow Frequency — statistical prediction, flood-frequency uncertainty and confidence intervals.
USGS — Sources of Uncertainty in Flood Inundation Maps — uncertainty from hydrologic data, topography and hydraulic modelling.
U.S. NRC — Backgrounder on Probabilistic Risk Assessment — event trees, fault trees, human reliability and Monte Carlo methods.
FAA — Fatigue and Damage Tolerance — life-cycle uncertainty in aircraft structures.

When Physics Is Certain but Engineering Outcomes Are Not

The Uncertainty Principle of Engineering: Why Knowing the Laws of Physics Does Not Mean Knowing What Will Happen

Table of Contents

Quick Links

The Difference Between Knowing and Predicting