You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardexpand all lines: doc/notebooks/sgp4_propagator.ipynb
+3-13
Original file line number
Diff line number
Diff line change
@@ -123,17 +123,7 @@
123
123
"id": "1e3ec1fa-1c09-46f7-a8fe-f6da4c33edb2",
124
124
"metadata": {},
125
125
"source": [
126
-
"{py:func}`~heyoka.model.sgp4_propagator()` takes as only mandatory input argument the list of satellites, here represented as ``Satrec`` objects from the [sgp4 Python module](https://pypi.org/project/sgp4/). The list of satellites can alternatively be passed as a NumPy 2D array containing the GPE data for all satellites (see the documentation). {py:func}`~heyoka.model.sgp4_propagator()` returns a propagator object, by default of type {py:func}`~heyoka.model.sgp4_propagator_dbl()` (i.e., a double-precision propagator). You can also request a single-precision propagator via the {ref}`fp_type keyword argument <api_common_kwargs_fp_type>`.\n",
127
-
"\n",
128
-
"(tut_sgp4_propagator_epochs)=\n",
129
-
"\n",
130
-
"## A caveat on epochs and scales of time\n",
131
-
"\n",
132
-
"When an {py:func}`~heyoka.model.sgp4_propagator()` is constructed from a list of ``Satrec`` objects, the satellite epochs are represented as UTC Julian dates. Consequently, UTC Julian dates must also be used when specifying the {ref}`propagation epochs <tut_sgp4_scalar_propagation>`. The use of UTC Julian dates comes with an important caveat: UTC days do not constitute a uniform scale of time due to the potential presence of [leap seconds](https://en.wikipedia.org/wiki/Leap_second). As a consequence, if the time interval between the satellite epoch and the propagation epoch includes a leap second, the result of the propagation will be slightly wrong.\n",
133
-
"\n",
134
-
"Considering that the last leap second was added in 2016 and that leap seconds may be phased out altogether by 2035, this quirk should not manifest itself when using contemporary GPE data. For the purpose of this tutorial we will thus ignore the leap seconds issue altogether.\n",
135
-
"\n",
136
-
"If precise propagation across leap seconds is required, one should construct an {py:func}`~heyoka.model.sgp4_propagator()` not via a list of ``Satrec`` objects, but instead using the second overload which takes as input the GPE data as a NumPy 2D array. The GPE epochs in the array should be represented as Julian dates in a continuous scale of time such as [TAI](https://en.wikipedia.org/wiki/International_Atomic_Time). Similarly, the propagation epochs should be provided as Julian dates in the same scale of time. We recommend to use of a library such as [Astropy](https://docs.astropy.org/en/stable/time/index.html) to convert between UTC epochs and TAI Julian dates."
126
+
"{py:func}`~heyoka.model.sgp4_propagator()` takes as only mandatory input argument the list of satellites, here represented as ``Satrec`` objects from the [sgp4 Python module](https://pypi.org/project/sgp4/). The list of satellites can alternatively be passed as a NumPy 2D array containing the GPE data for all satellites (see the documentation). {py:func}`~heyoka.model.sgp4_propagator()` returns a propagator object, by default of type {py:func}`~heyoka.model.sgp4_propagator_dbl()` (i.e., a double-precision propagator). You can also request a single-precision propagator via the {ref}`fp_type keyword argument <api_common_kwargs_fp_type>`."
137
127
]
138
128
},
139
129
{
@@ -263,7 +253,7 @@
263
253
"source": [
264
254
"Julian dates are represented via the {py:attr}`~heyoka.model.sgp4_propagator_dbl.jdtype` type, which is a {ref}`structured NumPy datatype<numpy:defining-structured-types>` consisting of\n",
265
255
"two floating-point fields, the first one called ``jd`` and representing a Julian date, the second one called ``frac`` representing a fractional correction to ``jd`` (so that the full\n",
266
-
"Julian date is ``jd + frac``). Remember that, since we constructed the propagator from a list of ``Satrec`` objects, the Julian dates are to be provided in the UTC time scale.\n",
256
+
"Julian date is ``jd + frac``). Julian dates must be provided in the UTC scale of time, following the [SOFA](http://www.iausofa.org/)/[ERFA](https://github.com/liberfa/erfa/) convention of handling leap seconds via slightly longer/shorter days. We highly recommend the use of a library such as [Astropy](https://docs.astropy.org/en/stable/time/index.html) to convert between calendar days and UTC Julian dates.\n",
267
257
"\n",
268
258
"Although in principle we could propagate each satellite to a different date, here we will be propagating *all* satellites to the same Julian date:"
0 commit comments