Orekit issueshttps://gitlab.orekit.org/groups/orekit/-/issues2018-08-07T14:16:43Zhttps://gitlab.orekit.org/orekit/rugged/-/issues/343Add Danish error messages2018-08-07T14:16:43ZLars Næsbye ChristensenAdd Danish error messagesI have translated the error messages from Danish and would like to see
them in Rugged.
*(from redmine: issue id 343, created on 2017-06-14, closed on 2017-12-21)*
* Uploads:
* [RuggedMessages_da.utf8](/uploads/1fc57cf01b69d4e68f7873...I have translated the error messages from Danish and would like to see
them in Rugged.
*(from redmine: issue id 343, created on 2017-06-14, closed on 2017-12-21)*
* Uploads:
* [RuggedMessages_da.utf8](/uploads/1fc57cf01b69d4e68f787341bc85680c/RuggedMessages_da.utf8) dk_da translation of Rugged error messageshttps://gitlab.orekit.org/orekit/orekit/-/issues/348Accuracy issue when computing duration between a FieldAbsoluteDate and an Abs...2018-08-07T09:45:45ZLuc MaisonobeAccuracy issue when computing duration between a FieldAbsoluteDate and an AbsoluteDateThe following test fails, due to accuracy issues between
FieldAbsoluteDate and AbsoluteDate
FieldAbsoluteDate<T> tF = new FieldAbsoluteDate&lt;&gt;(field,
new DateComponents(1970, 01, 01),
new TimeComponents(3, 25, 45.6789),
TimeS...The following test fails, due to accuracy issues between
FieldAbsoluteDate and AbsoluteDate
FieldAbsoluteDate<T> tF = new FieldAbsoluteDate<>(field,
new DateComponents(1970, 01, 01),
new TimeComponents(3, 25, 45.6789),
TimeScalesFactory.getUTC());
AbsoluteDate tA = tF.toAbsoluteDate();
double delta = -0.01;
T recomputedDelta = tF.shiftedBy(delta).durationFrom(tA);
Assert.assertEquals(delta, recomputedDelta.getReal(), 1.0e-15);
The recomputed delta is about -0.01 + 9.54e-9 instead of -0.01, so
accuracy is only 6 digits
in this round-trip computation.
*(from redmine: issue id 348, created on 2017-07-13, closed on 2017-07-27)*Luc MaisonobeLuc Maisonobehttps://gitlab.orekit.org/orekit/orekit/-/issues/349ImpulseManeuver does not forward additional states2018-08-07T09:45:45ZLuc MaisonobeImpulseManeuver does not forward additional statesThe resetState method in ImpulseManeuver.Handler that modifies the state
to add the
velocity increment does not copy the additional states from the old
state.
It should at least copy this data it does not know how to handle rather
th...The resetState method in ImpulseManeuver.Handler that modifies the state
to add the
velocity increment does not copy the additional states from the old
state.
It should at least copy this data it does not know how to handle rather
than
removing it.
*(from redmine: issue id 349, created on 2017-08-06, closed on 2017-11-25)*https://gitlab.orekit.org/orekit/orekit/-/issues/355Earth inertial frame obtained from CelestialBodyFactory is wrong2019-05-20T08:19:22ZLuc MaisonobeEarth inertial frame obtained from CelestialBodyFactory is wrongThe following code generates a wrong output:
final Frame earthFrame =
CelestialBodyFactory.getEarth().getInertiallyOrientedFrame();
final Frame base = FramesFactory.getGCRF();
final Rotation quarterPlus = new Rotation(Vector3D.PLUS\...The following code generates a wrong output:
final Frame earthFrame =
CelestialBodyFactory.getEarth().getInertiallyOrientedFrame();
final Frame base = FramesFactory.getGCRF();
final Rotation quarterPlus = new Rotation(Vector3D.PLUS\_K,
Vector3D.PLUS\_I,
Vector3D.PLUS\_K, Vector3D.PLUS\_J);
final Rotation quarterMinus = new Rotation(Vector3D.PLUS\_K,
Vector3D.PLUS\_I,
Vector3D.PLUS\_K, Vector3D.MINUS\_J);
for (double dt = -60; dt <= 60; dt += 1.0) {
final AbsoluteDate date = AbsoluteDate.J2000\_EPOCH.shiftedBy(dt);
Rotation rotation = base.getTransformTo(earthFrame,
date).getRotation();
System.out.println(dt + " " + Rotation.distance(Rotation.IDENTITY,
rotation) +
" " + Rotation.distance(quarterPlus, rotation) +
" " + Rotation.distance(quarterMinus, rotation));
}
According to the "Report of the IAU/IAG Working Group on Cartographic
Coordinates and Rotational Elements of the Planets and Satellites" the
Earth
frame should be almost aligned with GCRF, so the code above should
display
a first column with an angle of almost 0 and second and third colums
should
display angles of about π/2. However, the first column is about π/2, the
second
column starts with almost zero for dates before J2000.0 and jumps to π
after J200.0,
and the third column starts with π for dates before J2000.0 and drops to
0 after J200.0.
The problem is due to computation of the Q node vector (as per the
report of the IAU/IAG working
group), which is performed on current Orekit using a cross product, and
fails for the Earth
body since its pole is almost aligned with GCRF. There is already a
protection against exactly
aligned poles, but its threshold is far too low.
*(from redmine: issue id 355, created on 2017-08-22, closed on 2017-11-25)*Luc MaisonobeLuc Maisonobehttps://gitlab.orekit.org/orekit/orekit/-/issues/356earliest and latest dates unused in ShiftingTransformProvider and Interpolati...2018-08-07T09:45:51ZLuc Maisonobeearliest and latest dates unused in ShiftingTransformProvider and InterpolatingTransformProviderThe earliest and latest dates appear in the constructors of
ShiftingTransformProvider and InterpolatingTransformProvider,
but are not used anymore. They are just passed from
ShiftingTransformProvider to InterpolatingTransformProvider ...The earliest and latest dates appear in the constructors of
ShiftingTransformProvider and InterpolatingTransformProvider,
but are not used anymore. They are just passed from
ShiftingTransformProvider to InterpolatingTransformProvider
and only stored in InterpolatingTransformProvider without any use for
them, except being serialized and deserialized.
These parameters can be safely removed, and the constructors being
deprecated.
*(from redmine: issue id 356, created on 2017-08-23, closed on 2017-11-25)*Luc MaisonobeLuc Maisonobehttps://gitlab.orekit.org/orekit/orekit/-/issues/364osculating to mean computation fails of eccentricity is exactly 02018-08-07T09:45:59ZLuc Maisonobeosculating to mean computation fails of eccentricity is exactly 0The following test fails to compute the mean elements. The convergence
loops
generates NaNs right from first iteration, and then cannot converge.
It
stops when it hits the maximum number of iterations allowed for the
computation.
@T...The following test fails to compute the mean elements. The convergence
loops
generates NaNs right from first iteration, and then cannot converge.
It
stops when it hits the maximum number of iterations allowed for the
computation.
@Test
public void testIssue364() throws OrekitException {
Utils.setDataRoot("regular-data");
AbsoluteDate date = new AbsoluteDate("2003-06-18T00:00:00.000",
TimeScalesFactory.getUTC());
CircularOrbit orbit = new CircularOrbit(7389068.5, 0.0, 0.0, 1.709573,
1.308398, 0, PositionAngle.MEAN,
FramesFactory.getTOD(IERSConventions.IERS\_2010, false),
date, Constants.WGS84\_EARTH\_MU);
SpacecraftState osculatingState = new SpacecraftState(orbit, 1116.2829);
List<DSSTForceModel> dsstForceModels = new ArrayList<DSSTForceModel>();
dsstForceModels.add(new
DSSTThirdBody(CelestialBodyFactory.getMoon()));
dsstForceModels.add(new DSSTThirdBody(CelestialBodyFactory.getSun()));
SpacecraftState meanState =
DSSTPropagator.computeMeanState(osculatingState, null,
dsstForceModels);
Assert.assertEquals( 0.421, osculatingState.getA() - meanState.getA(),
1.0e-3);
Assert.assertEquals(<s>5.23e-8, osculatingState.getEquinoctialEx()</s>
meanState.getEquinoctialEx(), 1.0e-10);
Assert.assertEquals(15.22e-8, osculatingState.getEquinoctialEy() -
meanState.getEquinoctialEy(), 1.0e-10);
Assert.assertEquals(<s>3.15e-8, osculatingState.getHx()</s>
meanState.getHx(), 1.0e-10);
Assert.assertEquals( 2.83e-8, osculatingState.getHy() -
meanState.getHy(), 1.0e-10);
Assert.assertEquals(15.96e-8, osculatingState.getLM() -
meanState.getLM(), 1.0e-10);
}
If eccentricity components ex and ey are both set to 1.0e-15, the test
succeeds.
*(from redmine: issue id 364, created on 2017-10-11, closed on 2017-11-25)*https://gitlab.orekit.org/orekit/rugged/-/issues/371Parameters reversed in SensorToGroundMapping constructor2018-09-14T15:24:33ZLuc MaisonobeParameters reversed in SensorToGroundMapping constructorThe single parameter constructor SensorToGroundMapping(final String
sensorName)
calls the two parameters constructor SensorToGroundMapping(final String
ruggedName, final String sensorName)
with parameters reversed.
The first paramet...The single parameter constructor SensorToGroundMapping(final String
sensorName)
calls the two parameters constructor SensorToGroundMapping(final String
ruggedName, final String sensorName)
with parameters reversed.
The first parameter should be the name of the rugged instance, not the
sensor name.
*(from redmine: issue id 371, created on 2017-12-21)*Luc MaisonobeLuc Maisonobehttps://gitlab.orekit.org/orekit/orekit/-/issues/376SP3 file parse cannot parse files produced by GFZ for IGS Multi-GNSS Experime...2018-08-07T09:46:09ZLuc MaisonobeSP3 file parse cannot parse files produced by GFZ for IGS Multi-GNSS Experiment (MGEX)An example of such a file is
ftp://cddis.gsfc.nasa.gov/pub/gps/products/mgex/1950/gbm19500.sp3.Z
There are several issues.
First, the number of lines in the header is larger in multi-GNSS because
there are far more
satellites to hand...An example of such a file is
ftp://cddis.gsfc.nasa.gov/pub/gps/products/mgex/1950/gbm19500.sp3.Z
There are several issues.
First, the number of lines in the header is larger in multi-GNSS because
there are far more
satellites to handle. In the file above, there are 87 satellites and
their ids do not fit
within 5 lines (and the exponents will not fit either in the next 5
lines). So we need to
change the parser so it uses the two characters symbol at line start
instead of relying on
line number.
Second, the files produced have 80 characters lines instead of 60
characters. The last 20
characters are empty, but some part of the parser loop over repeated
substrings (typically
the ids and the exponents) until end of line, and fail when they reach
the empty final part.
*(from redmine: issue id 376, created on 2018-02-20, closed on 2018-06-04)*Luc MaisonobeLuc Maisonobehttps://gitlab.orekit.org/orekit/orekit/-/issues/403Add a provider generating process noise increasing in time, for better Kalman...2023-03-03T14:10:51ZLuc MaisonobeAdd a provider generating process noise increasing in time, for better Kalman filteringThe Kalman filter implementation in Orekit let the user provide the
process noise
matrix at each prediction step. As of 2018-03-22, the only
implementation of
the ProcessNoiseMatricProvider is ConstantProcessNoise. Users could
implem...The Kalman filter implementation in Orekit let the user provide the
process noise
matrix at each prediction step. As of 2018-03-22, the only
implementation of
the ProcessNoiseMatricProvider is ConstantProcessNoise. Users could
implement their
own process noise provider, as complex and as realistic as they want.
It would be interesting to have another implementation in Orekit that is
more realistic
than a constant matrix, and that simulates at least the expansion of the
uncertainty
ellipsoid along track as time without measurements increase.
A first idea would be to have user provide six polynomials representing
the diagonal
elements of the covariance in some Local Orbital Frame (say LVLH for
example). The
polynomial for the along velocity covariance would increase faster than
the polynomial
for the across directions. Then, by pre and post-multiplying by the
rotation matrix
we get from LOFType.rotationFromInertial, we get the dense matri in
inertial frame
we need to return.
This implementation is simple but much more realistic than a constant
matrix, and it
should properly take into account the fact the uncertainty from the
prediction step
is larger when the time between measurements is long than when
measurements occur
frequently.
Finding the polynomials would remain here the responsibility of the
caller. Later on,
we can think about using FieldPropagator on a reference orbit to
estimate these
polynomials during the mission analysis phase prior to operations.
*(from redmine: issue id 403, created on 2018-03-22)*12.0Maxime JournotMaxime Journothttps://gitlab.orekit.org/orekit/orekit/-/issues/404AttitudeSequence generates out-of-sync attitude computation with variable ste...2018-08-07T09:46:17ZLuc MaisonobeAttitudeSequence generates out-of-sync attitude computation with variable step numerical propagatorsWhen propagating with a variable step propagator a trajectory that uses
an
attitude sequence, displaying the results using a fixed step handler
generates
wrong output. The attitude seems to jump directly to the after switch
attitude ...When propagating with a variable step propagator a trajectory that uses
an
attitude sequence, displaying the results using a fixed step handler
generates
wrong output. The attitude seems to jump directly to the after switch
attitude
a few seconds before the switch really happens, then when the switch
happens
it goes back to a proper interpolation during the specified transition
time.
The problem is that AttitudeSequence, which should know about the
scheduling
issue between events handlers and ste handlers, is not protected for
out-of-sync
calls.
The issue was first raised by Tom Walford on the users mailing list
*(from redmine: issue id 404, created on 2018-03-26, closed on 2018-06-04)*Luc MaisonobeLuc Maisonobehttps://gitlab.orekit.org/orekit/orekit/-/issues/410Override Attitude During ConstantThrustManeuver2018-08-07T09:46:19ZLuc MaisonobeOverride Attitude During ConstantThrustManeuverThis feature is similar to issue \#176, but concerns constant thrust
instead of impulse maneuver.
The idea is to use a maneuver specific attitude just to compute the
direction of the ΔV and
not for the full spacecraft propagation
*(...This feature is similar to issue \#176, but concerns constant thrust
instead of impulse maneuver.
The idea is to use a maneuver specific attitude just to compute the
direction of the ΔV and
not for the full spacecraft propagation
*(from redmine: issue id 410, created on 2018-03-29, closed on 2018-06-04)*Luc MaisonobeLuc Maisonobehttps://gitlab.orekit.org/orekit/orekit/-/issues/412Allow choice of ITRF for very accurate mission needs2018-08-07T09:46:21ZLuc MaisonobeAllow choice of ITRF for very accurate mission needsAs of version 9.1, Orekit assumes the loaded Earth Orientation
Parameters defines
a specific version of ITRF that the users should be aware of. For
example if they
load their EOP from EOP 14 C04 files, they will get ITRF 2014. Howeve...As of version 9.1, Orekit assumes the loaded Earth Orientation
Parameters defines
a specific version of ITRF that the users should be aware of. For
example if they
load their EOP from EOP 14 C04 files, they will get ITRF 2014. However,
users
can mix EOP from different files (for example using EOP C04 for yearly
files en
Bulletin A for day to day operations). In this case, the EOP history
will not
define a unique ITRF, but will jump from one ITRF version to the other
depending
on data source.
Sticking to one type of EOP file is not sufficient to get a unique ITRF
as some
files changed their reference. As an example Bulletin A switched to
ITRF-2005 in
February 2007, then to ITRF-2008 in February 2011, and recently to
ITRF-2014 in
March 2018. Bulletin B switched to ITRF-2008 also in February 2011 and
as of
writing (2018-04-03) have not yet switched to ITRF-2014.
For most users, this is not a problem as various ITRF frames are only a
few
millimeters or centimeters away from one other. For very high accuracy
needs,
like geodesy, knowing which ITRF is used is mandatory.
Orekit should allow user to specify the ITRF to use, and should abide by
this
selection regardless of the EOP source used. The existing getITRF
method
without any specification should still remain available for less
demanding
applications.
*(from redmine: issue id 412, created on 2018-04-03, closed on 2018-06-04)*Luc MaisonobeLuc Maisonobehttps://gitlab.orekit.org/orekit/orekit/-/issues/446Add a filtering capability at data loading2018-08-07T09:46:29ZLuc MaisonobeAdd a filtering capability at data loadingData loading mechanism already implements a filtering capability for
gzip-compressed files.
When such files are present in the configuration data (typically an
orekit-data folder in
some well-known location), then a decompression filt...Data loading mechanism already implements a filtering capability for
gzip-compressed files.
When such files are present in the configuration data (typically an
orekit-data folder in
some well-known location), then a decompression filtering layer is
inserted between the
opening of the file by the operating system and the parsing by Orekit
data loaders.
This mechanism should be extended to allow more filters to be inserted,
including user-supplied
filters. This would allow more decompression scheme to be used as well
as deciphering or
monitoring capabilities.
*(from redmine: issue id 446, created on 2018-04-27, closed on 2018-06-04)*Luc MaisonobeLuc Maisonobehttps://gitlab.orekit.org/orekit/orekit/-/issues/447Add unix-compress decompression filter2018-08-07T09:46:30ZLuc MaisonobeAdd unix-compress decompression filterDespite unix-compress has been considered obsolete since decades, it
is
still widely used in the GNSS community, for example to provide
Klobuchar
coefficients (see ftp://ftp.aiub.unibe.ch/CODE/2016/) or SP3 and clock
files
(see ftp...Despite unix-compress has been considered obsolete since decades, it
is
still widely used in the GNSS community, for example to provide
Klobuchar
coefficients (see ftp://ftp.aiub.unibe.ch/CODE/2016/) or SP3 and clock
files
(see ftp://igs.ign.fr/pub/igs/products/mgex/1998/).
The decompression algorithm is quite simple and could probably be
added
easily as a predefined filter using the filtering mechanism described
in
issue \#446).
*(from redmine: issue id 447, created on 2018-04-27, closed on 2018-06-04)*Luc MaisonobeLuc Maisonobehttps://gitlab.orekit.org/orekit/orekit/-/issues/448New ICGEM format with piecewise-linear cofficients for gravity fields is not ...2022-02-14T07:50:08ZLuc MaisonobeNew ICGEM format with piecewise-linear cofficients for gravity fields is not supportedSome recent gravity fields published by ICGEM use a new file format.
A typical example is Eigen 6S2 from
http://icgem.gfz-potsdam.de/tom\_longtime
(the original Eigen 6S format is supported). The file reference a link
to
the format...Some recent gravity fields published by ICGEM use a new file format.
A typical example is Eigen 6S2 from
http://icgem.gfz-potsdam.de/tom\_longtime
(the original Eigen 6S format is supported). The file reference a link
to
the format that is broken. However, the file format seems easy to
understand.
The main difference with the previous version (2011) of the file format
is
that the time-dependent coefficients now have associated time spans,
and
several spans can be defined for the same coefficient.
This means the model is not linear plus harmonic, but rather
piecewise-linear
plus harmonics.
The J2 coefficient in the Eigen 6S2 gravity field has 29 different
intervals,
from 1950 to 2050, some intervals being one-year long while others are
several
decades long.
*(from redmine: issue id 448, created on 2018-05-14)*11.1Luc MaisonobeLuc Maisonobehttps://gitlab.orekit.org/orekit/orekit/-/issues/450NullPointerException generated when uncompressing a specific sp3 file2018-08-07T09:46:32ZLuc MaisonobeNullPointerException generated when uncompressing a specific sp3 fileWhen parsing the file
[ftp://igs.ign.fr/pub/igs/products/mgex/1843/gbm18432.sp3.Z](ftp://igs.ign.fr/pub/igs/products/mgex/1843/gbm18432.sp3.Z)
from IGS MGEX project, a NullPointerException is generated after having
successfully
uncom...When parsing the file
[ftp://igs.ign.fr/pub/igs/products/mgex/1843/gbm18432.sp3.Z](ftp://igs.ign.fr/pub/igs/products/mgex/1843/gbm18432.sp3.Z)
from IGS MGEX project, a NullPointerException is generated after having
successfully
uncompressed 80% of the file.
*(from redmine: issue id 450, created on 2018-05-16, closed on 2018-06-04)*Luc MaisonobeLuc Maisonobehttps://gitlab.orekit.org/orekit/orekit/-/issues/462Cannot compile with JDK 1.82018-08-07T09:46:35ZLuc MaisonobeCannot compile with JDK 1.8The commit:f714b8119 introduced a change in the gnss-attitude branch
on April 21 and merged back into develop branch on May 21 generates
a compilation error with Java 1.8 compilers (Oracle JDK 1.8 and
OpenJDK 1.8). The error is on ...The commit:f714b8119 introduced a change in the gnss-attitude branch
on April 21 and merged back into develop branch on May 21 generates
a compilation error with Java 1.8 compilers (Oracle JDK 1.8 and
OpenJDK 1.8). The error is on line 669 of file BatchLSEstimator.java.
There are no compilation errors wih Java 9 compiler used in 1.8
compatibiliy. The code seems to be correct, but older compilers
fail to understand a parameterized class.
*(from redmine: issue id 462, created on 2018-05-22, closed on 2018-06-04)*Luc MaisonobeLuc Maisonobehttps://gitlab.orekit.org/orekit/orekit/-/issues/470Redesign FieldPVCoordinatesProvider, and perhaps other Field-related classes2018-08-07T09:46:37ZLuc MaisonobeRedesign FieldPVCoordinatesProvider, and perhaps other Field-related classesLooking at issue \#366, it appears we sometime need a
FieldPVCoordinatesProvider
where the type of the field is not hard-coded in the class itself.
This means that the <T extends RealFieldElement<T>>clause should be
at method
level ...Looking at issue \#366, it appears we sometime need a
FieldPVCoordinatesProvider
where the type of the field is not hard-coded in the class itself.
This means that the <T extends RealFieldElement<T>>clause should be
at method
level (getPVCoordinates method in this case) rather than at class level.
This
design change is probably worth considering throughout the library.
This type of change can be done only for a major release as it is a
backward-incompatible change.
*(from redmine: issue id 470, created on 2018-05-23, closed on 2018-06-04)*https://gitlab.orekit.org/orekit/orekit/-/issues/472Add support for Hatanaka compact RINEX format2019-07-17T15:13:34ZLuc MaisonobeAdd support for Hatanaka compact RINEX formatAs of 9.2, Orekit supports RINEX versions 2.x and 3.x in both raw
format
or compressed with UNIX compress (.Z files), but not files compressed
with Hatanaka differential method.
Such files are for example provided by UNAVCO consorti...As of 9.2, Orekit supports RINEX versions 2.x and 3.x in both raw
format
or compressed with UNIX compress (.Z files), but not files compressed
with Hatanaka differential method.
Such files are for example provided by UNAVCO consortium
(ftp://data-out.unavco.org/pub/rinex/obs/).
The specification of the differential compression method can be found in
http://cedadocs.ceda.ac.uk/1254/1/Hatanaka\_compressed\_format\_help.pdf
*(from redmine: issue id 472, created on 2018-05-31)*Luc MaisonobeLuc Maisonobehttps://gitlab.orekit.org/orekit/orekit/-/issues/474Add support for version 3 of CCSDS Orbit Data Messages2021-04-16T16:21:36ZLuc MaisonobeAdd support for version 3 of CCSDS Orbit Data MessagesCCSDS Orbit Data Message will be updated in the near future, with
a new Orbit Comprehensive Message (OCM) in addition to the existing
OPM, OMM and OEM already supported by Orekit.
The update was presented during SpaceOps 2018 confer...CCSDS Orbit Data Message will be updated in the near future, with
a new Orbit Comprehensive Message (OCM) in addition to the existing
OPM, OMM and OEM already supported by Orekit.
The update was presented during SpaceOps 2018 conference by David
Berry (see https://arc.aiaa.org/doi/pdf/10.2514/6.2018-2456). The
paper provided a link to the current draft.
We discussed with Dave at the conference and agreed Orekit could
provide one of the prototype implementations for the standard.
*(from redmine: issue id 474, created on 2018-06-04)*11.0Luc MaisonobeLuc Maisonobe