Orekit issueshttps://gitlab.orekit.org/orekit/orekit/-/issues2019-12-17T13:32:46Zhttps://gitlab.orekit.org/orekit/orekit/-/issues/628Unexpected error with drag during one day numerical integration2019-12-17T13:32:46ZMikael FillastreUnexpected error with drag during one day numerical integrationIn some specific conditions of propagation, the drag models raise an error of altitude too low which is not expected to happen during the one day propagation.
A file is attached to reproduce the problem.
[UnexpectedCrashWithDrag.java](/uploads/fd95043f34fb1781823df4aee8a7a7cc/UnexpectedCrashWithDrag.java)
We found some weird workarounds but that sounds like bad ideas :
- use a fixed step integrator (so far we use a variable step with max step of 100s)
- converting the equinoctial orbit into keplerian orbit before building the spacecraft state (looks like a side effect of the next point)
- update only the anomaly obtained by consecutive conversion of the orbit : equinoctial -> keplerian -> equinoctialIn some specific conditions of propagation, the drag models raise an error of altitude too low which is not expected to happen during the one day propagation.
A file is attached to reproduce the problem.
[UnexpectedCrashWithDrag.java](/uploads/fd95043f34fb1781823df4aee8a7a7cc/UnexpectedCrashWithDrag.java)
We found some weird workarounds but that sounds like bad ideas :
- use a fixed step integrator (so far we use a variable step with max step of 100s)
- converting the equinoctial orbit into keplerian orbit before building the spacecraft state (looks like a side effect of the next point)
- update only the anomaly obtained by consecutive conversion of the orbit : equinoctial -> keplerian -> equinoctialhttps://gitlab.orekit.org/orekit/orekit/-/issues/626remove interface Comparable from IntegerLeastSquareSolution2019-11-29T10:26:30ZLuc Maisonoberemove interface Comparable from IntegerLeastSquareSolutionThe `IntegerLeastSquareSolution` implements `Comparable` but this is
not strictly needed from an API point of view. The sorting order
of various solutions is more related to the algorithm that solves the
integer least squares problem and is generally related only to some
properties (the squared distance to the float solution), not to the
other properties (the integers).
Having `IntegerLeastSquareSolution` implement `Comparable` also implies
implementing `equals` which itself involves implementing `hashCode`.
However, from a logical point of view, these two methods should depend
on all properties, not only on the squared distance, and therefore be
inconsistent with `compareTo`.
It would be more consistent if `IntegerLeastSquareSolution` does not
implement `Comparable` but the solver uses a separate and dedicated
`Comparator` for sorting.
This change is however backward incompatible, so it can be done only
for a major release.The `IntegerLeastSquareSolution` implements `Comparable` but this is
not strictly needed from an API point of view. The sorting order
of various solutions is more related to the algorithm that solves the
integer least squares problem and is generally related only to some
properties (the squared distance to the float solution), not to the
other properties (the integers).
Having `IntegerLeastSquareSolution` implement `Comparable` also implies
implementing `equals` which itself involves implementing `hashCode`.
However, from a logical point of view, these two methods should depend
on all properties, not only on the squared distance, and therefore be
inconsistent with `compareTo`.
It would be more consistent if `IntegerLeastSquareSolution` does not
implement `Comparable` but the solver uses a separate and dedicated
`Comparator` for sorting.
This change is however backward incompatible, so it can be done only
for a major release.11.0https://gitlab.orekit.org/orekit/orekit/-/issues/624Tropospheric delay computation2019-11-20T13:58:12ZBryan CazabonneTropospheric delay computationCurrently, the computation of the tropospheric delay is not enable to take into consideration station dynamic. Indeed, the latitude and the longitude of the station are initialized at the construction of the model. A better implementation is to consider these parameters in the `pathDelay()` method signature, with a `GeodeticPoint` for instance. This new signature could take into consideration important displacement of the station.
This enhancement introduces API changes that shall be performed in a major release of Orekit.Currently, the computation of the tropospheric delay is not enable to take into consideration station dynamic. Indeed, the latitude and the longitude of the station are initialized at the construction of the model. A better implementation is to consider these parameters in the `pathDelay()` method signature, with a `GeodeticPoint` for instance. This new signature could take into consideration important displacement of the station.
This enhancement introduces API changes that shall be performed in a major release of Orekit.11.0https://gitlab.orekit.org/orekit/orekit/-/issues/623Consistent archirecture between Propagators and PropagatorBuilders2019-11-20T12:59:42ZBryan CazabonneConsistent archirecture between Propagators and PropagatorBuildersAs discussed with @MaximeJ, the architecture of propagator builders is different from the architecture of propagators (interface and abstract classes). It can be important to have a consistent architecture between these two functionalities by using the same tree structure.
This modification introduces important API changes. In that respect, we have to wait the next major release of Orekit to perform it.As discussed with @MaximeJ, the architecture of propagator builders is different from the architecture of propagators (interface and abstract classes). It can be important to have a consistent architecture between these two functionalities by using the same tree structure.
This modification introduces important API changes. In that respect, we have to wait the next major release of Orekit to perform it.11.0https://gitlab.orekit.org/orekit/orekit/-/issues/618ClasspathCrawler matches suportedNames against full path of file2020-01-30T16:13:25ZEvan WardClasspathCrawler matches suportedNames against full path of fileOther crawlers only use the last part of the path, i.e. the file name, for matching with the `supportedNames`, but `ClasspathCrawler` uses the whole path. This creates issues when the regular expression include `^`. By default `CelestialBodyFactory` includes a `^` in the supported names regular expression. `ClasspathCrawler` should be updated to just use the last component of the path like `ZipJarCrawler` and the other crawlers do.
A workaround is to use a zip file on the class path since `ZipJarCrawler` does correctly handle file names.Other crawlers only use the last part of the path, i.e. the file name, for matching with the `supportedNames`, but `ClasspathCrawler` uses the whole path. This creates issues when the regular expression include `^`. By default `CelestialBodyFactory` includes a `^` in the supported names regular expression. `ClasspathCrawler` should be updated to just use the last component of the path like `ZipJarCrawler` and the other crawlers do.
A workaround is to use a zip file on the class path since `ZipJarCrawler` does correctly handle file names.11.0https://gitlab.orekit.org/orekit/orekit/-/issues/601getPVInPZ90 method of GLONASSNumericalPropagator should be private2019-09-10T14:52:26ZBryan CazabonnegetPVInPZ90 method of GLONASSNumericalPropagator should be privateThe getPVInPZ90 method of propagation.numerical.GLONASSNumericalPropagator should be private. Indeed since commit @1feaf45f the frame transformation is performed at the end of the propagation inside the propagate method.The getPVInPZ90 method of propagation.numerical.GLONASSNumericalPropagator should be private. Indeed since commit @1feaf45f the frame transformation is performed at the end of the propagation inside the propagate method.11.0Bryan CazabonneBryan Cazabonnehttps://gitlab.orekit.org/orekit/orekit/-/issues/591TimeComponents.toString() round to invalid time2020-05-14T13:42:55ZEvan WardTimeComponents.toString() round to invalid timeThe expression `new TimeComponents(23, 59, 59.9999).toString()` produces the string "23:59:60.000" which contains a second number that is invalid most of the time. Tricky because rolling over would also be wrong and TimeComponents doesn't know how many seconds are valid in this particular minute. Perhaps truncate seconds numbers in [59.999, 60) and [60.999, 61) to avoid producing invalid times.The expression `new TimeComponents(23, 59, 59.9999).toString()` produces the string "23:59:60.000" which contains a second number that is invalid most of the time. Tricky because rolling over would also be wrong and TimeComponents doesn't know how many seconds are valid in this particular minute. Perhaps truncate seconds numbers in [59.999, 60) and [60.999, 61) to avoid producing invalid times.11.0https://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)2019-08-21T08:21:56ZMauro 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)https://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/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/582RinexHeader exception with RINEX 3 file2019-08-21T08:23:21ZDavid SoulardRinexHeader exception with RINEX 3 fileParser does not accept header with the RINEX 3 file : ftp://igs.ensg.ign.fr/pub/igs/data/2016/044/MCHL00AUS_R_20160440000_01D_30S_MO.crx.gzParser does not accept header with the RINEX 3 file : ftp://igs.ensg.ign.fr/pub/igs/data/2016/044/MCHL00AUS_R_20160440000_01D_30S_MO.crx.gzhttps://gitlab.orekit.org/orekit/orekit/-/issues/577rename IRNSS into NAVIC2019-08-21T08:23:49ZLuc Maisonoberename IRNSS into NAVICThe Indian Regional Navigation Satellite System was renamed [NAVIC](https://gssc.esa.int/navipedia/index.php/NAVIC) (NAVigation with Indian Constellation) in 2016.
The enumerates for `Satellitesystem` should be updated and `IRNSSScale` time scale should be renamed.
Such renaming are incompatible change, so they have to wait for next major version: 11.0.The Indian Regional Navigation Satellite System was renamed [NAVIC](https://gssc.esa.int/navipedia/index.php/NAVIC) (NAVigation with Indian Constellation) in 2016.
The enumerates for `Satellitesystem` should be updated and `IRNSSScale` time scale should be renamed.
Such renaming are incompatible change, so they have to wait for next major version: 11.0.11.0https://gitlab.orekit.org/orekit/orekit/-/issues/576Add weak-time-dependent (WTD) terms in the DSST lunar solar short period motion.2019-07-18T13:24:33ZBryan 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.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.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?2019-11-13T15:37:35ZGowtham 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 file2020-05-14T06:20:39ZGowtham 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/orekit/-/issues/487DSST propagator is too slow if drag is added2019-05-10T12:25:11ZYongjun MoonDSST propagator is too slow if drag is addedThis may not be a huge problem, but I'm just curious.
here are conditions I used:
1. propagation for 1 year at a 500 km sun-synchronous orbit
1. a fixed handler step for gathering orbit elements: 1 day
1. gravity: degree 2, order 0
1. third body: sun
1. atmosphere model: DTM2000 with MarshallSolarActivityFutureEstimation
and it took
with DSST: about 1000 s and with
numerical: about 240 s
if without drag, it took
with DSST: about 5 s and with
numerical: about 85 s
Did I do something wrong or it?This may not be a huge problem, but I'm just curious.
here are conditions I used:
1. propagation for 1 year at a 500 km sun-synchronous orbit
1. a fixed handler step for gathering orbit elements: 1 day
1. gravity: degree 2, order 0
1. third body: sun
1. atmosphere model: DTM2000 with MarshallSolarActivityFutureEstimation
and it took
with DSST: about 1000 s and with
numerical: about 240 s
if without drag, it took
with DSST: about 5 s and with
numerical: about 85 s
Did I do something wrong or it?