Orekit issueshttps://gitlab.orekit.org/orekit/orekit/-/issues2023-11-08T10:18:37Zhttps://gitlab.orekit.org/orekit/orekit/-/issues/1263Remove support for Ant2023-11-08T10:18:37ZBryan CazabonneRemove support for AntMore details in: https://forum.orekit.org/t/removing-support-for-ant/3008/3
Removing support consists in:
- Removing build.xml file
- Removing update of build.xml in release guide task 5
- Removing all occurrences to Ant support in the ...More details in: https://forum.orekit.org/t/removing-support-for-ant/3008/3
Removing support consists in:
- Removing build.xml file
- Removing update of build.xml in release guide task 5
- Removing all occurrences to Ant support in the documentation12.1https://gitlab.orekit.org/orekit/orekit/-/issues/1262Comments in parsed CCSDS file cannot be updated2024-01-16T12:52:09ZDavid GondelachComments in parsed CCSDS file cannot be updatedHi all,
I tried to parse a message that contains comments, e.g. CDM or OEM, and then change or remove some comments before writing it to a file again. However, I was not able to do this. It looks like the comments are stored in a Commen...Hi all,
I tried to parse a message that contains comments, e.g. CDM or OEM, and then change or remove some comments before writing it to a file again. However, I was not able to do this. It looks like the comments are stored in a CommentsContainer and only accessible as a read-only list (Collections.unmodifiableList), hence not modifiable.
The easiest fixes would be to have `CommentsContainer.getComments` return a modifiable List or to add a setter for the List `comments`. I can implement such a change if there are no objections, but maybe you have better ideas!
https://gitlab.orekit.org/orekit/orekit/-/blob/develop/src/main/java/org/orekit/files/ccsds/section/CommentsContainer.java
Best,
DavidDavid GondelachDavid Gondelachhttps://gitlab.orekit.org/orekit/orekit/-/issues/1261Javadoc still refers to old name of yields2023-12-30T11:43:37ZRomain SerraJavadoc still refers to old name of yieldsFor (Field) AdditionalStateProvider as well as AdditionalDerivativesProvider, some Javadoc still references the old name of method `yields` that used to be called `yield`For (Field) AdditionalStateProvider as well as AdditionalDerivativesProvider, some Javadoc still references the old name of method `yields` that used to be called `yield`12.0.1Tanner MillsTanner Millshttps://gitlab.orekit.org/orekit/orekit/-/issues/1260Use new method square for FieldElement2023-12-19T19:41:16ZRomain SerraUse new method square for FieldElementHipparchus 3.1's snapshot has a new method for x^2 with `FieldElement`, with some performance increase depending on the inheritorHipparchus 3.1's snapshot has a new method for x^2 with `FieldElement`, with some performance increase depending on the inheritor12.1Romain SerraRomain Serrahttps://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/1257Update translations for the next release2023-11-03T10:31:15ZBryan CazabonneUpdate translations for the next releaseUpdating translations is a step that we usually forget to do before releasing a new Orekit version.
The purpose of this issue is to think about this important step.Updating translations is a step that we usually forget to do before releasing a new Orekit version.
The purpose of this issue is to think about this important step.12.1https://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/1255Add Field version of Gauss IOD2023-10-31T21:05:42ZRomain SerraAdd Field version of Gauss IODSimilar to #1027, but Gauss is different as there is no Field implementation of Laguerre solver in Hipparchus, hence it is dependent on a [contribution](https://github.com/Hipparchus-Math/hipparchus/issues/265) thereSimilar to #1027, but Gauss is different as there is no Field implementation of Laguerre solver in Hipparchus, hence it is dependent on a [contribution](https://github.com/Hipparchus-Math/hipparchus/issues/265) therehttps://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/1244Add abstract classes for (Field) Detectors related to topocentric and geocent...2023-10-25T19:02:26ZRomain SerraAdd abstract classes for (Field) Detectors related to topocentric and geocentric quantitiesThere is code duplications between detectors for elevation and longitude/latitude events for exampleThere is code duplications between detectors for elevation and longitude/latitude events for example