Orekit issueshttps://gitlab.orekit.org/groups/orekit/-/issues2022-01-14T17:20:38Zhttps://gitlab.orekit.org/orekit/orekit/-/issues/872Force models events detected twice when calling NumericalPropagator.propagato...2022-01-14T17:20:38ZLuc MaisonobeForce models events detected twice when calling NumericalPropagator.propagator(start, target)When propagation is called on a time range (start, target) in an integration-based propagator,
a first propagation is performed from initial start without user-defined events detection, then
user-defined events detectors and step handler...When propagation is called on a time range (start, target) in an integration-based propagator,
a first propagation is performed from initial start without user-defined events detection, then
user-defined events detectors and step handlers are activated and the second part of the propagation
from start to target is performed.
Events handlers from force models however are necessary throughout and properly activated even in the first
propagation.
The detectors from the force models are added twice to the integrator : once before starting the first propagation
and once before starting the second propagation. This results in events being detected twice and handlers being
called twice.11.1Luc MaisonobeLuc Maisonobehttps://gitlab.orekit.org/orekit/orekit-tutorials/-/issues/13[bug] loop reference between observer and estimator2022-02-14T10:17:26ZRongwang Lilirw1984@pku.org.cn[bug] loop reference between observer and estimatorI found a loop reference between `observer` and `estimator`, in the class `org.orekit.tutorials.estimation.common.AbstractOrbitDetermination`, `run` method.
The `estimator` is assigned when an `OrbitDeterminationObserver` is constructed...I found a loop reference between `observer` and `estimator`, in the class `org.orekit.tutorials.estimation.common.AbstractOrbitDetermination`, `run` method.
The `estimator` is assigned when an `OrbitDeterminationObserver` is constructed.
Then this `observer` is set as the estimator's `Observer` by calling the method `setObserver`, and the property `observer` of the `estimator` is assigned by this `observer`.
```
observer.estimator = estimator;
estimator.observer = observer;
```
It would leads to a memory leak for massive batch orbit determinations.
Here's the [topic in forum.](https://forum.orekit.org/t/java-lang-outofmemoryerror-gc-overhead-limit-exceeded/1461/4)11.1https://gitlab.orekit.org/orekit/rugged/-/issues/389add a tileupdater implements about Noaa's GLOBE DEM2021-12-11T12:47:20Zyoungcleadd a tileupdater implements about Noaa's GLOBE DEM
add a tileupdater implements about Noaa's GLOBE DEM which is descript in the doc [globedocumentationmanual.pdf](/uploads/2c7a21aeed9d243952ba5a0a4f973064/globedocumentationmanual.pdf)
in a rugged discussion in the forum, master Luc adv...
add a tileupdater implements about Noaa's GLOBE DEM which is descript in the doc [globedocumentationmanual.pdf](/uploads/2c7a21aeed9d243952ba5a0a4f973064/globedocumentationmanual.pdf)
in a rugged discussion in the forum, master Luc advice me to contribute my codes,i would love to have a try.
i have make a fork and i will try to contribute my implements code to rugged.https://gitlab.orekit.org/orekit/rugged/-/issues/388longitude normalization issue in tiles2022-07-03T18:09:30ZLuc Maisonobelongitude normalization issue in tiles`Tile.cellIntersection` may be called by algorithms with longitudes outside of the [-π; +π] interval.
The API declares the first argument as `GeodeticPoint`, but both Duvenhage algorithm and basic scan algorithm call it with a `Normalize...`Tile.cellIntersection` may be called by algorithms with longitudes outside of the [-π; +π] interval.
The API declares the first argument as `GeodeticPoint`, but both Duvenhage algorithm and basic scan algorithm call it with a `NormalizedGeodeticPoint` which overrides the `getLongitude` method explicitly to allow points outside of the [-π; +π] interval.
This should be made clearer, both in the API and in its documentation.
See [this forum discussion](https://forum.orekit.org/t/rugged-with-dem-has-problem-at-ground-point-lat-90-90-and-lon180-180).3.0Luc MaisonobeLuc Maisonobehttps://gitlab.orekit.org/orekit/orekit/-/issues/871Add atmospheric drag effect for Brouwer-Lyddane model2022-01-03T08:47:01ZBryan CazabonneAdd atmospheric drag effect for Brouwer-Lyddane modelThis issue is related to the discussion during the fix of #869. Warren Phipps's 1992 thesis [1] presents an analytical model for the atmospheric drag that is suited for the Brouwer-Lyddane orbit propagator.
Reference [2] highlights the ...This issue is related to the discussion during the fix of #869. Warren Phipps's 1992 thesis [1] presents an analytical model for the atmospheric drag that is suited for the Brouwer-Lyddane orbit propagator.
Reference [2] highlights the benefits of the drag augmented Brouwer-Lyddane orbit propagator for low Earth satellite orbit determination. Therefore, having this new feature could be interesing.
[1] https://apps.dtic.mil/sti/pdfs/ADA256133.pdf
[2] https://calhoun.nps.edu/bitstream/handle/10945/34052/danielson_comparison.pdf?sequence=1&isAllowed=y11.1Bryan CazabonneBryan Cazabonnehttps://gitlab.orekit.org/orekit/orekit/-/issues/870Performance improvement of Taylor-version TLE/SGP4 propagation by changing `F...2021-12-06T18:50:58ZHao PengPerformance improvement of Taylor-version TLE/SGP4 propagation by changing `FastMath.pow` to a naive power for-loop.After some profilings, I found we can increase greatly the speed of Taylor propagation of TLE sets using SGP4 model. This is helpful in a Monte-Carlo simulation like a particle filter.
I didn't test on other numerical Taylor propagators,...After some profilings, I found we can increase greatly the speed of Taylor propagation of TLE sets using SGP4 model. This is helpful in a Monte-Carlo simulation like a particle filter.
I didn't test on other numerical Taylor propagators, but I GUESS the improvement will be similar.
There may also be other operations that can be optimized for integers but I didn't dig into that much.
Modifications are made to `org.hipparchus.analysis.differentiation.DSCompiler#taylor(double[], int, double...)`, I'm not sure if it's proper to submit an issue here since it's mainly related to TLE propagation...
```
* By replacing the `FastMath.pow` calling by a naive power for-loop, we can increase the speed of DSCompiler greatly.
* In my case: 6.14s --> 1.46s
*
* Specific modifications are:
* Modify `org.hipparchus.analysis.differentiation.DSCompiler#taylor(double[], int, double...)`:
* Change this (line 3316 in commit-ea873ba0df8c7a3705f251a27711ac4696aae84b):
* term *= FastMath.pow(delta[k], orders[k]) /
* CombinatoricsUtils.factorial(orders[k]);
* To:
* for (int jj = orders[k]; jj > 0; jj--) term *= delta[k];
* term /= CombinatoricsUtils.factorial(orders[k]);
```
Attached is an example I used to test the performance.
[Work_05_speedup_taylor.java](/uploads/0fe0cd9bd584bbdd5ee69c5804a7b37f/Work_05_speedup_taylor.java)https://gitlab.orekit.org/orekit/orekit/-/issues/869Brouwer-Lyddane Critical Inclination Fix2022-03-22T12:59:02ZEvan WardBrouwer-Lyddane Critical Inclination FixI saw that the Brouwer-Lyddane model was added in #653 and it is not applicable for critical inclinations. Warren Phipps' 1992 thesis at [1] documents a fix for the critical inclination problem. It does change the behavior of the propaga...I saw that the Brouwer-Lyddane model was added in #653 and it is not applicable for critical inclinations. Warren Phipps' 1992 thesis at [1] documents a fix for the critical inclination problem. It does change the behavior of the propagator near the critical inclination so perhaps it is worthwhile to keep the original Brouwer-Lyddane model as well as one closer to the PPT2 model which is applicable for all near Earth orbits.
[1] https://apps.dtic.mil/sti/pdfs/ADA256133.pdf11.1Bryan CazabonneBryan Cazabonnehttps://gitlab.orekit.org/orekit/orekit/-/issues/868Whitespace characters in headers with CPFWriter2021-12-03T14:25:11ZClément JonglezWhitespace characters in headers with CPFWriterThe CPF V1 I write using Orekit do not pass the quality checks of the ILRS Operation Center online checker: https://edc.dgfi.tum.de/en/tools/cpf_check/ (requires free registration). Only for CPF V1 and not V2 though.
For instance I get ...The CPF V1 I write using Orekit do not pass the quality checks of the ILRS Operation Center online checker: https://edc.dgfi.tum.de/en/tools/cpf_check/ (requires free registration). Only for CPF V1 and not V2 though.
For instance I get the following errors:
> H1 CPF 1 DLR 2021 11 10 15 8141 tubin
> → EH1001 in line 1: The pattern in record H1 is wrong.
> H2 2105922 6208 48900 2021 11 10 13 1 0 2021 11 17 13 1 0 60 1 1 0 0 0
> → EH2001 in line 2: The pattern in record H2 is wrong.
The error messages are explained in https://edc.dgfi.tum.de/en/oc/cpf/
I narrowed down the issue to whitespaces. It seems that in version 1 of the CPF format, the header fields have fixed widths, see:
* Comment 5 at page 23 of the CPF V1 format document: https://ilrs.gsfc.nasa.gov/docs/2006/cpf_1.01.pdf
* The online documentation mentions the column number of all fields for the [V1 format](https://edc.dgfi.tum.de/en/oc/cpf/) only.
* This is not the case anymore for the [V2 format](https://edc.dgfi.tum.de/en/oc/cpf/v2/) which seems to tolerate any position and length, as long as the fields are separated by one whitespace
This would involve the following changes for the H1 header:
* Leaving one additional whitespace between Format Version and Ephemeris Source (jumps from column 9 to column 12)
* Leaving one additional whitespace between Hour of ephemeris production and Ephemeris sequence number (jumps from column 28 to column 31)
* Writing 10 whitespaces at the end of H1 to make up for the missing notes field.
For H2, this requires not writing a whitespace at the end of the line, which the Orekit CPFWriter seems to do for every line.
Attached is a sample CPF V1 file: https://forum.orekit.org/uploads/short-url/4OAbwJmpJbUz7SsByUNEWqVvVPl.dlr11.1Bryan CazabonneBryan Cazabonnehttps://gitlab.orekit.org/orekit/orekit/-/issues/867SinexLoader doesn’t handle multiple historical eccentricities for a same station2021-12-08T08:39:01ZClément JonglezSinexLoader doesn’t handle multiple historical eccentricities for a same stationWhen reading the eccentricities file for ILRS stations (https://ilrs.gsfc.nasa.gov/network/site_procedures/eccentricity.html), I realized that Orekit does not support multiple eccentricity entries for a same station.
This is used in ILR...When reading the eccentricities file for ILRS stations (https://ilrs.gsfc.nasa.gov/network/site_procedures/eccentricity.html), I realized that Orekit does not support multiple eccentricity entries for a same station.
This is used in ILRS stations to indicate the historical detector positions in case it was moved or in case a new survey provides a better estimation of the detector position. For instance for the Yarragadee station (7090), there are 18 entries with each a validity time interval, see `ecc_xyz.snx` lines 888 to 905.
Looking at the source code in `SinexLoader.java` from line 232, Orekit's behaviour is the following:
* Set the validity time interval of the `Station` object based on the first entry found for this station (for Yarragadee, it gives `1979-07-01T00:00:00.000Z` to `1983-07-26T23:59:58.000Z`)
* Set the eccentricities based on the last entry found for this station (for Yarragadee, it gives `[-1.2073; 2.5034; -1.5509]`)
A possible fix could be:
* Set the validity time interval of the `Station` object from the start time of the first segment until the end time of the last segment found for this station
* Store all the historical eccentricity data in a `TimeSpanMap`
* Add a method `Station::getEccentricities(AbsoluteDate date)` to return the eccentricity value corresponding to the time input by the user
* To not break existing code, maybe the method `Station::getEccentricities()` could be kept and could return the latest eccentricity value11.1https://gitlab.orekit.org/orekit/orekit/-/issues/866Confusing name for the class implementing sequential least squares2021-12-17T08:36:26ZRomain SerraConfusing name for the class implementing sequential least squaresThe current name of the class SequentialBatchLSEstimator is confusing as this is a sequential least square estimator and not a batch one. Thus the word "Batch" should be removed for clarity.The current name of the class SequentialBatchLSEstimator is confusing as this is a sequential least square estimator and not a batch one. Thus the word "Batch" should be removed for clarity.https://gitlab.orekit.org/orekit/orekit/-/issues/865Compute Jacobians with respect to maneuvers start and stop dates2022-09-16T14:13:07ZLuc MaisonobeCompute Jacobians with respect to maneuvers start and stop datesThe maneuvers models allow to compute partial derivatives with respect to thrust,
flow rate or multiplicative coefficients, but not start and stop dates.
This would be interesting as it allows for example to optimize maneuvers, retrieve...The maneuvers models allow to compute partial derivatives with respect to thrust,
flow rate or multiplicative coefficients, but not start and stop dates.
This would be interesting as it allows for example to optimize maneuvers, retrieve
maneuvers parameters in orbit determination, or calibrate maneuvers when spurious
pulses can be triggered by AOCS in some modes.11.1Luc MaisonobeLuc Maisonobehttps://gitlab.orekit.org/orekit/orekit/-/issues/864[BUG] BStar estimation in TLEPropagator2021-12-03T10:48:37ZRongwang Lilirw1984@pku.org.cn[BUG] BStar estimation in TLEPropagatorWhen using `TLEPropagator` as the `Propagator` to do an orbit determination, if `BStar` is selected to be estimated, it would raise the following exception:
```
java.lang.ArrayIndexOutOfBoundsException: 6
at org.orekit.propagation.analy...When using `TLEPropagator` as the `Propagator` to do an orbit determination, if `BStar` is selected to be estimated, it would raise the following exception:
```
java.lang.ArrayIndexOutOfBoundsException: 6
at org.orekit.propagation.analytical.tle.TLEJacobiansMapper.analyticalDerivatives(TLEJacobiansMapper.java:178)
at org.orekit.estimation.leastsquares.AbstractBatchLSModel.fetchEvaluatedMeasurement(AbstractBatchLSModel.java:390)
at org.orekit.estimation.leastsquares.MeasurementHandler.handleStep(MeasurementHandler.java:94)
at org.orekit.propagation.PropagatorsParallelizer$SinglePropagatorHandler.handleStep(PropagatorsParallelizer.java:259)
```
@bryan has found that, in `resetInitialState()` method of the `TLEPropagator`, there is a missing step to set `BStar` to be estimated for the new TLE if `BStar` is estimated.
It fixed this bug.
```
public void resetInitialState(final SpacecraftState state) {
super.resetInitialState(state);
super.setStartDate(state.getDate());
final TLE newTLE = TLE.stateToTLE(state, tle, utc, teme);
if (tle.getParametersDrivers().get(0).isSelected()) {
newTLE.getParametersDrivers().get(0).setSelected(true);
}
this.tle = newTLE;
initializeCommons();
sxpInitialize();
}
```
See forum [here](https://forum.orekit.org/t/failure-of-tleorbitdeterminationtest/1459)11.1Bryan CazabonneBryan Cazabonnehttps://gitlab.orekit.org/orekit/orekit/-/issues/863PropagatorsParallelizer has side effects on underlying propagators2023-07-21T11:49:30ZLuc MaisonobePropagatorsParallelizer has side effects on underlying propagators`PropagatorsParallelizer` is intended to run propagators without the underlying propagators noticing they are managed from outside. It sometimes fails to be transparent enough, which introduces difficult bugs.
In order to know which pro...`PropagatorsParallelizer` is intended to run propagators without the underlying propagators noticing they are managed from outside. It sometimes fails to be transparent enough, which introduces difficult bugs.
In order to know which propagator should run and which should be blocked, `PropagatorsParallelizer` calls the propagators interpolators, but these interpolators may be used by the raw propagator itself, so they are really called for multiple threads.
The first problem is that when propagators interpolators are evaluated, they do some regular interpolation and then they add the various additional states. Up to version 11.0.2, it involved static states and states manages by AdditionProviders, and as part of solving issue #856, it also involves integrable states. These states call user-defined callbacks, and these callbacks may not behave properly in multi-thread environment.
The second problem is that the interpolators `restrictStep` method is called from both `PropagatorsParallelizer` and the propagator (for example when handling events), and here again this does not work well in multi-thread contexts.
This is a difficult problem.https://gitlab.orekit.org/orekit/orekit/-/issues/862PropagatorParallelizer should allow individual step handlers in the propagators2021-12-03T08:03:27ZLuc MaisonobePropagatorParallelizer should allow individual step handlers in the propagatorsSince 11.0, propagators support multiple step handlers at once.
This could be used to preserve the step handlers in individual propagators handles by a global `PropagatorParallelizer`
even when this global parallelizer inserts its own st...Since 11.0, propagators support multiple step handlers at once.
This could be used to preserve the step handlers in individual propagators handles by a global `PropagatorParallelizer`
even when this global parallelizer inserts its own step handler11.1Luc MaisonobeLuc Maisonobehttps://gitlab.orekit.org/orekit/orekit/-/issues/861Replace uses of Math by FastMath in NtripClient2021-12-03T09:45:19ZBryan CazabonneReplace uses of Math by FastMath in NtripClientCurrently, `setFix()` method of `NtripClient` class uses Math to perform some computations. They must be replaced by `FastMath`.Currently, `setFix()` method of `NtripClient` class uses Math to perform some computations. They must be replaced by `FastMath`.11.1Bryan CazabonneBryan Cazabonnehttps://gitlab.orekit.org/orekit/orekit/-/issues/860Add Support for Loading Rinex 3.052023-04-16T16:41:08ZthechrishumphreyAdd Support for Loading Rinex 3.05Rinex v3.05 was [published ](https://files.igs.org/pub/data/format/rinex305.pdf) on 1st December 2020, so `org.orekit.gnss.RinexObservationLoader` should be updated to support v3.05.Rinex v3.05 was [published ](https://files.igs.org/pub/data/format/rinex305.pdf) on 1st December 2020, so `org.orekit.gnss.RinexObservationLoader` should be updated to support v3.05.12.0https://gitlab.orekit.org/orekit/orekit/-/issues/859stateToTLE() call from FiniteDifferencePropagatorConverter.convert() fails to...2023-08-23T20:33:14ZEmmanuel PapanagiotoustateToTLE() call from FiniteDifferencePropagatorConverter.convert() fails to convergeHello, I have experienced the following issue in Orekit 11.0. I have also provided a fix that worked for me.
When trying to create a fitted TLE (using FiniteDifferencePropagatorConverter) to a sample of measurements from an estimated pr...Hello, I have experienced the following issue in Orekit 11.0. I have also provided a fix that worked for me.
When trying to create a fitted TLE (using FiniteDifferencePropagatorConverter) to a sample of measurements from an estimated propagator, the convert() method of the fitter will eventually call stateToTLE() with a hardcoded number of iterations and convergence threshold.
More specifically, a FiniteDifferencePropagatorConverter that is configured with a TLEPropagatorBuilder will eventually invoke method stateToTLE(), when the fitter's convert() method is called.
I have provided a suggested fix, which requires modifications to the TLEPropagatorBuilder.class file. The attached file has resovled the above issue for me. The fix involves the addition of two constructors for the TLEPropagatorBuilder, so that the stateToTLE() convergence threshold and number of iterations is exposed during the fitter configuration. Having done this, and after providing more "loose" convergence criteria, I was able to get the stateToTLE() to converge and provide a very good TLE.
Thank you!
Emmanuel
[TLEPropagatorBuilder.java](/uploads/27744cb0972e0cad56afc36505f3b6b2/TLEPropagatorBuilder.java)12.0Bryan CazabonneBryan Cazabonnehttps://gitlab.orekit.org/orekit/orekit/-/issues/858TLES velocity not derivative of position2023-09-17T09:30:07ZEvan WardTLES velocity not derivative of positionFor this TLES for a GEO satellite after an ascending node the z velocity has the wrong sign.
```
1 28626U 05008A 19222.84791105 -.00000224 +00000-0 +00000-0 0 9997
2 28626 000.0058 356.1159 0000414 097.2736 085.7607 01.00271612017542...For this TLES for a GEO satellite after an ascending node the z velocity has the wrong sign.
```
1 28626U 05008A 19222.84791105 -.00000224 +00000-0 +00000-0 0 9997
2 28626 000.0058 356.1159 0000414 097.2736 085.7607 01.00271612017542
```
Here is the output from a Orekit program to print the position z coordinate, velocity z coordinate, and velocity computed by finite difference of the position:
```
time past epoch (min): 5319.50809 z: -1.308712 vz: 2.276642e-04 finite diff vz: NaN
time past epoch (min): 5320.50809 z: -0.770904 vz: 1.357177e-04 finite diff vz: 8.963475e-03
time past epoch (min): 5321.50809 z: -0.243799 vz: 4.344089e-05 finite diff vz: 8.785075e-03
time past epoch (min): 5322.50809 z: 0.272573 vz: -4.916140e-05 finite diff vz: 8.606193e-03
time past epoch (min): 5323.50809 z: 0.778183 vz: -1.420842e-04 finite diff vz: 8.426837e-03
time past epoch (min): 5324.50809 z: 1.273003 vz: -2.353224e-04 finite diff vz: 8.247012e-03
time past epoch (min): 5325.50809 z: 1.757007 vz: -3.288711e-04 finite diff vz: 8.066724e-03
time past epoch (min): 5326.50809 z: 2.230166 vz: -4.227252e-04 finite diff vz: 7.885982e-03
```
Clearly `vz` has the wrong sign after the node and the actual z velocity is relatively constant. Here is the code that produces the above output:
```java
@Test
public void testTlesVz() {
TLE tle = new TLE(
"1 28626U 05008A 19222.84791105 -.00000224 +00000-0 +00000-0 0 9997",
"2 28626 000.0058 356.1159 0000414 097.2736 085.7607 01.00271612017542");
double step = 60;
AbsoluteDate start = new AbsoluteDate("2019-226", tle.getUtc())
.shiftedBy(0.5430555555555555 * 86400) // approx time of issue
.shiftedBy(-90); // back up a bit
AbsoluteDate end = start.shiftedBy(7 * 60);
System.out.println(start.toStringRfc3339(tle.getUtc()));
TLEPropagator propagator = TLEPropagator.selectExtrapolator(tle);
Frame teme = propagator.getFrame();
propagator.setStepHandler(step, new OrekitFixedStepHandler() {
TimeStampedPVCoordinates last = null;
@Override
public void handleStep(SpacecraftState s) {
TimeStampedPVCoordinates pv = s.getPVCoordinates(teme);
final double z = pv.getPosition().getZ();
final double vz = pv.getVelocity().getZ();
double vzd = Double.NaN;
if (last != null) {
vzd = (z - last.getPosition().getZ()) / pv.getDate().durationFrom(last.getDate());
}
final double minutesPastEpoch = s.getDate().durationFrom(tle.getDate()) / 60;
System.out.format(
"time past epoch (min): %11.5f z: %9.6f vz: %11.6e finite diff vz: %11.6e\n",
minutesPastEpoch, z, vz, vzd);
last = pv;
}
});
propagator.propagate(start, end);
}
```https://gitlab.orekit.org/orekit/orekit/-/issues/857Tesselation sometime fails for small regions at high latitude2023-03-27T15:35:16ZLuc MaisonobeTesselation sometime fails for small regions at high latitudeThe fix for critical issue #792 was not sufficient.
In very rare case, and unfortunately cases difficult to reproduce (I am currently not able to them at all),
ellipsoid tesselation fails at high latitude.
Tesselation works by seeding a ...The fix for critical issue #792 was not sufficient.
In very rare case, and unfortunately cases difficult to reproduce (I am currently not able to them at all),
ellipsoid tesselation fails at high latitude.
Tesselation works by seeding a mesh with a single node arbitrarily extracted from the region, then expanding the mesh by looking at neighboring points until the two following conditions are met:
1) all neighbors are outside of the zone
2) there are no peaks in the region that escapes between two mesh nodes (like a long and thin peninsula for a region representing an island)
When a region is path-connected, this first step of the tesselation algorithm is sufficient to ensure the full region is covered and some grid points can be selected to construct a set list of regular tiles.
When a region is *not* path-connected (like when the region corresponds to an archipelago with one region split into several sub-regions), this first step is insufficient as it may cover only one of the islands and miss the other ones which are farther away. For this reason, the algorithm includes a second step to handle this case: the generated tile is removed from the initial region, and if the difference (with set theory semantics) is not empty, then a new iteration of the loop containing steps 1 and step 2 is performed, the seeding point for the new iteration being extracted from the difference, ensuring the new mesh will cover new areas. The meshes resulting from all iterations of this loop are merged together, taking care of cases where they intersect each other (in the archipelago example, this happens when islands are far enough to trigger several iterations, but close enough that some mesh happens to intersect other ones).
The critical bug happens when computing the regions difference. In rare cases (not fully characterized yet, but which seem to happen at high latitudes in along-track tiling), small path-connected regions lead to non-empty differences despite they are really fully covered by a single tile.Luc MaisonobeLuc Maisonobehttps://gitlab.orekit.org/orekit/orekit/-/issues/856Modularize Jacobians computation in NumericalPropagator2021-12-03T08:01:16ZLuc MaisonobeModularize Jacobians computation in NumericalPropagatorThis issue is a first step towards solving issue #855.
In addition to have a very awkward API, the `PartialDerivativesEquations` class does not meet some current needs.
It computes both the State Transition Matrix and the parameters Jac...This issue is a first step towards solving issue #855.
In addition to have a very awkward API, the `PartialDerivativesEquations` class does not meet some current needs.
It computes both the State Transition Matrix and the parameters Jacobians as a single `AdditionalEquations`
and this single equation should manage all derivatives by itself as the `JacobiansMapper` is used by orbit determination and expect the matrix columns to be in a specific order.
This is inflexible and does not allow to compute efficiently derivatives with respect to maneuver start date (which can be seen as a force model parameter). This computation is rather done using an analytical `AdditionalStateProvider`, but this provider reuses the pre-integrated State Transition Matrix, and should therefore see this integrated state.
This could be solved setting up some kind of priority or dependency between additional states (both analytical ones and integrated ones) and splitting current computations into smaller chunks (one for STM, one for each column of Jacobians with respect to parameters).11.1Luc MaisonobeLuc Maisonobe