Orekit issueshttps://gitlab.orekit.org/orekit/orekit/-/issues2024-01-30T22:20:51Zhttps://gitlab.orekit.org/orekit/orekit/-/issues/1259Add so-called (Field) kinematic transform2024-01-30T22:20:51ZRomain SerraAdd so-called (Field) kinematic transformThe idea is similar to `StaticTransform`, but for position and velocity stuff, without acceleration. It could then be used for example in atmospheric velocity within drag force.
See original idea of @evanward1 [there](https://forum.orek...The idea is similar to `StaticTransform`, but for position and velocity stuff, without acceleration. It could then be used for example in atmospheric velocity within drag force.
See original idea of @evanward1 [there](https://forum.orekit.org/t/improve-performance-of-transform/844)12.1Romain SerraRomain Serrahttps://gitlab.orekit.org/orekit/orekit/-/issues/1258Add getter for C20 in spherical harmonics provider2024-03-06T22:54:47ZRomain SerraAdd getter for C20 in spherical harmonics providerThe new method would be `get{Un}normalizedC20(date)` and would wrap `onDate(original.getDate()).get{Un}normalizedCnm(2,0)`.The new method would be `get{Un}normalizedC20(date)` and would wrap `onDate(original.getDate()).get{Un}normalizedCnm(2,0)`.12.1Romain SerraRomain Serrahttps://gitlab.orekit.org/orekit/orekit/-/issues/1256Concurrency in LazyLoadedTimeScales2023-11-02T20:20:57ZLuc MaisonobeConcurrency in LazyLoadedTimeScalesThe `LazyLoadedTimeScales` uses synchronization to retrieve the time scales that are built lazily.
This creates congestion in heavily multi-threaded contexts, as described in [this forum discussion](https://forum.orekit.org/t/concurrency...The `LazyLoadedTimeScales` uses synchronization to retrieve the time scales that are built lazily.
This creates congestion in heavily multi-threaded contexts, as described in [this forum discussion](https://forum.orekit.org/t/concurrency-in-lazyloadedtimescales/3024/).12.0Luc MaisonobeLuc Maisonobehttps://gitlab.orekit.org/orekit/orekit/-/issues/1254Wrong behavior of method "propagate(tStart, tEnd)" when used with "setResetAt...2023-12-30T11:44:16ZChristophe Le BrisWrong behavior of method "propagate(tStart, tEnd)" when used with "setResetAtEnd(false)"When setResetAtEnd is called with false, the initial state of the propagation remains unchanged after the propagation.
When `propagate(tStart, tEnd)` is called and tStart is different from the epoch of the initial state, a first integrat...When setResetAtEnd is called with false, the initial state of the propagation remains unchanged after the propagation.
When `propagate(tStart, tEnd)` is called and tStart is different from the epoch of the initial state, a first integration is done. But neither the event detectors nor the ephemeris generator are set up yet during this integration.
If `resetAtEnd=false`, the initial state is unchanged for the second propagation so this first propagation is lost.
Then, in a second time, the dynamics is integrated from initial state date to tEnd, with event detectors and ephemeris generators activated.
So technically, if `resetAtEnd=false` then the result of:
`propagate(tStart, tEnd)`
seems strictly equivalent to:
`propagate(tEnd)`
[TestEphemeris.java](/uploads/dbe047caa6538daf8c11bbd91908794f/TestEphemeris.java)12.0.1Maxime JournotMaxime Journothttps://gitlab.orekit.org/orekit/orekit/-/issues/1253Incorrect propagation of covariance with a "BoundedPropagator"2023-12-30T11:44:48ZChristophe Le BrisIncorrect propagation of covariance with a "BoundedPropagator"The propagation of the covariance extracted from the ephemeris provided by a BoundedPropagator is incorrect.
```
MatricesHarvester harvester = propagator.setupMatricesComputation("stm", null, null);
StateCovarianceMatrixProvider...The propagation of the covariance extracted from the ephemeris provided by a BoundedPropagator is incorrect.
```
MatricesHarvester harvester = propagator.setupMatricesComputation("stm", null, null);
StateCovarianceMatrixProvider covarianceProvider =
new StateCovarianceMatrixProvider("cov", "stm", harvester, covariance);
propagator.addAdditionalStateProvider(covarianceProvider);
EphemerisGenerator generator = propagator.getEphemerisGenerator();
propagator.propagate(startDate, targetDate);
BoundedPropagator ephemeris = generator.getGeneratedEphemeris();
```
Later, when a call is made to get the covariance from the BoundedPropagator with:
```
finalState = ephemeris.propagate(t);
StateCovariance finalCovariance = covarianceProvider.getStateCovariance(finalState);
```
The finalCovariance is incorrect and different from the value obtained by a direct propagation.12.0.1Maxime JournotMaxime Journothttps://gitlab.orekit.org/orekit/orekit/-/issues/1252org.orekit.time.UTCScaleTest fails building on Apple Silicon w/JDK 172023-11-03T08:23:33ZHank Grabowskiorg.orekit.time.UTCScaleTest fails building on Apple Silicon w/JDK 17I'm trying to do the full `mvn clean test` build on Apple Silicon running OpenJDK 17. This test fails with a potential out of memory bug even when I have MVN_OPTS set as high as `-Xmx16G -Xms16G` (the physical RAM of the system). The sam...I'm trying to do the full `mvn clean test` build on Apple Silicon running OpenJDK 17. This test fails with a potential out of memory bug even when I have MVN_OPTS set as high as `-Xmx16G -Xms16G` (the physical RAM of the system). The same build on ARM64 Ubuntu Linux running OpenJDK 17 with just 4 GB of physical RAM succeeds without problems. If I run the test individually then it does not have this problem. For other build reasons the last build configuration issues I can successfully get going is the one for the 11.3.3. I've attached the error output from the Maven run and the dump file that it references: [ErrorOutput.txt](/uploads/95fd3cb2569bef3fe0b337c6c7e8db3c/ErrorOutput.txt)[dump.txt](/uploads/f70b16ee265c1112954eb4bae23ed5a3/dump.txt)
This was for the 12.0 RC 1 as well as the head of the develop branch.12.0Hank GrabowskiHank Grabowskihttps://gitlab.orekit.org/orekit/orekit/-/issues/1251Add missing new contributors2023-11-02T20:41:35ZMaxime JournotAdd missing new contributorsSome contributors of 12.0 were not added to the pom.xml file and their contributions not added to changes.xml.
Here is a (potentially not exhaustive) list:
- [Rongwang Li](https://gitlab.orekit.org/orekit/orekit/-/merge_requests/306)
- ...Some contributors of 12.0 were not added to the pom.xml file and their contributions not added to changes.xml.
Here is a (potentially not exhaustive) list:
- [Rongwang Li](https://gitlab.orekit.org/orekit/orekit/-/merge_requests/306)
- [Theo Nguyen](https://gitlab.orekit.org/orekit/orekit/-/merge_requests/414)
- [Julien Asquier](https://gitlab.orekit.org/orekit/orekit/-/merge_requests/357)12.0Bryan CazabonneBryan Cazabonnehttps://gitlab.orekit.org/orekit/orekit/-/issues/1250Optimization of the load induced by the CI/CD pipeline2023-11-02T20:18:33ZSébastien Dinotsebastien.dinot@csgroup.euOptimization of the load induced by the CI/CD pipelineThe Maven [continuous-integration](pom.xml#L1104) profile applied in the CI/CD pipeline attempts to parallelize test execution as much as possible by instantiating one JVM per CPU thread:
```xml
<forkCount>1C</forkCount>
```
As Orekit ...The Maven [continuous-integration](pom.xml#L1104) profile applied in the CI/CD pipeline attempts to parallelize test execution as much as possible by instantiating one JVM per CPU thread:
```xml
<forkCount>1C</forkCount>
```
As Orekit performs intensive mathematical calculations, this results in unnecessary load and sub-optimal performance on most modern processors, designed on multi-threaded architectures. This is because all threads on the same core share the same floating-point computing units. If all threads try to use these units at the same time, a race condition arises, which degrades performance.
It's best to bet on the processor having two threads per core (the most common design) and to limit the number of forks to the number of cores (not the number of threads):
```xml
<forkCount>0.5C</forkCount>
```
I ran tests with this configuration on two processors (Intel Core i5-8259U 4c/8t and Intel Core i7-7700HQ 4c/8t). Processor load is logically divided by 2, the pipeline consumes less RAM and execution time is improved by 5 to 9%.https://gitlab.orekit.org/orekit/orekit/-/issues/1249Duplicated code in (Field) abstract propagators2024-01-13T14:02:52ZRomain SerraDuplicated code in (Field) abstract propagatorsThe duplicated code is `propagate(date). getPVCoordinates(frame)` for `getPVCoordinates(date, frame)`
It is the case at least for `AbstractAnalyticalPropagator`, `IntegratedEphemeris` and Numerical propagator (plus `Field` equivalent).The duplicated code is `propagate(date). getPVCoordinates(frame)` for `getPVCoordinates(date, frame)`
It is the case at least for `AbstractAnalyticalPropagator`, `IntegratedEphemeris` and Numerical propagator (plus `Field` equivalent).12.1Romain SerraRomain Serrahttps://gitlab.orekit.org/orekit/orekit/-/issues/1248Unused parameters in private methods compute* in DSSTZonal2024-03-28T06:39:30ZRomain SerraUnused parameters in private methods compute* in DSSTZonalUnused argument is of type (Field)AbsoluteDateUnused argument is of type (Field)AbsoluteDate12.1Bryan CazabonneBryan Cazabonnehttps://gitlab.orekit.org/orekit/orekit/-/issues/1247Add toStaticTransform in (Field)SpacecraftState2023-10-26T21:53:48ZRomain SerraAdd toStaticTransform in (Field)SpacecraftStateThe new method could then be used for performance in `FieldOfView`, wind-up stuff and some measurement modifiers.The new method could then be used for performance in `FieldOfView`, wind-up stuff and some measurement modifiers.12.0Romain SerraRomain Serrahttps://gitlab.orekit.org/orekit/orekit/-/issues/1246Global Ionosphe Model should be loadable from DataSource2023-11-08T20:28:09ZLuc MaisonobeGlobal Ionosphe Model should be loadable from DataSourceIt should be possible to use a list of explicit `DataSource` instance to load IONEX files for Global Ionosphere Model.It should be possible to use a list of explicit `DataSource` instance to load IONEX files for Global Ionosphere Model.12.0Luc MaisonobeLuc Maisonobehttps://gitlab.orekit.org/orekit/orekit/-/issues/1245Add individual computation methods for (Field) TrackingCoordinates in Topocen...2023-10-26T15:49:10ZRomain SerraAdd individual computation methods for (Field) TrackingCoordinates in TopocentricFrameThe recent addition of `(Field)TrackingCoordinates` avoids redundant computations when several quantities are needed e.g. elevation and azimuth. However when only one is needed, some performance is lost if all quantities are computed any...The recent addition of `(Field)TrackingCoordinates` avoids redundant computations when several quantities are needed e.g. elevation and azimuth. However when only one is needed, some performance is lost if all quantities are computed anyway in the process, as is now the case in `TopocentricFrame`. With `Field` in particular, this is detrimental as `atan2` is a bit slow.
So here is what I propose:
- put back methods `getElevation`, `getAzimuth`, etc., bypassing `getTrackingCoordinates`
- in order to avoid code duplication, introduce a private, intermediate method doing computations until the `transformPosition` basically. Also one for the azimuth rephasing.12.0Romain SerraRomain Serrahttps://gitlab.orekit.org/orekit/orekit/-/issues/1242Unused public static attributes in DTM20002023-10-28T12:57:07ZRomain SerraUnused public static attributes in DTM2000There are unused static integers e.g. HYDROGENThere are unused static integers e.g. HYDROGENRomain SerraRomain Serrahttps://gitlab.orekit.org/orekit/orekit/-/issues/1240Add toStaticTransform to (Field)Transform2023-10-26T15:49:18ZRomain SerraAdd toStaticTransform to (Field)TransformSometimes transformations in both ways are needed, but one of them might only need `transformPosition`, thus it'd be better for performance to extract a `(Field)StaticTransform` before computing the inverseSometimes transformations in both ways are needed, but one of them might only need `transformPosition`, thus it'd be better for performance to extract a `(Field)StaticTransform` before computing the inverse12.0Romain SerraRomain Serrahttps://gitlab.orekit.org/orekit/orekit/-/issues/1239Add derivatives to EOP when they are missing in the files2023-10-23T11:54:11ZLuc MaisonobeAdd derivatives to EOP when they are missing in the filesTwo sets of EOP data have derivatives: polhody (xp, yp, as derivatives will be added in early November 2023 by IERS in several products and are already present in EOP C04 since February 2023) and dUT1 (because LOD is linked to dUT1 deriv...Two sets of EOP data have derivatives: polhody (xp, yp, as derivatives will be added in early November 2023 by IERS in several products and are already present in EOP C04 since February 2023) and dUT1 (because LOD is linked to dUT1 derivative).
In some cases, the derivatives are present in the files Orekit loads, in some cases they are missing.
If for example one loads EOP C04 data from before Febrary 2023 and data after November 2023, the polhody data will be inconsistent.
Bulletin A also miss LOD data. In the regular txt version of the files, this is taken care of during parsing, and some finite difference algorithm is used to add the missing data. This is not done in the xml or csv versions of the file.
It would be better and more consistent to add missing derivatives to points that miss them during loading, as a post-processing step before the EOP history is returned. This way, all data will always have all derivatives and interpolation will be more consistent. This is a follow-up of issue #1238 as it will permit proper Hermite interpolation throughout history for these parameters.12.0Luc MaisonobeLuc Maisonobehttps://gitlab.orekit.org/orekit/orekit/-/issues/1238Allow customization of interpolation degree in EOP2023-10-22T19:02:08ZLuc MaisonobeAllow customization of interpolation degree in EOPEOP interpolation uses a fixed number of points for interpolation, and this number of points is the same for data that has no derivatives and uses Lagrange (like dx and dy) and for data that does have derivatives and uses Hermite (like x...EOP interpolation uses a fixed number of points for interpolation, and this number of points is the same for data that has no derivatives and uses Lagrange (like dx and dy) and for data that does have derivatives and uses Hermite (like xp, yp). Also UTA/LOD should use derivatives since LOD is basically the opposite of UT1 derivatives (scaled to one day).
It would be better for users and more consistent between parameters to set up an interpolation degree, with some default.
As some parameters use Hermite with first derivatives and for symmetry reason we want an even number of points, the degree should have the form 4k-1, typically 3 (4 points without derivatives, 2 points with derivatives) or 7 (8 points without derivatives, 4 points with derivatives).12.0Luc MaisonobeLuc Maisonobehttps://gitlab.orekit.org/orekit/orekit/-/issues/1235Checkstyle shall be verified before unit tests2023-10-18T16:53:33ZBryan CazabonneCheckstyle shall be verified before unit testsCurrently checkstyle is verified after unit tests. However, performing tests takes about 20 minutes. As a results, it is better to perform checkstyle verification before unit tests to reduce duration of possible fail pipelinesCurrently checkstyle is verified after unit tests. However, performing tests takes about 20 minutes. As a results, it is better to perform checkstyle verification before unit tests to reduce duration of possible fail pipelineshttps://gitlab.orekit.org/orekit/orekit/-/issues/1234Fix on typo on getReflection for Panel2023-10-18T16:35:59ZAlberto FerreroFix on typo on getReflection for PanelJust a small bug on getReflection() method for `Panel`Just a small bug on getReflection() method for `Panel`12.0https://gitlab.orekit.org/orekit/orekit/-/issues/1233Small fix on missing protected InterSatDirectViewDetector constructor2023-10-18T21:24:32ZAlberto FerreroSmall fix on missing protected InterSatDirectViewDetector constructorSmall fix, as Detector constructor were made `private`. (from https://gitlab.orekit.org/orekit/orekit/-/issues/1143)
Missing `InterSatDirectViewDetector`Small fix, as Detector constructor were made `private`. (from https://gitlab.orekit.org/orekit/orekit/-/issues/1143)
Missing `InterSatDirectViewDetector`12.0