About Orekit And STK

[tang]

Hello everyone,

We are trying to align Orekit KeplerianOrbit with respect to STK TwoBody.
We are running a 1 days propagation,But the results varied widely.

public static void main(String args) {
DataProvidersManager manager = DataContext.getDefault().getDataProvidersManager();
manager.addProvider(new DirectoryCrawler(new File(“E:/Orekit”)));

    double a = 6678137;
    double e = 0;
    double i = 45;
    double pa = 0;
    double raan = 0;
    double anomaly = 0;
    PositionAngleType type = PositionAngleType.MEAN;
    Frame frame = FramesFactory.getEME2000();
    AbsoluteDate date = new AbsoluteDate(2023, 01, 01, 0, 0, 0, TimeScalesFactory.getUTC());
    AbsoluteDate end = new AbsoluteDate(2023, 01, 02, 0, 0, 0, TimeScalesFactory.getUTC());
    int step = 60;

    final KeplerianOrbit orbit = new KeplerianOrbit(a, e, FastMath.toRadians(i), FastMath.toRadians(pa), FastMath.toRadians(raan), FastMath.toRadians(anomaly), type,
            frame, date, Constants.WGS84_EARTH_MU);

    KeplerianPropagator propagator = new KeplerianPropagator(orbit);

    final Frame earthFrame = CelestialBodyFactory.getEarth().getBodyOrientedFrame();
    ReferenceEllipsoid wgs84 = ReferenceEllipsoid.getWgs84(earthFrame);

    for (AbsoluteDate start = date;
         start.compareTo(end) <= 0;
         start = start.shiftedBy(step)) {
        SpacecraftState spacecraftState = propagator.propagate(start);
        Vector3D position = spacecraftState.getPVCoordinates().getPosition();
        GeodeticPoint geodeticPoint = wgs84.transform(position, frame, date);
        System.out.printf("date：%s, lon:%.3f, lat:%.3f, alt:%.3f\n", start, FastMath.toDegrees(geodeticPoint.getLongitude()), FastMath.toDegrees(geodeticPoint.getLatitude()), geodeticPoint.getAltitude() / 1000);
    }
}

Thanks！

[bcazabonne]

Hi @tang

Welcome to the Orekit forum

Just to understand better the problems, what are the columns of the file?
It looks to be the results of the printf but I see 7 columns in the file instead of 8 parameters in the function.

Also, are lon, lat, and alt the values from STK?

Thanks,
Bryan

[tang]

Hi Bryan
Thanks for answering my question.
Results from STK

24h Orekit KeplerianPropagator results

Thanks,
tang

[luc]

It seems you have a confusion between frames.
If you look at the longitude evolution in STK with respect to Orekit you will notice that in STK, for the 34 minutes between 23:26 and 00:00, longitude goes from 95.786° to -125.778° hence it decreases by 221.564°. When looking at Orekit results, it goes from 88.326° to -124.715° hence it decreases by 213.041°. The difference in rates between the two programs is 8.523° in 34 minutes, which is 359.988° in 86164s, pretty close to Earth rotation rate.

I guess you are mixing Earth and inertial frames somewhere, but not in an obvious way. As your STK input parameters refer to coordinates epoch at J2000.0 epoch, maybe there is something wrong there.

[luc]

Another point: CelestialBodyFactory.getEarth().getBodyOrientedFrame() is clearly not a good Earth frame to use, it does not include any EOP. You should use an ITRF frame if you want correct results.

[tang]

Thanks for answering my question, I am a beginner and want to calculate orbital propagation with a simple configuration, the results need to be consistent with STK.

I try to use ITRF frame, the result is not consistent, is there a simple way of authentication in Orekit / Orekit · GitLab

[luc]

There are often two types of frames used simultaneously in space flight dynamics.
The first type is inertial frames, i.e. frames whose axes are fixed with respect to the universe, in other words not rotating. Orbits are defined using these frames as they are the ones in which physics computation are simpler.
The second type is body oriented frames, i.e. frames whose axes are fixed with respect to the central body, in other words rotating with respect to the universe as the central body, Earth in many cases, rotates at roughly one turn per day. Coordinates with respect to the Earth like longitude and latitude are expressed in these frames as they correspond to the concerns people have when they design a space mission that is related to Earth. What adds a lot of complexity to this is that Earth rotation is not regular, so when computing the transformation between inertial and terrestrial frame, you have to load the so-called Earth Orientation Parameters (EOP) to take this into account. This is done transparently for you by both Orekit and STK, but you have to be sure you have the appropriate data available otherwise comparing anything in Earth frame will exhibit discrepancies between the two results. This is not what you are seeing in your results above, the errors you see are far above the level of inconsistent EOP, what you see is something related to Earth not rotating at all in the STK case (I guess). Perhaps one thing you could do is play with the “Coord Epoch” setting? Is there only one global setting for this or one for the input coordinates and one for the output coordinates?

We almost always need both frames and must take care to use the proper one in the proper context, so you have to think about it. In most cases, Orekit will prevent you to use a non-inertial frame to define an orbit (it will trigger an exception except if you use AbsolutePVCoordinates which I do not recommend as it is reserved for expert use). Just stick with regular KeplerianOrbit, CircularOrbit or CartesianOrbit to remain safe.
I would suggest you to start using only inertial frame (like EME2000, which is often called J2000 and in particular in STK) and to compare Cartesian coordinates first. Then, when you have found compatible configurations, you can add the inertial/Cartesian to terrestrial/geodetic coordinates at current epoch (not at a fixed epoch) and check if it still matches.
Both STK and Orekit are validated, even in much more sophisticated cases, with lots of perturbations, so the Kepler case should certainly give comparable results far below milli-degrees.

[tang]

Thank you so much for your assistance.