Orekit issueshttps://gitlab.orekit.org/orekit/orekit/-/issues2024-03-28T19:07:36Zhttps://gitlab.orekit.org/orekit/orekit/-/issues/1362Extract clock model from Rinex observation files2024-03-28T19:07:36ZLuc MaisonobeExtract clock model from Rinex observation filesRinex observation files optionally contain receiver clock offsets.
These offsets can be used to build a clock model, and they are needed when splicing files and rewriting observations.Rinex observation files optionally contain receiver clock offsets.
These offsets can be used to build a clock model, and they are needed when splicing files and rewriting observations.12.1Luc MaisonobeLuc Maisonobehttps://gitlab.orekit.org/orekit/orekit/-/issues/1357Zeros in unscented covariance2024-03-28T08:15:38ZMark RuttenZeros in unscented covarianceThe unscented filter produces zeros in the covariance matrix when including propagators parameters. This isn't the case with the kalman filter whereas I would expect both to behave very similarly.
This is the original [forum discussion...The unscented filter produces zeros in the covariance matrix when including propagators parameters. This isn't the case with the kalman filter whereas I would expect both to behave very similarly.
This is the original [forum discussion thread](https://forum.orekit.org/t/unscented-filter-propagation-parameters-covariance/3405).Mark RuttenMark Ruttenhttps://gitlab.orekit.org/orekit/orekit/-/issues/1358Add native AdpatableInterval for ApsideDetector2024-03-28T08:15:10ZRomain SerraAdd native AdpatableInterval for ApsideDetector12.1Romain SerraRomain Serrahttps://gitlab.orekit.org/orekit/orekit/-/issues/1310Creating an AbsoluteDate with createJDDate() at TDBscale introduces error2024-03-25T14:46:29ZSimonas StaseviciusCreating an AbsoluteDate with createJDDate() at TDBscale introduces errorI tried to create an `AbsoluteDate` corresponding to 2460157.5 JDTDB like so:
`TDBScale TDBscale = TimeScalesFactory.getTDB();`
`AbsoluteDate date = AbsoluteDate.createJDDate(2460157, Constants.JULIAN_DAY/2.0d, TDBscale);`
The expe...I tried to create an `AbsoluteDate` corresponding to 2460157.5 JDTDB like so:
`TDBScale TDBscale = TimeScalesFactory.getTDB();`
`AbsoluteDate date = AbsoluteDate.createJDDate(2460157, Constants.JULIAN_DAY/2.0d, TDBscale);`
The expected date is 2023-08-01T00:00:00.000, however `date.toString(TDBscale)` gives 2023-07-31T23:59:59.99998730725312 instead.
As observed by @MaximeJ in the forum [post](https://forum.orekit.org/t/earth-position-does-not-match-that-of-jpl-horizons/3211/2), the discrepancy comes from the way `createJDDate()` is written. It applies the offset of TDB from TAI at noon and then shifts the date by the fractional Julian day part. However, the offset from TAI is different at the final date than that at noon.https://gitlab.orekit.org/orekit/orekit/-/issues/1351Remove inner private class JacobiPolynomials.JacobiKey2024-03-22T20:49:49ZMaxime JournotRemove inner private class JacobiPolynomials.JacobiKeySince [JacobiKey](https://github.com/Hipparchus-Math/hipparchus/blob/b8b88c512e0f6b30f4e43075a2089e1f14edcae9/hipparchus-core/src/main/java/org/hipparchus/analysis/polynomials/PolynomialsUtils.java#L270) is now a public class in Hipparch...Since [JacobiKey](https://github.com/Hipparchus-Math/hipparchus/blob/b8b88c512e0f6b30f4e43075a2089e1f14edcae9/hipparchus-core/src/main/java/org/hipparchus/analysis/polynomials/PolynomialsUtils.java#L270) is now a public class in Hipparchus (see Hipparchus [issue 322](https://github.com/Hipparchus-Math/hipparchus/issues/322)), there's no need to have it duplicated in Orekit class [JacobiPolynomials](https://gitlab.orekit.org/orekit/orekit/-/blob/master/src/main/java/org/orekit/propagation/semianalytical/dsst/utilities/JacobiPolynomials.java?ref_type=heads#L182)12.1Maxime JournotMaxime Journothttps://gitlab.orekit.org/orekit/orekit/-/issues/1350Changing return type of MeasurementBuilder.build2024-03-22T19:28:17ZLuc MaisonobeChanging return type of MeasurementBuilder.buildThe `MeasurementBuilder` interface is used by Orekit measurements generation feature. It is specialized for each measurement type. Its `build` method returns a specific `ObservedMeasurement<T>` (i.e `Range` for `RangeBuilder`, `Phase` fo...The `MeasurementBuilder` interface is used by Orekit measurements generation feature. It is specialized for each measurement type. Its `build` method returns a specific `ObservedMeasurement<T>` (i.e `Range` for `RangeBuilder`, `Phase` for `PhaseBuilder`…).
Internally, all implementations work by creating first a dummy `ObservedMeasurement<T>`, then call its `estimateWithoutDerivatives` to build an `EstimatedMeasurementBase<T>`, retrieve from this intermediate object the true measurement value and finally build another `ObservedMeasurement<T>` with the correct value. This second `ObservedMeasurement<T>` is then returned through a bunch of classes (`AbstractScheduler`, then an internal step handler, then `Generator`). At the end, it is passed to a `GeneratedMeasurementSubscriber`).
I have a use case where the information present in the `ObservedMeasurement<T>` is not sufficient; I would need to get the states of the spacecraft involved in the measurement, as they hold some additional states I need. I cannot just call again the propagators that are used by the `Generator` because doing this stalls the generation (probably some kind of dead lock or infinite recursion as the propagator calls the measurements generator which then would call the propagator back). Setting up another propagator also seems a waste of resources since the states have already been computed during the measurement generation; they were just thrown away when building the second `ObservedMeasurement<T>` from the `EstimatedMeasurementBase<T>`.
This issue intends to change the API of `MeasurementBuilder` and all the intermediate classes so the measurements that are built and returned to users are `EstimatedMeasurementBase<T>` rather than `ObservedMeasurement<T>`. It targets Orekit 13.0 milestone as it changes several public signatures. Partial backward compatibility is ensured as `ObservedMeasurement<T>` can be retrieved from the `EstimatedMeasurementBase<T>` using its `getObservedMeasurement()` method. The returned `EstimatedMeasurementBase<T>` contains much more information than `ObservedMeasurement<T>` (states, participants...).13.0Luc MaisonobeLuc Maisonobehttps://gitlab.orekit.org/orekit/orekit/-/issues/1104Discrepancy in osculating elements between DSST and numerical propagators wit...2024-03-20T15:59:24ZMaxime JournotDiscrepancy in osculating elements between DSST and numerical propagators with 2x0 gravity fieldI've noticed a discrepancy in osculating elements when comparing orbits between DSST and numerical propagators.
Configuration:
- LEO satellite
- Gravity field 2x0 (but an higher degree x order gives the same results)
- Zonal and Tess...I've noticed a discrepancy in osculating elements when comparing orbits between DSST and numerical propagators.
Configuration:
- LEO satellite
- Gravity field 2x0 (but an higher degree x order gives the same results)
- Zonal and Tesseral DSST forces (with or without J2² mean effect)
- Propagation on 50 orbits
Result:
- Discrepancy between osculating elements on all 6 orbital parameters
- Ex. bias of about 20m on semi-major axis and parabolic evolution of inclination leading to a mean error of 0.4 mdeg after 50 orbits
→ See figure belowhttps://gitlab.orekit.org/orekit/orekit/-/issues/1348FieldDsstPropagator#afterIntegration does nothing2024-03-19T17:29:41ZBryan CazabonneFieldDsstPropagator#afterIntegration does nothingThe following implementation does nothing
```
protected void afterIntegration() {
// remove the special short periodics step handler if added before
if (isMeanOrbit() == PropagationType.OSCULATING) {
fin...The following implementation does nothing
```
protected void afterIntegration() {
// remove the special short periodics step handler if added before
if (isMeanOrbit() == PropagationType.OSCULATING) {
final List<FieldODEStepHandler<T>> preserved = new ArrayList<>();
final FieldODEIntegrator<T> integrator = getIntegrator();
// clear the list
integrator.clearStepHandlers();
// add back the step handlers that were important for the user
for (final FieldODEStepHandler<T> sp : preserved) {
integrator.addStepHandler(sp);
}
}
}
```
It shall be updated following DSSTPropagator implementation.https://gitlab.orekit.org/orekit/orekit/-/issues/1265Improve coverage for 12.X versions2024-03-19T17:04:44ZMaxime JournotImprove coverage for 12.X versionsFollowing the release of 12.0, the coverage on new code, that was up to 95.2% on develop branch, inexplicably dropped to 94.8% when the merge on master branch was done.
See the list of uncovered lines [here](https://sonar.orekit.org/co...Following the release of 12.0, the coverage on new code, that was up to 95.2% on develop branch, inexplicably dropped to 94.8% when the merge on master branch was done.
See the list of uncovered lines [here](https://sonar.orekit.org/component_measures?branch=master&id=orekit%3Aorekit&metric=new_line_coverage).
And now the quality gate is on "warning" on Orekit's [official website](https://orekit.org)...
I think this should be fixed in the next patchhttps://gitlab.orekit.org/orekit/orekit/-/issues/1311Account for EOP libration correction2024-03-19T16:14:54ZGaëtan PierreAccount for EOP libration correctionAdd the variations in pole coordinates corresponding to motions with periods less than two days in space that are not part of the IAU 2000 nutation model.
In IERS Convention 2010, see equation 5.11, Table 5.1a (which is already present i...Add the variations in pole coordinates corresponding to motions with periods less than two days in space that are not part of the IAU 2000 nutation model.
In IERS Convention 2010, see equation 5.11, Table 5.1a (which is already present in the resources) for pole corrections and Table 5.1b for UT1 and LOD corrections.
In the current implementation, only corrections due to ocean tide effects are taken into account.https://gitlab.orekit.org/orekit/orekit/-/issues/1349Add more overrides of getAttitudeRotation2024-03-19T16:07:47ZRomain SerraAdd more overrides of getAttitudeRotationConcerns implementations of `AttitudeProvider`
For example in `FixedRate`Concerns implementations of `AttitudeProvider`
For example in `FixedRate`https://gitlab.orekit.org/orekit/orekit/-/issues/1312Add more overrides of getStaticTransform in TransformProvider2024-03-19T16:07:33ZRomain SerraAdd more overrides of getStaticTransform in TransformProviderFor example in TODproviderFor example in TODproviderhttps://gitlab.orekit.org/orekit/orekit/-/issues/1298CPF parser ignores direction flag - causing an exception later2024-03-11T09:45:33ZM. VeltenCPF parser ignores direction flag - causing an exception later**The Problem**
Tested with Orekit 12.0.1.
As described in the [forum](https://forum.orekit.org/t/cpf-parser-ignores-direction-flag-causing-an-exception-later/3112), the CPF parser (`org.orekit.files.ilrs.CPFParser:470`) ignores the di...**The Problem**
Tested with Orekit 12.0.1.
As described in the [forum](https://forum.orekit.org/t/cpf-parser-ignores-direction-flag-causing-an-exception-later/3112), the CPF parser (`org.orekit.files.ilrs.CPFParser:470`) ignores the direction flag of position lines - index 1 in the generated array:
~~~java
/** Position values. */
TEN("10") {
/** {@inheritDoc} */
@Override
public void parse(final String line, final ParseInfo pi) {
// Data contained in the line
final String[] values = SEPARATOR.split(line);
// Epoch
final int mjd = Integer.parseInt(values[2]);
~~~
The direction flag is ignored for the other implemented line type parser (20), too.
The possible directional flag values are, according to the [CPF documentation (page 15)](https://ilrs.gsfc.nasa.gov/docs/2018/cpf_2.00h-1.pdf):
~~~
Common epoch (0):
instantaneous vector between geocenter and target, without light-time iteration. This epoch is the same as found in the corresponding old TIV format.
Transmit (1):
position vector contains light-time iterated travel time from the geocenter to the target at the transmit epoch.
Receive (2):
position vector contains light-time iterated travel time from the target to the geocenter at the receive epoch.
(The sign of each element is opposite to that of the transmit vector.)
~~~
For objects on the moon (apollo11, apollo 15 luna17 and luna21 on https://edc.dgfi.tum.de/pub/slr/cpf_predicts_v2/current) the inbound and outbound position vectors are given for the same time:
~~~
H1 CPF 2 OPA 2024 01 03 18 003 1 apollo11 OPA_ELP96
H2 100 100 0 2024 1 4 0 0 0 2024 1 8 23 45 0 900 0 1 0 0 0 3
H9
10 1 60313 0.0 0 16126075.681 398785441.280 -26042850.417
10 2 60313 0.0 0 -16202176.985 -398701851.546 26035563.466
30 1 -741. -40216. 3643. 26.9
10 1 60313 900.0 0 41473086.247 396893016.626 -26449307.496
10 2 60313 900.0 0 -41543554.533 -396804772.095 26442015.393
30 1 -3370. -40078. 3646. 26.9
~~~
**The outcome**
This causes an exception when interpolating between the points, because the time difference is zero:
~~~java
Exception in thread "main" org.hipparchus.exception.MathIllegalArgumentException: duplicated abscissa 0 causes division by zero
at org.hipparchus.analysis.interpolation.HermiteInterpolator.addSamplePoint(HermiteInterpolator.java:113)
at org.orekit.utils.TimeStampedPVCoordinatesHermiteInterpolator.lambda$interpolate$0(TimeStampedPVCoordinatesHermiteInterpolator.java:148)
at java.base/java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1655)
at java.base/java.util.stream.ReferencePipeline$Head.forEach(ReferencePipeline.java:658)
at org.orekit.utils.TimeStampedPVCoordinatesHermiteInterpolator.interpolate(TimeStampedPVCoordinatesHermiteInterpolator.java:146)
at org.orekit.utils.TimeStampedPVCoordinatesHermiteInterpolator.interpolate(TimeStampedPVCoordinatesHermiteInterpolator.java:39)
at org.orekit.time.AbstractTimeInterpolator.interpolate(AbstractTimeInterpolator.java:91)
at org.orekit.files.general.EphemerisSegmentPropagator.getPVCoordinates(EphemerisSegmentPropagator.java:115)
~~~
**Test-code**
This exception can be generated with this code snippet:
~~~
CPF cpfFile = new CPFParser().parse(new DataSource("satellite.cpf", new DataSource.ReaderOpener()
{
@Override
public Reader openOnce() throws IOException
{
return new StringReader("H1 CPF 2 OPA 2024 01 03 18 003 1 apollo11 OPA_ELP96\n"
+ "H2 100 100 0 2024 1 4 0 0 0 2024 1 8 23 45 0 900 0 1 0 0 0 3\n"
+ "H9\n"
+ "10 1 60313 0.0 0 16126075.681 398785441.280 -26042850.417\n"
+ "10 2 60313 0.0 0 -16202176.985 -398701851.546 26035563.466\n"
+ "30 1 -741. -40216. 3643. 26.9\n"
+ "10 1 60313 900.0 0 41473086.247 396893016.626 -26449307.496\n"
+ "10 2 60313 900.0 0 -41543554.533 -396804772.095 26442015.393\n"
+ "30 1 -3370. -40078. 3646. 26.9\n"
+ "10 1 60313 1800.0 0 66644291.059 393390899.000 -26855631.271\n"
+ "10 2 60313 1800.0 0 -66708842.979 -393298378.023 26848334.019\n"
+ "30 1 -5984. -39769. 3648. 26.9\n"
+ "10 1 60313 2700.0 0 91537552.217 388293816.394 -27261819.596\n"
+ "10 2 60313 2700.0 0 -91595929.760 -388197414.474 27254517.199\n"
+ "30 1 -8572. -39289. 3651. 26.8\n"
+ "10 1 60313 3600.0 0 116051895.405 381622972.022 -27667870.319\n"
+ "10 2 60313 3600.0 0 -116103866.930 -381523100.119 27660562.779\n"
+ "30 1 -11123. -38641. 3653. 26.8\n"
+ "10 1 60313 4500.0 0 140087920.030 373405955.825 -28073781.283\n"
+ "10 2 60313 4500.0 0 -140133281.178 -373303038.613 28066468.603\n"
+ "30 1 -13625. -37827. 3656. 26.8\n"
+ "10 1 60313 5400.0 0 163548202.818 363676629.997 -28479550.326\n"
+ "10 2 60313 5400.0 0 -163586777.325 -363571104.045 28472232.508\n"
+ "30 1 -16069. -36852. 3658. 26.8\n"
+ "99");
}
}));
for (CPFEphemeris ephemerisEntry : cpfFile.getSatellites().values()) {
ephemerisEntry.getPropagator().getPVCoordinates(ephemerisEntry.getStart(), FramesFactory.getITRF(IERSConventions.IERS_2010, true));
}
~~~
**Solution**
Ignore lines with direction flag value = 2 solves this issue. Probably it should be configurable which direction should be parsed?https://gitlab.orekit.org/orekit/orekit/-/issues/1340SRP dependance on position only should be true for isotropic models2024-03-10T14:20:33ZRomain SerraSRP dependance on position only should be true for isotropic models`false` slows down STM computation so should be avoided if possible
Could be done at same time than #1337`false` slows down STM computation so should be avoided if possible
Could be done at same time than #133712.1https://gitlab.orekit.org/orekit/orekit/-/issues/1161Add static method to create an event detector that would be activated or deac...2024-03-07T18:54:11ZVincent CUCCHIETTIvincent.cucchietti@csgroup.euAdd static method to create an event detector that would be activated or deactivated through another event detectorHi everyone,
After discussing with @Jasquier, we thought that a simple but yet very useful feature could be added to Orekit.
The idea would be to add static methods to ```EventEnablingPredicateFilter``` to easily create a detector that...Hi everyone,
After discussing with @Jasquier, we thought that a simple but yet very useful feature could be added to Orekit.
The idea would be to add static methods to ```EventEnablingPredicateFilter``` to easily create a detector that would be linked to another detector. For example :
```
newDetector = EventEnablingPredicateFilter.activateEventIfEventIsDetected(eventDetectorToActivate, otherEventDetector)
```
or
```
newDetector = EventEnablingPredicateFilter.deactivateEventIfEventIsDetected(eventDetectorToDeactivate, otherEventDetector)
```
This would allow for very interesting and computationally efficient uses such as linking maneuvers with each other so that the propagator would not check all maneuver triggers but only the one of the next maneuver.
Cheers,
Vincenthttps://gitlab.orekit.org/orekit/orekit/-/issues/1337Add getter for RadiationPressureSensitive in SolarRadiationPressure2024-03-07T16:52:16ZRomain SerraAdd getter for RadiationPressureSensitive in SolarRadiationPressure12.1https://gitlab.orekit.org/orekit/orekit/-/issues/1036Improve estimation of propagation and measurement parameters with Unscented K...2024-03-04T21:18:59ZBryan CazabonneImprove estimation of propagation and measurement parameters with Unscented Kalman FilterCurrently the Unscented Kalman Filter can "estimate" propagation and measurement parameters without throwing any exception. However, because these parameters are not “time propagated” like orbital parameters, the propagated sigma points ...Currently the Unscented Kalman Filter can "estimate" propagation and measurement parameters without throwing any exception. However, because these parameters are not “time propagated” like orbital parameters, the propagated sigma points are equals to the initial sigma points for these parameters. As a results, they don’t have any evolution because the computation of the corrected value depends on the difference between the propagated and the initial ones.
A solution is presented in the following paper:
Matthew C. VANDYKE et al. Unscented Kalman Filtering for Spacecraft attitude state and parameter estimation. AAS.
Probably the fix will also need modifications in Hipparchus.https://gitlab.orekit.org/orekit/orekit/-/issues/1024Add covariance matrices for propagation and measurement parameters in StateCo...2024-03-04T21:17:51ZBryan CazabonneAdd covariance matrices for propagation and measurement parameters in StateCovarianceThe tasks to performe are:
1. Add a new method `isCovarianceInLof()` in `StateCovariance`.
```
public boolean isCovarianceInLof() {
return lofType != null;
}
```
2. Add two new attributes in `StateCovariance` class:
```
private ...The tasks to performe are:
1. Add a new method `isCovarianceInLof()` in `StateCovariance`.
```
public boolean isCovarianceInLof() {
return lofType != null;
}
```
2. Add two new attributes in `StateCovariance` class:
```
private final RealMatrix propagationParametersCovariance;
private final RealMatrix measurementParametersCovariance;
```
3. Add new getters in `StateCovariance`: `getPropagationParametersCovariance()`, `getMeasurementParametersCovariance()`, and `getOrbitalParametersCovariance()`
4. Add a `getCovariance()` method that returns the full covariance.
5. Update the `StateCovarianceMatrixProvider` class to propagate the covariance parts corresponding to the propagation and measurements parameters. Note: propagate the covariance corresponding to the measurement parameters is done by multiplying by the identity matrix. For the measurement parameters, use the state transition matrix.
Maybe it could be important to note in the documentation of the `StateCovarianceMatrixProvider` how the matrix shall ordered according to Orekit's convention.https://gitlab.orekit.org/orekit/orekit/-/issues/1331Add (Field)RelativeDistanceDetector2024-03-02T14:07:25ZRomain SerraAdd (Field)RelativeDistanceDetector12.1Vincent CUCCHIETTIvincent.cucchietti@csgroup.euVincent CUCCHIETTIvincent.cucchietti@csgroup.euhttps://gitlab.orekit.org/orekit/orekit/-/issues/1334Plug in more Hipparchus interpolators in Ephemeris class2024-03-02T14:07:11ZRomain SerraPlug in more Hipparchus interpolators in Ephemeris classAs discussed [here](https://forum.orekit.org/t/interpolators-plugged-in-ephemeris-class/3328/5)As discussed [here](https://forum.orekit.org/t/interpolators-plugged-in-ephemeris-class/3328/5)12.1Vincent CUCCHIETTIvincent.cucchietti@csgroup.euVincent CUCCHIETTIvincent.cucchietti@csgroup.eu