Orekit issueshttps://gitlab.orekit.org/groups/orekit/-/issues2024-03-28T08:15:10Zhttps://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/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/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/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/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/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/1337Add getter for RadiationPressureSensitive in SolarRadiationPressure2024-03-07T16:52:16ZRomain SerraAdd getter for RadiationPressureSensitive in SolarRadiationPressure12.1https://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.euhttps://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/1330Add FieldExtremumApproachDetector2024-03-01T19:20:49ZRomain SerraAdd FieldExtremumApproachDetectorThere is no `Field` equivalent to `ExtremumApproachProvider`There is no `Field` equivalent to `ExtremumApproachProvider`12.1Vincent CUCCHIETTIvincent.cucchietti@csgroup.euVincent CUCCHIETTIvincent.cucchietti@csgroup.euhttps://gitlab.orekit.org/orekit/orekit/-/issues/1326CDM KVN Spaces2024-02-27T19:00:07ZEvan WardCDM KVN SpacesI've seen some CDMs that Orekit's `CdmParser` is not able to parse.
In one case there is not value between the number and the units, e.g.
```
CTDOT_TDOT =0.0001[m**2/s**2]
```
I know the CCSDS standard in Section 6.3.3 says "there...I've seen some CDMs that Orekit's `CdmParser` is not able to parse.
In one case there is not value between the number and the units, e.g.
```
CTDOT_TDOT =0.0001[m**2/s**2]
```
I know the CCSDS standard in Section 6.3.3 says "there must be at least one blank character between the value and the units", but in this case it shouldn't be to hard to separate them. Note that Orekit's own `KvnGenerator` will generate files like this with no space between the value and units if the units and alignment columns are too close.
I've also seen lines like the following with just a bunch of blanks after the `=`.
```
TIME_LASTOB_START =
```
I don't see in the CCSDS standard where it says the key shall not appear when an optional value is not present. So I think this one could be considered standard conforming.
See https://forum.orekit.org/t/cdmparser-kvn-enhancements/3309https://gitlab.orekit.org/orekit/orekit/-/issues/1324The method withHandler((state, detector, increasing) → {…}) fails if applied ...2024-02-17T19:32:46ZFrancesca PanzettaThe method withHandler((state, detector, increasing) → {…}) fails if applied after an eventsLogger.monitorDetector(detector)In Orekit version 11.1.2 the following pseudo code was working fine:
EventsLogger eventsLogger = new EventsLogger();
eventsLogger.monitorDetector(new DateDetector(maneuverStartDate)).withHandler((state, detector, increasing) → {System.o...In Orekit version 11.1.2 the following pseudo code was working fine:
EventsLogger eventsLogger = new EventsLogger();
eventsLogger.monitorDetector(new DateDetector(maneuverStartDate)).withHandler((state, detector, increasing) → {System.out.println(“entering here”);})
While in the latest version of Orekit 12.0.1, the withHandler((state, detector, increasing) → {...}) is not working anymore.
Discussion on the forum at https://forum.orekit.org/t/unexpected-behavior-when-using-withhandler-state-detector-increasing-after-eventslogger-monitordetector-detector/3287https://gitlab.orekit.org/orekit/orekit/-/issues/1323IntelsatElevenElementsPropagatorTest failing if run separately2024-02-09T23:11:49ZRomain SerraIntelsatElevenElementsPropagatorTest failing if run separatelyThere seems to be no time data loading in BeforeAllThere seems to be no time data loading in BeforeAllhttps://gitlab.orekit.org/orekit/orekit/-/issues/1320TDM parser fails on two CCSDS examples2024-02-06T12:26:43ZClément MassonTDM parser fails on two CCSDS examplesI've noticed that the TDM parser fails to read two of the examples provided in the [TDM standard](https://public.ccsds.org/Pubs/503x0b2c1.pdf).
I'm testing this with the Python wrapper:
```python
from org.orekit.data import DataSource
...I've noticed that the TDM parser fails to read two of the examples provided in the [TDM standard](https://public.ccsds.org/Pubs/503x0b2c1.pdf).
I'm testing this with the Python wrapper:
```python
from org.orekit.data import DataSource
from org.orekit.files.ccsds.ndm import ParserBuilder
from org.orekit.files.ccsds.ndm.tdm import Tdm
data_source = DataSource(str("C:\\TMPDIR\\example_10.txt"))
parsed_file = Tdm.cast_(ParserBuilder().buildTdmParser().parseMessage(data_source))
```
# Example 10 (page 86 on the standard)
[example_10.txt](/uploads/b5e79afcf695bdf346ad5fb40a1410bc/example_10.txt)
> org.orekit.errors.OrekitException: mot-clef inattendu à la ligne 25 du fichier CCSDS C:\TMPDIR\example_10.txt :
TRANSMIT_FREQ_1
at org.orekit.files.ccsds.utils.parsing.ErrorState.processToken(ErrorState.java:55)
at org.orekit.files.ccsds.utils.parsing.AbstractMessageParser.process(AbstractMessageParser.java:220)
at org.orekit.files.ccsds.utils.lexical.KvnLexicalAnalyzer.accept(KvnLexicalAnalyzer.java:138)
at org.orekit.files.ccsds.utils.parsing.AbstractMessageParser.parseMessage(AbstractMessageParser.java:156)
I'm not sure what's wrong here.
# Example 17 (page 93 on the standard)
[example_17.txt](/uploads/ff9bccbf524bce958443d6bde649fd74/example_17.txt)
> org.orekit.errors.OrekitException: mot-clef inattendu à la ligne 12 du fichier CCSDS C:\TMPDIR\example_17.txt :
EPHEMERIS_NAME
at org.orekit.files.ccsds.utils.parsing.ErrorState.processToken(ErrorState.java:55)
at org.orekit.files.ccsds.utils.parsing.AbstractMessageParser.process(AbstractMessageParser.java:220)
at org.orekit.files.ccsds.utils.lexical.KvnLexicalAnalyzer.accept(KvnLexicalAnalyzer.java:138)
at org.orekit.files.ccsds.utils.parsing.AbstractMessageParser.parseMessage(AbstractMessageParser.java:156)
For this one, it seems (looking at [the TdmMetadataKey code](https://gitlab.orekit.org/orekit/orekit/-/blob/develop/src/main/java/org/orekit/files/ccsds/ndm/tdm/TdmMetadataKey.java#L71) that Orekit expects numbered fields for EPHEMERIS_NAME (EPHEMERIS_NAME_1, etc.), which is consistent with the table on page 67, but not with the example or with the table on page 112. So it seems there is an inconsistency in the standard.https://gitlab.orekit.org/orekit/orekit/-/issues/1319CDM XML Parser should ignore empty not mandatory fields2024-02-02T17:23:57ZSabrina SarraCDM XML Parser should ignore empty not mandatory fieldsThe CDM Parser should ignore empty not mandatory fields by parsing CDM in XML format.
At the moment, empty tags like
<START_SCREEN_PERIOD nil=“true”/>
or
<START_SCREEN_PERIOD />
or
<START_SCREEN_PERIOD/></START_SCREEN_PERIOD>
raise exc...The CDM Parser should ignore empty not mandatory fields by parsing CDM in XML format.
At the moment, empty tags like
<START_SCREEN_PERIOD nil=“true”/>
or
<START_SCREEN_PERIOD />
or
<START_SCREEN_PERIOD/></START_SCREEN_PERIOD>
raise exception reading CDM file from JSPOC.
The issue does not occurr if the optional fields are not present at all.
https://forum.orekit.org/t/cdm-xml-parsing-error/3206https://gitlab.orekit.org/orekit/orekit/-/issues/1316Regression in EphemerisPropagatorBuilder API2024-02-01T10:39:58ZVincent CUCCHIETTIvincent.cucchietti@csgroup.euRegression in EphemerisPropagatorBuilder APIHi all,
@MaximeJ noticed that the previously available constructor :
```EphemerisPropagatorBuilder(List<SpacecraftState> states, int interpolationPoints, double extrapolationThreshold, AttitudeProvider attitudeProvider)```
Is not avai...Hi all,
@MaximeJ noticed that the previously available constructor :
```EphemerisPropagatorBuilder(List<SpacecraftState> states, int interpolationPoints, double extrapolationThreshold, AttitudeProvider attitudeProvider)```
Is not available anymore after the interpolation refactoring (my bad again).
Should we include a fix for this in a patch or a minor release @bryan ?
Cheers,
Vincent12.1Vincent CUCCHIETTIvincent.cucchietti@csgroup.euVincent CUCCHIETTIvincent.cucchietti@csgroup.euhttps://gitlab.orekit.org/orekit/orekit/-/issues/1313Discrepancy between ephemeride readings in Orekit and JPL Horizons2024-01-24T16:28:18ZSimonas StaseviciusDiscrepancy between ephemeride readings in Orekit and JPL HorizonsPosition and velocity of the Earth retrieved in Orekit from DE441 ephemerides does not match that of JPL Horizons exactly.
As reference, I am using the following reading of Earth's ICRF position from JPL Horizons:
> $$SOE
2460157.500...Position and velocity of the Earth retrieved in Orekit from DE441 ephemerides does not match that of JPL Horizons exactly.
As reference, I am using the following reading of Earth's ICRF position from JPL Horizons:
> $$SOE
2460157.500000000 = A.D. 2023-Aug-01 00:00:00.0000 TDB [del_T= 69.183312 s]
XYZ : 9.262412495155303E+07 -1.097336742893849E+08 -4.753366571502377E+07
2.291818900912849E+01 1.678010135905066E+01 7.273858345769444E+00
sigmas: n.a. n.a. n.a. n.a. n.a. n.a.
$$EOE
To match this, I create the Earth `CelestialBody` like so:
`JPLEphemeridesLoader earthLoader = new JPLEphemeridesLoader("lnxp1990.441", JPLEphemeridesLoader.EphemerisType.EARTH);`
`CelestialBody earth = earthLoader.loadCelestialBody("Earth");`
Then, I create an `AbsoluteDate`:
`TDBScale TDBscale = TimeScalesFactory.getTDB();`
`AbsoluteDate date = new AbsoluteDate("2023-08-01T00:00:00.000", TDBscale)`
I get the ICRF frame like this:
`CelestialBody centralBody = CelestialBodyFactory.getSolarSystemBarycenter();`
`Frame inertialFrame = centralBody.getInertiallyOrientedFrame();`
Finally, if I retrieve Earth's position at my date in the ICRF frame:
`earth.getPVCoordinates(date,inertialFrame)`
The result is this:
> {2023-07-31T23:58:50.81671611069787, P(9.262412495154932E10, -1.0973367428938684E11, -4.753366571502458E10), V(22918.189009133923, 16780.1013590413, 7273.858345764225), A(-0.0035420733727027968, 0.004120276885531439, 0.0017824598561580007)}
If you compare the positions, they differ by about 5 mm, while the velocities differ by a few nm/s. A discussion with @MaximeJ about this is [here](https://forum.orekit.org/t/earth-position-does-not-match-that-of-jpl-horizons/3211).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/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.