That's why I was surprised that with 60 second max step size at GEO that I was getting the problem when reporting out at 180 second intervals. Let me try bundling up in something to share....
Sent from my Android phone
Hi Hank,
Le 12/06/2015 01:19, Hank Grabowski a écrit :
> I'm using DP853 with 1e-12 tolerance with min step size of 0.001 and max
> of 3600. This reminds me, am I missing it or is there no way to get the
> actual table of states from the propagator?
You can get some hints in master mode. The interpolator that the
propagator will provide to you at each step is always consistent with
the integrator you use. In fact there is a specific interpolator
associated with each integrator class in Apache Commons Math
(DormandPrince853Integrator/DormandPrince853StepInterpolator,
LutherIntegrator/LutherStepInterpolator,
GraggBulirschStoerIntegrator/GraggBulirschStoerStepInterpolator ...).
Unfortunately the interpolator do not provide public API to their
states. What they do provide however is that each time you call
setInterpolatedTime/getInterpolatedState they really use the integrator
internal state to perform their intermediate evaluation. Internally,
they directly refer to the integrators arrays.
Do you have a short standalone program that we could run here to
understand what happens?
best regards,
Luc
>
> On Thu, Jun 11, 2015 at 5:57 PM, Evan Ward <evan.ward@nrl.navy.mil
> <mailto:evan.ward@nrl.navy.mil>> wrote:
>
> Hi Hank,
>
> I ran in to something vaguely similar to this today. I was trying to
> get the state every minute using a propagator in slave mode. It
> seems that the internal state of the integrator is not preserved
> across calls to propagate. So for every call to propagate the
> integrator step sizes ended up as 0.1, 1, 10, 47.9 seconds. I ended
> up switching to ephemeris mode to avoid the unnecessary oscillations
> in the step size. Though after I made the switch I saw less than 1mm
> difference in the ephemeris. What is your tolerance setting for the
> propagator? I used very tight tolerances, 1e-7, and the DP853
> integrator.
>
> Regards,
> Evan
>
>
> On 06/11/2015 05:34 PM, Hank Grabowski wrote:
>> Hello all,
>>
>> I'm in the process of doing a full up propagator V&V of the Orekit
>> library. It's mostly gone very well but I hit a couple of snags
>> today. One snag is with the BoundedPropagator that gets returned
>> by the getEphemeris. I essentially generate an ephemeris in two
>> ways. The first way is to manually walk over the propagation time
>> using the propagate method on the actual propagator. The second
>> way is to run the propagation from the beginning to the end in one
>> fell swoop and then to iterate over the generated ephemeris to
>> generate the lookup file. I do this for a HEO, GEO, and a LEO
>> orbit using various force model settings. When I do this with an
>> earth point mass setting the raw integrated and interpolated
>> ephemeris match to within 3e-4 meters at GEO after 15 days. I'm
>> very happy with that. If I do it with an EGM96 70x70 gravity
>> field however the solution over time gets worse and worse,
>> ultimately being 2 meters off 15 days later. This happens
>> regardless of the max step size I give the integrator. I even set
>> it to 60 seconds and reported out the ephemeris using the
>> generated ephemeris at 180 seconds. The error seems to be
>> consistent across those settings. The other orbit regimes have a
>> similar problem.
>>
>> I am going to investigate this further but I figured I'd put this
>> out there in case someone had a suggestion for why it would be
>> happening and how one would address it.
>>
>> Hank
>
>