Orekit unable to parse "DistanceUnit" parameter for STK ephemeris files

Hello, our team is attempting to integrate Orekit into our Java application and utilize the STKEphemerisFileParser class to ingest an incoming STK .e ephemeris file. When we attempt this, we’re noticing that including the optional “DistanceUnit” parameter in the file metadata causes Orekit throw an Orekit exception:

org.orekit.errors.OrekitException: unable to parse line 9 of file temp702168476126669949.tmp:
DistanceUnit 	 Kilometers

As far as I can tell, this should be a valid parameter to define in STK ephemeris files and I believe we’re formatting the file itself correctly, so I’m wondering if anyone else has come across this and let me know if I’m missing something. Removing the “DistanceUnit” parameter form the file will allow the parser to run successfully.

Here’s the raw example file I’m using:

stk.v.12.0
BEGIN Ephemeris
NumberOfEphemerisPoints		 1
ScenarioEpoch		 01 Jan 2000 12:00:00.000000
InterpolationMethod		 Lagrange
InterpolationSamplesM1		 7
CentralBody		 Earth
CoordinateSystem		 J2000
DistanceUnit 	 Kilometers
EphemerisTimePosVel		
0.0000000000000000e+00  1.0000000000000000e+03  2.0000000000000000e+03  3.0000000000000000e+03  1.0000000000000000e+00  2.0000000000000000e+00  3.0000000000000000e+00
END Ephemeris

And for reference, we’re currently using Orekit 13.1.12 and pulling it from the Maven repository. Any insight would be appreciated!

Hi @ejfernandez,

Welcome to the forum!

Is there a specification somewhere on the format of STK ephemeris files ? It could be a nice addition to Orekit documentation.

STKEphemerisFileParser in Orekit clearly states that:

The STK ephemeris file format specification is quite extensive and this implementation does not attempt (nor is it possible, given the lack of an STK scenario to provide context) to support all possible variations of the format.

However, DistanceUnit keyword should be handled, so you likely found a bug. Thank you for this! Could you please open an issue on the forge ?

I believe adding LineParser.DISTANCE_UNIT, after LineParser.COORDINATE_SYSTEM, in atributes KEYWORDS in STKEphemerisFileParser fixes the issue.

While investigating, I made a test for STKEphemerisFileParserTest based on your example:

  /** Test that parsing the keyword "DistanceUnit" does not cause an exception.
   * See issue XXX
   */
  @Test
  public void testIssueXXXParseDistanceUnit() {

    final String content = "stk.v.12.0\n" +
            "BEGIN Ephemeris\n" +
            "NumberOfEphemerisPoints 1\n" +
            "ScenarioEpoch 01 Jan 2000 12:00:00.000000\n" +
            "InterpolationMethod Lagrange\n" +
            "InterpolationSamplesM1 7\n" +
            "CentralBody Earth\n" +
            "CoordinateSystem J2000\n" +
            "DistanceUnit Kilometers\n" +
            "EphemerisTimePosVel\n" +
            "0.0000000000000000e+00  1.0000000000000000e+03  2.0000000000000000e+03  3.0000000000000000e+03  1.0000000000000000e+00  2.0000000000000000e+00  3.0000000000000000e+00\n" +
            "END Ephemeris";

    final DataSource source = new DataSource("inline", () -> new StringReader(content));
    final String satelliteId = "00000";
    final EnumMap<STKCoordinateSystem, Frame> frameMapping = new EnumMap<>(STKCoordinateSystem.class);
    final Frame frame = FramesFactory.getEME2000();
    frameMapping.put(STKCoordinateSystem.J2000, frame);
    final STKEphemerisFileParser parser = new STKEphemerisFileParser(satelliteId, MU, UTC, frameMapping);
    Assertions.assertDoesNotThrow(() -> parser.parse(source));
  }

Would you like to contribute the fix ? :wink:
If yes:

  • Replace “XXX” in the test with the issue number
  • Do the merge request starting from branch main or release-13.1 and targeting branch patch-13.1.5, so that it can be integrated in the next patch!

Cheers,
Maxime

1 Like

STK’s documentation on their ephemeris file format is a bit hard to find, as you likely know. The closest I’ve ever been able to find is the following STK Components Javadocs for the StkEphemerisFile class: StkEphemerisFile | DME Component Libraries for Java 2025 r2 . However, even they state in the docs that they can’t guarantee full compatibility compared to STK proper. It does though at least list out a number of properties that are supported - and conversely can appear in STK ephemeris files - some of which aren’t present in the list of KEYWORDS in that link you provided.

I don’t have any issues with contributing to the fix, but it wouldn’t happen anytime soon unfortunately. Our team has some major events coming up in next 2 months that we’re prepping for so I won’t have any time to work this in the near term. I’ll try to check back in a couple of weeks if I manage to get some free time and reevaluate then.

Regardless, thank you for responding to this. We have a workaround for this particular issue so it’s not a major blocker for us, but it’s something we’ve noticed since a while ago. I’ll continue to keep my eye on things here and check back in once things start to lighten up.

1 Like