simulation.hpp File Reference

The object that owns a run. More...

#include <memory>
#include "orrery/backend/executor.hpp"
#include "orrery/core/diagnostics.hpp"
#include "orrery/core/particle_data.hpp"
#include "orrery/core/types.hpp"
#include "orrery/integrators/integrator.hpp"
#include "orrery/solvers/force_solver.hpp"

Go to the source code of this file.

Classes
class	orrery::sim::Simulation
	A gravitational simulation in progress. More...

Detailed Description

The object that owns a run.

Everything below this layer computes something and returns: a solver answers one question about one instant, an integrator advances one step, a sampler produces one configuration. None of them knows that a simulation is a thing that goes on for a while. This class is where that is finally said, and it is deliberately the smallest statement of it that works: a state, the two objects that advance it, a step counter, and somewhere to send what happens.

Why the step counter is the clock

The simulated time is step * timestep, computed rather than accumulated. An accumulated time would drift: adding a timestep a million times gives a number that differs in its last bits from a million times the timestep, and which of the two a run reported would depend on whether it had been resumed. Multiplying keeps a resumed run and an uninterrupted one on the same clock, which is one of the several small things the bitwise-resume requirement in section 7 of the implementation plan turns out to mean.

What it owns and why the executor is in the list

The solver and the integrator, by unique pointer to their interfaces, so that which of each is in use is a run-time choice made once at assembly. Also the thread pool, when there is one, and that needs a word: a CPU solver is constructed from a reference to an executor which it does not own and which must outlive it (ADR-0017). Something has to hold that executor for exactly as long as the solver, and the simulation is the only object here whose lifetime is the run. It is stored before the solver so that the destruction order is the reverse of the construction order, which is what the reference requires.

The acceleration invariant

The integrators require that accelerations() holds the acceleration at positions() on entry to every step, and restore it on exit (ADR-0013). The constructor establishes it, and restore re-establishes it after a state arrives from somewhere else, so no caller of this class has to know the rule exists.