Sorry I did not have a lot of time recently to answer to this topic, I will resume the work on the IOD gauss. @Echulion thanks for the explanation of your work
What I was suggesting, if I remember, was not to limit the f and g definition of the first order of the Taylor Serie and use the definition of f and g found in Vallado equation 2-69 page 87. It should be more precise but maybe the tradeoff between the greater time computation and the gain of precision is not worth it. Anyway for the issue I will just do it at the first order.
For the development of Field, I guess I will have to do it Moreover, there is some duplication in the IOD Laplace and IOD Gooding with the lineOfSight method (and also now in the IOD Gauss) so I was thinking maybe reworking and cleaning the IOD package creating an abstract class and daughter classes. I will also try to take into consideration the proposition of @Serrof of giving the possibility of choosing between different versions.
What was a small issue is kind of becoming a bigger work
revamping the IOD package sounds like a good idea.
I also noticed methods in Gooding that are redundant w.r.t. what is already in Hipparchus’ Vector3D.
About the Lambert solver, there is already an open issue (#748) on it and it could benefit from a re-implementation I think.
So I completed the first part using the @Echulion values as a reference (congrats !) for the validation of my code, because I had the same issue with validating with the Vallado, and Curtis.
I will now work on refactoring the IOD classes and adding fields, so not for now for the merge request but sooner the better !
I was wondering, why do all the IOD methods return a KeplerianOrbit? Is that because only the elliptical case (and not the hyperbolic one) is treated in general? Even so, I think it should return non singular elements so certainly not Keplerian ones… Thoughts?
I’m not sure, I think it’s an oversight. In my opinion they should all return the generic type Orbit and not be limited to a specific type.
Now during the construction of the output orbit, instead of using KeplerianOrbit we could use for example CartesianOrbit. From what I’ve seen IodGibbs/Gooding/Lambert use PVs to construct a Keplerian orbit while a Cartesian would look more natural (Laplace already returns a Cartesian orbit).
You can open a bug but I think @jasquier is already taking care of this on his issue. Or maybe we should split since this would be an API-breaking modification ?
I am working on the iod package architecture so I will take care of the issue, as it was already identified with @MaximeJ. However, I tried to create a pertinent abstract class of the iod but all the iods have specific estimate method, even if looking alike. So it is hard without going deep into all the iods algorithms to do a good refactoring, and I have no time to do it right now.
About Fielding IOD Gauss, same I am stuck with the LaguerreSolver, which is not fielded, and so if I want to continue to field I will have to field a lot of things of Hipparchus about Solver, and same i don’t have the time right now, so i will put it aside for now.
So to summarise, working right now on the refactoring of the IOD architecture but not an ambitious one, putting aside fielding of IOD.
So maybe 2 issues to open about fielding the iod package + big refactoring of iod package.
So to put an end to this topic, I ended the implementation of the IOD Gauss and refactored the IOD package with an Abstract Method “AbstractAnglesOnlyIod” because some features where shared between Gauss, Gooding and Laplace.
The AbstractAnglesOnlyIod method allows the factorisation of the same methods for Gooding, Gauss or Laplace : An IOD can be launched from 3 AngularRaDec measurements, from 3 PVCoordinates or 3 Vector3D at 3 different dates, from only one Vector3D or PVCoordinates corresponding the the station position (at a given date and given frame) giving the 3 targeted measurements dates and the 3 LineOfSights associated.
I added 2 methods to the AngularRaDec class to compute the LineOfsight : “getLineOfSight” if the LineOfSight vector required is at the date of the AngularRaDec measurement, and a “gestEstimatedLOS” if a LOS is requested at another Date.
I tried to refactor all the IOD package but Lambert and Gibbs were not suitable for a refactoring, as the methods are really specific each.
Finally, I tried to field everything but it was depending of the fielding of LaguerreSolver, and so was beyond my scope for this issue.
It is merged in develop right now and will be part of the v12.0, hopefully released soon. Should be bugless as the mighty @Vincent did the review !
Thanks for your hard job. It is indeed very useful.
I just viewed your code, KeplerianOrbit is still used inside, only except IodLaplace, . According to comments of @MaximeJ , CartesianOrbit may be more suitable. Is that ok?
return new KeplerianOrbit(new PVCoordinates(p2Vector3D, v2Vector3D), outputFrame, obsDate2, mu);
→
return new CartesianOrbit(new PVCoordinates(p2Vector3D, v2Vector3D), outputFrame, obsDate2, mu);
Moreover, there is some duplication in the IOD Laplace and IOD Gooding with the lineOfSight method (and also now in the IOD Gauss) so I was thinking maybe reworking and cleaning the IOD package creating an abstract class and daughter classes. I will also try to take into consideration the proposition of @Serrof of giving the possibility of choosing between different versions.
.