Re: [Orekit Developers] Problem with getPVCoordinates?

[Luc Maisonobe <Luc.Maisonobe@c-s.fr>]

Le 26/01/2017 à 15:01, Evan Ward a écrit :
> Alessandro,
> 
> If you use the following line instead do you still see the problem?
> 
> Frame earthFrame = FramesFactory.getITRF(IERSConventions.IERS_2010, false);
> 
> My guess is that the difference has to do with how Orekit caches and
> interpolates EOP data to speed computation. Using simple EOP is roughly
> equivalent to cm level accuracy in LEO. Hopefully Luc can chime in with
> error levels introduced by interpolating and shifting the frame
> transformations, but in one case I only noticed differences at the mm
> level.

I agree with Evan, this should be related to caching.

Transforms between inertial frames and topocentric frames involve a lot
of computation, mainly in the nutation models (IERS conventions 2010 use
the big MHB 2000 nutation with thousands of Poissons series). As
this computation is huge, Orekit uses a caching mechanism to save
resources. A few reference points are computed (for nutation, 6 points
each separated one hour are used, but the initial fill of the cache
needs a few additional points), and when intermediate dates are needed,
interpolation is used. This means a full computation of the nutation
model is performed only once for every hour of simulation, not once
for each computation step. This is a huge performance gain. The
drawback is that we introduce sampling and interpolation error.

when Orekit starts, the cache is empty and filled up lazily at the
first call, and the exact time of the points will depend on the
first date used.

I have just added a print statement in the getTransform method
in CIRFProvider and have run your code, with and without commenting
out the first call. In one case, the CIRF provider is called with
sample points at the following dates to fill the cache:

   2000-01-01T11:58:55.816
   2000-01-01T12:58:55.816
   2000-01-01T13:58:55.816
   2000-01-01T14:58:55.816
   2000-01-01T15:58:55.816
   2000-01-01T16:58:55.816
   2000-01-01T10:58:55.816
   2000-01-01T09:58:55.816
   2000-01-01T08:58:55.816

In the other case, the sample points for the initial cache filling are:

   2000-01-01T11:58:56.816
   2000-01-01T12:58:56.816
   2000-01-01T13:58:56.816
   2000-01-01T14:58:56.816
   2000-01-01T15:58:56.816
   2000-01-01T16:58:56.816
   2000-01-01T10:58:56.816
   2000-01-01T09:58:56.816
   2000-01-01T08:58:56.816

You can notice these dates are shifted one second with respect to the
other case.

The fact we don't use exactly the same reference points explains the
interpolation will give slightly different results (here at nanometer
level).

The sampling rate as been carefully chosen so interpolation error
is very law. It is much lower than the accuracy of the models
themselves. You can look for example at the unit test
testShiftingAccuracyWithEOP in CIRFProviderTest. The selected
interpolation for CIRF (6 points separated one hour) leads to an
interpolation error smaller than 4.6e-12 radians, which is about
0.03mm at Earth surface. What you observe is even far below this
error.

Hope this helps,
Luc

> 
> Best Regards,
> Evan
> 
> On 01/26/2017 07:54 AM, alessandro.vananti@aiub.unibe.ch wrote:
>> I have a problem with the following code.
>>
>> Frame inertialFrame = FramesFactory.getEME2000();
>> GeodeticPoint station = new GeodeticPoint(Math.toRadians(40),
>> Math.toRadians(0), 0);
>> Frame earthFrame = FramesFactory.getITRF(IERSConventions.IERS_2010,
>> true);
>> BodyShape earth = new
>> OneAxisEllipsoid(Constants.WGS84_EARTH_EQUATORIAL_RADIUS,
>> Constants.WGS84_EARTH_FLATTENING, earthFrame);
>> TopocentricFrame staF = new TopocentricFrame(earth, station, "station");
>>
>> staF.getPVCoordinates(AbsoluteDate.J2000_EPOCH, inertialFrame);   //
>> line to
>> comment out
>>
>> System.out.println(staF.getPVCoordinates(AbsoluteDate.J2000_EPOCH.shiftedBy(1),
>>
>> inertialFrame).getPosition().getX());
>>
>>
>> When I run it I get as a result: 866163.3982467309
>> If I comment out the line
>> "staF.getPVCoordinates(AbsoluteDate.J2000_EPOCH,
>> inertialFrame);" then I get as a result 866163.3982467302.
>> So the last digit is different. How is it possible?
>>
>> Alessandro