Orekit issues
https://gitlab.orekit.org/groups/orekit/-/issues
2020-09-22T15:21:45Z
https://gitlab.orekit.org/orekit/orekit/-/issues/717
DSST orbit determination does not work in backward propagation mode
2020-09-22T15:21:45Z
Bryan Cazabonne
DSST orbit determination does not work in backward propagation mode
In backward propagation mode the DSST orbit determination mode does not work. An exception is thrown. It points an empty interpolation sample in DSST short periodic terms. This problems occurs only if short periodic terms must be computed.
To reproduce the bug, one can add BADG station measurements in the DSST orbit determination process/
In backward propagation mode the DSST orbit determination mode does not work. An exception is thrown. It points an empty interpolation sample in DSST short periodic terms. This problems occurs only if short periodic terms must be computed.
To reproduce the bug, one can add BADG station measurements in the DSST orbit determination process/
https://gitlab.orekit.org/orekit/orekit/-/issues/716
Add piecewise empirical force models
2020-10-23T14:59:44Z
Bryan Cazabonne
Add piecewise empirical force models
For precise orbit determination applications it could be useful to have an implementation of [PolynomialParametricAcceleration](https://gitlab.orekit.org/orekit/orekit/-/blob/master/src/main/java/org/orekit/forces/PolynomialParametricAcceleration.java) and [HarmonicParametricAcceleration](https://gitlab.orekit.org/orekit/orekit/-/blob/master/src/main/java/org/orekit/forces/HarmonicParametricAcceleration.java) that would allow for piecewise definition of the empirical coefficients.
Each coefficient would be defined with a timespan validity and the orbit determination would be able to estimate each one of them separately.
For precise orbit determination applications it could be useful to have an implementation of [PolynomialParametricAcceleration](https://gitlab.orekit.org/orekit/orekit/-/blob/master/src/main/java/org/orekit/forces/PolynomialParametricAcceleration.java) and [HarmonicParametricAcceleration](https://gitlab.orekit.org/orekit/orekit/-/blob/master/src/main/java/org/orekit/forces/HarmonicParametricAcceleration.java) that would allow for piecewise definition of the empirical coefficients.
Each coefficient would be defined with a timespan validity and the orbit determination would be able to estimate each one of them separately.
10.3
Bryan Cazabonne
Bryan Cazabonne
https://gitlab.orekit.org/orekit/orekit/-/issues/715
Relativistic clock correction term cannot be used for orbit determination
2020-10-23T14:59:45Z
Bryan Cazabonne
Relativistic clock correction term cannot be used for orbit determination
Currently, the relativistic clock correction term is computed inside an `AdditionalStateProvider`. This implementation prevents the use of this correction in orbit determination applications. A better implementation is:
1. Implement the relativistic clock correction term in a dedicated `EstimationModifier`.
2. Update the `ClockCorrectionProvider` documentation to point the new `EstimationModifier`.
This implementation is compatible for a minor release of Orekit.
Currently, the relativistic clock correction term is computed inside an `AdditionalStateProvider`. This implementation prevents the use of this correction in orbit determination applications. A better implementation is:
1. Implement the relativistic clock correction term in a dedicated `EstimationModifier`.
2. Update the `ClockCorrectionProvider` documentation to point the new `EstimationModifier`.
This implementation is compatible for a minor release of Orekit.
10.3
Bryan Cazabonne
Bryan Cazabonne
https://gitlab.orekit.org/orekit/orekit/-/issues/714
Add relativistic frequency deviation for RangeRate measurements
2020-10-23T14:59:44Z
Bryan Cazabonne
Add relativistic frequency deviation for RangeRate measurements
Currently, clock relativistic correction is not used in `RangeRate` measurements. Adding it can improve the modelling of the range-rate measurement. The implementation of that offset is given in [1].
It can be implemented as a new `EstimationModifier`.
[1] Teunissen, P., & Montenbruck, O. (Eds.). (2017). Springer handbook of global navigation satellite systems, Eq. (19.13) - (19.15) and (19.17). Springer.
Currently, clock relativistic correction is not used in `RangeRate` measurements. Adding it can improve the modelling of the range-rate measurement. The implementation of that offset is given in [1].
It can be implemented as a new `EstimationModifier`.
[1] Teunissen, P., & Montenbruck, O. (Eds.). (2017). Springer handbook of global navigation satellite systems, Eq. (19.13) - (19.15) and (19.17). Springer.
10.3
Bryan Cazabonne
Bryan Cazabonne
https://gitlab.orekit.org/orekit/orekit/-/issues/713
Wrong computation of DSST short period Jacobian
2020-10-23T14:59:44Z
Thomas Paulet
Wrong computation of DSST short period Jacobian
After discussion with @bryan, it was figured out that DSST short period derivative computation is wrong. Indeed, the setShortPeriodJacobians method in DSSTJacobianMapper.java is building a variational equation to complete an analytical calculation. The short period Jacobian should be directly computed using values from the orbital element Gradients.
After discussion with @bryan, it was figured out that DSST short period derivative computation is wrong. Indeed, the setShortPeriodJacobians method in DSSTJacobianMapper.java is building a variational equation to complete an analytical calculation. The short period Jacobian should be directly computed using values from the orbital element Gradients.
10.3
https://gitlab.orekit.org/orekit/orekit/-/issues/712
Add support for IGS clock products
2021-02-26T15:42:29Z
Bryan Cazabonne
Add support for IGS clock products
It could be an interesting feature to add support for IGS clock products. These files contain clock offsets (optionally clock rate) of GNSS satellites and IGS stations.
Format is described here: ftp://igs.org/pub/data/format/rinex_clock304.txt
It could be an interesting feature to add support for IGS clock products. These files contain clock offsets (optionally clock rate) of GNSS satellites and IGS stations.
Format is described here: ftp://igs.org/pub/data/format/rinex_clock304.txt
11.0
https://gitlab.orekit.org/orekit/orekit/-/issues/711
Allow setting default value for OEM interpolation samples
2020-11-10T14:48:50Z
Evan Ward
Allow setting default value for OEM interpolation samples
In an OEM `INTERPOLATION_DEGREE` is optional. In Orekit's implementation if it is not provided then it is assumed to be zero. In Orekit's implementation the number of samples to use for interpolation is `degree + 1`. This leads to linear (or quadratic if acceleration is present) *extrapolation* when the degree is not specified in the OEM. Orekit should provide a method to set the default interpolation samples to use if they are not specified in the OEM. E.g. add a method `OemParser.withDefaultInterpolationDegree(int)`.
In an OEM `INTERPOLATION_DEGREE` is optional. In Orekit's implementation if it is not provided then it is assumed to be zero. In Orekit's implementation the number of samples to use for interpolation is `degree + 1`. This leads to linear (or quadratic if acceleration is present) *extrapolation* when the degree is not specified in the OEM. Orekit should provide a method to set the default interpolation samples to use if they are not specified in the OEM. E.g. add a method `OemParser.withDefaultInterpolationDegree(int)`.
10.3
https://gitlab.orekit.org/orekit/orekit/-/issues/710
BatchLSEstimator slowing down with a lot of stations
2020-08-14T10:01:54Z
Pascal Parraud
BatchLSEstimator slowing down with a lot of stations
This is the very special case where each measurement is associated to a different station (i.e. the antenna is on a boat and each measurement is performed from a slightly different location). Of course, no station parameters are estimated in this context.
At the beginning of the BatchLSEstimator estimate method, the construction of the ParameterDriversList using the getMeasurementsParametersDrivers(false) method [line #367] can become very slow as the number of measurements, and thus stations, increases. In my case, the complete orbit restitution process takes 1' with 1000 measurements, 10' with 2000 measurements, 1h15' with 4000 measurements, and the loss of performance is entirely due to this initialization, the duration of the estimation itself remains of the same order.
This is the very special case where each measurement is associated to a different station (i.e. the antenna is on a boat and each measurement is performed from a slightly different location). Of course, no station parameters are estimated in this context.
At the beginning of the BatchLSEstimator estimate method, the construction of the ParameterDriversList using the getMeasurementsParametersDrivers(false) method [line #367] can become very slow as the number of measurements, and thus stations, increases. In my case, the complete orbit restitution process takes 1' with 1000 measurements, 10' with 2000 measurements, 1h15' with 4000 measurements, and the loss of performance is entirely due to this initialization, the duration of the estimation itself remains of the same order.
https://gitlab.orekit.org/orekit/orekit/-/issues/709
Satellite and receiver clock drifts are not taking into account in range-rate...
2020-11-12T11:08:46Z
Bryan Cazabonne
Satellite and receiver clock drifts are not taking into account in range-rate measurement theoritical evalutation.
According to [1], the most significant contributors to the range-rate measurement are the line-of-sight velocity and the receiver clock drift. Furthermore, the satellite clock drift must be also taking into account when modelling a range-rate measurement.
However, these two time drifts are not used in the theoretical evaluation of the range-rate measurement. Their contributions must be added.
Suggestion: Orekit considers receiver and satellite clock offsets. However, range-rate measurement considers clock drifts. Therefore, adding two new `ParameterDriver` to consider the clock drifts (one in ObservableSatellite and another one in `GroundStation`) can be an easy solution to solve the problem.
[1]: Teunissen, P., & Montenbruck, O. (Eds.). (2017). Springer handbook of global navigation satellite systems, Eq. 14.82. Springer.
According to [1], the most significant contributors to the range-rate measurement are the line-of-sight velocity and the receiver clock drift. Furthermore, the satellite clock drift must be also taking into account when modelling a range-rate measurement.
However, these two time drifts are not used in the theoretical evaluation of the range-rate measurement. Their contributions must be added.
Suggestion: Orekit considers receiver and satellite clock offsets. However, range-rate measurement considers clock drifts. Therefore, adding two new `ParameterDriver` to consider the clock drifts (one in ObservableSatellite and another one in `GroundStation`) can be an easy solution to solve the problem.
[1]: Teunissen, P., & Montenbruck, O. (Eds.). (2017). Springer handbook of global navigation satellite systems, Eq. 14.82. Springer.
10.3
https://gitlab.orekit.org/orekit/orekit/-/issues/708
Orekit parses non-existent dates in UTC
2020-07-31T13:41:38Z
Evan Ward
Orekit parses non-existent dates in UTC
The `AbsoluteDate(String, TimeScale)` constructor is inconsistent in its handling of non-existent dates. If the seconds of minute number is `>=61` an exception is thrown, but no exception is thrown if the seconds of minute number is `<61`. For example, an exception will not be thrown for `2009-12-31T23:59:60.5Z` which is an invalid date (no leap second at that time), but an exception will be thrown for `2009-12-31T23:59:61.5Z` which is also an invalid date.
At a minimum the behavior should be documented. For the sake of consistency all invalid times should be treated the same way. Either invalid times throw exceptions, or they don't. If they don't document the algorithm for converting invalid times to valid times.
The also affects `DateTimeComponents.parseDateTime(String)` and `TimeComponents.parseTime(String)`.
Failing test case:
```java
try {
// leap when not expected
new AbsoluteDate("2009-12-31T23:59:60.5Z", utc);
Assert.fail("Expected Exception");
} catch (OrekitException e) {
// expected
}
```
The `AbsoluteDate(String, TimeScale)` constructor is inconsistent in its handling of non-existent dates. If the seconds of minute number is `>=61` an exception is thrown, but no exception is thrown if the seconds of minute number is `<61`. For example, an exception will not be thrown for `2009-12-31T23:59:60.5Z` which is an invalid date (no leap second at that time), but an exception will be thrown for `2009-12-31T23:59:61.5Z` which is also an invalid date.
At a minimum the behavior should be documented. For the sake of consistency all invalid times should be treated the same way. Either invalid times throw exceptions, or they don't. If they don't document the algorithm for converting invalid times to valid times.
The also affects `DateTimeComponents.parseDateTime(String)` and `TimeComponents.parseTime(String)`.
Failing test case:
```java
try {
// leap when not expected
new AbsoluteDate("2009-12-31T23:59:60.5Z", utc);
Assert.fail("Expected Exception");
} catch (OrekitException e) {
// expected
}
```
https://gitlab.orekit.org/orekit/orekit/-/issues/707
Unable to parse 1960-12-31T23:59:61.4
2020-07-31T13:28:42Z
Evan Ward
Unable to parse 1960-12-31T23:59:61.4
The `AbsoluteDate(String, TimeScale)` constructor cannot parse the given date because the leap second then was greater than 1s. Failing test case below.
Not sure if this is worth fixing since it was so long ago. Reporting it here as a known defect for completeness.
```java
// first leap more than 1 s: 1.422818s
Assert.assertEquals(
new AbsoluteDate(1961, 1, 1, utc).shiftedBy(-0.022818),
new AbsoluteDate("1960-12-31T23:59:61.4", utc));
```
throws:
```
org.orekit.errors.OrekitIllegalArgumentException: non-existent time 23:59:61.4
at org.orekit.time.TimeComponents.<init>(TimeComponents.java:114)
at org.orekit.time.TimeComponents.parseTime(TimeComponents.java:364)
at org.orekit.time.DateTimeComponents.parseDateTime(DateTimeComponents.java:173)
at org.orekit.time.AbsoluteDate.<init>(AbsoluteDate.java:290)
```
The `AbsoluteDate(String, TimeScale)` constructor cannot parse the given date because the leap second then was greater than 1s. Failing test case below.
Not sure if this is worth fixing since it was so long ago. Reporting it here as a known defect for completeness.
```java
// first leap more than 1 s: 1.422818s
Assert.assertEquals(
new AbsoluteDate(1961, 1, 1, utc).shiftedBy(-0.022818),
new AbsoluteDate("1960-12-31T23:59:61.4", utc));
```
throws:
```
org.orekit.errors.OrekitIllegalArgumentException: non-existent time 23:59:61.4
at org.orekit.time.TimeComponents.<init>(TimeComponents.java:114)
at org.orekit.time.TimeComponents.parseTime(TimeComponents.java:364)
at org.orekit.time.DateTimeComponents.parseDateTime(DateTimeComponents.java:173)
at org.orekit.time.AbsoluteDate.<init>(AbsoluteDate.java:290)
```
https://gitlab.orekit.org/orekit/orekit/-/issues/706
Satellites clock offsets for InterSatellitesRange measurement missing from me...
2020-10-23T14:59:45Z
Bryan Cazabonne
Satellites clock offsets for InterSatellitesRange measurement missing from measurement parameters drivers
Remote and local satellites clock offsets are taken into account in `InterSatellitesRange` measurement. They are however not available in the measurements parameters.
The following statement should be added to the constructor:
```
if (!twoWay) {
// for one way measurements, the local and remote satellite clock offsets affects the measurement
addParameterDriver(local.getClockOffsetDriver());
addParameterDriver(remote.getClockOffsetDriver());
}
```
Remote and local satellites clock offsets are taken into account in `InterSatellitesRange` measurement. They are however not available in the measurements parameters.
The following statement should be added to the constructor:
```
if (!twoWay) {
// for one way measurements, the local and remote satellite clock offsets affects the measurement
addParameterDriver(local.getClockOffsetDriver());
addParameterDriver(remote.getClockOffsetDriver());
}
```
10.3
Bryan Cazabonne
Bryan Cazabonne
https://gitlab.orekit.org/orekit/orekit/-/issues/705
Allow writing an AEM file from a list of SpacecraftStates
2020-12-07T10:51:13Z
ClĂ©ment Masson
Allow writing an AEM file from a list of SpacecraftStates
This issue is related to [this thread](https://forum.orekit.org/t/writing-spacecraftstates-into-an-aem-file/944) on the forum.
A list of positions/velocities can be written to an OEM file as follows :
```
OrekitEphemerisFile ephemerisFile = new OrekitEphemerisFile();
OrekitEphemerisFile.OrekitSatelliteEphemeris satelliteEphemeris = ephemerisFile.addSatellite(satelliteId);
satelliteEphemeris.addNewSegment(spacecraftStates);
OEMWriter ephemerisFileWriter = new OEMWriter(OEMWriter.InterpolationMethod.HERMITE, originator, satelliteId, spaceObjectName);
ephemerisFileWriter.write(outputFilePath, ephemerisFile);
```
However, @bryan explained in the thread that this method doesn't work for AEM files, because `AEMFile` doesn't implement `EphemerisFile` and `AemSatelliteEphemeris` doesn't implement `SatelliteEphemeris`. The reason for that is these interfaces have methods that are specific to position/velocity ephemeris, and incompatible with attitude files. He suggested adding exceptions for those cases.
This issue is related to [this thread](https://forum.orekit.org/t/writing-spacecraftstates-into-an-aem-file/944) on the forum.
A list of positions/velocities can be written to an OEM file as follows :
```
OrekitEphemerisFile ephemerisFile = new OrekitEphemerisFile();
OrekitEphemerisFile.OrekitSatelliteEphemeris satelliteEphemeris = ephemerisFile.addSatellite(satelliteId);
satelliteEphemeris.addNewSegment(spacecraftStates);
OEMWriter ephemerisFileWriter = new OEMWriter(OEMWriter.InterpolationMethod.HERMITE, originator, satelliteId, spaceObjectName);
ephemerisFileWriter.write(outputFilePath, ephemerisFile);
```
However, @bryan explained in the thread that this method doesn't work for AEM files, because `AEMFile` doesn't implement `EphemerisFile` and `AemSatelliteEphemeris` doesn't implement `SatelliteEphemeris`. The reason for that is these interfaces have methods that are specific to position/velocity ephemeris, and incompatible with attitude files. He suggested adding exceptions for those cases.
10.3
https://gitlab.orekit.org/orekit/orekit/-/issues/704
Allow using user specified velocity error for computing tolerance vectors for...
2020-10-23T14:59:44Z
Bryan Cazabonne
Allow using user specified velocity error for computing tolerance vectors for integrators
Currently only user specified position error is used to compute tolerance vectors for integrators, velocity error is computed inside the method. It can be useful to have a method signature allowing user to specified both position and velocity errors to compute tolerance vectors for integrators.
Currently only user specified position error is used to compute tolerance vectors for integrators, velocity error is computed inside the method. It can be useful to have a method signature allowing user to specified both position and velocity errors to compute tolerance vectors for integrators.
10.3
https://gitlab.orekit.org/orekit/orekit/-/issues/703
Add inter-satellites phase measurements
2020-10-23T14:59:45Z
Bryan Cazabonne
Add inter-satellites phase measurements
LEO satellites can receive both range and phase measurements from GNSS satellites. Inter-satellites range measurement is implemented in Orekit, not the phase.
LEO satellites can receive both range and phase measurements from GNSS satellites. Inter-satellites range measurement is implemented in Orekit, not the phase.
10.3
Bryan Cazabonne
Bryan Cazabonne
https://gitlab.orekit.org/orekit/orekit/-/issues/702
Eclipses by Moon not considered in solar radiation pressure force model
2021-01-12T09:50:45Z
Luc Maisonobe
Eclipses by Moon not considered in solar radiation pressure force model
The solar radiation pressure force model does not consider the
eclipses generated by Moon.
This induces errors in orbit determination for GNSS satellites at some epochs.
The solar radiation pressure force model does not consider the
eclipses generated by Moon.
This induces errors in orbit determination for GNSS satellites at some epochs.
11.0
https://gitlab.orekit.org/orekit/orekit/-/issues/701
Kalman estimator confuses propagation parameters in multi-sat context
2020-07-31T13:06:43Z
Luc Maisonobe
Kalman estimator confuses propagation parameters in multi-sat context
When Kalman estimation is performed in a multi-satellite context, propagation parameters are not put in the proper column of measurement matrix.
The `KalmanModel` constructor sets up a `propagationParameterColumns` map to associate propagation parameters to columns, but this map is not stored as an instance field. When `getMeasurementMatrix` is called, it just counts parameters, assuming the propagation parameters are placed just after the estimated orbital parameters. If we consider two satellites and estimate the 6 orbital parameters and 2 propagation parameters for each. Then the estimated state has dimension 16. The `KalmanModel` constructor will properly assign columns 0:5 to orbit 1, 6:11 to orbit 2, 12:13 to propagation parameters 1 and 14:15 to propagation parameters 2. However, `getMeasurementMatrix` will fill up the measurement matrix with partial derivatives wrt orbit 1 to columns 0:5, partial derivatives wrt propagation parameters 1 to columns 6:7, partial derivatives wrt orbit 2 to columns 6:11 (overriding derivatives wrt propagation parameters 1), partial derivatives wrt propagation parameters 2 to columns 12:13 and never filling columns 14:15.
When Kalman estimation is performed in a multi-satellite context, propagation parameters are not put in the proper column of measurement matrix.
The `KalmanModel` constructor sets up a `propagationParameterColumns` map to associate propagation parameters to columns, but this map is not stored as an instance field. When `getMeasurementMatrix` is called, it just counts parameters, assuming the propagation parameters are placed just after the estimated orbital parameters. If we consider two satellites and estimate the 6 orbital parameters and 2 propagation parameters for each. Then the estimated state has dimension 16. The `KalmanModel` constructor will properly assign columns 0:5 to orbit 1, 6:11 to orbit 2, 12:13 to propagation parameters 1 and 14:15 to propagation parameters 2. However, `getMeasurementMatrix` will fill up the measurement matrix with partial derivatives wrt orbit 1 to columns 0:5, partial derivatives wrt propagation parameters 1 to columns 6:7, partial derivatives wrt orbit 2 to columns 6:11 (overriding derivatives wrt propagation parameters 1), partial derivatives wrt propagation parameters 2 to columns 12:13 and never filling columns 14:15.
10.3
Luc Maisonobe
Luc Maisonobe
https://gitlab.orekit.org/orekit/orekit/-/issues/700
Titles of the Download documentation page disapeared
2020-11-18T13:25:50Z
Guilhem Bonnefille
Titles of the Download documentation page disapeared
Since moving download page into markown+velocity the titles disapeared.
* Wrong: https://www.orekit.org/site-orekit-development/downloads.html
* Correct: https://www.orekit.org/site-orekit-10.0/downloads.html
Since moving download page into markown+velocity the titles disapeared.
* Wrong: https://www.orekit.org/site-orekit-development/downloads.html
* Correct: https://www.orekit.org/site-orekit-10.0/downloads.html
10.3
Guilhem Bonnefille
Guilhem Bonnefille
https://gitlab.orekit.org/orekit/website-2015/-/issues/8
Rugged: Update continuous integration link and add links to source code quali...
2020-07-20T14:05:37Z
Guylaine Prat
Rugged: Update continuous integration link and add links to source code quality and coverage
CI was updated for Rugged (like in Orekit):
* under Community tab:
- change link from Jenkins to Gitlab CI pipelines: https://gitlab.orekit.org/orekit/rugged/pipelines
- add link to Source code quality: https://sonar.orekit.org/dashboard?id=org.orekit%3Arugged
* in the home page, add badges to :
- quality date (source code quality): https://sonar.orekit.org/dashboard?id=org.orekit%3Arugged
- coverage: https://sonar.orekit.org/component_measures?id=org.orekit%3Arugged&metric=coverage&view=treemap
CI was updated for Rugged (like in Orekit):
* under Community tab:
- change link from Jenkins to Gitlab CI pipelines: https://gitlab.orekit.org/orekit/rugged/pipelines
- add link to Source code quality: https://sonar.orekit.org/dashboard?id=org.orekit%3Arugged
* in the home page, add badges to :
- quality date (source code quality): https://sonar.orekit.org/dashboard?id=org.orekit%3Arugged
- coverage: https://sonar.orekit.org/component_measures?id=org.orekit%3Arugged&metric=coverage&view=treemap
Guylaine Prat
Guylaine Prat
https://gitlab.orekit.org/orekit/orekit/-/issues/699
Satellite clock offset for Phase measurement missing from measurement paramet...
2020-10-23T14:59:42Z
Luc Maisonobe
Satellite clock offset for Phase measurement missing from measurement parameters drivers
Satellite clock offset are taken into account in Phase measurement since commit 3795667ecf8d8a401420d10a1bd490487de65e6f.
It is however not available in the measurements parameters.
The following statement should be added to the constructor:
```java
addParameterDriver(satellite.getClockOffsetDriver());
```
Satellite clock offset are taken into account in Phase measurement since commit 3795667ecf8d8a401420d10a1bd490487de65e6f.
It is however not available in the measurements parameters.
The following statement should be added to the constructor:
```java
addParameterDriver(satellite.getClockOffsetDriver());
```
10.3