Gravitational fields as vector fields

Gravity assigns an acceleration vector to every point in space around a mass. The direction points inward; its magnitude falls with distance squared.

Think like a programmer

Make gravity a pure function from position to acceleration. That lets the same field drive a particle integrator, vector-field renderer, and unit tests without duplicating force logic.

Model checklist

Inputs: Position relative to the attracting mass and gravitational parameter.
State: Acceleration vector at each position.
Rule: Scale the inward radial direction by inverse-square strength.
Output: Field sample or acceleration update.
Check: Equal radius gives equal strength, and opposite positions point toward the origin.

\[\mathbf a(\mathbf r)=-\mu\frac{\mathbf r}{\lVert\mathbf r\rVert^3}\]

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

Implement the field once

The input is a displacement from source to probe, not an arbitrary screen coordinate. For a point source at the origin, compute (r^2=x^2+y^2+z^2), reject or explicitly soften the singular case, and return the vector:

\[\mathbf a(\mathbf r)=-\mu\frac{\mathbf r}{(r^2+\varepsilon^2)^{3/2}}.\]

With (\varepsilon=0), this is the ideal inverse-square point-mass field away from the origin. A positive softening length is a numerical model change: it bounds close encounters and must be recorded with the result. Do not hide that policy only in a renderer’s arrow-length clamp.

Make the field function pure and use it in both a particle update and the vector sampler. The sampler has separate decisions: plane, extent, grid spacing, source location, arrow normalization, colour scale, and the mask around the singularity. A Three.js field can use the site’s main blue palette, but each probe should also expose direction and magnitude in text so the explanation survives disabled WebGL.

Check symmetry before integrating motion

Use analytic fixtures: at ((r,0,0)) acceleration has only a negative x component; opposite points have opposite vectors; equal radii have equal magnitudes; doubling radius quarters the ideal magnitude; and superposing two sources equals the sum of their separate accelerations. Test the field first, then test an orbit with a known initial condition while logging energy and angular momentum at fixed physical times.

Keep units explicit: (\mu=GM) has units of length cubed per time squared, so the output must be acceleration. The field assumes a fixed point source and instantaneous Newtonian interaction. An extended, moving, relativistic, or many-source system needs a different source model and a stated integration/refinement study.

Try this experiment

Prediction: Doubling radius reduces field magnitude to one quarter.

Compare two probe distances. Which part of the implementation prevents a division-by-zero crash at the center?

Where this model breaks

A point-mass field is singular at its origin and ignores relativistic effects, extended bodies, and other gravitating objects.

Summary

Represent gravity as one reusable, singularity-aware inward vector function. Separate solver physics from blue visual sampling, verify symmetry and units analytically, then use fixed-time invariants and refinement for motion.

Glossary

Gravitational parameter: product of gravitational constant and mass.
Central field: field pointing toward or away from one center.
Inverse-square law: magnitude proportional to one over distance squared.

Self-check

Which direction does the gravity vector point?
How does magnitude change with radius?
Why special-case the origin?

Sources

OpenStax, University Physics Volume 1, gravitation.

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 Gravitational Fields as Vector Fields, write down the quantities you can control, the values your program must retain, and the result a reader could inspect. In Gravitation, 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 Gravitational Fields as Vector Fields 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 Gravitational Fields as Vector Fields into a test

Implement gravity as a reusable inverse-square acceleration vector field.

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