Orekit issueshttps://gitlab.orekit.org/orekit/orekit/-/issues2024-03-19T16:14:54Zhttps://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/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/1308Overload getPosition in (Field) TlePropagator2024-02-28T07:17:11ZRomain SerraOverload getPosition in (Field) TlePropagatorThe part computing velocity could be ignored for speedThe part computing velocity could be ignored for speedhttps://gitlab.orekit.org/orekit/orekit/-/issues/1305Estimate Measurement Parameters in the Unscented Kalman Model2024-01-19T17:35:19ZDiego Iván Tirado HernándezEstimate Measurement Parameters in the Unscented Kalman ModelProblem in the UKF estimation without orbital and propagation parameters.
Description of the problem in: https://forum.orekit.org/t/estimate-measurement-parameters-in-the-unscented-kalman-model/3196/4Problem in the UKF estimation without orbital and propagation parameters.
Description of the problem in: https://forum.orekit.org/t/estimate-measurement-parameters-in-the-unscented-kalman-model/3196/4https://gitlab.orekit.org/orekit/orekit/-/issues/1303Feature request: implement STKEphemerisFile writer2024-01-16T09:42:31ZqmorFeature request: implement STKEphemerisFile writerPlease see https://forum.orekit.org/t/stkephemerisfile-writer/3192/1Please see https://forum.orekit.org/t/stkephemerisfile-writer/3192/1https://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/1297Can't truncate to CCSDS ODM-specified digits2024-01-16T12:51:29ZBrad KellyCan't truncate to CCSDS ODM-specified digitsOrekit writers are not currently compliant to https://public.ccsds.org/Pubs/502x0b3e1.pdf section 7.5.6 and 7.5.7, but outputting full double precision, per https://forum.orekit.org/t/odm-output-precision-control/3173.Orekit writers are not currently compliant to https://public.ccsds.org/Pubs/502x0b3e1.pdf section 7.5.6 and 7.5.7, but outputting full double precision, per https://forum.orekit.org/t/odm-output-precision-control/3173.https://gitlab.orekit.org/orekit/orekit/-/issues/1292Computations not used in (Field)BrouwerLyddanePropagator2024-02-23T09:57:41ZRomain SerraComputations not used in (Field)BrouwerLyddanePropagatorIn method `propagateParameters` which returns a `KeplerianOrbit`, `(Field)UnivariateDerivative2` are used, yet at the end there is no call to `getSecondDerivative`, so some computations are basically lost. It should probably leverage `ta...In method `propagateParameters` which returns a `KeplerianOrbit`, `(Field)UnivariateDerivative2` are used, yet at the end there is no call to `getSecondDerivative`, so some computations are basically lost. It should probably leverage `taylor` or use no `Derivative` at all.https://gitlab.orekit.org/orekit/orekit/-/issues/1291Comment discrepancy in Brouwer Lyddane2024-02-21T16:50:08ZRomain SerraComment discrepancy in Brouwer LyddaneIn method propagateParameters of `(Field)BrouwerLyddanePropagator`, an angle "l" is said as being the true anomaly, yet it is passed to constructor of `KeplerianOrbit `as the mean.
Phipps thesis, on which the implementation is based, ref...In method propagateParameters of `(Field)BrouwerLyddanePropagator`, an angle "l" is said as being the true anomaly, yet it is passed to constructor of `KeplerianOrbit `as the mean.
Phipps thesis, on which the implementation is based, refers to "l" as a mean anomaly, so it's a misleading comment, also present in tests.https://gitlab.orekit.org/orekit/orekit/-/issues/1290Signature discrepancy between double and Field methods in AberrationModifier2023-12-31T08:48:08ZRomain SerraSignature discrepancy between double and Field methods in AberrationModifierProblem concerns natural-to-proper conversions. A common "signature" should be agreed upon and the other one deprecated.Problem concerns natural-to-proper conversions. A common "signature" should be agreed upon and the other one deprecated.https://gitlab.orekit.org/orekit/orekit/-/issues/1289StepHandler and EventHandler callbacks order2023-12-30T08:30:43ZMirco RasottoStepHandler and EventHandler callbacks orderHi,
This issue is related to [this discussion](https://forum.orekit.org/t/stephandler-and-eventhandler-callbacks-order/3103) on the forum.
Thanks,
MircoHi,
This issue is related to [this discussion](https://forum.orekit.org/t/stephandler-and-eventhandler-callbacks-order/3103) on the forum.
Thanks,
Mircohttps://gitlab.orekit.org/orekit/orekit/-/issues/1284Wrong comment in measurement code2023-12-30T08:21:51ZBryan CazabonneWrong comment in measurement codeThe following code is taken from AngularAzEL
```java
// Partial derivatives of azimuth/elevation with respect to state
// (beware element at index 0 is the value, not a derivative)
final double[] azDerivatives = azimuth...The following code is taken from AngularAzEL
```java
// Partial derivatives of azimuth/elevation with respect to state
// (beware element at index 0 is the value, not a derivative)
final double[] azDerivatives = azimuth.getGradient();
final double[] elDerivatives = elevation.getGradient();
estimated.setStateDerivatives(0,
Arrays.copyOfRange(azDerivatives, 0, 6), Arrays.copyOfRange(elDerivatives, 0, 6));
```
The comment is correct for DerivativeStructure, not Gradient.
When perfoming the switch, some comments were forgotten.https://gitlab.orekit.org/orekit/orekit/-/issues/1282LOFType.EQW frame: mismatch between Javadoc and code?2024-01-19T07:53:09ZClément JonglezLOFType.EQW frame: mismatch between Javadoc and code?In `src/main/java/org/orekit/frames/LOFType.java:568`, the Javadoc says that the Z axis of the EQW frame is aligned with orbital momentum, but in the code it looks like it's rather the Y axis:
```
public Rotation rotationFromIne...In `src/main/java/org/orekit/frames/LOFType.java:568`, the Javadoc says that the Z axis of the EQW frame is aligned with orbital momentum, but in the code it looks like it's rather the Y axis:
```
public Rotation rotationFromInertial(final PVCoordinates pv) {
final Vector3D m = pv.getMomentum();
return new Rotation(new Vector3D(-m.getY(), m.getX(), 0), m,
Vector3D.PLUS_I, Vector3D.PLUS_J);
}
```Vincent CUCCHIETTIvincent.cucchietti@csgroup.euVincent CUCCHIETTIvincent.cucchietti@csgroup.euhttps://gitlab.orekit.org/orekit/orekit/-/issues/1279Orekit DSST bug in adding DDSTTesseral force model2023-11-28T22:18:08ZBryan PrestOrekit DSST bug in adding DDSTTesseral force modelIssue from forum discussion: https://forum.orekit.org/t/dsst-earth-gravity-field-addition/3053/7
No initialization of resonant terms (contribution equal to 0.0) when trying to use DSST propagator adding DSSTTesseral force model.
Initial ...Issue from forum discussion: https://forum.orekit.org/t/dsst-earth-gravity-field-addition/3053/7
No initialization of resonant terms (contribution equal to 0.0) when trying to use DSST propagator adding DSSTTesseral force model.
Initial state is set as MEAN, and the initial orbital elements are:
Mean elements:
a=7070966.981581845
e=0.0010432729458547982
i=98.15892489558152
pa=90.0
raan=287.4746
Ma=271.1660https://gitlab.orekit.org/orekit/orekit/-/issues/1274Use of Tide class in OceanTidesWaves2023-12-30T08:32:54ZGaëtan PierreUse of Tide class in OceanTidesWavesReplace `doodson`, `cGamma`, `cL`, `cLPrime`, `cF`, `cD`, `cOmega `by a `Tide`. In `addContribution`, replace `thetaF` computation by `getPhase` method.Replace `doodson`, `cGamma`, `cL`, `cLPrime`, `cF`, `cD`, `cOmega `by a `Tide`. In `addContribution`, replace `thetaF` computation by `getPhase` method.https://gitlab.orekit.org/orekit/orekit/-/issues/1272add converters AbsoluteDate from/to Instant2024-01-16T12:56:46ZSabrina Sarraadd converters AbsoluteDate from/to InstantIt would be useful to add methods to convert AbsoluteDate from/to Java Instant.
https://forum.orekit.org/t/absolutedate-to-java-instant/3090It would be useful to add methods to convert AbsoluteDate from/to Java Instant.
https://forum.orekit.org/t/absolutedate-to-java-instant/309012.1Christopher SchankChristopher Schankhttps://gitlab.orekit.org/orekit/orekit/-/issues/1270Renaming in (Field) Propagator2023-11-16T07:43:09ZRomain SerraRenaming in (Field) Propagator`Propagator` has a `getEventsDetectors` method, which is not coherent with `getEventDetectors` in `EventDetectorProvider` (no S in the middle) and should thus be renamed.
Check Field version as well.`Propagator` has a `getEventsDetectors` method, which is not coherent with `getEventDetectors` in `EventDetectorProvider` (no S in the middle) and should thus be renamed.
Check Field version as well.https://gitlab.orekit.org/orekit/orekit/-/issues/1268Add Herrick-Gibbs IOD method2023-11-13T13:55:03ZRomain SerraAdd Herrick-Gibbs IOD methodGibbs' method suitability for closely spaced positions is limited. There's an alternative for that case, referred to as Herrick-Gibbs in Vallado's book (page 466 in 4th edition)Gibbs' method suitability for closely spaced positions is limited. There's an alternative for that case, referred to as Herrick-Gibbs in Vallado's book (page 466 in 4th edition)https://gitlab.orekit.org/orekit/orekit/-/issues/1267Mixed up Javadoc for Orbit.getEquinoctialEx, getEquinoctialExDot, getEquinoct...2023-12-30T08:27:21ZClément JonglezMixed up Javadoc for Orbit.getEquinoctialEx, getEquinoctialExDot, getEquinoctialEy, getEquinoctialEyDotThe javadoc for the Orbit's `getEquinoctialEx` method for instance says the following, whereas this should rather apply to the `getEquinoctialExDot` method:
```
/** Get the first component of the equinoctial eccentricity vector deriv...The javadoc for the Orbit's `getEquinoctialEx` method for instance says the following, whereas this should rather apply to the `getEquinoctialExDot` method:
```
/** Get the first component of the equinoctial eccentricity vector derivative.
* @return first component of the equinoctial eccentricity vector derivative
*/
```
On the other hand, the first and fifth lines of `getEquinoctialExDot`'s method description rather belong to `getEquinoctialEx`:
```
/** Get the first component of the equinoctial eccentricity vector.
* <p>
* If the orbit was created without derivatives, the value returned is {@link Double#NaN}.
* </p>
* @return first component of the equinoctial eccentricity vector
* @see #hasDerivatives()
* @since 9.0
*/
```
The same apply for `getEquinoctialEy` vs `getEquinoctialEyDot`.
https://www.orekit.org/static/apidocs/org/orekit/orbits/Orbit.html#getEquinoctialEx--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 patch