Here is a list of all documented files with brief descriptions:

docs
adr
orrery
backend
cpu_features.hpp	Which vector extensions this processor has, asked at run time
cpu_topology.hpp	Which logical processors this machine has, and which of them are fast
executor.hpp	How a kernel asks for a loop to be run in parallel
partition.hpp	How a range of indices is divided between workers
serial_executor.hpp	The executor that does not thread at all
static_executor.hpp	Equal fixed shares, one per worker
sycl_device.hpp	Finding the GPU, and reporting what was found
sycl_usm.hpp	Unified shared memory, owned properly, and the evidence that it is unified
thread_pool.hpp	A fixed set of worker threads that run one body function on demand
work_stealing_executor.hpp	Dynamic partitioning by range stealing
worker_statistics.hpp	What each worker thread did, and how long it spent doing nothing
core
aligned_allocator.hpp	An allocator that starts every allocation on a cache line
build_info.hpp	What the running binary was built from and built for
diagnostics.hpp	The conserved quantities, which are how this project knows it is right
function_ref.hpp	A non-owning reference to something callable
particle_data.hpp	The particle store: one contiguous array per component
random.hpp	The project's source of randomness, and the only one
softening.hpp	Plummer softening, defined once for everything that needs it
types.hpp	The scalar and index types that every layer of the project agrees on
units.hpp	The unit system every quantity in the project is expressed in
vec3.hpp	A three-component vector for interfaces, not for storage
vec3_array.hpp	Storage for a vector quantity that is not part of the particle state
vec3_span.hpp	Three parallel component arrays, viewed as one sequence of 3-vectors
initial_conditions
centre_of_mass_frame.hpp	Moving a sampled configuration into its own centre-of-mass frame
disc_galaxy.hpp	A rotating disc galaxy: the configuration the project's demonstration is built from
galaxy_collision.hpp	Two disc galaxies on a collision course: the project's headline scenario
kepler.hpp	The two-body problem, which is the only gravitational system anyone can solve exactly
plummer.hpp	The Plummer sphere: a self-gravitating system that starts in equilibrium
uniform_sphere.hpp	A uniform sphere of cold particles: the configuration for scaling work
integrators
acceleration_field.hpp	What an integrator is allowed to know about gravity
integrator.hpp	The interface every time integrator presents, and the contract about accelerations that makes the cheap ones cheap
runge_kutta4.hpp	Classical fourth-order Runge-Kutta, included as the counterexample
velocity_verlet.hpp	Velocity Verlet, the method this project integrates with by default
yoshida4.hpp	Yoshida's fourth-order symplectic integrator, built from three velocity Verlet steps
sim
assembly.hpp	Turning a configuration into the objects that run it
binary_stream.hpp	Fixed-width little-endian reading and writing, which is what makes the two binary formats in this layer specifications rather than memory dumps
checkpoint.hpp	The complete state of a run, written so that it can be picked up exactly where it was put down
config_file.hpp	The declarative configuration file: a small language, defined here rather than adopted from elsewhere
configuration.hpp	Everything a run is, as data
diagnostics_log.hpp	The conserved quantities of a run, as they change, in a format anything can read
run_output.hpp	Where a run's results go, behind one interface so that the simulation does not know
simulation.hpp	The object that owns a run
trajectory.hpp	The trajectory file: what the simulation looked like, frame by frame
solvers
barnes_hut_solver.hpp	The hierarchical solver: the same physics as direct summation, with most of the interactions replaced by an approximation whose error is bounded and measured
direct_kernel.hpp	The innermost loop of the direct solver, in more than one instruction set
direct_solver.hpp	Direct summation: every particle against every other, and the standard the rest of the project is measured against
force_solver.hpp	What every gravitational force solver in this project provides
interaction_count.hpp	The unit in which the cost of a force evaluation is reported
morton.hpp	The order the tree solver reads particles in, and the reason it is not the order they arrived in
octree.hpp	The tree the Barnes-Hut solver walks, and the moments it carries
reference_kernel.hpp	The acceleration of one particle, computed as accurately as this project knows how, so that a fast kernel's error can be measured rather than asserted
sycl_direct_solver.hpp	Direct summation on the integrated GPU
sycl_tree_solver.hpp	The Barnes-Hut traversal on the integrated GPU, which is the hardest thing this project asks of the device
tree_walk.hpp	The traversal that turns a tree into an acceleration, which is where a Barnes-Hut solver spends nearly all of its time
viz
camera.hpp	The camera, as three angles and a distance
gl_api.hpp	The OpenGL entry points this renderer uses, and only those
image.hpp	An 8-bit colour image, and the one format this project writes it in
matrix4.hpp	The 4-by-4 transforms a camera needs, and nothing else
point_renderer.hpp	Drawing a few hundred thousand point masses as a field of stars
tone_map.hpp	Turning accumulated light into pixels
viewer_window.hpp	A window with an OpenGL context, and the controls that drive the camera