Orekit issueshttps://gitlab.orekit.org/groups/orekit/-/issues2021-08-18T14:41:43Zhttps://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/816DSST Short Period Motion Fourier Coefficient Time Derivatives2021-07-27T08:41:09ZPaul CefolaDSST Short Period Motion Fourier Coefficient Time DerivativesThe efficient computation of the DSST short period motion Fourier coefficients is important for Orekit DSST orbit determination applications, especially high accuracy applications where many of these coefficients are required. Currently...The efficient computation of the DSST short period motion Fourier coefficients is important for Orekit DSST orbit determination applications, especially high accuracy applications where many of these coefficients are required. Currently these coefficients are computed with Lagrange interpolators because the time derivatives of the coefficients are not available. If both the coefficients and their time derivatives were available, we could employ Hermite interpolators. Such Hermite interpolators have proved advantageous for the DSST mean element equations of motion. But Orekit has implemented an automatic differentiation scheme for derivatives of complex software-defined functions. This issue requests implementation of the capability to compute the time derivatives of the DSST short period motion Fourier coefficients via automatic differentiation.https://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/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/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 Maisonobehttps://gitlab.orekit.org/orekit/orekit/-/issues/812change turnaround terminology to primary/secondary stations2021-07-15T20:04:19ZLuc Maisonobechange turnaround terminology to primary/secondary stationsThe terminology for the two ground stations should be primary/secondary.
This is related to [this](https://forum.orekit.org/t/proposal-for-step-handling-overhaul/) forum discussion.The terminology for the two ground stations should be primary/secondary.
This is related to [this](https://forum.orekit.org/t/proposal-for-step-handling-overhaul/) forum discussion.11.0Luc MaisonobeLuc Maisonobehttps://gitlab.orekit.org/orekit/orekit/-/issues/811multiplexer for step handlers should manage on the fly add/remove/clean2021-07-13T10:45:07ZLuc Maisonobemultiplexer for step handlers should manage on the fly add/remove/cleanStep handlers should be allowed to be added, removed or cleaned during propagation.Step handlers should be allowed to be added, removed or cleaned during propagation.11.0Luc MaisonobeLuc Maisonobehttps://gitlab.orekit.org/orekit/orekit/-/issues/810merge multiplexers for fixed steps and variable steps2021-07-12T16:01:08ZLuc Maisonobemerge multiplexers for fixed steps and variable stepsThere are two different multiplexers for step handlers, one dedicated to variable steps, and one dedicated to fixed steps. The later also can only manage handlers that use the same size.
Everything should be merged into a more feature-ri...There are two different multiplexers for step handlers, one dedicated to variable steps, and one dedicated to fixed steps. The later also can only manage handlers that use the same size.
Everything should be merged into a more feature-rich multiplexer, allowing fixed and variable size steps,
several sizes for variable sizes, and also removal of handler.
This is would also be used internally for implementing issue #80911.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/808move isLast argument in step handler handleStep method to a separate method2021-07-09T21:41:02ZLuc Maisonobemove isLast argument in step handler handleStep method to a separate methodThis is the Orekit counterpart of Hipparchus [issue 146](https://github.com/Hipparchus-Math/hipparchus/issues/146).
This has been [discussed](https://forum.orekit.org/t/proposal-for-step-handling-overhaul/) on the forum.This is the Orekit counterpart of Hipparchus [issue 146](https://github.com/Hipparchus-Math/hipparchus/issues/146).
This has been [discussed](https://forum.orekit.org/t/proposal-for-step-handling-overhaul/) on the forum.11.0Luc MaisonobeLuc Maisonobehttps://gitlab.orekit.org/orekit/orekit/-/issues/807scheduling between calls to step handlers and events handlers in propagators ...2021-07-09T21:41:19ZLuc Maisonobescheduling between calls to step handlers and events handlers in propagators is wrongThis is the Orekit counterpart of Hipparchus [issue 145](https://github.com/Hipparchus-Math/hipparchus/issues/145).
This has been [discussed](https://forum.orekit.org/t/proposal-for-step-handling-overhaul/) on the forum.This is the Orekit counterpart of Hipparchus [issue 145](https://github.com/Hipparchus-Math/hipparchus/issues/145).
This has been [discussed](https://forum.orekit.org/t/proposal-for-step-handling-overhaul/) on the forum.11.0Luc MaisonobeLuc Maisonobehttps://gitlab.orekit.org/orekit/orekit/-/issues/806FieldOrekitStepInterpolator has no restrictStep method2021-07-09T21:41:36ZLuc MaisonobeFieldOrekitStepInterpolator has no restrictStep methodThe field version of step interpolation is not equivalent to the primitive
double version. It lacks a restrictStep method.The field version of step interpolation is not equivalent to the primitive
double version. It lacks a restrictStep method.11.0Luc MaisonobeLuc Maisonobehttps://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/804Provide Earth Orientation Parameters from SINEX files2022-06-20T06:50:17ZBryan CazabonneProvide Earth Orientation Parameters from SINEX filesUsually, when performing precise orbit determination (i.e. GNSS and laser ranging based) analysis center provide the estimated Earth Orientation Parameters inside the SINEX file used for station positions. It can be a good improvement if...Usually, when performing precise orbit determination (i.e. GNSS and laser ranging based) analysis center provide the estimated Earth Orientation Parameters inside the SINEX file used for station positions. It can be a good improvement if the `SinexLoader` of Orekit can also implements the `EOPHistoryLoader` interface to provide EOP.11.2https://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/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/801Add getter for meteorological data used in CRD data block2021-06-30T12:25:34ZBryan CazabonneAdd getter for meteorological data used in CRD data blockWith the current implementation, only a `Meteo` object is accessible to the user. It could be useful to add a getter to access the list of `MeteorologicalMeasurement` used to build this object.With the current implementation, only a `Meteo` object is accessible to the user. It could be useful to add a getter to access the list of `MeteorologicalMeasurement` used to build this object.11.0Bryan CazabonneBryan Cazabonnehttps://gitlab.orekit.org/orekit/orekit/-/issues/800Revert the design choice for the existing FootprintOverlapDetector2021-06-29T11:57:04Zjeje22Revert the design choice for the existing FootprintOverlapDetectorThis issue is related to the following discussion https://forum.orekit.org/t/created-sphericalpolygonset-gives-nullpointerexception-with-footprintoverlapdetectorh/1251/8This issue is related to the following discussion https://forum.orekit.org/t/created-sphericalpolygonset-gives-nullpointerexception-with-footprintoverlapdetectorh/1251/8https://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/798DSST Osculating Backward Propagation fails with event detectors2021-09-03T08:36:31ZEvan WardDSST Osculating Backward Propagation fails with event detectorsSee the attached test case. It seems that when DSST is propagating backwards it throws an exception about not having enough samples. Seems to be a problem with initializaiton. This only occurs if a force model has been added. See attache...See the attached test case. It seems that when DSST is propagating backwards it throws an exception about not having enough samples. Seems to be a problem with initializaiton. This only occurs if a force model has been added. See attached test case. Might be the same issue as #717.
[CloseEventsDsstOsculatingTest.java](/uploads/55d81303f2157d8203af0724232e1909/CloseEventsDsstOsculatingTest.java)
Sample exception:
```
org.orekit.errors.OrekitException: sample for interpolation is empty
at org.orekit.errors.OrekitException.unwrap(OrekitException.java:154)
at org.orekit.propagation.integration.AbstractIntegratedPropagator.propagate(AbstractIntegratedPropagator.java:495)
at org.orekit.propagation.integration.AbstractIntegratedPropagator.propagate(AbstractIntegratedPropagator.java:414)
at org.orekit.propagation.integration.AbstractIntegratedPropagator.propagate(AbstractIntegratedPropagator.java:397)
at org.orekit.propagation.events.CloseEventsAbstractTest.testEventCausedByStateResetReverse(CloseEventsAbstractTest.java:1628)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59)
at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56)
at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
at org.junit.runners.BlockJUnit4ClassRunner$1.evaluate(BlockJUnit4ClassRunner.java:100)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:366)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:103)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:63)
at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329)
at org.junit.runners.ParentRunner.access$100(ParentRunner.java:66)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293)
at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
at org.junit.runners.ParentRunner.run(ParentRunner.java:413)
at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
at com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:69)
at com.intellij.rt.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:33)
at com.intellij.rt.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:220)
at com.intellij.rt.junit.JUnitStarter.main(JUnitStarter.java:53)
Caused by: org.hipparchus.exception.MathIllegalArgumentException: sample for interpolation is empty
at org.hipparchus.analysis.interpolation.HermiteInterpolator.checkInterpolation(HermiteInterpolator.java:269)
at org.hipparchus.analysis.interpolation.HermiteInterpolator.value(HermiteInterpolator.java:177)
at org.orekit.propagation.semianalytical.dsst.utilities.ShortPeriodicsInterpolatedCoefficient.value(ShortPeriodicsInterpolatedCoefficient.java:76)
at org.orekit.propagation.semianalytical.dsst.forces.DSSTThirdBody$ThirdBodyShortPeriodicCoefficients.value(DSSTThirdBody.java:3109)
at org.orekit.propagation.semianalytical.dsst.DSSTPropagator$MeanPlusShortPeriodicMapper.mapArrayToState(DSSTPropagator.java:845)
at org.orekit.propagation.integration.StateMapper.mapArrayToState(StateMapper.java:167)
at org.orekit.propagation.integration.AbstractIntegratedPropagator.getCompleteState(AbstractIntegratedPropagator.java:596)
at org.orekit.propagation.integration.AbstractIntegratedPropagator.access$600(AbstractIntegratedPropagator.java:63)
at org.orekit.propagation.integration.AbstractIntegratedPropagator$AdaptedEventDetector.g(AbstractIntegratedPropagator.java:785)
at org.hipparchus.ode.events.EventState.evaluateStep(EventState.java:237)
at org.hipparchus.ode.AbstractIntegrator.acceptStep(AbstractIntegrator.java:315)
at org.hipparchus.ode.nonstiff.EmbeddedRungeKuttaIntegrator.integrate(EmbeddedRungeKuttaIntegrator.java:285)
at org.orekit.propagation.integration.AbstractIntegratedPropagator.propagate(AbstractIntegratedPropagator.java:469)
... 29 more
```11.0