FAQ » History » Version 8

« Previous - Version 8/33 (diff) - Next » - Current version
Michael Turner, 2012-10-26 12:47
minor grammar error


h1. FAQ

{{TOC}}

h2. References

h3. Has Orekit already been used?

Yes, it has been used in successful operational missions.

The most prominent use of Orekit was for the Automated Transfer Vehicle (ATV) mission to the International Space station (ISS). Orekit was used operationally during the real-time monitoring of the rendezvous phase up to the docking. It continuously recomputed the relative geometry of the two spacecraft using different sensors output to check its consistency.

CNES (the French space agency) has also selected Orekit and Apache Commons Math in early 2011 as the base building blocks for its next-generation space flight dynamics systems, including operational systems, study systems and mission analysis systems

h2. Validation

h3. Is Orekit validated?

Some parts are strongly validated, others are validated to a lesser extent.

  • The frames package is one of the best validated ones. The overall mechanism (transforms, navigation between frames, kinematics ...) has really been challenged a lot, both in theoretical tests and during real life operations. This part was extensively used for Automated Transfer Vehicle (ATV) rendezvous with the International Space Station (ISS). It was part of an operational ground program performing real-time monitoring of the rendezvous and docking phase. This part has been checked to below the millimeter-level precision for relative configuration. The reference frames part (ITRF and the like) has been validated using public data down to meter-level precision for version 3.1, and to centimeter-level for version 4.0.
  • A new round of validation was done after Orekit 3.1 was published. Two defects were identified and fixed: the J2000 frame was misaligned with real J2000 by a constant rotation bias of about 18 milliarcsceonds (it was really GCRF, not J2000) and the ITRF2000B implementation was wrong by a time-dependent rotation leading to about 0.6 meters error for orbits with a semi-minor axis of about 10000km. These errors have been fixed as of version 4.0. Our tests show the new frames are compliant with reference cases to about 10mm for LEO and 60mm for GEO.
  • The TLE package is also quite well validated; it has been checked against some reference data published by Vallado along with his revision of the original spacetrack report, where he fixed some errors in the original Fortran implementation from NORAD.
  • The atmosphere models have also been validated the same way, using published data.
  • The time package has been validated by its unit tests only, but since the behavior is simpler it can be checked by hand. The unit tests include a lot of borderline cases (for example behavior during the introduction of a leap second).
  • The Sun and Moon classes for version 3.1 are very low precision and are defined in a pseudo-inertial frame with loose definition. They can be compared only with very specific software. Their accuracy is probably limited to about 10 arcseconds. They have been replaced by accurate reference models in the version 4.0.
  • The least validated part is the numerical propagation. Only rough validation has been done so far. Precise validation requires a good model for Sun, so it has been postponed until this model can be re-implemented.

Validation is a continuous task for us, we are always working on improving it. We would be happy to also have other teams perform independent validation runs. We have already received some feedback and new test cases after the first version was published.

h2. Installation

h3. Where can I find the source code repository ?

h3. When I try to compile orekit, maven cannot find commons-math 2.0-SNAPSHOT. Where is it ?

Up to version 4.0, Orekit depended on features of Apache Commons Math which were not released as of mid 2008, so the dependency was set to 2.0-SNAPSHOT development version.
This development version was available from the Apache subversion repository. Starting with version 4.1, Orekit depends only on released versions of Apache Commons Math:

  • Orekit 4.1 depends on version 2.0 of Apache Commons Math.
  • Orekit 5.0 depends on version 2.1 of Apache Commons Math.
  • Orekit 5.1 depends on version 2.2 of Apache Commons Math.
  • Orekit 6.0 will dépend on version 3.0 oc Apache Commons Math.

h3. The orekit-data.zip file you provide is not up to date. Can you update it ?

There is no regular update for this file. Data are provided only as an example, to allow quick start for new users. For long-term use, data handling remains their own responsibility. The configuration page points out the data sources that can be taken into account by Orekit, so you can go visit that link to look for what you need.

Some difficulties may yet occur for very recent data. Indeed, the IERS once again changed its file formats and stopped publishing the B Bulletins (see Earth Orientation Data page). As an example, the last IAU 2000 B Bulletin published is number 263. The annual data (EOP 05 C04 file) are still published. We advise then that you add to the zip archive the annual file covering the whole year 2010 and the annual file covering the beginning of year 2011. You will then need to update that annual file regularly as the IERS fills it.

Concerning UTC leap seconds, as of early 2012, the last one was introduced on December 31st, 2008 and the next one will be introduced at the end of June 2012.

h2. Runtime errors

h3. I get an error "no utc-tai history data loaded" (or something similar in a another language). What does it mean ?

This error is probably the most frequent one, or at least it's the first one new users encounter.

Orekit needs some external data to be loaded in order to run. This includes UTC-TAI history for leap seconds handling, Earth Orientation Parameters for transforms to and from Earth fixed frames, or planetary ephemerides for Sun direction, for example.

The error message "no utc-tai history data loaded" means the UTC-TAI history file which is used for leap seconds management was not found. As leap seconds are used each time a UTC date is used, this message is often seen very early and is the first one unsuspecting users experience. It often means the user forgot to configure Orekit to load data.

Configuring data loading is explained in the configuration page For a first start, the simplest configuration is to download the orekit-data.zip file from the "download":https://www.orekit.org/forge/projects/orekit/files page and to either set the "orekit.data.path" Java property to this file or to manually configure the @DataProvidersManager@ to use it. This example archive file contains the required UTC-TAI history file among others. Configuring Orekit to use this archive file can be done by keeping the file as a zip archive and pointing to this archive, or by unzipping it and pointing to the unzipped folder.

Here is an example using the file in zip format:

DataProvidersManager.addProvider(new ZipJarCrawler(new File("/path/to/the/zip/file/orekit-data.zip")));

Here is an example using the folder resulting from expanding the archive:

DataProvidersManager.addProvider(new DirectoryCrawler(new File("/path/to/the/folder/orekit-data")));

Using a folder allows one to change the data in it, e.g., adding new EOP files as they are published by IERS.