Loading...
Searching...
No Matches
orrery::integrators::AccelerationField Class Referenceabstract
The acceleration produced by a set of masses at a set of positions. More...
#include <orrery/integrators/acceleration_field.hpp>
Inheritance diagram for orrery::integrators::AccelerationField:
Public Member Functions | |
| virtual void | evaluate (core::Vec3Span< const core::Real > positions, std::span< const core::Real > masses, core::Vec3Span< core::Real > accelerations)=0 |
| Write the acceleration of each position into accelerations. | |
Detailed Description
The acceleration produced by a set of masses at a set of positions.
One virtual call per force evaluation, which is between one and four per timestep, ahead of the N^2 or N log N interactions the implementation is about to compute. That is the boundary the implementation plan permits virtual dispatch at, and no call through this interface appears inside a loop over particles.
Member Function Documentation
◆ evaluate()
|
pure virtual |
Write the acceleration of each position into accelerations.
All three views describe the same particles in the same order and have the same length. The masses belong to the particles at those positions, which matters when the positions are a Runge-Kutta stage rather than the state: a stage moves the particles without changing what they are.
The accelerations are written rather than accumulated, so the caller passes a buffer without clearing it first.
Not const, because an implementation legitimately has state to change: the interaction counter the direct solver keeps for cross-algorithm comparison, and the tree the Barnes-Hut solver rebuilds as the particles move. A const interface would push both into mutable members, which says the same thing less honestly.
Implemented in orrery::solvers::BarnesHutSolver, orrery::solvers::DirectSolver, orrery::solvers::SyclDirectSolver, and orrery::solvers::SyclTreeSolver.
The documentation for this class was generated from the following file:
- orrery/integrators/acceleration_field.hpp
