Orekit issueshttps://gitlab.orekit.org/groups/orekit/-/issues2018-08-07T09:42:18Zhttps://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 StackOverflowErrorhttps://gitlab.orekit.org/orekit/orekit/-/issues/112SP3 position records are not converted to m from km.2018-08-07T09:42:25ZEvan WardSP3 position records are not converted to m from km.Hi,
The SP3Parser currently reports positions in km instead of m like the
rest of Orekit. I've attached a patch that updates SP3Parser and the
test case to use meters. The relevant part of the sp3 documentation is:
SP3 Line Twenty four...Hi,
The SP3Parser currently reports positions in km instead of m like the
rest of Orekit. I've attached a patch that updates SP3Parser and the
test case to use meters. The relevant part of the sp3 documentation is:
SP3 Line Twenty four (The Position and Clock Record)
(See example 1)
Column 1 Symbol P A1
Columns 2-4 Vehicle Id. G01 A1,I2.2
Columns 5-18 x-coordinate(km) \_-11044.805800 F14.6
Columns 19-32 y-coordinate(km) \_-10475.672350 F14.6
Columns 33-46 z-coordinate(km) \_\_21929.418200 F14.6
Thanks for the excellent library.
Evan
*(from redmine: issue id 112, created on 2012-09-18, closed on 2012-09-18)*
* Uploads:
* [sp3kmtom.patch](/uploads/2a925fe5af8961f648bac2689e32b5c8/sp3kmtom.patch) Nonehttps://gitlab.orekit.org/orekit/orekit/-/issues/113Strange behaviour with the TimeStampedCache and 3rd body ephemeris2018-08-07T09:42:30ZYannick TanguyStrange behaviour with the TimeStampedCache and 3rd body ephemerisWe encountered a problem while using 3rd body ephemeris on a long
period, across two JPL ephemeris files.
The following test case shows that when we ask for the moon position
between 1999 and 2002, there's a problem around year 2000, wh...We encountered a problem while using 3rd body ephemeris on a long
period, across two JPL ephemeris files.
The following test case shows that when we ask for the moon position
between 1999 and 2002, there's a problem around year 2000, when OREKIT
must load the new file.
Note that this test case needs to have two ephemeris file in the
resource folder.
*(from redmine: issue id 113, created on 2012-09-19, closed on 2012-09-19)*
* Uploads:
* [TimeStampedCacheBug.java](/uploads/54ecef0c25c8d94b85c10f2cb7e86872/TimeStampedCacheBug.java) None
* [unxp1950.405](/uploads/625d831eaeffac16fe127b64a7befb12/unxp1950.405) None
* [unxp2000.405](/uploads/dfd43c00ae9e38a3e595efe3a575d893/unxp2000.405) None
* [issue_113.patch](/uploads/d43a84d3c4cbe61853e6163125425c83/issue_113.patch) Nonehttps://gitlab.orekit.org/orekit/orekit/-/issues/114Unstability in KeplerianOrbit / shiftedBy with very big eccentricity2022-08-16T18:53:29ZYannick TanguyUnstability in KeplerianOrbit / shiftedBy with very big eccentricityWe noticed a strange bug with the shiftedBy method (with 0. offset !)
that occured with "weird" orbits, that became hyperbolic.
The following test is a simplified test :
- the initial orbit is a very excentric orbit, with a mean anoma...We noticed a strange bug with the shiftedBy method (with 0. offset !)
that occured with "weird" orbits, that became hyperbolic.
The following test is a simplified test :
- the initial orbit is a very excentric orbit, with a mean anomaly of 1
degree
- we add a big (!!) deltaV on Y, like in an impulse manoeuver, so the
orbit became very excentric
- we calculate PV coordinates
- we apply a shiftedBy(0) to the orbit ->we expect it to be the
same...
- we calculate PV coordinates and they are very different
Of course, this use case is not realistic, but the
KeplerianOrbit.shiftedByHyperbolic method seems to be unstable...
If we increment the deltaV progressively (see the second part of the
test), we see that the PVcoordinates (computed in
KeplerianOrbit.initPVCoordinatesHyperbolic) take some incoherent values
because the "posFactor" takes suddenly a very large value.
This seems to come from the quotient "(a \* (1 - e \* e)) / (1 + e \*
cosV)" :
->a and e become very big, and suddenly, cos(true anomaly) is very
close to 0.
I think the numerical instability comes from the conversions between
eccentric, mean and true anomaly, because the shiftedBy() method creates
a new orbit with mean anomaly, and then calls successively the methods
to compute eccentric and then true anomaly (see
"hyperbolicEccentricToTrue(meanToHyperbolicEccentric(anomaly))" in the
KeplerianOrbit constructror).
As I said, I think this instability only occurs on very weird orbits.
They don't correspond to a realistic flight domain.
But if we can localize the instability, it would be a good idea to
indicate some upper bound to orbit eccentricty, that OREKIT can manage.
*(from redmine: issue id 114, created on 2012-09-21, closed on 2012-09-21)*
* Relations:
* relates #135
* Uploads:
* [ShiftedByHyperbolicBug.java](/uploads/8ed437b612c1b88e3f7b040e3e0b32e6/ShiftedByHyperbolicBug.java) None
* [OREKIT_114.patch](/uploads/93294e71033d622b8279b9264399e667/OREKIT_114.patch) Nonehttps://gitlab.orekit.org/orekit/orekit/-/issues/115bug in GroundPointing's getAttitude()2018-08-07T09:42:35ZJulien Anxionnatbug in GroundPointing's getAttitude()We found a bug in the `getAttitude(...)` of `GroundPointing` class.
With the following code:
Attitude att1 = getAttitude(pvProv, date, frame1);
Attitude att2 = getAttitude(pvProv, date, frame2);
Attitude att3 = att2.withRe...We found a bug in the `getAttitude(...)` of `GroundPointing` class.
With the following code:
Attitude att1 = getAttitude(pvProv, date, frame1);
Attitude att2 = getAttitude(pvProv, date, frame2);
Attitude att3 = att2.withReferenceFrame(frame1);
the `att3` `Attitude` doesn't equal to `att1`, and it should be.
A possible solution could be:
public Attitude getAttitude(final PVCoordinatesProvider pvProv, final AbsoluteDate date,
final Frame frame)
throws OrekitException {
// inertial frame*
Frame eme2000 = FramesFactory.getEME2000();
// Construction of the satellite-target position/velocity vector at t-h, t and t+h
final double h = 0.1;
final AbsoluteDate dateM1H = date.shiftedBy(-h);
final PVCoordinates pvM1H = pvProv.getPVCoordinates(dateM1H, eme2000);
final Vector3D deltaPM1h = getTargetPoint(pvProv, dateM1H, eme2000).subtract(pvM1H.getPosition());
final PVCoordinates pv0 = pvProv.getPVCoordinates(date, eme2000);
final Vector3D deltaP0 = getTargetPoint(pvProv, date, eme2000).subtract(pv0.getPosition());
final AbsoluteDate dateP1H = date.shiftedBy(h);
final PVCoordinates pvP1H = pvProv.getPVCoordinates(dateP1H, eme2000);
final Vector3D deltaPP1h = getTargetPoint(pvProv, dateP1H, eme2000).subtract(pvP1H.getPosition());
// New orekit exception if null position.
if (deltaP0.equals(Vector3D.ZERO)) {
throw new OrekitException(OrekitMessages.SATELLITE_COLLIDED_WITH_TARGET);
}
// Attitude rotation:
// line of sight computed from inertial frame -> z satellite axis,
// satellite velocity computed from inertial frame -> x satellite axis.
final Rotation rot = new Rotation(deltaP0, pv0.getVelocity(), Vector3D.PLUS_K, Vector3D.PLUS_I);
// Attitude spin
final Rotation rotM1h = new Rotation(deltaPM1h, pvM1H.getVelocity(), Vector3D.PLUS_K, Vector3D.PLUS_I);
final Rotation rotP1h = new Rotation(deltaPP1h, pvP1H.getVelocity(), Vector3D.PLUS_K, Vector3D.PLUS_I);
final Vector3D spin = AngularCoordinates.estimateRate(rotM1h, rotP1h, 2 * h);
return new Attitude(date, eme2000, rot, spin).withReferenceFrame(frame);
}
Regards,
Julien
*(from redmine: issue id 115, created on 2012-09-21, closed on 2016-02-10)*https://gitlab.orekit.org/orekit/orekit/-/issues/116AbstractCelestialBody.InertiallyOriented.getTransform(...) syncronizes on Fra...2018-08-07T09:42:36ZEvan WardAbstractCelestialBody.InertiallyOriented.getTransform(...) syncronizes on FramesFactory.classHi,
Great progress on multi-threading recently!
In my test cases I found some synchronization that is not necessary. The
line:
final Transform t =
definingFrame.getTransformTo(FramesFactory.getEME2000(), date);
from AbstractCelestial...Hi,
Great progress on multi-threading recently!
In my test cases I found some synchronization that is not necessary. The
line:
final Transform t =
definingFrame.getTransformTo(FramesFactory.getEME2000(), date);
from AbstractCelestialBody.InertiallyOriented.getTransform(...) implies
syncronization on FramesFactory.class. This blocks when multiple
propagation threads are running that include third body effects. An easy
solution is to cache a reference to J2000 in AbstractCelestialBody so it
is not looked up every time. I've attached a patch that implements this.
This should be faster in the single thread case as well. With this
change in my multi-threaded test case I noticed cpu utilization jump
from ~30% to ~80%.
A possible downside is that the J2000 frame is created before it is
needed, but it is a cheap frame to create.
*(from redmine: issue id 116, created on 2012-09-21, closed on 2012-09-21)*
* Uploads:
* [cacheJ200inAbstractCelestialBody.patch](/uploads/f67a990dfa589f8cd60f34e1da679eb6/cacheJ200inAbstractCelestialBody.patch) Nonehttps://gitlab.orekit.org/orekit/orekit/-/issues/117Tidal Corrections are not thread safe2018-08-07T09:42:42ZEvan WardTidal Corrections are not thread safeHi,
I found that TidalCorrections is not thread safe, which makes any frame
through TIRF or ITRF unsafe. The effect is the same order of magnitude
as the tidal corrections, which made it hard to track down. I've
attached a failing test ...Hi,
I found that TidalCorrections is not thread safe, which makes any frame
through TIRF or ITRF unsafe. The effect is the same order of magnitude
as the tidal corrections, which made it hard to track down. I've
attached a failing test case.
Thanks,
Evan
*(from redmine: issue id 117, created on 2012-10-02, closed on 2012-10-02)*
* Uploads:
* [tidalCorrectionsTestCase.java](/uploads/88f362f1e184a15c76c70831c6452e49/tidalCorrectionsTestCase.java) None
* [TidalCorrection.java](/uploads/a34a7e0d174bb71dc636e01314adb54c/TidalCorrection.java) Thread-safe version using a TimeStampedCache
* [TidalCorrectionTest.java](/uploads/61531af11be3130453df83b4892c3372/TidalCorrectionTest.java) performance tests
* [TidalCorrection.java](/uploads/d749c24cabb051848b9e9f1115250665/TidalCorrection.java) Thread safe version using cache for individual data points (dx,dy,dt)https://gitlab.orekit.org/orekit/orekit/-/issues/118Earth Rotation Angle calculation in TIRF2000Provider is not thread safe2018-08-07T09:42:44ZEvan WardEarth Rotation Angle calculation in TIRF2000Provider is not thread safeHi,
I've found that the ERA calculation was not thread safe when calculating
the ERA for different dates. The magnitude of the bug is the same as the
ERA between the two dates, which can be huge. I've attached a patch for
the issue and ...Hi,
I've found that the ERA calculation was not thread safe when calculating
the ERA for different dates. The magnitude of the bug is the same as the
ERA between the two dates, which can be huge. I've attached a patch for
the issue and a test case. To fix the issue, I removed the instance
variable, era, and replaced it with direct calculation. The era was
already calculated on every call, so this **should** not be a
performance issue.
Thanks,
Evan
*(from redmine: issue id 118, created on 2012-10-03, closed on 2012-10-03)*
* Uploads:
* [TIRF2000ProviderTest.java](/uploads/32942761ee3ed1e915d329b6dd19b8cd/TIRF2000ProviderTest.java) Concurrent Test Case
* [tirf2000provider.patch](/uploads/b95671e2b12b8abd54a4d407399f1a10/tirf2000provider.patch) Fixhttps://gitlab.orekit.org/orekit/orekit/-/issues/119UT1Scale does not need to be syncronized2018-08-07T09:42:45ZEvan WardUT1Scale does not need to be syncronizedHi,
The UT1Scale offset methods do not need to be syncronized because they
only depend on other objects that store their data in a TimeStampedCache
(That is AbstractEOPHistory and UTCScale). I propose removing the
syncronized declaratio...Hi,
The UT1Scale offset methods do not need to be syncronized because they
only depend on other objects that store their data in a TimeStampedCache
(That is AbstractEOPHistory and UTCScale). I propose removing the
syncronized declaration so that these methods do not become a choke
point for concurrent applications.
I've attached a patch and a test case to check that offsetToTAI gives
the same answers independent of sequential or concurrent execution.
Thanks,
Evan
*(from redmine: issue id 119, created on 2012-10-04, closed on 2012-10-04)*
* Uploads:
* [ut1MT.patch](/uploads/a76ebfc8972f146758fb3ff55a3cb381/ut1MT.patch) Fix and test casehttps://gitlab.orekit.org/orekit/orekit/-/issues/120Typo on an inner class2018-08-07T09:42:46ZChristophe Le BrisTypo on an inner classReally really small remark about the spelling of an inner class in the
class "OsculatingToMeanElementsConverter".
One of the inner classes is spelled "Qua\*t\*ratureComputation" instead
of "Qua\*d\*ratureComputation".
*(from redmine:...Really really small remark about the spelling of an inner class in the
class "OsculatingToMeanElementsConverter".
One of the inner classes is spelled "Qua\*t\*ratureComputation" instead
of "Qua\*d\*ratureComputation".
*(from redmine: issue id 120, created on 2012-10-07, closed on 2012-10-07)*https://gitlab.orekit.org/orekit/orekit/-/issues/121osculating to mean elements2018-08-07T09:42:50ZDaniel Aguilar Taboadaosculating to mean elementsIt seems that there is an issue within the
OsculatingToMeanElementsConverter class. I was getting some errors and
after investigating a bit, here is where I see the problem:
Function "value", within QuadratureComputation class, accepts ...It seems that there is an issue within the
OsculatingToMeanElementsConverter class. I was getting some errors and
after investigating a bit, here is where I see the problem:
Function "value", within QuadratureComputation class, accepts time
offset (sec) as input. However, angular offset (rad) is given as inputs
to "quadrature.solve".
*(from redmine: issue id 121, created on 2012-10-16, closed on 2012-10-16)*
* Uploads:
* [issue_121.patch](/uploads/ea149c29159cb45a580bb41cf0732bdb/issue_121.patch) None
* [OsculatingToMeanElementsConverterTest.java](/uploads/90b52f93c6b934ecabace950d6c145ba/OsculatingToMeanElementsConverterTest.java) None
* [OsculatingToMeanElementsConverter.java](/uploads/13d72c8829cc4ebf7a78988914ac1c30/OsculatingToMeanElementsConverter.java) None
* [OsculatingToMeanElementsConverter.java](/uploads/9dacde3dd933f163010e6f5a88da5ece/OsculatingToMeanElementsConverter.java) None
* [OsculatingToMeanElementsConverterTest.java](/uploads/07cbacdacd652d67c8fc5a2ffb9a48f9/OsculatingToMeanElementsConverterTest.java) Nonehttps://gitlab.orekit.org/orekit/orekit/-/issues/122Frames and WeakHashMap2018-08-07T09:42:53ZEvan WardFrames and WeakHashMapDiscussion started on the ML:
https://www.orekit.org/wws/arc/orekit-developers/2012-10/msg00000.html
Summary: Remove WeakHashMaps to improve performance.
I've attached a patch that removes Frame.common and uses a HashMap in
FramesFacto...Discussion started on the ML:
https://www.orekit.org/wws/arc/orekit-developers/2012-10/msg00000.html
Summary: Remove WeakHashMaps to improve performance.
I've attached a patch that removes Frame.common and uses a HashMap in
FramesFactory.
If more performance is desired in Frame.findCommon() then pathToRoot()
could be converted to a final field (read only) as it is invariant once
the instance is created.
*(from redmine: issue id 122, created on 2012-10-17, closed on 2012-10-17)*
* Uploads:
* [weakHashMapFrames.patch](/uploads/5fd879e09f56c2facf7bdc7f2fbac3da/weakHashMapFrames.patch) Nonehttps://gitlab.orekit.org/orekit/orekit/-/issues/123javadoc: orbit.interpolate and all timeinterpolable classes2018-08-07T09:42:54ZBruno Revelinjavadoc: orbit.interpolate and all timeinterpolable classesThe interpolate method uses a Hermite interpolator which is not safe
when using too many sample points: it may loop endlessly in the
process.
The javadoc of each method interpolate should warn users not to provide
too many sample point...The interpolate method uses a Hermite interpolator which is not safe
when using too many sample points: it may loop endlessly in the
process.
The javadoc of each method interpolate should warn users not to provide
too many sample points in the input Orbit collection.
A good practice should probably be no more than 20 sample points.
*(from redmine: issue id 123, created on 2012-11-13, closed on 2012-11-13)*https://gitlab.orekit.org/orekit/orekit/-/issues/124Initial behavior of DSST according to DSSTCentralBody force model initialization2018-08-07T09:42:55ZChristophe Le BrisInitial behavior of DSST according to DSSTCentralBody force model initializationMy problem is related to the initialization or not of the
DSSTCentralBody force model before launching the propagation.
In the tutorial, there is no call to the "Initialize" method of
DSSTCentralBody before starting the propagation. Bu...My problem is related to the initialization or not of the
DSSTCentralBody force model before launching the propagation.
In the tutorial, there is no call to the "Initialize" method of
DSSTCentralBody before starting the propagation. But, in the online
documentation, it's written that "This method has to be triggered just
before the first propagation".
When I added a call to this method, the propagation was completely
different: I wasn't expecting such behavior.
Is there a misunderstanding from my side on the configuration of DSST in
Orekit?
Attached to this report, you will find the 2 plots (one with a call to
"initialize" and one without) and the java source code used.
*(from redmine: issue id 124, created on 2012-11-16, closed on 2012-11-16)*
* Uploads:
* ![with_no_init](/uploads/2907b39290a0d07710390da136d28cad/with_no_init.png) Plot when no call to "Initialize" method is made
* ![with_init](/uploads/4dab5567d5f744ff8ef0fcaa964a6290/with_init.png) Plot when a call to "Initialize" method is made before propagation
* [DSSTpropagation.java](/uploads/f29b486ca7315c41688ab10d94c0b467/DSSTpropagation.java) Source code examplehttps://gitlab.orekit.org/orekit/orekit/-/issues/125event detector behavior during propagator.resetInitialState2018-08-07T09:42:56ZBruno Revelinevent detector behavior during propagator.resetInitialStateWhen using method AbstractPropagator.resetInitialState, event detectors
included in that propagator are not reset. More precisely, the g
function is not initialized for this new initialState. Therefore during
the next propagation, the ev...When using method AbstractPropagator.resetInitialState, event detectors
included in that propagator are not reset. More precisely, the g
function is not initialized for this new initialState. Therefore during
the next propagation, the evaluation of g might not lead to its sign
change as may be expected, especially if the new propagation goes
backwards from the initialState.
In the attached file, a Junit test file for altitudeDetector that fails
because of this issue.
*(from redmine: issue id 125, created on 2012-11-30, closed on 2012-11-30)*
* Uploads:
* [AtltitudeDetectorTest.java](/uploads/aae1c40d89b44954305edb207d63b648/AtltitudeDetectorTest.java) Nonehttps://gitlab.orekit.org/orekit/orekit/-/issues/126Overflow in GravityFieldFactory.getUnnormalizationFactors(...)2018-08-07T09:42:58ZEvan WardOverflow in GravityFieldFactory.getUnnormalizationFactors(...)Using the snapshot that updated the potential provider interface I found
that I could not load the eigen-5c.gfc gravity field (360x360) provided
in the orekit-data zip due to the exception:
org.orekit.errors.OrekitException: missing...Using the snapshot that updated the potential provider interface I found
that I could not load the eigen-5c.gfc gravity field (360x360) provided
in the orekit-data zip due to the exception:
org.orekit.errors.OrekitException: missing gravity field coefficient C(171, 1) in file .../src/test/resources/orekit-data/orekit-data.zip!orekit-data/Potential/eigen-5c.gfc
at org.orekit.forces.gravity.potential.PotentialCoefficientsReader.setUnNormalizedC(PotentialCoefficientsReader.java:208)
at org.orekit.forces.gravity.potential.PotentialCoefficientsReader.setNormalizedC(PotentialCoefficientsReader.java:193)
at org.orekit.forces.gravity.potential.ICGEMFormatReader.loadData(ICGEMFormatReader.java:322)
I beleive this is due to the calculations in
GravityFieldFactory.getUnnormalizationFactors() as n increases.
`mfactNPlusM` overflows at `n=86` and causes many computed factors to be
zero. At `n=171`, `factN` overflows and the factors become NaNs.
I did not have this problem under the old api because I could request
normalized coefficients.
IMHO since the API is still new it would make sence to switch it to use
fully normalized coeffiects in order to support gravity fields with a
high degree and order. Rearanging the math would help some, but degree
and order would still be limited. For example, in the eigen-5c gravity
model the C\_360,360 ~ 2e-15 and the unnormalization factor is ~
1e-1740. Of course the result cannot fit in a double and all the
information is lost if unnormalized coefficients are used.
In my application I am trying to use high order fields as in this paper
by Holmes and Featherstone (2002):
http://cct.gfy.ku.dk/publ\_others/ccta1870.pdf
*(from redmine: issue id 126, created on 2013-01-09, closed on 2013-01-09)*https://gitlab.orekit.org/orekit/orekit/-/issues/127Build fails due to not meeting jacoco targets2018-08-07T09:42:59ZEvan WardBuild fails due to not meeting jacoco targetsexecuting \`mvn install\` fails due to jacoco plugin failing the project
for insufficient test coverage.
One way to fix the build, until the unit test targets are met, is turn
the errors in to warnings using:
false
I've attached a...executing \`mvn install\` fails due to jacoco plugin failing the project
for insufficient test coverage.
One way to fix the build, until the unit test targets are met, is turn
the errors in to warnings using:
false
I've attached a small patch that does this.
*(from redmine: issue id 127, created on 2013-02-12, closed on 2013-02-12)*
* Uploads:
* [jacoco.patch](/uploads/f0f85dbd8ca856e079b561b3646279b7/jacoco.patch) Nonehttps://gitlab.orekit.org/orekit/orekit/-/issues/129Ephemeris.getFrame() throws NPE2018-08-07T09:43:01ZEvan WardEphemeris.getFrame() throws NPEEphememris.getFrame() (as implemented in AbstractPropagator) will always
throw a NPE because Ephemeris does not use
AbstractPropagator.initialState. Are there other propagators that don't
use the initialState variable? They may have this...Ephememris.getFrame() (as implemented in AbstractPropagator) will always
throw a NPE because Ephemeris does not use
AbstractPropagator.initialState. Are there other propagators that don't
use the initialState variable? They may have this same bug.
I've attached a test case and patch that fixes it for Ephemeris. The
easy fix would be to change AbstractPropagator.getFrame() to
public Frame getFrame() {
return getInitialState().getFrame();
}
but that won't work because (counterintuitively) getInitialState() is
declared to throw a PropagationException.
Thanks in advance,
Evan
*(from redmine: issue id 129, created on 2013-03-22, closed on 2013-03-22)*
* Uploads:
* [Ephemeris.getFrame.patch](/uploads/74539174b5f426b3f8369444c92a22b5/Ephemeris.getFrame.patch)
* [getFrame.patch](/uploads/36b56dd961a10ecadad91308286e406b/getFrame.patch) v2