01 / The question
What does one extra body cost?
A many-body simulation is both a physics model and a software-design problem. Every interacting pair contributes work, while every time step can accumulate numerical error.
02 / The intuition
A mechanism worth testing.
Connect the force calculation to the program’s measured cost. A convincing animation must be considered alongside integration choices and memory behaviour.
03 / The work
Inside the method.
Explore each part of the approach.
01Represent bodies
C structures stored mass, position, velocity and force; the implementation used explicit memory management.
02Advance the system
Pairwise gravitational interactions and an Euler time integrator drove the evolution. PGM frames and GIF output made trajectories inspectable.
03Measure the implementation
Module tests, timing experiments and memory-analysis tools were used to examine correctness and scaling.
Pairwise force evaluation: O(N²) per time step
This describes the direct nested-loop algorithm, not a measured runtime guarantee.
04 / The observations
What emerged.
The notes describe a working simulator and runtime measurements consistent with the pairwise calculation. Exact benchmark and memory claims are deferred until the source and test outputs are attached.
This account is based on recorded project notes. Original reports, figures and datasets are not embedded here.
05 / The limits
Where the evidence stops.
Euler integration, periodic display boundaries and the absence of collisions limit physical interpretation. Animation alone does not validate long-term conservation properties.
The academic foundations