My work on Orekit for the SOCIS 2015 could possibly imply some changes in basic elements of Orekit. I hence would really appreciate if you could read through this analysis and tell me what you think about it, and what options you would prefer to see implemented.
Thank you in advance for your time.
SOCIS 2015:
I am working for the SOCIS 2015 on making the modifications necessary to allow Orekit to propagate orbits in non-inertial reference frames. The goal is to be able to deal with problems such as:
- trajectory about an L2 point,
- swing-by about Jupiter in different reference frames (EME2000, ICRF, inertial centred on Jupiter),
- Earth orbit in rotating reference frame.
To do so, several things need to be done:
- Allowing the definitions of Orbit and SpacecraftState in non-inertial reference frames,
- Allowing the definition of orbits without a central body,
- Creation of an inertial forces model,
- Allowing the orbit propagation in non-inertial reference frames.
Work progress:
- new inertial force model class (/src/main/java/org/orekit/forces/inertia/InertialForces.java) taking as argument an reference inertial reference frame to use to compute the forces.
- new orbit class (/src/main/java/org/orekit/orbits/CartesianOrbitWithoutCentralBody.java) allowing to define an orbit with no central body (mu=0) with all method using mu redefined (this class inherits from CartesianOrbit).
- Temporary commenting of some lines to prevent Orekit from throwing exceptions if the reference frame is not pseudo-inertial.
I attached to this email a very simple script allowing to test the new orbit class and the new force model.
Decisions to make for the next steps:
Now, these changes have been quite conservative so far, but in the next steps, I will probably need to shake up the inheritance and aggregation structure of basic elements such as Orbit and SpacecraftState. In the current state, these are defined as such:
data class
P, V, A --> PVCoordinates
P, V, A, date --> TimeStampedPVCoordinates
P, V, A, date, frame --> [not defined]
P, V, A, date, frame, mu --> Orbit and sub-classes
P, V, A, date, frame, mu, attitude --> SpacecraftState
TimeStampedPVCoordinates inherits from PVCoordinates.
Orbit aggregates TimeStampedPVCoordinates.
SpacecraftState aggregates Orbit .
In my current proposal, the "orbit without a central body" inherits from Orbit, which causes issues as many methods of Orbit do not make sense anymore with no "mu" (getA(), getKeplerianPeriod(), etc...).
There are two options to deal with the problem, and both consist in creating a new class containing the following data: P, V, A, date, frame. The doubt is on where to put it in the hierarchy.
Option 1: In the PVCoordinates/TimeStampedPVCoordinates tree
The new class (TimeStampedFramedPVCoordinates or FramedPVCoordinates) would extend TimeStampedPVCoordinates to add the methods that are frame-dependent.
Option 2: Above the Orbit class
Currently, my new class is below Orbit (inheritance). Creating a new class above instead would solve a lot of problems. It could be called TrajectoryState for instance. Then Orbit would inherit/aggregate TrajectoryState to add the methods related to the central body.
In both cases, SpacecraftState would be modified to deal with the new class.
Could you give me your impressions about these options,
and "vote" for the one you prefer?