 # AbsolutePVCoordinates vs Orbit for initial state in numerical propagation

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.

First, welcome to the Orekit forum!

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.

Regards,
Bryan

Bryan,

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?

Thanks,
Andrew

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).

Bryan