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

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



Le 18/05/2015 12:14, Petrus Hyvönen a écrit :
> 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

I think I have fixed it now. Could you try with the current development
version of Orekit? The same bug is certainly also in Apache Commons
Math, I will fix it there tonight.

best regards,
Luc

> 
> Regards
> /Petrus
> 
> 
> 
> 
> On Mon, May 18, 2015 at 9:54 AM, Petrus Hyvönen
> <petrus.hyvonen@gmail.com <mailto: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
>     <mailto: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>
>         <mailto: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>
>         >     <mailto: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> <tel:%2B46%2073%20803%2019%2000>
>         >
>         >
>         >
>         >
>         > --
>         > _____________________________________________
>         > 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 <tel:%2B46%2073%20803%2019%2000>
> 
> 
> 
> 
> -- 
> _____________________________________________
> Petrus Hyvönen, Uppsala, Sweden
> Mobile Phone/SMS:+46 73 803 19 00