Future Plans

[sefffal]

The current package architecture has done an excellent job powering Octofitter, but we're starting to run up against limitations of the current API. In this issue, I want to outline my goals and ideas for a new package architecture.

Goals:

• Support for multiple (>2) objects. This should include making the central body (eg star) a special case of general multi body mechanics
• Support for pluggable multi body solvers. These should include N body solvers, first order approximate multi planet calculations, and independent 2-body physics.
• nested 2-body physics eg. for exomoons and beyond.
• full 3D model of barycentric and individual body motion including light travel time effects
• eg I want to be able to ask for right ascension and declination of a moon orbiting a planet (calculated using keplerian approximation) which itself is part of a multi-planetary system propagated using an N-body solver

[sefffal]

In terms of specific architecture choices, my first instinct is to create a System parametric type that includes N (perhaps as low as zero) bodies and encodes a propagator. Encoding the number of bodies in the type has some advantages in allowing us to work with heterogeneous body types without dynamic dispatch.

We could adopt an inverse tree data type where each body is a lead node and holds a propagator object parent. Eg a moon could hold a planet with a Kepler solver, and the planet could hold a star with a Kepler solver. Alternatively, the planet could hold some kind of system object and an N body propagator. At the bottom of the tree could be a barycentre object encoding the position and velocity of the system as a whole. Calculating values with respect to another given body could result in a walk up the tree, calculating at each step.

On the other hand, it might be worth adopting a simpler architecture more inspired by rebound: 0-N bodies of the same data type indexed by a number only.