Orekit issueshttps://gitlab.orekit.org/groups/orekit/-/issues2023-10-26T15:49:10Zhttps://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 examplehttps://gitlab.orekit.org/orekit/orekit/-/issues/1243Execution time issues with frame cache2023-11-10T19:15:42ZDorian GegoutExecution time issues with frame cacheSee https://forum.orekit.org/t/execution-time-issues-with-frame-cache/2972 for full explanationSee https://forum.orekit.org/t/execution-time-issues-with-frame-cache/2972 for full explanationhttps://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/1241Field implementations of getDensity in Atmosphere should use FieldAbsoluteDat...2023-10-23T12:22:47ZRomain SerraField implementations of getDensity in Atmosphere should use FieldAbsoluteDate for solar positionBecause the solar-based models take a `PVCoordinatesProvider` for private attribute `sun`, the `getPosition` only accepts an `AbsoluteDate` (obtained via `toAbsoluteDate`). This means that partial derivatives w.r.t. time obtained from au...Because the solar-based models take a `PVCoordinatesProvider` for private attribute `sun`, the `getPosition` only accepts an `AbsoluteDate` (obtained via `toAbsoluteDate`). This means that partial derivatives w.r.t. time obtained from automatic differentiation e.g. Gradient are wrong. An `ExtendedPVCoordinatesProvider` is needed.
Classes concerned:
- `JB2008`
- `DTM2000`
- `HarrisPriest`
- `NRLMSISE00`https://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/1237Extend (Field)EquinoctialOrbit to hyperbolic case2023-10-27T16:51:32ZRomain SerraExtend (Field)EquinoctialOrbit to hyperbolic caseThere is no theoretical reason why Orekit's equinoctial elements do not work for hyperbolic orbits (and Keplerian ones already do)There is no theoretical reason why Orekit's equinoctial elements do not work for hyperbolic orbits (and Keplerian ones already do)https://gitlab.orekit.org/orekit/orekit/-/issues/1236Fix javadoc in PositionAngleDetector2023-12-29T21:49:30ZVincent CUCCHIETTIvincent.cucchietti@csgroup.euFix javadoc in PositionAngleDetectorHello, noticed a small issue in ```PositionAngleDetector``` : "The angles can be either true, **{link mean or eccentric angles.**"
Cheers,
VincentHello, noticed a small issue in ```PositionAngleDetector``` : "The angles can be either true, **{link mean or eccentric angles.**"
Cheers,
Vincenthttps://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.0https://gitlab.orekit.org/orekit/orekit/-/issues/1232Errors in input frame usage in AngularRaDec.getEstimatedLineOfSight2023-11-08T20:28:08ZMaxime JournotErrors in input frame usage in AngularRaDec.getEstimatedLineOfSightIn `AngularRaDec.getEstimatedLineOfSight` the input `frame` is called GCRF while it could be any frame.
This is more a documentation or Javadoc issue.
On second thought, the usage of this frame is questionable since the output values ...In `AngularRaDec.getEstimatedLineOfSight` the input `frame` is called GCRF while it could be any frame.
This is more a documentation or Javadoc issue.
On second thought, the usage of this frame is questionable since the output values of the RADEC and thus the line of sight will be given in the `referenceFrame` of the `AngularRaDec` object.
I do personally think this method does not have its place in the class, but at the very least the two points above should be fixed.12.0https://gitlab.orekit.org/orekit/orekit/-/issues/1231Bug on buildBox Fix Panel Coefficients2023-11-08T20:28:08ZAlberto FerreroBug on buildBox Fix Panel CoefficientsHi
I found a small bug regarding the FixedPanel call function in the `buildBox` function.
It adds a new panel as
```
panels.add(new FixedPanel(Vector3D.MINUS_I, yLength * zLength, false, absorption, reflection, drag, liftRatio));
```
but...Hi
I found a small bug regarding the FixedPanel call function in the `buildBox` function.
It adds a new panel as
```
panels.add(new FixedPanel(Vector3D.MINUS_I, yLength * zLength, false, absorption, reflection, drag, liftRatio));
```
but the order should be
```
panels.add(new FixedPanel(Vector3D.MINUS_I, yLength * zLength, false, drag, liftRatio, absorption, reflection));
```
as the panel constructor is:
```
public FixedPanel(final Vector3D normal, final double area, final boolean doubleSided,
final double drag, final double liftRatio,
final double absorption, final double reflection)
```
(so basically absorption and reflection are the two last and not the first two)12.0https://gitlab.orekit.org/orekit/orekit/-/issues/1230AberrationModifier should be usable with custom data context2023-12-30T11:46:12ZMaxime JournotAberrationModifier should be usable with custom data context`AberrationModifier` class cannot be used with a custom data context.
All methods using solar system barycenter (SSB) use `DefaultDataContext`.
APIs should be upgraded so that one can use a custom `DataContext` not linked to the defa...`AberrationModifier` class cannot be used with a custom data context.
All methods using solar system barycenter (SSB) use `DefaultDataContext`.
APIs should be upgraded so that one can use a custom `DataContext` not linked to the default one.
TBC, but maybe just putting the SSB as an attribute and adding a constructor taking a generic `DataContext` in input may do the trick.12.0.1Bryan CazabonneBryan Cazabonnehttps://gitlab.orekit.org/orekit/orekit/-/issues/1229Add TrackingCoordinates2023-10-16T12:38:49ZLuc MaisonobeAdd TrackingCoordinatesThe `TopocentricFrame` class provides three independent methods `getElevation`, `getAzimuth` and `getRange` that all recompute a static transform, then apply it to a single point and then extract the result. In many cases, one need sever...The `TopocentricFrame` class provides three independent methods `getElevation`, `getAzimuth` and `getRange` that all recompute a static transform, then apply it to a single point and then extract the result. In many cases, one need several of these values (often site and azimuth together), so some computation are done several times. All these methods should be replaced by a single `getTrackingCoordinates` returning a new `TrackingCoordinates` container holding all three values.12.0Luc MaisonobeLuc Maisonobehttps://gitlab.orekit.org/orekit/orekit/-/issues/1228Add lowestAltitudeIntermediate method to OneAxisEllipsoid2023-10-13T15:00:26ZLuc MaisonobeAdd lowestAltitudeIntermediate method to OneAxisEllipsoidThe lowest altitude point between two endpoints (mainly two satellites) is an important point when computing inter-satellite links.The lowest altitude point between two endpoints (mainly two satellites) is an important point when computing inter-satellite links.12.0Luc MaisonobeLuc Maisonobehttps://gitlab.orekit.org/orekit/orekit/-/issues/1227Add support for CCSDS/SANA geodetic orbital elements.2023-10-10T15:20:59ZLuc MaisonobeAdd support for CCSDS/SANA geodetic orbital elements.The SANA registry defines several types of orbital elements:
https://sanaregistry.org/r/orbital_elements/
Some are supported by Orekit, some are not.
The GEODETIC type should be supported as it allows simple output for plotting ground ...The SANA registry defines several types of orbital elements:
https://sanaregistry.org/r/orbital_elements/
Some are supported by Orekit, some are not.
The GEODETIC type should be supported as it allows simple output for plotting ground tracks.
This must be done in a major version because it implies passing the reference ellipsoid as external data. The CCSDS ODM standard misses this reference ellipsoid (it is probably an error in the standard, it has been notified to CCSDS).12.0Luc MaisonobeLuc Maisonobehttps://gitlab.orekit.org/orekit/orekit/-/issues/1226Constants.SUN_RADIUS does not correspond to IAU resolution B3 from 20152023-10-13T15:00:26ZLuc MaisonobeConstants.SUN_RADIUS does not correspond to IAU resolution B3 from 2015In 2015, IAU published a new standarized value for Sun radius, see [IAU 2015](https://www.iau.org/static/resolutions/IAU2015_English.pdf). This value is 6.957 × 10⁸ m. The value `Constants.SUN_RADIUS` used by Orekit was set in 2010 and i...In 2015, IAU published a new standarized value for Sun radius, see [IAU 2015](https://www.iau.org/static/resolutions/IAU2015_English.pdf). This value is 6.957 × 10⁸ m. The value `Constants.SUN_RADIUS` used by Orekit was set in 2010 and is 6.955 × 10⁸ m, we did not find where we sourced this value from.
It also appears that many tests in Orekit use a hard-coded value of 696000km, which corresponds to the ASUN constant in JPL DE ephemeris files.
The value should be standardized to the IAU resolution.12.0Luc MaisonobeLuc Maisonobe