I wrote a small script to test one of the cases proposed by Luc: propagation of a swing-by trajectory about Jupiter in 3 reference frames to test . I restricted myself to a very simple model where only Jupiter acts on the spacecraft. I tested this three cases:
Integration frame: EME2000
Representation of the trajectory: AbsolutePVCoordinates (No central body)
ThirdBodyAttraction with Jupiter
Case 2:
Integration frame: ICRF
Representation of the trajectory: AbsolutePVCoordinates (No central body)
ThirdBodyAttraction with Jupiter
Case 3:
Integration frame: Jupiter-centered inertial
Representation of the trajectory: Orbit (Central body: Jupiter)
For comparison, all orbits are shown in ICRF, and the third case is considered as reference (as it used to be the "old" way to do things).
After a propagation over 100000s and the swing-by, the difference in position for case 1 is of 30416 km, and for case 2 of 2296 km.On the animated plot herebelow, the three trajectories are almost superposed. (The trajectory in red, ICRF, barely visible, is actually very close to the one in yellow, Jupiter-centered).
As the errors almost does not vary with the parameters of the integrator, I think that they are due to the fact of considering all these frames pseudo-inertial, which they are not.
I am attaching the Orekit test (compatible with my last commit) as well as the Matlab plot script, just in case somebody wants to have a look.
I am interested in your feedback.
In particular, as I am not a regular of Orekit, I would appreciate if you could tell me if I built the script the way you commonly do, and if there are additional functions/tests I should include to make sure they still work.
Kind regards,
Guillaume Obrecht
Le lun. 17 août 2015 à 21:19, Guillaume Obrecht <guillaume.obrecht@gmail.com> a écrit :
Dear all,So as option 1 seems to have the preference, I started working on it.I created the "AbsolutePVCoordinates" class, which extend the TimeStampedPVCoordinates by adding a Frame. It implements the same interfaces as Orbit (TimeStamped, TimeInterpolate, Serializable and PVCoordinatesProvider).I then modified SpacecraftState, adding it an AbsolutePVCoordinates member, while still having the Orbit member. There are now two series of constructors for SpacecraftState: one initializing Orbit, the other one initializing AbsolutePVCoordinates (the one not initialized is set to null). With no setter defined for any of these members, it makes sure that there is no conflict possible, only one being not null. I also wanted the method getOrbit() to throw an error when the orbit has not been defined, but I would need to modify a lot of methods in Orekit to catch it. So I am still hesitating. The class methods (getPVCoordinates(), etc) have been modified to make use of the one initialized.The new class method mapAbsolutePVCoordinatesToArray() is meant to be the equivalent of the OrbitType.mapOrbitToArray() method (it throws an error if it is the Orbit that has been properly defined).With some minor changes in NumericalPropagator, this modified SpacecraftState can be propagated, both in inertial and non-inertial frames. The results are identical to the ones obtained with my previous solution (CartesianOrbitWithoutCentralBody).The changes have been pushed to the git. I like this solution, it makes much more sense to me than my previous attempt, and should be fully compatible with old code. I am looking forwards to your comments.Dear Hank,The advantages and disadvantages will greatly depend on the case. In terms of performance, it is hard to tell at this stage if the added computation time due to the evaluation of the inertial forces will be compensated by the suppression of the transformation step.The bigger difference will probably be on the precision. One can expect a greater precision of the floating-point if the numbers involved are small, i.e., in the case of an orbit about the Sun-Earth L2 points, if the reference frame is centered on the L2 point rather than on the Sun.But the goal is also to expand the possibilities of Orekit. The new class might be more suitable for trajectories where the gravitation of a single body is not the driving force.Kind regards,GuillaumeLe jeu. 13 août 2015 à 11:24, Hank Grabowski <hank@applieddefense.com> a écrit :What are the advantages vs. disadvantages of the two methodologies: doing the integration in the appropriate central body-locked inertial frame and then transforming the result, transforming each of the results into the non-inertial frame for force model evaluation?On Thu, Aug 13, 2015 at 10:14 AM, Guillaume Obrecht <guillaume.obrecht@gmail.com> wrote:Hello Hank,My first example, the propagation of a trajectory in a frame linked to an L2 point, is a case that requires all the changes we are talking about: no central body, propagation in non-inertial frame and inertial forces model.Propagating in inertial frames centred on a body and then transform to other frames is the only way to do now, with its benefits and drawbacks. My task is to allow direct propagation in any frame to give more flexibility to Orekit, without breaking previous functions. It is then up to the user to determine what method is the more suitable for his case.Formation flying is a good example indeed. With these changes, it will be possible to propagate the trajectory of a satellite w.r.t. a frame centred on another one.Kind regards,GuillaumeLe jeu. 13 août 2015 à 10:18, Hank Grabowski <hank@applieddefense.com> a écrit :I'm not sure I'm following why some of the changes are being made here. For example, why would there be a case of force model evaluation happening in a frame without a central body? Your three examples all have dominant central bodies. I understand the need to swap central bodies at different propagation stages, for example when you are going from a heliocentric to Jupiter centric frame, but couldn't that be achieved by a transform function between the heliocentric state and the Jupiter-centric state? The class structure of spacecraft state and orbit would therefore be unnecessary. If these are relative states, for formation flying for example, then I understand why we would want to have the option to represent orbits as non-inertial, but for force model evaluation I'm not sure you would propagate in those non-inertial frames but instead continue propagation in inertial frames and then transform them to the relative state representations.On Mon, Aug 10, 2015 at 7:18 PM, Guillaume Obrecht <guillaume.obrecht@gmail.com> wrote:Dear developers,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 --> SpacecraftStateTimeStampedPVCoordinates 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 treeThe new class (TimeStampedFramedPVCoordinates or FramedPVCoordinates) would extend TimeStampedPVCoordinates to add the methods that are frame-dependent.Option 2: Above the Orbit classCurrently, 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?Kind regards,Guillaume Obrecht