Physics as modeling

Physics is not a catalogue of equations to paste into a program. It is the practice of making a limited model, comparing its output with reality or a trusted limit, and revising the model when the mismatch matters. Code makes this loop visible because every assumption becomes an input, branch, type, constant, or missing test.

Think like a programmer

Start each physics task with a model contract. Name the question, output, inputs and units, retained state, rule, validation target, uncertainty, and stop condition. If one of those cannot be written down, the program is not yet ready to simulate.

Model checklist

Inputs: A concrete question, measured or chosen parameters with units, and a defined operating range.
State: The smallest information needed to reproduce the next calculation or update.
Rule: An equation, update step, or statistical relationship with stated assumptions.
Output: A measurable or inspectable prediction.
Check: A known limit, conservation law, analytic solution, or independent measurement.

The loop is the product

type ModelResult = {
  output: number;
  assumptions: string[];
  validation: { expected: number; tolerance: number };
};

function accept(result: ModelResult) {
  return Math.abs(result.output - result.validation.expected) <= result.validation.tolerance;
}

The value of this shape is not its syntax. It prevents a chart from separating a number from the conditions under which that number has meaning. A model may produce a precise floating-point result while being inaccurate because it omitted friction, used a wrong boundary condition, or applied a low-speed formula near the speed of light.

Build a capstone in stages

State a question narrow enough to test: “How far does this ideal projectile travel?” not “simulate sport.”
Choose the smallest state and inputs that answer it.
Implement a pure calculation before adding a renderer.
Write a test for an initial condition, limit, invariant, or known answer.
Display output with units and assumptions.
Change one input at a time, compare prediction and result, and record the mismatch.
Decide whether the mismatch is a code bug, numerical error, bad data, or a bad physical approximation.

That last distinction is central. A unit test can prove code follows an equation; it cannot prove the equation applies to the real system. Conversely, a bad implementation can hide behind a scientifically valid equation until a limiting-case test exposes it.

Try this experiment

Prediction: A model that passes a zero-input limit may still fail a real-world prediction if an omitted interaction is important.

Choose a familiar model from the course. Write one zero or symmetry test it should pass, then name one real condition that the test cannot validate. Explain whether changing that condition requires a new input, a new rule, or a new model.

Where this model breaks

Every model in this course is a teaching model. It may omit uncertainty, feedback, three-dimensional geometry, rare events, interactions, or data-quality limits. Passing tests are evidence for the stated contract, not permission to use a simplified result for high-stakes decisions.

Summary

Think like a computational physicist: make assumptions executable, separate numerical correctness from physical validity, and keep validation attached to every output.

Glossary

Model contract: explicit statement of inputs, state, rule, outputs, assumptions, and checks.
Validation: comparison with a result outside the implementation itself.
Approximation: deliberate simplification whose valid range must be stated.

Self-check

What belongs in a model contract before code is written?
What can a unit test prove that a real-world comparison cannot?
What can a real-world comparison reveal that a unit test cannot?

Sources

G. E. P. Box, “Science and Statistics,” Journal of the American Statistical Association (1976), model usefulness and limits.
OpenStax, University Physics, introductory modeling and problem-solving chapters.

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 Physics as Modeling, write down the quantities you can control, the values your program must retain, and the result a reader could inspect. In Thinking Like a Computational Physicist, 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 Physics as Modeling 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 Physics as Modeling into a test

Close the course by treating every physical explanation as a testable, scoped program model.

Name the inputs and units that the thinking like a computational physicist 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: