|
Hi Evan,
Thanks for responding. I thought about that, and I've tested the FiniteDifferencePropagatorConverter as low as 1e-6 with no change. I'll give it a try and go a couple more orders of magnitude lower.
Greg ___________________________________________________ From: orekit-users-request@orekit.org <orekit-users-request@orekit.org> on behalf of Ward, Evan <Evan.Ward@nrl.navy.mil>
Sent: Thursday, July 26, 2018 12:09 PM To: orekit-users@orekit.org Subject: Re: [Orekit Users] 0.1 deg Inclination bias? Hi Greg,
On Thu, 2018-07-26 at 14:35 +0000, Hammel, Gregory (ASC/CSA) wrote:
So, I have found the source of my 0.1deg error - it was a reference frame issue that I had missed (was passing a TOD vector but telling the Draper code it was J2000). I have taken the step to using the conversion process because the sma noise on the Draper propagation is larger than I would like. However, while my results are providing very good sma's, eccentricities and argument of perigees, I seem to have a "twist" in my orbit. Both the inclination and RAAN are off by ~0.005 deg. I've double checked against the osculating values and this is definitely not correct. The upper end of the osc inclination is 97.765deg which is what my fitted mean inclination is at. I've run the Draper propagator alongside the fit in the same code, so I've eliminated any possible errors in initial state, EOP data, reference frame, etc. When I do this, I am seeing inc values from the propagator of 97.760 deg, which is what I would be expecting. I've poured over my code and can't see where the problem is, but I'm sure its something I'm doing wrong - I just can't see it. I'm very new to both Java and Orekit so there is probably some fundamental mistake I'm making, but its not clear. Has anyone else build a Draper propagator builder? Any traps I may have fallen into that I should be wary of? Have you checked the step size of the finite difference? It is hard for the FiniteDifferencePropagatorConverter to achieve better accuracy than the finite difference step size. The step size is the scale factor for each parameter that is solved for (selected).
0.005 deg is about 1e-4 rad. So a step size of 1e-4 on an angular parameter might result in this behavior. Just a thought.
Best Regards,
Evan
One of the things I'm doing is using the FiniteDifferenceConverter and then casting it as a DSSTPropagator as follows: PropagatorConverter fitter = new FiniteDifferencePropagatorConverter(builder, 1.e-6, 5000); DSSTPropagator meanprop = (DSSTPropagator)fitter.convert(ephemeris, 86400, 251); Where "builder" is the DSSTPropagatorBuilider that I created and ephemeris is a BoundedPropagator osculating input. Is this valid? Any help, insights, pointers would be greatly appreciated. If I can get this sorted out this will be a very powerful tool for our upcoming mission. But a 0.005deg offset in inclination and RAAN will be difficult to work around. Thanks, Greg ___________________________________________________ Gregory Hammel Analyste de la dynamique de vol Contractuel SED a division of Calian Ltd. Utilisation de l’espace Agence spatiale canadienne / Gouvernement du Canada gregory.hammel@canada.ca / Tél.: 450-926-5138 Flight Dynamics Analyst Consultant SED a division of Calian Ltd. Space Utilization Canadian Space Agency / Government of Canada gregory.hammel@canada.ca / Tel.: 450-926-5138 ________________________________________ From: orekit-users-request@orekit.org <orekit-users-request@orekit.org> on behalf of MAISONOBE Luc <luc.maisonobe@c-s.fr> Sent: Thursday, July 19, 2018 2:35 PM To: orekit-users@orekit.org Subject: Re: [Orekit Users] 0.1 deg Inclination bias? "Hammel, Gregory (ASC/CSA)" <gregory.hammel@canada.ca> a écrit :Hello Luc, Thanks for this. This was actually going to be my next question - how to use LS to convert from osculating to DSST - was digging around the estimation project and was starting to run into a brick wall at the PropagatorBuilder. I didn't realize that my two problems may be actually only one. If this is the source of the problem, then what purpose does the DSSTPropagator.computeMeanState function serve? Is is intended to be a quick way to get mean states when precision isn't required?No, it is really intended to do what you want, but using only DSST models, not converting models at the same time, i.e. without a "first propagation" from another model beforehand. Some other things you could check are the difference between mean and osculating, i.e. the amplitude of the short periodic terms and the evolution rate of the mean elements, and compare this to the 0.1° you see. It may help understand what happens. best regards, LucWill give this a go. Thanks, Greg ________________________________________ From: orekit-users-request@orekit.org <orekit-users-request@orekit.org> on behalf of MAISONOBE Luc <luc.maisonobe@c-s.fr> Sent: Thursday, July 19, 2018 2:08 PM To: orekit-users@orekit.org Subject: Re: [Orekit Users] 0.1 deg Inclination bias? "Hammel, Gregory (ASC/CSA)" <gregory.hammel@canada.ca> a écrit :Hello,Hi Greg,This is my first post to this list, so I would just like to start by thanking everyone who contributes to this project. Its an incredible resource. I am trying to use Orekit for mean state generation for stationkeeping using DSST. To that end I want to take in a vector from an external source (in this case, STK) read it in, propagate it, including manoeuvres, and then use DSST to get pre and post-maneouvre mean states. If I take a J2000 vector and provide it to DSST to get a mean state, I get an inclination of 97.75 deg. However, if I first propagate that same vector and then pass it through DSST I get an inclination of 97.65 (in this case, without any manoeuvres). I'm using the same methods as outlined in the "MasterMode.java" tutorial for my "pre-mean" propagation, but I've modified it by including solar and lunar grav and DTM2000 drag. Can anyone explain why there is a 0.1 deg shift in the inclination? I can provide the code if it helps.If you convert starting from a single state vector, and change from one propagator to another one, you can have this sort of problems. I'll suggest to look at the propagation.conversion package and at the associated test cases to do the conversion from a full time range (say one or two periods) instead of a single state vector. What this package does is a fitting, trying to ensure the trajectories stay close to each other, in a least squares sense. Hope this helps, LucThanks, Greg Hammel ___________________________________________________ Gregory Hammel Analyste de la dynamique de vol Contractuel SED a division of Calian Ltd. Utilisation de l'espace Agence spatiale canadienne / Gouvernement du Canada gregory.hammel@canada.ca / Tél.: 450-926-5138 Flight Dynamics Analyst Consultant SED a division of Calian Ltd. Space Utilization Canadian Space Agency / Government of Canada gregory.hammel@canada.ca / Tel.: 450-926-5138 |