What can and cannot be simulated

A simulation can compute the consequences of its rules. It cannot discover data you did not supply, identify an omitted mechanism from a pretty picture, or make an approximation exact by drawing it smoothly. Its output is a conditional prediction whose credibility depends on model scope, input evidence, numerical verification, and validation against an independent physical reference.

Think like a programmer

A simulation is an executable specification with a budget. Store governing rules, state variables, parameters and units, initial/boundary conditions, random-state policy, numerical method, space/time resolution, stopping rule, hardware/resource limits, diagnostics, and version. More resolution is like more loop iterations: it may reduce one numerical error, but it cannot fix a missing requirement, biased initial data, or a wrong governing law.

Model checklist

Inputs: Governing rules and approximations, parameter/initial/boundary data with provenance, model state, numerical method, resolution schedule, resource budget, uncertainty policy, and independent reference data/solution.
State: State trajectory, numerical residuals, refined runs, parameter/input samples, validation comparison, cost/runtime/memory metrics, and scope warnings.
Rule: Apply the stated approximation under its boundary/initial policy; perform controlled resolution and input-sensitivity studies; compare with analytic manufactured cases or independent measurements.
Output: Conditional prediction, numerical-convergence evidence, validation residual, sensitivity/uncertainty context, resource cost, and explicit exclusions.
Check: Known analytic/manufactured fixture is recovered under refinement; changing only resolution has a measured convergence effect; changing omitted physics cannot be claimed fixed by resolution; input uncertainty changes output within reported sensitivity; validation uses data not already tuned into the same run.

\[e_h=\lVert u_h-u_{ref}\rVert,\qquad \text{verification asks whether the equations are solved correctly; validation asks whether the equations represent the intended system}\]

Resolution has a cost

Number of model slices: 4

A toy approximation is 0.7500. More slices reduce this toy error, but each slice needs more computation.

Verification and validation answer different questions. Verification checks implementation and numerical method against a known equation or manufactured solution. Validation compares a scoped model with independent observations. A simulation can pass verification while representing the wrong material, boundary condition, or force law; it can match one measured curve after tuning while failing a new condition. Record which evidence supports each claim.

Resolution needs a controlled experiment. Hold the physical domain, parameter values, output times, and comparison metric fixed while changing only step or grid spacing. Report error and computational cost together. A smaller step may reveal a convergence plateau caused by roundoff, a boundary error, or missing model physics; blindly choosing the smallest affordable value is not a justification.

Try this experiment

Prediction: Increasing slices improves the toy approximation but costs more work, while it cannot supply an omitted real-world mechanism.

Move the slider from 4 to 80. Identify the numerical error it reduces and the cost it adds. Hold one physical input fixed, make a refinement table, and compare with a known reference. Then name one omitted mechanism, one uncertain input, and one independent measurement needed before treating the output as a prediction about a real system.

Where this model breaks

Resolution cannot substitute for air resistance, uncertain initial data, unknown material properties, a wrong governing law, or an unmodeled system boundary. A simulation must state which omissions matter to the question. Finite compute, floating-point precision, random sampling, surrogate approximations, and visual encoding also limit what a run can establish.

Summary

Simulate what your model states. Label approximations, inputs, and exclusions; verify numerical convergence separately from validating physical applicability; report uncertainty and cost with any conditional prediction.

Glossary

Resolution: how finely a program divides time or space.
Convergence: an approximation approaching a stable answer as resolution increases.
Initial data: values needed before a model can run.
Verification: evidence that an implementation solves its stated equations as intended.
Validation: evidence that a scoped model represents an intended physical system.

Self-check

What can a smaller step improve?
What can it not repair?
What is the difference between verification and validation?
Which reference would you use to test a model?

Sources

N. J. Higham, Accuracy and Stability of Numerical Algorithms.
W. L. Oberkampf and C. J. Roy, Verification and Validation in Scientific Computing.

Model contract

Treat the lesson as a small function before treating it as a fact to memorize. Give every value a unit, keep only the state needed for the next step, and make the output easy to inspect.

\[\text{observable output} = f(\text{inputs},\,\text{state})\]

Inputs: Quantities you set or measure, with units and useful bounds.
State: Values the program must retain to reproduce the next result.
Rule: The relationship or update that turns inputs and state into a result.
Check: A known limit, unit check, invariant, or measured result that can expose a bad model.

Implement the idea as a model

For What Can and Cannot Be Simulated, write down the quantities you can control, the values your program must retain, and the result a reader could inspect. In Physics as Computation, the useful program is not the drawing: it is the smallest explicit model that makes a prediction you can test.

Guided experiment

Prediction: changing one declared input while holding the others fixed should change only the outputs that the model connects to that input. Choose one input, predict the direction of change, then check a limiting case such as zero, a symmetric arrangement, or a familiar low-speed or small-change approximation.

Where this model breaks

This lesson is a teaching model, not a complete simulator. Before using it outside the stated question, check which interactions, scales, uncertainties, boundary conditions, and measurement limits it leaves out.

Summary

Treat What Can and Cannot Be Simulated as a contract: named inputs and units enter a rule, the rule produces an observable result, and a known limit or invariant checks whether the implementation deserves trust.

Glossary

Input: a measured value or chosen parameter supplied to a model.
State: the smallest set of values needed to continue or reproduce a model.
Validation: comparing an output with a known result, limit, invariant, or measurement.

Self-check

Which values are inputs, and which values must remain state?
What observable result would tell you the model is behaving as expected?
Which assumption would you test first before applying the model to a real system?

Model review: turn What Can and Cannot Be Simulated into a test

Learn to separate a model's exact rules, useful approximations, missing inputs, and computational cost.

Name the inputs and units that the physics as computation model needs.
Separate the state you must keep from values you can calculate when needed.
Write one rule that maps the current state and inputs to an observable result.
Choose a limiting case, unit check, invariant, or known result before trusting an output.
State one assumption you would change before using this simplified model for a real decision.

Share to: