Astropy: Python for Astronomy

Olá, daqui fala o Alex da DEV STORIES DOT EU. Astropy: Python para Astronomia, episódio 1 de 15. Provavelmente já multiplicaste um array NumPy por uma constante. Mas se misturares acidentalmente metros e quilómetros numa equação complexa, o Python não te vai avisar, e o teu array final vai simplesmente conter os números errados. Deixar a library lidar com as dimensões físicas automaticamente é exatamente o que este episódio aborda. Vamos explorar o coração do Astropy: Units e Quantities. O Astropy lida com unidades físicas através do objeto Quantity. Um Quantity associa um número, ou um array de números, a uma unidade física. Como um Quantity é uma subclass direta de um ndarray do NumPy, não perdes qualquer performance ou funcionalidade de array. Podes fazer slice, broadcast e correr funções matemáticas standard do NumPy neles de forma nativa. Comportam-se como arrays normais que, por acaso, sabem que propriedade física representam. Para criar um Quantity, importas o módulo units do Astropy. A seguir, basta multiplicares o teu número pelo objeto de unit específico. Três multiplicado por units dot parsec cria um Quantity de três parsecs. Muitos developers assumem que esta abstração é lenta, o que é um equívoco comum. É verdade que multiplicar um array NumPy enorme por um objeto unit cria uma nova cópia desse array em memória. Para evitar este overhead, o Astropy faz override do bitwise left-shift operator, que se parece com dois sinais de menor que. Colocas o teu array existente à esquerda, o left-shift operator no meio, e a unit do Astropy à direita. Isto anexa a unit ao array in place, sem copiar os dados subjacentes. Aqui está o ponto chave. A library avalia as relações matemáticas entre as units à medida que fazes os cálculos. Supõe que queres calcular o tempo de viagem de uma nave espacial. A tua distância é três ponto zero parsecs. A tua velocidade é cento e trinta quilómetros por segundo. Crias um Quantity para a distância e divides pelo Quantity da velocidade. O Astropy devolve um novo Quantity para o tempo. Ele lida com a divisão dos valores, e calcula a unit resultante, devolvendo parsec segundos por quilómetro. Essa unit resultante é matematicamente correta, mas não é muito útil de se ler. Podes mudar isto usando o método to, disponível em qualquer Quantity. Chamas o método to e passas a tua unit de destino, como units dot year. O Astropy verifica se as dimensões de origem e de destino são ambas units de tempo, faz a conversão interna, e devolve um novo Quantity expresso em anos. Para standardizações rápidas, também podes aceder às propriedades dot SI ou dot CGS em qualquer Quantity para o converter imediatamente para as units base desses sistemas. Quando fazes cálculos onde as units se cancelam completamente, como dividir metros por centímetros, o Astropy devolve um Quantity dimensionless. A unit ainda existe under the hood como um tipo dimensionless unscaled. Se precisares de passar este resultado para uma library externa que espera floats standard do Python ou arrays NumPy simples, extrais o número bruto usando o atributo value. Antes de extraíres qualquer valor final, lembra-te que podes sempre simplificar units complexas e combinadas até às suas dimensões físicas fundamentais absolutas chamando o método decompose. Se quiseres apoiar o programa, podes procurar por DevStoriesEU no Patreon — isso ajuda-nos a continuar a fazer estes episódios. É tudo por este episódio. Obrigado por ouvires, e continua a programar!

Olá, daqui é o Alex do DEV STORIES DOT EU. Astropy: Python para Astronomia, episódio 2 de 15. Um float padrão de sessenta e quatro bits não consegue representar um timestamp que abranja mil milhões de anos sem destruir a sua própria precisão. Se tentares rastrear um evento celeste distante ao microssegundo, a aritmética de floating-point padrão simplesmente fica sem bits. Esta exata limitação de hardware é o motivo pelo qual precisamos de Escalas de Tempo e Precisão: o módulo astropy.time. Para manter uma precisão sub-nanossegundo ao longo da história cósmica, este módulo evita completamente usar um único número para representar o tempo. Em vez disso, depende de uma arquitetura inteligente de dois floats. Internamente, cada valor de tempo é dividido em dois floats separados de sessenta e quatro bits. O primeiro float armazena a parte inteira da Data Juliana, que regista os dias completos. O segundo float armazena a parte fracionária do dia. Se o Astropy os somasse numa única variável, a precisão iria degradar-se instantaneamente. Ao mantê-los separados, a library consegue realizar aritmética de tempo de alta precisão localmente, independentemente de quão no passado ou no futuro a data se encontre. Quando crias um objeto Time, passas o valor de tempo juntamente com dois argumentos cruciais: o format e a scale. Aqui está o ponto-chave. Os developers costumam confundir o formato visual de uma data com a sua escala de tempo física. São conceitos completamente distintos. O formato dita exclusivamente como os dados são lidos ou escritos. Formatos comuns incluem strings ISO padrão, Datas Julianas Modificadas numéricas e representações especializadas como headers FITS. O formato é apenas o wrapper estrutural à volta dos números. A escala de tempo, no entanto, define o referencial físico desses números. As escalas de tempo físicas têm em conta a rotação da Terra, os leap seconds e os efeitos relativísticos. Exemplos incluem o Tempo Universal Coordenado, conhecido como UTC, o Tempo Terrestre, ou TT, e o Tempo Atómico Internacional, ou TAI. Uma Data Juliana Modificada não é uma escala física, é apenas um formato. Podes facilmente ter um timestamp formatado como uma Data Juliana Modificada, mas fisicamente ancorado à escala UTC. Tens de definir explicitamente tanto o format como a scale ao passar dados raw para um objeto Time. Considera calcular a diferença de tempo entre dois timestamps de telemetria de uma nave espacial. Recebes o primeiro timestamp como uma string de formato ISO de ontem, e o segundo timestamp como uma string ISO de hoje. Primeiro, inicializas dois objetos Time. Passas a string raw para o objeto, declaras o format como ISO e defines a scale para UTC. Fazes isto para ambos os timestamps. Como o Astropy suporta operações vetorizadas, também poderias passar um array enorme destas strings para um único objeto Time, mas a lógica de inicialização subjacente permanece a mesma. Para encontrar o tempo decorrido exato, subtrais o objeto Time mais antigo ao mais recente. O Astropy executa automaticamente a aritmética interna de dois floats, retornando um objeto TimeDelta que guarda a duração exata. A seguir, precisas de mapear esse segundo timestamp de telemetria para uma escala física absoluta e uniforme, removendo os saltos imprevisíveis causados pelos leap seconds do UTC. Pegas no teu segundo objeto Time e simplesmente pedes o seu equivalente em Tempo Atómico Internacional. Consegues isto chamando o atributo TAI diretamente no objeto. O Astropy aciona imediatamente um recálculo dos floats internos, mudando o referencial de UTC para TAI enquanto preserva a precisão total ao nanossegundo. O verdadeiro poder do módulo astropy.time é que nunca geres manualmente os leap seconds ou correções relativísticas; defines os teus formats e scales antecipadamente, e a arquitetura de dois floats garante que a matemática se mantém exata em todo o universo. Gostaria de tirar um momento para te agradecer por ouvires — ajuda-nos imenso. Fica bem!

Daqui fala o Alex da DEV STORIES DOT EU. Astropy: Python para Astronomia, episódio 3 de 15. Converter manualmente coordenadas celestes de um sistema de referência para outro envolve uma trigonometria esférica assustadora. Um único erro de matriz pode facilmente fazer com que o teu telescópio aponte para o hemisfério errado. Navegar no Céu: A classe SkyCoord trata dessa matemática por ti, transformando transformações esféricas complexas num simples attribute lookup. No Astropy, o SkyCoord é o objeto principal de alto nível para representar posições celestes. Funciona como um smart wrapper sobre frames de coordenadas de mais baixo nível. Quando observas um alvo, precisas de registar a sua posição. Normalmente, usas a Ascensão Reta e a Declinação. Para construíres um SkyCoord, passas esses dois valores, especificas as unidades, como graus ou horas, e defines a reference frame. Se não especificares uma frame, ele assume por defeito o International Celestial Reference System, ou ICRS. Podes criar um único ponto no céu facilmente, mas isso levanta uma armadilha frequente. Os utilizadores frequentemente fazem parse de um ficheiro de dados que contém milhares de estrelas, criam um novo objeto SkyCoord para cada estrela, e guardam-nos numa list standard de Python. Quando precisam de fazer cálculos, fazem um loop sobre essa list. Isto é horrivelmente ineficiente e ignora por completo os benefícios de performance da library. O SkyCoord foi construído para lidar com arrays de forma nativa. Em vez de criares milhares de objetos individuais, passas um array de Numpy com os valores de Ascensão Reta e um array correspondente com os valores de Declinação para uma única inicialização do SkyCoord. Recebes de volta exatamente um objeto SkyCoord que contém todo o teu dataset. Considera um cenário onde estás a fazer cross-matching de um conjunto recém-descoberto de cem transientes de rádio registados em ICRS com um catálogo ótico existente. Ao carregares todos os cem transientes para um único SkyCoord baseado em arrays, a library passa os dados para rotinas de C e Numpy altamente otimizadas. Operações que levariam minutos num loop de Python são executadas em milissegundos. Esta estrutura de array torna-se especialmente poderosa quando precisas de transformar os teus dados. Os catálogos astronómicos nem sempre concordam num sistema de coordenadas. Os teus transientes de rádio podem estar em ICRS, mas talvez precises de analisar a sua distribuição em relação ao plano da Via Láctea. Para isso, precisas do sistema de coordenadas galáctico. Aqui está o ponto chave. Não precisas de procurar matrizes de rotação nem de escrever funções de conversão. O Astropy contém um enorme transformation graph built-in que sabe como ir de qualquer frame suportada para qualquer outra frame suportada. Como o SkyCoord faz o wrap deste graph, converter todo o teu array de cem transientes demora exatamente um passo. Pegas no teu objeto SkyCoord existente e chamas o seu método transform to, fornecendo o nome da frame de destino. Melhor ainda, para frames comuns, o Astropy fornece acesso direto a attributes. Se tiveres um objeto SkyCoord em ICRS, simplesmente pedes o attribute galactic. A library calcula automaticamente a transformação e devolve um objeto SkyCoord completamente novo. Este novo objeto contém exatamente as mesmas localizações físicas no espaço, mas representadas como longitude e latitude galácticas. O verdadeiro poder desta classe é que ela separa completamente os dados que representam uma posição celeste da geometria esférica subjacente necessária para a mover através do universo de reference frames astronómicas. É tudo por este episódio. Obrigado por ouvires, e continua a construir!

Olá, daqui é o Alex da DEV STORIES DOT EU. Astropy: Python para Astronomia, episódio 4 de 15. Podes saber exatamente onde uma estrela está esta noite, mas sem as correções de proper motion e da velocidade da Terra, o teu telescópio vai estar a apontar para o espaço vazio na próxima década. É aqui que vamos Além da Ascensão Reta e Declinação: Tracking 3D e Velocidades. Por default, as coordenadas mapeiam uma posição plana no céu usando ângulos. Para modelar um sistema físico, como um sistema estelar binário, precisas do espaço físico real entre os componentes. Muitas pessoas tentam calcular uma separação tridimensional usando apenas a ascensão reta e a declinação. Isso não funciona. Para usares o método de separação tridimensional, tens de fornecer um parâmetro distance ao criar o objeto coordinate. Passas um valor de distância com uma unidade física, como parsecs, juntamente com as tuas coordenadas angulares. Assim que ambos os objetos contiverem estes dados de distância, chamas o método de separação tridimensional na primeira coordenada, passando a segunda coordenada como argumento. O Astropy devolve a linha física direta entre elas no espaço tridimensional, lidando automaticamente com a trigonometria de fundo. Ora, esses objetos não são estáticos. Para modelar o seu movimento ao longo do tempo, anexas dados de velocidade diretamente ao objeto coordinate no momento da criação. Fazes isso passando parâmetros de proper motion. Especificamente, forneces o proper motion em ascensão reta e o proper motion em declinação. Estes recebem unidades angulares por tempo, como miliarcosegundos por ano. Também forneces um parâmetro de radial velocity, que recebe uma velocidade física, como quilómetros por segundo. Quando juntas tudo isto, o objeto coordinate torna-se um vetor completo no espaço de fase. Ele guarda a localização atual do objeto e o vetor exato para onde ele vai. Aqui está o ponto-chave. O teu telescópio também se está a mover pelo espaço. A Terra gira no seu eixo e orbita o Sol. Se medires a velocidade radial de uma estrela a partir do solo, a tua medição raw é contaminada pela própria velocidade da Terra naquele exato momento. Para partilhares os teus dados com outros astrónomos, tens de remover o movimento da Terra. Deslocas o teu ponto de referência para um referencial estável, geralmente o centro de massa do sistema solar. A isto chama-se a correção baricêntrica da velocidade radial. Para calcular esta correção no Astropy, precisas de definir onde está o observador usando um objeto EarthLocation. Crias isto passando a longitude, latitude e elevação exatas do teu instrumento. Em alternativa, podes extrair um local estabelecido diretamente do site registry built-in do Astropy, consultando um nome conhecido como o Observatório Keck. A seguir, precisas da hora exata em que a observação ocorreu. Com a tua localização e hora prontas, chamas o método de radial velocity correction diretamente no objeto coordinate do teu alvo. Passas-lhe a hora da observação e a tua EarthLocation. O Astropy calcula o vetor de velocidade do Observatório Keck naquele milissegundo específico, em relação ao alvo, e devolve o offset de velocidade. Adicionas este valor de correção à tua velocidade radial raw medida. O resultado é uma medição limpa e padronizada, referenciada ao baricentro do sistema solar. A principal conclusão aqui é que uma coordenada não é apenas um ponto fixo num mapa; é um modelo cinemático completo que guarda a posição do alvo, a sua trajetória e a geometria necessária para corrigir o teu próprio movimento. Obrigado por ouvirem. Fiquem bem.

Olá, daqui é o Alex da DEV STORIES DOT EU. Astropy: Python para Astronomia, episódio 5 de 15. O Pandas é incrível para dados planos, mas o que acontece quando uma única coluna no teu dataset precisa de guardar uma time series, uma unidade física e uma coordenada espacial? Os dataframes standard falham. Para resolver isto, precisas de dominar os dados tabulares: a classe QTable. Se trabalhas em Python, já conheces o Pandas. O Pandas assume que os teus dados são planos, preferindo um valor simples por célula. Na astronomia, os dados raramente são simples. Uma única observação pode exigir unidades estritas, uma matriz de valores, ou uma coordenada celeste complexa. O Astropy fornece uma estrutura de dados tabulares customizada, desenhada especificamente para esta realidade. Vais notar que o Astropy tem tanto uma classe Table standard como uma classe QTable. As pessoas costumam confundir as duas. A Table standard regista a informação das unidades como metadata de background, mas devolve arrays NumPy simples quando extrais uma coluna. Uma QTable impõe uma unit-awareness estrita. Quando recuperas uma coluna de uma QTable, ela garante que recebes de volta um objeto Quantity nativo do Astropy. A unidade física está permanentemente associada aos números. Vamos ver como construir uma QTable. Começas por importar a QTable do módulo astropy dot table. Podes construí-la usando um dicionário onde as chaves são os nomes das tuas colunas e os valores são os teus arrays de dados. Supõe que estás a criar um catálogo simples de galáxias. A tua primeira coluna é plain text. Atribuis uma lista de strings que representam os nomes das galáxias. Agora, precisas de registar onde estas galáxias estão. Não queres colunas separadas e desconectadas para a ascensão reta e declinação. Em vez disso, crias um objeto SkyCoord do Astropy com as posições de todas as tuas galáxias. Passas este único objeto SkyCoord diretamente para a tua tabela como a segunda coluna. Esta é uma coluna mixin. Os mixins permitem que tipos complexos do Astropy, como objetos SkyCoord ou Time, se comportem exatamente como arrays de dados standard dentro da tabela. Podes fazer slice, sort e filter às linhas da tabela, e o objeto mixin mantém automaticamente os seus dados internos perfeitamente sincronizados. A seguir, precisas de guardar as medições de fluxo em três bandas de comprimento de onda diferentes para cada galáxia. Num dataframe típico, serias obrigado a criar três colunas separadas. Numa QTable, usas uma coluna multidimensional. Defines um único array com um shape de N linhas e três colunas, associas uma unidade física de fluxo a tudo isto, e atribuis como a tua terceira coluna da tabela. É aqui que a coisa fica interessante. A QTable aceita o array multidimensional nativamente. Uma única linha nessa coluna agora guarda um array totalmente contido de três medições unit-aware. Quando fazes print desta tabela, o Astropy formata-a de forma limpa. Ele alinha os arrays aninhados e mostra as unidades diretamente debaixo dos headers das colunas. A tua metadata e as tuas medições ficam inseparáveis. A QTable não é apenas uma folha de cálculo; é um container especializado, construído para respeitar a física e a geometria dos teus dados. Obrigado por estares aí. Espero que tenhas aprendido algo novo.

Olá, daqui fala o Alex da DEV STORIES DOT EU. Astropy: Python para Astronomia, episódio 6 de 15. Procurar uma fonte específica num catálogo enorme geralmente significa executar um full linear scan que devora tempo de processamento. Mas se estruturares os teus dados corretamente, podes reduzir esses lookups de minutos para milissegundos. É isso que vamos abordar hoje: Operações Avançadas em Tabelas: Masking e Joins. As tabelas do Astropy não são apenas arrays. Funcionam como uma base de dados relacional in-memory que entende nativamente unidades físicas. Supõe que tens um catálogo fotométrico e um catálogo espectroscópico, e precisas de os combinar com base num source ID partilhado. Antes de fazeres o merge, tens de lidar com missing data. O teu catálogo fotométrico provavelmente tem valores de magnitude em falta porque uma observação falhou ou um sensor perdeu um frame. Podes tentar filtrar esses valores em falta usando boolean arrays standard do numpy. Não faças isso. Masks standard do numpy aplicadas diretamente a uma tabela unit-aware vão remover silenciosamente as tuas unidades físicas e quebrar mixin objects. Em vez disso, o Astropy lida com isto usando a MaskedColumn. Quando trabalhas dentro de uma QTable, que é a classe de tabela unit-aware, o Astropy usa automaticamente operações de MaskedColumn under the hood para missing data. Isto garante que a tua coluna de magnitude mantém as suas unidades físicas intactas, enquanto marca com segurança as missing entries para que não corrompam os teus downstream calculations. Com o teu catálogo fotométrico devidamente mascarado e pronto, é hora de o combinar com os teus dados espectroscópicos. O Astropy fornece uma função de join que funciona de forma muito semelhante a uma base de dados relacional. Passas à função a tua left table, a tua right table, e especificas o nome da coluna partilhada como key, que neste caso é o teu source ID. Se especificares um inner join, a função avalia ambos os datasets e devolve uma nova tabela contendo apenas as rows onde o source ID existe em ambos os catálogos. Aqui está o ponto chave. Como estás a usar objetos QTable, a operação de join reconcilia e preserva automaticamente as unidades de ambos os lados. A tua merged table vai conter os parâmetros físicos precisos dos dados espectroscópicos, juntamente com as magnitudes devidamente mascaradas dos dados fotométricos, perfeitamente alinhadas. Agora tens um merged catalog, e a tua análise requer extrair os parâmetros exatos para um source ID específico. Sem intervenção, encontrar uma row numa tabela enorme exige a verificação sequencial de cada entrada. O Astropy resolve este performance bottleneck com table indexing. Podes instruir a tabela a criar um index na coluna do teu source ID. Nos bastidores, o Astropy constrói uma estrutura de dados B-tree, mapeando os teus source IDs diretamente para as respetivas localizações das rows em memória. Uma vez que o index está construído, recuperas os teus dados usando a propriedade location da tabela, passando o teu target ID. O engine percorre a B-tree, ignora o full scan por completo, e vai buscar a tua row em tempo logarítmico. Podes até indexar várias colunas simultaneamente para lidar com lookups complexos, como encontrar uma row tanto pelo source ID como pela data de observação. Construir um index requer uma fração do compute time inicialmente, mas compensa imediatamente quando precisas de correr lookups repetidos em heavy datasets. O verdadeiro poder das tabelas Astropy não é apenas armazenar dados, mas manter a integridade física das tuas unidades através de relational joins complexos e queries B-tree de alta velocidade. É tudo por este episódio. Obrigado por ouvires, e continua a construir!

Olá, daqui é o Alex da DEV STORIES DOT EU. Astropy: Python para Astronomia, episódio 7 de 15. Tens um ficheiro de texto antigo e desorganizado com coordenadas de estrelas e precisas de o converter para um standard binário moderno e comprimido. Na maioria das libraries, isso significa escreveres um parser customizado, mapeares data types e lutares com serializers binários. No Astropy, consegues fazer isto com exatamente duas linhas de código. Isto graças à Unified I/O Interface. A Unified I/O Interface é uma layer polimórfica de manipulação de dados. Em vez de te forçar a importar um module específico para cada tipo de ficheiro, o Astropy expõe um método genérico de read e write diretamente nas suas estruturas de dados principais. Quer estejas a lidar com uma Table standard, uma QTable com unidades físicas, ou um array NDData multidimensional, o modelo de interação permanece idêntico em standards de ficheiros completamente diferentes. Existe um equívoco comum sobre a extração de dados. Quando os developers precisam de ler um ficheiro FITS, muitas vezes vão diretos ao module de baixo nível, astropy dot io dot fits. Esse module serve estritamente para manipulação raw de ficheiros, como editar header cards individuais ou inspecionar byte streams não formatados. Se apenas queres extrair dados tabulares de um ficheiro FITS, não o deves usar. Em vez disso, usas o método Table dot read. Ele faz bypass à extração manual do header e lida com o data mapping subjacente automaticamente. Quando chamas o método read e passas um file path ou um file object aberto, o Astropy confia num motor robusto de inferência de formato. Primeiro, verifica a extensão do ficheiro. Se forneceres uma string terminada em dot h5 ou dot parquet, ele encaminha o request para o parser especializado correspondente. Se a extensão for ambígua, inexistente, ou apenas uma extensão de texto genérica, o motor desce um nível e inspeciona o conteúdo do ficheiro. Lê os primeiros bytes dos dados à procura de assinaturas conhecidas ou magic numbers para identificar o standard de forma fiável. Se a inferência automática falhar completamente, podes fazer bypass passando uma string de argumento de format, como ascii dot csv, para forçar o parser correto. Eis como isto lida com o nosso cenário inicial. Tens aquela tabela de texto ASCII antiga com coordenadas de estrelas. Chamas QTable dot read e passas-lhe o file path do teu ficheiro de texto. O Astropy deteta o formato ASCII, faz o parse das colunas, e devolve um objeto QTable totalmente preenchido em memória. A seguir, queres guardar isto como uma tabela binária FITS comprimida. Pegas nesse mesmo objeto QTable em memória e chamas o seu método write. Forneces um novo filename terminado em dot fits, e passas um parâmetro extra para ativar a compressão. Também tens de passar uma flag overwrite definida como true, porque o método write protege os ficheiros existentes por default. É aqui que a coisa fica interessante. O Astropy muda dinamicamente o contexto de parsing de plain text para serialização binária complexa under the hood. Os protocolos de ficheiro subjacentes são completamente distintos, mas a interface que usas permanece inalterada. Como a interface está associada à estrutura de dados em vez do formato do ficheiro, as tuas pipelines de processamento de dados ficam decoupled dos teus meios de armazenamento. A principal conclusão aqui é que alterar a forma como a tua aplicação armazena e partilha dados requer apenas a alteração da extensão de um ficheiro numa única string, em vez de reescreveres toda a tua pipeline de ingestão de dados. Por hoje é tudo. Obrigado por ouvires — vai construir algo fixe.

Olá, daqui fala o Alex da DEV STORIES DOT EU. Astropy: Python para Astronomia, episódio 8 de 15. O standard de ficheiros FITS foi criado na década de 1980 para sistemas Fortran, armazenando metadata em blocos rígidos de oitenta bytes, modelados diretamente a partir de cartões perfurados físicos. Lidar com estruturas de cartões perfurados em código moderno raramente é agradável. O Astropy esconde esta complexidade traduzindo esses blocos para estruturas nativas, e é exatamente por isso que este episódio se foca em Desmistificar os Headers FITS e as HDUs. Pensa num ficheiro FITS como um container. Dentro desse container estão as Header Data Units, universalmente conhecidas como HDUs. Qualquer ficheiro FITS tem de conter pelo menos uma destas, chamada de Primary HDU. Muitas vezes, esta unidade primária não contém nada além de metadata, enquanto as imagens ou tabelas binárias propriamente ditas vêm logo a seguir como Extension HDUs. Quando abres um ficheiro FITS usando o Astropy, ele faz o parse deste container e devolve-te um objecto HDUList. Navegas por este objecto usando a bracket notation standard para selecionar HDUs individuais. Aqui está o ponto chave sobre indexing. O standard FITS oficial usa estritamente one-based indexing devido às suas raízes em Fortran. No entanto, como o Astropy é uma library Python, ele impõe zero-based indexing. A Primary HDU está sempre no index zero, e a primeira extensão no index um. É um detalhe simples, mas esquecê-lo causa constantes off-by-one errors. Cada objecto HDU contém um atributo header. É aqui que vivem aqueles antigos blocos de oitenta bytes. Na terminologia FITS, cada linha de metadata é chamada de card. Um card completo contém uma keyword, um value e, às vezes, um comentário descritivo. O Astropy processa estes cards e expõe-te o header como um objecto que atua exatamente como um dictionary Python standard. Se precisares do tempo de exposição, basta passares a keyword EXPTIME para o header. Modificar valores funciona da mesma maneira. Atribuis um novo valor à keyword usando um sinal de igual. Se também precisares de atualizar o comentário nesse card específico, atribuis um tuple contendo tanto o novo valor como a nova string de comentário. O Astropy faz o repack automático destes dados de volta para o standard de oitenta bytes exigido, em background. Esta tradução funciona perfeitamente até encontrares legacy data. Ficheiros FITS mais antigos violam frequentemente o standard rigoroso. Podem apresentar keywords demasiado longas ou conter caracteres ilegais. Como o Astropy valida rigorosamente os headers por default, tentar abrir um ficheiro não compatível vai muitas vezes lançar uma exception imediatamente. Em vez de abandonares o ficheiro, podes gerir isto usando o método verify. Imagina que abres uma imagem antiga de um telescópio e dás de caras com um validation error em relação à formatação. Capturas o file object e chamas o seu método verify, passando o string argument fix. O Astropy vai fazer o scan de todos os header cards, reparar automaticamente os problemas de formatação onde for possível, e suprimir os erros para os campos corrompidos que corrigir. Assim que o header estiver estabilizado, podes fazer o update em segurança de um card OBSERVER corrompido com a string correta, e depois escrever a tua HDUList limpa de volta para o disco. Trata sempre os teus updates de metadata FITS como simples dictionary operations, mas mantém esse método verify pronto para o momento em que a legacy data quebrar as regras. Se quiseres ajudar a manter o programa no ar, procura por DevStoriesEU no Patreon. Obrigado por ouvires. Até à próxima!

Olá, daqui é o Alex da DEV STORIES DOT EU. Astropy: Python para Astronomia, episódio 9 de 15. Não precisas de um supercomputador para analisar uma imagem de cem gigabytes. Só precisas de uma maneira de enganar o teu sistema operativo para que ele leia apenas os pixels exatos que te interessam. Lidar com ficheiros FITS massivos e cloud storage é o mecanismo exato que usas para conseguir isso. Ao trabalhar com arrays astronómicos massivos, tentar carregar um ficheiro inteiro para a memória vai fazer o teu processo crashar imediatamente. O Astropy evita isto usando uma funcionalidade chamada memory mapping. Ao abrires um ficheiro FITS, podes passar um argumento chamado memmap definido como True. Um memory map não lê os dados da imagem para a tua RAM física. Em vez disso, mapeia o ficheiro no teu disco rígido diretamente para o espaço de endereçamento de memória virtual do teu computador. Quando acedes a um slice específico do array, o teu sistema operativo vai buscar apenas esse bloco específico de dados ao disco. Tens a conveniência de fingir que o ficheiro inteiro está carregado, mas só pagas o custo de memória física pelos pixels que processas ativamente. Este comportamento introduz uma armadilha muito comum. Podes abrir um ficheiro FITS, atribuir o array da imagem a uma variável, e depois chamar close no objeto do ficheiro. Esperas que o file handle seja libertado e o recurso fique livre. Mas não é o que acontece. Como os memory maps dependem do sistema operativo para ligar o ficheiro a uma variável, o ficheiro permanece aberto e bloqueado enquanto existir qualquer referência a esse array na tua sessão de Python. Para realmente libertares o recurso e fechares o file handle completamente, tens de apagar explicitamente a tua variável de dados usando o comando delete standard do Python. Isso resolve a questão dos ficheiros locais, mas os datasets de astronomia modernos muitas vezes vivem em servidores remotos. Fazer o download de centenas de gigabytes só para inspecionar uma pequena região é um desperdício de largura de banda e de tempo. O Astropy lida com dados remotos integrando-se com a library file system spec. Ao abrires um ficheiro, passas um argumento chamado use fsspec definido como True. Isto diz à library para tratar as localizações de cloud storage exatamente como drives locais. Considera uma imagem de duzentos megabytes do Telescópio Espacial Hubble alojada num bucket público do Amazon S3. Só queres um pequeno recorte de dez por vinte pixels à volta de uma estrela específica. Primeiro, chamas fits open, passando o uniform resource identifier do S3 em vez de um file path local, juntamente com use fsspec definido como True. O Astropy liga-se ao bucket e faz o download apenas dos blocos de cabeçalho FITS. Isto permite-lhe entender a estrutura do ficheiro sem tocar nos dados reais da imagem. A seguir, navegas até à extensão de imagem correta e fazes o slice do array de dados usando indexação standard, agarrando apenas no teu bloco de dez por vinte. É aqui que a coisa fica interessante. O Astropy traduz esse slice do array em requests HTTP específicos de byte range. A tua máquina liga-se ao Amazon S3, pede apenas os bytes físicos correspondentes a esses duzentos pixels, e faz o download exatamente desse pequeno chunk. Ficas com o teu recorte instantaneamente, enquanto os restantes cento e noventa e nove megabytes do ficheiro ficam no servidor intocados. Combinar memory mapping local com streaming remoto de byte range significa que os teus scripts de análise são limitados apenas pelos dados que computas ativamente, nunca pelo tamanho total do ficheiro em si. Gostava de tirar um momento para te agradecer por ouvires — ajuda-nos imenso. Fica bem!

Olá, daqui é o Alex da DEV STORIES DOT EU. Astropy: Python para Astronomia, episódio 10 de 15. Se fizeres um slice a um array numérico standard, só obténs os raw pixels. Mas os dados de um telescópio nunca são apenas uma matriz de números. Quando fazes um crop a uma imagem para observar uma única estrela, os teus limites de erro, as tuas masks de dead pixels e as tuas coordenadas celestes têm de ficar perfeitamente alinhados, caso contrário, toda a tua análise falha. É exatamente por isso que usamos Gridded Data: as classes NDData e CCDData. Na sua essência, o Astropy fornece a base class NDData como um container standard para dados astronómicos em grelha. Embora a NDData lide com a estrutura geral, para imagens óticas ou infravermelhas reais, vais tipicamente usar a sua subclass especializada chamada CCDData. Este container existe para ligar os teus valores de raw pixels diretamente às suas propriedades físicas. Vamos ver como inicializar um objeto CCDData para uma exposição raw de um telescópio. Não passas simplesmente uma grelha bidimensional de números. Passas a grelha de raw data, e tens de atribuir uma unidade física, como eletrões ou analog-to-digital units. A seguir, anexas uma boolean mask. Se um raio cósmico de alta energia atingir o teu detetor durante a exposição, fazes flag desses pixels arruinados específicos como true num mask array separado, e passas isso diretamente para o objeto CCDData. Depois vem o error tracking. Anexas um uncertainty array. Para a nossa raw image, podes calcular o ruído de Poisson e anexá-lo usando a class Standard Deviation Uncertainty ou a class Variance Uncertainty. Agora, os teus valores de brilho, as tuas unidades, as tuas bad pixel flags e os teus limites de ruído estatístico estão trancados juntos como um único objeto unificado. Isto gera uma confusão comum. Assim que tiveres este objeto totalmente carregado, não tentes usar operadores matemáticos standard, como um simples sinal de mais ou menos, para processar a imagem. Se tentares fazer aritmética normal de arrays para subtrair uma dark background frame, vais deixar as tuas incertezas para trás. Em vez disso, tens de usar os built-in arithmetic methods fornecidos pela class, como as funções add, subtract, multiply e divide. É aqui que a coisa fica interessante. Quando chamas o método subtract, o Astropy não subtrai apenas os valores dos pixels. Ele propaga automaticamente as tuas variance uncertainties através da operação usando regras estatísticas standard, produzindo um perfil de ruído matematicamente sólido na imagem resultante. Mais tarde no teu workflow, podes aperceber-te de que a tua imagem completa do telescópio é demasiado grande, e só queres analisar uma única galáxia localizada no canto superior direito. Consegues fazer isto usando uma tool chamada Cutout2D. Forneces o teu objeto CCDData principal, as coordenadas exatas do centro da tua galáxia alvo, e o tamanho da bounding box que queres extrair. Como empacotaste tudo num container CCDData, o Cutout2D lida com a sincronização complexa automaticamente. Ele retorna um novo objeto mais pequeno. Ele faz um slice aos pixels da imagem, mas também faz crop automaticamente à cosmic ray mask e ao variance uncertainty array para as exatas mesmas dimensões. Crucialmente, ele traduz o world coordinate system subjacente. A coordenada de pixel zero-zero no teu novo cutout mapeia corretamente para a exata mesma ascensão reta e declinação que na master image. Ao tratar os pixel data, as margens de erro físico e as coordenadas espaciais como uma unidade indivisível, estas classes evitam a corrupção silenciosa de dados à medida que a tua imagem passa por pipelines de análise complexos. É tudo por este episódio. Obrigado por ouvires, e continua a criar!

Olá, daqui é o Alex do DEV STORIES DOT EU. Astropy: Python para Astronomia, episódio 11 de 15. Cada pixel num detetor de um telescópio é um quadrado plano e discreto, mas o céu é uma esfera curva contínua e matematicamente complexa. Mapear um ponto nesse detetor plano de volta para a sua posição real no universo é um problema geométrico complicado. O World Coordinate Systems, ou WCS, é o mecanismo que descodifica essa geometria. O WCS atua como a ponte definitiva entre o hardware e a física. Ele fornece a transformação matemática necessária para converter a coordenada de um pixel numa world coordinate, como Ascensão Reta e Declinação. Em dados astronómicos, estas regras de transformação geralmente são armazenadas como metadados padronizados dentro do header de um ficheiro FITS. O header contém keywords específicas que definem o pixel de referência, as coordenadas físicas desse pixel e a matriz de rotação ou escala usada pelo telescópio. O Astropy lê estas keywords e constrói um objeto de transformação ativo que modela todo o plano focal. Antes de fazer qualquer cálculo, precisamos de esclarecer uma fonte constante de confusão na indexação. O standard FITS define as coordenadas de pixel como one-indexed, o que significa que o primeiro pixel no detetor é o pixel um. O Python, e consequentemente o NumPy, é zero-indexed. O Astropy resolve esta dualidade através de duas layers diferentes. A API mais antiga, de low-level, não é um sistema de indexação unificado; exige que passes explicitamente um argumento origin de zero ou um sempre que transformas uma coordenada. Mas a moderna Shared Python Interface, de high-level, opera inteiramente com base na convenção zero-indexed do Python. Ela espera pixels zero-based da tua parte e lida automaticamente com o offset para o standard FITS internamente. Aqui está o ponto-chave. A API de high-level torna a conversão de coordenadas incrivelmente concisa. Digamos que localizaste uma estrela brilhante no teu array de imagem no pixel x igual a 30 e y igual a 40, e precisas de encontrar a sua posição real no espaço. Primeiro, lês o header do teu ficheiro FITS usando as ferramentas de input-output do Astropy. A seguir, inicializas um objeto WCS passando esse header diretamente para a class WCS. Finalmente, chamas um método chamado pixel to world nesse objeto WCS, passando os teus valores de pixel x e y de 30 e 40. O método avalia a matemática da projeção e retorna um objeto SkyCoord standard do Astropy. Este objeto contém as coordenadas físicas e está totalmente ciente do seu reference frame, como o ICRS. A beleza desta shared interface é que te protege dos raw numbers. Em vez de retornar um array genérico de floats representando graus abstratos, dá-te objetos ricos que entendem as suas próprias unidades físicas e sistemas de coordenadas. Podes pegar nesse SkyCoord e usá-lo imediatamente para fazer uma referência cruzada com um catálogo de estrelas. O sistema funciona exatamente da mesma forma no sentido inverso. Se tiveres as coordenadas de uma galáxia conhecida e quiseres determinar exatamente quais os pixels que ela ocupa no sensor da tua câmara, chamas o método world to pixel no teu objeto WCS. Passas o teu SkyCoord, e ele retorna as posições exatas de pixel x e y em floating-point. A API WCS de high-level isola a lógica da tua aplicação da matemática de projeção subjacente, o que significa que o teu código de conversão pixel-to-sky permanece idêntico, independentemente de estares a trabalhar com um mapa de rádio plano ou um mosaico ótico de campo amplo profundamente distorcido. É tudo por este episódio. Obrigado por ouvires, e continua a desenvolver!

Olá, daqui fala o Alex da DEV STORIES DOT EU. Astropy: Python para Astronomia, episódio 12 de 15. Em muitas bibliotecas científicas, a equação matemática que queres avaliar está fortemente acoplada ao algoritmo usado para a otimizar. Se quiseres alterar o funcionamento da otimização, muitas vezes tens de reescrever a forma como definiste a tua matemática. O Astropy elimina completamente este problema com a sua abordagem aos Modelos Analíticos e Fitting. A filosofia central de design do subpacote modeling do Astropy é uma separação estrita de responsabilidades. A definição matemática da tua equação é um objeto. O motor algorítmico que faz o fit dessa equação aos teus dados é um objeto completamente separado. Isto significa que podes definir a tua matemática uma vez e, depois, testá-la contra vários algoritmos de fitting diferentes, simplesmente passando o model para um fitter diferente. O Astropy fornece dezenas de modelos matemáticos predefinidos. Se estiveres a modelar uma tendência constante, usas um model Linear1D. Se estiveres a estudar uma linha de emissão num espectro, recorres a um model Gaussian1D. Estes objetos model encapsulam os seus parâmetros, como a amplitude, a média e o desvio padrão. Antes de olharmos para o processo de fitting, precisamos de abordar uma fonte frequente de confusão. No Astropy, os models são objetos callable. Passas um array de coordenadas diretamente para um model instanciado, e ele avalia a matemática para devolver os valores correspondentes. Mais importante ainda, quando otimizas um model, o fitter não muta o teu objeto inicial original. Devolve sempre uma instância completamente nova de um fitted model. A tua estimativa original é preservada exatamente como a definiste. Considera um cenário em que tens dados de um array unidimensional ruidoso que representam uma característica espectral. Primeiro, inicializas um model Gaussian1D com as tuas estimativas iniciais aproximadas para a amplitude, média e largura. Como o Astropy separa a matemática do optimizer, anexas as tuas restrições físicas diretamente aos parâmetros do model. Supõe que já conheces a coordenada central exata desta linha espectral. Acedes ao parâmetro mean no teu model e defines a sua propriedade fixed como True. O algoritmo de otimização agora deixará esse valor inalterado. Também podes estabelecer limites matemáticos. Ao definires um limite mínimo de zero no parâmetro amplitude, forças o algoritmo a rejeitar quaisquer soluções que resultem num pico negativo. Com o teu model inicial totalmente restringido, chamas o fitter. Para equações não lineares, como uma Gaussiana, instancias o fitter de mínimos quadrados de Levenberg-Marquardt, conhecido no Astropy como LevMarLSQFitter. Executas o fit chamando este objeto fitter, passando o teu model Gaussian inicial juntamente com os teus arrays de dados horizontal e vertical. O algoritmo corre e devolve um model Gaussian1D completamente novo, contendo os valores dos parâmetros otimizados. Como este novo model é diretamente callable, basta passares o teu array horizontal original para ele, para gerar uma curva matemática suave que podes plotar contra os teus dados ruidosos. Aqui está o ponto chave. Ao armazenar as restrições no model em vez de as passar para o solver, os algoritmos de fitting permanecem genéricos. Concentras os teus esforços em codificar a realidade física do teu problema no model matemático, permitindo que o Astropy troque a lógica de otimização em background sem quebrar a tua pipeline. É tudo por este episódio. Obrigado por ouvires, e continua a construir!

Olá, daqui é o Alex da DEV STORIES DOT EU. Astropy: Python para Astronomia, episódio 13 de 15. Em vez de escreveres à mão uma função matemática gigante com quinze parameters para fazer o fit a um espectro confuso, e se pudesses simplesmente somar formas básicas como peças de Lego e deixar o Python tratar do cálculo? É exatamente isso que vamos abordar hoje com Compound Models e Custom Fits. No Astropy, raramente precisas de construir modelos analíticos complexos do zero. Pegas em blocos simples e predefinidos e combinas-os usando operadores aritméticos standard do Python, como adição, subtração, multiplicação ou divisão. Quando somas dois models do Astropy, não obténs um array estático de números avaliados. Obténs um model object totalmente novo e funcional. Esta estrutura compound sabe como se avaliar a si própria, calcular as suas derivadas e fazer o track de cada parameter dos base models originais. Considera um cenário específico. Tens um espectro com duas linhas de emissão distintas sobrepostas a um background continuum plano. Queres fazer o fit a toda esta estrutura em simultâneo. Começas por instanciar um polynomial model básico para servir de baseline plana. A seguir, instancias dois Gaussian models unidimensionais separados para representar as duas linhas de emissão. Para criares o teu perfil espectral final, basta definires uma nova variable igual ao polynomial mais a primeira Gaussian mais a segunda Gaussian. O Astropy faz o merge automático deles numa única compound evaluation tree. Isto introduz uma armadilha comum em relação ao acesso aos parameters. Ao criares este compound model, podes perguntar-te como isolar a amplitude da segunda linha de emissão. Como ambos são Gaussians, ambos têm um parameter chamado amplitude. O Astropy resolve esta colisão fazendo o append automático de sufixos numéricos com base na ordem em que os models foram combinados. A primeira Gaussian tem os seus parameters renomeados para amplitude zero, mean zero e standard deviation zero. A segunda Gaussian recebe amplitude um, mean um, e por aí fora. Se alguma vez perderes o rasto de qual parameter pertence a qual componente, podes inspecionar o attribute parameter names do teu compound model para veres a lista exata gerada. Agora, a segunda parte disto é fazer o fit de dados que trazem unidades físicas. As medições astronómicas não são apenas raw floats. A tua independent variable pode ser o comprimento de onda em Angstroms, e a tua dependent variable pode ser a densidade de fluxo em Janskys. Os models do Astropy lidam com isto de forma elegante através do Quantity object. Quando passas os teus data arrays para um fitter, passas os Quantity objects do Astropy diretamente, sem fazeres o strip das unidades. O fitter analisa as unidades dos teus input data e a estrutura do teu compound model. Ele apanha mismatches dimensionais antes sequer de o fit começar. Assim que o fit converge, os parameters no model resultante vão ter automaticamente as unidades físicas corretas. As tuas Gaussian means atualizam-se para Angstroms, e as tuas amplitudes atualizam-se para Janskys. Não precisas de escrever custom conversion logic ou fazer o strip das unidades antes do fitting só para as voltares a anexar mais tarde. O compound model força a consistência dimensional durante todo o processo. Aqui está o key insight. Quando usas um sinal de mais entre dois models, não estás apenas a fazer chaining de funções. Estás a construir uma única equação unificada que mantém uma strict unit awareness e parameter traceability desde os raw data até ao fit final. É tudo por este episódio. Vemo-nos na próxima!

Olá, daqui fala o Alex da DEV STORIES DOT EU. Astropy: Python para Astronomia, episódio 14 de 15. Tens catorze mil fotos de telescópio de uma estrela, com espaçamento irregular. Algures nesse ruído, há uma queda de zero vírgula zero um por cento na luminosidade causada por um planeta alienígena a passar-lhe à frente. Aqui tens o algoritmo exato para o encontrares. Este episódio é sobre Time Series Analysis e a caça a exoplanetas. O Astropy lida com este workflow usando a class TimeSeries. Antes de avançarmos, vamos esclarecer um equívoco comum. Uma TimeSeries não é uma estrutura de dados completamente nova com as suas próprias regras. É simplesmente uma subclass de QTable. Isto significa que todos os methods de manipulação de tabelas, operações de colunas e técnicas de masking que já conheces continuam a funcionar perfeitamente. A única diferença é que a primeira coluna é estritamente forçada a ser um object Time do Astropy. Esta rigidez garante que os teus timestamps e as tuas medições de flux se mantenham perfeitamente alinhados, quer as tuas observações sejam uniformemente espaçadas ou totalmente aleatórias. Para começares a caçar um exoplaneta, primeiro carregas uma light curve. O Astropy oferece readers built-in, permitindo-te passar um ficheiro FITS do Kepler diretamente para a função read da TimeSeries. Ele configura automaticamente a coluna Time e importa as medições de luz, geralmente chamadas de flux. Os dados do Kepler são extremamente densos, contendo por vezes milhares de data points ao longo de alguns meses. Estes raw data contêm frequentemente ruído de alta frequência proveniente da nave espacial ou de atividade estelar. Podes suavizá-los usando downsampling através de aggregation. Defines o tamanho de um time bin, como dez minutos, e passas uma função de aggregation, como a mean. O Astropy agrupa os timestamps nestes bins e faz a média do flux, reduzindo o tamanho do dataset e suprimindo o ruído aleatório sem apagar o sinal real do trânsito. Agora tens dados limpos, mas os trânsitos dos exoplanetas estão escondidos algures ao longo de uma enorme timeline. Para encontrares o planeta, precisas de um periodogram. Podes estar familiarizado com o periodogram de Lomb-Scargle, que é excelente para encontrar sine waves suaves e contínuas, como a luz de uma estrela pulsante. Mas um planeta a passar em frente a uma estrela não cria uma sine wave. Cria uma linha plana, uma queda repentina, um fundo plano e uma subida repentina. O sinal é uma box. Devido a este formato, usas o periodogram Box Least Squares, ou BLS. Passas a tua coluna de time e a tua coluna de flux para a função BLS. O algoritmo avalia então uma grid inteira de possíveis períodos orbitais, testando talvez tudo desde uma órbita de um dia até uma órbita de cinquenta dias. Em cada frequência testada, ele desliza uma box matemática sobre os dados, tentando fazer match com a profundidade e duração de um possível trânsito planetário. Ele devolve um power spectrum que mostra o quão bem a box fez fit em cada uma das frequências. Simplesmente extrais o período que gerou o pico de power mais alto. Essa é a tua suspeita de órbita do exoplaneta. Assim que tiveres esse período exato, precisas de o verificar visualmente. Pegas na tua TimeSeries original e chamas o method fold, passando o período que acabaste de descobrir. O folding pega em cada observação ao longo de meses ou anos e mapeia-a para um único ciclo orbital. Em vez de uma timeline cronológica, o teu eixo horizontal passa a ser a phase, variando de zero a um. Sempre que o planeta transitou pela estrela ao longo da missão, esses data points individuais são empilhados uns sobre os outros exatamente na mesma phase. Esta é a parte que importa. Quando fazes o plot dessa TimeSeries com o fold, o scatter aleatório da timeline desaparece, e uma queda nítida e inegável em forma de U aparece precisamente no centro do teu gráfico. Acabaste de usar geometria e tempo para puxar um mundo invisível para fora do ruído. Obrigado por passares uns minutos comigo. Até à próxima, fica bem.

Olá, daqui fala o Alex do DEV STORIES DOT EU. Astropy: Python para Astronomia, episódio 15 de 15. Resolver a métrica do universo em expansão geralmente exige a avaliação manual de enormes integrais elípticas. Ou podes simplesmente importar um único module e deixar o Python fazer os cálculos. Hoje, vamos explorar os Cálculos Cosmológicos: Dimensionar o Universo. O subpackage cosmology do Astropy encapsula a relatividade geral e a métrica de Friedmann-Lemaitre-Robertson-Walker em function calls simples. Em vez de escreveres os teus próprios integradores para mapear o redshift para a distância física, defines um modelo cosmológico e a library trata da geometria subjacente. Uma cosmologia no Astropy é um object Python. Podes construir uma do zero usando a class FlatLambdaCDM. Passas-lhe uma constante de Hubble, como setenta, e uma densidade inicial de matéria, como ponto três. Isto dá-te um universo espacialmente plano impulsionado por energia escura e matéria escura fria. No entanto, raramente precisas de digitar estes parameters tu mesmo. O Astropy inclui realizações built-in standard derivadas de grandes levantamentos. Basta importares o Planck13 ou o WMAP9 do module cosmology, e tens instantaneamente um modelo totalmente configurado e pronto para avaliar. Aqui está a principal observação sobre o state. Os parameters de um object cosmology do Astropy são estritamente imutáveis. Se inicializares um modelo e depois decidires que queres ajustar a densidade da matéria, não podes atualizar esse attribute in place. Fazer isso dá um erro. Em vez disso, chamas o method clone no teu modelo existente, passando o novo valor do parameter como argument. Isto devolve uma instance de cosmology completamente nova com os teus valores atualizados. Pega num cenário concreto usando o modelo built-in do Planck13. Supõe que estás a observar uma galáxia com um redshift de dois. Queres saber o seu lookback time, ou seja, quantos anos a luz demorou a chegar ao teu telescópio. Pegas no teu object Planck13, chamas o seu method lookback time, e passas-lhe o número dois. O method devolve uma quantidade de tempo em giga-anos. Usas exatamente este mesmo pattern para calcular a luminosity distance. Chamas o method luminosity distance com o teu redshift, e o Astropy devolve a distância em megaparsecs, tendo em conta a expansão do universo. Isso cobre os inputs para os outputs, mas e o inverso? Às vezes tens uma medição física e precisas de encontrar o redshift correspondente. Imagina que queres saber o redshift exato em que o universo tinha exatamente dois mil milhões de anos. Não podes simplesmente passar uma idade para os methods standard. Em vez disso, importas uma function chamada z at value. Passas-lhe o method que queres inverter, que é o method age do teu modelo Planck13, e passas-lhe o valor alvo de dois giga-anos. O Astropy corre uma rotina numérica de root-finding nos bastidores e devolve o redshift preciso. A conversão entre redshift e tempo ou distância física é a base da astronomia extragaláctica, e este module dá-te uma source of truth testada para que te possas focar nos dados em vez de fazeres debugging a integrais. Como este é o episódio final da nossa série sobre Astropy, encorajo-te a leres a documentação oficial, a experimentares estas tools hands-on, ou a visitares dev stories dot e u para sugerires tópicos para a nossa próxima série. Obrigado por passares uns minutos comigo. Até à próxima, fica bem.