Orekit issueshttps://gitlab.orekit.org/orekit/orekit/-/issues2023-10-23T13:16:59Zhttps://gitlab.orekit.org/orekit/orekit/-/issues/1173Wrong uses of non-fielded AbsoluteDate for some transformations in Atmosphere...2023-10-23T13:16:59ZRomain SerraWrong uses of non-fielded AbsoluteDate for some transformations in Atmosphere and FieldElevationDetectorSimilar to #1170
Basically, (Static)Transform and other methods should be built with a `FieldAbsoluteDate`, so `toAbsoluteDate` should not be called beforehand.
Problem present at least in `getVelocity` of Interface `Atmosphere` and ...Similar to #1170
Basically, (Static)Transform and other methods should be built with a `FieldAbsoluteDate`, so `toAbsoluteDate` should not be called beforehand.
Problem present at least in `getVelocity` of Interface `Atmosphere` and `FieldElevationDetector`.
It might decrease performance a bit but the current implementation is not rigorous.12.0Romain SerraRomain Serrahttps://gitlab.orekit.org/orekit/orekit/-/issues/1172Make name available about ODE integrator in propagator2023-10-26T15:52:03ZRomain SerraMake name available about ODE integrator in propagator`AbstractIntegratedPropagator` should have ways to retrieve information on the underlying integrator from Hipparchus`AbstractIntegratedPropagator` should have ways to retrieve information on the underlying integrator from Hipparchus12.0Romain SerraRomain Serrahttps://gitlab.orekit.org/orekit/orekit/-/issues/1171Add possibility to compute position only for Chebyshev polynomials with JPL e...2023-08-31T19:14:46ZRomain SerraAdd possibility to compute position only for Chebyshev polynomials with JPL ephemeridesVelocity and acceleration vectors are systematically computed in `RawPV`, they could be skipped when calling `getPosition` in JPL bodies. This would be faster, particularly with `Field`
Follows up #1151Velocity and acceleration vectors are systematically computed in `RawPV`, they could be skipped when calling `getPosition` in JPL bodies. This would be faster, particularly with `Field`
Follows up #115112.0Romain SerraRomain Serrahttps://gitlab.orekit.org/orekit/orekit/-/issues/1170Wrong calls in case of Field with some gravitational force models2023-08-31T18:52:09ZRomain SerraWrong calls in case of Field with some gravitational force modelsIn method `acceleration`, `toAbsoluteDate` is erroneously used before calling `getStaticTransform` or `getPosition` in:
- HolmesFeatherStoneAttractionModel
- ThirdBodyAttraction
- SingleBodyAbsoluteAttraction
Basically this means that t...In method `acceleration`, `toAbsoluteDate` is erroneously used before calling `getStaticTransform` or `getPosition` in:
- HolmesFeatherStoneAttractionModel
- ThirdBodyAttraction
- SingleBodyAbsoluteAttraction
Basically this means that the dependence w.r.t. epoch is ignored.
This will decrease performance but the hack introduced in !386 softens the blow12.0Romain SerraRomain Serrahttps://gitlab.orekit.org/orekit/orekit/-/issues/1169MarshallSolarActivityFutureEstimation should follow the architecture of CssiS...2023-09-22T11:57:52ZVincent CUCCHIETTIvincent.cucchietti@csgroup.euMarshallSolarActivityFutureEstimation should follow the architecture of CssiSpaceWeatherDataHi everyone,
While working on #1072 (fix is on its way btw, tested and validated for ```CssiSpaceWeatherData```), i noticed that the ```MarshallSolarActivityFutureEstimation``` class is quite a mess. I'll use this opportunity to refacto...Hi everyone,
While working on #1072 (fix is on its way btw, tested and validated for ```CssiSpaceWeatherData```), i noticed that the ```MarshallSolarActivityFutureEstimation``` class is quite a mess. I'll use this opportunity to refactor it the same way ```CssiSpaceWeatherData``` is done.
Cheers,
Vincent12.0Vincent CUCCHIETTIvincent.cucchietti@csgroup.euVincent CUCCHIETTIvincent.cucchietti@csgroup.euhttps://gitlab.orekit.org/orekit/orekit/-/issues/1168Marshall Solar Activity website link is down in MarshallSolarActivityFutureEs...2023-09-26T09:58:42ZVincent CUCCHIETTIvincent.cucchietti@csgroup.euMarshall Solar Activity website link is down in MarshallSolarActivityFutureEstimationHi everyone,
I noticed that the link in the ```MarshallSolarActivityFutureEstimation``` class leading to the Marshall Solar Activity website is down.
Cheers,
VincentHi everyone,
I noticed that the link in the ```MarshallSolarActivityFutureEstimation``` class leading to the Marshall Solar Activity website is down.
Cheers,
Vincent12.0Vincent CUCCHIETTIvincent.cucchietti@csgroup.euVincent CUCCHIETTIvincent.cucchietti@csgroup.euhttps://gitlab.orekit.org/orekit/orekit/-/issues/1167Refactoring ForceModel and DSSTForceModel2023-10-26T15:52:16ZMaxime JournotRefactoring ForceModel and DSSTForceModelFollowing this [forum thread](https://forum.orekit.org/t/common-interface-for-forcemodel-and-dsstforcemodel/2763), `ForceModel` and `DSSTForceModel` should be refactored for 12.0.
* `ParameterDriver`-related methods could go up in interf...Following this [forum thread](https://forum.orekit.org/t/common-interface-for-forcemodel-and-dsstforcemodel/2763), `ForceModel` and `DSSTForceModel` should be refactored for 12.0.
* `ParameterDriver`-related methods could go up in interface `ParametersDriversProvider` (this could also reduce duplications in `DiscreteTroposphericModel` and `IonosphericModel`).
* `get(Field)EventDetectors` methods could be gathered in an interface `EventDetectorsprovider` that both force models would implement (following @bryan suggestion)
* Javadoc of the previous interface should stress the fact that these methods are not intended to be called several times, only once by the propagator, as it has a side effect of rebuilding the events detectors when called (following @luc suggestion)
* Signature of `get(Field)EventDetectors` should return either a `Stream` or, if possible, an `Iterable` (following @luc suggestion)
* `init` methods should stay as they are in both interfaces since their signatures may be different in the future (see @bryan suggestion)12.0Maxime JournotMaxime Journothttps://gitlab.orekit.org/orekit/orekit/-/issues/1165Plug in ControlVector3DNormType in finite burn classes2023-09-04T18:13:19ZRomain SerraPlug in ControlVector3DNormType in finite burn classes`ConstantThrustManeuver` and the like only use the Euclidean norm for the mass flow rate. More options have been introduced for (Field)ImpulseManeuver but are not yet applied in other classes.`ConstantThrustManeuver` and the like only use the Euclidean norm for the mass flow rate. More options have been introduced for (Field)ImpulseManeuver but are not yet applied in other classes.12.0Romain SerraRomain Serrahttps://gitlab.orekit.org/orekit/orekit/-/issues/1164Interpolators are not thread safe2023-08-28T15:57:52ZVincent CUCCHIETTIvincent.cucchietti@csgroup.euInterpolators are not thread safeHi everyone,
@luc found that the ```Ephemeris``` class is not thread safe. After investigation, it is due to the line 360 in ```Ephemeris``` :
```
final SpacecraftState evaluatedState = stateInterpolator.interpolate(date, s...Hi everyone,
@luc found that the ```Ephemeris``` class is not thread safe. After investigation, it is due to the line 360 in ```Ephemeris``` :
```
final SpacecraftState evaluatedState = stateInterpolator.interpolate(date, states);
```
Indeed, the "interpolate" method overwrites the cache which can then cause the "neighborList" to not be consistent anymore. It means that all interpolators are currently not thread safe.
I'm working on it.
Cheers,
Vincent12.0Vincent CUCCHIETTIvincent.cucchietti@csgroup.euVincent CUCCHIETTIvincent.cucchietti@csgroup.euhttps://gitlab.orekit.org/orekit/orekit/-/issues/1163Wrong error message in ImmutableTimeStampedCache2023-08-20T15:39:22ZLuc MaisonobeWrong error message in ImmutableTimeStampedCacheAs part of fixing issue #1155, a regression was introduced.
When attempting to get a point after last cached entry, the error message says the point is before first cached entry.As part of fixing issue #1155, a regression was introduced.
When attempting to get a point after last cached entry, the error message says the point is before first cached entry.12.0Luc MaisonobeLuc Maisonobehttps://gitlab.orekit.org/orekit/orekit/-/issues/1157Improve parallelism in measurements generation2023-08-08T18:39:37ZLuc MaisonobeImprove parallelism in measurements generationMeasurements generation supports multiple satellites handling thanks to `PropagatorsParallelizer` (which was in fact precisely developed for this purpose) which relies on multi-threading. This support was designed with inter-satellites m...Measurements generation supports multiple satellites handling thanks to `PropagatorsParallelizer` (which was in fact precisely developed for this purpose) which relies on multi-threading. This support was designed with inter-satellites measurements in mind, so for each measurement, all the spacecraft states provided by the parallelized propagators are made available and put in a flat array. The measurement builder picks up the states it needs using an index in the array, using the `ObervableSatellite` to get this index.
There is however another use case that was not foreseen: building lots of single satellite measurements for a full constellation, making sure that at any time, all the measurements corresponding to that time are available. A typical example is generating observation Rinex files. Each Rinex file correspond to one receiver only, but at any time it contains all the measurements corresponding to all GNSS satellites visible from this receiver. Hence, parallel measurements generation is needed there too.
The second use case can be handled using the current design, but it is clearly not efficient and does not fully take advantage of multi-threading. The reason is that despite the propagation itself is multi-threaded, the measurements generation is managed at top level by the `Generator` class which creates the `PropagatorsParallelizer` and a specialized `MultiSatStepHandler` that gather all states before calling the various `Scheduler` and ultimately the associated `MeasurementBuilder`. When a measurement involving a single satellite is desired, it could be generated within the individual propagator thread that handles this satellite, instead of being managed in the main parallelizer thread.12.0Luc MaisonobeLuc Maisonobehttps://gitlab.orekit.org/orekit/orekit/-/issues/1156Move getBuilder from AbstractScheduler base class to Scheduler interface2023-08-20T18:55:23ZLuc MaisonobeMove getBuilder from AbstractScheduler base class to Scheduler interfaceThis method should be declared at interface level.This method should be declared at interface level.12.0Luc MaisonobeLuc Maisonobehttps://gitlab.orekit.org/orekit/orekit/-/issues/1155Allow spllicing of SP3 files2024-03-27T22:02:15ZLuc MaisonobeAllow spllicing of SP3 filesA recurrent demand on the forum is to be able to use several consecutive SP3 files.
One suggestion [made](https://forum.orekit.org/t/interpolation-over-multiple-sp3-files/893) was to use an `AggregateBoundedPropagator` with a list of `Bo...A recurrent demand on the forum is to be able to use several consecutive SP3 files.
One suggestion [made](https://forum.orekit.org/t/interpolation-over-multiple-sp3-files/893) was to use an `AggregateBoundedPropagator` with a list of `BoundedPropagator` retrieved from each SP3 file.
This works great when the file producer takes care to have the last point of one file at the same date as the first point of the next file (typically at midnight), knowing that there may be a discontinuity as the files are produced on different batches of measurements.
This however does not work when there is a gap between the last point of one file and the first point of another file. As an example, some agencies produce files covering 1 day at 5 minutes interval, and these files start at 00:00 and end at 23:55. Using `AggregateBoundedPropagator`, the 5 minutes gap between the end of one propagator and the start of the next propagator cannot be filled: an exception is raised if a computation is attempted during the gap.
In order to alleviate this problem, it would be nice to be able to splice SP3 files together, taking care to drop one point if both files provide data at exactly the splice point. In this case, dropping the file from the earliest file and keeping the file from the newest one seems fair.
For consistency, splicing should be allowed only for files with matching metadata (same time system, same list of satellites, same interval between epochs…).12.0Luc MaisonobeLuc Maisonobehttps://gitlab.orekit.org/orekit/orekit/-/issues/1154Permission issue on downstream pipeline2023-11-08T21:43:45ZSébastien Dinotsebastien.dinot@csgroup.euPermission issue on downstream pipelineCf. [Permission issue on downstream pipeline](https://forum.orekit.org/t/permission-issue-on-downstream-pipeline/2731) topic on the forum.
The evanward1/orekit-performance> project should be moved to the `orekit` namespace to manage per...Cf. [Permission issue on downstream pipeline](https://forum.orekit.org/t/permission-issue-on-downstream-pipeline/2731) topic on the forum.
The evanward1/orekit-performance> project should be moved to the `orekit` namespace to manage permissions efficiently, consistent with the permissions given on projects in this namespace.12.0Sébastien Dinotsebastien.dinot@csgroup.euSébastien Dinotsebastien.dinot@csgroup.euhttps://gitlab.orekit.org/orekit/orekit/-/issues/1153Test failures in collision package due to wrong path2023-10-16T13:54:45ZMaxime JournotTest failures in collision package due to wrong pathSome tests in the collision package using resource "/collision-resources/ION_SCV8_vs_STARLINK_1233.txt" fail.
4 tests fail:
- Patera2005Test.testComputeProbabilityFromACdm()
- Patera2005Test.testComputeProbabilityFromACdmField
- Laas...Some tests in the collision package using resource "/collision-resources/ION_SCV8_vs_STARLINK_1233.txt" fail.
4 tests fail:
- Patera2005Test.testComputeProbabilityFromACdm()
- Patera2005Test.testComputeProbabilityFromACdmField
- Laas2005Test.testComputeProbabilityFromACdm()
- Laas2005Test.testComputeProbabilityFromACdmField
Type of error message:
```java
[ERROR] testComputeProbabilityFromACdmField Time elapsed: 0 s <<< ERROR!
org.orekit.errors.OrekitException: unable to find file /collision-resources/ION_SCV8_vs_STARLINK_1233.txt
at org.orekit.ssa.collision.shorttermencounter.probability.twod.Patera2005Test.testComputeProbabilityFromACdmField(Patera2005Test.java:885)
```
The first version of this issue was related to Windows and was fixed for OpenJDK8.
The error reappeared and was signaled by @luc in this forum [thread](https://forum.orekit.org/t/failing-tests-in-collision-package/2913).
This time it happened for OpenJDK 17 on Linux Debian Trixie.
Further investigations are needed.12.0Maxime JournotMaxime Journothttps://gitlab.orekit.org/orekit/orekit/-/issues/1152ArrayIndexOutOfBoundException in Nequick parameter2023-08-23T11:27:41ZLuc MaisonobeArrayIndexOutOfBoundException in Nequick parameterWhen a longitude is in the vicinity of -180°, an `ArrayIndexOutOfBoundException` is triggered `{Field}NequickParameters`.When a longitude is in the vicinity of -180°, an `ArrayIndexOutOfBoundException` is triggered `{Field}NequickParameters`.12.0Luc MaisonobeLuc Maisonobehttps://gitlab.orekit.org/orekit/orekit/-/issues/1151Performance loss in orbit determination with Solar Radiation Pressure2023-08-22T18:58:32ZMaxime JournotPerformance loss in orbit determination with Solar Radiation PressureI noticed a loss of performance compared to previous versions while doing an orbit determination with SRP perturbation activated.
I think they are due to:
- The calls to `ExtendedPVCoordinatesProvider.getPosition(FieldAbsoluteDate, Fr...I noticed a loss of performance compared to previous versions while doing an orbit determination with SRP perturbation activated.
I think they are due to:
- The calls to `ExtendedPVCoordinatesProvider.getPosition(FieldAbsoluteDate, Frame)` when getting the position of the occulted body (the Sun, but sometimes the Moon too)
→ I think we should try to reduce these calls as much as possible or even call the "non-fielded" version of the function since I'm not sure we need to field this.
- Issue #1000 which now takes the flatness of the occulting body into account in the computation of the lighting ratio of the spacecraft
→ I think users should be allowed to choose the model they want to use (spherical with small computation but less accuracy OR ellipsoidal with heavy computation and high accuracy) since I think that for most usages the ellipsoidal model isn't needed.
**What do you think?**
Some information I gathered. Here are:
- A test generating PV measurements on a day for a LEO satellite and doing an OD on these measurements (force model is Newtonian attraction + SRP)
- In version 12: [TestOdPerformancesWithSrp_V12.java](/uploads/eb2f85012223d6516c1dea3909dddc0e/TestOdPerformancesWithSrp_V12.java)
- In version 11: [TestOdPerformancesWithSrp_V11.java](/uploads/033fec3538704eb6e5d230f590412943/TestOdPerformancesWithSrp_V11.java)
- Some figures, this is the testing time in seconds for each file:
| V12 | Meas Gen | OD |
| ------ | ------ | ------ |
| With SRP and ellipsoidal Earth | 1.82 | **41** |
| With SRP and spherical Earth | 1.2 | **40.3** |
| Without SRP | 0.1 | 1.1 |
| V11.3.3 | Meas Gen | OD |
| ------ | ------ | ------ |
| With SRP | 0.63 | **30** |
| Without SRP | 0.1 | 1.1 |
- There's definitely a regression in V12 compared to V11, most probably due to the resolution of issue #1000.
But still, **30s for a one-day OD with only SRP is still a lot** with v11. I remember doing this in less than 10s a few years back, but I can't say which version used to have these performances.
- Digging a bit deeper, I profiled v12 and v11 versions of the test, and it appears that Orekit spends more than 80% of its time in `ExtendedPVCoordinatesProvider.getPosition(FieldAbsoluteDate, Frame)` which is, getting the "fielded" position of the Sun at a given date.
See for example v12 of the profile, here the 3 calls to the function amount for 81% of the time spent: ![image](/uploads/f03de06b76dda50964d73787bb8906dd/image.png)
- ~~The call at [line 284](https://gitlab.orekit.org/orekit/orekit/-/blob/develop/src/main/java/org/orekit/forces/radiation/SolarRadiationPressure.java#L284) of `SolarRadiationPressure` can use the un-fielded version since we only do a check on the distance here.~~
→ Changing this results in an OD lasting 30.4s (compared to 41s, so a 25% performance increase)
Edit: I changed this call because it's really useless to have a `Field` here (see commit [7bc916aa](https://gitlab.orekit.org/orekit/orekit/-/commit/7bc916aaa7d3930944ba33d446e59d558a5365c9))
- The one at line 149 cannot be avoided, it's the computation of the acceleration. **But do we really need a `FieldAbsoluteDate` here??**
→ Changing this to `AbsoluteDate` (with the previous change kept) results in an OD lasting 20s with no change in the results
- The one at [line 108 of `OcculationEngine`](https://gitlab.orekit.org/orekit/orekit/-/blob/develop/src/main/java/org/orekit/utils/OccultationEngine.java#L108) is the same but here the body could be either the Sun or the Moon (or any other body). **But do we really need a `FieldAbsoluteDate` here??**
→ Changing this to `AbsoluteDate` (with again the previous changes kept) results in an OD lasting 6.3s with no change in the results, which is more in the range of what I used to work with.
So, in the end, it's the multiple calls to the fielded version of the Sun position that degrade the performances.
I don't see exactly a test case where the `FieldAbsoluteDate` instead of `AbsoluteDate` would have a huge impact on the results but I understand that it's needed.
That being said, could we give the users the possibility to choose which function they want to use? (with a function in the attributes of the classes choosing between the fielded or un-fielded version of `ExtendedPVCoordinatesProvider.getPosition` method for example?)12.0Maxime JournotMaxime Journothttps://gitlab.orekit.org/orekit/orekit/-/issues/1150Wrong validity intervals in Sinex files2023-08-21T13:56:40ZLuc MaisonobeWrong validity intervals in Sinex filesSome Sinex files (like [JAX0MGXFIN_20202440000_01D_000_SOL.SNX.gz](https://cddis.nasa.gov/archive/gnss/products/2121/JAX0MGXFIN_20202440000_01D_000_SOL.SNX.gz)) have validity intervals for some data like antenna eccentricities set to def...Some Sinex files (like [JAX0MGXFIN_20202440000_01D_000_SOL.SNX.gz](https://cddis.nasa.gov/archive/gnss/products/2121/JAX0MGXFIN_20202440000_01D_000_SOL.SNX.gz)) have validity intervals for some data like antenna eccentricities set to default values 00:000:00000. This is applicable when the validity span is at least covered by the file span.
However, Orekit currently replace both start and end date with future infinity, hence the file interval and the eccentricities validity interval do not overlap.
As the files may be used also to initialize data for future estimation, it would be nice in this case to have the start date set to file start and the end date remaining at future infinity.12.0Luc MaisonobeLuc Maisonobehttps://gitlab.orekit.org/orekit/orekit/-/issues/1149Parsing error in Sinex files2023-08-21T13:56:39ZLuc MaisonobeParsing error in Sinex filesSome Sinex files published by CDDIS cannot be parsed.
One example is [JAX0MGXFIN_20202440000_01D_000_SOL.SNX.gz](https://cddis.nasa.gov/archive/gnss/products/2121/JAX0MGXFIN_20202440000_01D_000_SOL.SNX.gz)
The reason is that the header l...Some Sinex files published by CDDIS cannot be parsed.
One example is [JAX0MGXFIN_20202440000_01D_000_SOL.SNX.gz](https://cddis.nasa.gov/archive/gnss/products/2121/JAX0MGXFIN_20202440000_01D_000_SOL.SNX.gz)
The reason is that the header line contains blanks values for both file agency code and agency code.12.0Luc MaisonobeLuc Maisonobehttps://gitlab.orekit.org/orekit/orekit/-/issues/1148Add getName() method in LOF and remove toOrbitRelativeFrame from LOF to put i...2023-08-28T15:58:12ZVincent CUCCHIETTIvincent.cucchietti@csgroup.euAdd getName() method in LOF and remove toOrbitRelativeFrame from LOF to put it in LOFTypeHi everyone,
For consistency reason, i believe that the toOrbitRelativeFrame method is specific to ```LOFType``` so it should removed from the ```LOF```interface. In addition, a getName() method in ```LOF```would be interesting.
Cheers...Hi everyone,
For consistency reason, i believe that the toOrbitRelativeFrame method is specific to ```LOFType``` so it should removed from the ```LOF```interface. In addition, a getName() method in ```LOF```would be interesting.
Cheers,
Vincent12.0Vincent CUCCHIETTIvincent.cucchietti@csgroup.euVincent CUCCHIETTIvincent.cucchietti@csgroup.eu