Orekit issueshttps://gitlab.orekit.org/groups/orekit/-/issues2021-03-02T14:57:26Zhttps://gitlab.orekit.org/orekit/orekit/-/issues/763Add support for IGS SSR data2021-03-02T14:57:26ZBryan CazabonneAdd support for IGS SSR dataIn October 2020, IGS released the first format for SSR (State Space Representation) data: https://files.igs.org/pub/data/format/igs_ssr_v1.pdf
It could be interesting to start the implementation of this format in OrekitIn October 2020, IGS released the first format for SSR (State Space Representation) data: https://files.igs.org/pub/data/format/igs_ssr_v1.pdf
It could be interesting to start the implementation of this format in Orekit11.0https://gitlab.orekit.org/orekit/orekit/-/issues/759Add support for JB2008 (atmosphere model) input data2021-03-02T14:57:00ZBayden PritchardAdd support for JB2008 (atmosphere model) input dataCurrently the JB2008InputParameters interface is not implementedCurrently the JB2008InputParameters interface is not implemented11.0https://gitlab.orekit.org/orekit/orekit/-/issues/758Support alpha-5 TLE satellite numbers2021-03-02T14:57:45ZMark RuttenSupport alpha-5 TLE satellite numbersUS Space Force have introduced a new form of 5-digit satellite number (a combination of a letter and numbers) that allows for numbers > 99,999. Orekit currently expects the satellite numbers to be decimal digits.
From the [space-track documentation](https://www.space-track.org/documentation#tle-alpha5):
Alpha-5 is a stopgap object numbering schema from the United States Space Force that increases the satellite catalog’s capacity to display up to 339,999 objects in the GP/GP_History API classes using legacy fixed-width Two and Three Line Element Set (TLE/3LE) formats.
Replacing the 1st digit of the 5-digit object number with an alphanumeric character makes it possible to represent 240,000 more numbers. Objects less than 100,000 are unaffected by Alpha-5, as are users who download elsets from the GP and GP_History API classes in other formats like XML, JSON, KVN, and CSV. In order to preserve legacy operations that depend on 5-digit integers, our legacy API Classes tle, tle_latest, and tle_publish will not change to Alpha-5.
Only capital letters and numbers are used in Alpha-5. The letters “I” and “O” are omitted to avoid confusion with the numbers “1” and “0”.US Space Force have introduced a new form of 5-digit satellite number (a combination of a letter and numbers) that allows for numbers > 99,999. Orekit currently expects the satellite numbers to be decimal digits.
From the [space-track documentation](https://www.space-track.org/documentation#tle-alpha5):
Alpha-5 is a stopgap object numbering schema from the United States Space Force that increases the satellite catalog’s capacity to display up to 339,999 objects in the GP/GP_History API classes using legacy fixed-width Two and Three Line Element Set (TLE/3LE) formats.
Replacing the 1st digit of the 5-digit object number with an alphanumeric character makes it possible to represent 240,000 more numbers. Objects less than 100,000 are unaffected by Alpha-5, as are users who download elsets from the GP and GP_History API classes in other formats like XML, JSON, KVN, and CSV. In order to preserve legacy operations that depend on 5-digit integers, our legacy API Classes tle, tle_latest, and tle_publish will not change to Alpha-5.
Only capital letters and numbers are used in Alpha-5. The letters “I” and “O” are omitted to avoid confusion with the numbers “1” and “0”.11.0https://gitlab.orekit.org/orekit/orekit/-/issues/757Dynamic outlier filter and multiplexed measurements2021-02-16T15:26:04Zandrea fiorentinoDynamic outlier filter and multiplexed measurements[Relevant forum discussion here](https://forum.orekit.org/t/dynamic-outlier-filter-and-multiplexed-measurements/1104).
As of now, the dynamic outlier filter doesn't seem to be correctly applied to Multiplexed measurements before computation of innovation.
The measurement as a whole should be tagged as rejected if and only if all the observables are rejected. In this case no innovation should be computed.
On the other hand, if only a (proper) subset of the observables is accepted for processing, the innovation should be computed by only taking those into account.[Relevant forum discussion here](https://forum.orekit.org/t/dynamic-outlier-filter-and-multiplexed-measurements/1104).
As of now, the dynamic outlier filter doesn't seem to be correctly applied to Multiplexed measurements before computation of innovation.
The measurement as a whole should be tagged as rejected if and only if all the observables are rejected. In this case no innovation should be computed.
On the other hand, if only a (proper) subset of the observables is accepted for processing, the innovation should be computed by only taking those into account.https://gitlab.orekit.org/orekit/orekit/-/issues/754Add support for Space-Based Visible (SBV) observations2021-02-10T08:53:08ZBryan 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.11.0https://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 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
~Feature~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/748Access to Other Controls for iodLambert2021-03-02T14:59:13ZKennethAccess 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)11.1https://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 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?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/745Add Sequential-Batch Least Squares2021-01-12T13:38:37ZBryan CazabonneAdd Sequential-Batch Least SquaresBatch Least Squares main problem can be describe as follow:
"_Suppose we have 1000 observations and we perform an iterative loop to find the best answer to the state space of the system. But just as we finish converging on the answer, we receive 30 new observations. We could redo the process, using 1030 observations, but that is a waste of time because we've already extracted the information from the first 1000._"
Sequential-Batch Least Squares allows using the statistical information from the least squares processing of the first 1000 observations, and combine it with the new information.
More details are given in: Vallado D., Fundamentals of astrodynamics, Chapter 10.5.Batch Least Squares main problem can be describe as follow:
"_Suppose we have 1000 observations and we perform an iterative loop to find the best answer to the state space of the system. But just as we finish converging on the answer, we receive 30 new observations. We could redo the process, using 1030 observations, but that is a waste of time because we've already extracted the information from the first 1000._"
Sequential-Batch Least Squares allows using the statistical information from the least squares processing of the first 1000 observations, and combine it with the new information.
More details are given in: Vallado D., Fundamentals of astrodynamics, Chapter 10.5.11.1https://gitlab.orekit.org/orekit/orekit/-/issues/742Allow determination of maneuver start/stop time2021-03-02T13:47:32ZMaxime JournotAllow determination of maneuver start/stop timeThis issue was opened following a question from user Sacha on the forum.
As of now maneuver estimation (using batch least square or Kalman estimators) only allows the determination of ΔV vector but not the maneuver's date and/or duration.
It would be a good addition to allow determining date and duration.
@luc suggests to allow this for two independent parameters like:
* start date and stop date
* central date and duration
Related forum thread is [here](https://forum.orekit.org/t/detection-of-continuous-maneuver/1060).This issue was opened following a question from user Sacha on the forum.
As of now maneuver estimation (using batch least square or Kalman estimators) only allows the determination of ΔV vector but not the maneuver's date and/or duration.
It would be a good addition to allow determining date and duration.
@luc suggests to allow this for two independent parameters like:
* start date and stop date
* central date and duration
Related forum thread is [here](https://forum.orekit.org/t/detection-of-continuous-maneuver/1060).11.1https://gitlab.orekit.org/orekit/orekit/-/issues/726Ephemeris based estimation2021-01-13T09:51:11ZAleksandr GorbachevEphemeris based estimationWould be nice to add Ephemeris (BoundPropagator) based estimation feature for measurements parameters correction.
Opened in addition to [this](https://forum.orekit.org/t/ephemeris-based-estimation/1029) forum topic.Would be nice to add Ephemeris (BoundPropagator) based estimation feature for measurements parameters correction.
Opened in addition to [this](https://forum.orekit.org/t/ephemeris-based-estimation/1029) forum topic.11.0https://gitlab.orekit.org/orekit/orekit/-/issues/722Add parsing of Bulletin B data in RapidDataAndPredictionColumnsLoader class2021-01-12T09:43:38ZLeonardoAdd parsing of Bulletin B data in RapidDataAndPredictionColumnsLoader classThe current default behavior of the `RapidDataAndPredictionColumnsLoader` is to parse only Bulletin A data.
However it would be nice that if the user requested window is covered by Bulletin B data the parser uses those.
This permits to have an higher accuracy in case of a posteriori simulations.The current default behavior of the `RapidDataAndPredictionColumnsLoader` is to parse only Bulletin A data.
However it would be nice that if the user requested window is covered by Bulletin B data the parser uses those.
This permits to have an higher accuracy in case of a posteriori simulations.11.0https://gitlab.orekit.org/orekit/orekit/-/issues/721Add EventDetector to EventHandler.init(...)2020-12-09T07:10:14ZEvan WardAdd EventDetector to EventHandler.init(...)Add the `EventDetector` as a method parameter to `EventHandler.init(...)`. Lets the handler know some information about the detector before any events occur.Add the `EventDetector` as a method parameter to `EventHandler.init(...)`. Lets the handler know some information about the detector before any events occur.11.0https://gitlab.orekit.org/orekit/orekit/-/issues/717DSST orbit determination does not work in backward propagation mode2020-09-22T15:21:45ZBryan CazabonneDSST orbit determination does not work in backward propagation modeIn backward propagation mode the DSST orbit determination mode does not work. An exception is thrown. It points an empty interpolation sample in DSST short periodic terms. This problems occurs only if short periodic terms must be computed.
To reproduce the bug, one can add BADG station measurements in the DSST orbit determination process/In backward propagation mode the DSST orbit determination mode does not work. An exception is thrown. It points an empty interpolation sample in DSST short periodic terms. This problems occurs only if short periodic terms must be computed.
To reproduce the bug, one can add BADG station measurements in the DSST orbit determination process/https://gitlab.orekit.org/orekit/orekit/-/issues/710BatchLSEstimator slowing down with a lot of stations2020-08-14T10:01:54ZPascal 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 estimated in this context.
At the beginning of the BatchLSEstimator estimate method, the construction of the ParameterDriversList using the getMeasurementsParametersDrivers(false) method [line #367] 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.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 #367] 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/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`. 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
}
```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/707Unable to parse 1960-12-31T23:59:61.42020-07-31T13:28:42ZEvan 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 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)
```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/702Eclipses by Moon not considered in solar radiation pressure force model2021-01-12T09:50:45ZLuc MaisonobeEclipses by Moon not considered in solar radiation pressure force modelThe solar radiation pressure force model does not consider the
eclipses generated by Moon.
This induces errors in orbit determination for GNSS satellites at some epochs.The solar radiation pressure force model does not consider the
eclipses generated by Moon.
This induces errors in orbit determination for GNSS satellites at some epochs.11.0https://gitlab.orekit.org/orekit/orekit/-/issues/698RinexLoader does not support BDS-3 signal as specified in Rinex 3.042021-01-12T09:52:42ZLuc MaisonobeRinexLoader does not support BDS-3 signal as specified in Rinex 3.04RinexLoader does not fully support version 3.04 of the file format.
It misses all BDS-3 signals that are specified in table 9, page 21
of the format.
Some trigrams exist (for example C1P) but only associated with GPS and Glonass
frequencies. Some trigrams are completely missing (for example C7Z).RinexLoader does not fully support version 3.04 of the file format.
It misses all BDS-3 signals that are specified in table 9, page 21
of the format.
Some trigrams exist (for example C1P) but only associated with GPS and Glonass
frequencies. Some trigrams are completely missing (for example C7Z).11.0https://gitlab.orekit.org/orekit/orekit/-/issues/694TimeScalesFactory.getUTC().getFirstKnownLeapSecond().toString() throws an exc...2020-07-07T13:18:33ZEvan WardTimeScalesFactory.getUTC().getFirstKnownLeapSecond().toString() throws an exception11.0