Orekit issueshttps://gitlab.orekit.org/orekit/orekit/-/issues2021-08-19T08:11:05Zhttps://gitlab.orekit.org/orekit/orekit/-/issues/827SP3Parser supposes time scale is GPS2021-08-19T08:11:05ZBryan CazabonneSP3Parser supposes time scale is GPSWhen parsing position and velocity epochs of a SP3 file, the `SP3Parser` supposes that the time system is GPS (See line 281 of the parser).
```
280 hasVelocityEntries = false;
281 timeScale = timeScales.g...When parsing position and velocity epochs of a SP3 file, the `SP3Parser` supposes that the time system is GPS (See line 281 of the parser).
```
280 hasVelocityEntries = false;
281 timeScale = timeScales.getGPS();
282 maxSatellites = 0;
```
However, according to [SP3-c](https://files.igs.org/pub/data/format/sp3c.txt?_ga=2.209137691.821039935.1629300048-348441339.1579016726) and [SP3-d](https://files.igs.org/pub/data/format/sp3d.pdf?_ga=2.213455005.821039935.1629300048-348441339.1579016726) standards, the time system can be different from GPS. It is specified in line thirteen for SP3-c and twenty one for SP3-d. For SP3-a, the time system is GPS.11.0Bryan CazabonneBryan Cazabonnehttps://gitlab.orekit.org/orekit/orekit/-/issues/803Issue to parse position sometimes from SP3 files to due the latestClock value...2021-08-19T07:23:13ZGhost UserIssue to parse position sometimes from SP3 files to due the latestClock value in SP3Parser.javaIn some SP3 files, the lines that should contain the position (x, y, z) and latestClock value does not contain the latestClock therefore we get a NullPointerException.
If the latestClock value in the SP3 file does not exist, this variabl...In some SP3 files, the lines that should contain the position (x, y, z) and latestClock value does not contain the latestClock therefore we get a NullPointerException.
If the latestClock value in the SP3 file does not exist, this variable should be set to a default value = 999999.999999
note : Some Analysis and Combination centers such as NSGS, JCET and other seem to not give the latestClock value while BLG seems to always gives the default latestClock value.
Here is an example of a file that does not work :
[nsgf.orb.lageos2.160305.v35.sp3](/uploads/abbb7c844d66d5a6cc729ddf7460e9f9/nsgf.orb.lageos2.160305.v35.sp3)11.0Bryan CazabonneBryan Cazabonnehttps://gitlab.orekit.org/orekit/orekit/-/issues/817Use observed solar flux instead of adjusted flux for NRLMSISE00 in CssiSpaceW...2021-08-18T14:41:43ZMaxime JournotUse observed solar flux instead of adjusted flux for NRLMSISE00 in CssiSpaceWeatherDataObserved solar flux should be used instead of adjusted flux for NRLMSISE00 in CssiSpaceWeatherData.
See [this forum thread](https://forum.orekit.org/t/cssispaceweatherdata-java-using-adjusted-and-not-observed-flux-values) for more details.Observed solar flux should be used instead of adjusted flux for NRLMSISE00 in CssiSpaceWeatherData.
See [this forum thread](https://forum.orekit.org/t/cssispaceweatherdata-java-using-adjusted-and-not-observed-flux-values) for more details.11.0https://gitlab.orekit.org/orekit/orekit/-/issues/721Add EventDetector to EventHandler.init(...)2021-08-18T12:42:29ZEvan WardAdd EventDetector to EventHandler.init(...)Add the `EventDetector` as a method parameter to `EventHandler.init(...)`. Lets the handler know some information about the detector before any events occur.Add the `EventDetector` as a method parameter to `EventHandler.init(...)`. Lets the handler know some information about the detector before any events occur.11.0Bryan CazabonneBryan Cazabonnehttps://gitlab.orekit.org/orekit/orekit/-/issues/815Failing test cases in XmlGeneratorTest2021-08-18T11:12:12ZMaxime JournotFailing test cases in XmlGeneratorTestThe 4 tests of class XmlGeneratorTest fail with the following messages:
```
[ERROR] XmlGeneratorTest.testCcsdsUnits:56 expected:<..." encoding="UTF-8"?>[
<KEY_1 units="km*kg**3/s**0.5">1234.5678</KEY_1>
<KEY_2>1234567.8</KEY_2>
<KEY_3>...The 4 tests of class XmlGeneratorTest fail with the following messages:
```
[ERROR] XmlGeneratorTest.testCcsdsUnits:56 expected:<..." encoding="UTF-8"?>[
<KEY_1 units="km*kg**3/s**0.5">1234.5678</KEY_1>
<KEY_2>1234567.8</KEY_2>
<KEY_3>1234567.8</KEY_3>
<LOOOOONG>1234567.8</LOOOOONG>]
> but was:<..." encoding="UTF-8"?>[
<KEY_1 units="km*kg**3/s**0.5">1234.5678</KEY_1>
<KEY_2>1234567.8</KEY_2>
<KEY_3>1234567.8</KEY_3>
<LOOOOONG>1234567.8</LOOOOONG>
]
>
[ERROR] XmlGeneratorTest.testNoUnits:86 expected:<..." encoding="UTF-8"?>[
<KEY_1>90.0</KEY_1>
<KEY_2>180.0</KEY_2>]
> but was:<..." encoding="UTF-8"?>[
<KEY_1>90.0</KEY_1>
<KEY_2>180.0</KEY_2>
]
>
[ERROR] XmlGeneratorTest.testSections:38 expected:<..." encoding="UTF-8"?>[
<abc id="CCSDS_ABC_VERSION" version="99.0">
<BLOCK>
<KEY units="Hz">1234567.8</KEY>
</BLOCK>
</abc>]
> but was:<..." encoding="UTF-8"?>[
<abc id="CCSDS_ABC_VERSION" version="99.0">
<BLOCK>
<KEY units="Hz">1234567.8</KEY>
</BLOCK>
</abc>
]
>
[ERROR] XmlGeneratorTest.testUnitsPadding:72 expected:<..." encoding="UTF-8"?>[
<KEY_1 units="deg">90.0</KEY_1>
<KEY_2 units="deg">180.0</KEY_2>
<PERCENT units="%">25.0</PERCENT>]
> but was:<..." encoding="UTF-8"?>[
<KEY_1 units="deg">90.0</KEY_1>
<KEY_2 units="deg">180.0</KEY_2>
<PERCENT units="%">25.0</PERCENT>
]
>
```
This is a format String error. The same error was detected and corrected in Hipparchus by changing, for example for "testSections()"
```
Assert.assertEquals("<?xml version=\"1.0\" encoding=\"UTF-8\"?>\n" +
"<abc id=\"CCSDS_ABC_VERSION\" version=\"99.0\">\n" +
" <BLOCK>\n" +
" <KEY units=\"Hz\">1234567.8</KEY>\n" +
" </BLOCK>\n" +
"</abc>\n",
caw.toString());
```
With:
```
Assert.assertEquals(String.format("<?xml version=\"1.0\" encoding=\"UTF-8\"?>%n" +
"<abc id=\"CCSDS_ABC_VERSION\" version=\"99.0\">%n" +
" <BLOCK>%n" +
" <KEY units=\"Hz\">1234567.8</KEY>%n" +
" </BLOCK>%n" +
"</abc>%n"),
caw.toString());
```11.0https://gitlab.orekit.org/orekit/orekit/-/issues/824Improve contributing guide with Sonar configuration2021-08-18T09:15:16ZBryan CazabonneImprove contributing guide with Sonar configurationThe [contributing.md](https://gitlab.orekit.org/orekit/orekit/-/blob/develop/src/site/markdown/contributing.md) file could be improved to include Sonar configuration as described by @sdinot in the [following description](https://forum.or...The [contributing.md](https://gitlab.orekit.org/orekit/orekit/-/blob/develop/src/site/markdown/contributing.md) file could be improved to include Sonar configuration as described by @sdinot in the [following description](https://forum.orekit.org/t/improve-investigation-while-encoutering-a-mathillegalstateexception/1110/27?u=bcazabonne). However, the Sonar configuration could be highlighted as an optional step of a contribution since the changes performed in !177.
After updating the contributing guide, the `Please, configure SonarQube!` message in [.gitlab-ci.yml](https://gitlab.orekit.org/orekit/orekit/-/blob/develop/.gitlab-ci.yml) (line 50) could be replaced by `Please, configure SonarQube by following steps described in the contribution guide: https://www.orekit.org/site-orekit-latest/contributing.html`11.0https://gitlab.orekit.org/orekit/orekit/-/issues/820TLEJacobianMapper provides inconsistent Jacobian2021-08-16T12:51:04ZPascal ParraudTLEJacobianMapper provides inconsistent JacobianThe `getStateJacobian` method of the [TLEJacobiansMapper](https://gitlab.orekit.org/orekit/orekit/-/blob/develop/src/main/java/org/orekit/propagation/analytical/tle/TLEJacobiansMapper.java) class provides the Jacobian with respect to Kep...The `getStateJacobian` method of the [TLEJacobiansMapper](https://gitlab.orekit.org/orekit/orekit/-/blob/develop/src/main/java/org/orekit/propagation/analytical/tle/TLEJacobiansMapper.java) class provides the Jacobian with respect to Keplerian elements while the same method of the [JacobiansMapper](https://gitlab.orekit.org/orekit/orekit/-/blob/develop/src/main/java/org/orekit/propagation/numerical/JacobiansMapper.java) class provides the Jacobian with respect to Cartesian elements.
1. it is not clear and should be documented in both cases,
2. the inconsistency comes from the fact that the elements are not ordered in the same way as those of the Jacobian provided by the `computeJacobianMeanWrtCartesian` of the [KeplerianOrbit](https://gitlab.orekit.org/orekit/orekit/-/blob/develop/src/main/java/org/orekit/orbits/KeplerianOrbit.java) class, i.e. the first ones are ordered as a, e, i, **Ω, ω**, M while the second ones are ordered as a, e, i, **ω, Ω**, M. Applying directly the chain rule to get the state Jacobian wrt Cartesian elements for example will will produce an incorrect result.11.0Bryan CazabonneBryan Cazabonnehttps://gitlab.orekit.org/orekit/orekit/-/issues/799Use `CalculusFieldElement.getPi()` instead of `FastMath.PI`/`MathUtils.SEMI_P...2021-08-12T19:30:21ZLuc MaisonobeUse `CalculusFieldElement.getPi()` instead of `FastMath.PI`/`MathUtils.SEMI_PI` for field algorithmsThis issue is related to Hipparchus [issue 141](https://github.com/Hipparchus-Math/hipparchus/issues/141).
The problem is that if the field correspond to extended precision, like Hipparchus `Dfp` or `Apfloat`,
then using expressions like...This issue is related to Hipparchus [issue 141](https://github.com/Hipparchus-Math/hipparchus/issues/141).
The problem is that if the field correspond to extended precision, like Hipparchus `Dfp` or `Apfloat`,
then using expressions like `x.multiply(FastMath.PI)` (or `MathUtils.SEMI_PI`) loses precision.11.0Bryan CazabonneBryan Cazabonnehttps://gitlab.orekit.org/orekit/orekit/-/issues/821Add support for CCSDS TDM V2.02021-08-12T19:30:20ZLuc MaisonobeAdd support for CCSDS TDM V2.0As discussed in the forum on thread [TDMParser update](https://forum.orekit.org/t/tdmparser-update/1100),
a new version of the Tracking Data Messages format has been published in 2020.
Orekit should support reading/writing this new versi...As discussed in the forum on thread [TDMParser update](https://forum.orekit.org/t/tdmparser-update/1100),
a new version of the Tracking Data Messages format has been published in 2020.
Orekit should support reading/writing this new version of the format. The library already supports version 1.0 since several releases.11.0Luc MaisonobeLuc Maisonobehttps://gitlab.orekit.org/orekit/orekit/-/issues/626remove interface Comparable from IntegerLeastSquareSolution2021-08-12T09:46:32ZLuc Maisonoberemove interface Comparable from IntegerLeastSquareSolutionThe `IntegerLeastSquareSolution` implements `Comparable` but this is
not strictly needed from an API point of view. The sorting order
of various solutions is more related to the algorithm that solves the
integer least squares problem and...The `IntegerLeastSquareSolution` implements `Comparable` but this is
not strictly needed from an API point of view. The sorting order
of various solutions is more related to the algorithm that solves the
integer least squares problem and is generally related only to some
properties (the squared distance to the float solution), not to the
other properties (the integers).
Having `IntegerLeastSquareSolution` implement `Comparable` also implies
implementing `equals` which itself involves implementing `hashCode`.
However, from a logical point of view, these two methods should depend
on all properties, not only on the squared distance, and therefore be
inconsistent with `compareTo`.
It would be more consistent if `IntegerLeastSquareSolution` does not
implement `Comparable` but the solver uses a separate and dedicated
`Comparator` for sorting.
This change is however backward incompatible, so it can be done only
for a major release.11.0Bryan CazabonneBryan Cazabonnehttps://gitlab.orekit.org/orekit/orekit/-/issues/805Wrong equation in IERS Conventions computation of geopotential coefficient ch...2021-08-11T15:24:54ZPol MesallesWrong equation in IERS Conventions computation of geopotential coefficient changes due to solid Earth pole tideIn `IERSConventions.java`, both for `IERS_2003` and `IERS_2010`, there appears to be an error in the ratio used to compute the corrections to the geopotential coefficients due to the effect of the solid Earth pole tide.
The equations pu...In `IERSConventions.java`, both for `IERS_2003` and `IERS_2010`, there appears to be an error in the ratio used to compute the corrections to the geopotential coefficients due to the effect of the solid Earth pole tide.
The equations published in the [IERS Technical Note No. 36](https://www.iers.org/IERS/EN/Publications/TechnicalNotes/tn36.html) (IERS Conventions 2010) read:
```
∆C₂₁ = −1.333 × 10⁻⁹ (m₁ + 0.0115m₂)
∆S₂₁ = −1.333 × 10⁻⁹ (m₂ − 0.0115m₁)
```
which is the same that the comments in the file suggest. However, in both line 1281 and 1812, the ratio is implemented as 0.00115 (an additional 0). The comments in the `IERS_2003` section (see lines 1333~1358) indicate that there already was a sign issue that was corrected in the IERS 2010 Conventions, and in fact go on to demonstrate the origin of the error by estimating the ratio as:
```
Im(k₂)/Re(k₂)
where k₂ is the complex number 0.3077 + 0.0036i, yielding
ratio ≈ Im(k₂)/Re(k₂) ≈ 0.0115 (not 0.00115)
```
I believe this is an error in the implementation that is very easy to fix and should be corrected asap because it will lead to incorrect values of accelerations during propagations that include solid tide forces.11.0Pol MesallesPol Mesalleshttps://gitlab.orekit.org/orekit/orekit/-/issues/785Add license badge to Readme file2021-08-11T13:41:39ZBryan CazabonneAdd license badge to Readme fileIt could be an interesting documentation enhancement to add the license badge in the README.md file ([like Hipparchus project](https://github.com/Hipparchus-Math/hipparchus#readme))It could be an interesting documentation enhancement to add the license badge in the README.md file ([like Hipparchus project](https://github.com/Hipparchus-Math/hipparchus#readme))11.0Bryan CazabonneBryan Cazabonnehttps://gitlab.orekit.org/orekit/orekit/-/issues/795Atmospheric model NRLMSISE-00: problem at 35 km2021-08-11T06:47:10ZGuylaine PratAtmospheric model NRLMSISE-00: problem at 35 kmFor the atmospheric model [NRLMSISE-00](src/main/java/org/orekit/models/earth/atmosphere/NRLMSISE00.java), there is a bug when altitude is exactly (at machine accuracy) = 35.0000000... km, identical to the one corrected in the [C version...For the atmospheric model [NRLMSISE-00](src/main/java/org/orekit/models/earth/atmosphere/NRLMSISE00.java), there is a bug when altitude is exactly (at machine accuracy) = 35.0000000... km, identical to the one corrected in the [C version](https://git.linta.de/?p=~brodo/nrlmsise-00.git;a=commitdiff;h=bc9a2feba4344e74201281e563332688a4d09cc3#patch2).
The test: ``` if (alt < ZN3[0]) ``` should be changed to ``` if (alt <= ZN3[0]) ```
TBN:
the ftp site (for the Fortran version) is no longer available. As seen in [NRLMSISE-00 - Dr. Dominik Brodowski](https://www.brodo.de/space/nrlmsise/index.html) page, the Fortran page should be http://uap-www.nrl.navy.mil/models_web/msis/msis_home.htm but is not available either ...11.0Bryan CazabonneBryan Cazabonnehttps://gitlab.orekit.org/orekit/orekit/-/issues/652Remove deprecated methods from BoxAndSolarArraySpacecraft class2021-08-10T07:16:12ZMaxime JournotRemove deprecated methods from BoxAndSolarArraySpacecraft classThis action was forgotten for version 10.0.
Should be done for version 11.0.This action was forgotten for version 10.0.
Should be done for version 11.0.11.0https://gitlab.orekit.org/orekit/orekit/-/issues/789EphemerisFileParser.parse(...) from a Reader2021-08-09T18:42:22ZEvan WardEphemerisFileParser.parse(...) from a ReaderIn 10.x users could pass a Reader to the parse method. This let the user set the correct character encoding. 11.0-SNAP assumes the character encoding is UTF-8 if it is not XML. It is also inefficient if the user already has a stream of c...In 10.x users could pass a Reader to the parse method. This let the user set the correct character encoding. 11.0-SNAP assumes the character encoding is UTF-8 if it is not XML. It is also inefficient if the user already has a stream of characters instead of a stream of bytes.11.0https://gitlab.orekit.org/orekit/orekit/-/issues/802Potential error when converting SpacecraftState to TLE2021-07-21T12:47:17ZPascal ParraudPotential error when converting SpacecraftState to TLEThe static method `stateToTle` from TLE class doesn't convert the orbit from the input SpacecraftState to the TEME frame required for TLEs. If the input frame is not TEME, that is most of the time, the converted TLE is not correct.
Tests...The static method `stateToTle` from TLE class doesn't convert the orbit from the input SpacecraftState to the TEME frame required for TLEs. If the input frame is not TEME, that is most of the time, the converted TLE is not correct.
Tests miss the case because they only handle TLEs to build states and thus TEME is the only considered frame.11.0https://gitlab.orekit.org/orekit/orekit/-/issues/745Add Sequential-Batch Least Squares2021-07-19T13:13:18ZBryan CazabonneAdd Sequential-Batch Least SquaresBatch Least Squares main problem can be describe as follow:
"_Suppose we have 1000 observations and we perform an iterative loop to find the best answer to the state space of the system. But just as we finish converging on the answer, w...Batch Least Squares main problem can be describe as follow:
"_Suppose we have 1000 observations and we perform an iterative loop to find the best answer to the state space of the system. But just as we finish converging on the answer, we receive 30 new observations. We could redo the process, using 1030 observations, but that is a waste of time because we've already extracted the information from the first 1000._"
Sequential-Batch Least Squares allows using the statistical information from the least squares processing of the first 1000 observations, and combine it with the new information.
More details are given in: Vallado D., Fundamentals of astrodynamics, Chapter 10.5.11.0https://gitlab.orekit.org/orekit/orekit/-/issues/814ephemeris created from analytical propagators loose additional states2021-07-16T08:54:56ZLuc Maisonobeephemeris created from analytical propagators loose additional statesWhen an analytical propagator starts from an initial state that contains
additional states, the propagator itself preserves these additional states
but the generated ephemeris looses them.
See this [discussion](https://forum.orekit.org/...When an analytical propagator starts from an initial state that contains
additional states, the propagator itself preserves these additional states
but the generated ephemeris looses them.
See this [discussion](https://forum.orekit.org/t/bug-with-boundedpropagatorview-and-additional-states/1291) in the forum.11.0Luc MaisonobeLuc Maisonobehttps://gitlab.orekit.org/orekit/orekit/-/issues/809Drop the concept of propagation modes2021-07-15T20:05:31ZLuc MaisonobeDrop the concept of propagation modesAll current propagation modes (master, slave, ephemeris generation) should be removed and replaced
with rich step handling mechanisms.
See the [discussion](https://forum.orekit.org/t/proposal-for-step-handling-overhaul/1272) on the forum.All current propagation modes (master, slave, ephemeris generation) should be removed and replaced
with rich step handling mechanisms.
See the [discussion](https://forum.orekit.org/t/proposal-for-step-handling-overhaul/1272) on the forum.11.0Luc MaisonobeLuc Maisonobehttps://gitlab.orekit.org/orekit/orekit/-/issues/813Wrong derivatives in turnaround modifiers2021-07-15T20:04:40ZLuc MaisonobeWrong derivatives in turnaround modifiersIn both `TurnAroundRangeIonosphericDelayModifier` and `TurnAroundRangeTroposphericDelayModifier`,
the derivatives with respect to the secondary station are in fact computed using the data from
the primary station.In both `TurnAroundRangeIonosphericDelayModifier` and `TurnAroundRangeTroposphericDelayModifier`,
the derivatives with respect to the secondary station are in fact computed using the data from
the primary station.11.0Luc MaisonobeLuc Maisonobe