¿Qué causó el problema del día del año del elemento de dos líneas de la ISS a partir del 24 de diciembre de 2019?

¿Alguien sabe que sucedió en NORAD o NASA o dondequiera que se originen los TLE publicados, que causó la inestabilidad del TLE de la ISS durante la última semana de 2019? No sucedió en 2018. ¿Qué pasó? El día del año aumentó más allá de los 365 días (no es un año bisiesto), y el año permaneció 19 (2019), para los conjuntos de TLE computados que entraron y pasaron la primera semana del año 2020.

Obtengo mis juegos ISS TLE de aquí:

https://spaceflight.nasa.gov/realdata/sightings/SSapplications/Post/JavaSSOP/orbit/ISS/SVPOST.html

y aquí:

https://tle.info/data/ISS_DATA.TXT

Mi código ahora corrige esas fechas TLE almacenadas en mi archivo, después de dos días de reescribir un código para buscarlo la próxima vez (y, por otro lado, me llamó la atención sobre algunos problemas futuros ocultos que ahora también están solucionados) . Pero me gustaría saber si fue solo un contratiempo, o hay algún cambio en el formato en curso, siendo 'probado'? A partir del 1/2/2020, los TLE que recibí hoy ahora están de vuelta en el formato esperado, ya no se hace referencia a ellos como días de 2019 más allá de 365.

¿La palabra oficial?

Entienda, estoy muy agradecido de que tengamos todos estos maravillosos servicios disponibles, y que ya no tenga que entrecerrar los ojos para leer los informes en papel de Greenbelt, MD, o escribirlos manualmente, como era necesario hace tantos años (pero incluso entonces, agradecido por eso). Quisiera saber si hay cambios en las obras que podría estar preparando con anticipación. Y muchas gracias a todos aquellos que mantienen los servidores, los servicios y las herramientas de software que tanto apreciamos aquí.

Actualización 1-2-2020

En respuesta a la solicitud de uhoh en los comentarios, aquí hay tres conjuntos de TLE de muestra adquiridos el 30-12-2019, pero el problema se vio por primera vez el 24-12-2019, de los enlaces mencionados anteriormente. Tenga en cuenta el primero aquí (que no fue el primer TLE en la página web, pero estoy condensando). Está bien. Pero los otros, de los cuales muestro dos, tienen 2019 como año (por supuesto, los primeros 20 no se muestran en el formato estándar), pero luego el día del año es 366 (no un año bisiesto), y luego en el último TLE, el día del año es 372? Y el año sigue siendo 19. Lo que yo llamo 'torpe'.

ISS
1 25544U 98067A   19365.78947330  .00016717  00000-0  10270-3 0  9114
2 25544  51.6407 101.7439 0005315  86.0590 274.1168 15.49502788  5904

ISS
1 25544U 98067A   19366.82137887  .00016717  00000-0  10270-3 0  9129
2 25544  51.6392  96.6358 0005156  88.7140 271.4601 15.49497216  6061

.
.
.

ISS
1 25544U 98067A   19372.17436792  .00016717  00000-0  10270-3 0  9187
2 25544  51.6415  70.1365 0004825 107.1627 253.0051 15.49525362  6890

Modifiqué mi código para capturar y corregir esto al leer de mis archivos, por supuesto, también recalculé la suma de verificación, ya que mis archivos conservan los 'inestables' como los obtuve por primera vez. (Para aquellos que están ansiosos por hacer la pregunta, sí, me olvidé de volver a calcular la suma de verificación en el primer intento). Aquí está la versión procesada de ese último conjunto, que ahora funciona bien con pyephem (que me alegro sin rodeos de que no le haya gustado la suma de verificación incorrecta):

ISS
1 25544U 98067A   20007.17436792  .00016717  00000-0  10270-3 0  9184
2 25544  51.6415  70.1365 0004825 107.1627 253.0051 15.49525362  6890

Estaría feliz de proporcionar más detalles o código, si ayudaran, pero principalmente estoy preguntando si alguien sabe si esto fue solo un problema de procesamiento de fin de año, como una cosa mini y2k, o si hay algunos cambios en el formato en las obras, y no estaban listos para el horario de máxima audiencia? Como la mayoría de las personas, prefiero codificar con anticipación para un cambio próximo conocido, que ser sorprendido por él. Y ese es el motivo parcial de mi pregunta.

Actualización 1-4-2020:

Ahora lea el informe de seguimiento espacial n.° 3 para obtener más información. Para los interesados, el enlace está aquí:

https://celestrak.org/NORAD/documentation/spacetrk.pdf

A medida que sigo investigando esto, sigo esperando y agradeciendo y agradeciendo más información de los demás.

Aunque todavía no tengo mi respuesta, una conclusión práctica de este tema es que otros sean conscientes de que el doy > días del año objetivo en una situación de año es una posible fecha de época que se puede encontrar en TLE en la última semana de ese año, o incluso comenzando el año anterior (?! ya que aún no hemos determinado si hay un límite fijo fijo inferior a 999 antes de que se incremente el año y el doy se ajuste correctamente para ese incremento de año), y así la base de código propia necesita tratar con él donde sea que pueda causar problemas, si ocurre inesperadamente. IOTW, escriba el código para esperarlo.

@uhoh en respuesta a su comentario, agregué una actualización hoy con algunas muestras.
Cualquiera que sea el motivo de estos datos en particular, las funciones de conversión de datos de su lenguaje de programación deberían poder manejarlo. Es muy común referirse a cosas como 'día -1' para el último día del último mes o '34 de octubre' para referirse al tercer día de noviembre. Es muy conveniente con los cálculos.
@asdfex después de leer varias fuentes que brindan una clave para comprender los datos en las diversas posiciones de un conjunto de elementos de dos líneas, aún no he encontrado ningún detalle como su Es muy común referirse a cosas como 'día -1' para el último día del último mes o '34 de octubre' para referirse al tercer día de noviembre. . Creo que no soy el único a quien le gustaría que se expresara de manera más clara, simple y oficial en las muchas páginas que están ahí para informarnos. Gracias por inspirar a llenar ese vacío con tu comentario.
Si de hecho es, como se ha dicho, "muy común", esto plantea la pregunta: "¿Hasta qué punto fuera de los rangos esperados estándar en este contexto, se puede esperar razonablemente que la fecha de época de un tle oficial se desvíe fuera de los rangos esperados culturalmente comunes del ¿Calendario gregoriano? ¿Cinco días? ¿Nueve semanas? ¿Menos de 999 días? ¿Hay algún documento que aclare esto? Podría resultar inmensamente útil al diseñar código y escribir pruebas para ese código.
Mi comentario fue sobre trabajar con objetos de fecha en cualquier tipo de software, no específicamente sobre TLE.
@asdfex está bien. Comprendido. Mi código hace un uso extensivo de tales funciones. Lo inesperado fue que los datos reales publicados se salieran de un rango razonablemente esperado, basados ​​en documentos que brindan una clave para comprender los valores e implican que los rangos están dentro de límites culturalmente aceptados. Un valor de día del año de 372 para el año 2019 no es el límite normal culturalmente aceptado para días en un año calendario gregoriano. De ahí mi OP. ¿Es un doy de 372 para 2019 realmente mejor para presentar una usabilidad clara y no confusa de los datos? Incluso una nota a pie de página en una clave de formato de archivo ayudaría. ¿Sí?
@always_learning Solo mira la especificación. Io y he aquí, hay múltiples. Una cosa que todos tienen en común es que la época es el día juliano + fracción, dada como tres caracteres en el rango [0-9]. Así que 999 es definitivamente el mayor número aceptable, no se permiten números negativos. STK también dice que el valor más grande permitido es 366, una restricción que está ausente en la especificación NORAD. Entonces, si implementa estrictamente la especificación NORAD, debe permitir días hasta 999.
@polygnome, ¿sería tan amable de darnos un enlace a la especificación NORAD y la especificación STK, para que otros lectores puedan leer exactamente lo que acaba de mencionar? Dado que aún no se ha publicado nada como respuesta, intentaré resumir lo que se ha dicho hasta ahora, como una primera publicación de una respuesta.
@always_learning Los valores> 366 que no están prohibidos en los TLE difícilmente responden a la pregunta de por qué realmente hicieron eso, o por qué se detuvieron en 372 y luego se desbordaron. Es por eso que no he publicado una respuesta, esta es información complementaria.
@polygnome Estoy de acuerdo. Todavía no tengo una conclusión, pero estoy intentando hacer un resumen, después de leer un par de artículos mañana. Quizá despierte algunas ideas. Si NORAD no ha cambiado su algoritmo en años, uno podría concluir que simplemente debemos asegurarnos de que nuestro código pueda manejar la situación adecuadamente. Técnicamente, el TLE expresado de cualquier manera da como resultado la misma trayectoria orbital, pero eso deja mi pregunta aún sin respuesta. Si es un resultado posible, ocasionalmente, de SGP4, o fechas julianas... lo que es seguro es que las fechas familiares humanas necesitarán un código adicional para verificar y convertir cuando sea necesario.
@always_learning Creo que la pregunta de interés más convincente para los lectores del sitio sería una pregunta objetiva sobre los rangos permitidos de TLE en diferentes contextos, y eso permitiría que Polygnome publique una respuesta informativa para todos. Puede modificar su título para que eso suceda. Sin embargo, si lo que es más importante para su pregunta es "¿Qué causó..." en spaceflight.nasa.gov (que puede ser difícil de encontrar y, en última instancia, trivial y sin interés), entonces puede dejarlo como está.
@uhoh muy buenos puntos. Tengo una edición casi lista. También después de haber revisado el spacetrackreport 3 y el código fortran, creo que tengo una pista sobre la causa. Como usted dice, es posible que no escuche directamente de la NASA o NORAD, pero espero que mi especulación sea suficiente para que otros entiendan que el día del año puede hacer esto al final del año en función de la frecuencia con la que realizan ejecuciones adicionales para generar los TLE que conducen a la actualización se ejecutan el 1 o el 2 de enero. Todo se reduce a lo que se alimenta a su programa de llamada y cuándo se ejecuta una actualización. Entraré más en eso cuando termine de escribirlo.
@uhoh Ya hay publicaciones sobre qué tan lejos en el futuro una época TLE puede seguir siendo precisa, etc., con contribuciones de... usted. No estoy buscando construir más puntos si eso significa repetir un tema, por lo que puedo dejar la pregunta como está y concluir con lo que puede ser la respuesta trivial, pero esa respuesta fue una picazón que necesitaba rascarme. Al ver las subrutinas, el CONDUCTOR, etc. en el informe, comenzó a enfocarlo. Una simple cuestión, quizás, de cuántos TLE en el futuro se producen a partir de la fecha de ejecución inicial del trabajo, donde el código de llamada ve este problema de fin de año como, sí, trivial.
La mayoría de estos comentarios míos desaparecerán cuando publique la 'respuesta' resumida, ya que incluirá las partes relevantes en un resumen. Hasta entonces, se aceptan más sugerencias.

Respuestas (1)

El propagador SGP4 en realidad no usa el día del año (solo la hora desde la época), por lo que un valor más allá de 366 está bien. Algunas personas pueden agregar algunas comprobaciones a un TLE para generar esto como un error, pero el propio propagador no vería ningún problema en ello. Además, si desea ver cuánto "tiempo desde la época" hay entre la época de TLE y una fecha determinada, es posible que tenga problemas para usar uno de esos TLE, pero, de nuevo, esto no es un problema con el TLE ni con SGP4.

Supongo que el problema es con el software de generación de TLE (que NORAD no revela). Probablemente propagan la órbita de la ISS hacia el futuro utilizando mejores métodos numéricos y ajustan un TLE a una combinación de posiciones reales y propagadas, pero colocan la época cerca del final de la ventana de ajuste. Posiblemente, dependiendo de cuánto tiempo se supone que es la ventana y cuándo se generó el TLE, terminarían generando una época que tiene lugar "el próximo año", pero el software no toca el campo del año, solo el día de campo de año.

Otro script/programa podría solucionarlo, y posiblemente el software/servidor se movió o actualizó, y tal vez alguien no se dio cuenta de que era necesario o que no se estaba ejecutando. Tal vez alguien lo deshabilitó para mejorar el rendimiento porque "nunca" se necesita y se olvidó de volver a habilitarlo.

Tenga en cuenta que esto es parcialmente especulación, pero, de nuevo, nos preguntamos por qué un software no divulgado presentó un resultado que no es necesariamente un problema (aunque estoy de acuerdo en que debería solucionarse).

+1"El propagador SGP4 en realidad no usa el día del año (solo el tiempo desde la época)..." ¡Guau, nunca me di cuenta de esto por completo hasta ahora! Sí, una revisión rápida de Revisiting Spacetrack Report #3 muestra solo armónicos zonales (J2, J3, J4) y no tesserales que luego requerirían conocer el tiempo absoluto y un modelo para la rotación de la Tierra, y las expresiones siempre se expanden sobre (t -t_cero).
Bueno, después de haber estado ocupado últimamente, y ahora viendo esto, son aproximadamente 3/4 de lo que ahora estoy editando por cuarta vez. Así que parece que todos estamos generalmente en la misma página. Estoy haciendo algunos ejemplos gráficos para aclarar aún más el punto, pero es posible que no se publique hasta dentro de una semana. Y estoy tomando una época ideal de TLE años atrás para llevar el doy del año a cerca de 999, para verlo funcionar, y mostrar nuevamente que una época es principalmente una instantánea de un momento en el tiempo. Como dice spacetrack rpt3, algunos componentes de él, para órbitas profundas, usan un desplazamiento de 0.0 de enero de 1950 para tener en cuenta la gravedad del sol y la luna.
... Y una variable recurrente de TSINCE en el código fortran IV de la mayoría de las subrutinas. Un momento definitorio en el tiempo, y el tiempo desde ese momento luego define el momento actual de interés.
¿Qué causó el problema del día del año del elemento de dos líneas de la ISS a partir del 24 de diciembre de 2019?
RespuestasAquíPolítica de privacidad1y, 0v