Orekit issueshttps://gitlab.orekit.org/groups/orekit/-/issues2024-03-16T14:20:08Zhttps://gitlab.orekit.org/orekit/orekit/-/issues/1309Incorrect transmitter location in BistaticRange measurement2024-03-16T14:20:08ZMark RuttenIncorrect transmitter location in BistaticRange measurementThe transmit date is incorrectly calculated by shifting the receive date in the wrong direction. For example
```java
final FieldAbsoluteDate<Gradient> transmitDateDS = downlinkDateDS.shiftedBy(tauTotal);
```
should be
```java
final Fiel...The transmit date is incorrectly calculated by shifting the receive date in the wrong direction. For example
```java
final FieldAbsoluteDate<Gradient> transmitDateDS = downlinkDateDS.shiftedBy(tauTotal);
```
should be
```java
final FieldAbsoluteDate<Gradient> transmitDateDS = downlinkDateDS.shiftedBy(tauTotal.negate());
```
This doesn't affect the calculation of the theoretical measurement but does affect the list of participants in the estimated measurement.12.0.2Mark RuttenMark Ruttenhttps://gitlab.orekit.org/orekit/orekit/-/issues/1296org.orekit.time.LazyLoadedTimeScales#getUTC is not thread safe2024-03-16T14:20:08ZChristopher Schankorg.orekit.time.LazyLoadedTimeScales#getUTC is not thread safeorg.orekit.time.LazyLoadedTimeScales#getUTC is not thread safe. When the UTCScale is not loaded yet, two threads can enter the lazy loading, and cause a ConcurrentModificationException when looping over the loaders
Patch to fix it:
```...org.orekit.time.LazyLoadedTimeScales#getUTC is not thread safe. When the UTCScale is not loaded yet, two threads can enter the lazy loading, and cause a ConcurrentModificationException when looping over the loaders
Patch to fix it:
```
Subject: [PATCH] fix_issue-1296
---
Index: src/main/java/org/orekit/time/LazyLoadedTimeScales.java
IDEA additional info:
Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP
<+>UTF-8
===================================================================
diff --git a/src/main/java/org/orekit/time/LazyLoadedTimeScales.java b/src/main/java/org/orekit/time/LazyLoadedTimeScales.java
--- a/src/main/java/org/orekit/time/LazyLoadedTimeScales.java (revision 4314309b071f9ab340b7740b1a7da4e46e003aa2)
+++ b/src/main/java/org/orekit/time/LazyLoadedTimeScales.java (date 1704290488132)
@@ -177,23 +177,28 @@
UTCScale refUtc = utc.get();
if (refUtc == null) {
- List<OffsetModel> entries = Collections.emptyList();
- if (loaders.isEmpty()) {
- addDefaultUTCTAIOffsetsLoaders();
- }
- for (UTCTAIOffsetsLoader loader : loaders) {
- entries = loader.loadOffsets();
- if (!entries.isEmpty()) {
- break;
- }
- }
- if (entries.isEmpty()) {
- throw new OrekitException(OrekitMessages.NO_IERS_UTC_TAI_HISTORY_DATA_LOADED);
- }
- utc.compareAndSet(null, new UTCScale(getTAI(), entries));
- refUtc = utc.get();
- }
+ synchronized (this) {
+ if (utc.get() == null) { // Check if utc was not loaded in the meantime
+ List<OffsetModel> entries = Collections.emptyList();
+ if (loaders.isEmpty()) {
+ addDefaultUTCTAIOffsetsLoaders();
+ }
+ for (UTCTAIOffsetsLoader loader : loaders) {
+ entries = loader.loadOffsets();
+ if (!entries.isEmpty()) {
+ break;
+ }
+ }
+ if (entries.isEmpty()) {
+ throw new OrekitException(OrekitMessages.NO_IERS_UTC_TAI_HISTORY_DATA_LOADED);
+ }
+ utc.compareAndSet(null, new UTCScale(getTAI(), entries));
+ }
+ refUtc = utc.get();
+ }
+ }
+
return refUtc;
}
```12.0.2Christopher SchankChristopher Schankhttps://gitlab.orekit.org/orekit/orekit/-/issues/986DSST orbit estimation cannot estimate propagation and/or measurement parameters2024-03-15T17:18:59ZBryan CazabonneDSST orbit estimation cannot estimate propagation and/or measurement parametersSince the addition of the Extended Semi-analytical Kalman Filter, the DSST OD cannot estimate propagation and measurement parameters. Before this addition, the estimation was possible.Since the addition of the Extended Semi-analytical Kalman Filter, the DSST OD cannot estimate propagation and measurement parameters. Before this addition, the estimation was possible.12.0.2Evan WardEvan Wardhttps://gitlab.orekit.org/orekit/orekit/-/issues/1314Wrong parsing of GAL timesystem in SP3 files2024-03-15T13:26:43ZLuc MaisonobeWrong parsing of GAL timesystem in SP3 filesSP3 files can use GAL as the time system. This however does not work because we use `TimeSystem.valueOf` instead of `TimeSystem.parseTimeSystem`.
So it works only for the time systems enumerates that have 3 letters (GPS, UTC, and probabl...SP3 files can use GAL as the time system. This however does not work because we use `TimeSystem.valueOf` instead of `TimeSystem.parseTimeSystem`.
So it works only for the time systems enumerates that have 3 letters (GPS, UTC, and probably TAI), but not for GALILEO, GLONASS and the likes.12.0.2Luc MaisonobeLuc Maisonobehttps://gitlab.orekit.org/orekit/orekit/-/issues/1321Wrong parsing of Beidou time system in SP3 file2024-03-15T13:26:43ZLuc MaisonobeWrong parsing of Beidou time system in SP3 fileThe Beidou system time should be written BDT and not BDS.The Beidou system time should be written BDT and not BDS.12.0.2Luc MaisonobeLuc Maisonobehttps://gitlab.orekit.org/orekit/orekit/-/issues/1322Wrong writing of SBAS time system in SP3 files2024-03-15T13:26:43ZLuc MaisonobeWrong writing of SBAS time system in SP3 filesThe SBAS time system is not allowed in SP3 files, it should be changed to UTC.The SBAS time system is not allowed in SP3 files, it should be changed to UTC.12.0.2Luc MaisonobeLuc Maisonobehttps://gitlab.orekit.org/orekit/orekit/-/issues/1327SP3Writer generates blank lines2024-03-15T13:26:43ZMark RuttenSP3Writer generates blank linesI found a problem with a multiple of 17 satellites (i.e. a complete row), where the SP3Writer incorrectly generates two blank lines in the header, one just after the satellite names and one just after the accuracies.I found a problem with a multiple of 17 satellites (i.e. a complete row), where the SP3Writer incorrectly generates two blank lines in the header, one just after the satellite names and one just after the accuracies.12.0.2Mark RuttenMark Ruttenhttps://gitlab.orekit.org/orekit/orekit/-/issues/1346Rinex observation V4 can miss ANTENNA: DELTA H/E/N header line for receivers ...2024-03-15T13:26:43ZLuc MaisonobeRinex observation V4 can miss ANTENNA: DELTA H/E/N header line for receivers in vehiclesThis header line is replaced by ANTENNA: DELTA X/Y/Z for moving receivers.
However, when the END header marker is found, there are checks that ANTENNA: DELTA H/E/N has been parsed, so correct files are rejected.This header line is replaced by ANTENNA: DELTA X/Y/Z for moving receivers.
However, when the END header marker is found, there are checks that ANTENNA: DELTA H/E/N has been parsed, so correct files are rejected.12.0.2Luc MaisonobeLuc Maisonobehttps://gitlab.orekit.org/orekit/orekit/-/issues/1347No public constructor in Inertia and InertiaAxis classes2024-03-15T13:26:43ZMiyuNo public constructor in Inertia and InertiaAxis classesThere is no public constructor in Inertia and InertiaAxis classes, so it is not possible to create those objects.
(Posted this [here](https://forum.orekit.org/t/how-to-use-torquefree-attitude-provider/3369))There is no public constructor in Inertia and InertiaAxis classes, so it is not possible to create those objects.
(Posted this [here](https://forum.orekit.org/t/how-to-use-torquefree-attitude-provider/3369))12.0.2https://gitlab.orekit.org/orekit/orekit/-/issues/1300Regression: Ephemeris with interpolationPoints=12024-03-15T13:26:43ZEvan WardRegression: Ephemeris with interpolationPoints=1As a user I would like to use an `Ephemeris` with interpolationOrder=1, i.e. step-wise interpolation. This was possible in Orekit 11.x, but no longer possible in Orekit 12.0.
Failing test case (Credit Sander Cochran):
```java
/* Ep...As a user I would like to use an `Ephemeris` with interpolationOrder=1, i.e. step-wise interpolation. This was possible in Orekit 11.x, but no longer possible in Orekit 12.0.
Failing test case (Credit Sander Cochran):
```java
/* Ephemeris propagate fails for interpolation point value of 1 */
@Test
void testMinInterpolationPoints() {
// GIVEN
final AbsoluteDate initialDate = new AbsoluteDate();
final Orbit initialOrbit = TestUtils.getDefaultOrbit(initialDate);
// Setup propagator
final Orbit finalOrbit = initialOrbit.shiftedBy(1);
final List<SpacecraftState> states = new ArrayList<>();
states.add(new SpacecraftState(initialOrbit));
states.add(new SpacecraftState(finalOrbit));
final Ephemeris ephemeris = new Ephemeris(states, 1);
// WHEN & THEN
// Error thrown when there is more than one state in ephemeris and interpolation points is 1
ephemeris.propagate(ephemeris.getMaxDate());
}
```12.0.2Evan WardEvan Wardhttps://gitlab.orekit.org/orekit/orekit/-/issues/1328Potential NullPointerException in Frame2024-03-15T13:26:43ZLuc MaisonobePotential NullPointerException in FrameThe field version of `Frame.getStaticTransformTo` javadoc states that null `date` parameters are allowed (they are allowed in the primitive double version).
However, the first instruction is `date.hasZeroField()`, which will trigger an e...The field version of `Frame.getStaticTransformTo` javadoc states that null `date` parameters are allowed (they are allowed in the primitive double version).
However, the first instruction is `date.hasZeroField()`, which will trigger an exception if null date is passed.
This occured to me because SonarQube identified a bug between lines 530 and 534 of the field version of `GroundStation.getOffsetGeodeticPoint`, as the check for null date is performed *after* `getStaticTransformTo` has been called.12.0.2https://gitlab.orekit.org/orekit/orekit/-/issues/1341{set|get}ClkOffset in RinexObservationHeader is confusing2024-03-14T12:17:18ZLuc Maisonobe{set|get}ClkOffset in RinexObservationHeader is confusingThe name of the methods as well as its javadoc seem to imply the value is an offset (despite it is an integer), but it really is a flag corresponding to entry "RCV CLOCK OFFS APPL" in Rinex header.
So the names should read `{set|get}Cloc...The name of the methods as well as its javadoc seem to imply the value is an offset (despite it is an integer), but it really is a flag corresponding to entry "RCV CLOCK OFFS APPL" in Rinex header.
So the names should read `{set|get}ClockOffsetApplied` and the type should be a boolean.12.1Luc MaisonobeLuc Maisonobehttps://gitlab.orekit.org/orekit/orekit/-/issues/1336Add getBodyName in third bodies2024-03-07T20:10:35ZRomain SerraAdd getBodyName in third bodiesPossibly also factorize things like `dependsOnlyOnPosition` for `ForceModel`Possibly also factorize things like `dependsOnlyOnPosition` for `ForceModel`12.1Romain SerraRomain Serrahttps://gitlab.orekit.org/orekit/orekit/-/issues/1335Allow choice of orbit type in SmallManeuverAnalyticalModel2024-03-07T18:44:01ZMaxime JournotAllow choice of orbit type in SmallManeuverAnalyticalModel[SmallManeuverAnalyticalModel](https://gitlab.orekit.org/orekit/orekit/-/blob/develop/src/main/java/org/orekit/forces/maneuvers/SmallManeuverAnalyticalModel.java?ref_type=heads) imposes an internal `OrbitType` (Keplerian or Equinoctial d...[SmallManeuverAnalyticalModel](https://gitlab.orekit.org/orekit/orekit/-/blob/develop/src/main/java/org/orekit/forces/maneuvers/SmallManeuverAnalyticalModel.java?ref_type=heads) imposes an internal `OrbitType` (Keplerian or Equinoctial depending on eccentricity).
This is nice when a user doesn't know which type of orbit he wants to deal with.
However, when one knows which type to use, it's much faster to use this type than to rely on the many conversions the model as to do to go back and forth between types.
As an example, using Keplerian orbits and enforcing the internal type to Keplerian results in a 77% increase in performance for a LEO → GEO low-thrust transfer of 15 days with about 17000 maneuvers (see this [forum thread](https://forum.orekit.org/t/performance-configure-orbit-type-in-smallmaneuveranalyticalmodel/3324/3)).
So the proposal here is to add constructors to `SmallManeuverAnalyticalModel` that will allow the choice of orbit type to use.12.1Maxime JournotMaxime Journothttps://gitlab.orekit.org/orekit/orekit/-/issues/1258Add getter for C20 in spherical harmonics provider2024-03-06T22:54:47ZRomain SerraAdd getter for C20 in spherical harmonics providerThe new method would be `get{Un}normalizedC20(date)` and would wrap `onDate(original.getDate()).get{Un}normalizedCnm(2,0)`.The new method would be `get{Un}normalizedC20(date)` and would wrap `onDate(original.getDate()).get{Un}normalizedCnm(2,0)`.12.1Romain SerraRomain Serrahttps://gitlab.orekit.org/orekit/orekit/-/issues/1338Add a way to retrieve the effect of an EstimationModifier2024-03-06T22:13:39ZLuc MaisonobeAdd a way to retrieve the effect of an EstimationModifier`EstimationModifier` implementations use `setEstimatedValue` to update the current value.
There is no way to retrieve the original value before any modifications or to get the effect of each modifier independently, only the final updated...`EstimationModifier` implementations use `setEstimatedValue` to update the current value.
There is no way to retrieve the original value before any modifications or to get the effect of each modifier independently, only the final updated value is available.
Accessing these data should be possible.12.1Luc MaisonobeLuc Maisonobehttps://gitlab.orekit.org/orekit/orekit/-/issues/1339CI/CD environment and scripts must be adapted to SonarQube 9.9 LTS2024-03-06T21:21:26ZSébastien Dinotsebastien.dinot@csgroup.euCI/CD environment and scripts must be adapted to SonarQube 9.9 LTSThe current CI/CD pipeline is based on a Docker image that uses a version of Java (8) that is not compatible with the minimum requirements (11) of SonarQube 9.9 LTS. Consequently, the CI/CD pipeline must use a more recent Docker image. I...The current CI/CD pipeline is based on a Docker image that uses a version of Java (8) that is not compatible with the minimum requirements (11) of SonarQube 9.9 LTS. Consequently, the CI/CD pipeline must use a more recent Docker image. I have successfully tried the [maven:3.9.6-eclipse-temurin-11](https://hub.docker.com/_/maven) on my clone.
I will push as soon as possible a MR.https://gitlab.orekit.org/orekit/orekit/-/issues/1198Plug in new FieldOrbit constructor in FieldSpacecraftState from non Field2024-02-26T20:11:05ZRomain SerraPlug in new FieldOrbit constructor in FieldSpacecraftState from non FieldNew constructor from issue #1194 could be plugged in within constructor of `FieldSpacecraftState` from `Field` and `SpacecraftState`.
When I tried in MR!409, it was breaking some tests due to tolerance and didn't have time to investigat...New constructor from issue #1194 could be plugged in within constructor of `FieldSpacecraftState` from `Field` and `SpacecraftState`.
When I tried in MR!409, it was breaking some tests due to tolerance and didn't have time to investigate.
There is also `Fieldifier` that has similar methods that could be updated.12.1Romain SerraRomain Serrahttps://gitlab.orekit.org/orekit/orekit/-/issues/1201Change default angle type in (Field)NumericalPropagator2024-02-25T22:37:28ZRomain SerraChange default angle type in (Field)NumericalPropagatorCurrent default `PositionAngleType` is `TRUE`, which is the slowest, the fastest being `MEAN` as far as derivative evaluation is concerned. `ECCENTRIC` might be a good compromise as it is used for conversion to position vector.Current default `PositionAngleType` is `TRUE`, which is the slowest, the fastest being `MEAN` as far as derivative evaluation is concerned. `ECCENTRIC` might be a good compromise as it is used for conversion to position vector.12.1Romain SerraRomain Serrahttps://gitlab.orekit.org/orekit/orekit/-/issues/1307Unnecessary calls to transformPVCoordinates in (Field)ShortTermEncounter2DDef...2024-02-24T08:39:12ZRomain SerraUnnecessary calls to transformPVCoordinates in (Field)ShortTermEncounter2DDefinitionCan be replaced by `transformPosition` as only `getPosition` is called afterwardsCan be replaced by `transformPosition` as only `getPosition` is called afterwards12.1Romain SerraRomain Serra