Hi everyone, our research group has recently found some discrepancies between Orekit-obtained results and STELA-obtained results.
For example, a payload with a mass of 260 kg, an area (drag&reflective) of 30 m^2, a reflectivity coeff of 0.5, a constant drag coeff of 2.2, mean parameter propagation in the EME2000 frame from 2024-11-19T14:11:58.709 and with an initial orbit defined by a=6878 km, e=0.001, i=30º, RAAN=aop=mean anomaly=0º. For this test we use a DSST integrator with 24h step, with atmospheric drag (NRLMSISE-00 atmospheric model), sun radiation pressure (mean constant solar activity), sun & moon third-body perturbations, zonal and tesseral (order 7) Earth gravity perturbations and reentry at 150 km.
For this scenario the STELA simulation deorbits in around 0.18 years while Orekit takes around 0.22 years, which is a big percentual difference. Could this be due to a known issue with Orekit or is it rather more probable that there is an issue with our implementation?
First of all, I’d say that reentry predictions are highly sensitive to simulation parameters, especially the atmospheric density prediction/history. So even with a given software, you’d get a wide range of different outputs by changing those. For example with Orekit, the NRLMSISE model can be initialized in different ways, using MFASE or CSSI.
Are you defining your initial orbit with osculating elements? If not they are DSST mean and are different to the ones used by STELA.
Last remark, your integration step is probably a bit big. Use a few orbital periods instead of 24h in LEO.
Hi, thanks for your response, it was very helpful.
I forgot to mention it on the original post, but the parameter definition in both Stela (initial state) and Orekit (initial state and propagation) was done with PropagationType.MEAN. We tried changing the initial state PropagationType to osculating and it was indeed slightly closer to the results we got on STELA. However, we do not know why, since STELA states that you select the nature of the initial parameters and we chose MEAN in both cases. Could you please go into more detail on why that mismatch happens?
We tried using both CssiSpaceWeatherData and MarshallSolarActivityFutureEstimation for the weather data source (NRLMSISE00), and the second option seemed to return results that are slightly more similar to STELA (but we do not really know why, since the source of STELA is never mentioned as far as we know). We also tried changing the iteration step as you suggested, but it didn’t quite solve the issue, although we see how it could have been the cause.
Lastly, we wanted to underline that even though the deorbit time is an important metric, we are more concerned by the fact that there are differences in the semi-major axis as big as 10 km only 30 days into the simulation.
I would suggest you start with a simple force model (Keplerian gravity + drag) on both sides and then add up perturbations one by one. To see where the difference may come from.
If I’m not wrong, for Stela you need to edit by hand the file containing the solar activity. I’m not sure where the default values come from.
As for the type of initial orbit, osculating basically means that they correspond to a given position velocity vector in a specific inertial frame. If you use anything else, you need to make sure that after converting them to osculating (pointwise or by smoothing on a time interval) they give you more or less the same PV vector.
On another note, for non gravitational forces like drag, semi analytical models like DSST and Stela handle them by using quadratures (basically you don’t have analytical expressions to take them into account in the mean differential equations so you use a numerical approximation). This operation relies on some parameters such as the number of points per orbit. Orekit (and Stela I guess) use default values for that if you don’t pass custom ones. Try to see if you can use the same settings.
As Maxime said, go back to no perturbations and see if incrementally you can align the two propagators.