Orekit merge requestshttps://gitlab.orekit.org/orekit/orekit/-/merge_requests2020-05-15T08:47:03Zhttps://gitlab.orekit.org/orekit/orekit/-/merge_requests/66Issue #6052020-05-15T08:47:03ZBryan CazabonneIssue #605Fix issue #605Fix issue #60510.2https://gitlab.orekit.org/orekit/orekit/-/merge_requests/99Resolve "initial blanks in some gravity fields headers prevent loading them"2020-11-05T12:44:16ZLuc MaisonobeResolve "initial blanks in some gravity fields headers prevent loading them"Closes #731Closes #73110.3https://gitlab.orekit.org/orekit/orekit/-/merge_requests/100Resolve "initial blanks in some gravity fields headers prevent loading them"2020-11-05T13:21:41ZLuc MaisonobeResolve "initial blanks in some gravity fields headers prevent loading them"Closes #731Closes #73110.3https://gitlab.orekit.org/orekit/orekit/-/merge_requests/294Draft: Fix Issue 949 - No initialization of initialState in Ephemeris, Integr...2023-03-03T15:38:45ZVincent CUCCHIETTIvincent.cucchietti@csgroup.euDraft: Fix Issue 949 - No initialization of initialState in Ephemeris, IntegratedEphemeris and AdapterPropagator constructors.## <a href="https://gitlab.orekit.org/orekit/orekit/-/issues/949"> Issue 949 </a>
This issue was opened because it was found that propagating an <b>IntegratedEphemeris</b> with a <b>StateCovarianceMatrixProvider</b> would result in <b>N...## <a href="https://gitlab.orekit.org/orekit/orekit/-/issues/949"> Issue 949 </a>
This issue was opened because it was found that propagating an <b>IntegratedEphemeris</b> with a <b>StateCovarianceMatrixProvider</b> would result in <b>NullPointerException</b> being thrown.
After further investigation, it was found that this error would happen with the followings inheritors of <b>AbstractAnalyticalPropagator</b> :
<ul>
<li>Ephemeris</li>
<li>IntegratedEphemeris</li>
<li>AdapterPropagator</li>
<li>GLONASSAnalyticalPropagator</li>
<li>GNSSPropagator</li>
<li>SBASPropagator</li>
</ul>
In addition, one need to use an additional state provider which actually uses its own ```init()``` method (and not the default, empty one) for this exception to be thrown.
## Solution
The solution is straightforward for inheritors of <b>AbstractAnalyticalPropagator</b> that have their own ```getInitialState()``` method defined, we only need to add the following in their respective constructor : ```super.resetInitialState(getInitialState());``` (slightly different solution depending on the case).
For now and with this merge request, the following classes would be fixed :
<ul>
<li>Ephemeris</li>
<li>IntegratedEphemeris</li>
<li>AdapterPropagator (depends on given propagator but will be ready when all propagators are fixed)</li>
</ul>https://gitlab.orekit.org/orekit/orekit/-/merge_requests/298Fix issue 924: Numerical noise in ThrustPropulsionModel and tests2022-09-16T14:17:31ZMaxime JournotFix issue 924: Numerical noise in ThrustPropulsionModel and testsFixes #924.
@evanward1 , I put you as reviewer as you opened the issue.
I simply removed the incriminated comments.
There is indeed a numerical difference when doing:
1. `acc = new Vector3D(thrust / s.getMass(), maneuverAttitude.get...Fixes #924.
@evanward1 , I put you as reviewer as you opened the issue.
I simply removed the incriminated comments.
There is indeed a numerical difference when doing:
1. `acc = new Vector3D(thrust / s.getMass(), maneuverAttitude.getRotation().applyInverseTo(direction));` (current code)
2. `acc = new Vector3D(1. / s.getMass(), maneuverAttitude.getRotation().applyInverseTo(thrustVector));` (better code?)
(or the `Field` equivalent of these)
It's a small difference due to the usage of `getNorm()` for the module (about 1e-17/18 on the acceleration norm in the tests I have checked).
The thing is, before we changed the `maneuvers` package it was like (1) and we left it like this.
Mostly because some tests in `PolynomialAccelerationTest` and `HarmonicAccelerationModelTest` compare the outputs of propagation to a propagation with an equivalent maneuver.
Since the definition of the forces is given like (1) in `PolynomialAcceleration` and `HarmonicAccelerationModel` tests, the differences are all zeros.
If we use (2) in `ThrustPropulsionModel`, numerical differences appear because of integration of the acceleration during propagation.
(See for example `PolynomialAccelerationTest#testEquivalentTangentialManeuver`)
Maybe the tolerances are too tight but I don't feel like changing all the tolerances of the tests for this small change.
Tell me what you think.11.3https://gitlab.orekit.org/orekit/orekit/-/merge_requests/343Modification of GLONASS parser per issue 10332023-02-16T22:17:02ZJonathan HoodModification of GLONASS parser per issue 1033modified GLONASS parser to set ToC and Date directly to ingested date instead of rounded GPS date per RINEX 8.1 specifications noting that GLONASS time is aligned with UTC and not with GPS timemodified GLONASS parser to set ToC and Date directly to ingested date instead of rounded GPS date per RINEX 8.1 specifications noting that GLONASS time is aligned with UTC and not with GPS time11.3.2https://gitlab.orekit.org/orekit/orekit/-/merge_requests/369Stop using internal JDK methods (needed for Java 17 compilation)2023-06-30T12:08:33ZLUGANStop using internal JDK methods (needed for Java 17 compilation)11.3.3https://gitlab.orekit.org/orekit/orekit/-/merge_requests/382Draft:Issue 9472023-09-30T14:56:11ZAlberto FerreroDraft:Issue 947Closes #947
As discussed in https://forum.orekit.org/t/from-osculating-to-mean-elements-with-brouwer-lyddane-propagator/1867
Brouwner Lyddane propagator is failing for near-circular orbits.
Idea is to convert to `EquinoctialOrbit` or ...Closes #947
As discussed in https://forum.orekit.org/t/from-osculating-to-mean-elements-with-brouwer-lyddane-propagator/1867
Brouwner Lyddane propagator is failing for near-circular orbits.
Idea is to convert to `EquinoctialOrbit` or `CartesianOrbit` to avoid the exception on `KeplerianOrbit` constructor.https://gitlab.orekit.org/orekit/orekit/-/merge_requests/416Draft: Fixed issue 1205: failing tests after correction of Hipparchus issue 2532023-10-18T21:38:01ZVincent CUCCHIETTIvincent.cucchietti@csgroup.euDraft: Fixed issue 1205: failing tests after correction of Hipparchus issue 253Hey everyone,
This mr aims to fix the errors introduced by the fix of hipparchus issue 253.
I fixed the failing tests in the SSA package but some tests still need to be fixed :
```
869472 [ERROR] HaloOrbitTest.testManifolds:158 » Mat...Hey everyone,
This mr aims to fix the errors introduced by the fix of hipparchus issue 253.
I fixed the failing tests in the SSA package but some tests still need to be fixed :
```
869472 [ERROR] HaloOrbitTest.testManifolds:158 » MathIllegalArgument non symmetric matrix: th...
869472 [ERROR] LyapunovOrbitTest.testManifolds:150 » MathIllegalArgument non symmetric matrix...
```
Closes #1205
Cheers,
VincentVincent CUCCHIETTIvincent.cucchietti@csgroup.euVincent CUCCHIETTIvincent.cucchietti@csgroup.euhttps://gitlab.orekit.org/orekit/orekit/-/merge_requests/462Draft: Fixed issue 1273: Resolve "TimeSystem parsing in SP3Parser"2024-03-16T14:26:17ZMark RuttenDraft: Fixed issue 1273: Resolve "TimeSystem parsing in SP3Parser"Closes #1273.
I've fixed the bug and added a single test. I've included a partial QZSS SP3 file, with the number of time-steps edited down to one.Closes #1273.
I've fixed the bug and added a single test. I've included a partial QZSS SP3 file, with the number of time-steps edited down to one.12.0.2https://gitlab.orekit.org/orekit/orekit/-/merge_requests/465Closes #1296: Make lazy loading of UTC thread safe by checking if already...2024-03-16T14:25:37ZChristopher SchankCloses #1296: Make lazy loading of UTC thread safe by checking if already...Fix issue-1296: Make lazy loading of UTC thread safe by checking if already loaded inside synchronized block
Closes #1296Fix issue-1296: Make lazy loading of UTC thread safe by checking if already loaded inside synchronized block
Closes #129612.0.2