Orekit issueshttps://gitlab.orekit.org/groups/orekit/-/issues2022-04-27T09:50:04Zhttps://gitlab.orekit.org/orekit/orekit/-/issues/826Null ephemeris generators while propagating several numerical propagators wit...2022-04-27T09:50:04ZLUGANNull ephemeris generators while propagating several numerical propagators with PropagatorsParallelizerThe problem is that the first generator have ephemeris but the others not.
The test is silly by propagating exactly the samething but in my case I have different spacecraft/propagator and the nulls occur too.
Test unit seggested in [bra...The problem is that the first generator have ephemeris but the others not.
The test is silly by propagating exactly the samething but in my case I have different spacecraft/propagator and the nulls occur too.
Test unit seggested in [branch](https://gitlab.orekit.org/Anne-Laure/orekit/-/tree/feature/parallelizer)
Some discussion started in [forum](https://forum.orekit.org/t/ephemeris-with-propagatorsparallelizer/1321).11.1.2https://gitlab.orekit.org/orekit/orekit/-/issues/825Update AbsoluteDate.toString() for 11.02021-09-02T13:48:34ZEvan WardUpdate AbsoluteDate.toString() for 11.0Discussion on the forum: https://forum.orekit.org/t/update-absolutedate-tostring-for-11-0
### Shortcomings
- As #677 noted it does not return valid ISO 8601 event though it is documented to.
- Limiting to millisecond precision creates...Discussion on the forum: https://forum.orekit.org/t/update-absolutedate-tostring-for-11-0
### Shortcomings
- As #677 noted it does not return valid ISO 8601 event though it is documented to.
- Limiting to millisecond precision creates strange error messages. E.g. "2020-01-01T00:00:00.000 is before 2020-01-01T00:00:00.000" when the two dates differ by less than 1ms.
- In Effective Java Josh Bloch writes that the `toString()` method should be primarily for developers. He recommends making it an unambiguous representation of the object's state. Since Orekit is a library written for other developers and given how `toString()` is used I agree. There are other methods for presenting dates to users.
- It is in UTC which needs leap seconds to be loaded. Instances of `AbsoluteDate` can be created without loading leap seconds, but the `toString()` method doesn't work, creating one of the most common errors in Orekit for new comers and experienced developers alike.
- It uses the default data context. This can produce some strange error messages when an application is using a different data context as the leap second tables may be different. Also, this use of the default data context can only be detected at runtime using an `ExceptionalDataContext`, which is problematic.
### Implementation Options
0. Just keep the current implementation. The shortcomings are minor.
1. Use TAI and extend the precision of the seconds field, and include `"TAI"` to denote the time scale. TAI is the de facto time scale of `AbsoluteDate` so no time scale conversions would need to be done. 16 digits after the decimal place would eliminate most ambiguity issues, but some ambiguity still exists for small values of `AbsoluteDate.offset`. TAI conversion is less complex and buggy than UTC conversion, as seen in the bugs reported concerning time. A reliable `toString()` is helpful for developers, especially in exception messages. The result would be neither ISO 8601 nor RFC 3339 since they require UTC or an integer number of minutes offset thereof. To generate those formats use `toString(TimeScale)` and related methods.
2. Print the `epoch` and `offset` as stored internally in `AbsoluteDate`. Unambiguous but perhaps not that user friendly.
3. Add `epoch` and `offset` using `BigDecimal` or similar class and convert the result to a string. The result would be seconds past the `AbsoluteDate` epoch. Should theoretically be unambiguous because of how those values are set. Needs some more investigation to see if it is possible to have `epoch + offset` sum to the same number but be set to different values. Perhaps this kind of ambiguity is not significant because `equals`, `compareTo`, and `durationFrom` are all computed based on the sum of `epoch + offset`.
4. Combine 3 and 1 so the developer gets a description in calendar format and full precision, unambiguous representation of the `AbsoluteDate`. Something like `"123456.789456123456789 (2020-01-01T00:00:00... TAI)"`.
5. others
Based on the discussion it seemed there was a preference for printing elapsed seconds since an epoch and date-time components in the TAI time scale.11.0Evan WardEvan Wardhttps://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/823Wrong implementation of Kalman estimation using DSST propagator2022-02-14T07:50:08ZBryan CazabonneWrong implementation of Kalman estimation using DSST propagatorCurrent implementation of orbit determination using both DSST propagator and Extended Kalman Filter (EKF) is not correct. Orbit determination based on semi-analytical satellite theory and recursive filter must be done using a specific al...Current implementation of orbit determination using both DSST propagator and Extended Kalman Filter (EKF) is not correct. Orbit determination based on semi-analytical satellite theory and recursive filter must be done using a specific algorithm: the Extended Semi-analytical Kalman Filter (ESKF). The EKF algorithm needs to re-initialize the orbital state at each observation epoch. However, the time difference between two observations is usually much smaller than the DSST step size (e.g., half a day). ESKF reconciles the conflicting goal of both theories.
Current implementation (`DSSTKalmanModel`) must be removed and replace by a new implementation.
For more details about the equations and the theory [1] [2] [3]
[1]: Taylor S. P., Semi-analytical Satellite Theory and Sequential Estimation, Master of Science Thesis, Department of
Mechanical Engineering, MIT, September, 1981
[2]: Wagner E. A., Application of the Extended Semianalytical Kalman Filter to Synchronous Orbits, Master of Science
Thesis, Department of Aeronautics and Astronautics, MIT, June, 1983
[3]: Folcik Z., Orbit Determination Using Modern Filters/Smoothers and Continuous Thrust Modeling, Master of Sci-
ence Thesis, Department of Aeronautics and Astronautics, MIT, June, 200811.1Bryan CazabonneBryan Cazabonnehttps://gitlab.orekit.org/orekit/orekit/-/issues/822Add support for CCSDS TDM version 2.02022-01-14T17:22:56ZDavid GondelachAdd support for CCSDS TDM version 2.0The current TDM parser and writer do not yet support Tracking Data Message version 2.0, see https://public.ccsds.org/Pubs/503x0b2.pdf
The following keywords need to be added to support TDM v2.0:
MetaData section:
- DATA_TYPES
- EPHEMER...The current TDM parser and writer do not yet support Tracking Data Message version 2.0, see https://public.ccsds.org/Pubs/503x0b2.pdf
The following keywords need to be added to support TDM v2.0:
MetaData section:
- DATA_TYPES
- EPHEMERIS_NAME_n
- INTERPOLATION
- INTERPOLATION_DEGREE
- DOPPLER_COUNT_BIAS
- DOPPLER_COUNT_SCALE
- DOPPLER_COUNT_ROLLOVER
- CORRECTION_MAG
- CORRECTION_RCS
Data section:
- DOPPLER_COUNT
- MAG
- RCS
- RECEIVE_PHASE_CT_n
- TRANSMIT_PHASE_CT_nhttps://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/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/819data filtering stack should be available for explicit loading2022-01-14T17:23:38ZLuc Maisonobedata filtering stack should be available for explicit loadingOrekit provides `DataFilter` that are automatically activated in an
appropriate stack when loading data using a `DataProvidersManager`.
As some file formats like CCSDS, ILRS or SP3 are loaded explicitly by
applications without using a `...Orekit provides `DataFilter` that are automatically activated in an
appropriate stack when loading data using a `DataProvidersManager`.
As some file formats like CCSDS, ILRS or SP3 are loaded explicitly by
applications without using a `DataProvidersManager`, applying filters
upon data loading is cumbersome.
The filtering stack feature should be extracted from `DataProvidersManager`
and be available to applications.11.0Luc MaisonobeLuc Maisonobehttps://gitlab.orekit.org/orekit/orekit/-/issues/818Verify if DTM2000 density model expects adjusted or observed solar flux2021-09-03T09:31:46ZClément JonglezVerify if DTM2000 density model expects adjusted or observed solar fluxAs of now, the `CssiSpaceWeatherData` loader provides adjusted fluxes to the `DTM2000` model:
* `getInstantFlux` method (`CssiSpaceWeatherData.java:194): F10.7Adj
* `getMeanFlux` method (`CssiSpaceWeatherData.java:204): ctr81Adj
We sho...As of now, the `CssiSpaceWeatherData` loader provides adjusted fluxes to the `DTM2000` model:
* `getInstantFlux` method (`CssiSpaceWeatherData.java:194): F10.7Adj
* `getMeanFlux` method (`CssiSpaceWeatherData.java:204): ctr81Adj
We should make sure whether the `DTM2000` model expects adjusted or observed solar flux.
Context from issue #817: `NRLMSISE00` is expecting observed solar flux, while previously the `CssiSpaceWeatherData` loader was providing adjusted solar flux.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/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 Maisonobe