Orekit issueshttps://gitlab.orekit.org/groups/orekit/-/issues2023-09-22T12:04:29Zhttps://gitlab.orekit.org/orekit/orekit/-/issues/1200Implement Blendable interface in Orbit2023-09-22T12:04:29ZVincent CUCCHIETTIvincent.cucchietti@csgroup.euImplement Blendable interface in OrbitHey everyone,
Opening this issue before the 12.0 even comes out to not forget to implement the ```Blendable``` interface in ```Orbit```. The goal would be for the blended orbit to be of the same type of the initial orbit (we would have ...Hey everyone,
Opening this issue before the 12.0 even comes out to not forget to implement the ```Blendable``` interface in ```Orbit```. The goal would be for the blended orbit to be of the same type of the initial orbit (we would have to check orbit compatibility or simply convert them to ```CartesianOrbit``` by default.
Cheers,
VincentVincent CUCCHIETTIvincent.cucchietti@csgroup.euVincent CUCCHIETTIvincent.cucchietti@csgroup.euhttps://gitlab.orekit.org/orekit/orekit/-/issues/1193ssa package refactoring2023-09-18T08:55:30ZVincent CUCCHIETTIvincent.cucchietti@csgroup.eussa package refactoringOpening this issue because i would like to refactor the ssa package if possible even though it is not absolutely necessary.
EDIT: Will probably be postponed to 13.0 if i don't have enough time.
cheers,
VincentOpening this issue because i would like to refactor the ssa package if possible even though it is not absolutely necessary.
EDIT: Will probably be postponed to 13.0 if i don't have enough time.
cheers,
VincentVincent CUCCHIETTIvincent.cucchietti@csgroup.euVincent CUCCHIETTIvincent.cucchietti@csgroup.euhttps://gitlab.orekit.org/orekit/orekit/-/issues/1184ISS OEM failing in XML format2024-01-19T22:24:22ZPetrus HyvönenISS OEM failing in XML formatThe online NASA published ISS OEM format fails to be parsed in XML format (works in text format).
"org.orekit.errors.OrekitException: unsupported format for file XXX.xml". I have not had time to investigate further.
Source: https://sp...The online NASA published ISS OEM format fails to be parsed in XML format (works in text format).
"org.orekit.errors.OrekitException: unsupported format for file XXX.xml". I have not had time to investigate further.
Source: https://spotthestation.nasa.gov/trajectory_data.cfm
[ISS.OEM_J2K_EPH.xml](/uploads/30dd11966d99fa387835ff7bc2925c72/ISS.OEM_J2K_EPH.xml)
[ISS.OEM_J2K_EPH.txt](/uploads/f5ea80708db9f115de15ca4170e45798/ISS.OEM_J2K_EPH.txt)https://gitlab.orekit.org/orekit/orekit/-/issues/1183Potential Issue in JB2008 Implementation with Local Hour Angle Computation2023-09-06T05:20:10ZPol MesallesPotential Issue in JB2008 Implementation with Local Hour Angle ComputationI was going through the `JB2008` Orekit implementation and found a potential discrepancy between the original Fortran code from Bowman and Orekit's implementation. The [original code](https://sol.spacenvironment.net/JB2008/JB2008.f) take...I was going through the `JB2008` Orekit implementation and found a potential discrepancy between the original Fortran code from Bowman and Orekit's implementation. The [original code](https://sol.spacenvironment.net/JB2008/JB2008.f) takes in the following inputs:
```
C AMJD : Date and Time, in modified Julian Days
C and Fraction (MJD = JD-2400000.5)
C SUN(1) : Right Ascension of Sun (radians)
C SUN(2) : Declination of Sun (radians)
C SAT(1) : Right Ascension of Position (radians)
C SAT(2) : Geocentric Latitude of Position (radians)
C SAT(3) : Height of Position (km)
C F10 : 10.7-cm Solar Flux (1.0E-22*Watt/(M**2*Hertz))
C (Tabular time 1.0 day earlier)
C F10B : 10.7-cm Solar Flux, ave.
C 81-day centered on the input time
C (Tabular time 1.0 day earlier)
C S10 : EUV index (26-34 nm) scaled to F10
C (Tabular time 1.0 day earlier)
C S10B : EUV 81-day ave. centered index
C (Tabular time 1.0 day earlier)
C XM10 : MG2 index scaled to F10
C (Tabular time 2.0 days earlier)
C XM10B : MG2 81-day ave. centered index
C (Tabular time 2.0 days earlier)
C Y10 : Solar X-Ray & Lya index scaled to F10
C (Tabular time 5.0 days earlier)
C Y10B : Solar X-Ray & Lya 81-day ave. centered index
C (Tabular time 5.0 days earlier)
C DSTDTC : Temperature change computed from Dst index
```
In Orekit, the Java translation of this main `JB2008` Fortran subroutine is available via [this](https://www.orekit.org/site-orekit-10.0/apidocs/org/orekit/models/earth/atmosphere/JB2008.html#getDensity-double-double-double-double-double-double-double-double-double-double-double-double-double-double-double-) method.
For this issue, what I am concerned with are the `SAT` and `SUN` arrays. In particular, `SAT(1)` or as is called in Orekit `satLon`, which is supposed to represent the right ascension of the satellite, as well as `SUN(1)` or `sunRA`, which is the right ascension of the Sun. This is important because internally in the JB2008 code it is used to compute the LHA (local hour angle) that is then an input to Equation (16) for τ from Jacchia's [original work](https://ntrs.nasa.gov/api/citations/19700027590/downloads/19700027590.pdf), which is simply:
```
LHA = SAT(1) - SUN(1)
```
In Orekit, this occurs [here](https://gitlab.orekit.org/orekit/orekit/-/blob/develop/src/main/java/org/orekit/models/earth/atmosphere/JB2008.java#L271) for the scalar implementation.
Note that LHA as an input is not a JB2008-specific input, but it's part of all Jacchia models. In fact, this shows up in Appendix B of Vallado as well, where he suggests an alternative way to compute it. Separately from LHA (which should be computed using TOD / inertial coordinates as it represents the angle in the celestial equator), the Jacchia models also require the geocentric/geodetic latitude and height inputs. This got me at first when going through the `JB2008.for` code as `SAT` is an array with right ascension (1) and then geodetic latitude (2) and height (3), which is definitely not a common coordinate system combination.
My concern is that when using the generic Orekit `Atmosphere` interface and its `getDensity` [method](https://www.orekit.org/site-orekit-10.0/apidocs/org/orekit/models/earth/atmosphere/JB2008.html#getDensity-org.orekit.time.AbsoluteDate-org.hipparchus.geometry.euclidean.threed.Vector3D-org.orekit.frames.Frame-), the inputs that are passed into the [original interface method](https://www.orekit.org/site-orekit-10.0/apidocs/org/orekit/models/earth/atmosphere/JB2008.html#getDensity-double-double-double-double-double-double-double-double-double-double-double-double-double-double-double-) are:
- Equivalent of `SUN`: `sunInBody.getLongitude()`, `sunInBody.getLatitude()`
- Equivalent of `SAT`: `inBody.getLongitude()`, `inBody.getLatitude()`, `inBody.getAltitude()`
where `sunInBody = earth.transform(sunPos, ecef, date)` and `inBody = earth.transform(position, frame, date)` are `GeodeticPoint`s as can be seen [here](https://gitlab.orekit.org/orekit/orekit/-/blob/develop/src/main/java/org/orekit/models/earth/atmosphere/JB2008.java#L1226).
Therefore, to me it looks like the generic Orekit [`getDensity`](https://www.orekit.org/site-orekit-10.0/apidocs/org/orekit/models/earth/atmosphere/JB2008.html#getDensity-org.orekit.time.AbsoluteDate-org.hipparchus.geometry.euclidean.threed.Vector3D-org.orekit.frames.Frame-) implementation is passing in the wrong values to the internal original [`getDensity`](https://www.orekit.org/site-orekit-10.0/apidocs/org/orekit/models/earth/atmosphere/JB2008.html#getDensity-double-double-double-double-double-double-double-double-double-double-double-double-double-double-double-) interface. It appears to be passing in the geodetic longitude instead of the inertial right ascension, resulting in a different LHA.
I may have missed something as I was going through the code, so please feel free to close this issue in that case, but I wanted to get another set of eyes on this. Thank you!https://gitlab.orekit.org/orekit/orekit/-/issues/1180Add spherical harmonics for third bodies2023-10-27T16:50:25ZRomain SerraAdd spherical harmonics for third bodieshttps://gitlab.orekit.org/orekit/orekit/-/issues/1166IodGooging. Orbit got from three angular observations2023-08-14T13:00:56ZDaianaKadyrovaIodGooging. Orbit got from three angular observationsIodGooding (Orbit got from three angular observations) gives not appropriate results for orbits, while other Iod methods with same input parameters dealing well with this problem. The problem is described in more details in this discussi...IodGooding (Orbit got from three angular observations) gives not appropriate results for orbits, while other Iod methods with same input parameters dealing well with this problem. The problem is described in more details in this discussion https://forum.orekit.org/t/iodgooging-orbit-got-from-three-angular-observations/2749https://gitlab.orekit.org/orekit/website-2015/-/issues/15Add a subsection "Research Work Using Orekit" in section "Publications"2023-11-10T17:12:54ZMaxime JournotAdd a subsection "Research Work Using Orekit" in section "Publications"It would be nice to have a section in "Publications" gathering research papers where the authors used Orekit.It would be nice to have a section in "Publications" gathering research papers where the authors used Orekit.https://gitlab.orekit.org/orekit/orekit/-/issues/1162Better exception for unknown body2023-08-09T19:41:38ZEvan WardBetter exception for unknown bodyCurrently I see the follow exception when calling `celectialBodies.getBody("MON")`. My mistake, but it would be nicer if the exception is an `OrekitException` and included the name of the requested body and said it was not found so that ...Currently I see the follow exception when calling `celectialBodies.getBody("MON")`. My mistake, but it would be nicer if the exception is an `OrekitException` and included the name of the requested body and said it was not found so that I know what my mistake is.
```
java.lang.NullPointerException: null
at org.orekit.bodies.LazyLoadedCelestialBodies.getBody(LazyLoadedCelestialBodies.java:330)
```https://gitlab.orekit.org/orekit/orekit/-/issues/1161Add static method to create an event detector that would be activated or deac...2024-03-07T18:54:11ZVincent CUCCHIETTIvincent.cucchietti@csgroup.euAdd static method to create an event detector that would be activated or deactivated through another event detectorHi everyone,
After discussing with @Jasquier, we thought that a simple but yet very useful feature could be added to Orekit.
The idea would be to add static methods to ```EventEnablingPredicateFilter``` to easily create a detector that...Hi everyone,
After discussing with @Jasquier, we thought that a simple but yet very useful feature could be added to Orekit.
The idea would be to add static methods to ```EventEnablingPredicateFilter``` to easily create a detector that would be linked to another detector. For example :
```
newDetector = EventEnablingPredicateFilter.activateEventIfEventIsDetected(eventDetectorToActivate, otherEventDetector)
```
or
```
newDetector = EventEnablingPredicateFilter.deactivateEventIfEventIsDetected(eventDetectorToDeactivate, otherEventDetector)
```
This would allow for very interesting and computationally efficient uses such as linking maneuvers with each other so that the propagator would not check all maneuver triggers but only the one of the next maneuver.
Cheers,
Vincenthttps://gitlab.orekit.org/orekit/orekit/-/issues/1160GMSTScale only implements IERS 96 conventions2023-08-09T12:54:14ZEvan WardGMSTScale only implements IERS 96 conventionsIn `IERSConventions` there are two different implementations of `getGMSTFunction(...)` depending on the conventions used, but `GMSTScale` only implements one, which can lead to discrepancies between the two implementations for IERS 2003 ...In `IERSConventions` there are two different implementations of `getGMSTFunction(...)` depending on the conventions used, but `GMSTScale` only implements one, which can lead to discrepancies between the two implementations for IERS 2003 and 2010 conventions.https://gitlab.orekit.org/orekit/orekit/-/issues/1159Add public method to parse Alpha5 satellite number2023-08-09T12:07:44ZEvan WardAdd public method to parse Alpha5 satellite numberAs a user I would like to parse an alpha5 format satellite number from a `String` to an `int`. The `TLE` class can do it, but if I just have the satellite number I would have to create a fake TLES to use it. The `ParseUtils.parseSatellit...As a user I would like to parse an alpha5 format satellite number from a `String` to an `int`. The `TLE` class can do it, but if I just have the satellite number I would have to create a fake TLES to use it. The `ParseUtils.parseSatelliteNumber(...)` method can do it, but the class is not public.https://gitlab.orekit.org/orekit/orekit/-/issues/1158Add Field version of Lagrange points orbits2023-09-25T18:57:15ZRomain SerraAdd Field version of Lagrange points orbitshttps://gitlab.orekit.org/orekit/orekit/-/issues/1145Create field equivalent of existing "calculateField" method within GeoMagneti...2023-07-27T18:12:17ZVincent CUCCHIETTIvincent.cucchietti@csgroup.euCreate field equivalent of existing "calculateField" method within GeoMagneticFieldHi everyone,
As explained in the title, it could be interesting to have the field equivalent of the "calculateField" method within the ```GeoMagneticField``` class.
Cheers,
VincentHi everyone,
As explained in the title, it could be interesting to have the field equivalent of the "calculateField" method within the ```GeoMagneticField``` class.
Cheers,
Vincenthttps://gitlab.orekit.org/orekit/orekit/-/issues/1140NaN on anomaly with FieldEclipseDetector and Complex Field2023-07-21T08:37:37ZRomain SerraNaN on anomaly with FieldEclipseDetector and Complex FieldA NaN can appear on the anomaly (after event detection?), leading to the code crashing at org.orekit.bodies.Ellipsoid.pointOnLimb
Data to reproduce:
Initial conditions
```
final double mu = Constants.WGS84_EARTH_MU;
final Frame...A NaN can appear on the anomaly (after event detection?), leading to the code crashing at org.orekit.bodies.Ellipsoid.pointOnLimb
Data to reproduce:
Initial conditions
```
final double mu = Constants.WGS84_EARTH_MU;
final Frame inertialFrame = FramesFactory.getGCRF();
final Vector3D initialPosition = new Vector3D(Constants.EGM96_EARTH_EQUATORIAL_RADIUS + 2000e3,
100., -1000.);
final Vector3D initialVelocity = new Vector3D(-100., 7.5e3, 1.);
final double initialMass = 1000.;
final PVCoordinates pvCoordinates = orbit.getPVCoordinates();
final FieldVector3D<T> fieldPosition = new FieldVector3D<>(field, pvCoordinates.getPosition());
final FieldVector3D<T> fieldVelocity = new FieldVector3D<>(field, pvCoordinates.getVelocity());
final FieldPVCoordinates<T> fieldPVCoordinates = new FieldPVCoordinates<>(fieldPosition,
fieldVelocity);
return new FieldCartesianOrbit<>(fieldPVCoordinates, inertialFrame,
new FieldAbsoluteDate<>(field, orbit.getDate()), field.getZero().add(mu));
```
Propagator
```
final T fieldStepSize = field.getOne().add(stepSize);
final ClassicalRungeKuttaFieldIntegrator<T> fieldIntegrator = new ClassicalRungeKuttaFieldIntegrator<>(field,
60.);
final FieldNumericalPropagator<T> fieldPropagator = new FieldNumericalPropagator<>(field,
fieldIntegrator);
final FieldOrbit<T> fieldInitialOrbit = createConstantFieldOrbit(field, initialOrbit);
final T fieldInitialMass = field.getZero().add(initialMass);
fieldPropagator.setInitialState(new FieldSpacecraftState<>(fieldInitialOrbit, fieldInitialMass));
```
detector
```
eventDetector = new EclipseDetector(CelestialBodyFactory.getSun(),Constants.SUN_RADIUS,
new OneAxisEllipsoid(Constants.WGS84_EARTH_EQUATORIAL_RADIUS,
Constants.WGS84_EARTH_FLATTENING, earth.getBodyOrientedFrame()));
fieldDetector = new FieldEclipseDetector<>(field,
((EclipseDetector) detector).getOccultationEngine()).withHandler(new FieldStopOnEvent<>());
```
Time of flight of 10000 seconds will lead to bug with Complex (not DerivativeStructure for instance).https://gitlab.orekit.org/orekit/orekit/-/issues/1131Spherical coordinates2023-10-27T16:50:55ZRomain SerraSpherical coordinatesSpherical coordinates (not necessarily in a usual pseudo-inertial frame like GCRF, but more with a custom XY plane) would be good to have, for propagation in particular. So as an `OrbitType`, with the associated `Orbit` class?Spherical coordinates (not necessarily in a usual pseudo-inertial frame like GCRF, but more with a custom XY plane) would be good to have, for propagation in particular. So as an `OrbitType`, with the associated `Orbit` class?https://gitlab.orekit.org/orekit/orekit/-/issues/1119Inconsistent AP Index selection at 3-hour marks in CssiSpaceWeatherData.getAp()2023-10-29T17:18:00Zkyle-cochranInconsistent AP Index selection at 3-hour marks in CssiSpaceWeatherData.getAp()Hello, first off: great library! Thanks for working to make astrodynamics more open source.
I am using Orekit to benchmark/validate a similar open source project in C++: [Open Space Toolkit](https://github.com/open-space-collective)
It ...Hello, first off: great library! Thanks for working to make astrodynamics more open source.
I am using Orekit to benchmark/validate a similar open source project in C++: [Open Space Toolkit](https://github.com/open-space-collective)
It has been quite helpful so far.
While comparing inputs for the NRLMSISE-00 model, I believe I may have found an edge case in computing the AP Index input array. [i.e. this function](https://gitlab.orekit.org/orekit/orekit/-/blob/develop/src/main/java/org/orekit/models/earth/atmosphere/data/CssiSpaceWeatherData.java#L287).
**description:**
If the AP indices are computed at exactly a 3-hour mark (i.e. 00:00, 03:00, 06:00, ...) there may be some inconsistency in the AP index that is returned.
The AP indices provided by Celestrak are specified within 3 hour time ranges, but do not seem to specify inclusivity on the edge of each range:
```
| AP1 | Planetary Equivalent Amplitude (Ap) for 0000-0300 UT. |
| AP2 | Planetary Equivalent Amplitude (Ap) for 0300-0600 UT. |
| AP3 | Planetary Equivalent Amplitude (Ap) for 0600-0900 UT. |
| AP4 | Planetary Equivalent Amplitude (Ap) for 0900-1200 UT. |
| AP5 | Planetary Equivalent Amplitude (Ap) for 1200-1500 UT. |
| AP6 | Planetary Equivalent Amplitude (Ap) for 1500-1800 UT. |
| AP7 | Planetary Equivalent Amplitude (Ap) for 1800-2100 UT. |
| AP8 | Planetary Equivalent Amplitude (Ap) for 2100-0000 UT. |
```
(copied from documentation at https://celestrak.org/SpaceData/SpaceWx-format.php)
So it is unclear which AP index should be returned for 0600, for example (AP2 or AP3?). However, I am observing that the selection is inconsistent in Orekit.
**example:**
The `getAp()` function returns an array with the following format:
```
0 : daily AP
1 : 3 hr AP index for current time
2 : 3 hr AP index for 3 hrs before current time
3 : 3 hr AP index for 6 hrs before current time
4 : 3 hr AP index for 9 hrs before current time
5 : Average of eight 3 hr AP indicies from 12 to 33 hrs
prior to current time
6 : Average of eight 3 hr AP indicies from 36 to 57 hrs
prior to current time
```
if `getAp()` is called for the instant `2021-01-08 00:00:00` the following array is returned:
`4, 9, 9, 5, 2, 4.5, 13.25`
Checking this against the [source file data](https://ftp.agi.com/pub/DynamicEarthData/SpaceWeather-All-v1.2.txt):
```
AP1 AP2 AP3 AP4 AP5 AP6 AP7 AP8 APd
2021 01 07 ... 5 6 4 3 2 2 5 9 4 ...
2021 01 08 ... 2 2 2 2 2 0 0 2 2 ...
```
For the "3 hr AP index for current time" value, 9 is returned, indicating that it is choosing AP8 from the previous day (AP ranges are inclusive on the _higher_ end).
However, for the "3 hr AP index for 3 hrs before current time" value, it is also returning 9, which indicates that it is choosing AP8 again (ranges are inclusive on the _lower_ end).
**impact:**
This is a somewhat rough comparison, I am comparing to my code which matches quite well when computations do not lie on a 3 hour mark but matches much worse when taken at 0300, 0600, etc.
Calculating density every 3 hours for the range `2021-01-01T00:00:00`-`2021-01-11T00:00:00`
Starting at 2021-01-01T00:00:00 [i.e. landing on 3 hour marks]:
- matches to a tolerance of 2.472e-14 kg/m^3
Starting at 2021-01-01T01:00:00 [i.e. avoiding 3 hour marks]:
- matches to a tolerance of 1.1004e-15 kg/m^3
Please let me know if there's something I'm missing! I am also happy to provide the code that I am using to produce the Orekit values and my working C++ implementation is [here](https://github.com/open-space-collective/open-space-toolkit-physics/pull/145) for comparison. Otherwise, thanks again for the great library!
Best,
Kylehttps://gitlab.orekit.org/orekit/orekit/-/issues/1104Discrepancy in osculating elements between DSST and numerical propagators wit...2024-03-20T15:59:24ZMaxime JournotDiscrepancy in osculating elements between DSST and numerical propagators with 2x0 gravity fieldI've noticed a discrepancy in osculating elements when comparing orbits between DSST and numerical propagators.
Configuration:
- LEO satellite
- Gravity field 2x0 (but an higher degree x order gives the same results)
- Zonal and Tess...I've noticed a discrepancy in osculating elements when comparing orbits between DSST and numerical propagators.
Configuration:
- LEO satellite
- Gravity field 2x0 (but an higher degree x order gives the same results)
- Zonal and Tesseral DSST forces (with or without J2² mean effect)
- Propagation on 50 orbits
Result:
- Discrepancy between osculating elements on all 6 orbital parameters
- Ex. bias of about 20m on semi-major axis and parabolic evolution of inclination leading to a mean error of 0.4 mdeg after 50 orbits
→ See figure belowhttps://gitlab.orekit.org/orekit/orekit/-/issues/1103CCSDS : Use Optional for not-mandatory fields2024-01-16T12:52:54ZLUGANCCSDS : Use Optional for not-mandatory fieldsDiscussion in https://forum.orekit.org/t/clarify-not-mandatory-values-coming-from-cdm-xml-files/2562/9Discussion in https://forum.orekit.org/t/clarify-not-mandatory-values-coming-from-cdm-xml-files/2562/9https://gitlab.orekit.org/orekit/orekit/-/issues/1086NaN derivatives in Keplerian propagation with Cartesian coordinates2023-06-30T12:49:18ZRomain SerraNaN derivatives in Keplerian propagation with Cartesian coordinatesIn `FieldCartesianOrbit`, `shiftPVElliptic` causes NaN on the derivatives when used with `Gradient` (although this probably happens as well with `DerivativeStructure`, etc.) and a circular orbit, in particular of the type position (X,0,0...In `FieldCartesianOrbit`, `shiftPVElliptic` causes NaN on the derivatives when used with `Gradient` (although this probably happens as well with `DerivativeStructure`, etc.) and a circular orbit, in particular of the type position (X,0,0) and velocity (0, sqrt(mu/X),0).
This is not a singularity of the propagation itself (as there is no problem if converting to equinoctial, propagating and converting back), but rather of the particular method used. The NaNs appear at the call to `arctan2`https://gitlab.orekit.org/orekit/orekit/-/issues/1085NaNs in propagation of Keplerian motion with Cartesian coordinates and comple...2023-06-30T12:49:49ZRomain SerraNaNs in propagation of Keplerian motion with Cartesian coordinates and complex numbersIn `shiftPVElliptic` of `FieldCartesianOrbit`, using `ComplexField` with a circular orbit leads to NaN. In particular, any initial position like (X, 0,0) and velocity (0,sqrt(mu/X),0) will cause it. They appear in the `arctan2`.
This hap...In `shiftPVElliptic` of `FieldCartesianOrbit`, using `ComplexField` with a circular orbit leads to NaN. In particular, any initial position like (X, 0,0) and velocity (0,sqrt(mu/X),0) will cause it. They appear in the `arctan2`.
This happens at least if the initial imaginary parts are zeros, have not checked other cases. It is a regression because it doesn't happen when using the old version before Orekit 11.3.