A Byte of PhysicsLogo

Boundary conditions

Boundaries determine how a field interacts with a domain edge: it may be fixed, free, absorbing, periodic, or connected to another model. They are physical assumptions and numerical rules at the same time. An unexpected reflection often comes from an unrecorded edge policy, not a new discovery in the interior equations.

Think like a programmer

Make boundary handling a named, testable stage of every update. Keep the interior stencil separate from the rule that supplies out-of-range neighbours or overwrites constrained edge cells. Store boundary type and parameters with output snapshots; otherwise the same initial condition can produce visually different results that cannot be reproduced or explained.

Model checklist

Inputs
Domain dimensions and spacing, interior update, boundary type, edge values or material parameters, time step, and initial state.
State
Interior field values, edge cells or ghost values, boundary configuration, and optional absorbed/reflected energy ledger.
Rule
Advance the interior from the previous snapshot, then supply/enforce boundary data according to the declared condition.
Output
Field snapshot, reflection/transmission/absorption behavior, boundary residual, and configuration provenance.
Check
Fixed endpoint cells retain their imposed value; wrap reads opposite-edge cells exactly; a known travelling-wave fixture follows the expected boundary phase; changing only the boundary policy changes no interior equation code.

For a fixed string endpoint at x = 0, displacement is constrained by

\[y(0,t)=0\]

An incident displacement pulse on an ideal fixed string reflects with inversion so the sum remains zero at the endpoint. A free string end instead has approximately zero spatial slope, while a periodic computational domain identifies opposite edges. These are different rules and should never share an undocumented default. In a two-dimensional grid, periodic wrapping means an out-of-range index is mapped with modular arithmetic; a fixed-zero policy instead supplies zero outside the finite domain.

Wave data sampler

Adjust amplitude and wavelength. The plotted line is a view of sampled displacement data; its speed is frequency divided by wave number.

Amplitude 1.0; wavelength 3.0 m; model speed 1.91 m/s.

The wave sampler is an analytic view, not a boundary solver. A solver must make edge state visible. For a fixed endpoint, assert the first and last displacement cells immediately after every update. For a periodic grid, assert that a neighbour read left of index zero returns the last column, and test it with distinct values rather than a symmetric pattern that could conceal an indexing error.

Try this experiment

Prediction: A fixed string end reflects displacement with inversion; periodic wrapping returns the opposite edge's state without changing the interior stencil.

Write tests for the first and last cells of a fixed-end string after one update. Put distinct values in the leftmost and rightmost grid cells, then state the expected read at index −1 for fixed-zero and wrap policies. Explain why an absorbing boundary needs a measured reflection diagnostic rather than a label.

Where this model breaks

An absorbing edge is approximate and can reflect some frequencies, angles, or packet widths. Interface boundaries require impedance or material data, while finite-difference ghost-cell formulas must match the PDE and stencil order. “Fixed” and “free” have different meanings for different fields; the string examples here do not automatically transfer to pressure, electromagnetic, or quantum boundary conditions.

Summary

Boundaries are model inputs and part of numerical reproducibility. Implement them explicitly after the interior update, test them with asymmetric fixtures, and separate a known constraint from an approximate absorber or physical interface.

Glossary

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 Boundary Conditions, write down the quantities you can control, the values your program must retain, and the result a reader could inspect. In Waves I — Mechanical 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 Boundary Conditions 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 Boundary Conditions into a test

Treat edge behavior as explicit, testable model input for a numerical wave solver.

  1. Name the inputs and units that the waves i — mechanical 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: