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:petrus.hyvonen@gmail.com> <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>>> 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
> <tel:%2B46%2073%20803%2019%2000> <tel:%2B46%2073%20803%2019%2000>> <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
> >
> >
> >
> >
> > --
> > _____________________________________________
> > 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