Orekit-data update giving worst reference frame conversion results

Hello everyone!

I’m using orekit through the python wrapper.
I updated my local orekit-data.zip because the one was using before it’s very old

Old version: Updated with aprill 2022 data. (3981e68c) · Commits · Orekit / Orekit Data · GitLab (19 April 2022)

New version: updated to March 2024. (4f95ffad) · Commits · Orekit / Orekit Data · GitLab (17 March 2024)

My orekit version is 11.3.3

I made some tests to check how the update of the orekit-data.zip is influencing my simulator in terms of propagation and reference frame conversion. I notice that using the new version of orekit-data.zip my results on reference frame conversion are worst.

So using the following point, which is in ECEF

Instant: 2024-05-27T09:49:26.703Z
Position: [3931.8886855634414,4882.664580844832,-2827.6958795134237]
Velocity: [-0.7393581869670774,-3.3909482489911196,-6.866712111908378]

and converting it to EME2000, using the following code

inertialFrame = FramesFactory.getEME2000()
fixedFrame = FramesFactory.getITRF(IERSConventions.IERS_2010, True)

point_date = datetime_to_absolutedate(point['Instant'])
point_position = Vector3D(point['Position'][0]*1000.0, point['Position'][1]*1000.0, point['Position'][2]*1000.0)
point_velocity = Vector3D(point["Velocity"][0]*1000.0, point["Velocity"][1]*1000.0, point["Velocity"][2]*1000.0)
ecef_tpv = TimeStampedPVCoordinates(point_date, point_position, point_velocity)
transform = fixedFrame.getTransformTo(inertialFrame, point_date)
tpv = transform.transformPVCoordinates(ecef_tpv)

Using the old version of orekit-data.zip tpv is:

{2024-05-27T09:49:26.703, P(686544.8029968282, 6230440.403643706, -2829539.651928883), V(727.5319561418162, -3206.94615903976, -6868.339932521091), A(0.4713588457669586, 0.1416019228785583, -0.0011184269861723862)}

Using the new version of orekit-data.zip, tpv is:

{2024-05-27T09:49:26.703, P(686561.8282723054, 6230434.173183345, -2829549.239950467), V(727.5357752399009, -3206.959040348474, -6868.332656847968), A(0.4713608150897179, 0.14160244422760146, -0.0011184316565229246)}

The difference in range between the two points is around 20m
Here a screen shot on STK for better visualization

Could be something related to the orekit version and orekit-data verison? Like certain orekit-data versions only work properly for certain orekit versions?

If your input data is in Earth frame, then you need to have proper Earth Orientation Parameters to convert it to inertial frame, so yes, you must update your orekit data regularly as EOP clearly cannot be predicted two years in advance.

The orekit-data folder provided by the Orekit team is only a starting point, it is users responsibility to update the content. there is an update.sh script that does it, you can run it whenever you want, even each day if you want up to date data.

Hi @jpedro500,

What do you mean by “worst”? Do you have any reference to check against?
As Luc said the Earth Orientation Parameters must be regularly updated. If you use EOP from 2022 to estimated an Earth-based transform in 2024, you will actually get worst results than when using an EOP from 2024 :wink:

@luc @MaximeJ
What I mean by “worst” is that:~

When I use an old version of orekit-data.zip to convert it to EME2000 frame and I plot it for example on STK, I get the exact same points overlapped
When I use the newest version of orekit-data.zip and I plot it on STK, this point is not exactly overlaped with the ECEF point.

But I’m thinking now that probably I need also to update the EOP on STK as well
Thank you for making me notice this

2 Likes

Hello @luc!
I’m using the update.sh to update the orekit-data folder daily

I get these ‘failed’ prints when I run it


fetching URL
https://maia.usno.navy.mil/ser7/tai-utc.dat…
done
fetching URL
https://datacenter.iers.org/data/9/finals2000A.all…
done
fetching URL
https://datacenter.iers.org/data/7/finals.all…
done
fetching URL
https://www.nasa.gov/wp-content/uploads/2024/04/apr2024f10-prd.txt…
done
apr2024f10-prd.txt is complete
fetching URL
https://www.nasa.gov/wp-content/uploads/2024/05/may2024f10-prd.txt…
done
may2024f10-prd.txt is complete
fetching URL
https://www.nasa.gov/wp-content/uploads/2024/06/jun2024f10-prd.txt…
done
jun2024f10-prd.txt is complete
fetching URL
https://www.nasa.gov/wp-content/uploads/2024/07/jul2024f10-prd.txt…
failed!
fetching URL
https://www.nasa.gov/wp-content/uploads/2024/07/jul2024f10_prd.txt…
failed!
fetching URL
https://www.nasa.gov/wp-content/uploads/2024/07/jul2024f10.txt…
failed!
fetching URL
https://www.nasa.gov/wp-content/uploads/2024/06/jul2024f10-prd.txt…
failed!
fetching URL
https://www.nasa.gov/wp-content/uploads/2024/06/jul2024f10_prd.txt…
failed!
fetching URL
https://www.nasa.gov/wp-content/uploads/2024/06/jul2024f10.txt…
failed!
fetching URL
https://www.nasa.gov/wp-content/uploads/2024/08/jul2024f10-prd.txt…
failed!
fetching URL
https://www.nasa.gov/wp-content/uploads/2024/08/jul2024f10_prd.txt…
failed!
fetching URL
https://www.nasa.gov/wp-content/uploads/2024/08/jul2024f10.txt…
failed!
fetching URL
https://www.nasa.gov/wp-content/uploads/2024/05/jul2024f10-prd.txt…
failed!
fetching URL
https://www.nasa.gov/wp-content/uploads/2024/05/jul2024f10_prd.txt…
failed!
fetching URL
https://www.nasa.gov/wp-content/uploads/2024/05/jul2024f10.txt…
failed!
fetching URL
https://www.nasa.gov/wp-content/uploads/2024/09/jul2024f10-prd.txt…
failed!
fetching URL
https://www.nasa.gov/wp-content/uploads/2024/09/jul2024f10_prd.txt…
failed!
fetching URL
https://www.nasa.gov/wp-content/uploads/2024/09/jul2024f10.txt…
failed!
fetching URL
https://www.nasa.gov/wp-content/uploads/2024/04/jul2024f10-prd.txt…
failed!
fetching URL
https://www.nasa.gov/wp-content/uploads/2024/04/jul2024f10_prd.txt…
failed!
fetching URL
https://www.nasa.gov/wp-content/uploads/2024/04/jul2024f10.txt…
failed!
fetching URL
https://www.nasa.gov/wp-content/uploads/2024/10/jul2024f10-prd.txt…
failed!
fetching URL
https://www.nasa.gov/wp-content/uploads/2024/10/jul2024f10_prd.txt…
failed!
fetching URL
https://www.nasa.gov/wp-content/uploads/2024/10/jul2024f10.txt…
failed!
fetching URL
https://www.nasa.gov/wp-content/uploads/2024/03/jul2024f10-prd.txt…
failed!
fetching URL
https://www.nasa.gov/wp-content/uploads/2024/03/jul2024f10_prd.txt…
failed!
fetching URL
https://www.nasa.gov/wp-content/uploads/2024/03/jul2024f10.txt…
failed!
fetching URL
https://www.nasa.gov/wp-content/uploads/2024/11/jul2024f10-prd.txt…
failed!
fetching URL
https://www.nasa.gov/wp-content/uploads/2024/11/jul2024f10_prd.txt…
failed!
fetching URL
https://www.nasa.gov/wp-content/uploads/2024/11/jul2024f10.txt…
failed!
fetching URL
https://www.nasa.gov/wp-content/uploads/2019/04/jul2024f10-prd.txt…
failed!
fetching URL
https://www.nasa.gov/wp-content/uploads/2019/04/jul2024f10_prd.txt…
failed!
fetching URL
https://www.nasa.gov/wp-content/uploads/2019/04/jul2024f10.txt…
failed!
fetching URL
https://www3.nasa.gov/sites/default/files/atoms/files/jul2024f10-prd.txt…
done
jul2024f10-prd.txt removed (fetched only a 404 error page)
fetching URL
https://www3.nasa.gov/sites/default/files/atoms/files/jul2024f10_prd.txt…
done
jul2024f10_prd.txt removed (fetched only a 404 error page)
fetching URL
https://www3.nasa.gov/sites/default/files/atoms/files/jul2024f10.txt…
done
jul2024f10.txt removed (fetched only a 404 error page)
fetching URL
ftp://ftp.agi.com/pub/DynamicEarthData/SpaceWeather-All-v1.2.txt…
done

Are these ‘fails’ normal? What is the root cause for it?

Yes, the fails are normal.
The MSAFE urls have an history of variations, with either the top level server changing, or the suffix changing, or the ‘-’ being replaced by ‘_’. So the script attempts for each month several URL combinations, and it increments the month. The loop stops when for one given month all the attempts with all known variations of the name fail, then it considers this month has not been published yet. So you end up with lots of messages in the console. The files that are removed correspond mainly to the 404 error html page that is returned by the server when attempting to download one url that does not exist, so this is safe.

2 Likes