Orekit issueshttps://gitlab.orekit.org/orekit/orekit/-/issues2022-01-20T16:04:59Zhttps://gitlab.orekit.org/orekit/orekit/-/issues/884Deprecate TimeSpanMap.getTransitions()2022-01-20T16:04:59ZLuc MaisonobeDeprecate TimeSpanMap.getTransitions()`TimeSpanMap` has a dual view for its content: `Span` and `Transition`.
The underlying storage is based on ordered elements in a `TreeSet` (hence guaranteed
log(n) query time) and a chronological comparator.
As spans may have two limit ...`TimeSpanMap` has a dual view for its content: `Span` and `Transition`.
The underlying storage is based on ordered elements in a `TreeSet` (hence guaranteed
log(n) query time) and a chronological comparator.
As spans may have two limit dates, both can be null and all dates are duplicated
as the end and start dates of neighboring spans, what is stored in the `TreeSet`
are really the `Transitions`, not the `Spans`. A side effect is that a `TimeSpanMap`
with only one valid entry has a single dummy transition that is not meaningful and
is replaced as soon as a real transition is added.
This dummy transition leaks from the API when calling `map.getTransitions()`.
As the API implemented as part of issue #883 adds links that help global navigation
in both directions, for both `Span` and `Transition` views and also allows to go
from time spans to transitions and back, `map.getTransitions()` is obsolete and
error prone due to the single dummy transition. This method should be deprecated.11.1Luc MaisonobeLuc Maisonobehttps://gitlab.orekit.org/orekit/orekit/-/issues/883Add navigation links between time spans and transitions in TimeSpanMap2022-01-20T16:04:59ZLuc MaisonobeAdd navigation links between time spans and transitions in TimeSpanMapThe `TimeSpanMap` container provides duals views to its data.
The `Span` view represent the time span during which one entry is valid, it has a value, and start and end dates.
The `Transition` view represent one transition date between t...The `TimeSpanMap` container provides duals views to its data.
The `Span` view represent the time span during which one entry is valid, it has a value, and start and end dates.
The `Transition` view represent one transition date between two spans.
The `Span` view can be retrieved only for single dates, using `map.getSpan(date)`, it is not possible from a span to get naturally the previous or next span, one has to use dirty tricks like `map.getSpan(currentSpan.getStart().shiftedBy(-0.001))`, hoping the previous span is larger than 1ms.
The `Transition` view can be retrieved only globally as a `NavigableSet<Transitions>` using `map.getTransitions()`. There is
no way to get the `Span` on each side, only the value contained in the `Span`.
The dual `Span` and `Transition` views are therefore mutually exclusive at API level, despite they are intertwined in the implementation.
It would be nice to have a way to get the `Transition` at start and end of a `Span`, and to have the before and after `Spans` at both sides of a `Transition`. It would also be nice to have `next` and `previous` methods to navigated from one `Transition` to the other or to one `Span` to the other.11.1Luc MaisonobeLuc Maisonobehttps://gitlab.orekit.org/orekit/orekit/-/issues/882Can't write ITRF OEM, or OEM without interpolation order2022-04-27T06:35:59ZEvan WardCan't write ITRF OEM, or OEM without interpolation orderIn Orekit 10 it was possible to use the `StreamingOemWriter` to write a OEM file in a Earth fixed frame. This appears to be impossible in Orekit 11. Similarly Orekit 10 could write a OEM without the optional `interpolationDegree` field, ...In Orekit 10 it was possible to use the `StreamingOemWriter` to write a OEM file in a Earth fixed frame. This appears to be impossible in Orekit 11. Similarly Orekit 10 could write a OEM without the optional `interpolationDegree` field, which appears to be impossible in Orekit 11. It seems that the current code ignores the value of `metadata.getReferenceFrame()` when writing. Perhaps there is a better way to set the output reference frame?
Test case for `StreamingOemWriterTest` below[OEMExample5ITRF.txt](/uploads/368dee5e53a77ea897bef7db4387a7ad/OEMExample5ITRF.txt) and expected file attached.
```java
@Test
public void testWriteOemEcfTaiNoInterpolation() {
// setup
String path = "/ccsds/odm/oem/OEMExample5.txt";
DataSource source = new DataSource(path, () -> getClass().getResourceAsStream(path));
final OemParser oemParser = new ParserBuilder().buildOemParser();
final Oem original = oemParser.parse(source);
final OemSatelliteEphemeris originalEphem =
original.getSatellites().values().iterator().next();
final BoundedPropagator propagator = originalEphem.getPropagator();
StringBuilder buffer = new StringBuilder();
Header header = original.getHeader();
OemMetadata metadata = original.getSegments().get(0).getMetadata();
metadata.setTimeSystem(TimeSystem.TAI);
metadata.setReferenceFrame(FrameFacade.map(FramesFactory.getITRF(IERSConventions.IERS_2010, true)));
metadata.setInterpolationMethod(null);
metadata.setInterpolationDegree(-1);
// action
StreamingOemWriter writer =
new StreamingOemWriter(new KvnGenerator(buffer, OemWriter.KVN_PADDING_WIDTH, "out", 0),
new WriterBuilder().buildOemWriter(),
header, metadata);
propagator.setStepHandler(30 * 60, writer.newSegment());
propagator.propagate(propagator.getMinDate(), propagator.getMaxDate());
// verify
System.out.println(buffer.toString());
String expectedPath = "/ccsds/odm/oem/OEMExample5ITRF.txt";
Oem expected = oemParser.parse(
new DataSource(expectedPath, () -> getClass().getResourceAsStream(expectedPath)));
Oem actual = oemParser.parse(
new DataSource("mem", () -> new StringReader(buffer.toString())));
compareOems(expected, actual, 1e-6, 1e-9);
}
```11.1.2https://gitlab.orekit.org/orekit/orekit/-/issues/878Fix writing of ITRF frame before 2000 in CCSDS files2022-01-17T15:10:35ZBryan CazabonneFix writing of ITRF frame before 2000 in CCSDS filesUsing the ITRF 1993 frame example, when writing the `REF_FRAME` entry in a CCSDS file, Orekit writes `ITRF1993` instead of `ITRF-93`. This issue is valid for all ITRF frames before 2000. The issue could be fixed by adding a `getName()` m...Using the ITRF 1993 frame example, when writing the `REF_FRAME` entry in a CCSDS file, Orekit writes `ITRF1993` instead of `ITRF-93`. This issue is valid for all ITRF frames before 2000. The issue could be fixed by adding a `getName()` method in the `CelestialBodyFrame` enumerate.
A file to reproduce the problem: [OEMExample9.txt](/uploads/c0d643e668023a487066219508f29533/OEMExample9.txt)
The test to add in `OemWriterTest` class:
@Test
public void testWriteExample9() {
doTest("/ccsds/odm/oem/OEMExample9.txt");
}11.1https://gitlab.orekit.org/orekit/orekit/-/issues/875Exception parsing empty CCSDS OEM comment2022-01-20T16:04:13ZM. VeltenException parsing empty CCSDS OEM commentParsing the CCSDS OEM file in txt format from [Spot the station](https://spotthestation.nasa.gov/trajectory_data.cfm) with Orekit 11.0.2 gives a parsing error on empty comments such as "COMMENT ".
A patch was proposed in the Orekit foru...Parsing the CCSDS OEM file in txt format from [Spot the station](https://spotthestation.nasa.gov/trajectory_data.cfm) with Orekit 11.0.2 gives a parsing error on empty comments such as "COMMENT ".
A patch was proposed in the Orekit forum [by Luc Maisonobe](https://forum.orekit.org/t/exception-parsing-empty-ccsds-oem-comment/1473/3?u=m-v) and confirmed to fix the problem.11.1https://gitlab.orekit.org/orekit/orekit/-/issues/874PositionAngleDetector not initialized in ConfigurableLowThrustManeuver2022-01-10T07:35:45ZsbaudierPositionAngleDetector not initialized in ConfigurableLowThrustManeuverAdding a PositionAngleDetector to a ConfigurableLowThrustManeuver as start and stop firing detector leads to a java.lang.NullPointerException error.
The issue had been solved in the Orekit forum by [@bcazabonne](https://forum.orekit.or...Adding a PositionAngleDetector to a ConfigurableLowThrustManeuver as start and stop firing detector leads to a java.lang.NullPointerException error.
The issue had been solved in the Orekit forum by [@bcazabonne](https://forum.orekit.org/t/usage-of-configurablelowthrustmaneuver-with-positionangledetector/1492/2?u=sbaudier):
> The fix to apply in Orekit is straightforward. In the init method of the EventBasedManeuverTriggers class, the following implementation.
> ```
> /** {@inheritDoc} */
> @Override
> public void init(final SpacecraftState initialState, final AbsoluteDate target) {
>
> if (!initialized) {
>
> initialized = true;
> forward = target.isAfterOrEqualTo(initialState);
> if (!forward && !allowBackwardPropagation) {
> // backward propagation was forbidden
> throw new OrekitException(OrekitMessages.BACKWARD_PROPAGATION_NOT_ALLOWED);
> }
>
> checkInitialFiringState(initialState);
>
> } // multiples calls to init : because it is a force model and by each detector
> }
> ```
>
> must be improved by
>
> ```
> /** {@inheritDoc} */
> @Override
> public void init(final SpacecraftState initialState, final AbsoluteDate target) {
>
> if (!initialized) {
>
> initialized = true;
> forward = target.isAfterOrEqualTo(initialState);
> if (!forward && !allowBackwardPropagation) {
> // backward propagation was forbidden
> throw new OrekitException(OrekitMessages.BACKWARD_PROPAGATION_NOT_ALLOWED);
> }
> startFiringDetector.init(initialState, target);
> stopFiringDetector.init(initialState, target);
>
> checkInitialFiringState(initialState);
>
> } // multiples calls to init : because it is a force model and by each detector
> }
> ```11.1Bryan CazabonneBryan Cazabonnehttps://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/-/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/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/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/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/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 Maisonobehttps://gitlab.orekit.org/orekit/orekit/-/issues/855Overhaul Jacobians matrices computation API2022-01-21T10:33:34ZLuc MaisonobeOverhaul Jacobians matrices computation APIJacobians matrices are currently extracted from propagators using several classes extending `AbstractJacobiansMapper` and that are specialized for each propagator. TLE propagator has an analytical implementation, DSST propagator has a mi...Jacobians matrices are currently extracted from propagators using several classes extending `AbstractJacobiansMapper` and that are specialized for each propagator. TLE propagator has an analytical implementation, DSST propagator has a mixed implementation and nulmerical propagator has an implementation based on using the old monolithic class `PartialDerivativesEquations` that implements `AdditionalEquation` and has a very awkward API (auto-add itself to the
propagator, but needs to wrap the initial state before reinitializing the propagator with its return value…)
A more user-friendly API would be welcome, where propagators themselves would provide a `getJacobiansMapper` method that would trigger computation internally as anyway each propagator already does the computation in specific ways.
A complete API overhaul could be done only on a major version (i.e. 12.0).11.1https://gitlab.orekit.org/orekit/orekit/-/issues/854AbstractManeuverTriggers.addResetter should be declared at interface level2023-09-04T18:04:12ZLuc MaisonobeAbstractManeuverTriggers.addResetter should be declared at interface levelThe `addResetter` methods (two signatures) from `AbstractManeuverTriggers`
really belongs to the public interface `ManeuverTriggers` an should be moved there.
As the interface is public and already present in the 11.x series and as this...The `addResetter` methods (two signatures) from `AbstractManeuverTriggers`
really belongs to the public interface `ManeuverTriggers` an should be moved there.
As the interface is public and already present in the 11.x series and as this
method cannot have a default implementation, this change cannot be done before 12.012.0Maxime JournotMaxime Journot