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