Orekit issueshttps://gitlab.orekit.org/groups/orekit/-/issues2018-08-07T09:43:02Zhttps://gitlab.orekit.org/orekit/orekit/-/issues/130EME2000 orientation used at several places where ICRF orientation should be used2018-08-07T09:43:02ZLuc MaisonobeEME2000 orientation used at several places where ICRF orientation should be usedThere are several places where EME2000 orientation is used when ICRF
orientation should be used.
The first example concern the definition of ICRF itself, which was
aligned with EME2000.
Initial investigations showed that this was in fa...There are several places where EME2000 orientation is used when ICRF
orientation should be used.
The first example concern the definition of ICRF itself, which was
aligned with EME2000.
Initial investigations showed that this was in fact a consequence of a
wrong implementation of the dummy
IAU pole used for the dummy celestial bodies representing solar system
barycenter and Earth-Moon barycenter.
Further investigations showed that in fact **all** IAU poles were not
used correctly in the
JPLCelestialBody.InertiallyOriented internal class.
The orientation error corresponds to the forgotten bias between EME2000
and GCRF, as ICRF and GCRF are aligned
with each other. The main effect of this error is that the Sun direction
which is used in many places in Orekit
(eclipse computation, solar radiation pressure, Sun pointed attitude
...) is slightly wrong, to the level of a
few tens of milli-arcseconds.
*(from redmine: issue id 130, created on 2013-03-27, closed on 2013-03-27)*https://gitlab.orekit.org/orekit/orekit/-/issues/131The GTOD frame uses EOP corrections when they are not requested.2018-08-07T09:43:03ZEvan WardThe GTOD frame uses EOP corrections when they are not requested.When FramesFactory.getGTOD(false) is called the resulting frame still
uses some EOP corrections because GTODProvider always applies the time
corrections. The parent TOD frame is created without corrections.
This bug affects AdapterPropa...When FramesFactory.getGTOD(false) is called the resulting frame still
uses some EOP corrections because GTODProvider always applies the time
corrections. The parent TOD frame is created without corrections.
This bug affects AdapterPropagatorTest.testNonKeplerian
*(from redmine: issue id 131, created on 2013-04-05, closed on 2013-04-05)*https://gitlab.orekit.org/orekit/orekit/-/issues/132Adding user data to SpacecraftState2018-08-07T09:43:03ZLuc MaisonobeAdding user data to SpacecraftStateAll propagators provides a way to propagate additional state. The
analytical propagators
can register AdditionalStateProviders instances representing already
integrated states,
and integrated propagators (numerical and DSST) can regi...All propagators provides a way to propagate additional state. The
analytical propagators
can register AdditionalStateProviders instances representing already
integrated states,
and integrated propagators (numerical and DSST) can register
AdditionalEquations representin
differential equations for these states. In both cases, the output is
difficult to retrieve
and lives aparts from the SpacecraftState.
Having these data available within the SpacecraftState would be much
simpler.
A way to add user data may also prove useful outside of propagation.
*(from redmine: issue id 132, created on 2013-04-08, closed on 2013-04-08)*https://gitlab.orekit.org/orekit/orekit/-/issues/133AdditionalStateProvider should be available also in non-analytical propagators2018-08-07T09:43:04ZLuc MaisonobeAdditionalStateProvider should be available also in non-analytical propagatorsCurrently, the AdditionalStateProvider interface can be registered only
to analytical propagators
(Kepler, Eckstein-Hechler, TLE SGP4/SDP4, adapter propagator,
ephemeris).
Integration-based propagators like numerical and DSST handle a...Currently, the AdditionalStateProvider interface can be registered only
to analytical propagators
(Kepler, Eckstein-Hechler, TLE SGP4/SDP4, adapter propagator,
ephemeris).
Integration-based propagators like numerical and DSST handle additional
states only by integrating
by themselves differential equations provided by the user.
If users want to provide additional states directly to an
integration-based propagator without
having a differential equations, they cannot do it (or they need to set
up a dummy equation with
0 derivative which is awkward).
The handling of AdditionalStateProvider should be moved upward in the
propagator hierarchy.
*(from redmine: issue id 133, created on 2013-04-08, closed on 2013-04-08)*https://gitlab.orekit.org/orekit/orekit/-/issues/134Additional states are not available in events2018-08-07T09:43:05ZLuc MaisonobeAdditional states are not available in eventsWhen a user set up additional state in a propagator, these states are
available
in the step handler, but not in the event handlers. This is not natural.
A typical use case for such a feature is for example battery management.
*(from...When a user set up additional state in a propagator, these states are
available
in the step handler, but not in the event handlers. This is not natural.
A typical use case for such a feature is for example battery management.
*(from redmine: issue id 134, created on 2013-04-08, closed on 2013-04-08)*https://gitlab.orekit.org/orekit/orekit/-/issues/135CartesianOrbit meanToHyperbolicEccentric method failure2018-08-07T09:43:05ZFrancesco CacciatoreCartesianOrbit meanToHyperbolicEccentric method failureApparently resolution of hyperbolic Kepler equation would fail for the
following conditions:
- state vector =
`[-6.7884943832E7 -2.1423006112E7 -3.1603915377E7 -4732.55 -2472.086 -3022.177]`
(m,m/s);
- `mu = 324858...Apparently resolution of hyperbolic Kepler equation would fail for the
following conditions:
- state vector =
`[-6.7884943832E7 -2.1423006112E7 -3.1603915377E7 -4732.55 -2472.086 -3022.177]`
(m,m/s);
- `mu = 324858598826460` (m^3/s^2)
resulting in output hyperbolicc eccentric anomaly close to 240
rad.
This seems to be due to the initial solution chosen to start the
iterative process (H=-M). By employing Danby's initial guess to
start the iterative process the issue is solved:
`H = FastMath.log(2.0*M/e+1.8);`
*For reference*
Title: The solution of Kepler's equation. I
Authors: Danby, J. M. A. & Burkardt, T. M.
Journal: Celestial Mechanics (ISSN 0008-8714), vol. 31, Oct. 1983, p.
95-107.
http://adsabs.harvard.edu/full/1983CeMec..31...95D
http://www.cdeagle.com/omnum/pdf/demokep1.pdf
*(from redmine: issue id 135, created on 2013-04-18, closed on 2013-04-18)*
* Relations:
* relates #114Pascal ParraudPascal Parraudhttps://gitlab.orekit.org/orekit/orekit/-/issues/136Failure in propagation with eventdetectors2018-08-07T09:43:08ZPetrus HyvönenFailure in propagation with eventdetectorsHi,
On propagation with eventdetector (elevationdetector) and
EcksteinHeckler propagator, a failure occurs.
A example based on VisibilityCheck.java is attached.
Orekit 6.0 released + apache math v. 3.2 released.
Debug log below.
Re...Hi,
On propagation with eventdetector (elevationdetector) and
EcksteinHeckler propagator, a failure occurs.
A example based on VisibilityCheck.java is attached.
Orekit 6.0 released + apache math v. 3.2 released.
Debug log below.
Regards
/Petrus
JavaError: org.orekit.errors.PropagationException: function values at
endpoints do not have different signs, endpoints: \[9, 119,986\],
values: \[-0, -0,033\]
Java stacktrace:
org.orekit.errors.PropagationException: function values at endpoints do
not have different signs, endpoints: \[9, 119,986\], values: \[-0,
-0,033\]
at
org.orekit.errors.PropagationException.unwrap(PropagationException.java:108)
at
org.orekit.propagation.analytical.AbstractAnalyticalPropagator.propagate(AbstractAnalyticalPropagator.java:185)
at
org.orekit.propagation.AbstractPropagator.propagate(AbstractPropagator.java:256)
Caused by: org.apache.commons.math3.exception.NoBracketingException:
function values at endpoints do not have different signs, endpoints:
\[9, 119,986\], values: \[-0, -0,033\]
at
org.apache.commons.math3.analysis.solvers.BrentSolver.doSolve(BrentSolver.java:123)
at
org.apache.commons.math3.analysis.solvers.BaseAbstractUnivariateSolver.solve(BaseAbstractUnivariateSolver.java:196)
at
org.apache.commons.math3.analysis.solvers.BaseAbstractUnivariateSolver.solve(BaseAbstractUnivariateSolver.java:201)
at
org.orekit.propagation.events.EventState.evaluateStep(EventState.java:195)
at
org.orekit.propagation.analytical.AbstractAnalyticalPropagator.acceptStep(AbstractAnalyticalPropagator.java:278)
at
org.orekit.propagation.analytical.AbstractAnalyticalPropagator.propagate(AbstractAnalyticalPropagator.java:169)
... 1 more
org.orekit.propagation.analytical.EcksteinHechlerPropagator
*(from redmine: issue id 136, created on 2013-05-16, closed on 2013-05-16)*
* Relations:
* relates #110
* Uploads:
* [VisibilityCheck_fail.java](/uploads/aea5aae8f6dcb685e5d3505c4673572e/VisibilityCheck_fail.java) Failing example based on VisibilityCheck.java
* [issue-136-result-no-errors.txt](/uploads/f37cea01fc37416b21a121e47076cbdb/issue-136-result-no-errors.txt) output of test with additional print at event occurrenceshttps://gitlab.orekit.org/orekit/orekit/-/issues/137Conversion from Cartesian to geodetic coordinates fails for very far points.2018-08-07T09:43:09ZLuc MaisonobeConversion from Cartesian to geodetic coordinates fails for very far points.When attempting conversion from Cartesian coordinates to geodetic
coordinates for very far points (typically Sun),
the conversion fails with an internal error exception as a loop which
should always converge fails to converge.
Changin...When attempting conversion from Cartesian coordinates to geodetic
coordinates for very far points (typically Sun),
the conversion fails with an internal error exception as a loop which
should always converge fails to converge.
Changing the accuracy threshold sometimes work, but it really error
prone.
An example of such a case is:
@Test
public void testFarPoint() throws OrekitException {
AbsoluteDate date = AbsoluteDate.J2000_EPOCH;
Frame frame = FramesFactory.getITRF2005(true);
OneAxisEllipsoid model = new OneAxisEllipsoid(90.0, 5.0 / 9.0, frame);
Vector3D point = new Vector3D(1.0e15, 2.0e15, -1.0e12);
GeodeticPoint gp = model.transform(point, frame, date);
Vector3D rebuilt = model.transform(gp);
Assert.assertEquals(0.0, rebuilt.distance(point), 1.0e-15 * point.getNorm());
}
*(from redmine: issue id 137, created on 2013-05-18, closed on 2013-05-18)*https://gitlab.orekit.org/orekit/orekit/-/issues/138Problem with post-processing event detection2018-08-07T09:43:10ZSylvain RouardProblem with post-processing event detectionWe found a strange behaviour when adding 2 instances of the same event
detector to a propagator generated by a previous Ephemeris mode
propagation.
A simple example to illustrate this issue:
double a = 800000 + Constants.WGS84_...We found a strange behaviour when adding 2 instances of the same event
detector to a propagator generated by a previous Ephemeris mode
propagation.
A simple example to illustrate this issue:
double a = 800000 + Constants.WGS84_EARTH_EQUATORIAL_RADIUS;
double e = 0.0001;
double i = FastMath.toRadians(98);
double w = -90;
double raan = 0;
double v = 0;
Frame inertialFrame = FramesFactory.getEME2000();
AbsoluteDate initialDate = new AbsoluteDate(2014, 01, 01, 0, 0, 0, TimeScalesFactory.getUTC());
AbsoluteDate finalDate = initialDate.shiftedBy(5000);
KeplerianOrbit initialOrbit = new KeplerianOrbit(a, e, i, w, raan, v, PositionAngle.TRUE, inertialFrame, initialDate, Constants.WGS84_EARTH_MU);
SpacecraftState initialState = new SpacecraftState(initialOrbit, 1000);
double[][] tol = NumericalPropagator.tolerances(10, initialOrbit, initialOrbit.getType());
AdaptiveStepsizeIntegrator integrator = new DormandPrince853Integrator(0.001, 1000, tol[0], tol[1]);
NumericalPropagator propagator = new NumericalPropagator(integrator);
propagator.setInitialState(initialState);
// Define 2 instances of NodeDetector:
EventDetector node1 = new NodeDetector(1e-6,initialState.getOrbit(), initialState.getFrame()){
private static final long serialVersionUID = -5495471556543226249L;
public Action eventOccurred(final SpacecraftState s, final boolean increasing)
throws OrekitException {
System.out.println("node crossing - detector1: Date ="+s.getDate()+" / Z inertial = "+s.getPVCoordinates().getPosition().getZ());
return Action.CONTINUE;
}
};
EventDetector node2 = new NodeDetector(1e-6,initialState.getOrbit(), initialState.getFrame()){
private static final long serialVersionUID = -7979764548288236088L;
public Action eventOccurred(final SpacecraftState s, final boolean increasing)
throws OrekitException {
System.out.println("node crossing - detector2: Date ="+s.getDate()+" / Z inertial = "+s.getPVCoordinates().getPosition().getZ());
return Action.CONTINUE;
};
};
propagator.addEventDetector(node1);
propagator.addEventDetector(node2);
// First propagation
propagator.setEphemerisMode();
System.out.println("StartDate = "+initialDate+" / End Date = "+finalDate);
propagator.propagate(finalDate);
BoundedPropagator postpro = propagator.getGeneratedEphemeris();
// Post-processing
System.out.println("Post-processing: ");
postpro.addEventDetector(node1);
postpro.addEventDetector(node2);
postpro.propagate(finalDate);
The console output is:
StartDate = 2014-01-01T00:00:00.000 / End Date = 2014-01-01T01:23:20.000
node crossing - detector1: Date =2014-01-01T00:32:40.476 / Z inertial = 8.669672720972587E-8
node crossing - detector2: Date =2014-01-01T00:32:40.476 / Z inertial = 8.669672720972587E-8
node crossing - detector1: Date =2014-01-01T01:23:07.027 / Z inertial = -3.9502712349237726E-8
node crossing - detector2: Date =2014-01-01T01:23:07.027 / Z inertial = -3.9502712349237726E-8
Post-processing:
node crossing - detector1: Date =2014-01-01T00:32:40.476 / Z inertial = 0.007229913089589053
node crossing - detector1: Date =2014-01-01T01:23:07.027 / Z inertial = -3.9502712349237726E-8
node crossing - detector2: Date =2014-01-01T01:23:20.000 / Z inertial = -95730.44875635671
No issue during the first propagation, but during the second one,
detector2 only returns the final SpacecraftState.
I also tried to run the second propagation in MasterMode, with a
FixedStepHandler =>detector2 will go through eventOccurred() for
each step, instead of each node.
*(from redmine: issue id 138, created on 2013-05-31, closed on 2013-05-31)*https://gitlab.orekit.org/orekit/orekit/-/issues/139using XML-based Earth Orientation Parameters in a zip file triggers an exception2018-08-07T09:43:10ZLuc Maisonobeusing XML-based Earth Orientation Parameters in a zip file triggers an exceptionWhen EOP data is parsed from an XML file, it works well as long as the
file is in a regular directories hierarchy, but fails when the file is
in a zip archive.
In this case, an exception is triggered while loading the data, as the
globa...When EOP data is parsed from an XML file, it works well as long as the
file is in a regular directories hierarchy, but fails when the file is
in a zip archive.
In this case, an exception is triggered while loading the data, as the
global stream used to read the archive is automatically closed when the
archive entry corresponding to the XML file is read. This prevents the
analysis of the rest of the archive to be completed properly.
*(from redmine: issue id 139, created on 2013-06-04, closed on 2013-06-04)*https://gitlab.orekit.org/orekit/orekit/-/issues/140Error while transforming osculating parameters into mean TLE2018-08-07T09:43:12ZJuan Carlos DoladoError while transforming osculating parameters into mean TLELors de la transformation TLE ->Osc ->TLE du TLE suivant
1 19858U 76077FL 10001.61249236 -.00047525 00000-0 -26271-1 0 9133
2 19858 103.3140 212.2317 0236482 203.2554 155.7430 13.98406682927728
On obtient l'erreur
Exception in threa...Lors de la transformation TLE ->Osc ->TLE du TLE suivant
1 19858U 76077FL 10001.61249236 -.00047525 00000-0 -26271-1 0 9133
2 19858 103.3140 212.2317 0236482 203.2554 155.7430 13.98406682927728
On obtient l'erreur
Exception in thread "main" org.orekit.errors.PropagationException:
réinitialisation de l'état non autorisée
at
org.orekit.propagation.analytical.tle.TLEPropagator.resetInitialState(TLEPropagator.java:471)
at
org.orekit.propagation.conversion.OsculatingToMeanElementsConverter.convert(OsculatingToMeanElementsConverter.java:66)
at MAIN.transformTLE2MeanTLE(MAIN.java:110)
at MAIN.main(MAIN.java:39)
Le code utilisé pour faire cette transformation est:
\_\_final TLEPropagator propagator =
TLEPropagator.selectExtrapolator(tle);
final PVCoordinates pvOsc = propagator.getPVCoordinates(finalDate);
System.out.println("Osculating parameters at epoch " + finalDate);
System.out.println("X " + pvOsc.getPosition().getX());
System.out.println("Y " + pvOsc.getPosition().getY());
System.out.println("Z " + pvOsc.getPosition().getZ());
System.out.println("Vx " + pvOsc.getVelocity().getX());
System.out.println("Vy " + pvOsc.getVelocity().getY());
System.out.println("Vz " + pvOsc.getVelocity().getZ());
// Conversion from osculating elements to mean elements (in TLE sense)
final SpacecraftState oscState = new SpacecraftState(new
CartesianOrbit(pvOsc, frameTEME, finalDate,
CelestialBodyFactory.getEarth().getGM()));
final SpacecraftState meanState = new OsculatingToMeanElementsConverter
(oscState, 1, propagator).convert();**\_
\_
Ceci semblerait être un bug.
*(from redmine: issue id 140, created on 2013-07-05, closed on 2013-07-05)*https://gitlab.orekit.org/orekit/orekit/-/issues/141non-bracketing exception while converting Cartesian point to geodetic coordin...2018-08-07T09:43:13ZLuc Maisonobenon-bracketing exception while converting Cartesian point to geodetic coordinatesThe following test case triggers an exception in the Apache commons Math
solver:
`AbsoluteDate date = new AbsoluteDate("2002-03-06T20:50:20.44188731559965033", TimeScalesFactory.getUTC());
Frame frame = FramesFactory.getGTOD(fal...The following test case triggers an exception in the Apache commons Math
solver:
`AbsoluteDate date = new AbsoluteDate("2002-03-06T20:50:20.44188731559965033", TimeScalesFactory.getUTC());
Frame frame = FramesFactory.getGTOD(false);
OneAxisEllipsoid model = new OneAxisEllipsoid(Constants.WGS84_EARTH_EQUATORIAL_RADIUS,
Constants.WGS84_EARTH_FLATTENING,
frame);
Vector3D point = new Vector3D(-6838696.282102453, -2148321.403361013, -0.011907944179711194);
GeodeticPoint gp = model.transform(point, frame, date);`
The problem is that the point is very close to equator, but not close
enough to be handled by the dedicated branch in the OneAxisEllipsoid
class, it is still handled by the general purpose branch which uses a
solver. When the solver is set up, its search interval is set up to the
length of the ellipse evolute, as it is known the intersection of nadir
and equator will remain in this interval. Since the point is already
very close to the equator, the final point will be at the very end of
the interval, near the cusp of the evolute. Due to numerical issues, the
function computed does not really crosses 0 and is very sligthly
positive (10^-12) at the cusp. So the interval does not really bracket
the root.
*(from redmine: issue id 141, created on 2013-07-11, closed on 2013-07-11)*https://gitlab.orekit.org/orekit/orekit/-/issues/142AbsoluteDate.JAVA_EPOCH returns Incorrect Time2018-08-07T09:43:13ZMatt EdwardsAbsoluteDate.JAVA_EPOCH returns Incorrect TimeDue to the linear model of offset between UTC and TAI (introduced in
commit e8421aa) the java doc for AbsoluteDate.JAVA\_EPOCH (commit
3098823c) is incorrect in its assertion that this returns a UTC date,
and that UTC and TAI are synchro...Due to the linear model of offset between UTC and TAI (introduced in
commit e8421aa) the java doc for AbsoluteDate.JAVA\_EPOCH (commit
3098823c) is incorrect in its assertion that this returns a UTC date,
and that UTC and TAI are synchronous prior to 1972. Calling this creates
an AbsoluteDate that is shifted 8 seconds in UTC. A simple test is as
follows:
public static void main(String\[\] args) {
AbsoluteDate epoch = AbsoluteDate.JAVA\_EPOCH;
System.out.println(epoch.toString(TimeScalesFactory.getTAI()));
System.out.println(epoch.JAVA\_EPOCH.toString());
//Milliseconds - April 1, 2006
long msOffset = 1143849600000l;
AbsoluteDate ad;
try {
ad = new AbsoluteDate(epoch, msOffset/1000,
TimeScalesFactory.getUTC());
System.out.println(ad);
} catch (OrekitException e) {
e.printStackTrace();
}
AbsoluteDate ad\_2 = new AbsoluteDate(epoch, msOffset/1000,
TimeScalesFactory.getTAI());
System.out.println(ad\_2);
}
Yields the following output:
1970-01-01T00:00:00.000
1969-12-31T23:59:52.000
2006-03-31T23:59:52.000
2006-03-31T23:59:27.000
The final result makes the most sense, given the offset is 33 seconds
for April 1 2006. The other results display the 8 second shift from the
linear model in the UTC frame.
A suitable workaround for the moment is to build a new epoch from the
Date/Time Components.
AbsoluteDate java\_epoch = new AbsoluteDate(DateComponents.JAVA\_EPOCH,
TimeComponents.H00, TimeScalesFactory.getUTC());
AbsoluteDate ad = new AbsoluteDate(java\_epoch, offset,
TimeScalesFactory.getUTC());
*(from redmine: issue id 142, created on 2013-08-06, closed on 2013-08-06)*https://gitlab.orekit.org/orekit/orekit/-/issues/143Frame transformation problem from TEME to EME20002018-08-07T09:43:16ZJuan Carlos DoladoFrame transformation problem from TEME to EME2000During the propagation of a group of TLEs, an abnormal behavior has been
observed. Imagine that we have two different TLE to be propagated (A and
B), being the intersection of the propagation time span of both objects
not zero (i.e. 28/0...During the propagation of a group of TLEs, an abnormal behavior has been
observed. Imagine that we have two different TLE to be propagated (A and
B), being the intersection of the propagation time span of both objects
not zero (i.e. 28/05/2012 to 09/08/2012 for A and 23/03/2012 to
06/06/2012 for B). The result of the propagation is an ephemeris defined
in a given reference frame.
When the reference frame, in which the output ephemeris is expressed, is
the same than the input reference frame (i.e. TEME), no matter the order
in which the propagation is performed (i.e. A and B or B and A) the
output ephemeris for A and B are always the same. When the output
ephemeris is expressed in a different reference frame than the input one
(e.g. EME2000) differences are found on the propagated ephemeris
depending on the order of the propagation (i.e. A\_ephemeris propagating
A and B is not the same than A\_ephemeris propagation B and A).
This behavior is not reproduced when the propagation time span of both
objects are very different.
*(from redmine: issue id 143, created on 2013-08-07, closed on 2013-08-07)*
* Uploads:
* [getPVCoordinates_Anomaly.zip](/uploads/fe3b54038006ff2dd044addd41d4c89f/getPVCoordinates_Anomaly.zip) Java Projet highlighting this behaviourhttps://gitlab.orekit.org/orekit/orekit/-/issues/144Small suggestion elevation detector getElevation() method2018-08-07T09:43:19ZPetrus HyvönenSmall suggestion elevation detector getElevation() methodHi,
This might be a bad idea depending on view, could a method be added to
ElevationDetector getElevation(az) to get same interface as getElevation
in the GroundMaskElevationDetector? az would just be ignored but give a
transparent inte...Hi,
This might be a bad idea depending on view, could a method be added to
ElevationDetector getElevation(az) to get same interface as getElevation
in the GroundMaskElevationDetector? az would just be ignored but give a
transparent interface between the two?
*(from redmine: issue id 144, created on 2013-08-22, closed on 2013-08-22)*
* Uploads:
* [Issue144Files_20131115.zip](/uploads/8a18eb55c331538479ac404203032c9c/Issue144Files_20131115.zip)https://gitlab.orekit.org/orekit/orekit/-/issues/145computeLimitVisibilityPoint misinterprets Azimuth2018-08-07T09:43:20ZPetrus HyvönencomputeLimitVisibilityPoint misinterprets AzimuthThe following (python) code using orekit as of aug 22:
ITRF2005 = FramesFactory.getITRF2005()
earth = OneAxisEllipsoid(Constants.WGS84\_EARTH\_EQUATORIAL\_RADIUS,
...: Constants.WGS84\_EARTH\_FLATTENING,
...: ITRF2005)
...: staFr...The following (python) code using orekit as of aug 22:
ITRF2005 = FramesFactory.getITRF2005()
earth = OneAxisEllipsoid(Constants.WGS84\_EARTH\_EQUATORIAL\_RADIUS,
...: Constants.WGS84\_EARTH\_FLATTENING,
...: ITRF2005)
...: staFrame = TopocentricFrame(earth, GeodeticPoint(0.0,0.0,0.0),
'test')
print
staFrame.computeLimitVisibilityPoint(Constants.WGS84\_EARTH\_EQUATORIAL\_RADIUS+600000,
0.0,5.0)
{lat: 0 deg, lon: 148,4942265118 deg, alt: 599�999,9999999991}
staFrame.getNorth()
Out\[65\]: <Vector3D: {-0; -0; 1}>
The direction to the point should be in latitude direction (Azimuth 0.0
is assumed north)
Luc comment from mailinglist: A very quick look makes me think there is
an inconsistency between the pointAtDistance method and the other ones
like getAzimuth/getElevation) about how the frame is oriented.
*(from redmine: issue id 145, created on 2013-08-22, closed on 2013-08-22)*https://gitlab.orekit.org/orekit/orekit/-/issues/148overflow in TimeComponents extraction2018-08-07T09:45:35ZLuc Maisonobeoverflow in TimeComponents extractionWhen using the constructor TimeComponents(final int secondInDayA, final
double secondInDayB),
the computation of the components can overflow.
This happens with the following code snippet, which repesents a date
during a leap second:
...When using the constructor TimeComponents(final int secondInDayA, final
double secondInDayB),
the computation of the components can overflow.
This happens with the following code snippet, which repesents a date
during a leap second:
AbsoluteDate t0 = new AbsoluteDate(2012, 6, 30, 23, 59, 50.0, utc);
DateTimeComponents components = t0.shiftedBy(11.0 - 200 * Precision.EPSILON).getComponents(utc);
The problem is linked to the computation of secondInDayA + secondInDayB
when secondInDayA is
quite large (in this case 86399) and secondInDayB is just below an
integer (here 1.0 - 200ε).
The tiny 200ε disappears when the sum is computed, so the hour wraps
around 24h.
*(from redmine: issue id 148, created on 2013-09-30, closed on 2013-09-30)*https://gitlab.orekit.org/orekit/orekit/-/issues/149wrong date/time split2020-04-22T14:18:00ZLuc Maisonobewrong date/time splitThe following code snippet shows a badly split date:
AbsoluteDate t0 = new AbsoluteDate(2012, 6, 30, 23, 59, 59, utc);
DateTimeComponents components = t0.shiftedBy(1.0 - Precision.EPSILON).getComponents(utc);
The date is just b...The following code snippet shows a badly split date:
AbsoluteDate t0 = new AbsoluteDate(2012, 6, 30, 23, 59, 59, utc);
DateTimeComponents components = t0.shiftedBy(1.0 - Precision.EPSILON).getComponents(utc);
The date is just before a leap seconds introduction in 2012. As the
DateTimeComponents are extracted,
the date is considered to be already on 2012-07-01 despite it really is
still in 2012-06-30, and even
still before the leap seconds introduction (so the next day will start
only one second later).
Note that this bug is **not** related to issue \#148, despite they look
similar. Here the problem occurs
before time components are built.
*(from redmine: issue id 149, created on 2013-09-30, closed on 2013-09-30)*https://gitlab.orekit.org/orekit/orekit/-/issues/150missing correction in Equation Of Equinoxes2018-08-07T09:43:23ZLuc Maisonobemissing correction in Equation Of EquinoxesThe Equation Of Equinoxes adds the periodic nutation components to the
sidereal time,
thus changing the GMST (mean) into GAST (apparent).
The equation involves a ΔΨ cos(ε₀) part. In the current version of
Orekit, the correction
part...The Equation Of Equinoxes adds the periodic nutation components to the
sidereal time,
thus changing the GMST (mean) into GAST (apparent).
The equation involves a ΔΨ cos(ε₀) part. In the current version of
Orekit, the correction
part δΔΨ read in the EOP file is not included in the ΔΨ, which
introduces an error in longitude.
Comparing ITRF computation from equinox paradigm and Non-Rotating Origin
shows this effect
to be the dominant error (about 1 milli arcsecond for IERS 2010
conventions). Of course, the
error disappears when EOP files are not available.
Looking in the SOFA manual examples also shows the correction should be
included, as part
of the code in section 5.2 "IAU 1976/1980/1982/1994, equinox based"
reads:
* Equation of the equinoxes, including nutation correction.
EE = iau_EQEQ94 ( DJMJD0, TT ) + DDP80 * COS ( EPSA )
*(from redmine: issue id 150, created on 2013-10-01, closed on 2013-10-01)*https://gitlab.orekit.org/orekit/orekit/-/issues/151Error while performing the conversion KeplerianOrbit -> EquinoctialOrbit -> K...2018-08-07T09:43:24ZLucian BarbulescuError while performing the conversion KeplerianOrbit -> EquinoctialOrbit -> KeplerianOrbitThere seems to be a problem with the converison when the inclination of
the orbit is 0 and the RAAN is not 0. For example, if the initial
keplerian orbit is:
- a = 13378.0
- e = 0.05
- i = 0.0
- **raan = 180.0**
- **pa = 0.0**...There seems to be a problem with the converison when the inclination of
the orbit is 0 and the RAAN is not 0. For example, if the initial
keplerian orbit is:
- a = 13378.0
- e = 0.05
- i = 0.0
- **raan = 180.0**
- **pa = 0.0**
- ma = 0.0
after the double conversion the result is:
- a = 13378.0
- e = 0.05
- i = 0.0
- **raan = 0.0**
- **pa = 0.0**
- ma = 0.0
Since the inclination is 0 then the RAAN is undefined and the value 0 is
used correctly. However, in this case, the value of pa should be 180 and
not 0.
*(from redmine: issue id 151, created on 2013-11-13, closed on 2013-11-13)*