A Byte of PhysicsLogo

Numerical field evolution

Numerical field evolution advances coupled arrays under a stability condition. A field solver is an explicit state machine: a saved initial grid and settings deterministically produce a sequence of grids. If a result is questioned, you should be able to replay the same update order, boundaries, time steps, and diagnostics—not infer what happened from a video.

Think like a programmer

Keep the numerical core as a pure step(previousState, configuration) function. It returns a new state plus diagnostics, never mutates the input grid, and does not schedule animation. Store the initial arrays, coefficient fields, source schedule, mesh spacing, time step, boundary policy, integrator version, and random seed if any. Rendering samples the result after a successful step.

Model checklist

Inputs
Initial field arrays, coefficients, sources, mesh spacing h, time step Δt, integrator, boundaries, and duration.
State
Current and any prior-time field arrays, simulation time, diagnostics, and boundary-transfer accumulators.
Rule
Apply the same local stencil order to the prior state, then accept only finite stable next values.
Output
Field sequence, residual history, energy/momentum ledger, and convergence comparison.
Check
Replay produces the same snapshots; stable settings remain finite; refinements approach the same physical result over a fixed duration.

For a characteristic propagation speed v, an explicit wave-like update usually needs a Courant–Friedrichs–Lewy (CFL) restriction of the form

\[C=\frac{v\Delta t}{h}\leq C_{\max}\]

Cmax depends on dimension, stencil, and integrator. Do not copy a bound from another scheme. For the existing explicit two-dimensional unit-grid diffusion example, the corresponding condition is

\[D\Delta t\leq\frac14\]

The solver should reject a configuration that violates its documented condition before it produces a visually impressive explosion. A stability check does not guarantee accuracy: it only prevents one class of growing numerical error.

type EvolutionRun = {
  initialState: ScalarGrid;
  configuration: { diffusivity: number; timeStep: number; boundary: "fixed-zero" | "wrap" };
  snapshots: readonly ScalarGrid[];
  diagnostics: { time: number; total: number; residual: number }[];
};

const next = diffuseGrid(previous, configuration.diffusivity, configuration.timeStep, configuration.boundary);

Use snapshot fixtures at selected times, not only an image test. For a symmetric central peak, symmetry and positivity under a stable diffusion step are useful checks. For a periodic boundary, total scalar amount should remain constant within roundoff if the update conserves it; for a fixed-zero boundary, a changed total can represent flux through the boundary and needs a ledger term.

Convergence requires comparing the same physical experiment, not simply using “more cells.” Keep duration, domain size, sources, and measurement location fixed while reducing h and Δt consistently. Record an observable such as peak time, phase at a probe, or integrated energy. If coarse and fine results differ, distinguish a stability failure, boundary artifact, insufficient resolution, and a wrong physical assumption before adjusting the visual scale.

Try this experiment

Prediction: Two runs that look similarly smooth can disagree quantitatively if one violates the needed relationship between spatial and time resolution.

Design a replay record for a central pulse. List the configuration values needed to reproduce it, choose one probe observable, then describe how you would compare coarse, medium, and fine runs at the same physical time.

Where this model breaks

This workflow is general, but no one stability rule or diagnostic fits every PDE. Nonlinear shocks, turbulence, multiscale material response, adaptive meshes, implicit solvers, stochastic sources, and complex geometry require additional algorithms and validation. Deterministic replay also cannot validate missing physics or inaccurate input data.

Summary

Field evolution is replayable array-state programming. Make the update pure, reject unstable configurations, preserve snapshots and diagnostics, account for boundaries, and use a fixed-physical-problem refinement study before claiming a solver result is trustworthy.

Glossary

Self-check

  1. Why should a step function not mutate its input grid?
  2. What does a CFL-style condition prevent, and what does it not guarantee?
  3. Which values must remain fixed across a meaningful refinement study?

Sources

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 Numerical Field Evolution, write down the quantities you can control, the values your program must retain, and the result a reader could inspect. In Maxwell’s Equations and EM Waves, 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 Numerical Field Evolution 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

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

Model review: turn Numerical Field Evolution into a test

Advance coupled field arrays with explicit stability, replay metadata, and refinement evidence.

  1. Name the inputs and units that the maxwell’s equations and em waves model needs.
  2. Separate the state you must keep from values you can calculate when needed.
  3. Write one rule that maps the current state and inputs to an observable result.
  4. Choose a limiting case, unit check, invariant, or known result before trusting an output.
  5. State one assumption you would change before using this simplified model for a real decision.

Share to: