When More Accuracy Becomes Less Truthful: The Deceptive Illusion of Precision in Physics and Engineering

Engr. Kamran Abbas

BSc Civil Engineering

MS Transportation Engineering

The Number Is Not the Truth
Precision, Accuracy, Error, and Uncertainty Are Different
Where Engineering Uncertainty Actually Comes From
A More Detailed Model Can Still Be the Wrong Model
Why CFD Makes the Problem Especially Serious
Verification Is Not Validation
Sensitivity Analysis: Finding What Actually Matters
Experiments Must Be Designed Around Uncertainty
How False Precision Enters Engineering Decisions
Engineering Truth Requires Evidence, Not Decimal Places
References

Quick Links

Health and Fitness Tools

Engineering Calculators

Finance Calculators

Economics Calculators

Percentage Calculators

Sciences Calculators

Math Calculators

Unit Converters

The Number Is Not the Truth

Modern engineering has acquired an extraordinary ability to produce numbers. A structural model can contain millions of finite elements. A computational fluid dynamics simulation can resolve millions or billions of computational cells. A trajectory calculation can track position and velocity at extremely small time intervals. Sensors can record pressure, temperature, acceleration, strain, velocity, and vibration at high sampling rates. And after all that computation, a screen may display something like:

v = 127.384 m/s

The number looks authoritative. It has six significant digits. It is precise. It is reproducible inside the software. Another engineer can run the same model and obtain essentially the same value. But there is a fundamental question that the number itself cannot answer:

How closely does 127.384 m/s represent the physical quantity that actually exists in the real system?

That is the difference between numerical precision and physical accuracy. A computer can solve a mathematical problem to extraordinary numerical precision while the mathematical problem itself remains an approximation of reality.

NASA’s CFD verification and validation guidance makes this distinction explicit. Verification examines whether the computational implementation correctly solves the intended mathematical model; validation examines whether the model and simulation adequately represent physical reality. NASA also identifies modeling, experimental, and computational uncertainties as distinct parts of the credibility problem.

This matters because engineering decisions are not made on the basis of attractive numbers. They are made on the assumption that those numbers represent reality sufficiently well for the decision being made.

A bridge is not safe because a finite-element program reports its maximum stress σ_max = 238.47261 MPa. An aircraft is not aerodynamically correct because CFD predicts C_L = 0.873421. A vehicle is not guaranteed to stop within a particular distance because a simulation calculates d = 43.7281 m.

The decimal places describe the representation of the computational result. They do not automatically describe the knowledge we possess about the physical system. This is the central danger of false precision. The more sophisticated the computational environment becomes, the easier it is to confuse a highly resolved answer with a highly certain answer.

That confusion is particularly dangerous because modern engineering increasingly combines:

high-performance computing,
artificial intelligence,
automated optimization,
digital twins,
high-resolution sensors,
CFD,
finite-element analysis,
probabilistic simulation,
surrogate models,
enormous experimental datasets.

The engineering challenge is therefore changing.

The problem is no longer simply, ‘Can we calculate the answer?’

It is increasingly:

Do we know how much confidence the answer deserves?

Precision, Accuracy, Error, and Uncertainty Are Different

The first defense against false precision is terminology. Precision and accuracy are not interchangeable. NIST describes accuracy as closeness of agreement with an accepted reference value, while precision concerns the agreement among measurement results under specified conditions. NIST specifically cautions against treating precision as a quantitative substitute for accuracy and recommends expressing measurement uncertainty rather than assigning a numerical “accuracy” to a result.

Consider a temperature sensor that repeatedly reports 24.382, 24.381, 24.383, 24.382 °C. The measurements are tightly clustered. The instrument therefore demonstrates high repeatability. But suppose the actual reference temperature is
24.90°C. The readings are precise but biased.

Conversely, measurements might scatter around the reference value. They may collectively be representative, yet individually lack repeatability. The distinction becomes even more important in computational engineering.

Four Concepts that should not be Confused

Concept	Engineering meaning	Typical question
Precision	Degree of agreement among repeated results	Do repeated calculations/measurements agree?
Accuracy	Closeness to an accepted reference or physical reality	Is the result close to reality?
Error	Difference between a computed/measured result and a reference or exact solution, where defined	How far is the result from the reference?
Uncertainty	Quantified lack of knowledge associated with the result	How much could the result reasonably vary or remain unknown?

The distinction is fundamental. Suppose a simulation produces Q=100.0000 and a second simulation using the same model produces Q=100.0001. The computational results appear extremely precise. But if changing the turbulence model produces Q=92.4 and another defensible turbulence model produces Q=108.7 then the six decimal places in the original answer are not the important information.

The important information is the sensitivity of the prediction to the physical-model choice.

This is why modern verification, validation, and uncertainty quantification frameworks explicitly treat uncertainties in model inputs, model form, numerical solutions, experimental data, and uncertainty propagation. ASME’s VVUQ framework exists precisely to establish terminology and evidence for the credibility of computational models.

The Hierarchy of Confidence

A useful engineering hierarchy is:

More decimal places ≠ more physical knowledge

and:

Numerical convergence ≠ physical validation

and:

Model complexity ≠ model correctness

These three distinctions should be treated as basic engineering discipline.

Where Engineering Uncertainty Actually Comes From

Uncertainty does not enter engineering models at one single point. It can enter through measurements, parameters, assumptions, mathematical formulations, boundary conditions, numerical discretization, geometry, material properties, environmental conditions, and even the interpretation of the experiment used for validation.

A useful representation is:

Y = f(X₁, X₂, …, Xₙ; θ, M)

where:

(Y) is the predicted output,
(X_i) are uncertain inputs,
(θ) represents model parameters,
(M) represents the chosen model form.

The uncertainty in (Y) can therefore arise from several fundamentally different sources.

Major Uncertainty Classes

Source	Example	Typical mechanism
Measurement uncertainty	Pressure measurement	Sensor resolution, calibration, environmental effects
Input uncertainty	Material strength	Natural variation or incomplete knowledge
Parameter uncertainty	Turbulence-model coefficient	Imperfectly known parameter
Model-form uncertainty	RANS turbulence model	Simplification of physical processes
Boundary-condition uncertainty	Inlet turbulence intensity	Imperfect knowledge of real operating condition
Geometry uncertainty	Surface roughness	Manufacturing or measurement variation
Numerical uncertainty	Mesh/time-step dependence	Discretization and convergence
Experimental uncertainty	Wind-tunnel measurement	Instrumentation and test conditions
Extrapolation uncertainty	New operating regime	Model applied beyond validated evidence

NASA technical literature distinguishes numerical solution-bias uncertainty from modeling uncertainty and identifies model-form and model-parameter uncertainty as separate concerns. It also notes that even exact solution of the mathematical equations does not remove the prediction bias introduced by physical approximations. This leads to a crucial engineering observation:

A perfect solution to an imperfect model can still be an imperfect prediction.

Consider a CFD calculation. Suppose the solver has:

negligible round-off error,
excellent iterative convergence,
a very fine mesh,
a small time step,
carefully implemented equations.

The numerical solution may be exceptionally well resolved. But the result can still be wrong because:

the turbulence model is inadequate,
transition is modeled incorrectly,
wall roughness is uncertain,
inlet conditions are inaccurate,
separation physics are poorly represented,
the geometry differs from the physical object,
the operating conditions differ from the experiment.

NASA explicitly identifies turbulence modeling, transition, boundary conditions, surface roughness, and other physical modeling assumptions as sources of CFD uncertainty. This is why increasing computational resolution is sometimes the wrong response to an uncertain model. If the dominant uncertainty comes from the physics, doubling the mesh density may produce a beautifully converged answer to the wrong physical approximation.

A More Detailed Model Can Still Be the Wrong Model

Engineering culture often rewards complexity. A model with:

more elements,
more equations,
more parameters,
smaller time steps,
higher mesh resolution,
more sophisticated algorithms

can appear inherently superior.

That assumption is unsafe. A model is an abstraction. It deliberately removes information from reality so that a problem becomes solvable. The real world contains enormous numbers of interacting variables. Engineering models retain those variables judged important for the intended application and simplify or eliminate others.

That simplification is not automatically a defect. The problem begins when the simplification is hidden. Consider a fluid-flow problem. A physical flow contains three-dimensional structures across a very large range of spatial and temporal scales. A practical CFD model may use the Reynolds-averaged Navier–Stokes equations together with a turbulence closure. The governing equations can be solved with extraordinary numerical precision.

But the turbulence closure remains an approximation. NASA’s turbulence-model resources emphasize the continuing need to benchmark turbulence and transition models against experimental and high-fidelity data. NASA’s current Turbulence Modeling Resource includes turbulence and transition models together with verification and validation cases and experimental/DNS/LES reference data.

The important issue is therefore, not, ‘Which model produces the most attractive number?’

It is:

Which model has demonstrated sufficient predictive capability for this physical regime and intended use?

This distinction becomes critical near phenomena such as:

flow separation,
transition,
shock-wave interaction,
strongly swirling flows,
multiphase flow,
combustion,
turbulent mixing,
highly nonlinear material behavior,
fracture,
fatigue,
contact,
large deformation.

A model may perform extremely well for one regime and poorly for another. Therefore, model validity is conditional on context. Validation is not a permanent certificate stating that a model is “correct.” It is evidence that the model has demonstrated acceptable behavior for specified conditions, variables, and intended uses.

ASME V&V 20, for example, focuses on quantifying the degree of accuracy inferred by comparison between simulation solutions and experimental data at specified validation points. That qualification matters enormously.

A model validated for one flow condition should not automatically be treated as validated for every geometry, Reynolds number, Mach number, pressure ratio, surface condition, or operating regime.

Why CFD Makes the Problem Especially Serious

CFD is one of the clearest examples of the precision paradox. A modern CFD workflow can contain:

Geometry → Mesh → Governing Equations → Physical Models → Boundary Conditions → Solver → Convergence → Post-processing

Every stage can introduce uncertainty. Imagine a simulation predicting aerodynamic drag C_D=0.024731. It is tempting to interpret the result as highly accurate because the output contains five significant digits. But consider what happens if:

the inlet velocity is uncertain,
the turbulence intensity is unknown,
the wall condition is idealized,
the transition location is uncertain,
the surface roughness is simplified,
the turbulence model changes,
the mesh changes,
the experimental reference itself has uncertainty.

The apparent precision of (0.024731) can then be profoundly misleading. NASA’s CFD verification and validation guidance separates verification from validation precisely for this reason. Verification addresses whether the computational implementation correctly solves the intended mathematical model; validation addresses agreement with physical reality through comparison with experimental evidence. NASA also identifies three interacting foundations of CFD credibility:

Theory + Experiment + Computation

Ignoring any one of these creates a credibility gap.

A Conceptual CFD Uncertainty Structure

CFD component	Question	Example uncertainty
Geometry	Is the computational geometry representative?	Surface roughness
Boundary conditions	Are real operating conditions known?	Turbulence intensity
Governing equations	Are the equations appropriate?	Physical approximation
Turbulence model	Does closure reproduce relevant physics?	Separation prediction
Mesh	Is the spatial discretization adequate?	Grid dependence
Time step	Is temporal resolution adequate?	Transient response
Solver	Is the numerical method implemented correctly?	Algorithmic error
Convergence	Has the numerical solution stabilized?	Iterative error
Experiment	Is the reference data trustworthy?	Measurement uncertainty
Validation domain	Does the evidence cover the intended use?	Extrapolation

The practical lesson is straightforward: A finer mesh cannot repair a wrong turbulence model. Nor can a more powerful computer automatically repair uncertain boundary conditions. Nor can an elegant visualization compensate for inadequate validation data. This is why experimental planning is not an afterthought to CFD. It is part of the model-development process.

NASA’s validation guidance recommends building validation evidence progressively, beginning with simpler physical phenomena before moving toward more complex systems.

Verification Is Not Validation

One of the most consequential mistakes in computational engineering is treating verification and validation as synonyms. They answer different questions.

Verification

Verification asks, did we solve the mathematical/computational problem correctly? Examples include:

code verification,
analytical solution comparison,
manufactured solutions,
mesh refinement studies,
time-step refinement,
iterative convergence,
conservation checks.

Validation

Validation asks, does the model represent the real physical system adequately for its intended use? Examples include:

comparison against experiments,
comparison against trusted benchmark data,
validation of forces,
validation of pressure distributions,
validation of temperature fields,
validation of structural response,
validation across relevant operating conditions.

NASA’s formal CFD guidance makes this distinction directly: verification examines the correctness of the computational implementation, whereas validation examines whether the simulation agrees with physical reality. The difference can be illustrated simply. Suppose the exact mathematical solution is Q=100 and the numerical solver produces Q=99.999999. The numerical method may be excellent.

But suppose the real experiment produces Q=87. The solver has successfully verified the numerical solution of its mathematical model. The model itself has not adequately represented reality. That is not a numerical failure. It is a modeling failure.

The Credibility Chain

A defensible simulation therefore follows approximately:

Physical question → Model → Implementation → Verification → Validation → Uncertainty → Decision

Skipping verification creates computational uncertainty. Skipping validation creates physical credibility uncertainty. Skipping uncertainty quantification creates decision uncertainty. A simulation without these distinctions may still produce useful engineering information, but the strength of the conclusion must be limited accordingly. ASME’s VVUQ standards explicitly treat verification, validation, and uncertainty quantification as interconnected components of computational-model credibility.

Sensitivity Analysis: Finding What Actually Matters

If an engineering model contains dozens or thousands of uncertain inputs, not every uncertainty deserves equal attention. This is where sensitivity analysis becomes essential.

Suppose: Y = f(x₁, x₂, x₃, …, xₙ). A local sensitivity measure can be expressed conceptually as: Sᵢ = ∂Y/∂xᵢ . A normalized sensitivity coefficient is often more useful: Sᵢ = (xᵢ/Y)(∂Y/∂xᵢ). This indicates how strongly the output responds to relative changes in an input. For uncertainty propagation, a first-order approximation for independent variables can be written as: u_Y² ≈ Σᵢ₌₁ⁿ (∂Y/∂xᵢ)² uₓᵢ² where uₓᵢ represents the uncertainty associated with input xᵢ.

The equation contains an important engineering lesson. An input does not need to have large uncertainty to dominate the output. A small uncertainty in a highly sensitive parameter may matter more than a large uncertainty in an insensitive parameter.

Example

Imagine a model with three uncertain inputs:

Input	Relative uncertainty	Output sensitivity	Potential importance
(x_1)	1%	Very high	High
(x_2)	10%	Very low	Low
(x_3)	5%	Moderate	Moderate

A common but inefficient engineering response would be to improve measurements of (x_2) simply because its uncertainty is largest. Sensitivity analysis may show that improving (x_1) provides far greater reduction in output uncertainty. This changes how experiments should be designed. Instead of asking, ‘What can we measure most accurately?’, the better question is:

Which measurement would most reduce uncertainty in the engineering decision?

This is the bridge between uncertainty quantification and experimental design. For CFD, sensitivity studies can involve:

turbulence-model selection,
inlet conditions,
wall roughness,
Reynolds number,
Mach number,
geometry,
mesh density,
time step,
material properties,
heat-transfer coefficients.

NASA documentation on uncertainty quantification similarly emphasizes propagation of uncertain model inputs and the role of sensitivity analysis in understanding their effect on simulation outputs.

The Engineering Value of Sensitivity Analysis

Sensitivity analysis prevents a common waste of computational and experimental resources, Reducing an uncertainty that does not matter. A highly precise measurement of an irrelevant variable is not necessarily a useful measurement. The best experiment is often not the one that produces the most data. It is the one that removes the uncertainty that matters most.

Experiments Must Be Designed Around Uncertainty

There is an uncomfortable truth in computational engineering: A poor experiment can produce data that are too weak to validate a sophisticated simulation. A measured value without adequate information about:

boundary conditions,
instrumentation,
calibration,
uncertainty,
geometry,
test conditions,
spatial resolution,
temporal resolution

may not provide strong validation evidence.

NASA has repeatedly emphasized that validation experiments require carefully characterized physical conditions. Its CFD validation literature notes that surface or integral measurements alone may be insufficient for complex simulations and identifies flow-field and boundary-condition measurements as important components of validation datasets.

This is an important reversal of conventional thinking. The purpose of an experiment is not simply to obtain a number. It is to obtain evidence capable of discriminating between competing explanations or models. Suppose two turbulence models predict: C_D=0.025 and C_D=0.027.

If the experimental uncertainty is ±0.004, the experiment may be incapable of distinguishing the models. The two predictions differ, but the measurement is not sufficiently informative to determine which model is better. Now suppose an improved experiment achieves ±0.0005.

The same experiment becomes much more useful for model discrimination. This produces a powerful design principle, experimental resolution should be related to the difference one needs to detect.

Validation Experiment Logic

A useful validation experiment should therefore answer:

What physical phenomenon is being tested?
Which model assumptions are being challenged?
Which output variables are sensitive to those assumptions?
What measurement uncertainty is acceptable?
Which boundary conditions must be measured?
Which parameters must be controlled?
What competing models should the experiment distinguish?
What operating range is relevant?
Can the experiment be repeated?
How will the experimental uncertainty be propagated into the validation comparison?

NIST provides formal guidance for evaluating and expressing measurement uncertainty, including statistical and model-based approaches. This is why uncertainty analysis should be performed before an experiment rather than merely attached to the results afterward.

How False Precision Enters Engineering Decisions

False precision rarely appears because engineers deliberately deceive themselves. It usually emerges from a chain of individually reasonable practices. A software package calculates more digits because it can. A spreadsheet preserves full floating-point precision. A CFD solver reports residuals to many orders of magnitude. A sensor records many decimal places. A visualization shows extremely smooth contours. A report copies the software output directly into a table. Eventually the presentation of the result begins to imply more certainty than the evidence supports.

Consider this sequence 127.384276 becomes 127.384 then 127.38 becomes 127.4. The first number may be the computer’s internal numerical result. The final number may be the scientifically honest engineering statement. The correct number of significant figures depends on the uncertainty and purpose of the result—not on how many digits the calculator happens to display. NIST guidance explicitly recommends expressing measurement results with uncertainty and using significant figures consistent with the uncertainty of the result.

A simple example

Suppose: v=127.384 m/s but the estimated uncertainty is u_v = ±2.0 m/s. Reporting 127.384 m/s creates an impression of millimeter-per-second-level knowledge that the uncertainty does not support.

A more honest representation is approximately v = 127.4 ± 2.0 m/s or, depending on the uncertainty convention and reporting requirement v ≈ 127 m/s. The second form contains fewer digits. But it contains more scientific information because it does not imply knowledge that does not exist.

This is the paradox:

Removing digits can make an engineering result more truthful.

Precision Inflation in Computational Workflows

Stage	What can happen
Solver	Produces many numerical digits
Spreadsheet	Preserves all digits
Graph	Displays highly precise curves
Report	Copies numerical output
Decision-maker	Interprets digits as confidence
Design	Margin is based on apparent certainty

The danger becomes particularly severe when a prediction sits near a design limit. Suppose a calculated response is R=99.8 and the allowable value is R_allow = 100. The difference appears to be 0.2. But if the prediction uncertainty is ±5 then the engineering interpretation is completely different.

The model does not establish that the system safely lies below the limit. It establishes that the prediction is uncertain relative to the limit. This is why engineering decisions should compare uncertainty bands with decision thresholds, not merely point estimates.

Point Prediction vs Uncertainty-Aware Decision

POINT ESTIMATE

Prediction
     |
     v
----●---------------- Limit
   99.8              100


UNCERTAINTY-AWARE VIEW

       <------ uncertainty ------>
     |-----------------------------|
             ●
            99.8
                         | Limit
                         100

The second representation is much closer to the information actually needed by a designer.

Engineering Truth Requires Evidence, Not Decimal Places

The real objective of engineering analysis is not numerical precision. It is credible prediction for a defined purpose. That requires a hierarchy of evidence. A useful framework is:

Measurement → Model → Verification → Validation → Uncertainty Quantification → Decision

Each stage answers a different question.

Engineering Credibility Checklist

Question	Why it matters
What physical quantity is being predicted?	Defines the measurand/output
What assumptions define the model?	Reveals abstraction
What inputs are uncertain?	Identifies input uncertainty
What parameters are uncertain?	Identifies parameter uncertainty
What model forms are possible?	Exposes model-form uncertainty
Is the numerical solution verified?	Establishes computational correctness
Has the model been validated?	Establishes physical credibility
Are experiments sufficiently accurate?	Determines strength of validation evidence
Which variables dominate sensitivity?	Directs resources efficiently
How is uncertainty propagated?	Connects inputs to outputs
Does the uncertainty affect the decision?	Establishes practical significance
Is the model being extrapolated?	Identifies unsupported use

The engineering community has increasingly formalized this way of thinking. ASME’s VVUQ standards provide a common framework for verification, validation, and uncertainty quantification, while V&V 20 specifically addresses CFD and heat-transfer applications.

NASA’s CFD guidance similarly emphasizes that credibility requires assessment of both errors and uncertainties and that validation involves comparison with physical experimental evidence.

The implication for modern engineering is profound. Computational power is not eliminating uncertainty. It is changing the location of the engineering problem. In earlier engineering practice, computational limitations often dominated. Engineers worried about whether they could solve the equations. Today, computers can solve enormous numerical systems with extraordinary speed.

The limiting question increasingly becomes:

Are the equations, parameters, boundary conditions, experiments, and assumptions sufficiently representative of reality?

That is a much harder question. And it cannot be answered by adding another decimal place.

The Precision Paradox

The central argument can be summarized in one relationship:

Numerical precision ↛ Physical accuracy

More formally, an engineering prediction can be viewed as:

f(X, θ, M) + ε_numerical + ε_model

where:

(X) represents uncertain inputs,
(θ) represents model parameters,
(M) represents model form,
(ε_numerical) represents numerical solution error,
(ε_model) represents the discrepancy associated with physical modeling.

Making the numerical error extremely small does not necessarily make the model-form error small. That is the heart of the problem. A simulation may therefore move through the following stages:

Coarse model → Refined mesh → Better convergence → More decimal places

while the actual physical uncertainty remains almost unchanged. The result looks more certain. The knowledge has not necessarily become more certain.

The New Engineering Discipline: Knowing What You Do Not Know

The next generation of engineering analysis should therefore move away from a culture in which computational sophistication is treated as a substitute for physical evidence. The better standard is Calculate precisely + validate honestly + quantify uncertainty. This does not mean abandoning high-fidelity simulation.

Quite the opposite. High-fidelity computation is enormously valuable. But high fidelity should be used where it actually reduces uncertainty or improves predictive capability. A billion-cell CFD model is not automatically more useful than a carefully validated lower-order model. A highly sampled sensor is not automatically more informative than a properly calibrated instrument.

A complicated finite-element model is not automatically more trustworthy than a simpler model whose assumptions have been thoroughly validated. And a machine-learning surrogate trained on enormous quantities of data does not escape the fundamental requirement that its training domain, inputs, outputs, uncertainty, and intended application must be understood.

The engineering objective should therefore shift from, How many digits can we calculate? to, How much of those digits can we defend?

That is the difference between computational output and engineering knowledge. It is also why uncertainty should not be treated as an embarrassing footnote at the end of a report. Uncertainty is part of the result.

In many engineering problems, the most useful answer is not Y=127.384 but Y = 127.4 ± 2.0 together with an explanation of where the uncertainty comes from, which assumptions dominate it, how the model was verified, how it was validated, and whether the uncertainty is acceptable for the decision being made.

That is not weaker engineering. It is stronger engineering. The mature engineer is not the person who can produce the most decimal places.

It is the person who can distinguish between a number that is computationally precise, a number that is experimentally repeatable, a number that is physically accurate, and a number that is credible enough to support a decision.

The most dangerous simulation is therefore not necessarily the one with a large numerical error. It may be the one with an extremely small numerical error, an attractive visualization, excellent convergence, and six convincing decimal places—while quietly solving the wrong physical problem.

Engineering Takeaway

The governing principle is simple:

Precision describes how finely we express a result.
Accuracy concerns how well that result represents reality.
Uncertainty describes what we still do not know.
Verification establishes computational correctness; validation establishes physical credibility.

The future of engineering will not be defined merely by models that calculate faster or simulations that resolve smaller scales. It will be defined by models that can demonstrate why their predictions deserve to be believed. That is the real challenge behind modern CFD, turbulence modeling, digital twins, autonomous systems, structural simulation, experimental design, and computational physics. The question is no longer simply:

Can the computer calculate it?

The more important question is:

What evidence tells us that the calculated answer is true enough to act upon?