On 11/18/2014 09:06 AM, Luc Maisonobe wrote: > Hi all, > > Here are some final updates about the derivatives and the velocity > problem in Eckstein-Hechler. > >>> Evan Ward <evan.ward@nrl.navy.mil> a écrit : >>> To check that the initial orbit matching is causing the errors, I found >>> that if the initial orbit is shifted by a quarter period (or -0.75 >>> period) that the EH ephemeris stays within 70 m of the numerical >>> propagator. >> For better fitting, we can always use the PropagatorConverter >> implementations : they adjust the initial parameters on a complete >> sample instead of only one point. > I have further studied this option and reached a state I consider now > acceptable. > > The Eckstein-Hechler-Cartesian branch includes the latest fixes, as well > as some attempt to document the behaviour. > >>> So IMHO we can either fit the velocity exactly at the epoch or fit the >>> orbit parameters and tolerate a small velocity discrepancy at the epoch >>> in return for an orbit closer to the numerical propagator. Both can work >>> with option 2. >> I definitely think option 2 is much simpler, so if you can find a way to >> meke it work, I would be very happy. > The solution implemented in this branch is the one proposed by Evan: > directly build a CartesianOrbit, and forget about any new specialized > orbit type. > > Looking at several ways to fit the initial orbits, it appeared that was > has been done from the beginning (i.e. fit the circular parameters) > works pretty well, so I ave kept it. Furthermore, this means the new > Eckstein-Hechler propagator just propagates the exact same positions has > it has always done, it only output them as Cartesian. > > So the circular orbit that are used in the equations of the model and > that are also used for the initialization are now only internal ones, > they are not output anymore. > > I compared this initialization with the PropagatorConverter Pascal > created a few years ago, and which relies on a full sample and not a > single point, and indeed the result are pretty close. So our > initialization was good, and could be kept. > > So if users rebuild circular parameters from the generated Cartesian > parameters, they will see a difference with respect to the initial orbit > they used for building the propagator, but I now consider these > differences to be normal and related to the velocity discrepancy we > observed. If we recompute just the position from the circular > parameters, they all match to sub-micrometer level (i.e. the position > computed from the initial circular parameters, the position extracted > from the propagated orbit at t = 0 and the position computed from > converting the propagated orbit at t = 0 to circular). > > I have created an issue <https://www.orekit.org/forge/issues/180> and > solved it. I have also updated the wiki page on propagation > <https://www.orekit.org/forge/projects/orekit/wiki/Propagation#Eckstein-Hechler-propagation>. > > I think we could now merge branch Eckstein-Hechler-Cartesian (which > includes the branch position-velocity-acceleration) back to master. > > What do you think ? Looks good to me. Thanks for getting to the bottom of this issue. One small thing, is EHPropagator.toCartesian(...) supposed to be public? Best Regards, Evan >> For now, I have pushed the two branches I use for experiments. One is >> called EHOrbit and implements option 3, the other is called >> Eckstein-Hechler-Cartesian and implements option 2. In both cases, I >> have updated the tests as much as possible to match the accuracy >> achieved. For option 3, now all tests without exception do pass. >> Interpolation is very good but shiftedBy behaves strangely (I feel the >> error increases too fast for my taste). For option 2, four tests in >> EcksteinHechlerPropagatorTest fail, as explained in my previous post. If >> we could get them working, I think this branch would be a much better >> solution to merge in master. >> >>> Do you have access the reference publication for the EH propagator? I >>> think it may help to see how the propagator is initialized there. >> Unfortunately, no. The implementation was created from an appendix in >> the CNES 1995 book, not from the original paper. This book is not >> available anymore as far as I know. I will look again at it but don't >> think there is anything about initialization. The initialization process >> we used is a very simple fixed-point iteration as the model creates >> osculating parameters from mean parameters : so we iterate until the >> produced osculating match the initial orbit, currently in terms of >> circular parameters. > I have looked in the book. There was nothing about the initialization of > the model, only a few pages of raw equations without any explanation. If > you have access to this book (Spaceflight Dynamics - part I, 1995, > collaborative work from CNES, editor Jean-Pierre Carrou, ISBN > 2.85428.376.7), the model is in pp 474-481. > > best regards, > Luc > >> best regards, >> Luc >> >>> Best Regards, >>> Evan >>> >>>> So up to now, I was not able to have both initial orbit, propagated >>>> orbit and velocity correct. In all my tests, I had only two correct >>>> among the three. >>>> >>>>> 3. Create a combined orbit that has both the EH elements and the >>>>> position and velocity. This may be a bit confusing for the users since >>>>> the EH orbital elements are only define w.r.t. the EH propagation >>>>> model. >>>> In fact, as seen in the previous case, the orbital elements are also >>>> visible to the user as they are used to initialize the propagator from >>>> an osculating orbit (notwithstanding velocity). The hidden parameters >>>> are the mean parameters from wich EH computes the osculating ones. >>>> >>>>> In other words, if a user writes a method to use a Propagator (the base >>>>> interface, not one of its sub classes) then the user wouldn't be >>>>> able to >>>>> use the elements (a, e, i, ...) in the returned orbit since they >>>>> wouldn't know how the elements are defined. On the other hand, if the >>>>> user needs the EH parameters then I think this is the definition we >>>>> should choose. (IIUC this is what Luc is describing.) >>>> I tried it for the last few days (before switching to your suggestion >>>> number 2 above). It almost works but is quite complicated and I did >>>> not yet manage to solve a last problem. >>>> >>>> The way I've done it was to create an internal EHOrbit class extending >>>> CircularOrbit and overriding a few methods. At construction time it >>>> preserve the value of the circular osculating parameters (so initial >>>> orbit is preserved when propagating to same date), and it does not >>>> modify the mean parameters computation loop (so propagated orbit is >>>> consistent with other numerical propagators), and it additionally >>>> computes Cartesian parameters knowing about the derivatives (so it >>>> solves the initial problem). It's a bunch of code, but is quite >>>> straightforward thanks to the DerivativeStructure class which greatly >>>> simplifies derivatives computation. >>>> >>>> This however is not enough, and a few methods should be overriden too: >>>> shitfetBy and interpolate. Failing to overriding thme creates another >>>> type of inconsistency: the velocity of shifted or interpolated >>>> instances computed directly by the base CircularOrbit class is wrong. >>>> Overriding shiftedBy is trivial and works well. Overriding interpolate >>>> is difficult as it could be fed from several types of orbit in the >>>> sample, so I tried to rebuild the derivatives if the sample did not >>>> include them. This is a nightmare and I utterly failed. The problem is >>>> interpolate is automatically used for example when one creates an >>>> ephemeris from an EcksteinHechler propagator. It is a feature shared >>>> among all propagators and widely used. >>>> >>>> So I am confused now. >>>> >>>> I could attempt to reset the specialized EHOrbit class that knows >>>> about non-Keplerian effect when converting back and forth between >>>> circular and Cartesian, but I have yet to find how interpolate should >>>> work. Perhaps we could simply say that the specific implementation of >>>> interpolate in EHOrbit works *only* when the sample contains only >>>> EHOrbit instances and throws an exception otherwise. It seems fair to >>>> me as we cannot rebuild missing derivatives, and it would still work >>>> correctly in the regular case where people use consistently EHOrbit >>>> for a sample. In fact, it could probably be considered a general >>>> contract of the interpolate method to use only one type of orbits at a >>>> time and not to convert anything under the hood. >>>> >>>> Any thought ? >>>> Luc >>>> >>>>>> >>>>>>>> The problem may not hold for NumericalPropagator (I still have to >>>>>>>> check), because basically we do the computation the other way >>>>>>>> round. We >>>>>>>> start from x, y, z, vx, vy, vz and deduce a, e, ... from the >>>>>>>> mapping. So >>>>>>>> as long as our vx=dx/dt, vy=dy/dt, vz=dz/dt, the initial mapping >>>>>>>> will >>>>>>>> still hold. >>>>>>>> >>>>>>>>> It seems that if we add rates to all the elements then the >>>>>>>>> resulting >>>>>>>>> class could be classified as a Propagator. >>>>>>>> It is only a way to get a consistent (P, V), and as a propagator it >>>>>>>> would be really limited as it is a Taylor expansion. I would simply >>>>>>>> qualify it as a perturbed orbit allowing local expansion. >>>>>>> Extending the Taylor series expansion to higher order derivatives >>>>>>> makes >>>>>>> sense if we need to return the propagator's internal state, and the >>>>>>> satellite's PV in one consistent object. Is there a use case for >>>>>>> providing the propagator's internal state? I don't know, but I can't >>>>>>> think of any. >>>>>>> >>>>>>> If we need to provide the user with acceleration as well as PV then I >>>>>>> agree that we need a bigger container class to hold the extra >>>>>>> information. Maybe the new PVACoordinates would be the right choice >>>>>> I agree this is a good place. However, I did not create an extra class >>>>>> for this either, I simply added a third vector to PVCoordinates. We >>>>>> can discuss this later, when the merge of the branch will be >>>>>> attempted. >>>>>> >>>>>>> instead of a PerturbedOrbit class since I don't think we would get >>>>>>> the >>>>>>> same extrapolation from a PerturbedOrbit stored in Keplerian vs >>>>>>> Cartesian elements. To put it another way, If I converted a >>>>>>> PerturbedKeplerianOrbit to a PerturbedCartesianOrbit would they both >>>>>>> follow the same path? >>>>>> At second order level, in the neighborhood of the matching date, yes >>>>>> they should. Differences should appear at the first ignored derivative >>>>>> level and build up from there. >>>>>> >>>>>>> I'm not against the PerturbedOrbit classes; I just want to make >>>>>>> sure we >>>>>>> don't choose a complex solution to a simple problem. >>>>>> You are right. I have a clear tendency to over-engineer things, this >>>>>> is why I ask for advice from time to time. This is the great force of >>>>>> collaborative development : people don't get stuck in their own errors >>>>>> too long. >>>>> I think these constructive discussions combine the best ideas from >>>>> everyone. >>>>> >>>>>> So to be clear, here is the consensus : >>>>>> >>>>>> - I will simplify what I have done to limit as much as possible >>>>>> the changes to CircularOrbit. >>>>>> - In this setting, orbits will not know about non-Keplerian effects. >>>>>> - As this knowledge is needed for accurate and more importantly >>>>>> consistent velocity computation, the mapping between orbital >>>>>> parameters >>>>>> and Cartesian parameters will be precomputed by the propagators >>>>>> - If the mapping is not precomputed and orbits are built from one >>>>>> set of parameters only, then the mapping will be Keplerian only >>>>>> and will be performed byt orbit classes just as it is now >>>>>> >>>>> If we decide to define the orbit returned from a Propagator >>>>> according to >>>>> option 3 above then I think this is a good plan to implement it. >>>>> >>>>> Best Regards, >>>>> Evan >>>>> >>>>>> best regards, >>>>>> Luc >>>>>> >>>>>>>>> There might be a case for >>>>>>>>> this intermediate level of fidelity/speed, but is it worth the >>>>>>>>> added >>>>>>>>> complexity? Especially since we already have one that is fast (the >>>>>>>>> Orbit >>>>>>>>> class) and one that is precise (the Propagator classes). Maybe I'm >>>>>>>>> still >>>>>>>>> not understanding your proposal. >>>>>>>> I detected the problem when checking some pointing attitude modes >>>>>>>> that >>>>>>>> are related to spacecraft velocity (alignment of the spacecraft axis >>>>>>>> with ground drift for Earth observation). This mode transforms >>>>>>>> something >>>>>>>> that is a derivative (velocity) into a regular non-differentiated >>>>>>>> value >>>>>>>> (an angle). So we go up one order of derivation. For such modes, a >>>>>>>> wrong >>>>>>>> velocity induces a wrong angle and a wrong acceleration induces a >>>>>>>> wrong >>>>>>>> angular rate. As the angular rate is used for time shift, I needed >>>>>>>> it to >>>>>>>> be accurate. >>>>>>>> >>>>>>>> You also mentioned issues with Doppler which would also occur. >>>>>>>> >>>>>>>> We do need accurate velocity, and we do need a velocity that is >>>>>>>> consistent with the derivative of the position. >>>>>>> Definitely agree that getting the velocity correct is important. >>>>>>> Thanks >>>>>>> again for all the work you've put into solving this bug. >>>>>>> >>>>>>> Best Regards, >>>>>>> Evan >>>>>>> >>>>>>>> best regards, >>>>>>>> Luc >>>>>>>> >>>>>>>>> Best Regards, >>>>>>>>> Evan >>>>>>>>> >>>>>>>>>>> Then we wouldn't have to modify the existing set of Orbit >>>>>>>>>>> classes, and >>>>>>>>>>> the user would see the correct osculating P/V. (This might be >>>>>>>>>>> equivalent >>>>>>>>>>> to your second approach.) >>>>>>>>>>> >>>>>>>>>>> As far as where to put the code, it seems like the conversion >>>>>>>>>>> code would >>>>>>>>>>> be specific to the internal state representation used by the >>>>>>>>>>> propagator, >>>>>>>>>>> so I think it makes sense to keep the code as private to the >>>>>>>>>>> propagator. >>>>>>>>>>> Though if you think there would be other uses for the >>>>>>>>>>> conversion, I >>>>>>>>>>> think a public static factory method would work well. >>>>>>>>>> Yes, the conversion code is propagator dependent. The first >>>>>>>>>> implementation I played with is Eckstein-Hechler propagator, >>>>>>>>>> and it >>>>>>>>>> definitely is Eckstein-Hechler specific (it's a simple >>>>>>>>>> derivation of >>>>>>>>>> the original equations, so each time we did compute something like >>>>>>>>>> e = >>>>>>>>>> a * c + b * d, now we also have another statement to compute >>>>>>>>>> eDot = >>>>>>>>>> aDot * c + a * dCot + bDot * d + b * dDot). For numerical >>>>>>>>>> propagator >>>>>>>>>> we already have the derivatives since we start from the >>>>>>>>>> derivatives >>>>>>>>>> and integrate them, so its even simpler. For DSST, this will be >>>>>>>>>> a mix >>>>>>>>>> as the mean elements are integrated and the short periodics >>>>>>>>>> terms are >>>>>>>>>> computed from Fourier coefficients which are straightforward to >>>>>>>>>> differentiate. For ephemeris-based propagator, we will need to >>>>>>>>>> compute >>>>>>>>>> the derivatives of the underlying polynomials, which is also >>>>>>>>>> straightforward. >>>>>>>>>> >>>>>>>>>>> Thanks Luc for finding this issue and doing the analysis. I can >>>>>>>>>>> see how >>>>>>>>>>> this would be an issue when computing the Doppler as well as time >>>>>>>>>>> shifting. >>>>>>>>>> your welcome >>>>>>>>>> >>>>>>>>>> best regards, >>>>>>>>>> Luc >>>>>>>>>> >>>>>>>>>>> Best Regards, >>>>>>>>>>> Evan >>>>>>>>>>> >>>>>>>>>>> On 10/29/2014 06:57 AM, MAISONOBE Luc wrote: >>>>>>>>>>>> Hi Paul, >>>>>>>>>>>> >>>>>>>>>>>> paulcefo <paulcefo@buffalo.edu> a écrit : >>>>>>>>>>>> >>>>>>>>>>>>> Luc, >>>>>>>>>>>>> >>>>>>>>>>>>> Do I correctly understand that your concern is that Keplerian >>>>>>>>>>>>> transformations do apply outside the osculating space? >>>>>>>>>>>> The problem I had was that we did use Keplerian-only expression >>>>>>>>>>>> to set up local Taylor expansions around the current point (a >>>>>>>>>>>> few >>>>>>>>>>>> seconds away). This was slightly wrong when all the parameters >>>>>>>>>>>> were >>>>>>>>>>>> time-dependent and not only the anomaly was time-dependent. Of >>>>>>>>>>>> course, >>>>>>>>>>>> the error increasing with the time offset with respect to the >>>>>>>>>>>> central >>>>>>>>>>>> date at which the Taylor expansion is built. The fix was >>>>>>>>>>>> simply to >>>>>>>>>>>> not forget the derivatives of these other parameters. >>>>>>>>>>>> >>>>>>>>>>>> This Taylor expansion feature is a built-in feature available in >>>>>>>>>>>> all >>>>>>>>>>>> Orekit orbits, it typically allows to do computation in the >>>>>>>>>>>> vicinity of >>>>>>>>>>>> an already computed point without needed to trigger a complete >>>>>>>>>>>> propagator. >>>>>>>>>>>> It can even be used for some computation inside the run of a >>>>>>>>>>>> propagator, >>>>>>>>>>>> as for example when the higher level propagator takes care of >>>>>>>>>>>> the long >>>>>>>>>>>> term propagation and at each step we need some additional points >>>>>>>>>>>> surrounding the current step to compute attitude evolution in >>>>>>>>>>>> some >>>>>>>>>>>> specific modes. >>>>>>>>>>>> >>>>>>>>>>>> My concern was how to implement this fix in our current >>>>>>>>>>>> architecture, >>>>>>>>>>>> and more precisely were to put the code: in an existing class >>>>>>>>>>>> or in >>>>>>>>>>>> a dedicated class which would be used only by propagators. >>>>>>>>>>>> >>>>>>>>>>>> best regards, >>>>>>>>>>>> Luc >>>>>>>>>>>> >>>>>>>>>>>>> Paul >>>>>>>>>>>>> >>>>>>>>>>>>> -- >>>>>>>>>>>>> Dr. Paul J. Cefola >>>>>>>>>>>>> Consultant in Aerospace Systems, Spaceflight Mechanics, & >>>>>>>>>>>>> Astrodynamics >>>>>>>>>>>>> Adjunct Faculty, Dept. of Mechanical and Aerospace Engineering, >>>>>>>>>>>>> University at Buffalo (SUNY) >>>>>>>>>>>>> >>>>>>>>>>>>> 4 Moonstone Way >>>>>>>>>>>>> Vineyard Haven, MA 02568 >>>>>>>>>>>>> USA >>>>>>>>>>>>> >>>>>>>>>>>>> 508-696-1884 (phone on Martha's Vineyard) >>>>>>>>>>>>> 978-201-1393 (cell) >>>>>>>>>>>>> >>>>>>>>>>>>> paulcefo@buffalo.edu >>>>>>>>>>>>> paul.cefola@gmail.com >>>>>>>>>>>>> >>>>>>>>>>>>> On 10/29/2014 6:02 am, MAISONOBE Luc wrote: >>>>>>>>>>>>>> Hello, >>>>>>>>>>>>>> >>>>>>>>>>>>>> As some of you may be aware, I have been working for a few >>>>>>>>>>>>>> months on >>>>>>>>>>>>>> second order derivatives in the git branch >>>>>>>>>>>>>> position-velocity-acceleration. This work is still ongoing but >>>>>>>>>>>>>> I hope >>>>>>>>>>>>>> to finish it for 7.0 and merge the branch back to master soon. >>>>>>>>>>>>>> For >>>>>>>>>>>>>> now, there are still failing tests so I can't do it. >>>>>>>>>>>>>> >>>>>>>>>>>>>> This change should allow us to reach several goals : >>>>>>>>>>>>>> >>>>>>>>>>>>>> - improved accuracy in shiftedBy methods >>>>>>>>>>>>>> - improved accuracy in interpolators (with user-defined >>>>>>>>>>>>>> choices to use or not first and second derivatives >>>>>>>>>>>>>> from the sample) >>>>>>>>>>>>>> - improved accuracy in attitude >>>>>>>>>>>>>> - removal of ugly hidden finite differences in some classes >>>>>>>>>>>>>> (most notably attitude modes) with hard-coded steps >>>>>>>>>>>>>> - hopefully faster Earth transforms, by replacing Hermite >>>>>>>>>>>>>> interpolation with single point extrapolation >>>>>>>>>>>>>> - availability of non-Keplerian acceleration everywhere >>>>>>>>>>>>>> - availability of angular acceleration in attitude and frames >>>>>>>>>>>>>> - proper composition of dynamics in frames >>>>>>>>>>>>>> - possibility to propagate orbits in non-inertial frames >>>>>>>>>>>>>> - possibility to propagate orbits without a central body >>>>>>>>>>>>>> (interplanetary missions, Lagrange point missions, ...) >>>>>>>>>>>>>> >>>>>>>>>>>>>> There is one point that bothers me right now. As I removed >>>>>>>>>>>>>> some of >>>>>>>>>>>>>> the >>>>>>>>>>>>>> ugly finite differences, some non-regression tests started to >>>>>>>>>>>>>> fail. I >>>>>>>>>>>>>> finally found the raw cause of these failures and was >>>>>>>>>>>>>> surprised to >>>>>>>>>>>>>> discover an old bug in the way we use the osculating orbits >>>>>>>>>>>>>> produced >>>>>>>>>>>>>> by the Eckstein-Hechler analytical propagator. This propagator >>>>>>>>>>>>>> takes >>>>>>>>>>>>>> zonal terms into account, and produces directly circular >>>>>>>>>>>>>> parameters a, >>>>>>>>>>>>>> ex, ey, ... When we compute anything related to geometry, we >>>>>>>>>>>>>> compute >>>>>>>>>>>>>> Cartesian coordinates using the Orbit getPVCoordinates method. >>>>>>>>>>>>>> As the >>>>>>>>>>>>>> Orbit classes do not know anything about the perturbation, the >>>>>>>>>>>>>> (P, V) >>>>>>>>>>>>>> pair does in fact implicitly relies on Keplerian-only >>>>>>>>>>>>>> expressions. So >>>>>>>>>>>>>> the velocity part is *not* consistent with the derivative of >>>>>>>>>>>>>> the >>>>>>>>>>>>>> position. The real derivative of the position takes the >>>>>>>>>>>>>> non-Keplerian >>>>>>>>>>>>>> effects into account which are ignored by getPVCoordinates. >>>>>>>>>>>>>> The >>>>>>>>>>>>>> difference is small, but as the tests threshold were >>>>>>>>>>>>>> deliberatly very >>>>>>>>>>>>>> tight, the tests started to fail when the various pointing >>>>>>>>>>>>>> directions >>>>>>>>>>>>>> were not computed anymore from finite differences mainly >>>>>>>>>>>>>> involving >>>>>>>>>>>>>> position and when they relied on the computed velocity. So the >>>>>>>>>>>>>> problem >>>>>>>>>>>>>> already happens in the master branch, it is not specific to >>>>>>>>>>>>>> the >>>>>>>>>>>>>> introduction of acceleration (it was just detected here during >>>>>>>>>>>>>> testing). >>>>>>>>>>>>>> >>>>>>>>>>>>>> The solution is in fact quite simple. If an orbit has been >>>>>>>>>>>>>> produced by >>>>>>>>>>>>>> a non-Keplerian propagator, the propagator already knows about >>>>>>>>>>>>>> the >>>>>>>>>>>>>> derivatives of the orbital elements (which are circular in the >>>>>>>>>>>>>> Eckstein-Hechler model case but can be any kind of >>>>>>>>>>>>>> parameters for >>>>>>>>>>>>>> other propagators). The propagator should therefore provide >>>>>>>>>>>>>> these >>>>>>>>>>>>>> derivatives to the orbit so they can be used in the >>>>>>>>>>>>>> PVCoordinates >>>>>>>>>>>>>> conversion. The code is very simple and straightforward. I >>>>>>>>>>>>>> have >>>>>>>>>>>>>> checked this and got very interesting results with >>>>>>>>>>>>>> Eckstein-Hechler/Circular, as for example a simple >>>>>>>>>>>>>> interpolation over >>>>>>>>>>>>>> a 900s arc with proper velocity/acceleration has a 88m error >>>>>>>>>>>>>> with two >>>>>>>>>>>>>> base points now whereas it was 5162 m before (and 0.02m vs >>>>>>>>>>>>>> 650m for 3 >>>>>>>>>>>>>> points, 1.0e-5m vs 259m for 4 points). >>>>>>>>>>>>>> >>>>>>>>>>>>>> Here is what bothers me: >>>>>>>>>>>>>> >>>>>>>>>>>>>> Should we create specialized classes for perturbed orbits or >>>>>>>>>>>>>> should we >>>>>>>>>>>>>> simply add a constructor to the existing orbits with the >>>>>>>>>>>>>> parameters >>>>>>>>>>>>>> derivatives and set them to 0 when they are not known? >>>>>>>>>>>>>> >>>>>>>>>>>>>> For my tests, I created PerturbedCircularOrbit which extends >>>>>>>>>>>>>> CircularOrbit and override the protected initPVCoordinates >>>>>>>>>>>>>> method and >>>>>>>>>>>>>> the public shiftedBy and interpolate methods. I could also >>>>>>>>>>>>>> have >>>>>>>>>>>>>> simply >>>>>>>>>>>>>> moved everything into CircularOrbit with a new constructor. >>>>>>>>>>>>>> >>>>>>>>>>>>>> I do not like much the PerturbedXxxxOrbit approach, as it >>>>>>>>>>>>>> forces to >>>>>>>>>>>>>> create also additional entries in the OrbitType enum with >>>>>>>>>>>>>> additional >>>>>>>>>>>>>> converters and it becomes awkward if for example a user >>>>>>>>>>>>>> configures a >>>>>>>>>>>>>> NumericalPropagator to generate XxxxOrbit, despite this >>>>>>>>>>>>>> propagator >>>>>>>>>>>>>> will in fact really generate PerturbedXxxOrbit because it is >>>>>>>>>>>>>> what a >>>>>>>>>>>>>> Numerical propagator is for. So there should be either an >>>>>>>>>>>>>> internal >>>>>>>>>>>>>> modification of the user setting from OrbitType.XXXX to >>>>>>>>>>>>>> OrbitType.PERTURBED_XXXX or an error triggered which would >>>>>>>>>>>>>> invalidate >>>>>>>>>>>>>> *all* current user code as it would become forbiddent to >>>>>>>>>>>>>> generate >>>>>>>>>>>>>> XXXX >>>>>>>>>>>>>> orbits now. >>>>>>>>>>>>>> >>>>>>>>>>>>>> On the other hand, the drawback of modifying the existing >>>>>>>>>>>>>> classes to >>>>>>>>>>>>>> hold the non-Keplerian derivatives is that they will consume >>>>>>>>>>>>>> more >>>>>>>>>>>>>> memory. I don't think it is a problem with current computers. >>>>>>>>>>>>>> >>>>>>>>>>>>>> In any case, initial orbits created directly from user code >>>>>>>>>>>>>> or by >>>>>>>>>>>>>> reading files would not include the derivatives and therefore >>>>>>>>>>>>>> will be >>>>>>>>>>>>>> built as usual (by calling the unmodified classes in the first >>>>>>>>>>>>>> approach, or by using the already existing constructors in the >>>>>>>>>>>>>> second >>>>>>>>>>>>>> approach, assuming these constructors will automatically set >>>>>>>>>>>>>> the >>>>>>>>>>>>>> derivatives to Keplerian-only values). In any case, full-blown >>>>>>>>>>>>>> perturbed orbits will be created internally by Orekit >>>>>>>>>>>>>> propagators, >>>>>>>>>>>>>> which can easily be modified to provide the derivatives they >>>>>>>>>>>>>> know (by >>>>>>>>>>>>>> creating instances of the new derived classes in the first >>>>>>>>>>>>>> approach, >>>>>>>>>>>>>> or by using new constructors with additional parameters in the >>>>>>>>>>>>>> second >>>>>>>>>>>>>> approach). >>>>>>>>>>>>>> >>>>>>>>>>>>>> My humble opinion would be to use the second approach to solve >>>>>>>>>>>>>> this >>>>>>>>>>>>>> bug. I will probably do this in the >>>>>>>>>>>>>> position-velocity-acceleration >>>>>>>>>>>>>> branch so it will include accelerations right from the start >>>>>>>>>>>>>> and will >>>>>>>>>>>>>> be merged to master at the same time as the rest of the >>>>>>>>>>>>>> branch. Of >>>>>>>>>>>>>> course, this will be a dedicated commits (Git branches are >>>>>>>>>>>>>> great!). >>>>>>>>>>>>>> >>>>>>>>>>>>>> What do you think ? >>>>>>>>>>>>>> >>>>>>>>>>>>>> best regards, >>>>>>>>>>>>>> Luc >>>>>>>>>>>>>> >>>>>>>>>>>>>> ---------------------------------------------------------------- >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> This message was sent using IMP, the Internet Messaging >>>>>>>>>>>>>> Program. >>>>>>>>>>>> >>>>>>>>>>>> ---------------------------------------------------------------- >>>>>>>>>>>> This message was sent using IMP, the Internet Messaging Program. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> ---------------------------------------------------------------- >>>>>>>>>> This message was sent using IMP, the Internet Messaging Program. >>>>>>>>>> >>>>>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> ---------------------------------------------------------------- >>>>>> This message was sent using IMP, the Internet Messaging Program. >>>>>> >>>>>> >>>>> >>>> >>>> >>>> ---------------------------------------------------------------- >>>> This message was sent using IMP, the Internet Messaging Program. >>>> >>>> >>> >> >> >> ---------------------------------------------------------------- >> This message was sent using IMP, the Internet Messaging Program. >>
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature