Orekit issueshttps://gitlab.orekit.org/orekit/orekit/-/issues2019-06-12T13:31:23Zhttps://gitlab.orekit.org/orekit/orekit/-/issues/559Marshall Solar Activity Future Estimation URL and name patterns have changed2019-06-12T13:31:23ZLuc MaisonobeMarshall Solar Activity Future Estimation URL and name patterns have changedThe NASA web site for providing MSAFE file have changed, there are three main consequence:
- the URL given in the configuration page is obsolete, it is now https://www.nasa.gov/msfcsolar/archivedforecast
- the old file names pattern...The NASA web site for providing MSAFE file have changed, there are three main consequence:
- the URL given in the configuration page is obsolete, it is now https://www.nasa.gov/msfcsolar/archivedforecast
- the old file names patterns have been changed to full lower case (Mar1999F10.txt was renamed mar1999f10.txt')
- the newer file names have a '_prd' part after the 'f10' (for example may2019f10_prd.txt)
The first change is just documentation, but the last two changes imply changing calling code (the supportedNames regexp)10.0Luc MaisonobeLuc Maisonobehttps://gitlab.orekit.org/orekit/orekit/-/issues/553AttitudeSequence bug with Ephemeris propagator2019-07-05T17:42:36ZRomaric HERAttitudeSequence bug with Ephemeris propagatorIn case of an attitude transition during an propagation with Ephemeris, a "OUT_OF_RANGE_SIMPLE" exception will be thrown.
This is due to a check in the getPVCoordinates method of Ephemeris, that will check that the current date is the s...In case of an attitude transition during an propagation with Ephemeris, a "OUT_OF_RANGE_SIMPLE" exception will be thrown.
This is due to a check in the getPVCoordinates method of Ephemeris, that will check that the current date is the same as the computed state date. In case of an attitude transition, if we try to compute the attitude during the transition period, the propagator needs the attitude at the end of this period, so this check will fail.10.0Romaric HERRomaric HERhttps://gitlab.orekit.org/orekit/orekit/-/issues/552AttitudeSequence bug when the propagation ends and restart during the transit...2019-07-05T17:42:37ZRomaric HERAttitudeSequence bug when the propagation ends and restart during the transition periodIn case of multiple uses of the propagate method with an attitude sequence, if one use of propagate method ends in the transition period an another one starts during the transition period, the attitude after the transition is not correct...In case of multiple uses of the propagate method with an attitude sequence, if one use of propagate method ends in the transition period an another one starts during the transition period, the attitude after the transition is not correct.
This is due to the fact that each use of the propagate method reset the events detector, that reset the TimeSpanMap used in the AttitudeSequence object. The reset will cause that the map that is supposed to describe the "after" attitude law is deleted by the reset, since the current date is still in the transition period. But the transition event is already in the past so the "after" attitude law will not be computed again. The attitude law is stuck in the transition phase and returns wrong values.10.0Romaric HERRomaric HERhttps://gitlab.orekit.org/orekit/orekit/-/issues/551AttitudeSequence transition not computed with analytical propagators2019-07-05T17:42:37ZRomaric HERAttitudeSequence transition not computed with analytical propagatorsIn the case of an attitude transition is triggered by an event detector during an analytical propagation, the attitude of the satellite is not correctly computed if the beginning of the propagation is before the transition and the end of...In the case of an attitude transition is triggered by an event detector during an analytical propagation, the attitude of the satellite is not correctly computed if the beginning of the propagation is before the transition and the end of the propagation is after the transition.
The origin of the bug is : the final SpacecraftState is computed before the event triggering, but the attitude transition is computed only after the events triggering. So the returned SpacecraftState is computed with the initial attitude law, not the updated one after the transition.10.0Romaric HERRomaric HERhttps://gitlab.orekit.org/orekit/orekit/-/issues/544Infinite loop on GPSPropagator and (Field)KeplerianOrbit2019-07-05T17:42:35ZBryan CazabonneInfinite loop on GPSPropagator and (Field)KeplerianOrbitA pull request has been open on the Orekit GitHub repository ([here](https://github.com/CS-SI/Orekit/pull/21#issuecomment-489652905)). It is related to an endless loop when `x.getValue()` or `x0.getValue()` is Double.NaN on GPSPropagator...A pull request has been open on the Orekit GitHub repository ([here](https://github.com/CS-SI/Orekit/pull/21#issuecomment-489652905)). It is related to an endless loop when `x.getValue()` or `x0.getValue()` is Double.NaN on GPSPropagator class. This endless loop can also occur on KeplerianOrbit and FieldKeplerianOrbit classes.10.0https://gitlab.orekit.org/orekit/orekit/-/issues/543Hang via crafted itrf-versions.conf2019-07-05T17:41:52ZEvan WardHang via crafted itrf-versions.confI was playing around with the new itrf-versions.conf and noticed that any regular expression (RE) is accepted. If the file is loaded from an un-trusted source this can hang the application because Java's REs can take exponential time to ...I was playing around with the new itrf-versions.conf and noticed that any regular expression (RE) is accepted. If the file is loaded from an un-trusted source this can hang the application because Java's REs can take exponential time to halt.[1] One one hand supplemental data should only be loaded from trusted sources to ensure the accuracy of computations. On the other hand one could argue that the effects of loading un-trusted data shouldn't be any worse than inaccurate results. So I'm not decided if it is a security issue or not. The thing that makes me nervous is that Orekit can load these files from the internet. What do you think? @luc
For example, I have a `itrf-versions.conf` file that contains:
```
f(.+)+.{40} ------ ------ ITRF-2005
```
And a EOP file named `finals2000A.0reallyloooooooooooooooooooonName`. With these settings Orekit has been hung since yesterday. It seems the file name needs to be longer than about 20 characters to cause issues.
Possible Solutions:
1. Document it and warn the user so they can take appropriate steps to only load trusted data.
2. Use a different RE implementation than Java's Matcher. It is possible to match the above RE in roughly linear time, but Java's implementation of RE is extended to include non-regular expressions such as back references which necessitates the slower algorithm.
3. Implement a watchdog, though I'm not sure if RE matching is interruptible.
4. others?
[1] https://www.owasp.org/index.php/Regular_expression_Denial_of_Service_-_ReDoS10.0Evan WardEvan Wardhttps://gitlab.orekit.org/orekit/orekit/-/issues/539Deprecated day of year computation in DTM2000 model.2019-07-05T17:42:36ZMaxime JournotDeprecated day of year computation in DTM2000 model.DTM2000 atmosphere class uses Java class GregorianCalendar in method [getDensity](https://gitlab.orekit.org/orekit/orekit/blob/develop/src/main/java/org/orekit/forces/drag/atmosphere/DTM2000.java#L333) to compute the day of year.
No Tim...DTM2000 atmosphere class uses Java class GregorianCalendar in method [getDensity](https://gitlab.orekit.org/orekit/orekit/blob/develop/src/main/java/org/orekit/forces/drag/atmosphere/DTM2000.java#L333) to compute the day of year.
No TimeZone is provided so that the default TimeZone is used. Default TimeZone depends on user's machine so it can be different than "GMT+00".
Day of year computation should not be dependent on user's default time zone.
Method [DateComponents.getDayOfYear](https://gitlab.orekit.org/orekit/orekit/blob/develop/src/main/java/org/orekit/time/DateComponents.java#L447) should be used instead (as in [NRLMSIS00.getDensity](https://gitlab.orekit.org/orekit/orekit/blob/develop/src/main/java/org/orekit/forces/drag/atmosphere/NRLMSISE00.java#L1127)).10.0https://gitlab.orekit.org/orekit/orekit/-/issues/538Problem with method ComparableMeasurement.compareTo()2019-07-05T17:42:40ZDorian GegoutProblem with method ComparableMeasurement.compareTo()It seems there is a bug the method ComparableMeasurement.compareTo() which allow violation of the transitivity rule. Further details are explained on https://forum.orekit.org/t/problem-with-method-comparablemeasurement-compareto/438It seems there is a bug the method ComparableMeasurement.compareTo() which allow violation of the transitivity rule. Further details are explained on https://forum.orekit.org/t/problem-with-method-comparablemeasurement-compareto/43810.0https://gitlab.orekit.org/orekit/orekit/-/issues/529Attitude transitions in analytical propagators2019-07-05T17:42:40ZMirco RasottoAttitude transitions in analytical propagatorsWhen trying to use the attitude sequence with an Ephemeris object, an OUT_OF_RANGE_SIMPLE exception is thrown.When trying to use the attitude sequence with an Ephemeris object, an OUT_OF_RANGE_SIMPLE exception is thrown.10.0https://gitlab.orekit.org/orekit/orekit/-/issues/528getClockCorrection from SP3File returns value in megaseconds2019-07-05T17:42:39ZGowtham SivaramangetClockCorrection from SP3File returns value in megasecondsWhen trying to load clock corrections value using `SP3Parser` from an sp3 file, the value returned by `getClockCorrection` is in megaseconds, although the document specifies seconds.
During parsing of SP3 file, `latestClock` is multipl...When trying to load clock corrections value using `SP3Parser` from an sp3 file, the value returned by `getClockCorrection` is in megaseconds, although the document specifies seconds.
During parsing of SP3 file, `latestClock` is multiplied by 1E6 instead of 1E-6. Similarly issue exists for `clockRateChange` also.10.0https://gitlab.orekit.org/orekit/orekit/-/issues/514Deprecate then delete unused DerivativeStructure acceleration computation met...2019-07-05T17:41:52ZMaxime JournotDeprecate then delete unused DerivativeStructure acceleration computation methodsSome methods computing `FieldVector3D<DerivativeStructure>` acceleration and using a parameter name as input should have been deleted in version 9.0 but were left over.
They should be deemed `@Deprecated` in version 9.3 and then deleted ...Some methods computing `FieldVector3D<DerivativeStructure>` acceleration and using a parameter name as input should have been deleted in version 9.0 but were left over.
They should be deemed `@Deprecated` in version 9.3 and then deleted in version 10.0.
These methods are:
- `FieldVector3D<DerivativeStructure> dragAcceleration` in interface [DragSensitive](https://gitlab.orekit.org/orekit/orekit/blob/develop/src/main/java/org/orekit/forces/drag/DragSensitive.java#L117) and all its implementations;
- `FieldVector3D<DerivativeStructure> radiationPressureAcceleration` in [RadiationSensitive](https://gitlab.orekit.org/orekit/orekit/blob/develop/src/main/java/org/orekit/forces/radiation/RadiationSensitive.java#L90) and all its implementations
Related tests should also be deprecated then deleted.10.0https://gitlab.orekit.org/orekit/orekit/-/issues/389Change type parameter of AbstractDetector to T extends AbstractDetector<T>2019-07-05T17:41:54ZEvan WardChange type parameter of AbstractDetector to T extends AbstractDetector<T>If the user knows they have an AbstractDetector, they should be able to
call the withXxx methods any number of times.
Currently the following fails to compile because the type returned by
the withXxx() methods is an EventDetector
\`\`...If the user knows they have an AbstractDetector, they should be able to
call the withXxx methods any number of times.
Currently the following fails to compile because the type returned by
the withXxx() methods is an EventDetector
\`\`\`
AbstractDetector<?>d = ...;
d.withMaxIter(9).withMaxIter(9);
\`\`\`
To call the with methods multiple times you have replace \`?\` with \`?
extends AbstractDetector<?>\` once for each time you plan to call
a with method. Clearly this does not scale well and is bad API design.
Changing the declaration of AbstractDetector to
\`AbstractDetector<T extends AbstractDetector<T>>\` would solve the
issue and allow the earlier example to compile.
This change is backwards incompatible, so I'm making a note of it here
util we are ready to include it.
*(from redmine: issue id 389, created on 2018-03-07)*10.0