Orekit issueshttps://gitlab.orekit.org/orekit/orekit/-/issues2021-08-18T08:39:02Zhttps://gitlab.orekit.org/orekit/orekit/-/issues/826Null ephemeris generators while propagating several numerical propagators wit...2021-08-18T08:39:02ZLUGANNull ephemeris generators while propagating several numerical propagators with PropagatorsParallelizerThe problem is that the first generator have ephemeris but the others not.
The test is silly by propagating exactly the samething but in my case I have different spacecraft/propagator and the nulls occur too.
Test unit seggested in [bra...The problem is that the first generator have ephemeris but the others not.
The test is silly by propagating exactly the samething but in my case I have different spacecraft/propagator and the nulls occur too.
Test unit seggested in [branch](https://gitlab.orekit.org/Anne-Laure/orekit/-/tree/feature/parallelizer)
Some discussion started in [forum](https://forum.orekit.org/t/ephemeris-with-propagatorsparallelizer/1321).https://gitlab.orekit.org/orekit/orekit/-/issues/823Wrong implementation of Kalman estimation using DSST propagator2021-08-11T15:42:29ZBryan CazabonneWrong implementation of Kalman estimation using DSST propagatorCurrent implementation of orbit determination using both DSST propagator and Extended Kalman Filter (EKF) is not correct. Orbit determination based on semi-analytical satellite theory and recursive filter must be done using a specific al...Current implementation of orbit determination using both DSST propagator and Extended Kalman Filter (EKF) is not correct. Orbit determination based on semi-analytical satellite theory and recursive filter must be done using a specific algorithm: the Extended Semi-analytical Kalman Filter (ESKF). The EKF algorithm needs to re-initialize the orbital state at each observation epoch. However, the time difference between two observations is usually much smaller than the DSST step size (e.g., half a day). ESKF reconciles the conflicting goal of both theories.
Current implementation (`DSSTKalmanModel`) must be removed and replace by a new implementation.
For more details about the equations and the theory [1] [2] [3]
[1]: Taylor S. P., Semi-analytical Satellite Theory and Sequential Estimation, Master of Science Thesis, Department of
Mechanical Engineering, MIT, September, 1981
[2]: Wagner E. A., Application of the Extended Semianalytical Kalman Filter to Synchronous Orbits, Master of Science
Thesis, Department of Aeronautics and Astronautics, MIT, June, 1983
[3]: Folcik Z., Orbit Determination Using Modern Filters/Smoothers and Continuous Thrust Modeling, Master of Sci-
ence Thesis, Department of Aeronautics and Astronautics, MIT, June, 200812.0https://gitlab.orekit.org/orekit/orekit/-/issues/816DSST Short Period Motion Fourier Coefficient Time Derivatives2021-07-27T08:41:09ZPaul CefolaDSST Short Period Motion Fourier Coefficient Time DerivativesThe efficient computation of the DSST short period motion Fourier coefficients is important for Orekit DSST orbit determination applications, especially high accuracy applications where many of these coefficients are required. Currently...The efficient computation of the DSST short period motion Fourier coefficients is important for Orekit DSST orbit determination applications, especially high accuracy applications where many of these coefficients are required. Currently these coefficients are computed with Lagrange interpolators because the time derivatives of the coefficients are not available. If both the coefficients and their time derivatives were available, we could employ Hermite interpolators. Such Hermite interpolators have proved advantageous for the DSST mean element equations of motion. But Orekit has implemented an automatic differentiation scheme for derivatives of complex software-defined functions. This issue requests implementation of the capability to compute the time derivatives of the DSST short period motion Fourier coefficients via automatic differentiation.https://gitlab.orekit.org/orekit/orekit/-/issues/804Provide Earth Orientation Parameters from SINEX files2021-07-01T08:45:06ZBryan CazabonneProvide Earth Orientation Parameters from SINEX filesUsually, when performing precise orbit determination (i.e. GNSS and laser ranging based) analysis center provide the estimated Earth Orientation Parameters inside the SINEX file used for station positions. It can be a good improvement if...Usually, when performing precise orbit determination (i.e. GNSS and laser ranging based) analysis center provide the estimated Earth Orientation Parameters inside the SINEX file used for station positions. It can be a good improvement if the `SinexLoader` of Orekit can also implements the `EOPHistoryLoader` interface to provide EOP.https://gitlab.orekit.org/orekit/orekit/-/issues/800Revert the design choice for the existing FootprintOverlapDetector2021-06-29T11:57:04Zjeje22Revert the design choice for the existing FootprintOverlapDetectorThis issue is related to the following discussion https://forum.orekit.org/t/created-sphericalpolygonset-gives-nullpointerexception-with-footprintoverlapdetectorh/1251/8This issue is related to the following discussion https://forum.orekit.org/t/created-sphericalpolygonset-gives-nullpointerexception-with-footprintoverlapdetectorh/1251/8https://gitlab.orekit.org/orekit/orekit/-/issues/791Add ability to truncate IntegratedEphemeris2021-06-14T16:02:17ZEvan WardAdd ability to truncate IntegratedEphemerisThis is a memory optimization, particularly useful when `IntegratedEphemeris` is used with `AggregateBoundedPropagator` and there are overlapping intervals. The data in the overlapping intervals will never be used and is therefore a memo...This is a memory optimization, particularly useful when `IntegratedEphemeris` is used with `AggregateBoundedPropagator` and there are overlapping intervals. The data in the overlapping intervals will never be used and is therefore a memory leak of sorts.
This could be implemented within the existing API, probably within a minor release, by specializing `getGeneratedEphemeris()` to return a new copy of `IntegratedEphemeris` with only the data needed for the new time interval. The when the original `IntegratedEphemeris` is garbage collected the unneeded data could be garbage collected as well. Draw back is that the copy operation would be slower and use more memory when not needed.
Another approach is leaving the existing `getGeneratedEphemeris()` as is and to add a dedicated `public IntegratedEphemeris copy(AbsoluteDate start, AbsoluteDate end) {...}` method. Would need to change the return type of `AbstractIntegratedPropagator.getGeneratedEphemeris()` from `BoundedPropagator` to `IntegratedEphemeris`. Also could be added in a minor release.
Currently `IntegratedEphemeris` is immutable, don't think we want to change that.https://gitlab.orekit.org/orekit/orekit/-/issues/790Add writing of velocity record in CPF file writer2021-06-14T09:51:47ZBryan CazabonneAdd writing of velocity record in CPF file writerCurrently, only satellite position vector can be written in a CPF file. However, according to ILRS format, satellite's velocity vector can also be written in the file. Since the method `writeEphemerisLine` in `StreamingCpfWriter` has a `...Currently, only satellite position vector can be written in a CPF file. However, according to ILRS format, satellite's velocity vector can also be written in the file. Since the method `writeEphemerisLine` in `StreamingCpfWriter` has a `TimeStampedPVCoordinates` parameter in input, the change is straightforward.https://gitlab.orekit.org/orekit/orekit/-/issues/787Eckstein-Hechler can work with CircularOrbit2021-05-20T08:37:31ZNicolas FialtonEckstein-Hechler can work with CircularOrbitEckstein-Hechler propagator can work with CircularOrbit instead of CartesianOrbit because since 2017 we can get the circular coordinates derivatives and not only the cartesian coordinate derivatives.
This development could solve some iss...Eckstein-Hechler propagator can work with CircularOrbit instead of CartesianOrbit because since 2017 we can get the circular coordinates derivatives and not only the cartesian coordinate derivatives.
This development could solve some issue in EcksteinHechlerBatchLSEstimatorTest and EcksteinHechlerKalmanEstimatorTest currently in progress and could improve the understanding of the model as the original paper only use the Circular coordinates.Nicolas FialtonNicolas Fialtonhttps://gitlab.orekit.org/orekit/orekit/-/issues/786KeplerianOrbit has NaNs when constructed from PV computed from KeplerianOrbit2021-05-19T14:40:52ZEvan WardKeplerianOrbit has NaNs when constructed from PV computed from KeplerianOrbitA colleague, Kendra Hale, tried creating a copy of a `KeplerianOrbit` using the TSPVC constructor and it fails to build a usable orbit. Seems to be a side effect of the code that guesses whether the user would like rates with their Keple...A colleague, Kendra Hale, tried creating a copy of a `KeplerianOrbit` using the TSPVC constructor and it fails to build a usable orbit. Seems to be a side effect of the code that guesses whether the user would like rates with their Keplerian elements. In this case `hasNonKeplerianAcceleration()` returns true when the acceleration is the Keplerian acceleration.
Failing test case:
```java
@Test
public void testKeplerianToPvToKeplerian() {
// setup
Frame eci = FramesFactory.getGCRF();
AbsoluteDate date = AbsoluteDate.ARBITRARY_EPOCH;
double mu = Constants.EGM96_EARTH_MU;
Orbit orbit = new KeplerianOrbit(6878e3, 0, 0, 0, 0, 0,
PositionAngle.TRUE, eci, date, mu);
// action
KeplerianOrbit broken = new KeplerianOrbit(orbit.getPVCoordinates(), eci, mu);
// verify
assertThat(orbit.shiftedBy(1), CoreMatchers.is(broken.shiftedBy(1)));
}
```
Output is:
```
java.lang.AssertionError:
Expected: is <Keplerian parameters: {a: NaN; e: NaN; i: NaN; pa: NaN; raan: NaN; v: NaN;}>
but: was <Keplerian parameters: {a: 6878000.0; e: 0.0; i: 0.0; pa: 0.0; raan: 0.0; v: 0.06341591497145493;}>
```https://gitlab.orekit.org/orekit/orekit/-/issues/784Compute derivatives of tabulated functions with respect to the interpolation ...2021-05-07T12:11:28ZBryan CazabonneCompute derivatives of tabulated functions with respect to the interpolation parameterMore details are given in #587More details are given in #587https://gitlab.orekit.org/orekit/orekit/-/issues/779Default handler for PositionAngleDetector has improperly defined behavior on ...2021-04-30T09:31:45ZBayden PritchardDefault handler for PositionAngleDetector has improperly defined behavior on EventOccurredThe default handler for PositionAngleDetector has default behavior to `StopOnIncreasing`, where it should issue the Stop on _all_ events, ie. `StopOnEvent`.
Noticed via inconsistent triggering/detection of events when using this detecto...The default handler for PositionAngleDetector has default behavior to `StopOnIncreasing`, where it should issue the Stop on _all_ events, ie. `StopOnEvent`.
Noticed via inconsistent triggering/detection of events when using this detector to find mean-anomaly crossings in orbits. See [forum post here](https://forum.orekit.org/t/eventdetector-not-triggering-upon-first-occurrence-of-condition/1185).https://gitlab.orekit.org/orekit/orekit/-/issues/778Update pole definitions to IAU WGCCRE 2015 report2021-04-30T09:30:27ZJorge M.G.Update pole definitions to IAU WGCCRE 2015 reportHi all,
I just noticed that the current Orekit's [predefined IAU poles](https://gitlab.orekit.org/orekit/orekit/-/blob/develop/src/main/java/org/orekit/bodies/PredefinedIAUPoles.java) are making use of the numerical values from the [IAU...Hi all,
I just noticed that the current Orekit's [predefined IAU poles](https://gitlab.orekit.org/orekit/orekit/-/blob/develop/src/main/java/org/orekit/bodies/PredefinedIAUPoles.java) are making use of the numerical values from the [IAU WGCCRE 2009 report](https://astropedia.astrogeology.usgs.gov/download/Docs/WGCCRE/WGCCRE2009reprint.pdf), although a more modern version of this document is available, see [IAU WGCCRE 2015 report](https://astropedia.astrogeology.usgs.gov/download/Docs/WGCCRE/WGCCRE2015reprint.pdf)
Do you think it might be interesting to update the different values within [PredefinedIAUPoles.javaj](https://gitlab.orekit.org/orekit/orekit/-/blob/develop/src/main/java/org/orekit/bodies/PredefinedIAUPoles.java) or is there any reason not to do so?
Best regards!https://gitlab.orekit.org/orekit/orekit/-/issues/777Conjunction Data Messages2021-04-13T17:36:01ZEvan WardConjunction Data MessagesMostly a wish list item to round out Orekit's coverage of CCSDS formats. Conjunction Data Messages describe a close approach between two objects. Hopefully it will be relatively easy to build off of Luc's work in #474.
https://public.cc...Mostly a wish list item to round out Orekit's coverage of CCSDS formats. Conjunction Data Messages describe a close approach between two objects. Hopefully it will be relatively easy to build off of Luc's work in #474.
https://public.ccsds.org/Pubs/508x0b1e2c1.pdfhttps://gitlab.orekit.org/orekit/orekit/-/issues/771Test EventDetection with tolerance > integrator step size2021-04-30T09:30:02ZEvan WardTest EventDetection with tolerance > integrator step sizeif the tests fail to detect events decide if the fix is improved documentation or code changes. The lines in `EventState.evaluateStep(...)` that make me suspicious are:
```
if (FastMath.abs(dt) < detector.getThreshold()) {
...if the tests fail to detect events decide if the fix is improved documentation or code changes. The lines in `EventState.evaluateStep(...)` that make me suspicious are:
```
if (FastMath.abs(dt) < detector.getThreshold()) {
// we cannot do anything on such a small step, don't trigger any events
return false;
}
```
It seems then that events could be missed even if the g function was positive/negative for longer than `maxCheck` across several integrator steps.https://gitlab.orekit.org/orekit/orekit/-/issues/770Refactoring of supported RINEX files2021-08-10T07:03:50ZBryan CazabonneRefactoring of supported RINEX filesSince the implementation of the first RINEX format in Orekit (i.e. RINEX observation files represented by RinexHeader and RinexLoader classes), more and more other RINEX formats were added in Orekit: clock files and navigation files for ...Since the implementation of the first RINEX format in Orekit (i.e. RINEX observation files represented by RinexHeader and RinexLoader classes), more and more other RINEX formats were added in Orekit: clock files and navigation files for instance.
Furthermore, RINEX formats are part of the more generic IGS standards regrouping RINEX, ANTEX, and SINEX. All this formats are also supported in Orekit.
Many keys and elements are common between the formats. However, the factorization of these common elements has never been done in Orekit. It could be very useful to take advantage of these commun elements by implementing a more generic and factorized architecture of the RINEX and IGS standard.
Here some idea:
- Create `ObservationFileHeader`, `ClockFileHeader`, and `NavigationFileHeader` classes containing the specific data in the different RINEX formats.
- Create `RinexFileHeader` class containing the common data in the header of the RINEX format.
- Create `IgsFileHeader` class containing the common data in the header of RINEX, ANTEX, and SINEX files.
- Create `RinexParser` class containing the common parsing methods of RINEX formats
- Create `IgsParser` class containing the common parsing methods of IGS standard.
- Rename `RinexLoader` class in `ObservationFileparser` class.
- Create `ObservationFile` class to contain the specific date of RINEX observation files.
- Create `IgsFile` class to contain the common data in IGS files.
- Create `RinexFile` class to contain the common data in Rinex files.
This implementation can be inspired by what is currently done in issue- #474 branch for the factorization of common data.12.0https://gitlab.orekit.org/orekit/orekit/-/issues/767Feature Request: Add a generic `TwoVectorAttitudeProvider` interface2021-04-30T09:29:14ZGowtham SivaramanFeature Request: Add a generic `TwoVectorAttitudeProvider` interfaceIt can be interesting to work out a generic interface, say `TwoVectorAttitudeProvider`, where in we need two vectors or vector providers (like PVCoordinatesProvider), one for pointing and other for phasing.
This will make sure the `Cele...It can be interesting to work out a generic interface, say `TwoVectorAttitudeProvider`, where in we need two vectors or vector providers (like PVCoordinatesProvider), one for pointing and other for phasing.
This will make sure the `CelestialBodyPointed`, `NadirPointing` and `YawSteering` etc. can all implement this particular interface and simplify the architecture of Attitude computation in a whole.
More details on this [here](https://forum.orekit.org/t/sun-pointing-attitude-mode-with-nadir-constraint/1094/5)https://gitlab.orekit.org/orekit/orekit/-/issues/765Implement Geoid.projectToGround2021-03-09T21:01:33ZEvan WardImplement Geoid.projectToGroundImplement `Geoid.projectToGround(TSPVC, ...)`. The method currently throws an `UnsupportedOperationException`. Before that the JavaDoc for `BodyShape.projectToGround(TSPVC, ...)` should be clarified as what projection, if any, is perform...Implement `Geoid.projectToGround(TSPVC, ...)`. The method currently throws an `UnsupportedOperationException`. Before that the JavaDoc for `BodyShape.projectToGround(TSPVC, ...)` should be clarified as what projection, if any, is performed for the velocity and acceleration.https://gitlab.orekit.org/orekit/orekit/-/issues/759Add support for JB2008 (atmosphere model) input data2021-08-10T07:21:12ZBayden PritchardAdd support for JB2008 (atmosphere model) input dataCurrently the JB2008InputParameters interface is not implementedCurrently the JB2008InputParameters interface is not implemented11.1https://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 computa...[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-08-10T07:20:53ZBryan 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.1