Orekit issueshttps://gitlab.orekit.org/groups/orekit/-/issues2020-05-14T13:42:55Zhttps://gitlab.orekit.org/orekit/orekit/-/issues/590DateTimeComponents.toString() incorrect during leap second2020-05-14T13:42:55ZEvan WardDateTimeComponents.toString() incorrect during leap second```java
TimeScale utc = TimeScalesFactory.getUTC();
AbsoluteDate d = new AbsoluteDate("2017-01-01", utc).shiftedBy(-0.5);
DateTimeComponents dtc = d.getComponents(utc)
// the assert below fails, values are
// 2016-12-31T23:59:60.568 and 2017-01-01T00:00:00.000
Assert.assertEquals(d.toString(), dtc.toString());
// this passes, indicating the issue is in DateTimeComponents
Assert.assertEquals(d.toString(), dtc.getDate().toString() + "T" + dtc.getTime());
``````java
TimeScale utc = TimeScalesFactory.getUTC();
AbsoluteDate d = new AbsoluteDate("2017-01-01", utc).shiftedBy(-0.5);
DateTimeComponents dtc = d.getComponents(utc)
// the assert below fails, values are
// 2016-12-31T23:59:60.568 and 2017-01-01T00:00:00.000
Assert.assertEquals(d.toString(), dtc.toString());
// this passes, indicating the issue is in DateTimeComponents
Assert.assertEquals(d.toString(), dtc.getDate().toString() + "T" + dtc.getTime());
```11.0https://gitlab.orekit.org/orekit/orekit/-/issues/587DerivativeStructures derivatives diverge for low altitudes (drag + srp)2021-01-12T10:19:15ZMauro ViturroDerivativeStructures derivatives diverge for low altitudes (drag + srp)Resulting from [this](https://forum.orekit.org/t/derivativestructures-with-adaptivestepsizeintegrator-for-reentry/532/2) discussion. Derivatives of the PV variables with respect to their initial values, when obtained through a PartialDifferentialEquations object vastly differ from those obtained using DerivativeStructures objects (the latter diverge) when conditions are as follows:
- Low altitude (6550km initial altitude, nearly 0 eccentricity).
- Drag force with a HarrisPriester atmosphere model is on.
(- SolarRadiationPressure force model is also on, but divergence is also there without it.)
- The integrators used for both computations are DormandPrince853 both in field and non-field versions.
This small piece of code can be used as a quick reference for identifying the problem.
[FieldBugTest.java](/uploads/4e9f20817bad74de134df4fd89c89bb0/FieldBugTest.java)Resulting from [this](https://forum.orekit.org/t/derivativestructures-with-adaptivestepsizeintegrator-for-reentry/532/2) discussion. Derivatives of the PV variables with respect to their initial values, when obtained through a PartialDifferentialEquations object vastly differ from those obtained using DerivativeStructures objects (the latter diverge) when conditions are as follows:
- Low altitude (6550km initial altitude, nearly 0 eccentricity).
- Drag force with a HarrisPriester atmosphere model is on.
(- SolarRadiationPressure force model is also on, but divergence is also there without it.)
- The integrators used for both computations are DormandPrince853 both in field and non-field versions.
This small piece of code can be used as a quick reference for identifying the problem.
[FieldBugTest.java](/uploads/4e9f20817bad74de134df4fd89c89bb0/FieldBugTest.java)11.0https://gitlab.orekit.org/orekit/orekit/-/issues/586Set Propagator's default attitude provider to be aligned with Propagator.getF...2019-08-13T14:45:44ZEvan WardSet Propagator's default attitude provider to be aligned with Propagator.getFrame()For performance reasons when possible the default attitude provider should be aligned with the Propagator's Frame. This avoid computing frame transformations to/from EME2000 when the user isn't interested in the attitude. Some performance profiling on my machine has shown that for the `TLEPropagator` computing the attitude is about as expensive as computing the position and velocity. In other words, there is a factor of two slow down if the default attitude law is not changed and the user doesn't need an EME2000 aligned attitude. I think most analytical propagators would benefit from changing the default attitude provider including `EphemerisSegmentPropagator` and `Ephemeris`. Since this changes semantics and may subtly break some applications I think we should wait until the next major release to make the change. I can add a `FrameAligned` `AttitudeProvider` now.
Workaround until this is fully implemented:
```java
TLEPropagator p = ...;
Frame teme = FramesFactory.getTEME()
// with new FrameAligned class
p.setAttitudeProvider(new FrameAligned(teme));
// with existing classes, but not as fast
p.setAttitudeProvider(new FixedRate(epoch, teme, AngularCoordinates.IDENTITY));
```For performance reasons when possible the default attitude provider should be aligned with the Propagator's Frame. This avoid computing frame transformations to/from EME2000 when the user isn't interested in the attitude. Some performance profiling on my machine has shown that for the `TLEPropagator` computing the attitude is about as expensive as computing the position and velocity. In other words, there is a factor of two slow down if the default attitude law is not changed and the user doesn't need an EME2000 aligned attitude. I think most analytical propagators would benefit from changing the default attitude provider including `EphemerisSegmentPropagator` and `Ephemeris`. Since this changes semantics and may subtly break some applications I think we should wait until the next major release to make the change. I can add a `FrameAligned` `AttitudeProvider` now.
Workaround until this is fully implemented:
```java
TLEPropagator p = ...;
Frame teme = FramesFactory.getTEME()
// with new FrameAligned class
p.setAttitudeProvider(new FrameAligned(teme));
// with existing classes, but not as fast
p.setAttitudeProvider(new FixedRate(epoch, teme, AngularCoordinates.IDENTITY));
```11.0Evan WardEvan Wardhttps://gitlab.orekit.org/orekit/website-2015/-/issues/3Give visibility to the Python wrapper on the web site2020-02-14T16:02:53ZSébastien Dinotsebastien.dinot@csgroup.euGive visibility to the Python wrapper on the web siteThe Orekit Python wrapper is now very popular, but it is not highlighted on the Orekit website. This needs to be addressed.
Here are some suggestions:
- [x] Mention this wrapper on the home page
- [ ] Add a link to the documentation of the Python wrapper in the main menu
- [ ] Add a link to the Python wrapper archive in the download page
Petrus recently also developed a Python wrapper for Rugged. We must give some visibility to it too.The Orekit Python wrapper is now very popular, but it is not highlighted on the Orekit website. This needs to be addressed.
Here are some suggestions:
- [x] Mention this wrapper on the home page
- [ ] Add a link to the documentation of the Python wrapper in the main menu
- [ ] Add a link to the Python wrapper archive in the download page
Petrus recently also developed a Python wrapper for Rugged. We must give some visibility to it too.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.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.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/576Add weak-time-dependent (WTD) terms in the DSST lunar solar short period motion.2021-01-12T10:22:35ZBryan 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 significantly the results.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.11.1https://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.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.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/555Change ionospheric models API2019-11-14T14:38:08ZBryan CazabonneChange ionospheric models APICurrent API used for the computation of the path delay due to ionospheric effects limits the implementation of new ionospheric models. Current API can be improved by:
* Add `SpacecraftState` information and the possibility to estimate some ionospheric model parameters.
* Add the frequency parameter to limit the number of model initialization.
* Replace `GeodeticPoint`, elevation and azimuth parameters with `TopocentricFrame` parameter.
Old method parameters: `pathDelay(AbsoluteDate date, GeodeticPoint geo, double elevation, double azimuth)`
New method parameters: `pathDelay(SpacecraftState state, TopocentricFrame baseFrame, double frequency, double[] parameters)`Current API used for the computation of the path delay due to ionospheric effects limits the implementation of new ionospheric models. Current API can be improved by:
* Add `SpacecraftState` information and the possibility to estimate some ionospheric model parameters.
* Add the frequency parameter to limit the number of model initialization.
* Replace `GeodeticPoint`, elevation and azimuth parameters with `TopocentricFrame` parameter.
Old method parameters: `pathDelay(AbsoluteDate date, GeodeticPoint geo, double elevation, double azimuth)`
New method parameters: `pathDelay(SpacecraftState state, TopocentricFrame baseFrame, double frequency, double[] parameters)`11.0Bryan CazabonneBryan Cazabonnehttps://gitlab.orekit.org/orekit/orekit/-/issues/537`FIXME` in codes2019-11-15T14:17:03ZHao Peng`FIXME` in codesCurrently 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)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)11.0https://gitlab.orekit.org/orekit/orekit/-/issues/525How to use BatchLSEstimator with GPSPropagator?2020-10-04T09:26:39ZGowtham 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 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.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.11.0https://gitlab.orekit.org/orekit/orekit/-/issues/523Add support for loading RINEX navigation file2021-03-02T10:46:59ZGowtham SivaramanAdd support for loading RINEX navigation fileOrekit (as of v9.3) supports RINEX (measurement/observation files) versions 2.x and 3.x. But the support for loading navigation files (Eg: ftp://cddis.nasa.gov/gnss/data/daily/2019/035/19n/brdc0350.19n.Z) is lacking. The RINEX data format document (ftp://igs.org/pub/data/format/rinex301.pdf
) discusses the format of navigation file broadcasted.
Similar to SEM/YUMA parsers, the support to run GPSPropagator at the end of loading RINEX navigation files can be made available.Orekit (as of v9.3) supports RINEX (measurement/observation files) versions 2.x and 3.x. But the support for loading navigation files (Eg: ftp://cddis.nasa.gov/gnss/data/daily/2019/035/19n/brdc0350.19n.Z) is lacking. The RINEX data format document (ftp://igs.org/pub/data/format/rinex301.pdf
) discusses the format of navigation file broadcasted.
Similar to SEM/YUMA parsers, the support to run GPSPropagator at the end of loading RINEX navigation files can be made available.11.0https://gitlab.orekit.org/orekit/rugged/-/issues/375Make Rugged able to deal with seamless DEM tiles (no ovelapping constraints)2019-01-28T16:30:47ZGuylaine PratMake Rugged able to deal with seamless DEM tiles (no ovelapping constraints)DEM tiles must be overlapping by at least one line/column in all directions.
To avoid user to pre-process their DEM, Rugged must be able to deal with seamless DEM tiles, as well as DEM with overlapping tiles.DEM tiles must be overlapping by at least one line/column in all directions.
To avoid user to pre-process their DEM, Rugged must be able to deal with seamless DEM tiles, as well as DEM with overlapping tiles.Guylaine PratGuylaine Prathttps://gitlab.orekit.org/orekit/rugged/-/issues/242InverseLocation: maybe inappropriate use of coarse threshold in SensorPixelCr...2018-08-07T14:16:21ZGuylaine PratInverseLocation: maybe inappropriate use of coarse threshold in SensorPixelCrossingIn Rugged.inverseLocation method, in the first step to find the mean
plane crossing (method getPlaneCrossing),
the accuracy is set to COARSE\_INVERSE\_LOCATION\_ACCURACY (= 0.01).
In the second step, to find approximately the pixel along the sensor
line, the same accuracy is used.
It may not be sufficient, as for an expected inverse location of (0, 0),
according to the (min, max) lines given,
the SensorPixel found is
- (Line: -2.53e-3, pixel: -7.6e-7) for (minLine = -12046; maxLine
= 10993)
- (Line: -2.79e-7, pixel: -7.6E-7) for (minLine = -29277; maxLine
= 69120)
*(from redmine: issue id 242, created on 2016-05-24)*In Rugged.inverseLocation method, in the first step to find the mean
plane crossing (method getPlaneCrossing),
the accuracy is set to COARSE\_INVERSE\_LOCATION\_ACCURACY (= 0.01).
In the second step, to find approximately the pixel along the sensor
line, the same accuracy is used.
It may not be sufficient, as for an expected inverse location of (0, 0),
according to the (min, max) lines given,
the SensorPixel found is
- (Line: -2.53e-3, pixel: -7.6e-7) for (minLine = -12046; maxLine
= 10993)
- (Line: -2.79e-7, pixel: -7.6E-7) for (minLine = -29277; maxLine
= 69120)
*(from redmine: issue id 242, created on 2016-05-24)*https://gitlab.orekit.org/orekit/rugged/-/issues/186Allow user customization of terrain masking influence in inverse location2018-08-07T14:16:07ZLuc MaisonobeAllow user customization of terrain masking influence in inverse locationInverse location currently ignores terrain masking effect. When the user
specifies
a ground location that in fact would be being some other ground feature
as seen from the
spacecraft (and therefore should not be visible in direct location), the
computation is
done ignoring this effect. This implies that two different ground points
could theoretically
be mapped to the exact same sensor pixel in inverse location, whereas
this pixel location would
be mapped to only one of these ground points in direct location.
The current process is perfectly sound in some image processing chains
when the masking effects
are considered later on in the processing. However, in some cases it
would be interesting for user
to be able to select a different behavior and be warned that the
specified ground point cannot be
seen during this spacecraft pass over the area. There are two
possibilities for this: either an exception
should be thrown or simply a null result could be returned. The second
possibility (null return) seems
more logical for this case, as it is simply equivalent to a "No DATA"
information, its not a logical
error as would be implied by an exception.
*(from redmine: issue id 186, created on 2015-01-13)*Inverse location currently ignores terrain masking effect. When the user
specifies
a ground location that in fact would be being some other ground feature
as seen from the
spacecraft (and therefore should not be visible in direct location), the
computation is
done ignoring this effect. This implies that two different ground points
could theoretically
be mapped to the exact same sensor pixel in inverse location, whereas
this pixel location would
be mapped to only one of these ground points in direct location.
The current process is perfectly sound in some image processing chains
when the masking effects
are considered later on in the processing. However, in some cases it
would be interesting for user
to be able to select a different behavior and be warned that the
specified ground point cannot be
seen during this spacecraft pass over the area. There are two
possibilities for this: either an exception
should be thrown or simply a null result could be returned. The second
possibility (null return) seems
more logical for this case, as it is simply equivalent to a "No DATA"
information, its not a logical
error as would be implied by an exception.
*(from redmine: issue id 186, created on 2015-01-13)*https://gitlab.orekit.org/orekit/orekit/-/issues/475Short circuit BooleanDetector2021-01-12T10:24:14ZEvan 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 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)*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)*11.0https://gitlab.orekit.org/orekit/orekit/-/issues/474Add support for version 3 of CCSDS Orbit Data Messages2021-03-08T17:07:23ZLuc MaisonobeAdd support for version 3 of CCSDS Orbit Data MessagesCCSDS Orbit Data Message will be updated in the near future, with
a new Orbit Comprehensive Message (OCM) in addition to the existing
OPM, OMM and OEM already supported by Orekit.
The update was presented during SpaceOps 2018 conference by David
Berry (see https://arc.aiaa.org/doi/pdf/10.2514/6.2018-2456). The
paper provided a link to the current draft.
We discussed with Dave at the conference and agreed Orekit could
provide one of the prototype implementations for the standard.
*(from redmine: issue id 474, created on 2018-06-04)*CCSDS Orbit Data Message will be updated in the near future, with
a new Orbit Comprehensive Message (OCM) in addition to the existing
OPM, OMM and OEM already supported by Orekit.
The update was presented during SpaceOps 2018 conference by David
Berry (see https://arc.aiaa.org/doi/pdf/10.2514/6.2018-2456). The
paper provided a link to the current draft.
We discussed with Dave at the conference and agreed Orekit could
provide one of the prototype implementations for the standard.
*(from redmine: issue id 474, created on 2018-06-04)*11.0Luc MaisonobeLuc Maisonobehttps://gitlab.orekit.org/orekit/orekit/-/issues/448New ICGEM format with piecewise-linear cofficients for gravity fields is not ...2021-01-12T10:26:30ZLuc MaisonobeNew ICGEM format with piecewise-linear cofficients for gravity fields is not supportedSome recent gravity fields published by ICGEM use a new file format.
A typical example is Eigen 6S2 from
http://icgem.gfz-potsdam.de/tom\_longtime
(the original Eigen 6S format is supported). The file reference a link
to
the format that is broken. However, the file format seems easy to
understand.
The main difference with the previous version (2011) of the file format
is
that the time-dependent coefficients now have associated time spans,
and
several spans can be defined for the same coefficient.
This means the model is not linear plus harmonic, but rather
piecewise-linear
plus harmonics.
The J2 coefficient in the Eigen 6S2 gravity field has 29 different
intervals,
from 1950 to 2050, some intervals being one-year long while others are
several
decades long.
*(from redmine: issue id 448, created on 2018-05-14)*Some recent gravity fields published by ICGEM use a new file format.
A typical example is Eigen 6S2 from
http://icgem.gfz-potsdam.de/tom\_longtime
(the original Eigen 6S format is supported). The file reference a link
to
the format that is broken. However, the file format seems easy to
understand.
The main difference with the previous version (2011) of the file format
is
that the time-dependent coefficients now have associated time spans,
and
several spans can be defined for the same coefficient.
This means the model is not linear plus harmonic, but rather
piecewise-linear
plus harmonics.
The J2 coefficient in the Eigen 6S2 gravity field has 29 different
intervals,
from 1950 to 2050, some intervals being one-year long while others are
several
decades long.
*(from redmine: issue id 448, created on 2018-05-14)*11.1https://gitlab.orekit.org/orekit/orekit/-/issues/403Add a provider generating process noise increasing in time, for better Kalman...2019-11-13T15:15:52ZLuc MaisonobeAdd a provider generating process noise increasing in time, for better Kalman filteringThe Kalman filter implementation in Orekit let the user provide the
process noise
matrix at each prediction step. As of 2018-03-22, the only
implementation of
the ProcessNoiseMatricProvider is ConstantProcessNoise. Users could
implement their
own process noise provider, as complex and as realistic as they want.
It would be interesting to have another implementation in Orekit that is
more realistic
than a constant matrix, and that simulates at least the expansion of the
uncertainty
ellipsoid along track as time without measurements increase.
A first idea would be to have user provide six polynomials representing
the diagonal
elements of the covariance in some Local Orbital Frame (say LVLH for
example). The
polynomial for the along velocity covariance would increase faster than
the polynomial
for the across directions. Then, by pre and post-multiplying by the
rotation matrix
we get from LOFType.rotationFromInertial, we get the dense matri in
inertial frame
we need to return.
This implementation is simple but much more realistic than a constant
matrix, and it
should properly take into account the fact the uncertainty from the
prediction step
is larger when the time between measurements is long than when
measurements occur
frequently.
Finding the polynomials would remain here the responsibility of the
caller. Later on,
we can think about using FieldPropagator on a reference orbit to
estimate these
polynomials during the mission analysis phase prior to operations.
*(from redmine: issue id 403, created on 2018-03-22)*The Kalman filter implementation in Orekit let the user provide the
process noise
matrix at each prediction step. As of 2018-03-22, the only
implementation of
the ProcessNoiseMatricProvider is ConstantProcessNoise. Users could
implement their
own process noise provider, as complex and as realistic as they want.
It would be interesting to have another implementation in Orekit that is
more realistic
than a constant matrix, and that simulates at least the expansion of the
uncertainty
ellipsoid along track as time without measurements increase.
A first idea would be to have user provide six polynomials representing
the diagonal
elements of the covariance in some Local Orbital Frame (say LVLH for
example). The
polynomial for the along velocity covariance would increase faster than
the polynomial
for the across directions. Then, by pre and post-multiplying by the
rotation matrix
we get from LOFType.rotationFromInertial, we get the dense matri in
inertial frame
we need to return.
This implementation is simple but much more realistic than a constant
matrix, and it
should properly take into account the fact the uncertainty from the
prediction step
is larger when the time between measurements is long than when
measurements occur
frequently.
Finding the polynomials would remain here the responsibility of the
caller. Later on,
we can think about using FieldPropagator on a reference orbit to
estimate these
polynomials during the mission analysis phase prior to operations.
*(from redmine: issue id 403, created on 2018-03-22)*https://gitlab.orekit.org/orekit/orekit/-/issues/351PartialDerivativesEquations does not work with non-Cartesian elements2019-11-13T15:24:06ZEvan 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 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)*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)*11.0https://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)*