Astropy: Python for Astronomy

Hola, soy Alex de DEV STORIES DOT EU. Astropy: Python para Astronomía, episodio 1 de 15. Probablemente hayas multiplicado un array de NumPy por una constante. Pero si accidentalmente mezclas metros y kilómetros en una ecuación compleja, Python no te avisará, y tu array final simplemente contendrá los números equivocados. Dejar que la librería gestione las dimensiones físicas automáticamente es exactamente de lo que trata este episodio. Vamos a ver el corazón de Astropy: Units y Quantities. Astropy gestiona las unidades físicas a través del objeto Quantity. Un Quantity vincula un número, o un array de números, a una unidad física. Como un Quantity es una subclase directa de un ndarray de NumPy, no pierdes nada de rendimiento ni funcionalidad de array. Puedes hacer slice, broadcast y ejecutar funciones matemáticas estándar de NumPy sobre ellos de forma nativa. Se comportan como arrays normales que, simplemente, saben qué propiedad física representan. Para crear un Quantity, importas el módulo units de Astropy. Luego, simplemente multiplicas tu número por el objeto unit específico. Tres multiplicado por units punto parsec crea un Quantity de tres parsecs. Muchos developers asumen que esta abstracción es lenta, lo cual es un error muy común. Es cierto que multiplicar un array de NumPy enorme por un objeto unit crea una nueva copia de ese array en memoria. Para evitar este overhead, Astropy hace override del bitwise left-shift operator, que se ve como dos signos de menor que. Pones tu array existente a la izquierda, el left-shift operator en el medio, y el unit de Astropy a la derecha. Esto adjunta el unit al array in place, sin copiar los datos subyacentes. Aquí está la clave. La librería evalúa las relaciones matemáticas entre los units a medida que haces los cálculos. Supón que quieres calcular el tiempo de viaje de una nave espacial. Tu distancia es de tres punto cero parsecs. Tu velocidad es de ciento treinta kilómetros por segundo. Creas un Quantity para la distancia y lo divides por el Quantity de la velocidad. Astropy devuelve un nuevo Quantity para el tiempo. Gestiona la división de los valores y calcula el unit resultante, devolviendo parsec segundos por kilómetro. Ese unit resultante es matemáticamente correcto, pero no es muy útil al leerlo. Puedes cambiar esto usando el método to, disponible en cada Quantity. Llamas al método to y le pasas tu unit de destino, como units punto year. Astropy verifica que las dimensiones de origen y destino sean ambas units de tiempo, hace la conversión interna, y devuelve un nuevo Quantity expresado en años. Para estandarizaciones rápidas, también puedes acceder a las properties punto SI o punto CGS en cualquier Quantity, para convertirlo inmediatamente a los base units de esos sistemas. Cuando haces operaciones matemáticas donde los units se cancelan por completo, como dividir metros entre centímetros, Astropy devuelve un Quantity dimensionless. El unit sigue existiendo under the hood como un tipo dimensionless unscaled. Si necesitas pasar este resultado a una librería externa que espera floats estándar de Python o arrays de NumPy normales, extraes el número en crudo usando el atributo value. Antes de extraer cualquier valor final, recuerda que siempre puedes simplificar units combinados y complejos a sus dimensiones físicas fundamentales absolutas llamando al método decompose. Si te gustaría apoyar el programa, puedes buscar DevStoriesEU en Patreon; nos ayuda a seguir haciendo estos episodios. Eso es todo por este episodio. Gracias por escuchar, ¡y a seguir programando!

Hola, soy Alex de DEV STORIES DOT EU. Astropy: Python para Astronomía, episodio 2 de 15. Un float estándar de sesenta y cuatro bits no puede representar un timestamp que abarque miles de millones de años sin destruir su propia precisión. Si intentas registrar un evento celeste distante al microsegundo, la aritmética de coma flotante estándar simplemente se queda sin bits. Esta misma limitación de hardware es la razón por la que necesitamos Escalas de Tiempo y Precisión: el módulo astropy.time. Para mantener una precisión subnanosegundo a lo largo de la historia cósmica, este módulo evita por completo usar un único número para representar el tiempo. En su lugar, se basa en una ingeniosa arquitectura de dos floats. Internamente, cada valor de tiempo se divide en dos floats separados de sesenta y cuatro bits. El primer float almacena la parte entera de la Fecha Juliana, que registra los días completos. El segundo float almacena la parte fraccionaria del día. Si Astropy los sumara en una sola variable, la precisión se degradaría al instante. Al mantenerlos separados, la librería puede realizar cálculos de tiempo de alta precisión localmente, sin importar lo lejos que esté la fecha en el pasado o en el futuro. Cuando creas un objeto Time, le pasas el valor de tiempo junto con dos argumentos cruciales: el formato y la escala. Aquí está la clave. Los desarrolladores suelen confundir el formato visual de una fecha con su escala de tiempo física. Son conceptos completamente distintos. El formato solo determina cómo se leen o escriben los datos. Los formatos comunes incluyen strings ISO estándar, Fechas Julianas Modificadas numéricas y representaciones especializadas como las cabeceras FITS. El formato es simplemente el wrapper estructural alrededor de los números. La escala de tiempo, sin embargo, define el marco de referencia físico de esos números. Las escalas de tiempo físicas tienen en cuenta la rotación de la Tierra, los segundos intercalares y los efectos relativistas. Algunos ejemplos incluyen el Tiempo Universal Coordinado, conocido como UTC, el Tiempo Terrestre, o TT, y el Tiempo Atómico Internacional, o TAI. Una Fecha Juliana Modificada no es una escala física, es solo un formato. Puedes tener fácilmente un timestamp formateado como Fecha Juliana Modificada, pero anclado físicamente a la escala UTC. Debes definir explícitamente tanto el formato como la escala al pasar datos raw a un objeto Time. Imagina que calculas la diferencia de tiempo entre dos timestamps de telemetría de una nave espacial. Recibes el primer timestamp como un string en formato ISO de ayer, y el segundo timestamp como un string ISO de hoy. Primero, inicializas dos objetos Time. Le pasas el string raw al objeto, declaras el formato como ISO y estableces la escala en UTC. Haces esto para ambos timestamps. Como Astropy soporta operaciones vectorizadas, también podrías pasar un array enorme de estos strings a un único objeto Time, pero la lógica de inicialización subyacente sigue siendo la misma. Para encontrar el tiempo transcurrido exacto, le restas el objeto Time anterior al posterior. Astropy ejecuta automáticamente la aritmética interna de dos floats, devolviendo un objeto TimeDelta que contiene la duración exacta. A continuación, necesitas mapear ese segundo timestamp de telemetría a una escala física absoluta y uniforme, eliminando los saltos impredecibles causados por los segundos intercalares de UTC. Coges tu segundo objeto Time y simplemente pides su equivalente en Tiempo Atómico Internacional. Consigues esto llamando al atributo TAI directamente en el objeto. Astropy desencadena inmediatamente un recálculo de los floats internos, cambiando el marco de referencia de UTC a TAI mientras conserva la precisión total de nanosegundos. El verdadero poder del módulo astropy.time es que nunca gestionas manualmente los segundos intercalares ni las correcciones relativistas; defines tus formatos y escalas por adelantado, y la arquitectura de dos floats garantiza que los cálculos se mantengan exactos en todo el universo. Me gustaría tomarme un momento para darte las gracias por escucharnos; nos ayuda mucho. ¡Que vaya genial!

Hola, soy Alex de DEV STORIES DOT EU. Astropy: Python para Astronomía, episodio 3 de 15. Convertir manualmente coordenadas celestes de un sistema de referencia a otro implica una trigonometría esférica horrible. Un simple error en la matriz puede hacer fácilmente que tu telescopio apunte al hemisferio equivocado. Navigating the Sky: la clase SkyCoord se encarga de esas matemáticas por ti, convirtiendo las transformaciones esféricas complejas en un simple attribute lookup. En Astropy, SkyCoord es el objeto principal de alto nivel para representar posiciones celestes. Actúa como un wrapper inteligente sobre frames de coordenadas de más bajo nivel. Cuando observas un objetivo, necesitas registrar su posición. Normalmente, usas la Ascensión Recta y la Declinación. Para crear un SkyCoord, pasas esos dos valores, especificas las unidades, como grados u horas, y configuras el reference frame. Si no especificas un frame, por defecto usa el Sistema Internacional de Referencia Celeste, o ICRS. Puedes crear un único punto en el cielo fácilmente, pero esto conlleva una trampa frecuente. Los usuarios suelen parsear un archivo de datos con miles de estrellas, crear un nuevo objeto SkyCoord para cada estrella y guardarlos en una list estándar de Python. Cuando necesitan hacer cálculos, hacen un loop sobre esa list. Esto es horriblemente ineficiente y se salta por completo los beneficios de rendimiento de la library. SkyCoord está diseñado para manejar arrays de forma nativa. En lugar de crear miles de objetos individuales, pasas un array de Numpy de valores de Ascensión Recta y un array correspondiente de valores de Declinación a una única inicialización de SkyCoord. Obtienes exactamente un objeto SkyCoord que contiene todo tu dataset. Imagina un escenario donde estás haciendo un cross-matching de un conjunto recién descubierto de cien transitorios de radio registrados en ICRS con un catálogo óptico existente. Al cargar los cien transitorios en un único SkyCoord respaldado por arrays, la library pasa los datos a rutinas de C y Numpy altamente optimizadas. Las operaciones que tardarían minutos en un loop de Python se ejecutan en milisegundos. Esta estructura de array resulta especialmente potente cuando necesitas transformar tus datos. Los catálogos astronómicos no siempre coinciden en un sistema de coordenadas. Puede que tus transitorios de radio estén en ICRS, pero quizás necesites analizar su distribución con respecto al plano de la Vía Láctea. Para eso, necesitas el sistema de coordenadas galácticas. Aquí está la clave. No necesitas buscar matrices de rotación ni escribir funciones de conversión. Astropy incluye un enorme grafo de transformación integrado que sabe cómo pasar de cualquier frame soportado a cualquier otro frame soportado. Dado que SkyCoord hace un wrap de este grafo, convertir todo tu array de cien transitorios requiere exactamente un paso. Coges tu objeto SkyCoord existente y llamas a su método transform to, proporcionando el nombre del frame de destino. Mejor aún, para los frames comunes, Astropy proporciona acceso directo a los attributes. Si tienes un objeto SkyCoord en ICRS, simplemente pides el attribute galactic. La library calcula automáticamente la transformación y devuelve un objeto SkyCoord totalmente nuevo. Este nuevo objeto contiene exactamente las mismas ubicaciones físicas en el espacio, pero representadas como longitud y latitud galácticas. El verdadero poder de esta clase es que desvincula por completo los datos que representan una posición celeste de la geometría esférica subyacente necesaria para moverla a través del universo de reference frames astronómicos. Eso es todo por este episodio. ¡Gracias por escuchar, y sigue creando!

Hola, soy Alex de DEV STORIES DOT EU. Astropy: Python for Astronomy, episodio 4 de 15. Puede que sepas con exactitud dónde está una estrella esta noche, pero sin las correcciones de proper motion y de velocidad de la Tierra, tu telescopio apuntará al vacío la próxima década. Aquí es donde vamos más allá de la ascensión recta y la declinación: tracking 3D y velocidades. Por defecto, las coordenadas mapean una posición plana en el cielo usando ángulos. Para modelar un sistema físico, como un sistema estelar binario, necesitas el espacio físico real entre los componentes. Mucha gente intenta calcular una separación tridimensional usando solo la ascensión recta y la declinación. Eso no funciona. Para usar el método de separación tridimensional, debes proporcionar un parámetro distance al crear el objeto coordinate. Pasas un valor de distancia con una unidad física, como pársecs, junto con tus coordenadas angulares. Una vez que ambos objetos contienen estos datos de distancia, llamas al método de separación tridimensional en la primera coordenada, pasándole la segunda coordenada como argumento. Astropy devuelve la línea física directa entre ellos en el espacio tridimensional, gestionando automáticamente la trigonometría de fondo. Ahora bien, esos objetos no son estáticos. Para modelar su movimiento a lo largo del tiempo, adjuntas datos de velocidad directamente al objeto coordinate al crearlo. Esto lo haces pasando parámetros de proper motion. Específicamente, proporcionas el proper motion en ascensión recta y el proper motion en declinación. Estos toman unidades angulares por tiempo, como miliarcosegundos por año. También proporcionas un parámetro de radial velocity, que toma una velocidad física, como kilómetros por segundo. Cuando empaquetas todo esto junto, el objeto coordinate se convierte en un vector completo de phase-space. Contiene la ubicación actual del objeto y el vector exacto de hacia dónde va. Aquí está la clave. Tu telescopio también se mueve por el espacio. La Tierra rota sobre su eje y orbita alrededor del Sol. Si mides la velocidad radial de una estrella desde la Tierra, tu medición raw está contaminada por la propia velocidad de la Tierra en ese preciso instante. Para compartir tus datos con otros astrónomos, tienes que eliminar el movimiento de la Tierra. Cambias tu punto de referencia a un frame estable, generalmente el centro de masas del sistema solar. Esto se llama corrección de velocidad radial baricéntrica. Para calcular esta corrección en Astropy, necesitas definir dónde está el observador usando un objeto Earth location. Lo creas pasando la longitud, latitud y elevación exactas de tu instrumento. Alternativamente, puedes sacar un sitio establecido directamente del site registry integrado de Astropy haciendo una query con un nombre conocido, como el Observatorio Keck. A continuación, necesitas la hora exacta en la que tuvo lugar la observación. Con tu ubicación y hora listas, llamas al método de radial velocity correction directamente sobre el objeto coordinate de tu objetivo. Le pasas el tiempo de observación y tu Earth location. Astropy calcula el vector de velocidad del Observatorio Keck en ese milisegundo específico, en relación con el objetivo, y devuelve el velocity offset. Sumas este valor de corrección a tu velocidad radial raw medida. El resultado es una medición limpia y estandarizada referenciada al baricentro del sistema solar. La lección más útil aquí es que una coordenada no es solo un punto fijo en un mapa; es un modelo cinemático completo que guarda la posición del objetivo, su trayectoria y la geometría necesaria para corregir tu propio movimiento. Gracias por escuchar. Cuidaos todos.

Hola, soy Alex de DEV STORIES DOT EU. Astropy: Python para Astronomía, episodio 5 de 15. Pandas es increíble para datos planos, pero ¿qué sucede cuando una sola columna de tu dataset necesita contener una serie temporal, una unidad física y una coordenada espacial? Los dataframes estándar se quedan cortos. Para resolver esto, necesitas dominar los datos tabulares: la clase QTable. Si trabajas con Python, ya conoces Pandas. Pandas asume que tus datos son planos y prefiere un valor simple por celda. En astronomía, los datos rara vez son simples. Una sola observación puede requerir unidades estrictas, un array de valores o una coordenada celeste compleja. Astropy proporciona una estructura de datos tabular personalizada diseñada específicamente para esta realidad. Verás que Astropy tiene tanto una clase Table estándar como una clase QTable. La gente suele confundirlas. La clase Table estándar guarda la información de las unidades como metadata en segundo plano, pero devuelve arrays de NumPy normales cuando extraes una columna. Una QTable impone un control estricto de las unidades. Cuando recuperas una columna de una QTable, te garantiza que obtendrás de vuelta un objeto Quantity nativo de Astropy. La unidad física está permanentemente unida a los números. Vamos a ver cómo construir una QTable. Empiezas importando QTable del módulo astropy punto table. Puedes construirla usando un diccionario donde las claves son los nombres de tus columnas y los valores son tus arrays de datos. Imagina que estás creando un catálogo simple de galaxias. Tu primera columna es texto plano. Asignas una lista de strings que representan los nombres de las galaxias. Ahora, necesitas registrar dónde están estas galaxias. No quieres tener columnas separadas y desconectadas para la ascensión recta y la declinación. En su lugar, creas un objeto SkyCoord de Astropy que contiene las posiciones de todas tus galaxias. Pasas este único objeto SkyCoord directamente a tu tabla como la segunda columna. Esto es una columna mixin. Los mixins permiten que tipos complejos de Astropy, como los objetos SkyCoord o Time, actúen exactamente igual que los arrays de datos estándar dentro de la tabla. Puedes hacer slice, ordenar y filtrar las filas de la tabla, y el objeto mixin mantiene automáticamente sus datos internos perfectamente sincronizados. A continuación, necesitas almacenar mediciones de flujo en tres bandas de longitud de onda diferentes para cada galaxia. En un dataframe típico, te verías obligado a crear tres columnas separadas. En una QTable, utilizas una columna multidimensional. Defines un único array con un shape de N filas y tres columnas, le añades una unidad física de flujo a todo el conjunto, y lo asignas como tu tercera columna de la tabla. Aquí es donde se pone interesante. La QTable acepta el array multidimensional de forma nativa. Una sola fila en esa columna ahora contiene un array completo de tres mediciones con sus unidades. Cuando imprimes esta tabla, Astropy la formatea limpiamente. Alinea los arrays anidados y muestra las unidades directamente debajo de las cabeceras de las columnas. Tu metadata y tus mediciones quedan vinculadas entre sí. La QTable no es solo una hoja de cálculo; es un contenedor especializado diseñado para respetar la física y la geometría de tus datos. Gracias por estar ahí. Espero que hayas aprendido algo nuevo.

Hola, soy Alex de DEV STORIES DOT EU. Astropy: Python para Astronomía, episodio 6 de 15. Buscar una fuente específica en un catálogo enorme suele implicar ejecutar un linear scan completo que consume mucho tiempo de procesamiento. Pero si estructuras tus datos correctamente, puedes reducir esos lookups de minutos a milisegundos. Eso es lo que veremos hoy: Operaciones avanzadas con tablas: Masking y Joins. Las tablas de Astropy no son simples arrays. Funcionan como una base de datos relacional in-memory que entiende de forma nativa las unidades físicas. Supongamos que tienes un catálogo fotométrico y un catálogo espectroscópico, y necesitas combinarlos basándote en un source ID compartido. Antes de hacer el merge, tienes que gestionar los datos faltantes. Es probable que tu catálogo fotométrico tenga valores de magnitud faltantes porque una observación falló o un sensor perdió un frame. Podrías intentar filtrar esos valores faltantes usando boolean arrays estándar de numpy. No lo hagas. Las masks estándar de numpy aplicadas directamente a una tabla unit-aware eliminan silenciosamente tus unidades físicas y rompen los objetos mixin. En su lugar, Astropy gestiona esto con MaskedColumn. Cuando trabajas dentro de una QTable, que es la clase de tabla unit-aware, Astropy utiliza automáticamente operaciones de MaskedColumn por debajo para los datos faltantes. Esto asegura que tu columna de magnitud conserve sus unidades físicas intactas mientras marca de forma segura las entradas faltantes para que no corrompan tus cálculos downstream. Con tu catálogo fotométrico limpiamente masked y listo, es hora de combinarlo con tus datos espectroscópicos. Astropy proporciona una función join que funciona de forma muy parecida a una base de datos relacional. Le pasas a la función tu tabla izquierda, tu tabla derecha, y especificas el nombre de la columna compartida como key, que en este caso es tu source ID. Si especificas un inner join, la función evalúa ambos datasets y devuelve una nueva tabla que contiene solo las filas donde el source ID existe en ambos catálogos. Aquí está la clave. Como estás usando objetos QTable, la operación join concilia y conserva automáticamente las unidades de ambos lados. Tu tabla merged contendrá los parámetros físicos precisos de los datos espectroscópicos junto con las magnitudes correctamente masked de los datos fotométricos, perfectamente alineadas. Ahora tienes un catálogo merged, y tu análisis requiere extraer los parámetros exactos para un source ID específico. Sin intervención, encontrar una fila en una tabla enorme requiere comprobar cada entrada secuencialmente. Astropy resuelve este cuello de botella de rendimiento con table indexing. Puedes indicarle a la tabla que cree un index en tu columna de source ID. Por debajo, Astropy construye una estructura de datos B-tree que mapea tus source IDs directamente a sus ubicaciones de fila subyacentes en memoria. Una vez construido el index, recuperas tus datos usando la propiedad location de la tabla, pasándole tu target ID. El motor recorre el B-tree, se salta el full scan por completo y recupera tu fila en tiempo logarítmico. Incluso puedes indexar varias columnas simultáneamente para gestionar lookups complejos, como encontrar una fila tanto por source ID como por fecha de observación. Construir un index requiere una fracción de compute time por adelantado, pero compensa de inmediato cuando necesitas ejecutar lookups repetidos en datasets pesados. El verdadero poder de las tablas de Astropy no es solo almacenar datos, sino mantener la integridad física de tus unidades a través de joins relacionales complejos y queries B-tree de alta velocidad. Eso es todo por este episodio. ¡Gracias por escuchar, y sigue creando!

Hola, soy Alex de DEV STORIES DOT EU. Astropy: Python para Astronomía, episodio 7 de 15. Tienes un archivo de texto antiguo y desordenado con coordenadas estelares y necesitas convertirlo a un estándar binario moderno y comprimido. En la mayoría de las librerías, esto implica escribir un parser a medida, mapear tipos de datos y pelear con serializadores binarios. En Astropy, puedes hacerlo con exactamente dos líneas de código. Esto es gracias a la Unified I/O Interface. La Unified I/O Interface es una capa polimórfica para el manejo de datos. En lugar de obligarte a importar un módulo específico para cada tipo de archivo, Astropy expone un método genérico read y write directamente en sus estructuras de datos core. Tanto si trabajas con una Table estándar, una QTable con unidades físicas o un array NDData multidimensional, el modelo de interacción permanece idéntico entre estándares de archivo completamente diferentes. Existe un malentendido muy común sobre la extracción de datos. Cuando los desarrolladores necesitan leer un archivo FITS, a menudo van directamente al módulo de bajo nivel, astropy punto io punto fits. Ese módulo es estrictamente para la manipulación de archivos raw, como editar headers individuales o inspeccionar byte streams sin formato. Si solo quieres extraer datos tabulares de un archivo FITS, no deberías usarlo. En su lugar, usas el método Table punto read. Este omite la extracción manual de headers y gestiona automáticamente el mapeo de datos subyacente. Cuando llamas al método read y pasas un path de archivo o un file object abierto, Astropy se basa en un robusto motor de inferencia de formato. Primero, comprueba la extensión del archivo. Si proporcionas un string que termina en punto h5 o punto parquet, dirige la petición al parser especializado correspondiente. Si la extensión es ambigua, falta o es simplemente una extensión de texto genérica, el motor baja un nivel e inspecciona el contenido del archivo. Lee los primeros bytes de los datos buscando signatures conocidas o magic numbers para identificar de forma fiable el estándar. Si la inferencia automática falla por completo, puedes saltártela pasando un string como argumento format, como ascii punto csv, para forzar el parser correcto. Veamos cómo maneja esto nuestro escenario inicial. Tienes esa vieja tabla de texto ASCII con coordenadas estelares. Llamas a QTable punto read y le pasas el path de tu archivo de texto. Astropy detecta el formato ASCII, parsea las columnas y devuelve un objeto QTable completamente poblado en memoria. A continuación, quieres guardar esto como una tabla binaria FITS comprimida. Tomas ese mismo objeto QTable en memoria y llamas a su método write. Proporcionas un nuevo nombre de archivo que termina en punto fits y pasas un parámetro extra para habilitar la compresión. También debes pasar un flag overwrite a true, porque el método write protege los archivos existentes de forma segura por defecto. Aquí es donde la cosa se pone interesante. Astropy cambia dinámicamente de contexto bajo el capó, pasando del parseo de texto plano a una serialización binaria compleja. Los protocolos de archivo subyacentes son completamente distintos, pero la interfaz que utilizas permanece sin cambios. Como la interfaz está vinculada a la estructura de datos en lugar del formato de archivo, tus pipelines de procesamiento de datos se desacoplan de tus medios de almacenamiento. La conclusión más útil aquí es que cambiar la forma en que tu aplicación almacena y comparte datos requiere modificar la extensión de un archivo en un solo string, en lugar de reescribir todo tu pipeline de ingesta de datos. Eso es todo por hoy. Gracias por escuchar, ve a construir algo genial.

Hola, soy Alex de DEV STORIES DOT EU. Astropy: Python para Astronomía, episodio 8 de 15. El estándar de archivos FITS se creó en la década de los 80 para sistemas Fortran, y almacenaba metadatos en bloques rígidos de ochenta bytes modelados directamente a partir de tarjetas perforadas físicas. Trabajar con estructuras de tarjetas perforadas en código moderno rara vez es agradable. Astropy oculta esta complejidad al traducir esos bloques a estructuras nativas, y por eso mismo este episodio se centra en desmitificar los headers de FITS y las HDUs. Piensa en un archivo FITS como un contenedor. Dentro de este contenedor se encuentran las Header Data Units, conocidas universalmente como HDUs. Cada archivo FITS debe contener al menos una de estas, llamada Primary HDU. A menudo, esta unidad primaria solo contiene metadatos, mientras que las imágenes o tablas binarias reales van justo después como Extension HDUs. Cuando abres un archivo FITS con Astropy, este parsea el contenedor y te devuelve un objeto HDUList. Navegas por este objeto usando la notación estándar de corchetes para seleccionar HDUs individuales. Aquí está la clave sobre la indexación. El estándar oficial FITS utiliza estrictamente la indexación basada en uno debido a sus raíces en Fortran. Sin embargo, como Astropy es una librería de Python, impone la indexación basada en cero. La Primary HDU siempre está en el índice cero, y la primera extensión en el índice uno. Es un detalle muy simple, pero olvidarlo provoca los típicos errores off-by-one constantemente. Cada objeto HDU contiene un atributo header. Aquí es donde viven esos antiguos bloques de ochenta bytes. En la terminología FITS, cada línea de metadatos se llama card. Una card completa contiene una keyword, un valor y, a veces, un comentario descriptivo. Astropy procesa estas cards y te expone el header como un objeto que funciona exactamente igual que un diccionario estándar de Python. Si necesitas el tiempo de exposición, simplemente le pasas la keyword EXPTIME al header. Modificar valores funciona de la misma manera. Le asignas un nuevo valor a la keyword usando un signo igual. Si también necesitas actualizar el comentario en esa card específica, le asignas una tupla que contenga tanto el nuevo valor como el nuevo string del comentario. Astropy vuelve a empaquetar automáticamente estos datos en el estándar requerido de ochenta bytes por debajo. Esta traducción funciona a la perfección hasta que te encuentras con datos legacy. Los archivos FITS más antiguos suelen saltarse el estricto estándar. Pueden tener keywords demasiado largas o contener caracteres ilegales. Como Astropy valida estrictamente los headers por defecto, intentar abrir un archivo que no cumpla el estándar a menudo lanzará una excepción de inmediato. En lugar de descartar el archivo, puedes gestionar esto usando el método verify. Imagina que abres una imagen antigua de un telescopio y te topas con un error de validación sobre el formato. Capturas el objeto del archivo y llamas a su método verify, pasándole el argumento de string fix. Astropy escaneará todas las cards del header, reparará automáticamente los problemas de formato donde sea posible, y suprimirá los errores de los campos corruptos que arregle. Una vez que el header esté estabilizado, puedes actualizar de forma segura una card OBSERVER rota con el string correcto, y luego escribir tu HDUList limpia de vuelta al disco. Trata siempre tus actualizaciones de metadatos FITS como simples operaciones de diccionario, pero ten ese método verify a mano para cuando los datos legacy rompan las reglas. Si quieres ayudar a que el programa continúe, busca DevStoriesEU en Patreon. Gracias por escucharnos. ¡Hasta la próxima!

Hola, soy Alex de DEV STORIES DOT EU. Astropy: Python para Astronomía, episodio 9 de 15. No necesitas un superordenador para analizar una imagen de cien gigabytes. Solo necesitas una forma de engañar a tu sistema operativo para que lea únicamente los píxeles que te interesan. Manejar archivos FITS masivos y cloud storage es exactamente el mecanismo que usas para conseguirlo. Al trabajar con arrays astronómicos masivos, intentar cargar un archivo entero en memoria provocará un crash inmediato en tu proceso. Astropy evita esto usando una feature llamada memory mapping. Cuando abres un archivo FITS, puedes pasar un argumento llamado memmap puesto a True. Un memory map no lee los datos de la imagen en tu RAM física. En su lugar, mapea el archivo de tu disco duro directamente en el espacio de direcciones de memoria virtual de tu ordenador. Cuando accedes a un slice específico del array, tu sistema operativo recupera solo ese bloque de datos específico del disco. Obtienes la comodidad de fingir que el archivo entero está cargado, pero solo pagas el coste de memoria física por los píxeles que procesas activamente. Este comportamiento introduce una trampa muy común. Podrías abrir un archivo FITS, asignar el array de la imagen a una variable, y luego llamar a close en el file object. Esperas que el file handle se libere y el recurso quede libre. Pues no es así. Como los memory maps dependen de que el sistema operativo enlace el archivo a una variable, el archivo permanece abierto y bloqueado mientras exista cualquier referencia a ese array en tu sesión de Python. Para liberar realmente el recurso y cerrar el file handle por completo, debes eliminar explícitamente tu variable de datos usando el comando delete estándar de Python. Eso cubre los archivos locales, pero los datasets de astronomía modernos a menudo viven en servidores remotos. Descargar cientos de gigabytes solo para inspeccionar una pequeña región es un desperdicio de ancho de banda y tiempo. Astropy maneja los datos remotos integrándose con la librería file system spec. Cuando abres un archivo, pasas un argumento llamado use fsspec puesto a True. Esto le dice a la librería que trate las ubicaciones de cloud storage exactamente igual que los discos locales. Imagina una imagen del Telescopio Espacial Hubble de doscientos megabytes alojada en un bucket público de Amazon S3. Solo quieres un recorte diminuto de diez por veinte píxeles alrededor de una estrella en concreto. Primero, llamas a fits open, pasando el uniform resource identifier de S3 en lugar de un file path local, junto con use fsspec puesto a True. Astropy se conecta al bucket y descarga solo los bloques del header de FITS. Esto le permite entender la estructura del archivo sin tocar los datos reales de la imagen. A continuación, navegas hasta la extensión de imagen correcta y haces un slice del array de datos usando indexing estándar, obteniendo solo tu bloque de diez por veinte. Aquí es donde la cosa se pone interesante. Astropy traduce ese slice del array en byte range requests de HTTP específicas. Tu máquina se conecta a Amazon S3, pide solo los bytes físicos que corresponden a esos doscientos píxeles, y descarga exactamente ese pequeño chunk. Obtienes tu recorte al instante, mientras que los ciento noventa y nueve megabytes restantes del archivo permanecen intactos en el servidor. Combinar el memory mapping local con el byte range streaming remoto significa que tus scripts de análisis están limitados únicamente por los datos que computas activamente, nunca por el tamaño total del propio archivo. Me gustaría tomarme un momento para agradecerte que nos escuches, nos ayuda muchísimo. ¡Que tengas un gran día!

Hola, soy Alex de DEV STORIES DOT EU. Astropy: Python para Astronomía, episodio 10 de 15. Si haces un slice de un array numérico estándar, solo obtienes píxeles raw. Pero los datos de un telescopio nunca son solo una matriz de números. Cuando recortas una imagen para observar una sola estrella, tus márgenes de error, tus máscaras de píxeles muertos y tus coordenadas celestes deben mantenerse perfectamente alineados; de lo contrario, todo tu análisis se rompe. Precisamente por eso usamos Gridded Data: las clases NDData y CCDData. En esencia, Astropy proporciona la clase base NDData como un contenedor estándar para datos astronómicos en formato grid. Aunque NDData gestiona la estructura general, para imágenes ópticas o infrarrojas reales, normalmente usarás su subclase especializada llamada CCDData. Este contenedor existe para vincular tus valores de píxeles raw directamente con sus propiedades físicas. Vamos a ver cómo inicializar un objeto CCDData para una exposición raw de telescopio. No le pasas simplemente un grid bidimensional de números. Le pasas el grid de datos raw y debes asignarle una unidad física, como electrones o unidades analógico-digitales. A continuación, le adjuntas una máscara booleana. Si un rayo cósmico de alta energía impacta tu detector durante la exposición, marcas esos píxeles arruinados específicos como true en un array de máscara independiente, y se lo pasas directamente al objeto CCDData. Luego viene el seguimiento de errores. Le adjuntas un array de incertidumbre. Para nuestra imagen raw, podrías calcular el ruido de Poisson y adjuntarlo usando la clase Standard Deviation Uncertainty o la clase Variance Uncertainty. Ahora, tus valores de brillo, tus unidades, tus flags de píxeles malos y tus límites de ruido estadístico quedan bloqueados juntos como un único objeto unificado. Esto nos lleva a una confusión muy común. Una vez que tienes este objeto completamente cargado, no intentes usar operadores matemáticos estándar, como un simple signo de más o menos, para procesar la imagen. Si intentas hacer aritmética de arrays normal para restar un frame de fondo oscuro, dejarás atrás tus incertidumbres. En su lugar, debes usar los métodos aritméticos integrados que proporciona la clase, como las funciones add, subtract, multiply y divide. Aquí es donde la cosa se pone interesante. Cuando llamas al método subtract, Astropy no solo resta los valores de los píxeles. Propaga automáticamente tus incertidumbres de varianza a través de la operación usando reglas estadísticas estándar, produciendo un perfil de ruido matemáticamente sólido en la imagen resultante. Más adelante en tu workflow, puede que te des cuenta de que tu imagen completa del telescopio es demasiado grande, y solo quieres analizar una única galaxia situada en la esquina superior derecha. Logras esto usando una herramienta llamada Cutout2D. Le pasas tu objeto CCDData principal, las coordenadas exactas del centro de tu galaxia objetivo y el tamaño del bounding box que quieres extraer. Como empaquetaste todo en un contenedor CCDData, Cutout2D gestiona la sincronización compleja automáticamente. Te devuelve un objeto nuevo y más pequeño. Hace un slice de los píxeles de la imagen, pero también recorta automáticamente la máscara de rayos cósmicos y el array de incertidumbre de varianza exactamente a las mismas dimensiones. Y lo que es crucial, traduce el sistema de coordenadas del mundo subyacente. La coordenada de píxel cero-cero en tu nuevo cutout se mapea correctamente a la misma ascensión recta y declinación exactas que tenía en la imagen maestra. Al tratar los datos de los píxeles, los márgenes de error físicos y las coordenadas espaciales como una unidad indivisible, estas clases evitan la corrupción silenciosa de datos a medida que tu imagen avanza por pipelines de análisis complejos. Eso es todo por este episodio. ¡Gracias por escuchar y sigue creando!

Hola, soy Alex de DEV STORIES DOT EU. Astropy: Python para Astronomía, episodio 11 de 15. Cada píxel del detector de un telescopio es un cuadrado plano y discreto, pero el cielo es una esfera curva continua y matemáticamente compleja. Mapear un punto de ese detector plano de vuelta a su posición real en el universo es un problema geométrico complicado. World Coordinate Systems, o WCS, es el mecanismo que decodifica esa geometría. WCS actúa como el puente definitivo entre el hardware y la física. Proporciona la transformación matemática necesaria para convertir una coordenada de píxel en una world coordinate, como la Ascensión Recta y la Declinación. En los datos astronómicos, estas reglas de transformación suelen almacenarse como metadatos estandarizados en el header de un archivo FITS. El header contiene keywords específicas que definen el píxel de referencia, las coordenadas físicas de ese píxel y la matriz de rotación o escalado utilizada por el telescopio. Astropy lee estas keywords y construye un objeto de transformación activo que modela todo el plano focal. Antes de hacer cálculos, debemos aclarar una fuente constante de confusión con el indexing. El estándar FITS define las coordenadas de los píxeles como one-indexed, lo que significa que el primer píxel del detector es el píxel uno. Python, y por lo tanto NumPy, es zero-indexed. Astropy resuelve esta dualidad mediante dos capas diferentes. La API más antigua, de bajo nivel, no es un sistema de indexación unificado; requiere que pases explícitamente un argumento origin de cero o uno cada vez que transformas una coordenada. Pero la moderna Shared Python Interface de alto nivel opera completamente con la convención zero-indexed de Python. Espera que le pases píxeles zero-based y gestiona automáticamente el offset respecto al estándar FITS internamente. Aquí está la clave. La API de alto nivel hace que la conversión de coordenadas sea increíblemente concisa. Supongamos que has localizado una estrella brillante en tu array de imagen en el píxel x igual a 30 e y igual a 40, y necesitas encontrar su posición real en el espacio. Primero, lees el header de tu archivo FITS usando las herramientas de input-output de Astropy. Luego, inicializas un objeto WCS pasando ese header directamente a la clase WCS. Finalmente, llamas a un método llamado pixel to world en ese objeto WCS, pasándole tus valores de píxel x e y de 30 y 40. El método evalúa las matemáticas de la proyección y devuelve un objeto SkyCoord estándar de Astropy. Este objeto contiene las coordenadas físicas y es completamente consciente de su reference frame, como ICRS. La belleza de esta shared interface es que te protege de los raw numbers. En lugar de devolver un array genérico de floats que representan grados abstractos, te da objetos ricos que entienden sus propias unidades físicas y sistemas de coordenadas. Puedes coger ese SkyCoord y usarlo inmediatamente para cruzar datos con un catálogo estelar. El sistema funciona exactamente igual a la inversa. Si tienes las coordenadas de una galaxia conocida y quieres determinar exactamente qué píxeles ocupa en el sensor de tu cámara, llamas al método world to pixel en tu objeto WCS. Le pasas tu SkyCoord, y te devuelve las posiciones exactas de los píxeles x e y en coma flotante. La API WCS de alto nivel aísla la lógica de tu aplicación de las matemáticas de proyección subyacentes, lo que significa que tu código de conversión de píxel a cielo permanece idéntico tanto si estás trabajando con un mapa de radio plano como con un mosaico óptico de campo amplio profundamente distorsionado. Eso es todo por este episodio. ¡Gracias por escuchar, y seguid construyendo!

Hola, soy Alex de DEV STORIES DOT EU. Astropy: Python para Astronomía, episodio 12 de 15. En muchas librerías científicas, la ecuación matemática que quieres evaluar está estrechamente ligada al algoritmo utilizado para optimizarla. Si quieres cambiar cómo funciona la optimización, a menudo tienes que reescribir cómo definiste tus matemáticas. Astropy elimina este problema por completo con su enfoque de Modelos Analíticos y Fitting. La filosofía de diseño principal del subpaquete modeling de Astropy es una estricta separación de responsabilidades. La definición matemática de tu ecuación es un objeto. El motor algorítmico que hace el fit de esa ecuación a tus datos es un objeto completamente independiente. Esto significa que puedes definir tus matemáticas una sola vez, y luego probarlas con varios algoritmos de fitting diferentes simplemente pasándole el modelo a un fitter distinto. Astropy ofrece docenas de modelos matemáticos predefinidos. Si estás modelando una tendencia constante, usas un modelo Linear1D. Si estás estudiando una línea de emisión en un espectro, recurres a un modelo Gaussian1D. Estos objetos modelo encapsulan sus parámetros, como la amplitud, la media y la desviación estándar. Antes de ver el proceso de fitting, tenemos que aclarar una fuente frecuente de confusión. En Astropy, los modelos son objetos callable. Le pasas un array de coordenadas directamente a un modelo instanciado, y este evalúa las matemáticas para devolver los valores correspondientes. Lo más importante es que, cuando optimizas un modelo, el fitter no muta tu objeto inicial original. Siempre devuelve una instancia completamente nueva del modelo. Tu estimación inicial se conserva exactamente como la definiste. Imagina un escenario donde tienes datos ruidosos en un array unidimensional que representan una característica espectral. Primero, inicializas un modelo Gaussian1D con tus estimaciones iniciales aproximadas para la amplitud, la media y el ancho. Como Astropy separa las matemáticas del optimizador, tú añades tus restricciones físicas directamente a los parámetros del modelo. Supón que ya conoces la coordenada central exacta de esta línea espectral. Accedes al parámetro mean de tu modelo y estableces su propiedad fixed en true. El algoritmo de optimización ahora dejará ese valor intacto. También puedes establecer límites matemáticos. Al establecer un límite mínimo de cero en el parámetro amplitude, obligas al algoritmo a rechazar cualquier solución que dé como resultado un pico negativo. Con tu modelo inicial completamente restringido, traes el fitter. Para ecuaciones no lineales como una gaussiana, instancias el fitter de mínimos cuadrados de Levenberg-Marquardt, conocido en Astropy como LevMarLSQFitter. Ejecutas el fit llamando a este objeto fitter, pasándole tu modelo gaussiano inicial junto con tus arrays de datos horizontales y verticales. El algoritmo se ejecuta y devuelve un modelo Gaussian1D completamente nuevo que contiene los valores optimizados de los parámetros. Como este nuevo modelo es directamente callable, simplemente le pasas tu array horizontal original para generar una curva matemática suave que puedes plotear frente a tus datos ruidosos. Aquí está la clave. Al almacenar las restricciones en el modelo en lugar de pasarlas al solver, los algoritmos de fitting se mantienen genéricos. Dedicas tu esfuerzo a codificar la realidad física de tu problema en el modelo matemático, permitiendo a Astropy intercambiar la lógica de optimización en segundo plano sin romper tu pipeline. Eso es todo por este episodio. Gracias por escuchar, y ¡sigue creando!

Hola, soy Alex de DEV STORIES DOT EU. Astropy: Python para Astronomía, episodio 13 de 15. En lugar de escribir a mano una función matemática enorme de quince parámetros para ajustar un espectro complicado, ¿qué pasaría si pudieras simplemente sumar formas básicas como si fueran piezas de Lego y dejar que Python se encargue del cálculo? Eso es precisamente lo que veremos hoy con Compound Models y Custom Fits. En Astropy, rara vez necesitas construir modelos analíticos complejos desde cero. Coges bloques simples y predefinidos y los combinas usando operadores aritméticos estándar de Python como suma, resta, multiplicación o división. Cuando sumas dos modelos de Astropy, no obtienes un array estático de números evaluados. Obtienes un objeto model completamente nuevo y funcional. Esta estructura compuesta sabe cómo evaluarse a sí misma, calcular sus derivadas y hacer un seguimiento de cada parámetro de los modelos base originales. Imagina un escenario específico. Tienes un espectro que contiene dos líneas de emisión distintas superpuestas a un continuo de fondo plano. Quieres ajustar toda esta estructura simultáneamente. Empiezas instanciando un modelo polynomial básico para que actúe como tu línea base plana. Luego, instancias dos modelos Gaussian 1D separados para representar las dos líneas de emisión. Para crear tu perfil espectral final, simplemente defines una nueva variable igual al polynomial más el primer Gaussian más el segundo Gaussian. Astropy los combina automáticamente en un único árbol de evaluación compuesto. Esto introduce una trampa común en cuanto al acceso a los parámetros. Al crear este compound model, puede que te preguntes cómo aislar la amplitude de la segunda línea de emisión. Como ambos son Gaussians, los dos tienen un parámetro llamado amplitude. Astropy resuelve esta colisión añadiendo automáticamente sufijos numéricos según el orden en que se combinaron los modelos. Al primer Gaussian se le renombran sus parámetros a amplitude cero, mean cero y standard deviation cero. El segundo Gaussian recibe amplitude uno, mean uno, y así sucesivamente. Si en algún momento pierdes la pista de qué parámetro pertenece a cada componente, puedes inspeccionar el atributo parameter names de tu compound model para ver la lista exacta generada. Ahora, la segunda parte de esto es ajustar datos que llevan unidades físicas. Las mediciones astronómicas no son simples floats crudos. Tu variable independiente podría ser la longitud de onda en Angstroms, y tu variable dependiente podría ser la densidad de flujo en Janskys. Los modelos de Astropy manejan esto de forma elegante mediante el objeto Quantity. Cuando pasas tus arrays de datos a un fitter, pasas los objetos Quantity de Astropy directamente, sin quitarles las unidades. El fitter analiza las unidades de tus datos de entrada y la estructura de tu compound model. Detecta las discrepancias dimensionales incluso antes de que empiece el fit. Una vez que el fit converge, los parámetros del modelo resultante tendrán automáticamente las unidades físicas correctas. Los means de tus Gaussians se actualizan a Angstroms, y tus amplitudes se actualizan a Janskys. No tienes que escribir lógica de conversión personalizada ni quitar las unidades antes de fittear solo para volver a ponerlas después. El compound model garantiza la consistencia dimensional durante todo el proceso. Aquí está la clave. Cuando usas un signo más entre dos modelos, no solo estás encadenando funciones. Estás construyendo una única ecuación unificada que mantiene un control estricto de las unidades y la trazabilidad de los parámetros desde los datos crudos hasta el fit final. Eso es todo por este episodio. ¡Nos vemos en la próxima!

Hola, soy Alex de DEV STORIES DOT EU. Astropy: Python para Astronomía, episodio 14 de 15. Tienes catorce mil fotos de telescopio de una estrella, tomadas con intervalos irregulares. En algún punto de ese ruido hay una caída de luz del 0,01% causada por un planeta alienígena que pasa por delante. Aquí tienes el algoritmo exacto para encontrarlo. Este episodio trata sobre Time Series Analysis y la caza de exoplanetas. Astropy gestiona este workflow usando la clase TimeSeries. Antes de seguir, aclaremos un malentendido común. Una TimeSeries no es una estructura de datos completamente nueva con sus propias reglas. Es simplemente una subclase de QTable. Esto significa que todos los métodos de manipulación de tablas, operaciones de columnas y técnicas de masking que ya conoces siguen funcionando a la perfección. La única diferencia es que la primera columna se fuerza estrictamente a ser un objeto Time de Astropy. Esta rigidez garantiza que tus timestamps y tus mediciones de flux se mantengan perfectamente alineados, tanto si tus observaciones están espaciadas uniformemente como si son completamente aleatorias. Para empezar a cazar un exoplaneta, primero cargas una curva de luz. Astropy incluye readers integrados que te permiten pasar un archivo FITS de Kepler directamente a la función read de TimeSeries. Esto configura automáticamente la columna Time y extrae las mediciones de luz, normalmente llamadas flux. Los datos de Kepler son extremadamente densos, y a veces contienen miles de data points a lo largo de unos pocos meses. Estos datos raw suelen contener ruido de alta frecuencia de la nave espacial o de la actividad estelar. Puedes suavizarlo usando downsampling mediante aggregation. Defines el tamaño de un time bin, por ejemplo, de diez minutos, y le pasas una función de aggregation, como mean. Astropy agrupa los timestamps en estos bins y promedia el flux, reduciendo el tamaño del dataset y suprimiendo el ruido aleatorio sin borrar la señal real del tránsito. Ahora tienes datos limpios, pero los tránsitos del exoplaneta están ocultos en algún punto de un timeline masivo. Para encontrar el planeta, necesitas un periodograma. Puede que conoces el periodograma de Lomb-Scargle, que es excelente para encontrar ondas sinusoidales suaves y continuas, como la luz de una estrella pulsante. Pero un planeta que pasa por delante de una estrella no crea una onda sinusoidal. Crea una línea plana, una caída repentina, un fondo plano y una subida repentina. La señal es una caja. Debido a esta forma, usas el periodograma Box Least Squares, o BLS. Pasas tu columna Time y tu columna flux a la función BLS. El algoritmo evalúa entonces un grid entero de posibles periodos orbitales, probando quizás desde una órbita de un día hasta una de cincuenta días. En cada frecuencia probada, desliza una caja matemática a través de los datos, intentando encajar la profundidad y la duración de un posible tránsito planetario. Devuelve un espectro de potencia que muestra lo bien que se ajusta la caja en cada una de las frecuencias. Simplemente extraes el periodo que generó el pico de potencia más alto. Esa es la órbita de tu exoplaneta sospechoso. Una vez que tienes ese periodo exacto, necesitas verificarlo visualmente. Coges tu TimeSeries original y llamas al método fold, pasándole el periodo que acabas de descubrir. El folding coge cada observación a lo largo de meses o años y la mapea a un único ciclo orbital. En lugar de un timeline cronológico, tu eje horizontal se convierte en la fase, que va de cero a uno. Cada vez que el planeta transitó la estrella durante la misión, esos data points individuales se apilan unos encima de otros exactamente en la misma fase. Esta es la parte que importa. Cuando haces un plot de esa TimeSeries con el fold aplicado, el scatter aleatorio del timeline desaparece, y aparece una caída limpia e innegable en forma de U justo en el centro de tu gráfico. Acabas de usar la geometría y el tiempo para extraer un mundo invisible del ruido. Gracias por pasar unos minutos conmigo. Hasta la próxima, cuídate.

Hola, soy Alex de DEV STORIES DOT EU. Astropy: Python para Astronomía, episodio 15 de 15. Resolver la métrica del universo en expansión suele requerir evaluar a mano integrales elípticas masivas. O puedes simplemente importar un solo module y dejar que Python haga los cálculos. Hoy veremos Cálculos Cosmológicos: Dimensionando el universo. El subpackage cosmology de Astropy encapsula la relatividad general y la métrica de Friedmann-Lemaitre-Robertson-Walker en function calls muy sencillas. En lugar de escribir tus propios integradores para mapear el redshift a la distancia física, defines un modelo cosmológico y la librería se encarga de la geometría subyacente. Una cosmología en Astropy es un objeto de Python. Puedes crear una desde cero usando la class FlatLambdaCDM. Le pasas una constante de Hubble, como setenta, y una densidad de materia inicial, como cero coma tres. Esto te da un universo espacialmente plano impulsado por la energía oscura y la materia oscura fría. Sin embargo, rara vez necesitas teclear estos parámetros tú mismo. Astropy incluye modelos built-in estándar derivados de los principales estudios. Simplemente haces un import de Planck13 o WMAP9 desde el module cosmology, y al instante tienes un modelo totalmente configurado y listo para evaluar. Aquí está la clave respecto al state. Los parámetros de un objeto cosmology de Astropy son estrictamente inmutables. Si inicializas un modelo y luego decides que quieres retocar la densidad de materia, no puedes actualizar ese attribute in place. Hacerlo lanza un error. En su lugar, llamas al method clone en tu modelo existente, pasándole el nuevo valor del parámetro como argument. Esto devuelve una instance de cosmology totalmente nueva con tus valores actualizados. Veamos un escenario concreto usando el modelo built-in Planck13. Supongamos que estás observando una galaxia con un redshift de dos. Quieres saber su lookback time, es decir, cuántos años tardó la luz en llegar a tu telescopio. Coges tu objeto Planck13, llamas a su method lookback time y le pasas el número dos. El method devuelve una cantidad de tiempo en gigaaños. Usas exactamente este mismo patrón para calcular la luminosity distance. Llamas al method luminosity distance con tu redshift, y Astropy devuelve la distancia en megaparsecs, teniendo en cuenta la expansión del universo. Eso cubre de inputs a outputs, pero ¿qué pasa con la inversa? A veces tienes una medición física y necesitas encontrar el redshift correspondiente. Digamos que quieres saber el redshift exacto en el que el universo tenía exactamente dos mil millones de años. No puedes simplemente pasarle una edad a los methods estándar. En su lugar, importas una function llamada z at value. Le pasas el method que quieres invertir, que es el method age de tu modelo Planck13, y le pasas el valor objetivo de dos gigaaños. Astropy ejecuta una rutina numérica de búsqueda de raíces en segundo plano y devuelve el redshift preciso. Convertir entre redshift y tiempo o distancia física es la columna vertebral de la astronomía extragaláctica, y este module te da una source of truth probada para que puedas centrarte en los datos en lugar de debuggear integrales. Como este es el último episodio de nuestra serie sobre Astropy, te animo a leer la documentación oficial, probar estas herramientas de forma práctica, o visitar DEV STORIES DOT EU para sugerir temas para nuestra próxima serie. Gracias por pasar unos minutos conmigo. Hasta la próxima, cuídate.