generic orbit class
The Orbit class is currently the highest level implementation for orbit. However it is based on equinoctial elements which are not generic: the class is limited to Elliptical osculating orbit. It is not suitable for parabolic/hyperbolic trajectories, Lissajous type orbits... The most generic orbit should probably only contain PV coordinates for numerical integration. Moreover the center of the frame for a generic orbit should not have to coincide with the "center of motion" : it is possible to numerically integrate an heliocentric orbit with a center of integration set to a planet. More generally the frame center and orientation for a generic orbit should not have to be quasi-inertial if the user is providing the correct force model for that frame (including inertial forces).
(from redmine: issue id 22, created on 2011-04-13)
- Changesets:
- Revision c9b1c8f9662f865a613632e1d390922050130b60 on 2015-12-27T12:09:13Z:
Added compose and composeInverse to rotations.
These method are more flexible than the existing applyTo and
applyInverseTo (which are still present), because they allow caller
to specify a RotationConvention.
JIRA: MATH-1302, MATH-1303
Github: closes #22