Electric field visualization

Field visualizations sample a vector function at selected locations. Arrow density, length scaling, color, camera direction, and singularity handling are display encodings. They can make a model easier to inspect, but they must not change the sampled physics or quietly substitute visual length for a numerical magnitude.

Think like a programmer

Build a one-way pipeline: pure field function → immutable samples with units → display mapping → renderer. Keep probe coordinates, sampled components, magnitude, scale/clamp rule, grid spacing, source state, and singularity policy in accessible text. The Three.js scene consumes samples; it never owns the field equation or mutates its data. A no-WebGL fallback should report the same selected probe result and the same model limits.

Model checklist

Inputs: Field function, source state, sample-grid origin and spacing, probe position, display scale/clamp, color mapping, camera/view convention, singularity mask, and units.
State: Immutable vector samples, exact probe vector/magnitude, display-arrow geometry, visible legend, and fallback text.
Rule: Evaluate the field at each valid physical sample, retain the numerical vector, then map direction and a separately documented magnitude scale to arrows.
Output: Arrow/scalar display, exact textual probe value, legend, omitted-sample list, and reproducible display configuration.
Check: Changing arrow scale, color, density, or camera leaves a fixed probe’s numerical vector unchanged; direction agrees with components; clamped arrows are labelled as clamped; source singularities are omitted or marked, never fabricated as zero; fallback text reports the selected probe and units.

The object to visualize is a function, such as a point-charge field:

\[\mathbf E(\mathbf r)=kq\frac{\mathbf r-\mathbf r_s}{\lVert\mathbf r-\mathbf r_s\rVert^3}\]

At every grid coordinate, retain the actual vector and magnitude. A renderer may cap arrow length with a rule like displayLength = min(scale × |E|, cap), but a cap turns magnitude into a lower-bound visual statement: two arrows of equal maximum length may represent very different fields. The legend must say so, and the selected-probe text must report the uncapped value in units.

Sampling density answers a display question, not a physics question. A denser grid exposes local turning but can hide arrows through overlap; a sparse grid can miss structure between samples. Keep a single probe fixed while changing density. Its numerical vector should not move merely because rendering points were regenerated. If it changes, the code has coupled analysis to display resolution.

Field lines are a different derived construction from arrow samples. They need a seed policy and numerical streamline integration; arrow direction alone neither proves nor draws them. Likewise, a 2D plot may show one slice through a 3D field. State the plane, viewing orientation, and any components omitted from display.

Loading the interactive visual. The lesson text and model remain available while it starts.

Try this experiment

Prediction: Clamping arrow length improves readability but hides absolute magnitude differences, while changing density leaves a fixed probe’s field unchanged.

Choose a probe away from the source and record its x/y components and magnitude. Change grid density and visual scale independently. Verify the probe text is unchanged, then activate or imagine an arrow cap and explain why equal displayed lengths no longer imply equal field magnitude. State the plane, units, and singularity behavior needed to reproduce one arrow.

Where this model breaks

Arrow plots can mislead at sparse resolution or near singularities. They are diagnostics, not direct measurements of field lines. They also omit uncertainty, 3D components, dynamic timing, material response, and values between samples unless the model supplies them. Perspective, color vision differences, motion, and WebGL availability are presentation conditions, not evidence about a field.

Summary

Make field sampling and visual encoding separate. Expose exact, unit-bearing numeric state behind the display, preserve its configuration, and ensure the textual fallback supports the same conceptual conclusion as the Three.js view.

Glossary

Sample grid: selected field-evaluation locations.
Clamp: display limit on a value.
Singularity: point where an ideal model diverges.
Display mapping: non-physical rule that turns a data vector into an arrow, color, or glyph.
Fallback: accessible non-canvas representation of the selected model state.
Self-check
1. What must rendering not change?
2. Why clamp arrows?
3. Which uncapped values must be disclosed beside a clamp?
4. Why does an arrow plot not automatically provide field lines?

Sources

OpenStax, University Physics Volume 2, Electric Fields.
E. R. Tufte, The Visual Display of Quantitative Information.

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 Electric Field Visualization, write down the quantities you can control, the values your program must retain, and the result a reader could inspect. In Electrostatics, 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 Electric Field Visualization 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 Electric Field Visualization into a test

Render sampled field vectors without conflating visual scaling choices with physical state.

Name the inputs and units that the electrostatics 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: