A NumericalPropagator can propagate using AbsolutePVCoordinates or one of the Orbit subclasses: CartesianOrbit, EquinoctialOrbit, KeplerianOrbit, etc.
What is the difference between propagation using AbsolutePVCoordinates vs propagation using CartesianOrbit?
What are some practical reasons why I would choose to propagate using each of these different classes? Can you give me an example of some situations when one representation would have an advantage over another? Cartesian coordinates seem like the obvious choice to me.
My use case: I am a first-time Orekit user setting up a numerical propagator using a 20x20 gravity field, sun and moon perturbations, and an atmospheric model for drag. I’m interested in propagating satellites in LEO.
Using AbsolutePVCoordinates you can define and propagate your orbit/coordinates with a non-inertial frame.
Using the Orbit subclasses, the frame defining your orbit must be an inertial frame otherwise, an exception is thrown.
AbsolutePVCoordinates are very useful for propagating orbits around Lagragian points or for modelling interplanetary trajectories because non-inertial frames are usually used. If you want some examples, you can look at the Orekit CR3BP tutorials.
For other use cases (i.e. classical orbit around a celestial body) you can easily define an orbit with an inertial frame. Therefore, Orbit subclasses can be easily used.
Your use case is what I previously called a “classical orbit around a celestial body”. Therefore, you can use Orbit subclasses.
Thanks very much, that makes things a little clearer. I am still confused about the difference between AbsolutePVCoordinates and CartesianOrbit, though. What is it about AbsolutePVCoordinates that allows propagation in non-inertial frames, and what is it about CartesianOrbit that prevents propagation in non-inertial frames? Don’t both ultimately use the same underlying representation of Cartesian position/velocity?
Both classes contain position and velocity of a satellite. Both classes can be constructed using the same objects (i.e. a Frame, an AbsoluteDate and a PVCoordinates).
CartesianOrbit also asks the central attraction coefficient to be initialized. AbsolutePVCoordinates not because during the orbit propagation, the Newtonian attraction is automatically added if your orbit defined a central attraction coefficient. Therefore, in the case of AbsolutePVCoordinates, the Newtonian attraction is not added. And this is a normal behavior because, as I said before, the two main use cases of AbsolutePVCoordinates is for propagating orbit around Lagragian points and interplanetary trajectories. For them, you can’t define the Earth attraction with a Newtonian Attraction, you will have to use SingleBodyAbsoluteAttraction to define the Earth attraction. As a consequence, it is very useful for the orbit propagator to have this two different classes because they represent two different contexts of propagation.
Historically CartesianOrbit is present in Orekit since the beginning. Orbit propagation also. Propagation in non-inertial frame features have been added later (version 10.0, 10.1 and CR3BP model in 10.2). So, some years after (more than 10 years to be exact).