Orekit issueshttps://gitlab.orekit.org/orekit/orekit/-/issues2021-09-14T07:59:21Zhttps://gitlab.orekit.org/orekit/orekit/-/issues/835Format symbols for year, month, day in DateComponents#toString()2021-09-14T07:59:21ZBryan CazabonneFormat symbols for year, month, day in DateComponents#toString()Issue related to the following post: https://forum.orekit.org/t/vote-releasing-orekit-11-0-from-release-candidate-2/1356/10?u=bcazabonneIssue related to the following post: https://forum.orekit.org/t/vote-releasing-orekit-11-0-from-release-candidate-2/1356/10?u=bcazabonne11.0https://gitlab.orekit.org/orekit/orekit/-/issues/831FieldOfViewDetector documentation - noting the lack of body awareness2021-09-03T12:39:46ZItalianmooseFieldOfViewDetector documentation - noting the lack of body awarenessc.f. https://forum.orekit.org/t/field-of-view-sat-event-detector-example/1347/6
Could the fact that a FieldOfViewDetector is unaware of a body blocking the field of view be added to the documentation page? (https://www.orekit.org/site-o...c.f. https://forum.orekit.org/t/field-of-view-sat-event-detector-example/1347/6
Could the fact that a FieldOfViewDetector is unaware of a body blocking the field of view be added to the documentation page? (https://www.orekit.org/site-orekit-10.3/apidocs/org/orekit/propagation/events/FieldOfViewDetector.html)
It would avoid confusion.
The further addition of the example code from https://forum.orekit.org/t/fov-fov-detector-usage-problems/249/8 would be grand too.
The note could read something like:
A FieldOfViewDetector is unaware of any bodies occluding line-of-sight to the target. To include the central body blocking the field of view a BooleanDetector can be combine the FieldOfViewDetector with an ElevationDetector:
final FieldOfViewDetector fd = new FieldOfViewDetector(topocentric_point, field_of_view);
final ElevationDetector ed = new ElevationDetector(topocentric_frame).withConstantElevation(0.);
final BooleanDetector detector = BooleanDetector.andCombine(ed, BooleanDetector.notCombine(fd)).withMaxCheck(maxCheckingInterval);11.0Bryan CazabonneBryan Cazabonnehttps://gitlab.orekit.org/orekit/orekit/-/issues/830Remove step size limitations in analytic propagators2021-09-02T13:08:16ZEvan WardRemove step size limitations in analytic propagatorsSee discussion at https://forum.orekit.org/t/stepsize-hardcoded-for-master-mode-in-analyticalpropagator-change/1243
The offending code is:
```java
// evaluate step size
final double stepSize;
if (get...See discussion at https://forum.orekit.org/t/stepsize-hardcoded-for-master-mode-in-analyticalpropagator-change/1243
The offending code is:
```java
// evaluate step size
final double stepSize;
if (getMultiplexer().getHandlers().isEmpty()) {
stepSize = dt;
} else {
// we look only at the first handler
final OrekitStepHandler handler = getMultiplexer().getHandlers().get(0);
if (handler instanceof OrekitStepNormalizer) {
stepSize = FastMath.copySign(((OrekitStepNormalizer) handler).getFixedTimeStep(), dt);
} else {
stepSize = FastMath.copySign(state.getKeplerianPeriod() / 100, dt);
}
}
```
which is then used to make analytic propagation slower by limiting it to stepping 1/100th of a rev with a `OrekitStepHandler`. Analytic propagation should be able to propagate in one step. The `StepInterpolator` calls `basicPropagate()` so there is actually no interpolation and hence no need for closely spaced points. This is likely heritage from when `shiftedBy()` or actual interpolation was used in the `StepInterpolator`.11.0Evan WardEvan Wardhttps://gitlab.orekit.org/orekit/orekit/-/issues/829Failing test case DataSourceTest#testFileName (Windows OS)2021-09-03T12:39:46ZMaxime JournotFailing test case DataSourceTest#testFileName (Windows OS)Test DataSourceTest#testFileName fails on a Windows OS with following error:
```
java.nio.file.InvalidPathException: Illegal char <:> at index 2: /C:/[..]
```
On line:
```
try (InputStream is = ds.getOpener().openStreamOnce();
```...Test DataSourceTest#testFileName fails on a Windows OS with following error:
```
java.nio.file.InvalidPathException: Illegal char <:> at index 2: /C:/[..]
```
On line:
```
try (InputStream is = ds.getOpener().openStreamOnce();
```
The problem is that the name given as input file name in `DataSource ds = new DataSource(url.toURI().getPath());` starts with a "/".
It seems to be a classical problem with Windows-formed path String when calling ``URI.getPath()`` (see https://stackoverflow.com/questions/9834776/java-nio-file-path-issue).
For example, trying the following will fail on Windows with the same exception: `Paths.get(url.toURI().getPath());`
While `Paths.get(url.toURI())` will work and return a properly-formed path (i.e. without the leading "/" character).
Problem is easily solved by replacing the DataSource filename from:
```
DataSource ds = new DataSource(url.toURI().getPath());
```
to
```
DataSource ds = new DataSource(Paths.get(url.toURI()).toString());
```
I don't think it's an Orekit issue, in my opinion Windows developers should make sure the filename given in input is properly formed.
It's not Orekit's job to check that. Furthermore, the exception is sufficiently detailed for a developer to point out where the problem comes from.
Note that we could also provide a DataSource constructor based on a URI object:
```
public DataSource(final URI uri) {
this(Paths.get(uri).toString(), () -> Files.newInputStream(Paths.get(uri)));
}
```
That would prevent developers from falling into this apparently classical trap.11.0https://gitlab.orekit.org/orekit/orekit/-/issues/828SP3Parser ignores new SP3-d File types2021-08-19T09:37:24ZBryan CazabonneSP3Parser ignores new SP3-d File typesIRNSS and SBAS file types were introduced in SP3-d format. There are ignored by the `SP3Parser` according to the current implementation of the `getFileType()` method. However, JavaDoc specifies that SP3-d format is supported. As a result...IRNSS and SBAS file types were introduced in SP3-d format. There are ignored by the `SP3Parser` according to the current implementation of the `getFileType()` method. However, JavaDoc specifies that SP3-d format is supported. As a results, the new file types must be considered.11.0Bryan CazabonneBryan Cazabonnehttps://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/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/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/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 Maisonobe