I am currently using V12.2.1 and encountered an error regarding to MarshallSolarActivityFutureEstimation.getAverageFlux(). It throws MathIllegalArgumentExceptıon: -0 out of [0,1] range and it points to PolynomialSplineFunction.value().
I am trying to update the spacecraft state in future time and back propagating it to the current time by some iterations. I was dealing with a cartesian orbit at epoch 07.04.2025. I tought that it might be caused by the incosistency between MSAFE time span and state epoch because I am propagating it to one year and back. Yet, my orekit data is already up-to-date and I checked the MSAFE time span which is covering the dates that my analysis is running. I tried to change the FluxLevel from STRONG to AVERAGE and it worked during for few iterations and than it throw the same error.
How can I avoid this error or what is the root cause is there any idea?
Thanks in advance,
Exception in thread "main" org.hipparchus.exception.MathIllegalArgumentException: -0 out of [0, 1] range
at org.hipparchus.util.MathUtils.checkRangeInclusive(MathUtils.java:356)
at org.hipparchus.analysis.polynomials.PolynomialSplineFunction.value(PolynomialSplineFunction.java:137)
Caused by: org.hipparchus.exception.MathIllegalArgumentException: -0 out of [0, 1] range
at org.orekit.models.earth.atmosphere.data.MarshallSolarActivityFutureEstimation.getAverageFlux(MarshallSolarActivityFutureEstimation.java:366)
at org.orekit.models.earth.atmosphere.NRLMSISE00.getDensity(NRLMSISE00.java:1179)
at org.orekit.forces.drag.DragForce.acceleration(DragForce.java:90)
at org.orekit.forces.ForceModel.addContribution(ForceModel.java:120)
at org.orekit.propagation.integration.AbstractIntegratedPropagator$Main.computeDerivatives(AbstractIntegratedPropagator.java:979)
at org.orekit.propagation.integration.AbstractIntegratedPropagator$ConvertedMainStreamEquations.computeDerivatives(AbstractIntegratedPropagator.java:810)
at org.hipparchus.ode.ExpandableODE.computeDerivatives(ExpandableODE.java:134)
at org.hipparchus.ode.nonstiff.ExplicitRungeKuttaIntegrator.applyInternalButcherWeights(ExplicitRungeKuttaIntegrator.java:131)
at org.hipparchus.ode.nonstiff.EmbeddedRungeKuttaIntegrator.integrate(EmbeddedRungeKuttaIntegrator.java:241)
at org.orekit.propagation.integration.AbstractIntegratedPropagator.integrateDynamics(AbstractIntegratedPropagator.java:509)
I’m pretty sure a colleague of mine has already come across that exception too. Unfortunately they couldn’t reproduce it so we didn’t investigate further but I’m definitely interested.
Would you be able to work out a code example for people here to run?
Sorry for my late response, I have produced the initial orbital elements and corresponding force models, numerical integrator and all the other configurations,
at below, you can find the code snippet:
double x = -4475821.133966731;
double y = 797606.6407738312;
double z = -5414155.302645127;
double vx = 5805.4373316227014;
double vy = 639.0828204599451;
double vz = -4708.359751218741;
Vector3D p = new Vector3D(x,y,z);
Vector3D v = new Vector3D(vx,vy,vz);
Frame ecef = FramesFactory.getITRF(IERSConventions.IERS_2010,false);
Frame eci = FramesFactory.getEME2000();
double mu = Constants.WGS84_EARTH_MU;
AbsoluteDate initialDate = new AbsoluteDate("2025-04-14T01:18:39.34508452322439Z", TimeScalesFactory.getUTC());
AbsoluteDate backPropagationDate = new AbsoluteDate("2025-04-14T00:00:00.000Z",TimeScalesFactory.getUTC());
TimeStampedPVCoordinates pvt = new TimeStampedPVCoordinates(initialDate,p,v);
CartesianOrbit initialOrbit = new CartesianOrbit(pvt,eci,mu);
SpacecraftState initialState = new SpacecraftState(initialOrbit,1036.739911);
CelestialBody sun = CelestialBodyFactory.getSun();
MarshallSolarActivityFutureEstimation msfe = new MarshallSolarActivityFutureEstimation(MarshallSolarActivityFutureEstimation.DEFAULT_SUPPORTED_NAMES, MarshallSolarActivityFutureEstimation.StrengthLevel.STRONG);
OneAxisEllipsoid earth = new OneAxisEllipsoid(Constants.WGS84_EARTH_EQUATORIAL_RADIUS, Constants.WGS84_EARTH_FLATTENING,ecef);
NRLMSISE00 nrlmsise00 = new NRLMSISE00(msfe,sun,earth);
double dragArea = 10.0;
double cd = 1.137;
IsotropicDrag dragPhysicalModel = new IsotropicDrag(dragArea,cd);
DragForce dragForce = new DragForce(nrlmsise00,dragPhysicalModel);
double reflectiveArea = 10.0;
double cr = 1.137;
IsotropicRadiationSingleCoefficient radiationPhysicalModel = new IsotropicRadiationSingleCoefficient(reflectiveArea,cr);
SolarRadiationPressure srp = new SolarRadiationPressure(sun,earth.getEquatorialRadius(),radiationPhysicalModel);
int degree = 70;
int oreder = 70;
NormalizedSphericalHarmonicsProvider provider = GravityFieldFactory.getNormalizedProvider(degree,oreder);
HolmesFeatherstoneAttractionModel potatoe = new HolmesFeatherstoneAttractionModel(ecef,provider);
CelestialBody moon = CelestialBodyFactory.getMoon();
ThirdBodyAttraction nBodyMoon = new ThirdBodyAttraction(moon);
ThirdBodyAttraction nBodySun = new ThirdBodyAttraction(sun);
double minStep = 1e-3;
double maxStep = 300.0;
double positionTolerance = 1e-9;
OrbitType propagationType = OrbitType.CARTESIAN;
double[][] tolerances = NumericalPropagator.tolerances(positionTolerance,initialOrbit,propagationType);
DormandPrince853Integrator integrator = new DormandPrince853Integrator(minStep,maxStep,tolerances[0],tolerances[1]);
NumericalPropagator propagator = new NumericalPropagator(integrator);
propagator.addForceModel(dragForce);
propagator.addForceModel(srp);
propagator.addForceModel(potatoe);
propagator.addForceModel(nBodyMoon);
propagator.addForceModel(nBodySun);
propagator.setInitialState(initialState);
SpacecraftState currentState = propagator.propagate(backPropagationDate);
Also, error occured at Orekit 12.2.1 with up-to-date orekit-data, I have tried to reproduce it in 11.3.3 but it does not occured.
These initial state parameters are in m, m/s and kg, I check the keplerian parameters and they seems ok, around 681 km of altitude and frozen eccentricity. I wonder why you thought the units are mismatched Is something off about those parameters?
I’ve identified the root cause in MSAFE and created an issue on Gitlab. We could have this in the next patch.
Basically, if you’re unlucky, the integration step is very close to the interpolation points and the scaled variable is outside the range [0,1]. There might be a deeper problem with the cache system.
Ok so i have found the source of the issue and two solutions are available i would say.
Problem
When the difference between a reference date and a cached value date is smaller than the QUANTUM_STEP defined inside GenericTimeStampedCache, the cache is not able to differentiate the reference date from the cached value date.
Hence it thinks that they are the same and increase the reference date index which is then used to define the neighbours list. This cause the neighbours list to not encapsulate the reference date and thus, makes the normalized reference date outside the [0;1] which is the error that is later thrown.
Solution 1
A simple way to fix this is to decrease the value of QUANTUM_STEP to the order of magnitude that we desire.
Solution 2
Another solution, with a more physical approach, is to consider that such a small difference in time is negligible on final results and proceed to apply @Serrof solution of rounding to closest bound.
Solution 1 should not have a performance impact from what i understand but i may be wrong so i would like to hear your opinions on this.
I think that the QUANTUM_STEP had been set up only in order to convert from continuous (i.e. primitive double) to discrete with a long.
As now the dates are always discrete at attoseconds accuracy, I wonder if we need QUANTUM_STEP at all. We have to take care dates use two longs and not just one.
Is something off about those parameters?