Orekit issueshttps://gitlab.orekit.org/orekit/orekit/-/issues2024-02-16T08:30:01Zhttps://gitlab.orekit.org/orekit/orekit/-/issues/1215New coordinates (Latitude/Longitude) range crossing detectors2024-02-16T08:30:01ZAlberto FerreroNew coordinates (Latitude/Longitude) range crossing detectorsI would like to propose to merge 2 new detectors: `LongitudeRangeCrossingDetector` and `LatitudeRangeCrossingDetector` as per discussion in: https://forum.orekit.org/t/latitude-and-longitude-crossing-detector/2908
AlbertoI would like to propose to merge 2 new detectors: `LongitudeRangeCrossingDetector` and `LatitudeRangeCrossingDetector` as per discussion in: https://forum.orekit.org/t/latitude-and-longitude-crossing-detector/2908
Alberto12.1Alberto FerreroAlberto Ferrerohttps://gitlab.orekit.org/orekit/orekit/-/issues/1214Enable choice of cached PositionAngleType w/ applicable Orbit2024-02-09T23:09:51ZRomain SerraEnable choice of cached PositionAngleType w/ applicable Orbit`PositionAngleType`-based Orbit's constructors systematically convert the input into TRUE. This is an unnecessary computation and it is suitable to be able to choose the cached type`PositionAngleType`-based Orbit's constructors systematically convert the input into TRUE. This is an unnecessary computation and it is suitable to be able to choose the cached type12.1Romain SerraRomain Serrahttps://gitlab.orekit.org/orekit/orekit/-/issues/1213Decrease code duplication in (Field)SpacecraftState by using isOrbitDefined more2023-11-08T20:28:10ZRomain SerraDecrease code duplication in (Field)SpacecraftState by using isOrbitDefined moreAll the `absPva == null` can be replaced by `isOrbitDefined()`All the `absPva == null` can be replaced by `isOrbitDefined()`12.0Tanner MillsTanner Millshttps://gitlab.orekit.org/orekit/orekit/-/issues/1212GIM model doesn't use ionospheric pierce point2023-11-08T20:28:09ZAustin BeerGIM model doesn't use ionospheric pierce pointFrom what I can tell, the formulas in https://www.sgc.ethz.ch/sgc-volumes/sgk-59.pdf are used in https://gitlab.orekit.org/orekit/orekit/-/blob/0b108c1d05fb2a3be8bddb17e85e1d38d6902a5b/src/main/java/org/orekit/models/earth/ionosphere/Glo...From what I can tell, the formulas in https://www.sgc.ethz.ch/sgc-volumes/sgk-59.pdf are used in https://gitlab.orekit.org/orekit/orekit/-/blob/0b108c1d05fb2a3be8bddb17e85e1d38d6902a5b/src/main/java/org/orekit/models/earth/ionosphere/GlobalIonosphereMapModel.java to calculate the STEC value.
However, the VTEC value that's used to calculate the STEC value is currently interpolated at the **receiver/station** location instead of at the **ionospheric pierce point** location. See Figure 3.5 in https://www.sgc.ethz.ch/sgc-volumes/sgk-59.pdf. I believe this difference may negatively affect the accuracy of the resulting path delay calculations.
Note that equation (3) in https://upcommons.upc.edu/bitstream/handle/2117/361016/remotesensing-13-00012-v2.pdf also indicates that the STEC at the receiver site (x_R) should be calculated from the VTEC at the ionospheric pierce point (x_IPP).
Note also that https://gitlab.orekit.org/orekit/orekit/-/blob/0b108c1d05fb2a3be8bddb17e85e1d38d6902a5b/src/main/java/org/orekit/models/earth/ionosphere/KlobucharIonoModel.java#L144 **does** use the ionospheric pierce point in its calculations.12.0Luc MaisonobeLuc Maisonobehttps://gitlab.orekit.org/orekit/orekit/-/issues/1211Add method to produce angle-based (Field)Orbit instance without derivatives2023-10-26T15:45:27ZRomain SerraAdd method to produce angle-based (Field)Orbit instance without derivativesThe presence of derivatives in `EquinoctialOrbit` and the like can produce computational overhead when computing `PVCoordinates` in `shiftedBy` for example, which is not always suitable.The presence of derivatives in `EquinoctialOrbit` and the like can produce computational overhead when computing `PVCoordinates` in `shiftedBy` for example, which is not always suitable.12.0Romain SerraRomain Serrahttps://gitlab.orekit.org/orekit/orekit/-/issues/1210Add missing inheritance of FieldTimeShiftable2023-10-26T15:45:50ZRomain SerraAdd missing inheritance of FieldTimeShiftable- `FieldTimeShiftable` should inherit from `TimeShiftable` as it defines a double version of `shiftedBy`
- Some classes e.g. `FieldAbsoluteDate`, `FieldTransform`, etc. should inherit from `FieldTimeShiftable` since they define the requi...- `FieldTimeShiftable` should inherit from `TimeShiftable` as it defines a double version of `shiftedBy`
- Some classes e.g. `FieldAbsoluteDate`, `FieldTransform`, etc. should inherit from `FieldTimeShiftable` since they define the required methods12.0Romain SerraRomain Serrahttps://gitlab.orekit.org/orekit/orekit/-/issues/1209Rename PositionAngle2023-10-26T15:46:39ZRomain SerraRename PositionAngle`PositionAngleType` is a better name for an enum, more in line with other ones in Orekit and already used for some setter/getter.`PositionAngleType` is a better name for an enum, more in line with other ones in Orekit and already used for some setter/getter.12.0Romain SerraRomain Serrahttps://gitlab.orekit.org/orekit/orekit/-/issues/1208Default settings give errors in ssa package2023-10-26T15:44:58ZVincent CUCCHIETTIvincent.cucchietti@csgroup.euDefault settings give errors in ssa packageHey all,
Opening this issue following [this thread](https://forum.orekit.org/t/collision-probability-algorithms-default-settings-give-errors/2899).
Cheers,
VincentHey all,
Opening this issue following [this thread](https://forum.orekit.org/t/collision-probability-algorithms-default-settings-give-errors/2899).
Cheers,
Vincent12.0Vincent CUCCHIETTIvincent.cucchietti@csgroup.euVincent CUCCHIETTIvincent.cucchietti@csgroup.euhttps://gitlab.orekit.org/orekit/orekit/-/issues/1205Fix failing tests after correction of Hipparchus issue 2532023-10-26T15:46:53ZMaxime JournotFix failing tests after correction of Hipparchus issue 253Following the correction of issue [253](https://github.com/Hipparchus-Math/hipparchus/issues/253), 6 [failing test cases](https://gitlab.orekit.org/orekit/orekit/-/jobs/11904) appeared in Orekit.
They must be fixed before 12.0.Following the correction of issue [253](https://github.com/Hipparchus-Math/hipparchus/issues/253), 6 [failing test cases](https://gitlab.orekit.org/orekit/orekit/-/jobs/11904) appeared in Orekit.
They must be fixed before 12.0.12.0https://gitlab.orekit.org/orekit/orekit/-/issues/1203Add new method addSupportedParameters in AbstractPropagatorBuilder2023-11-28T17:16:28ZTheo NguyenAdd new method addSupportedParameters in AbstractPropagatorBuilderHello,
I have noticed that this method is sorting the propagation drivers each time that the a driver is added :
````
protected void addSupportedParameter(final ParameterDriver driver) {
propagationDrivers.add(driver);
...Hello,
I have noticed that this method is sorting the propagation drivers each time that the a driver is added :
````
protected void addSupportedParameter(final ParameterDriver driver) {
propagationDrivers.add(driver);
propagationDrivers.sort();
}
````
If we do a propagation with a lot of force models ( a lot of maneuvers for example), adding all the maneuvers to the propagatorBuilder takes more time than the propagation itself and it is is increasing exponentially with the number of maneuvers.
I think that there is a simple turnaround if we replace the method with `addSupportedParameters(final List<ParameterDriver> drivers)`12.0Theo NguyenTheo Nguyenhttps://gitlab.orekit.org/orekit/orekit/-/issues/1201Change default angle type in (Field)NumericalPropagator2024-02-25T22:37:28ZRomain SerraChange default angle type in (Field)NumericalPropagatorCurrent default `PositionAngleType` is `TRUE`, which is the slowest, the fastest being `MEAN` as far as derivative evaluation is concerned. `ECCENTRIC` might be a good compromise as it is used for conversion to position vector.Current default `PositionAngleType` is `TRUE`, which is the slowest, the fastest being `MEAN` as far as derivative evaluation is concerned. `ECCENTRIC` might be a good compromise as it is used for conversion to position vector.12.1Romain SerraRomain Serrahttps://gitlab.orekit.org/orekit/orekit/-/issues/1199CDM xml file values truncated at reading2023-10-26T15:47:06ZLUGANCDM xml file values truncated at readingSee https://forum.orekit.org/t/cdm-xml-file-values-truncated-at-reading/2870 for initial discussionSee https://forum.orekit.org/t/cdm-xml-file-values-truncated-at-reading/2870 for initial discussion12.0LUGANLUGANhttps://gitlab.orekit.org/orekit/orekit/-/issues/1198Plug in new FieldOrbit constructor in FieldSpacecraftState from non Field2024-02-26T20:11:05ZRomain SerraPlug in new FieldOrbit constructor in FieldSpacecraftState from non FieldNew constructor from issue #1194 could be plugged in within constructor of `FieldSpacecraftState` from `Field` and `SpacecraftState`.
When I tried in MR!409, it was breaking some tests due to tolerance and didn't have time to investigat...New constructor from issue #1194 could be plugged in within constructor of `FieldSpacecraftState` from `Field` and `SpacecraftState`.
When I tried in MR!409, it was breaking some tests due to tolerance and didn't have time to investigate.
There is also `Fieldifier` that has similar methods that could be updated.12.1Romain SerraRomain Serrahttps://gitlab.orekit.org/orekit/orekit/-/issues/1197GradientConverter should only use FieldOrbit when applicable2023-10-26T15:47:20ZRomain SerraGradientConverter should only use FieldOrbit when applicable`ModifierGradientConverter` uses `FieldOrbit` even when the original `SpacecraftState` is not based on an `Orbit`. This causes problems when calling `getMu`, see #1141. The issue is larger as `NumericalGradientConverter` seems to have th...`ModifierGradientConverter` uses `FieldOrbit` even when the original `SpacecraftState` is not based on an `Orbit`. This causes problems when calling `getMu`, see #1141. The issue is larger as `NumericalGradientConverter` seems to have the same behaviour.12.0Romain SerraRomain Serrahttps://gitlab.orekit.org/orekit/orekit/-/issues/1196Multiple issues in IOD between 11.3.3 and 12.02023-10-01T13:13:09ZBryan CazabonneMultiple issues in IOD between 11.3.3 and 12.0Between 11.3.3 and 12.0 they are multiple issues in IOD. These issues are mainly regressions in both performance and use of the default data context. More details here: https://forum.orekit.org/t/some-issues-with-iod-architecture-in-orek...Between 11.3.3 and 12.0 they are multiple issues in IOD. These issues are mainly regressions in both performance and use of the default data context. More details here: https://forum.orekit.org/t/some-issues-with-iod-architecture-in-orekit-12-0/2860?u=bcazabonne
I think it is important to fix these issues before releasing 12.0 because they compromise the use of IOD for users using their own data context (usuall in case of operational systems such a Flight Dynamics Systems).12.0Bryan CazabonneBryan Cazabonnehttps://gitlab.orekit.org/orekit/orekit/-/issues/1195OrbitBlender shall have a generic API but well documented2023-10-26T15:47:58ZBryan CazabonneOrbitBlender shall have a generic API but well documentedCurrently, `OrbitBlender `only uses analytical orbit propagator to perform its computations.
There is no technical reason to limit this feature to analytical propagator. The only limitation is the computation time. So, 2 tasks can be pe...Currently, `OrbitBlender `only uses analytical orbit propagator to perform its computations.
There is no technical reason to limit this feature to analytical propagator. The only limitation is the computation time. So, 2 tasks can be performed:
1. Use a more generic API: `Propagator `instead of `AbstractAnalyticalPropagator`
2. Improve the documentation to highlight that analytical propagators are recommended for computation time.
This work can be done in a minor release12.0https://gitlab.orekit.org/orekit/orekit/-/issues/1194Add constructors from Field and Orbit for FieldOrbit2023-10-26T15:48:24ZRomain SerraAdd constructors from Field and Orbit for FieldOrbitFieldSpacecraftState has one constructor that internally converts an Orbit to FieldOrbit but there is nothing in FieldOrbit inheritorsFieldSpacecraftState has one constructor that internally converts an Orbit to FieldOrbit but there is nothing in FieldOrbit inheritors12.0Romain SerraRomain Serrahttps://gitlab.orekit.org/orekit/orekit/-/issues/1192Revamp (Field)SpacecraftState2023-10-26T15:47:45ZRomain SerraRevamp (Field)SpacecraftStateBoth classes have a few minor problems, including:
- Javadoc is not up to date, especially regarding the `AbsolutePVCoordinates` option
- The default, undisclosed attitude is hard coded several times and could actually be switched to a `...Both classes have a few minor problems, including:
- Javadoc is not up to date, especially regarding the `AbsolutePVCoordinates` option
- The default, undisclosed attitude is hard coded several times and could actually be switched to a `FrameAlignedProvider` for performance (instead of an `LofOffset`)12.0Romain SerraRomain Serrahttps://gitlab.orekit.org/orekit/orekit/-/issues/1191Interpolate SP3 coordinates, including clocks2023-09-08T19:48:37ZLuc MaisonobeInterpolate SP3 coordinates, including clocksSP3 coordinates should be interpolable, including clocksSP3 coordinates should be interpolable, including clocks12.0Luc MaisonobeLuc Maisonobehttps://gitlab.orekit.org/orekit/orekit/-/issues/1190SP3 parsing does not handle dummy positions properly2023-09-08T19:48:37ZLuc MaisonobeSP3 parsing does not handle dummy positions properlyIn SP3 files, formats c and d at least, unknown satellite positions are replaced by vectors with coordinates set to 0.0.
This is not detected by the SP3Parser, which only generates one ephemeris segment and will gladly interpolate betwee...In SP3 files, formats c and d at least, unknown satellite positions are replaced by vectors with coordinates set to 0.0.
This is not detected by the SP3Parser, which only generates one ephemeris segment and will gladly interpolate between these dummy positions.
The parser should instead detect these dummy entries and split the ephemeris in several segments.12.0Luc MaisonobeLuc Maisonobe