[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Orekit Developers] Bug in eventdetector/commons-math?



Hi,

I have recreated a similar failure in java. I didn't manage to get it exacly same as in my python version, seems to be some number details issue.

Issue filed under:
https://www.orekit.org/forge/issues/203

Regards
/Petrus




On Mon, May 18, 2015 at 9:54 AM, Petrus Hyvönen <petrus.hyvonen@gmail.com> wrote:
Hi Luc,

I will try to see if I can make a java version with same error.

From my jvm debugging it seems as you say it's some kind of numeric problem,

The error seems to appear around line 230 in Eventstate.java:

 AbsoluteDate ta = t0;
            double ga = g0;
            for (int i = 0; i < n; ++i) {

                // evaluate detector value at the end of the substep
                final AbsoluteDate tb = t0.shiftedBy((i + 1) * h);
                interpolator.setInterpolatedDate(tb);
                final double gb = g(interpolator.getInterpolatedState());

                // check events occurrence
                if (g0Positive ^ (gb >= 0)) {
                    // there is a sign change: an event is expected during this step

                    // variation direction, with respect to the integration direction
                    increasing = gb >= ga;

                    // find the event time making sure we select a solution just at or past the exact root
                    final double dtA = ta.durationFrom(t0);
                    final double dtB = tb.durationFrom(t0);
                    final double dtRoot = forward ?
                                          solver.solve(maxIterationcount, f, dtA, dtB, AllowedSolution.RIGHT_SIDE) :
                                          solver.solve(maxIterationcount, f, dtB, dtA, AllowedSolution.LEFT_SIDE);
                    final AbsoluteDate root = t0.shiftedBy(dtRoot);

When solver.solve is called and the error occurs dtA (which in solver translate to min) is 60.0  and dtB (which becomes max) is 59.999714243309676. At this point the loop variable i is 0. I don't understand where ta gets modified with 60 seconds from t0 at iteration 0.


I'm not using custom event detectors, the only thing which was a bit unusal was a highly detailed elevation mask.

I will try to make a simple java testcase..

Regards
/Petrus


On Mon, May 18, 2015 at 9:30 AM, Luc Maisonobe <Luc.Maisonobe@c-s.fr> wrote:
Le 15/05/2015 22:34, Petrus Hyvönen a écrit :
> Hi again,
>
> To be more specific, I think it's in the ElevationDetector. If I remove
> this there is no error. Removing the NodeDetector does not remove the error.
>
> I'm using a custom horizon profile.

Could you provide us a complete test case reproducing the error? This
means also the orbit date, the frames you use, a reference to the EOP
you use, the horizon profile, the target date for the propagation, the
mode, ... All should be given to full numerical accuracy to ensure we
run the exact same values than you.

The rationale is that the issue you encounter is often linked to very
small numerical inaccuracy, at the level of the last significant bit in
double numbers (i.e. about 15th-16th significant digit in base 10). We
did encounter this a large number of times, it used to be the most
frequent bug in Orekit/Apache Commons Math. However, since a few years,
all issues have been resolved and the code is now quite robust. Since
about 2 years, all issues triggering this error message were usage
error, mainly with event switching function that were not continuous in
the neighborhood of the event, thus not fulfilling the constraints of
the API. If you use a regular ElevationDetector, this should not be the
case though, so your problem should be investigated in depth. For this,
we need to be able to reproduce it.

best regards,
Luc

>
> Regards
> /Petrus
>
>
> On Fri, May 15, 2015 at 8:43 PM, Petrus Hyvönen
> <petrus.hyvonen@gmail.com <mailto:petrus.hyvonen@gmail.com>> wrote:
>
>     Hi,
>
>     I'm using NodeDetector and ElevationDetector, both wrapped in a
>     logger.monitorDetector
>
>     Regards
>     /Petrus
>
>
>     On Fri, May 15, 2015 at 8:40 PM, Evan Ward <evan.ward@nrl.navy.mil
>     <mailto:evan.ward@nrl.navy.mil>> wrote:
>
>         Hi Petrus,
>
>         Which event detector(s) are you using?
>
>         Regards,
>         Evan
>
>
>         On 05/15/2015 02:25 PM, Petrus Hyvönen wrote:
>>         Hi,
>>
>>         I'm experiencing some strange errors in my propagation with
>>         some eventdetectors, and thought I'd ask you for comments. I'm
>>         using orekit via the pythonwrapper so debugging is a bit complex..
>>
>>         It seems to occur only on certain orbits, but I'm just
>>         changing altitude and inclination (SSO) so seems more like
>>         some math issue. For some orbits it works.
>>
>>         The error stack is:
>>         JavaError:
>>         org.apache.commons.math3.exception.NumberIsTooLargeException:
>>         endpoints do not specify an interval: [60, 59.951]
>>             Java stacktrace:
>>         org.apache.commons.math3.exception.NumberIsTooLargeException:
>>         endpoints do not specify an interval: [60, 59.951]
>>         at
>>         org.apache.commons.math3.analysis.solvers.UnivariateSolverUtils.verifyInterval(UnivariateSolverUtils.java:417)
>>         at
>>         org.apache.commons.math3.analysis.solvers.UnivariateSolverUtils.verifySequence(UnivariateSolverUtils.java:435)
>>         at
>>         org.apache.commons.math3.analysis.solvers.BaseAbstractUnivariateSolver.verifySequence(BaseAbstractUnivariateSolver.java:280)
>>         at
>>         org.apache.commons.math3.analysis.solvers.BracketingNthOrderBrentSolver.doSolve(BracketingNthOrderBrentSolver.java:154)
>>         at
>>         org.apache.commons.math3.analysis.solvers.BaseAbstractUnivariateSolver.solve(BaseAbstractUnivariateSolver.java:199)
>>         at
>>         org.apache.commons.math3.analysis.solvers.BaseAbstractUnivariateSolver.solve(BaseAbstractUnivariateSolver.java:204)
>>         at
>>         org.apache.commons.math3.analysis.solvers.BracketingNthOrderBrentSolver.solve(BracketingNthOrderBrentSolver.java:398)
>>         at
>>         org.orekit.propagation.events.EventState.evaluateStep(EventState.java:231)
>>         at
>>         org.orekit.propagation.analytical.AbstractAnalyticalPropagator.acceptStep(AbstractAnalyticalPropagator.java:279)
>>         at
>>         org.orekit.propagation.analytical.AbstractAnalyticalPropagator.propagate(AbstractAnalyticalPropagator.java:167)
>>         at
>>         org.orekit.propagation.AbstractPropagator.propagate(AbstractPropagator.java:257)
>>
>>
>>         The call (from python) is:
>>         finalState = prop.propagate(self.ore_t[0].shiftedBy(60 * 60 *
>>         24.0 * self.duration))
>>
>>         prop.getInitialState().getOrbit()
>>         <Orbit: keplerian parameters: {a: 7138142.0; e:
>>         7.004623892026274E-7; i: 98.51876854105349; pa: 0.0; raan:
>>         94.9995; v: 0.00700813981787154;}>
>>
>>         the propagator is a:
>>         org.orekit.propagation.analytical.EcksteinHechlerPropagator
>>
>>         I'm running orekit 7.0 with apache math 3.4.2.
>>
>>         Do you have any feeling what could be the issue? I have the
>>         impression that this part of orekit would be very well used,
>>         so maybe it's something I'm doing but hard to see what.
>>
>>         Any inputs appriciated
>>
>>         Best Regards
>>         /Petrus
>>
>>
>>
>
>
>
>
>     --
>     _____________________________________________
>     Petrus Hyvönen, Uppsala, Sweden
>     Mobile Phone/SMS:+46 73 803 19 00 <tel:%2B46%2073%20803%2019%2000>
>
>
>
>
> --
> _____________________________________________
> Petrus Hyvönen, Uppsala, Sweden
> Mobile Phone/SMS:+46 73 803 19 00




--
_____________________________________________
Petrus Hyvönen, Uppsala, Sweden
Mobile Phone/SMS:+46 73 803 19 00



--
_____________________________________________
Petrus Hyvönen, Uppsala, Sweden
Mobile Phone/SMS:+46 73 803 19 00