Orekit issueshttps://gitlab.orekit.org/groups/orekit/-/issues2018-08-07T09:41:53Zhttps://gitlab.orekit.org/orekit/orekit/-/issues/89Improper handling of leap seconds2018-08-07T09:41:53ZNicolae MihalacheImproper handling of leap secondsSince a few days, the handling of leap seconds for the first day (24h)
in the last interval in UTC-TAI.history, is one second off.
For example this piece of code:
`String utc="2012-07-01T00:00:00.000";
AbsoluteDate ad=new AbsoluteDate...Since a few days, the handling of leap seconds for the first day (24h)
in the last interval in UTC-TAI.history, is one second off.
For example this piece of code:
`String utc="2012-07-01T00:00:00.000";
AbsoluteDate ad=new AbsoluteDate(utc, TimeScalesFactory.getUTC());
System.out.println("utc: "+utc+" ad: "+ad);`
prints:
`utc: 2012-07-01T00:00:00.000 ad: 2012-07-01T00:00:01.000`
The times starting with 2-July or before 1-July are ok.
*(from redmine: issue id 89, created on 2012-04-13, closed on 2012-04-13)*Luc MaisonobeLuc Maisonobehttps://gitlab.orekit.org/orekit/orekit/-/issues/90Use IERS conventions 20102018-08-07T09:41:53ZLuc MaisonobeUse IERS conventions 2010IERS Earth Orientation Data are now available only with respect to IERS
conventions 2010 and not IERS conventions 2003 anymore.
The changes are mainly the precession model which is now IAU-2006 (the
nutation model is still IAU-2000A). ...IERS Earth Orientation Data are now available only with respect to IERS
conventions 2010 and not IERS conventions 2003 anymore.
The changes are mainly the precession model which is now IAU-2006 (the
nutation model is still IAU-2000A).
The ITRF frame is also ITRF 2008 now.
*(from redmine: issue id 90, created on 2012-04-16, closed on 2012-04-16)*https://gitlab.orekit.org/orekit/orekit/-/issues/91Update CCSDS Time Code parser to version 4 of the Blue Book2018-08-07T09:41:54ZLuc MaisonobeUpdate CCSDS Time Code parser to version 4 of the Blue BookThe current version of Orekit supports CCSDS Unsegmented Time Code is
defined in the
version 3 of the blue book CCSDS Time Code Format (CCSDS 301.0-B-3)
published in 2002.
This version has been superseded by version 4 (CCSDS 301.0-B-...The current version of Orekit supports CCSDS Unsegmented Time Code is
defined in the
version 3 of the blue book CCSDS Time Code Format (CCSDS 301.0-B-3)
published in 2002.
This version has been superseded by version 4 (CCSDS 301.0-B-4)
published in 2010.
This new version adds a new byte in the CCSDS Unsegmented Time Code
(CUC).
Orekit should support the current version of the standard.
*(from redmine: issue id 91, created on 2012-04-18, closed on 2012-04-18)*https://gitlab.orekit.org/orekit/orekit/-/issues/92Error in the the computation of the radiative force of one facet2018-08-07T09:41:55ZYannick TanguyError in the the computation of the radiative force of one facetThere's an error in the formula coded in the BoxAndSolarArraySpacecraft,
in the facetRadiationAcceleration method :
- the normal contribution uses the area in the denominator
- the tangential contribution does not take into account t...There's an error in the formula coded in the BoxAndSolarArraySpacecraft,
in the facetRadiationAcceleration method :
- the normal contribution uses the area in the denominator
- the tangential contribution does not take into account the area
We checked Vallado's equation and corrected OREKIT that way (see the Cn
and Cs computation) :
private Vector3D facetRadiationAcceleration(final Facet facet, final
Vector3D fluxSat,
final double dot) {
final double area = facet.getArea();
final double dOa = dot / area;
final double psr = fluxSat.getNorm();
// Vallado's equation 8-44 uses different parameters which are related
to our parameters as:
// cos (phi) = -dot / (psr \* area)
// n = facet / area
// s = -fluxSat / psr
final double cN = 2 \* area \* dot \* (diffuseReflectionCoeff / 3 -
specularReflectionCoeff \* dot / psr);
final double cS = (area \* dot / psr) \* (specularReflectionCoeff -
1);
return new Vector3D(cN, facet.getNormal(), cS, fluxSat);
}
Our unitary tests confirm the correction and there is no impact on
OREKIT tests.
*(from redmine: issue id 92, created on 2012-04-24, closed on 2012-04-24)*https://gitlab.orekit.org/orekit/orekit/-/issues/93Long term DSST behavior2018-08-07T09:41:59ZSimon BillemontLong term DSST behaviorHi,
I am checking out the DSST module in Orekit 6 (git snapshot) and found
that the very-long term behavior of DSST does not comply with other
results. I compared against using the same forces using a normal
numerical integrator in Orek...Hi,
I am checking out the DSST module in Orekit 6 (git snapshot) and found
that the very-long term behavior of DSST does not comply with other
results. I compared against using the same forces using a normal
numerical integrator in Orekit and using a free software tool STELA
(http://logiciels.cnes.fr/STELA/fr/logiciel.htm) which both produce
practically the same results. So, I suspect that there is an anomaly in
the DSST implementation.
When I integrate an initial GTO orbit over a period of 200 years, after
only 3 years, the DSST eccentricity deviates significantly from the
alternative results (see attached graphs). The period of the oscillation
of about 5 years seems to be off by 25% and the period of about 200
years seems to be missing altogether.
There is also a difference in the rate of change of the pericenter,
which is slightly different between DSST and numerical / STELA
integration runs. Since the eccentricity and pericenter are coupled,
this affects the eccentricity as well, perhaps missing a resonance
condition.
The forces in both systems are:
- Central body (earth, Cnm/Snm to order 5)
- Lunar and Solar (3rd body) gravitational effects
- No drag, no SRP
The orbital elements used are mean elements, but the difference between
mean/osculating elements is negligible with respect to the differences
shown between DSST and the numerical propagator.
Can you confirm that this is a bug and not a configuration issue and
possibly provide a solution to this problem?
I've included the source I used to run the DSST/numerical orekit
propagator, as well as the ephemeris generated by the STELA tool.
*(from redmine: issue id 93, created on 2012-05-06, closed on 2015-01-12)*
* Relations:
* relates #95
* Uploads:
* [DSST_simulation.java](/uploads/03e37c901b12f14480590c883f39f737/DSST_simulation.java) None
* ![stela-dsst-e](/uploads/45005e6d78865f4180781274b361770e/stela-dsst-e.png) None
* ![stela-dsst-e-zoom](/uploads/f8d2bf07037cdb0815b9a4a352bf0cb0/stela-dsst-e-zoom.png) None
* ![stela-dsst-w](/uploads/e01636e8d9db2809c266224338529f1d/stela-dsst-w.png) None
* [STELA.7z](/uploads/2e2e8d8441b09027707ac5f0e0d4bb62/STELA.7z) None
* ![new-stela-dsst-e](/uploads/985e5e9c51f97f7909f1891c3d9b642a/new-stela-dsst-e.png) None
* ![new-stela-dsst-e-zoom](/uploads/8f3d0fc95d986a65f938a345c794c1d6/new-stela-dsst-e-zoom.png) None
* ![GTO_bug93-2](/uploads/25ebce84d9e22392f679496869d48453/GTO_bug93-2.png)
* ![GTO_bug93-2_diff](/uploads/9b370314994c26645e7f9589aeb96f7c/GTO_bug93-2_diff.png)Pascal ParraudPascal Parraudhttps://gitlab.orekit.org/orekit/orekit/-/issues/94Bounded Propagator2018-08-07T09:42:00ZFrancesco RoccaBounded PropagatorIn BoudedPropagator it would be utils have a method for direct access to
the source array data.
SpacecraftState\[\] getSourceData(){}
*(from redmine: issue id 94, created on 2012-05-07, closed on 2015-01-12)*In BoudedPropagator it would be utils have a method for direct access to
the source array data.
SpacecraftState\[\] getSourceData(){}
*(from redmine: issue id 94, created on 2012-05-07, closed on 2015-01-12)*https://gitlab.orekit.org/orekit/orekit/-/issues/95Comment on Bug 93 report2018-08-07T09:42:02ZPaul CefolaComment on Bug 93 reportI have explored the issue raised in Bug 93. I have recreated the test
case using the Linux R&D GTDS numerical propagator and the GTDS
implementation of DSST. I created precise mean element initial
conditions for the DSST using a PCE proc...I have explored the issue raised in Bug 93. I have recreated the test
case using the Linux R&D GTDS numerical propagator and the GTDS
implementation of DSST. I created precise mean element initial
conditions for the DSST using a PCE process. I then integrated the
numerical propagator and the DSST ahead over a twenty (20) year
interval. The key result is the plot of the eccentricity histories
(Figure 2 in the attached file).
The numerical and DSST eccentricity agree well over the 20 yrs. The
differences are much smaller than the differences reported by Billemont.
Therefore, I think we can suspect that there is a difference between
Orekit DSST and GTDS DSST.
In the attached file I have provided both the initial conditions for the
numerical propagation (Table 1) and the DSST propagation (Table 3).
*(from redmine: issue id 95, created on 2012-05-14, closed on 2012-05-14)*
* Relations:
* relates #93
* Uploads:
* [CefolaCommentOn_OrekitBug93_rev3.pdf](/uploads/ce36821b82d8034aba9d659f450dfb9e/CefolaCommentOn_OrekitBug93_rev3.pdf) Comments on Orekit Bug 93https://gitlab.orekit.org/orekit/orekit/-/issues/96Unitary tests for the numerical propagator2018-08-07T09:42:04ZYannick TanguyUnitary tests for the numerical propagatorWe have validated the numerical propagator, using several integrators
(DOP853, RK4, GBS), different force models (potential up to 60x60 order,
3rd bodies, SRP, atmospheric drag), on different orbits (LEO, MEO, GEO,
HEO). Reference data c...We have validated the numerical propagator, using several integrators
(DOP853, RK4, GBS), different force models (potential up to 60x60 order,
3rd bodies, SRP, atmospheric drag), on different orbits (LEO, MEO, GEO,
HEO). Reference data come from our numerical propagators used for high
accurate orbit determination.
We propose to extract some use cases to improve OREKIT unitary tests.
These tests would cover some of the more significant use cases : 5 days
propagation on a LEO orbit with all conservative forces, 10 days
propagation on a GEO orbit with all conservative forces and SRP, etc.
Each test will compare a numerical propagation with the results we
obtained during our validation tests. The initial deviation with our
reference tools will also be documented.
*(from redmine: issue id 96, created on 2012-05-15, closed on 2015-05-29)*
* Uploads:
* [NumericalPropagatorOrbitsTest.java](/uploads/987072dbb0b3857703730af80f04d918/NumericalPropagatorOrbitsTest.java) Test case with some reference from high accuracy numerical propagator
* [grim4s4_gr](/uploads/1c08395df3a453f2a771dcaac924dbf1/grim4s4_gr) The potential file used for the testhttps://gitlab.orekit.org/orekit/orekit/-/issues/97The cunningham model returns a NaN for high order of potential2018-08-07T09:42:06ZYannick TanguyThe cunningham model returns a NaN for high order of potentialWe encountered some problems of numerical stability with the Cunningham
model.
For high order / degree, the model returned NaN while the Droziner model
returned correct values.
We are going to analyse the behaviour of this algorithm w...We encountered some problems of numerical stability with the Cunningham
model.
For high order / degree, the model returned NaN while the Droziner model
returned correct values.
We are going to analyse the behaviour of this algorithm with specific
tools.
The attached case shows the problem for degree/order 46.
*(from redmine: issue id 97, created on 2012-05-15, closed on 2012-05-15)*
* Uploads:
* [CunninghamPotentialBugTest.java](/uploads/fa4403b407885bdedafa64bfe03a9c12/CunninghamPotentialBugTest.java) None
* [grim4s4_gr](/uploads/8c37ea12638c0165e1549ed98dd30dc4/grim4s4_gr) The potential file used for the test
* [cunningham.diff](/uploads/f9e20ae20615c4eb8b19c7475f920d34/cunningham.diff) Nonehttps://gitlab.orekit.org/orekit/orekit/-/issues/98Orphan frames2018-08-07T09:42:07ZYannick TanguyOrphan framesAs now, OREKIT does not allow to manipulate frames that are not attached
to a parent one. We made a small modification in OREKIT that allows to
use "orphan" frames ; it can be very useful, for instance to manipulate
different parts (ie :...As now, OREKIT does not allow to manipulate frames that are not attached
to a parent one. We made a small modification in OREKIT that allows to
use "orphan" frames ; it can be very useful, for instance to manipulate
different parts (ie : a spacecraft "main" box and its solar arrays, a
ground station and its antenna). Later, we can attach them to an
existing frame (ie : a LOF to attach a whole spacecraft structure, or a
topocentric frame to attach a ground station).
For example, one can define different parts, attached with its parent
with a Transform object, and then attach it to an existing frame in the
main tree of frames.
The modification is very little :
- we modified the constructor of Frame so that it's protected and not
private.
- we added a OrphanFrame class (in the Frame package), with a static
method that returns a frame which is not attached to any frame. A
"local" tree of frames can be built around this orphan frame. Later,
this tree of frames can be attached to the main tree of frames.
Maybe this getNewOrphanFrame method could be in the "Frames Factory".
------------------------------------------------------------------------
public class OrphanFrame {
/** Private constructor.
*/
private OrphanFrame() {
}
/** This method creates an Orphan Frame.
* @param name Orphan frame name
* @return the created orphan frame
*/
public static final Frame getNewOrphanFrame(final String name) {
return new Frame(name, false);
}
}
------------------------------------------------------------------------
*(from redmine: issue id 98, created on 2012-05-15, closed on 2012-05-15)*https://gitlab.orekit.org/orekit/orekit/-/issues/99quadruple precision2018-08-07T09:42:09ZBernard Godardquadruple precisionFor high-accuracy solar system body or interplanetary spacecraft orbit
propagation or determination, it is recommended that state vectors and
position vectors are represented in quadruple precision. Ideally, all
floating point arithmetic...For high-accuracy solar system body or interplanetary spacecraft orbit
propagation or determination, it is recommended that state vectors and
position vectors are represented in quadruple precision. Ideally, all
floating point arithmetics in the orbit propagation/determination
program should be in quadruple precision. When the software is written
in FORTRAN, it is possible with some compilers to promote all double
precision variables to quadruple precision using a compiler option that
emulates quadruple precision arithmetics. Then you can get two version
of the software almost for free: a fast version in double precision, and
a quadruple precision version for high accuracy (extremely slow because
the hardware does not support quadruple precision arithmetics so this is
in software). In C**, one would use template <class scalar> to achieve
something similar, although this requires that the software was
originally designed with the possibility to change the scalar type. Is
it possible to achieve something similar with Apache Commons Math and
Orekit? I have been browsing for a java virtual machine that would allow
promotion of all double to quad without success.
*(from redmine: issue id 99, created on 2012-05-17, closed on 2015-05-29)*https://gitlab.orekit.org/orekit/orekit/-/issues/100Problem when using a YawCompensation attitude provider with BodyCenterPointing2018-08-07T09:42:10ZYannick TanguyProblem when using a YawCompensation attitude provider with BodyCenterPointingWe noticed a problem when we give a BodyCenterPointing instance to a
YawCompensation attitude provider. The behaviour is not the one
expected, as the BodyCenterPointing returns the earth center instead of
a ground point aligned with the ...We noticed a problem when we give a BodyCenterPointing instance to a
YawCompensation attitude provider. The behaviour is not the one
expected, as the BodyCenterPointing returns the earth center instead of
a ground point aligned with the earth center when calling
getTargetPoint() method.
A solution would be to modify BodyCenterPointing so it does not extend
GroundPointing, and to create a new AttitudeProvider that uses a
BodyCenterPointing to calculate the targeted point on the ground.
What do you think about it ?
*(from redmine: issue id 100, created on 2012-05-23, closed on 2016-02-10)*https://gitlab.orekit.org/orekit/orekit/-/issues/101Transform does not compute 3D line transformations correctly2018-08-07T09:42:11ZLuc MaisonobeTransform does not compute 3D line transformations correctlySince the 3D Line class has been replaced by Apache Commons Math 3D Line
which has different constructors semantics, Transform does not transform
lines correctly anymore.
This can be observed by separately transforming a line and a poin...Since the 3D Line class has been replaced by Apache Commons Math 3D Line
which has different constructors semantics, Transform does not transform
lines correctly anymore.
This can be observed by separately transforming a line and a point
belonging to the line:
Transform transform = ...;
Line originalLine = ...;
Vector3D pointOnLine = originalLine.pointAt(1.0e6);
Line transformedLine = transform.transformLine(originalLine);
Vector3D transformedPoint = transform.transformPosition(pointOnLine);
System.out.println("distance = " + transformedLine.distance(transformedPoint));
The displayed distance should be very small, but in many cases it is
huge.
The problem comes from transformLine method which uses transformVector
to compute the second point of the Line constructor, when it should use
transformPoint.
*(from redmine: issue id 101, created on 2012-06-11, closed on 2012-06-11)*https://gitlab.orekit.org/orekit/orekit/-/issues/104Selecting the slope of a g function in event detectors2018-08-07T09:42:12ZYannick TanguySelecting the slope of a g function in event detectorsThis feature is both an improvement to OREKIT/Commons Math behaviour and
a correction to a bug we encountered while using angle event detectors.
To understand the bug, the initial message can be found here :
https://www.orekit.org/wws/a...This feature is both an improvement to OREKIT/Commons Math behaviour and
a correction to a bug we encountered while using angle event detectors.
To understand the bug, the initial message can be found here :
https://www.orekit.org/wws/arc/orekit-developers/2012-07/msg00000.html
This feature consists in adding a new parameter (slope selection) to the
event detectors : this parameter will allow the user to choose if he
wants to detect ascending/descending g functions, or both (as of now).
This parameter is used in the *EventState* class (method *acceptStep*).
A few classes are impacted : *EventDetector*, *EventState*,
*AbstractDetector*, a few classes that implements directly the
*EventDetector* interface.
The user who wants to detect only an ascending event (ex : in a node
detector) will choose the new constructor in *AbstractDetector*.
This feature also needs to be implemented in Commons Math.
I will join source code and reference on Commons Math issue.
*(from redmine: issue id 104, created on 2012-07-02, closed on 2012-07-02)*https://gitlab.orekit.org/orekit/orekit/-/issues/105UTCScale#offsetToTAI is not zero before first leap second2018-08-07T09:42:13ZEvan WardUTCScale#offsetToTAI is not zero before first leap secondIn my own unit tests I noticed an issue that I tracked down to
UTCScale\#offsetToTAI. It should check if the requested date is before
the first leap second as in UTCScale\#offsetFromTAI.
Here is a test case that currently fails:
@Test ...In my own unit tests I noticed an issue that I tracked down to
UTCScale\#offsetToTAI. It should check if the requested date is before
the first leap second as in UTCScale\#offsetFromTAI.
Here is a test case that currently fails:
@Test
public void testOffsetToTAIBeforeFirstLeapSecond() throws
OrekitException {
TimeScale scale = TimeScalesFactory.getUTC();
// time before first leap second
DateComponents dateComponents = new DateComponents(1950, 1, 1);
double actual = scale.offsetToTAI(dateComponents, TimeComponents.H00);
assertThat(actual, is(0d));
}
*(from redmine: issue id 105, created on 2012-07-05, closed on 2012-07-05)*https://gitlab.orekit.org/orekit/orekit/-/issues/106Cache in CelestialBodyFactory2018-08-07T09:42:15Z Carlos CasasCache in CelestialBodyFactoryThe cache system you have implemented in the CelestialBodyFactory by
means of the CELESTIAL\_BODIES\_MAP variable is giving me a hard time.
The problem is that I add a loader and ask for a body. Then I remove all
loaders and add a differ...The cache system you have implemented in the CelestialBodyFactory by
means of the CELESTIAL\_BODIES\_MAP variable is giving me a hard time.
The problem is that I add a loader and ask for a body. Then I remove all
loaders and add a different loader. If I ask for the same body, I still
get the body I would have gotten with the first loader. I would have
expected the body created by the new loader.
As strange as this could be in a piece of code (using bodies, then
removing their loaders, redefining them in a different way and asking
for the same bodies again...), this situation arises easily in the
testing process. I use jUnit as unit test tool. jUnit runs all the
defined tests one after another in the same run, in an undefined order.
I have two different tests, each of them using different ephemeris. If I
run them separately, everything works. If I run them together, one of
them fails because it uses the wrong bodies.
I was wondering, maybe you had this problem already? Do you have unitary
tests with different loaders for the same bodies? How did you make them
work?
In my opinion, there are two ways of solving this issue while keeping
this body cache system:
- Everytime a loader is cleared, all the bodies created with this loader
should be removed from CELESTIAL\_BODIES\_MAP, or
- Everytime a body is requested, check if its loader is still in. If
not, remove it from CELESTIAL\_BODIES\_MAP and recalculate it.
Thanks for your support. You really are doing a very good work with
Orekit.
*(from redmine: issue id 106, created on 2012-07-23, closed on 2012-07-23)*https://gitlab.orekit.org/orekit/orekit/-/issues/107Retropropagation issue in AbstractPropagator.acceptedStep2018-08-07T09:42:17ZBruno RevelinRetropropagation issue in AbstractPropagator.acceptedStepIf eventStates are not yet initialized, a propagation is performed at
the previous date (ie initialState), resulting in a retropropagation,
*even if there is no actual event Handler* !
It becomes troublesome if the propagator cannot do...If eventStates are not yet initialized, a propagation is performed at
the previous date (ie initialState), resulting in a retropropagation,
*even if there is no actual event Handler* !
It becomes troublesome if the propagator cannot do retropropagation.
Suggested workaround: adding a <if (!eventStates.isEmpty())> condition
inside the <if (!statesInitialized)>
Suggested and prefered correction: saving the event handler states when
performing a setInitialStep.
*(from redmine: issue id 107, created on 2012-07-31, closed on 2012-07-31)*https://gitlab.orekit.org/orekit/orekit/-/issues/108Unuseful g calls in the event detection2018-08-07T09:42:18ZYannick TanguyUnuseful g calls in the event detectionWhen a propagation is done with event detector, if the integration step
is smaller than the "maxCheck" of event detection, the "g" function is
called twice at each step (in other words, at both start and end of each
step).
This case oc...When a propagation is done with event detector, if the integration step
is smaller than the "maxCheck" of event detection, the "g" function is
called twice at each step (in other words, at both start and end of each
step).
This case occurs frequently for all events with few occurrences in the
orbit period (in such cases the "maxCheck" can be set to a high value
wrt orbital period).
It could be interesting to avoid these double computations, especially
when the g function is complex.
*(from redmine: issue id 108, created on 2012-08-02, closed on 2012-08-02)*https://gitlab.orekit.org/orekit/orekit/-/issues/110Event detection fails with an abstract propagator and a non monotonic function2018-08-07T09:42:22ZYannick TanguyEvent detection fails with an abstract propagator and a non monotonic functionWe noticed some problem with event detection feature of the analytical
propagator (AbstractPropagator).
Some times, when the g function is not monotonic during the step
interval, the abstract propagator fails to detect the root. The
num...We noticed some problem with event detection feature of the analytical
propagator (AbstractPropagator).
Some times, when the g function is not monotonic during the step
interval, the abstract propagator fails to detect the root. The
numerical propagator detects the 0 even for a non monotonic function.
Setting the max chack parameter to a lower value might solve the problem
practically, but occurrences of such failures should still be expected.
Indeed, the g function can still exhibit non-monotony, however small the
\[dtA, dtB\] interval might be.
In this specific case, we consider a step \[tmin ; tmax\], for which the
root is in the middle of the step :
tmin = 0.00, g = 5.23E-16
tmax = 399.99, g = -0.10
In the first iteration (in EventState.evaluateStep()), the algorithm
tries to detect between t1 = tmin and t2 = 1. In this case, g(t2) =
4.6E-4 >g(t1) : the g function has a local maximum value.
So the algorithm tries to decrease t1, but it is limited by tmin, so the
algorithm keeps the value t1 = tmin and fails after a "max iteration"
threshold is reached.
->The attached image file helps to understand how the sub-steps are
evaluated.
So we compared the code of EventState.evaluateStep (in OREKIT) and the
same code in CommonsMath (which uses double values instead of
AbsoluteDate/SpacecraftState) and we found a main difference :
->by default, Commons Math uses a BracketingNthOrderBrentSolver
(with order 5) whereas OREKIT tries with a simple BrentSolver and after
with a PegasusSolver (to force side of the root, on the left or right of
the "real" root)
We tried to adapt OREKIT to use this BracketingNthOrderBrentSolver
instead of the BrentSolver and it seems to solve our problem.
By the way, we still don't understand why two solvers are used one after
the other : the first to find the real root (dtBaseRoot) and the other
to switch the root on the left or right of the current step. Is it done
in order to avoid multiple detections ?
*(from redmine: issue id 110, created on 2012-08-24, closed on 2012-08-24)*
* Relations:
* relates #136
* Uploads:
* ![event_detection](/uploads/9c92a5b24796746fb6f7a4d5247f4a10/event_detection.PNG) None
* [BugA417NonCvgDetector.java](/uploads/64289dd743ba158383c05f79df26426b/BugA417NonCvgDetector.java) None
* [ModifiedElevationDetector.java](/uploads/08c4762020fffc0684ff28daf1daecfd/ModifiedElevationDetector.java) None
* [ModifiedElevationDetector.java](/uploads/50941d013c3a932876a1fc94825f83ef/ModifiedElevationDetector.java) None
* ![event_detection](/uploads/616772d7c2888d8221774df6e8369088/event_detection.png) Nonehttps://gitlab.orekit.org/orekit/orekit/-/issues/111Stackoverflow for empty UTC data2018-08-07T09:42:23ZSimon BillemontStackoverflow for empty UTC dataHi,
When the UTC data is empty (not using UTC), an infinite loop is created
starting from AbsoluteDate.toString(...)
Exception in thread "main" java.lang.StackOverflowError
....
at org.orekit.errors.OrekitExcept...Hi,
When the UTC data is empty (not using UTC), an infinite loop is created
starting from AbsoluteDate.toString(...)
Exception in thread "main" java.lang.StackOverflowError
....
at org.orekit.errors.OrekitException.buildMessage(OrekitException.java:166)
at org.orekit.errors.OrekitException.getMessage(OrekitException.java:126)
at org.orekit.errors.OrekitException.getLocalizedMessage(OrekitException.java:138)
at java.lang.Throwable.toString(Throwable.java:343)
at java.lang.Throwable.(Throwable.java:242)
at java.lang.Exception.(Exception.java:77)
at java.lang.RuntimeException.(RuntimeException.java:77)
at org.orekit.time.AbsoluteDate.toString(AbsoluteDate.java:797)
at java.text.MessageFormat.subformat(MessageFormat.java:1246)
at java.text.MessageFormat.format(MessageFormat.java:836)
at java.text.Format.format(Format.java:140)
at org.orekit.errors.OrekitException.buildMessage(OrekitException.java:166)
at org.orekit.errors.OrekitException.getMessage(OrekitException.java:126)
at org.orekit.errors.OrekitException.getLocalizedMessage(OrekitException.java:138)
at java.lang.Throwable.toString(Throwable.java:343)
at java.lang.Throwable.(Throwable.java:242)
at java.lang.Exception.(Exception.java:77)
at java.lang.RuntimeException.(RuntimeException.java:77)
at org.orekit.time.AbsoluteDate.toString(AbsoluteDate.java:797)
at java.lang.String.valueOf(String.java:2826)
at java.io.PrintStream.println(PrintStream.java:771)
at AbsoluteDateStackOverflow.main(TestFrames1.java:27)
I've attached the class that generates this error.
This means that you must setup UTC. However this conflics with the
javadoc for UTCTAILoader.loadTimeSteps that states
>sorted UTC-TAI offsets entries (may be empty)
There doesn't seem to be a "simple" way to avoid this issue in
AbsoluteDate. Perhaps a warning can be added to the UTCTAILoader javadoc
that some valid entries must exist?
Simon Billemont
*(from redmine: issue id 111, created on 2012-09-07, closed on 2012-09-07)*
* Uploads:
* [AbsoluteDateStackOverflow.java](/uploads/65c311430d7e61a706f6a0a6b80df55e/AbsoluteDateStackOverflow.java) Minimal case that generates a StackOverflowError