Orekit issueshttps://gitlab.orekit.org/groups/orekit/-/issues2019-02-03T19:19:40Zhttps://gitlab.orekit.org/orekit/orekit/-/issues/480Add transformation from AbsoluteDate to GPS date (week and milliseconds)2019-02-03T19:19:40ZLuc MaisonobeAdd transformation from AbsoluteDate to GPS date (week and milliseconds)Orekit can create an AbsoluteDate from a GPS date (week and
milliseconds),
but the opposite is not possible.
It would be nice to have a simple GPSDate container and conversions
in both directions.
*(from redmine: issue id 480, cre...Orekit can create an AbsoluteDate from a GPS date (week and
milliseconds),
but the opposite is not possible.
It would be nice to have a simple GPSDate container and conversions
in both directions.
*(from redmine: issue id 480, created on 2018-06-22)*
* Changesets:
* Revision 2f89195fa873ca98f3307d5b7cce89f56354e15a by Luc Maisonobe on 2018-06-22T16:11:53Z:
```
Added GPSDate class to convert back and forth with AbsoluteDate.
Fixes #480.
```
* Revision 2f89195fa873ca98f3307d5b7cce89f56354e15a by Luc Maisonobe on 2018-06-22T16:11:53Z:
```
Added GPSDate class to convert back and forth with AbsoluteDate.
Fixes #480.
```Luc MaisonobeLuc Maisonobehttps://gitlab.orekit.org/orekit/orekit/-/issues/485Need access to Kalman filter matrices2019-02-03T19:19:34ZShiva IyerNeed access to Kalman filter matricesCurrently, KalmanEstimator and the filter's observer interface (via
KalmanEstimation) only expose the covariance matrix. However, in order
to characterize filter performance and for subsequent smoothing, we need
access to the Kalman filt...Currently, KalmanEstimator and the filter's observer interface (via
KalmanEstimation) only expose the covariance matrix. However, in order
to characterize filter performance and for subsequent smoothing, we need
access to the Kalman filter's innovations covariance and state
transition matrices. Ideally, the KalmanEstimation interface ought to
expose the state transition, H matrix, Kalman gain, and innovations
covariance matrices. These matrices are currently being evaluated but
are marked as either protected or private in Orekit and Hipparchus.
Please provide accessors for these matrices, which I believe will be a
straightforward change. They will be enormously useful for our Orbit
Determination efforts here at the University of Texas. Thank you!
*(from redmine: issue id 485, created on 2018-07-18)*Luc MaisonobeLuc Maisonobehttps://gitlab.orekit.org/orekit/orekit/-/issues/14Some questions2018-08-07T09:40:56ZFrancesco RoccaSome questions1)In Ephemeris Mode the state vector output for min date and max date of
integrator is different if it considered the Bounded propagator or
not.Are this 2 points in the set of bounded points?
2)It would be better if the orbit, in ephem...1)In Ephemeris Mode the state vector output for min date and max date of
integrator is different if it considered the Bounded propagator or
not.Are this 2 points in the set of bounded points?
2)It would be better if the orbit, in ephemeris mode, were represented
by Analitic formula(parametric order and type polynomial );maybe is more
efficiently in time for example if you want retrive often different
single point or if you want store the calculated orbit in file and use
it later, and in this way you would have separate the orbit propagation
with other utility (orbital event ecc).
3) Droziner an Cunninghan models have a problem if high order
coefficients are considered.
*(from redmine: issue id 14, created on 2011-03-07, closed on 2011-03-07)*Luc MaisonobeLuc Maisonobehttps://gitlab.orekit.org/orekit/orekit/-/issues/15Maven eclipse plug-in fail to import project2018-08-07T09:40:57ZMichel LacotteMaven eclipse plug-in fail to import projectPlug-ins m2clipse and iam fail when importing orekit maven project from
source into eclipse.
It could be corrected by declaring maven-compiler-plugin in build
section of pom.xml rather than in reporting section.
*(from redmine: issue...Plug-ins m2clipse and iam fail when importing orekit maven project from
source into eclipse.
It could be corrected by declaring maven-compiler-plugin in build
section of pom.xml rather than in reporting section.
*(from redmine: issue id 15, created on 2011-03-10, closed on 2011-03-10)*
* Changesets:
* Revision ad7c5d7e79e2a71d40a1a62adc87f420a0de17aa by Guilhem Bonnefille on 2017-11-09T13:29:07Z:
```
Move extra files into META-INF inside the sources.jar.
The LICENSE.txt and NOTICE.txt files are already stored into the
META-INF of the binary jar file.
GitHub: fixes #15.
```
* Revision ad7c5d7e79e2a71d40a1a62adc87f420a0de17aa by Guilhem Bonnefille on 2017-11-09T13:29:07Z:
```
Move extra files into META-INF inside the sources.jar.
The LICENSE.txt and NOTICE.txt files are already stored into the
META-INF of the binary jar file.
GitHub: fixes #15.
```
* Revision ad7c5d7e79e2a71d40a1a62adc87f420a0de17aa by Guilhem Bonnefille on 2017-11-09T13:29:07Z:
```
Move extra files into META-INF inside the sources.jar.
The LICENSE.txt and NOTICE.txt files are already stored into the
META-INF of the binary jar file.
GitHub: fixes #15.
```https://gitlab.orekit.org/orekit/orekit/-/issues/16BoundedPropagator does not recognize AdditionalEquations2018-08-07T09:40:58ZGlauco Di GenovaBoundedPropagator does not recognize AdditionalEquationsWhen using ephemeris generated e.g. by a numerical propagator with
additional PartialDerivativesEquations, a bounded propagator with a
registered OrekitStepHandler is not able to interpolate the additional
state components. The exception...When using ephemeris generated e.g. by a numerical propagator with
additional PartialDerivativesEquations, a bounded propagator with a
registered OrekitStepHandler is not able to interpolate the additional
state components. The exception is "unknown additional equation" and it
seems due to the bounded propagator not keeping track of the additional
equations used for numerical ephemerides generation.
*(from redmine: issue id 16, created on 2011-03-11, closed on 2011-03-11)*
* Changesets:
* Revision 40f969bc9e162deead55967da3c128e2da933dfc on 2015-09-11T17:47:56Z:
```
Added negative zero support in FastMath.pow.
JIRA: MATH-1273
Github: closes #16
```
* Revision d4028d2dccf739d36450bd2a77d80edcf8649bc5 by Guilhem Bonnefille on 2017-11-09T13:29:22Z:
```
Add goal package to the building procedure.
The assembly:site does not trigger building, testing and packaging.
This goal should be explicitly invoked.
GitHub: fixes #16.
```
* Revision d4028d2dccf739d36450bd2a77d80edcf8649bc5 by Guilhem Bonnefille on 2017-11-09T13:29:22Z:
```
Add goal package to the building procedure.
The assembly:site does not trigger building, testing and packaging.
This goal should be explicitly invoked.
GitHub: fixes #16.
```
* Revision d4028d2dccf739d36450bd2a77d80edcf8649bc5 by Guilhem Bonnefille on 2017-11-09T13:29:22Z:
```
Add goal package to the building procedure.
The assembly:site does not trigger building, testing and packaging.
This goal should be explicitly invoked.
GitHub: fixes #16.
```https://gitlab.orekit.org/orekit/orekit/-/issues/17Availability of orekit in public maven repository2018-08-07T09:41:00ZThomas NeidhartAvailability of orekit in public maven repositoryIt would be very convenient if orekit (release, snapshots) would be
available in a public maven repository.
*(from redmine: issue id 17, created on 2011-03-16, closed on 2011-03-16)*
* Changesets:
* Revision adebc412dd4ee5a95c9be9f1...It would be very convenient if orekit (release, snapshots) would be
available in a public maven repository.
*(from redmine: issue id 17, created on 2011-03-16, closed on 2011-03-16)*
* Changesets:
* Revision adebc412dd4ee5a95c9be9f101e83f73f3a027c1 by Roman Ivanov on 2017-11-26T09:17:30Z:
```
bump checkstyle version to 8.4.
Github: fixes #17
```
* Revision adebc412dd4ee5a95c9be9f101e83f73f3a027c1 by Roman Ivanov on 2017-11-26T09:17:30Z:
```
bump checkstyle version to 8.4.
Github: fixes #17
```
* Revision adebc412dd4ee5a95c9be9f101e83f73f3a027c1 by Roman Ivanov on 2017-11-26T09:17:30Z:
```
bump checkstyle version to 8.4.
Github: fixes #17
```https://gitlab.orekit.org/orekit/orekit/-/issues/18ConstamtThrustManeuver problem2018-08-07T09:41:01ZGlauco Di GenovaConstamtThrustManeuver problemThe attached code fragment (a slight modification of one of the Orekit
tests) throws a null pointer exception. This problem only arises when
using a propagator with PartialDerivativesEquation.
-------------------------------------------...The attached code fragment (a slight modification of one of the Orekit
tests) throws a null pointer exception. This problem only arises when
using a propagator with PartialDerivativesEquation.
------------------------------------------------------------------------
import org.apache.commons.math.geometry.Rotation;
import org.apache.commons.math.geometry.Vector3D;
import
org.apache.commons.math.ode.nonstiff.AdaptiveStepsizeIntegrator;
import
org.apache.commons.math.ode.nonstiff.DormandPrince853Integrator;
import org.apache.commons.math.util.FastMath;
import org.orekit.attitudes.AttitudeProvider;
import org.orekit.attitudes.InertialProvider;
import org.orekit.errors.OrekitException;
import org.orekit.forces.maneuvers.ConstantThrustManeuver;
import org.orekit.frames.FramesFactory;
import org.orekit.orbits.KeplerianOrbit;
import org.orekit.orbits.Orbit;
import org.orekit.orbits.PositionAngle;
import org.orekit.propagation.SpacecraftState;
import org.orekit.propagation.numerical.NumericalPropagator;
import org.orekit.propagation.numerical.PartialDerivativesEquations;
import org.orekit.time.AbsoluteDate;
import org.orekit.time.DateComponents;
import org.orekit.time.TimeComponents;
import org.orekit.time.TimeScalesFactory;
public class TESTConstantThrustManeuver {
public static void main(String\[\] args) throws OrekitException {
Autoconfiguration.configureOrekit();
Setup.Init();
// Body mu
final double mu = 3.9860047e14;
final double isp = 318;
final double mass = 2500;
final double a = 24396159;
final double e = 0.72831215;
final double i = FastMath.toRadians(7);
final double omega = FastMath.toRadians(180);
final double OMEGA = FastMath.toRadians(261);
final double lv = 0;
final double duration = 3653.99;
final double f = 420;
final double delta = FastMath.toRadians(-7.4978);
final double alpha = FastMath.toRadians(351);
final AttitudeProvider law = new InertialProvider(new Rotation(new
Vector3D(alpha, delta), Vector3D.PLUS\_I));
final AbsoluteDate initDate = new AbsoluteDate(new DateComponents(2004,
01, 01),
new TimeComponents(23, 30, 00.000),
TimeScalesFactory.getUTC());
final Orbit orbit =
new KeplerianOrbit(a, e, i, omega, OMEGA, lv, PositionAngle.TRUE,
FramesFactory.getEME2000(), initDate, mu);
final SpacecraftState initialState =
new SpacecraftState(orbit, law.getAttitude(orbit, orbit.getDate(),
orbit.getFrame()), mass);
final AbsoluteDate fireDate = new AbsoluteDate(new DateComponents(2004,
01, 02),
new TimeComponents(04, 15, 34.080),
TimeScalesFactory.getUTC());
final ConstantThrustManeuver maneuver =
new ConstantThrustManeuver(fireDate, duration, f, isp,
Vector3D.PLUS\_I);
double\[\] absTolerance = {
0.001, 1.0e-9, 1.0e-9, 1.0e-6, 1.0e-6, 1.0e-6, 0.001
};
double\[\] relTolerance = {
1.0e-7, 1.0e-4, 1.0e-4, 1.0e-7, 1.0e-7, 1.0e-7, 1.0e-7
};
AdaptiveStepsizeIntegrator integrator =
new DormandPrince853Integrator(0.001, 1000, absTolerance,
relTolerance);
integrator.setInitialStepSize(60);
final NumericalPropagator propagator = new
NumericalPropagator(integrator);
propagator.setInitialState(initialState);
propagator.setAttitudeProvider(law);
propagator.addForceModel(maneuver);
propagator.setPropagationParametersType(NumericalPropagator.PropagationParametersType.CARTESIAN);
PartialDerivativesEquations PDE = new
PartialDerivativesEquations(propagator);
PDE.selectParamAndStep("thrust", Double.NaN);
PDE.setInitialJacobians(7, 1);
final SpacecraftState finalorb =
propagator.propagate(fireDate.shiftedBy(3800));
System.out.println(finalorb.getPVCoordinates().toString());
}
}
*(from redmine: issue id 18, created on 2011-03-30, closed on 2011-03-30)*
* Changesets:
* Revision 68d06e04ba4b661f2c4669598c9d80b05d6c791e on 2017-11-26T09:21:02Z:
```
Javadoc fix for TDMFile.ObservationsBlock::addObservation.
Github: fixes #18
```
* Revision 68d06e04ba4b661f2c4669598c9d80b05d6c791e on 2017-11-26T09:21:02Z:
```
Javadoc fix for TDMFile.ObservationsBlock::addObservation.
Github: fixes #18
```
* Revision 68d06e04ba4b661f2c4669598c9d80b05d6c791e on 2017-11-26T09:21:02Z:
```
Javadoc fix for TDMFile.ObservationsBlock::addObservation.
Github: fixes #18
```https://gitlab.orekit.org/orekit/orekit/-/issues/19Event missed2018-08-07T09:41:03ZPascal ParraudEvent missedPropagating back and forth with a KeplerianPropagator can miss some
event: if an event is found propagating forward, changing to backward
propagation will miss this event.
The same occurs with an Ephemeris, but not with a NumericalProp...Propagating back and forth with a KeplerianPropagator can miss some
event: if an event is found propagating forward, changing to backward
propagation will miss this event.
The same occurs with an Ephemeris, but not with a NumericalPropagator,
so it seems related to the AbstractPropagator.
*(from redmine: issue id 19, created on 2011-03-31, closed on 2011-03-31)*
* Changesets:
* Revision abb2057959377f26664bf4f8a2b4aea9422c1092 on 2015-12-15T18:44:38Z:
```
Fixed javadoc.
Thanks to Ole Ersoy for the patch.
Github: closes #19
```
* Revision 10b138d4b3229c1f8010ec558f54380fb310783d on 2018-01-18T11:30:53Z:
```
Override tle equals and hashcode.
Github: fixes #19
```
* Revision 10b138d4b3229c1f8010ec558f54380fb310783d on 2018-01-18T11:30:53Z:
```
Override tle equals and hashcode.
Github: fixes #19
```
* Uploads:
* [orekit-propagator-testcase.tar.gz](/uploads/a82888e57e56ec6384faf5073632806a/orekit-propagator-testcase.tar.gz) Nonehttps://gitlab.orekit.org/orekit/orekit/-/issues/20ephemeris mode broken (at least for GraggBulirschStoerIntegrator)2018-08-07T09:41:04ZGlauco Di Genovaephemeris mode broken (at least for GraggBulirschStoerIntegrator)Setting any propagator using a GraggBulirschStoerIntegrator in ephemeris
mode generates a null pointer exception. A working fix in this case is
to move the following statement in EphemerisModeHandler
this.model = new ContinuosOutput Mod...Setting any propagator using a GraggBulirschStoerIntegrator in ephemeris
mode generates a null pointer exception. A working fix in this case is
to move the following statement in EphemerisModeHandler
this.model = new ContinuosOutput Model();
from the method "initialize(...)" to the default constructor
"EphemerisModeHandler()"
Other integrators (e.g. DormandPrince) don't need this fix.
GraggBulirschStoerIntegrator invokes initializeArrays in its
addStepHandler method, which in turn tests for DenseOutput. Problem is
that at this stage EphemerisModeHandler.initialize han not been invoked
yet.
*(from redmine: issue id 20, created on 2011-04-08, closed on 2011-04-08)*
* Changesets:
* Revision 5566a21d2b34090d1ce8129f41b551a1187e7d5b on 2015-12-18T11:47:13Z:
```
Updated FieldMatrix exceptions thrown to match javadoc.
Github: closes #20
```
* Revision 89d3af4bc8a39ce6d62257bee7ac63e04b566c17 on 2018-01-18T13:04:10Z:
```
Corrected Romanian translations.
Github: fixes #20
```
* Revision 89d3af4bc8a39ce6d62257bee7ac63e04b566c17 on 2018-01-18T13:04:10Z:
```
Corrected Romanian translations.
Github: fixes #20
```https://gitlab.orekit.org/orekit/orekit/-/issues/21DE405 ephemeris and EME20002018-08-07T09:41:05ZBernard GodardDE405 ephemeris and EME2000Orekit assumes orientation for position velocity coordinates provided by
JPL is EME2000 axes.
However most modern ephemerides (DE4xx, INPOP...) are aligned with ICRF
axes.
The frame for the JPL bodies should then be derived from the ...Orekit assumes orientation for position velocity coordinates provided by
JPL is EME2000 axes.
However most modern ephemerides (DE4xx, INPOP...) are aligned with ICRF
axes.
The frame for the JPL bodies should then be derived from the GCRF frame,
not from EME2000.
References:
http://en.wikipedia.org/wiki/DE400
ftp://ssd.jpl.nasa.gov/pub/eph/export/DE405/de405iom.ps
ftp://ssd.jpl.nasa.gov/pub/eph/export/DE414/de414iom.ps
ftp://ssd.jpl.nasa.gov/pub/eph/planets/ioms/de421.iom.v1.pdf
http://syrte.obspm.fr/jsr/journees2008/Folkner.pdf
http://www.imcce.fr/inpop/
*(from redmine: issue id 21, created on 2011-04-13, closed on 2011-04-13)*https://gitlab.orekit.org/orekit/orekit/-/issues/22generic orbit class2019-11-13T15:22:49ZBernard Godardgeneric orbit classThe Orbit class is currently the highest level implementation for orbit.
However it is based on equinoctial elements which are not generic: the
class is limited to Elliptical osculating orbit. It is not suitable for
parabolic/hyperbolic ...The Orbit class is currently the highest level implementation for orbit.
However it is based on equinoctial elements which are not generic: the
class is limited to Elliptical osculating orbit. It is not suitable for
parabolic/hyperbolic trajectories, Lissajous type orbits... The most
generic orbit should probably only contain PV coordinates for numerical
integration. Moreover the center of the frame for a generic orbit should
not have to coincide with the "center of motion" : it is possible to
numerically integrate an heliocentric orbit with a center of integration
set to a planet. More generally the frame center and orientation for a
generic orbit should not have to be quasi-inertial if the user is
providing the correct force model for that frame (including inertial
forces).
*(from redmine: issue id 22, created on 2011-04-13)*
* Changesets:
* Revision c9b1c8f9662f865a613632e1d390922050130b60 on 2015-12-27T12:09:13Z:
```
Added compose and composeInverse to rotations.
These method are more flexible than the existing applyTo and
applyInverseTo (which are still present), because they allow caller
to specify a RotationConvention.
JIRA: MATH-1302, MATH-1303
Github: closes #22
```10.1https://gitlab.orekit.org/orekit/orekit/-/issues/23planetary ephemeris2018-08-07T09:41:09ZBernard Godardplanetary ephemerisThe JPL ephemerides class could easily be extended to support many more
ephemeris which have almost the same format as DE405 and are much more
accurate
- DE414, DE421, ... : http://ssd.jpl.nasa.gov/?planet\_eph\_export
- INPOP8, INPO...The JPL ephemerides class could easily be extended to support many more
ephemeris which have almost the same format as DE405 and are much more
accurate
- DE414, DE421, ... : http://ssd.jpl.nasa.gov/?planet\_eph\_export
- INPOP8, INPOP10A ... : http://www.imcce.fr/inpop/
It should be mainly a matter of adjusting the record length depending on
the ephemeris as is done for selecting between DE405/DE406. These files
are provided for both Big Endian and Little Endian systems.
INPOP ephemerides like DE ephemerides come with Moon libration ephemeris
but contrary to DE without Earth nutation ephemeris. They additionally
provide a time ephemeris (accurate TT-TDB for the worldline of the
geocenter), although for compatibility with legacy DExxx reading
programs, the INPOP files are also available without the time ephemeris.
The CALCEPH C library can read INPOPxx and JPL DExxx ephemeris files:
http://www.imcce.fr/inpop/calceph/index.php
On a side note, I am wondering why OREKIT is using the Big Endian
version of the ephemeris file (orekit does this explicitly even though
the Java virtual machine is big endian) and not the little endian file?
If only one file type was to be provided in the future for a certain
ephemeris, I think it would be the little endian type. Or maybe orekit
could use org.apache.commons.io.EndianUtils to read either big endian or
little endian depending on the filenames.
*(from redmine: issue id 23, created on 2011-04-14, closed on 2011-04-14)*
* Uploads:
* [DExxx_support.patch](/uploads/6e040d6061ee2d29fca7ecbc53f99ee7/DExxx_support.patch) Nonehttps://gitlab.orekit.org/orekit/orekit/-/issues/24Detector Access on Ground Point2019-12-30T08:23:42ZFrancesco RoccaDetector Access on Ground PointFor Earth observation satellites could be interesting to determine if a
georeferenced point is in the field of view of a detector (circular or
rectangular).
*(from redmine: issue id 24, created on 2011-05-03, closed on 2011-05-03)*For Earth observation satellites could be interesting to determine if a
georeferenced point is in the field of view of a detector (circular or
rectangular).
*(from redmine: issue id 24, created on 2011-05-03, closed on 2011-05-03)*https://gitlab.orekit.org/orekit/orekit/-/issues/26Reload the EOP1980History data at each update of the VeisFrame2018-08-07T09:41:13ZRomain di CostanzoReload the EOP1980History data at each update of the VeisFrameTo update the Veis Frame at a specific date, the dut1 value is needed.
To achieve this, Orekit is first getting the EOP1980 history values.
But, as those data aren't saved into the Veis frame, or inside the
FrameFactory, data files are r...To update the Veis Frame at a specific date, the dut1 value is needed.
To achieve this, Orekit is first getting the EOP1980 history values.
But, as those data aren't saved into the Veis frame, or inside the
FrameFactory, data files are read at each call. As EOP files can
contains a large amount of data, the computation time can be
excessive.
To avoid this, we could store the EOP data (for both 1980 and 2000 ! )
inside the FrameFactory.java as a static attribute.
The problem described here can be seen in the VeisFrame file at :
https://www.orekit.org/forge/projects/orekit/repository/revisions/master/entry/src/main/java/org/orekit/frames/VEISFrame.java\#L80
:
Line 80 :
final double dut1 =
FramesFactory.getEOP1980History().getUT1MinusUTC(date);
*(from redmine: issue id 26, created on 2011-06-27, closed on 2011-06-27)*https://gitlab.orekit.org/orekit/orekit/-/issues/27problem getting UTC timescale2018-08-07T09:41:15ZSébastien Herbinièreproblem getting UTC timescaleHello,
I've got a really annoying problem using Orekit v5.
I am using a numerical integrator to propagate an orbit over a long
period to simulate station keeping.
The propagation works fine for several years, then, sometimes, in an...Hello,
I've got a really annoying problem using Orekit v5.
I am using a numerical integrator to propagate an orbit over a long
period to simulate station keeping.
The propagation works fine for several years, then, sometimes, in an
unpredictable way, the following exception occurs:
`java.lang.ArrayIndexOutOfBoundsException: 26
at org.orekit.time.UTCScale.setCurrent(UTCScale.java:161)
at org.orekit.time.UTCScale.offsetFromTAI(UTCScale.java:97)
at org.orekit.frames.TIRF2000Frame.updateFrame(TIRF2000Frame.java:126)
at org.orekit.frames.Frame.getTransformTo(Frame.java:193)
at org.orekit.forces.gravity.CunninghamAttractionModel.addContribution(CunninghamAttractionModel.java:124)
at org.orekit.propagation.numerical.NumericalPropagator$DifferentialEquations.computeDerivatives(NumericalPropagator.java:521)
at org.apache.commons.math.ode.AbstractIntegrator.computeDerivatives(AbstractIntegrator.java:182)
at org.apache.commons.math.ode.nonstiff.EmbeddedRungeKuttaIntegrator.integrate(EmbeddedRungeKuttaIntegrator.java:273)
at org.orekit.propagation.numerical.NumericalPropagator.propagate(NumericalPropagator.java:419)
at fr.tas.anamis.study.o3b.O3bStationKeeping.propagate(O3bStationKeeping.java:605)
`
This "26" out of bounds exception comes from the TAI to UTC conversion
in UTCScale class
There is a table of 26 values (26 lines in UTC-TAI.history file) with
index from 0 to 25.
So when the index "current" is incremented to 26 there is an out of
bound exception :
@ private synchronized void setCurrent(final AbsoluteDate date) {
while (date.compareTo(offsets\[current\].getValidityStart()) < 0) {
--current;
}
while (date.compareTo(offsets\[current\].getValidityEnd()) >= 0) {
++current;
}
}
@
I've tried several workarounds, but nothing really satisfying...
This problem seems not to occur with Orekit v4.
It may be due to a bad use, but I don't understand why it works 99.9% of
time.
Anyway I think this exception should be properly raised by Orekit
(should not be java.lang.ArrayIndexOutOfBoundsException: 26 )
I would appreciate if you could help
Thanks.
*(from redmine: issue id 27, created on 2011-06-28, closed on 2011-06-28)*https://gitlab.orekit.org/orekit/orekit/-/issues/28SP3-[a,c] orbit file parser2018-08-07T09:41:17ZThomas NeidhartSP3-[a,c] orbit file parserFollowing a short discussion on the mailing list, I would like to
contribute a SP3 orbit file parser.
It has been specifically designed/implemented for a project in order to
extract PV coordinates from sp3 files, not yet taking correlat...Following a short discussion on the mailing list, I would like to
contribute a SP3 orbit file parser.
It has been specifically designed/implemented for a project in order to
extract PV coordinates from sp3 files, not yet taking correlation and
maneuver records into account.
See attached archive to review the current interface, I am of course
willing to update the contribution according to your comments.
P.S. the logging dependency to slf4j will be removed in the final
contribution
*(from redmine: issue id 28, created on 2011-07-25, closed on 2011-07-25)*
* Uploads:
* [sp3parser.tar.gz](/uploads/5eb2cce07e6a2317adf98de0a5cfb6f0/sp3parser.tar.gz) Nonehttps://gitlab.orekit.org/orekit/orekit/-/issues/29Atmospheric/Earth Magnetic field models2018-08-07T09:41:20ZThomas NeidhartAtmospheric/Earth Magnetic field modelsIs there an interest to include certain atmospheric and geomagnetic
models into orekit?
I am working on the following models, which I could contribute:
- tropospheric delay model (Saastamoinen) ->available
- ionospheric delay model (...Is there an interest to include certain atmospheric and geomagnetic
models into orekit?
I am working on the following models, which I could contribute:
- tropospheric delay model (Saastamoinen) ->available
- ionospheric delay model (TBD)
- geomagnetic field model (WMM, IGRF) ->available
*(from redmine: issue id 29, created on 2011-07-25, closed on 2011-07-25)*
* Uploads:
* [tropospheric-delays.patch](/uploads/556ae57fc7aae1cdbb2afd953d992fc0/tropospheric-delays.patch) None
* [geomagnetic-field.patch.gz](/uploads/40a53d6304b0b8aab85adbabf1afede5/geomagnetic-field.patch.gz) Nonehttps://gitlab.orekit.org/orekit/orekit/-/issues/30support for CCSDS Orbit Data Messages2018-08-07T09:41:21ZDale Thompsonsupport for CCSDS Orbit Data MessagesThe Orbit Data Message CCSDS recommended standard version 2 has been
published in late 2009.
It is available here:
http://public.ccsds.org/publications/archive/502x0b2.pdf
Orekit should support this recommended standard.
*(from red...The Orbit Data Message CCSDS recommended standard version 2 has been
published in late 2009.
It is available here:
http://public.ccsds.org/publications/archive/502x0b2.pdf
Orekit should support this recommended standard.
*(from redmine: issue id 30, created on 2011-07-29, closed on 2011-07-29)*
* Relations:
* duplicates #13
* Uploads:
* [OrekitMessagesTest.java](/uploads/7b59741b85aaa0168e61ee39c68abbde/OrekitMessagesTest.java) NoneLuc MaisonobeLuc Maisonobehttps://gitlab.orekit.org/orekit/orekit/-/issues/31Frame for TLEPropagator2018-08-07T09:41:21ZPascal ParraudFrame for TLEPropagatorgetFrame for TLEPropagator always throws a NullPointerException, because
it never defines internal initialState, but it could return a TEME frame
for consistancy.
*(from redmine: issue id 31, created on 2011-08-22, closed on 2011-08-22)*getFrame for TLEPropagator always throws a NullPointerException, because
it never defines internal initialState, but it could return a TEME frame
for consistancy.
*(from redmine: issue id 31, created on 2011-08-22, closed on 2011-08-22)*https://gitlab.orekit.org/orekit/orekit/-/issues/32Eckstein-Hechler documentation2018-08-07T09:41:22ZSébastien HerbinièreEckstein-Hechler documentationHello,
I am using extensively the Eckstein-Hechler propagator and I would like
to get more information about the model.
The information in the javadoc concerning the model is poor :
"The Eckstein-Hechler model is suited for near ci...Hello,
I am using extensively the Eckstein-Hechler propagator and I would like
to get more information about the model.
The information in the javadoc concerning the model is poor :
"The Eckstein-Hechler model is suited for near circular orbits (e <
0.1, with poor accuracy between 0.005 and 0.1) and inclination neither
equatorial (direct or retrograde) nor critical (direct or
retrograde)."
It gives the conditions of use but there is no reference to any document
that describes the algorithm.
Searching in Google scholar, I've found this reference :
\*"A reliable derivation of the perturbations due to any zonal and
tesseral harmonics of the geopotential for nearly-circular satellite
orbits
ECKSTEIN, M C | HECHLER, F" - ESRO-SR-13 - 1970\*
Unfortunately, I did not manage to get this document.
Is this document the baseline for the Orekit Eckstein-Hechler
perturbation ?
If not, could you give your reference ?
Thanks,
Sébastien
*(from redmine: issue id 32, created on 2011-09-16, closed on 2011-09-16)*