Orekit issueshttps://gitlab.orekit.org/groups/orekit/-/issues2023-09-06T05:20:10Zhttps://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/1182Move Rinex features from gnss to files package2023-08-28T21:04:42ZBryan CazabonneMove Rinex features from gnss to files packageFeatures related to standard formats (i.e., CCSDS, ILRS, SINEX, and SP3) are in files package. However, RINEX format is in gnss. It shall be moved to files in order to improve consistency.
See forum discussion: https://forum.orekit.org/...Features related to standard formats (i.e., CCSDS, ILRS, SINEX, and SP3) are in files package. However, RINEX format is in gnss. It shall be moved to files in order to improve consistency.
See forum discussion: https://forum.orekit.org/t/moving-rinex-parser-to-files-package/276512.0Bryan CazabonneBryan Cazabonnehttps://gitlab.orekit.org/orekit/orekit/-/issues/1181Misleading javadoc for angles only IOD2023-10-01T13:13:09ZRomain SerraMisleading javadoc for angles only IOD`AbstractAnglesOnlyIod` header says that the orbit is determined "from three position vector". It should rather be "from three lines of sight w.r.t. their respective observers inertial positions vectors".
The acronym IOD should also pro...`AbstractAnglesOnlyIod` header says that the orbit is determined "from three position vector". It should rather be "from three lines of sight w.r.t. their respective observers inertial positions vectors".
The acronym IOD should also probably be defined somewhere.12.0https://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/1179Unnecessary calls to (Field)Transform for some measurement models2023-09-21T08:10:32ZRomain SerraUnnecessary calls to (Field)Transform for some measurement models(Field)StaticTransform can be used.
Problem is at least in `AngularRaDec`.(Field)StaticTransform can be used.
Problem is at least in `AngularRaDec`.12.0https://gitlab.orekit.org/orekit/orekit/-/issues/1178Adaptable max checking interval for event detectors2023-09-04T15:09:34ZJakeRandellOCAdaptable max checking interval for event detectorsA key feature that is missing from the existing event detecting architecture, is the ability to dynamically change the maximum checking interval based on the current `SpacecraftState` or some condition. A key use-case for this would be t...A key feature that is missing from the existing event detecting architecture, is the ability to dynamically change the maximum checking interval based on the current `SpacecraftState` or some condition. A key use-case for this would be to be able to detect short infrequent events during a large search window, where a small interval would have to be set in order to capture every event, at the expense of a long computation time.
The suggestion is to replace the current no-argument withMaxCheckInterval() method in event detectors with a method that would take the current state as an argument `withMaxCheckInterval(state)`. A default implementation would simply always return the same value, but users could register a custom method using something like:
```java
EventDetector detector = new SomeDetector().
withThreshold(aTinyThreshold).
withMaxCheck(state -> closeToEventPredicate(state) ? 1.0 : 100.0);
```
See the original forum post [here](https://forum.orekit.org/t/adaptable-max-check-interval-or-predicate-for-event-detectors/2792) and a similar issue [#87](https://gitlab.orekit.org/orekit/orekit/-/issues/87).12.0Luc MaisonobeLuc Maisonobehttps://gitlab.orekit.org/orekit/orekit/-/issues/1177GLONASS SLOT / FRQ # should be written even if no data is available2023-08-23T19:58:18ZLuc MaisonobeGLONASS SLOT / FRQ # should be written even if no data is availableSome Rinex files do have an empty GLONASS SLOT / FRQ # line, because this line is mandatory in recent Rinex versions.
However, the writer does not write the line if data is missing. An empty line should be written, in order to be allow p...Some Rinex files do have an empty GLONASS SLOT / FRQ # line, because this line is mandatory in recent Rinex versions.
However, the writer does not write the line if data is missing. An empty line should be written, in order to be allow proper read/write roundtrip.12.0Luc MaisonobeLuc Maisonobehttps://gitlab.orekit.org/orekit/orekit/-/issues/1176Wrong parsing of Rinex observation files with SBAS or QZSS satellites in SYS ...2023-08-23T19:58:18ZLuc MaisonobeWrong parsing of Rinex observation files with SBAS or QZSS satellites in SYS / PHASE SHIFTRinex observation files that have SBAS or QZSS satellites in SYS / PHASE SHIFT
do not parse the PRN correctly.Rinex observation files that have SBAS or QZSS satellites in SYS / PHASE SHIFT
do not parse the PRN correctly.12.0Luc MaisonobeLuc Maisonobehttps://gitlab.orekit.org/orekit/orekit/-/issues/1175Wrong parsing of Rinex files with continuation lines in SYS / PHASE SHIFT2023-08-23T19:58:18ZLuc MaisonobeWrong parsing of Rinex files with continuation lines in SYS / PHASE SHIFTWhen Rinex observation files have SYS / PHASE SHIFT lines with more than 10 satellites, parsing fails.
Issue first identified in the [forum](https://forum.orekit.org/t/potential-error-parsing-rinex-files/2786)[SampleRinexFile.23O](/uplo...When Rinex observation files have SYS / PHASE SHIFT lines with more than 10 satellites, parsing fails.
Issue first identified in the [forum](https://forum.orekit.org/t/potential-error-parsing-rinex-files/2786)[SampleRinexFile.23O](/uploads/cef37e83e1c6afe77d61b62da4f3e07b/SampleRinexFile.23O)12.0Luc MaisonobeLuc Maisonobehttps://gitlab.orekit.org/orekit/orekit/-/issues/1174Retrieve individual propagators from AggregateBoundedPropagator2023-09-21T08:11:14ZBrianna AubinRetrieve individual propagators from AggregateBoundedPropagatorCreate a method to retrieve the individual `BoundedPropagators` that make up an `AggregateBoundedPropagator` object. This would allow the user to inspect and confirm the exact nature of the individual propagators that make up the `Aggre...Create a method to retrieve the individual `BoundedPropagators` that make up an `AggregateBoundedPropagator` object. This would allow the user to inspect and confirm the exact nature of the individual propagators that make up the `AggregateBoundedPropagator` object.12.0https://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/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/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/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/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.