[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Orekit Developers] Coming changes in Orbit class hierarchy


Guillaume Obrecht <guillaume.obrecht@gmail.com> a écrit :


Dear developers,


Hi Guillaume,



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:*
I already completed the following tasks, and the modifications uploaded on
https://www.orekit.org/forge/projects/socis-2015/repository :

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


As I already wrote to you when you emailed me privately, I still do hesitate
about the best architecture. I slightly prefer the first option, i.e. putting
the new class in the PVCoordinates tree rather than in the Orbits tree. The
main reasons are:

  - may be this class may prove useful elsewhere, not related with Orbit
  - experienced proved that putting several levels of inheritance in
    Orbit for different features is always awkward. In fact, we tried that
    at the very beginning to consider for example one layer for Cartesian/
    Keplerian/Circular/Equinoctial, another layer for Osculating/Mean and
    considered yet another layer with Target orbit/Determined Orbit/
    Propagated Orbit and so on but we always had a case when the layers
    when in the wrong order. In fact, we overused inheritance, it was a mess.
We end up removing all layers except the Cartesian/Keplerian/Circular/Equinoctial 
    and it remained much more stable. As you wrote, your current work put the
    extra orbit below and the proposal put it above: it is a clear indication
that something is not clear, so perhaps inheritance should not be used here. 

best regards,
Luc



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?*



Kind regards,

Guillaume Obrecht