Orekit issueshttps://gitlab.orekit.org/groups/orekit/-/issues2021-01-12T10:26:30Zhttps://gitlab.orekit.org/orekit/orekit/-/issues/448New ICGEM format with piecewise-linear cofficients for gravity fields is not ...2021-01-12T10:26:30ZLuc 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 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)*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.1https://gitlab.orekit.org/orekit/orekit/-/issues/403Add a provider generating process noise increasing in time, for better Kalman...2019-11-13T15:15:52ZLuc 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
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)*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)*https://gitlab.orekit.org/orekit/orekit/-/issues/351PartialDerivativesEquations does not work with non-Cartesian elements2019-11-13T15:24:06ZEvan WardPartialDerivativesEquations does not work with non-Cartesian elementsUsing PDE with the propagator's orbitType set to a non-Cartesian value
does not produce meaningful results. See the discussion on the dev list:
https://www.orekit.org/wws/arc/orekit-developers/2017-08/msg00010.html
One workaround is to compute the STM in Cartesian elements and then
transform it to the desired element set using equation 7.32 in
Montenbruck & Gill:
\`\`\`
STM (Keplerian) = d(kep)/d(cart) \* STM (Cartesian) \* ( d(kep)/d(cart)
)^-1
\`\`\`
Another workaround is to use a
FieldNumericalPropagator<DerivativeStructure> with the orbitType set to
the desired value, and then extract the STM from the final orbital
elements.
*(from redmine: issue id 351, created on 2017-08-11)*Using PDE with the propagator's orbitType set to a non-Cartesian value
does not produce meaningful results. See the discussion on the dev list:
https://www.orekit.org/wws/arc/orekit-developers/2017-08/msg00010.html
One workaround is to compute the STM in Cartesian elements and then
transform it to the desired element set using equation 7.32 in
Montenbruck & Gill:
\`\`\`
STM (Keplerian) = d(kep)/d(cart) \* STM (Cartesian) \* ( d(kep)/d(cart)
)^-1
\`\`\`
Another workaround is to use a
FieldNumericalPropagator<DerivativeStructure> with the orbitType set to
the desired value, and then extract the STM from the final orbital
elements.
*(from redmine: issue id 351, created on 2017-08-11)*11.0https://gitlab.orekit.org/orekit/orekit/-/issues/199improve eclipse event handling in DSST Solar Radiation Pressure2020-09-22T07:54:30ZLuc Maisonobeimprove eclipse event handling in DSST Solar Radiation PressureEclipses are currently ignored in this force model.
*(from redmine: issue id 199, created on 2015-04-30)*Eclipses are currently ignored in this force model.
*(from redmine: issue id 199, created on 2015-04-30)*