Orekit issueshttps://gitlab.orekit.org/orekit/orekit/-/issues2020-09-22T07:54:30Zhttps://gitlab.orekit.org/orekit/orekit/-/issues/199improve eclipse event handling in DSST Solar Radiation Pressure2020-09-22T07:54:30ZLuc Maisonobeimprove eclipse event handling in DSST Solar Radiation PressureEclipses are currently ignored in this force model.
*(from redmine: issue id 199, created on 2015-04-30)*Eclipses are currently ignored in this force model.
*(from redmine: issue id 199, created on 2015-04-30)*https://gitlab.orekit.org/orekit/orekit/-/issues/351PartialDerivativesEquations does not work with non-Cartesian elements2021-08-09T15:47:37ZEvan WardPartialDerivativesEquations does not work with non-Cartesian elementsUsing PDE with the propagator's orbitType set to a non-Cartesian value
does not produce meaningful results. See the discussion on the dev list:
https://www.orekit.org/wws/arc/orekit-developers/2017-08/msg00010.html
One workaround is to ...Using PDE with the propagator's orbitType set to a non-Cartesian value
does not produce meaningful results. See the discussion on the dev list:
https://www.orekit.org/wws/arc/orekit-developers/2017-08/msg00010.html
One workaround is to compute the STM in Cartesian elements and then
transform it to the desired element set using equation 7.32 in
Montenbruck & Gill:
\`\`\`
STM (Keplerian) = d(kep)/d(cart) \* STM (Cartesian) \* ( d(kep)/d(cart)
)^-1
\`\`\`
Another workaround is to use a
FieldNumericalPropagator<DerivativeStructure> with the orbitType set to
the desired value, and then extract the STM from the final orbital
elements.
*(from redmine: issue id 351, created on 2017-08-11)*https://gitlab.orekit.org/orekit/orekit/-/issues/475Short circuit BooleanDetector2021-09-02T13:14:10ZEvan WardShort circuit BooleanDetectorMake BooleanDetector a short circuit operator similar to Java's \`&&\`
or \`||\`. This could provide performance advantages. For example, if an
\`AND\` operator is used with five constituent detectors and the first
one is negative then t...Make BooleanDetector a short circuit operator similar to Java's \`&&\`
or \`||\`. This could provide performance advantages. For example, if an
\`AND\` operator is used with five constituent detectors and the first
one is negative then the value of the g function will be negative,
irrespective of the values of the remaining four detectors. Since only
-/0/+ matters for event detection the remaining four values could be
ignored. Current implementation is to use the minimum (for AND) value of
all the constituent event detectors.
A potential draw-back is that the g function becomes less smooth. In the
current implementation if all constituent detectors are continuous then
the BooleanDetector's g function is continuous. With this proposal the
BooleanDetector's g function would be piece wise continuous under the
same assumptions. The BooleanDetector's g function would come very close
to zero, then step down to a more negative number when a constituent
detector crosses from negative to positive. Current event detection code
can handle discontinuous functions, but the impact on the performance of
the root finder should be investigated further.
*(from redmine: issue id 475, created on 2018-06-11)*https://gitlab.orekit.org/orekit/orekit/-/issues/525How to use BatchLSEstimator with GPSPropagator?2023-07-21T11:50:59ZGowtham SivaramanHow to use BatchLSEstimator with GPSPropagator?A typical problem of Orbit determination of LEO satellites using GNSS involves processing InterSatellitesRange with remote satellite being one of the GNSS satellites. But the BatchLSEstimator requires the constellation to be propagated n...A typical problem of Orbit determination of LEO satellites using GNSS involves processing InterSatellitesRange with remote satellite being one of the GNSS satellites. But the BatchLSEstimator requires the constellation to be propagated numerically (instead of using GPSPropagator).
Since the Numerical propagation of the constellation requires PV data, which typically is unavailable (even with IGS final product). It would be a great feature to implement a separate propagator to interpolate the position solution from IGS data (as mentioned here: https://gssc.esa.int/navipedia/index.php/Precise_GNSS_Satellite_Coordinates_Computation) which can be fed into BatchLSEstimator to use for the orbit determination.https://gitlab.orekit.org/orekit/orekit/-/issues/537`FIXME` in EKF code2023-10-31T19:48:47ZHao Peng`FIXME` in EKF codeCurrently I'm using the EKF provided as a sequential estimation package. I found many code snippets commented as `FIXME`. Could you guys provide more explanation about these `FIXME`? To my understanding, they should imply errors, but the...Currently I'm using the EKF provided as a sequential estimation package. I found many code snippets commented as `FIXME`. Could you guys provide more explanation about these `FIXME`? To my understanding, they should imply errors, but the result looks correct.
Specifically, I would like to know if the `FIXME` in `/orekit-main/src/main/java/org/orekit/estimation/sequential/UnivariateProcessNoise.java` has been fixed or not yet? Thank you.
[A list of all the `FIXME` in the `master` branch.](https://gitlab.orekit.org/search?utf8=%E2%9C%93&search=fixme&group_id=&project_id=1&search_code=true&repository_ref=master)https://gitlab.orekit.org/orekit/orekit/-/issues/561Creating TLES with epoch during leap second fails2020-05-13T18:12:01ZEvan WardCreating TLES with epoch during leap second failsBacktrace:
```
org.orekit.errors.OrekitInternalError: internal error, please notify development team by creating an issue at https://gitlab.orekit.org/orekit/orekit/issues
at org.orekit.propagation.analytical.tle.TLE.toString(TLE.jav...Backtrace:
```
org.orekit.errors.OrekitInternalError: internal error, please notify development team by creating an issue at https://gitlab.orekit.org/orekit/orekit/issues
at org.orekit.propagation.analytical.tle.TLE.toString(TLE.java:617)
...
Caused by: org.orekit.errors.OrekitException: invalid TLE parameter for object 34,602: fraction = 100000579
at org.orekit.propagation.analytical.tle.TLE.addPadding(TLE.java:431)
at org.orekit.propagation.analytical.tle.TLE.addPadding(TLE.java:414)
at org.orekit.propagation.analytical.tle.TLE.buildLine1(TLE.java:310)
at org.orekit.propagation.analytical.tle.TLE.getLine1(TLE.java:271)
at org.orekit.propagation.analytical.tle.TLE.toString(TLE.java:615)
... 26 more
```
Not sure if on days with leap seconds the divisor is supposed to be 86400 or 86401. I'll see how some other tools handle it.https://gitlab.orekit.org/orekit/orekit/-/issues/576Add weak-time-dependent (WTD) terms in the DSST lunar solar short period motion.2022-01-19T15:34:59ZBryan CazabonneAdd weak-time-dependent (WTD) terms in the DSST lunar solar short period motion.For a better accuracy in orbit propagation and orbit determination it is necessary to add the weak-time-dependent (WTD) terms in the Orekit DSST lunar solar short period motion. For GNSS or GEO orbits adding these terms can improve signi...For a better accuracy in orbit propagation and orbit determination it is necessary to add the weak-time-dependent (WTD) terms in the Orekit DSST lunar solar short period motion. For GNSS or GEO orbits adding these terms can improve significantly the results.https://gitlab.orekit.org/orekit/orekit/-/issues/584Long overflow in AbsoluteDate2020-05-13T18:10:14ZEvan WardLong overflow in AbsoluteDateIf the constructor `AbsoluteDate(AbsoluteDate, double)` is called with a large double value, or if the epoch of the first argument is already large then overflow can occur in `epoch = since.epoch + dl` if the sum is greater than `Long.M...If the constructor `AbsoluteDate(AbsoluteDate, double)` is called with a large double value, or if the epoch of the first argument is already large then overflow can occur in `epoch = since.epoch + dl` if the sum is greater than `Long.MAX_VALUE`. `FastMath.addExact()` could be used to throw an exception if overflow does occur. If overflow does occur the values should probably be set equal to past/future infinity. This can occur in the other constructor that sets `epoch` as well. A more conservative approach would be to return infinities if `offset` is not in the interval [0, 1).
Examples:
```
AbsoluteDate.J2000_EPOCH.shiftedBy(Long.MAX_VALUE).shiftedBy(Long.MAX_VALUE).toString()
// result is "2000-01-01T11:58:53.816" but it should be far in the future
AbsoluteDate.J2000_EPOCH.durationFrom(AbsoluteDate.J2000_EPOCH.shiftedBy(Long.MIN_VALUE))
// result is -9.223372036854776E18 but it should be positive
```
Not sure if this has an practical relevance.https://gitlab.orekit.org/orekit/orekit/-/issues/638Event shifter detects unwanted events when "event duration" is smaller than t...2021-08-18T08:31:25ZMaxime JournotEvent shifter detects unwanted events when "event duration" is smaller than the sum of the shiftsThis issue is related to [this forum post](https://forum.orekit.org/t/eventshifter-behavior-when-the-duration-of-the-event-is-less-than-the-shift/691/4).
Thanks @krys06 for pointing it.
In short, when the signed sum of the shifts (incr...This issue is related to [this forum post](https://forum.orekit.org/t/eventshifter-behavior-when-the-duration-of-the-event-is-less-than-the-shift/691/4).
Thanks @krys06 for pointing it.
In short, when the signed sum of the shifts (increasing - decreasing) is greater than the "duration" of the event, some unwanted events are detected.
This is due to the way the g function is computed inside the [EventShifter](https://gitlab.orekit.org/orekit/orekit/blob/develop/src/main/java/org/orekit/propagation/events/EventShifter.java#L137) class.https://gitlab.orekit.org/orekit/orekit/-/issues/642NodeDetector.estimateNodesTimeSeparation fails for hyperbolic orbits2020-02-06T21:03:43ZEvan WardNodeDetector.estimateNodesTimeSeparation fails for hyperbolic orbitsHyperbolic orbits still have one or two nodes so it is reasonable to try to detect it. The constructor for `NodeDetector` attempts to create two different `KeplerianOrbit`s with true anomaly separated by pi, which is the problem since so...Hyperbolic orbits still have one or two nodes so it is reasonable to try to detect it. The constructor for `NodeDetector` attempts to create two different `KeplerianOrbit`s with true anomaly separated by pi, which is the problem since some values of true anomaly are invalid. Workaround is to call the `NodeDetector` constructor with an elliptical orbit and then `withMaxCheck()`.
Back trace from a decidedly extreme test case:
```
org.orekit.errors.OrekitIllegalArgumentException: true anomaly 3.165 out of hyperbolic range (e = 592,962.934, -1.571 < v < 1.571)
at org.orekit.orbits.KeplerianOrbit.<init>(KeplerianOrbit.java:263)
at org.orekit.orbits.KeplerianOrbit.<init>(KeplerianOrbit.java:163)
at org.orekit.propagation.events.NodeDetector.estimateNodesTimeSeparation(NodeDetector.java:137)
at org.orekit.propagation.events.NodeDetector.<init>(NodeDetector.java:74)
at org.orekit.propagation.events.NodeDetector.<init>(NodeDetector.java:61)
```https://gitlab.orekit.org/orekit/orekit/-/issues/643DecimalFormat not thread safe in DateComponents, TimeComponents2022-01-04T17:18:01ZEvan WardDecimalFormat not thread safe in DateComponents, TimeComponentsCurrently `DateComponents` and `TimeComponents` have static `DecimalFormat` fields that are shared between threads to implement `toString()`. According to the doc for `DecimalFormat`
> "Decimal formats are generally not synchronized. ...Currently `DateComponents` and `TimeComponents` have static `DecimalFormat` fields that are shared between threads to implement `toString()`. According to the doc for `DecimalFormat`
> "Decimal formats are generally not synchronized. It is recommended to create separate format instances for each thread. If multiple threads access a format concurrently, it must be synchronized externally."
I haven't seen any practical impacts and the actual implementation may be thread safe in particular JVMs, but for safety we should use these classes inline with their documentation.https://gitlab.orekit.org/orekit/orekit/-/issues/675Add support for reading general SPICE Ephemeris/Attitude Files2021-01-12T09:57:13ZHank GrabowskiAdd support for reading general SPICE Ephemeris/Attitude Fileshttps://gitlab.orekit.org/orekit/orekit/-/issues/693Allow dynamic outlier filters to be used with batch LS estimator2021-09-02T13:23:39ZBryan CazabonneAllow dynamic outlier filters to be used with batch LS estimatorCurrently, Orekit batch LS architecture does not allow dynamic outlier filter to be used for measurement rejection. Only "static" outlier filters can be used. However, it can be useful to change rejection threshold between iterations.
A...Currently, Orekit batch LS architecture does not allow dynamic outlier filter to be used for measurement rejection. Only "static" outlier filters can be used. However, it can be useful to change rejection threshold between iterations.
A second idea related to that issue: having an independent interface for outlier filters could improve code readability. Especially by differentiating measurement value modifiers and measurement status modifier.https://gitlab.orekit.org/orekit/orekit/-/issues/707Unable to parse 1960-12-31T23:59:61.42021-09-02T13:24:21ZEvan WardUnable to parse 1960-12-31T23:59:61.4The `AbsoluteDate(String, TimeScale)` constructor cannot parse the given date because the leap second then was greater than 1s. Failing test case below.
Not sure if this is worth fixing since it was so long ago. Reporting it here as a k...The `AbsoluteDate(String, TimeScale)` constructor cannot parse the given date because the leap second then was greater than 1s. Failing test case below.
Not sure if this is worth fixing since it was so long ago. Reporting it here as a known defect for completeness.
```java
// first leap more than 1 s: 1.422818s
Assert.assertEquals(
new AbsoluteDate(1961, 1, 1, utc).shiftedBy(-0.022818),
new AbsoluteDate("1960-12-31T23:59:61.4", utc));
```
throws:
```
org.orekit.errors.OrekitIllegalArgumentException: non-existent time 23:59:61.4
at org.orekit.time.TimeComponents.<init>(TimeComponents.java:114)
at org.orekit.time.TimeComponents.parseTime(TimeComponents.java:364)
at org.orekit.time.DateTimeComponents.parseDateTime(DateTimeComponents.java:173)
at org.orekit.time.AbsoluteDate.<init>(AbsoluteDate.java:290)
```https://gitlab.orekit.org/orekit/orekit/-/issues/708Orekit parses non-existent dates in UTC2020-07-31T13:41:38ZEvan WardOrekit parses non-existent dates in UTCThe `AbsoluteDate(String, TimeScale)` constructor is inconsistent in its handling of non-existent dates. If the seconds of minute number is `>=61` an exception is thrown, but no exception is thrown if the seconds of minute number is `<61...The `AbsoluteDate(String, TimeScale)` constructor is inconsistent in its handling of non-existent dates. If the seconds of minute number is `>=61` an exception is thrown, but no exception is thrown if the seconds of minute number is `<61`. For example, an exception will not be thrown for `2009-12-31T23:59:60.5Z` which is an invalid date (no leap second at that time), but an exception will be thrown for `2009-12-31T23:59:61.5Z` which is also an invalid date.
At a minimum the behavior should be documented. For the sake of consistency all invalid times should be treated the same way. Either invalid times throw exceptions, or they don't. If they don't document the algorithm for converting invalid times to valid times.
The also affects `DateTimeComponents.parseDateTime(String)` and `TimeComponents.parseTime(String)`.
Failing test case:
```java
try {
// leap when not expected
new AbsoluteDate("2009-12-31T23:59:60.5Z", utc);
Assert.fail("Expected Exception");
} catch (OrekitException e) {
// expected
}
```https://gitlab.orekit.org/orekit/orekit/-/issues/710BatchLSEstimator slowing down with a lot of stations2023-10-30T09:21:35ZPascal ParraudBatchLSEstimator slowing down with a lot of stationsThis is the very special case where each measurement is associated to a different station (i.e. the antenna is on a boat and each measurement is performed from a slightly different location). Of course, no station parameters are estimate...This is the very special case where each measurement is associated to a different station (i.e. the antenna is on a boat and each measurement is performed from a slightly different location). Of course, no station parameters are estimated in this context.
At the beginning of the BatchLSEstimator estimate method, the construction of the ParameterDriversList using the getMeasurementsParametersDrivers(false) method [line number367] can become very slow as the number of measurements, and thus stations, increases. In my case, the complete orbit restitution process takes 1' with 1000 measurements, 10' with 2000 measurements, 1h15' with 4000 measurements, and the loss of performance is entirely due to this initialization, the duration of the estimation itself remains of the same order.https://gitlab.orekit.org/orekit/orekit/-/issues/747Full Eckstein-Hechler dynamical model realization2021-01-26T13:38:55ZLiao SpacefanFull Eckstein-Hechler dynamical model realizationBoth Orekit and [Celestlab](https://atoms.scilab.org/toolboxes/celestlab) implement the Eckstein-Hechler model, but the modeling is not fully realized, only the perturbations of J2~J6 and J2^2 are considered.
The semi-major axis accurac...Both Orekit and [Celestlab](https://atoms.scilab.org/toolboxes/celestlab) implement the Eckstein-Hechler model, but the modeling is not fully realized, only the perturbations of J2~J6 and J2^2 are considered.
The semi-major axis accuracy of the complete Eckstein-Hechler model can reach 1m. The full implementation can address many orbital maneuver planning problems, is anyone willing to do this difficult but cool task together?https://gitlab.orekit.org/orekit/orekit/-/issues/748Access to Other Controls for iodLambert2023-03-08T12:35:31ZKennethAccess to Other Controls for iodLambertExpand access to iodLambert.java to allow user to specify orbit path as left or right branch, long or short way.
(See call to solveLambertPb) (For reference and examples see "Superior Lambert Algorithm by Gim Der)Expand access to iodLambert.java to allow user to specify orbit path as left or right branch, long or short way.
(See call to solveLambertPb) (For reference and examples see "Superior Lambert Algorithm by Gim Der)Julien AsquierJulien Asquierhttps://gitlab.orekit.org/orekit/orekit/-/issues/750Attitude Dynamics Integration2021-01-27T08:12:31ZEmmanuel PapanagiotouAttitude Dynamics Integration~Feature
According to [this](https://forum.orekit.org/t/attitude-dynamics-integration/1001/8) Orekit Forum post, it has been identified that _it would be desirable for an Attitude Dynamics model to be integrated by a propagator_ in Ore...~Feature
According to [this](https://forum.orekit.org/t/attitude-dynamics-integration/1001/8) Orekit Forum post, it has been identified that _it would be desirable for an Attitude Dynamics model to be integrated by a propagator_ in Orekit. In other words, the user could provide the attitude dynamics equations as additional equations, depending on a variety of additional states, and those would be ideally integrated throughout the propagation, changing the spacecraft attitude as desired.
Such a feature would allow Orekit developers to address a variety of use cases, including but not limited to:
- Incorporation of reaction wheel dynamics models, coupled with the spacecraft attitude;
- Reaction wheel momentum management and dumping with the modelling of magnetic torquers or paired thrusters;
- Design of custom control laws. For instance, given a desired attitude maneuver, the user could be allowed to develop attitude maneuver laws that are eigen-axis maneuvers, time-optimal maneuvers, minimum-cost maneuvers etc..
- Effect of gimbaling (or misaligned) thrusters to the spacecraft attitude, which could also be used as momentum dumping devices.
It would be beneficial to investigate the use of such a feature in combination with analytical and/or numerical propagators.
An older [mailing list post](https://www.orekit.org/mailing-list-archives/orekit-users/msg00175.html) sheds additional light to the complexity of Orekit propagation pipeline, and specifically how the attitude in Orekit is computed "on top" of the orbital state integration, in a sequential manner. The sequence of steps in integration is also discussed in the initally mentioned post.
A suggested course of action to develop this feature is outlined by @luc. [His answer](https://forum.orekit.org/t/attitude-dynamics-integration/1001/6?u=manny) suggests to implement a final step during the integration process:
> What I could suggest [...] would be to add a 6th step that would apply a user-provided post-processing object to the state before it is returned. This post-processing would simply take a state and return a possibly modified state. [...] You could have the attitude really handled there, overriding the attitude used in earlier step, perhaps by simple interpolation, or using a crude model, or reusing data extracted the previous call if you use the same object as attitude provider and as state post-processor.
I hope this feature will be considerd for some new version of Orekit.
Kind regards,
Emmanuel Papanagiotou
~Featurehttps://gitlab.orekit.org/orekit/orekit/-/issues/754Add support for Space-Based Visible (SBV) observations2022-01-21T10:38:44ZBryan CazabonneAdd support for Space-Based Visible (SBV) observationsSpace-Based Visible (SBV) observations are optical observations of space objects from a satellite mounted telescope.
In other words, they represent inter-satellites angular measurements.Space-Based Visible (SBV) observations are optical observations of space objects from a satellite mounted telescope.
In other words, they represent inter-satellites angular measurements.