Astropy: Python for Astronomy

Cześć, tu Alex z DEV STORIES DOT EU. Astropy: Python dla astronomii, odcinek 1 z 15. Prawdopodobnie zdarzyło ci się mnożyć NumPy array przez stałą. Ale jeśli w złożonym równaniu przypadkowo pomieszasz metry z kilometrami, Python cię nie ostrzeże, a twój końcowy array będzie po prostu zawierał złe liczby. Pozwolenie bibliotece na automatyczną obsługę wymiarów fizycznych to dokładnie to, o czym jest ten odcinek. Przyjrzymy się sercu Astropy: Units i Quantities. Astropy obsługuje jednostki fizyczne za pomocą obiektu Quantity. Quantity wiąże liczbę lub array liczb z jednostką fizyczną. Ponieważ Quantity jest bezpośrednią subclassą ndarray z NumPy, nie tracisz na wydajności ani na funkcjonalności arraya. Możesz na nich natywnie używać slice, broadcast i odpalać standardowe funkcje matematyczne z NumPy. Zachowują się jak normalne arraye, które po prostu wiedzą, jaką właściwość fizyczną reprezentują. Aby utworzyć Quantity, importujesz moduł units z Astropy. Następnie po prostu mnożysz swoją liczbę przez konkretny obiekt jednostki. Trzy pomnożone przez units dot parsec tworzy Quantity o wartości trzech parseków. Wielu developerów zakłada, że ta abstrakcja jest wolna, co jest powszechnym błędem. To prawda, że pomnożenie ogromnego NumPy array przez obiekt jednostki tworzy nową kopię tego arraya w pamięci. Aby uniknąć tego overheadu, Astropy nadpisuje operator bitwise left-shift, który wygląda jak dwa znaki mniejszości. Dajesz swój istniejący array po lewej, operator left-shift w środku, a jednostkę Astropy po prawej. To przypina jednostkę do arraya in place, bez kopiowania danych pod spodem. Oto kluczowa sprawa. Biblioteka ewaluuje matematyczne relacje między jednostkami w trakcie obliczeń. Załóżmy, że chcesz obliczyć czas podróży statku kosmicznego. Twój dystans to trzy przecinek zero parseków. Twoja prędkość to sto trzydzieści kilometrów na sekundę. Tworzysz Quantity dla dystansu i dzielisz je przez Quantity dla prędkości. Astropy zwraca nowe Quantity dla czasu. Obsługuje dzielenie wartości i oblicza wynikową jednostkę, zwracając parseko-sekundy na kilometr. Ta wynikowa jednostka jest matematycznie poprawna, ale niezbyt czytelna. Możesz to zmienić używając metody to, dostępnej w każdym Quantity. Wywołujesz metodę to i przekazujesz docelową jednostkę, na przykład units dot year. Astropy weryfikuje, czy wymiary źródłowy i docelowy to jednostki czasu, wykonuje wewnętrzną konwersję i zwraca nowe Quantity wyrażone w latach. Dla szybkiej standaryzacji możesz też użyć properties dot SI lub dot CGS w dowolnym Quantity, aby natychmiast przekonwertować je na jednostki bazowe tych systemów. Kiedy wykonujesz operacje matematyczne, w których jednostki całkowicie się skracają, jak dzielenie metrów przez centymetry, Astropy zwraca dimensionless Quantity. Jednostka nadal istnieje pod maską jako nieskalowany typ dimensionless. Jeśli musisz przekazać ten wynik do zewnętrznej biblioteki, która oczekuje standardowych floatów z Pythona lub zwykłych arrayów z NumPy, wyciągasz surową liczbę za pomocą atrybutu value. Zanim wyciągniesz jakąkolwiek końcową wartość, pamiętaj, że zawsze możesz uprościć nieczytelne, połączone jednostki do ich absolutnych, fundamentalnych wymiarów fizycznych, wywołując metodę decompose. Jeśli chcesz wesprzeć nasz podcast, wyszukaj DevStoriesEU na Patreon – to pomaga nam tworzyć kolejne odcinki. To wszystko na dzisiaj. Dzięki za słuchanie i budujcie dalej!

Cześć, tu Alex z DEV STORIES DOT EU. Astropy: Python dla astronomii, odcinek 2 z 15. Standardowy sześćdziesięcioczterobitowy float nie może reprezentować timestampu obejmującego miliardy lat bez utraty własnej precyzji. Jeśli spróbujesz śledzić odległe zdarzenie astronomiczne z dokładnością do mikrosekundy, standardowej arytmetyce zmiennoprzecinkowej po prostu brakuje bitów. Właśnie przez to ograniczenie sprzętowe potrzebujemy tematu: Skale czasu i precyzja, czyli moduł astropy.time. Aby zachować subnanosekundową dokładność w skali kosmicznej historii, ten moduł całkowicie unika używania pojedynczej liczby do reprezentowania czasu. Zamiast tego opiera się na sprytnej architekturze dwóch floatów. Pod spodem każda wartość czasu jest dzielona na dwa oddzielne sześćdziesięcioczterobitowe floaty. Pierwszy float przechowuje część całkowitą daty juliańskiej, która liczy pełne dni. Drugi float przechowuje część ułamkową dnia. Gdyby Astropy dodało je do siebie w jedną zmienną, precyzja natychmiast by spadła. Dzięki trzymaniu ich osobno, biblioteka może lokalnie wykonywać bardzo precyzyjną arytmetykę czasu, niezależnie od tego, jak głęboko w przeszłości lub przyszłości znajduje się dana data. Kiedy tworzysz obiekt Time, przekazujesz wartość czasu wraz z dwoma kluczowymi argumentami: formatem i skalą. I tu jest kluczowa kwestia. Developerzy nagminnie mylą wizualny format daty z jej fizyczną skalą czasu. To zupełnie odrębne pojęcia. Format decyduje wyłącznie o tym, jak dane są odczytywane lub zapisywane. Popularne formaty to standardowe stringi ISO, numeryczne zmodyfikowane daty juliańskie oraz specjalistyczne reprezentacje, takie jak nagłówki FITS. Format to tylko strukturalne opakowanie dla liczb. Skala czasu definiuje natomiast fizyczny układ odniesienia dla tych liczb. Fizyczne skale czasu uwzględniają obrót Ziemi, sekundy przestępne i efekty relatywistyczne. Przykłady to uniwersalny czas skoordynowany, znany jako UTC, czas ziemski, czyli TT, oraz międzynarodowy czas atomowy, czyli TAI. Zmodyfikowana data juliańska nie jest fizyczną skalą, to tylko format. Możesz bez problemu mieć timestamp sformatowany jako zmodyfikowana data juliańska, ale fizycznie zakotwiczony w skali UTC. Musisz jawnie zdefiniować zarówno format, jak i skalę, kiedy przekazujesz surowe dane do obiektu Time. Wyobraź sobie obliczanie różnicy czasu między dwoma timestampami z telemetrii statku kosmicznego. Otrzymujesz pierwszy timestamp jako string w formacie ISO z wczoraj, a drugi timestamp jako string ISO z dzisiaj. Najpierw inicjalizujesz dwa obiekty Time. Przekazujesz surowy string do obiektu, deklarujesz format jako ISO i ustawiasz skalę na UTC. Robisz to dla obu timestampów. Ponieważ Astropy obsługuje operacje wektorowe, mógłbyś również przekazać ogromną tablicę tych stringów do pojedynczego obiektu Time, ale logika inicjalizacji pod spodem pozostaje taka sama. Aby znaleźć dokładny czas, który upłynął, odejmujesz wcześniejszy obiekt Time od późniejszego. Astropy automatycznie wykonuje wewnętrzną arytmetykę na dwóch floatach, zwracając obiekt TimeDelta, który przechowuje dokładny czas trwania. Następnie musisz zmapować ten drugi timestamp z telemetrii na absolutną, jednolitą fizyczną skalę, usuwając nieprzewidywalne skoki spowodowane sekundami przestępnymi UTC. Bierzesz swój drugi obiekt Time i po prostu żądasz jego odpowiednika w międzynarodowym czasie atomowym. Osiągasz to, wywołując atrybut TAI bezpośrednio na obiekcie. Astropy natychmiast uruchamia przeliczenie wewnętrznych floatów, przesuwając układ odniesienia z UTC na TAI, zachowując jednocześnie pełną nanosekundową precyzję. Prawdziwą mocą modułu astropy.time jest to, że nigdy nie musisz ręcznie zarządzać sekundami przestępnymi ani poprawkami relatywistycznymi; definiujesz swoje formaty i skale z góry, a architektura oparta na dwóch floatach gwarantuje, że obliczenia pozostają dokładne w całym wszechświecie. Chciałbym poświęcić chwilę, aby podziękować ci za słuchanie — to bardzo nam pomaga. Miłego dnia!

Cześć, tu Alex z DEV STORIES DOT EU. Astropy: Python dla astronomii, odcinek 3 z 15. Ręczna konwersja współrzędnych niebieskich z jednego układu odniesienia na inny wiąże się z przerażającą trygonometrią sferyczną. Pojedynczy błąd macierzy może łatwo sprawić, że twój teleskop będzie skierowany na niewłaściwą półkulę. Nawigacja po niebie: klasa SkyCoord ogarnia tę matematykę za ciebie, zamieniając złożone transformacje sferyczne w proste odczytanie atrybutu. W Astropy, SkyCoord jest podstawowym obiektem high-level do reprezentowania położeń ciał niebieskich. Działa jak inteligentny wrapper na low-levelowe układy współrzędnych. Kiedy obserwujesz obiekt, musisz zapisać jego pozycję. Zazwyczaj używasz rektascensji i deklinacji. Aby zbudować obiekt SkyCoord, przekazujesz te dwie wartości, określasz jednostki, takie jak stopnie czy godziny, i ustawiasz układ odniesienia. Jeśli nie podasz frame'a, domyślnie użyje Międzynarodowego Układu Odniesienia Niebieskiego, czyli ICRS. Możesz łatwo utworzyć pojedynczy punkt na niebie, ale to prowadzi do częstej pułapki. Użytkownicy często parsują plik z danymi zawierający tysiące gwiazd, tworzą nowy obiekt SkyCoord dla każdej z nich i przechowują je w standardowej liście w Pythonie. Kiedy muszą wykonać obliczenia, iterują po tej liście w pętli. Jest to potwornie nieefektywne i całkowicie omija korzyści wydajnościowe tej biblioteki. SkyCoord jest zbudowany tak, aby natywnie obsługiwać arraye. Zamiast tworzyć tysiące pojedynczych obiektów, przekazujesz array Numpy z wartościami rektascensji i odpowiadający mu array z wartościami deklinacji do pojedynczej inicjalizacji SkyCoord. W zamian dostajesz dokładnie jeden obiekt SkyCoord, który zawiera cały twój dataset. Wyobraź sobie scenariusz, w którym robisz cross-match nowo odkrytego zestawu stu transjentów radiowych zarejestrowanych w ICRS z istniejącym katalogiem optycznym. Ładując wszystkie sto transjentów do jednego obiektu SkyCoord opartego na arrayach, biblioteka przekazuje dane w dół do mocno zoptymalizowanych procedur w C i Numpy. Operacje, które w pythonowej pętli zajęłyby minuty, wykonują się w milisekundach. Ta struktura oparta na arrayach staje się szczególnie potężna, kiedy musisz przetransformować swoje dane. Katalogi astronomiczne nie zawsze są zgodne co do układu współrzędnych. Twoje transjenty radiowe mogą być w ICRS, ale być może musisz przeanalizować ich rozkład względem płaszczyzny Drogi Mlecznej. Do tego potrzebujesz układu współrzędnych galaktycznych. I tu pojawia się kluczowa sprawa. Nie musisz szukać macierzy rotacji ani pisać funkcji konwertujących. Astropy zawiera potężny, wbudowany graf transformacji, który wie, jak przejść z dowolnego obsługiwanego frame'a do dowolnego innego obsługiwanego frame'a. Ponieważ SkyCoord jest wrapperem na ten graf, konwersja całego twojego arraya stu transjentów zajmuje dokładnie jeden krok. Bierzesz swój istniejący obiekt SkyCoord i wywołujesz na nim metodę transform_to, podając nazwę docelowego frame'a. Co więcej, dla popularnych frame'ów, Astropy zapewnia bezpośredni dostęp przez atrybut. Jeśli masz obiekt SkyCoord w ICRS, po prostu odpytujesz o atrybut galactic. Biblioteka automatycznie oblicza transformację i zwraca zupełnie nowy obiekt SkyCoord. Ten nowy obiekt zawiera dokładnie te same fizyczne lokalizacje w przestrzeni, ale reprezentowane jako galaktyczna długość i szerokość. Prawdziwa siła tej klasy polega na tym, że całkowicie oddziela dane reprezentujące pozycję na niebie od leżącej pod spodem geometrii sferycznej, wymaganej do przenoszenia ich po wszechświecie astronomicznych układów odniesienia. To wszystko w tym odcinku. Dzięki za wysłuchanie i twórz dalej!

Cześć, tu Alex z DEV STORIES DOT EU. Astropy: Python dla astronomii, odcinek 4 z 15. Możesz dokładnie wiedzieć, gdzie znajduje się gwiazda dziś wieczorem, ale bez uwzględnienia proper motion i korekcji prędkości Ziemi, za dekadę twój teleskop będzie skierowany w pustą przestrzeń. W tym odcinku wychodzimy poza RA i Dec: śledzenie 3D i prędkości. Domyślnie współrzędne mapują płaską pozycję na niebie za pomocą kątów. Aby zamodelować układ fizyczny, taki jak układ podwójny gwiazd, potrzebujesz rzeczywistej fizycznej odległości między jego składnikami. Wiele osób próbuje obliczyć separację 3D, używając tylko rektascensji i deklinacji. To tak nie działa. Aby użyć metody 3D separation, musisz podać parametr distance podczas tworzenia obiektu coordinate. Przekazujesz wartość distance z fizyczną jednostką, taką jak parseki, razem ze współrzędnymi kątowymi. Kiedy oba obiekty zawierają te dane o odległości, wywołujesz metodę 3D separation na pierwszym obiekcie coordinate, przekazując drugi coordinate jako argument. Astropy zwraca bezpośrednią fizyczną linię między nimi w przestrzeni trójwymiarowej, automatycznie ogarniając trygonometrię w tle. Ale te obiekty nie są statyczne. Aby modelować ich ruch w czasie, podpinasz dane o prędkości bezpośrednio do obiektu coordinate podczas jego tworzenia. Robisz to, przekazując parametry proper motion. Dokładniej mówiąc, podajesz proper motion dla rektascensji i proper motion dla deklinacji. Przyjmują one jednostki kątowe na jednostkę czasu, takie jak milisekundy kątowe na rok. Podajesz również parametr radial velocity, który przyjmuje fizyczną prędkość, na przykład kilometry na sekundę. Kiedy połączysz to wszystko razem, obiekt coordinate staje się pełnym wektorem w przestrzeni fazowej. Przechowuje on aktualną lokalizację obiektu i dokładny wektor wskazujący, dokąd zmierza. I tu pojawia się kluczowa kwestia. Twój teleskop również porusza się w przestrzeni. Ziemia obraca się wokół własnej osi i krąży wokół Słońca. Jeśli mierzysz prędkość radialną gwiazdy z powierzchni Ziemi, twój surowy pomiar jest zaburzony przez prędkość samej Ziemi w tym konkretnym momencie. Aby podzielić się swoimi danymi z innymi astronomami, musisz odfiltrować ruch Ziemi. Przesuwasz swój punkt odniesienia do stabilnego układu, zazwyczaj do środka masy Układu Słonecznego. Nazywa się to barycentryczną korekcją prędkości radialnej. Aby obliczyć tę korekcję w Astropy, musisz zdefiniować, gdzie znajduje się obserwator, używając obiektu EarthLocation. Tworzysz go, przekazując dokładną długość i szerokość geograficzną oraz wysokość nad poziomem morza twojego instrumentu. Alternatywnie, możesz wyciągnąć gotową lokalizację bezpośrednio z wbudowanego w Astropy rejestru site registry, odpytując go o znaną nazwę, taką jak Obserwatorium Kecka. Następnie potrzebujesz dokładnego czasu, w którym miała miejsce obserwacja. Mając gotową lokalizację i czas, wywołujesz metodę radial velocity correction bezpośrednio na obiekcie coordinate twojego celu. Przekazujesz do niej czas obserwacji i twój obiekt EarthLocation. Astropy oblicza wektor prędkości Obserwatorium Kecka w tej konkretnej milisekundzie względem celu i zwraca offset prędkości. Dodajesz tę wartość korekcji do twojej surowej, zmierzonej prędkości radialnej. W rezultacie otrzymujesz czysty, ustandaryzowany pomiar odniesiony do barycentrum Układu Słonecznego. Najważniejszy wniosek z tego jest taki, że coordinate to nie tylko stały punkt na mapie; to pełny model kinematyczny, który przechowuje pozycję celu, jego trajektorię i geometrię potrzebną do skorygowania twojego własnego ruchu. Dzięki za wysłuchanie. Trzymajcie się!

Cześć, tu Alex z DEV STORIES DOT EU. Astropy: Python dla astronomii, odcinek 5 z 15. Pandas jest niesamowity do płaskich danych, ale co się stanie, gdy pojedyncza kolumna w twoim datasiecie będzie musiała pomieścić szereg czasowy, jednostkę fizyczną i współrzędną przestrzenną? Standardowe dataframe'y zawodzą. Aby to rozwiązać, potrzebujesz Tabular Data Mastery: klasa QTable. Jeśli pracujesz w Pythonie, znasz już Pandasa. Pandas zakłada, że twoje dane są płaskie, preferując jedną prostą wartość na komórkę. W astronomii dane rzadko są proste. Pojedyncza obserwacja może wymagać ścisłych jednostek, macierzy wartości lub złożonej współrzędnej niebieskiej. Astropy dostarcza customową tabelaryczną strukturę danych, zaprojektowaną specjalnie dla takich realiów. Zauważysz, że Astropy ma zarówno standardową klasę Table, jak i klasę QTable. Ludzie często je mylą. Standardowa klasa Table śledzi informacje o jednostkach jako metadane w tle, ale zwraca zwykłe arraye NumPy, gdy wyciągasz kolumnę. QTable wymusza ścisłą świadomość jednostek. Kiedy pobierasz kolumnę z QTable, masz gwarancję, że dostaniesz z powrotem natywny obiekt Astropy Quantity. Jednostka fizyczna jest na stałe przypięta do liczb. Przejdźmy przez budowanie QTable. Zaczynasz od zaimportowania QTable z modułu astropy dot table. Możesz ją skonstruować używając dictionary, gdzie klucze to nazwy twoich kolumn, a wartości to twoje arraye z danymi. Załóżmy, że tworzysz prosty katalog galaktyk. Twoja pierwsza kolumna to zwykły tekst. Przypisujesz listę stringów reprezentujących nazwy galaktyk. Teraz musisz zapisać, gdzie te galaktyki się znajdują. Nie chcesz oddzielnych, rozłącznych kolumn dla rektascensji i deklinacji. Zamiast tego tworzysz obiekt Astropy SkyCoord, zawierający pozycje wszystkich twoich galaktyk. Przekazujesz ten pojedynczy obiekt SkyCoord bezpośrednio do swojej tabeli jako drugą kolumnę. To jest kolumna typu mixin. Mixiny pozwalają złożonym typom Astropy, takim jak obiekty SkyCoord lub Time, działać dokładnie tak samo jak standardowe arraye z danymi wewnątrz tabeli. Możesz slice'ować, sortować i filtrować wiersze tabeli, a obiekt mixin automatycznie utrzymuje swoje wewnętrzne dane w idealnej synchronizacji. Następnie musisz przechować pomiary strumienia w trzech różnych pasmach długości fali dla każdej galaktyki. W typowym dataframe'ie byłbyś zmuszony do utworzenia trzech oddzielnych kolumn. W QTable używasz kolumny wielowymiarowej. Definiujesz pojedynczy array o kształcie N wierszy i trzech kolumn, dołączasz fizyczną jednostkę strumienia do całości i przypisujesz to jako trzecią kolumnę tabeli. I tu robi się ciekawie. QTable natywnie akceptuje wielowymiarowy array. Pojedynczy wiersz w tej kolumnie przechowuje teraz w pełni zawarty array trzech pomiarów świadomych jednostek. Kiedy printujesz tę tabelę, Astropy formatuje ją w przejrzysty sposób. Wyrównuje zagnieżdżone arraye i wyświetla jednostki bezpośrednio pod nagłówkami kolumn. Twoje metadane i twoje pomiary są ze sobą spięte. QTable to nie tylko arkusz kalkulacyjny; to wyspecjalizowany kontener zbudowany tak, aby respektować fizykę i geometrię twoich danych. Dzięki, że wpadłeś. Mam nadzieję, że dowiedziałeś się czegoś nowego.

Cześć, tu Alex z DEV STORIES DOT EU. Astropy: Python dla astronomii, odcinek 6 z 15. Przeszukiwanie ogromnego katalogu w poszukiwaniu konkretnego źródła zazwyczaj oznacza wykonanie pełnego skanu liniowego, który pożera czas przetwarzania. Ale jeśli odpowiednio ustrukturyzujesz swoje dane, możesz skrócić czas tych lookupów z minut do milisekund. Właśnie tym zajmiemy się dzisiaj: Zaawansowane operacje na tabelach: Maskowanie i joiny. Tabele w Astropy to nie tylko zwykłe arraye. Działają jak relacyjna baza danych in-memory, która natywnie rozumie jednostki fizyczne. Załóżmy, że masz katalog fotometryczny i spektroskopowy, i musisz je połączyć na podstawie wspólnego source ID. Przed ich zmergowaniem musisz obsłużyć brakujące dane. W twoim katalogu fotometrycznym prawdopodobnie brakuje wartości magnitudo, ponieważ obserwacja się nie powiodła albo sensor zgubił klatkę. Możesz spróbować odfiltrować te brakujące wartości za pomocą standardowych numpy boolean arrays. Nie rób tego. Standardowe maski z numpy zaaplikowane bezpośrednio na tabelę unit-aware po cichu usuną twoje jednostki fizyczne i zepsują obiekty mixin. Zamiast tego Astropy radzi sobie z tym za pomocą MaskedColumn. Kiedy pracujesz wewnątrz QTable, czyli klasie tabeli unit-aware, Astropy automatycznie używa operacji MaskedColumn pod spodem dla brakujących danych. To gwarantuje, że twoja kolumna magnitudo zachowa swoje jednostki fizyczne w nienaruszonym stanie, jednocześnie bezpiecznie oznaczając brakujące wpisy, aby nie zepsuły twoich obliczeń downstream. Kiedy twój czysto zamaskowany katalog fotometryczny jest gotowy, czas połączyć go z danymi spektroskopowymi. Astropy udostępnia funkcję join, która działa bardzo podobnie jak w relacyjnej bazie danych. Przekazujesz do funkcji swoją lewą tabelę, prawą tabelę i określasz nazwę wspólnej kolumny jako klucz, którym w tym przypadku jest twój source ID. Jeśli określisz inner join, funkcja ewaluuje oba zbiory danych i zwraca nową tabelę zawierającą tylko te wiersze, w których source ID istnieje w obu katalogach. I tu jest kluczowa sprawa. Ponieważ używasz obiektów QTable, operacja join automatycznie uzgadnia i zachowuje jednostki z obu stron. Twoja zmergowana tabela będzie zawierać precyzyjne parametry fizyczne z danych spektroskopowych obok odpowiednio zamaskowanych wartości magnitudo z danych fotometrycznych, idealnie do siebie dopasowanych. Masz teraz zmergowany katalog, a twoja analiza wymaga wyciągnięcia dokładnych parametrów dla jednego konkretnego source ID. Bez żadnej interwencji, znalezienie wiersza w ogromnej tabeli wymaga sekwencyjnego sprawdzania każdego wpisu po kolei. Astropy rozwiązuje ten bottleneck wydajnościowy za pomocą indeksowania tabel. Możesz poinstruować tabelę, aby utworzyła indeks na twojej kolumnie source ID. Pod spodem Astropy buduje strukturę danych B-tree, mapując twoje source ID bezpośrednio na ich fizyczne lokalizacje wierszy w pamięci. Kiedy indeks jest już zbudowany, pobierasz swoje dane używając właściwości location tabeli, przekazując swój target ID. Silnik przechodzi przez B-tree, całkowicie pomija pełny skan i pobiera twój wiersz w czasie logarytmicznym. Możesz nawet indeksować wiele kolumn jednocześnie, aby obsługiwać złożone lookupy, takie jak znalezienie wiersza zarówno po source ID, jak i dacie obserwacji. Zbudowanie indeksu zajmuje na początku ułamek czasu obliczeniowego, ale opłaca się natychmiast, gdy musisz odpalać powtarzające się lookupy na ciężkich datasetach. Prawdziwa moc tabel w Astropy to nie tylko przechowywanie danych, ale utrzymywanie fizycznej integralności twoich jednostek podczas złożonych relacyjnych joinów i bardzo szybkich zapytań do B-tree. To wszystko w tym odcinku. Dzięki za wysłuchanie i buduj dalej!

Cześć, tu Alex z DEV STORIES DOT EU. Astropy: Python dla astronomii, odcinek 7 z 15. Masz stary, nieuporządkowany plik tekstowy ze współrzędnymi gwiazd i musisz go przekonwertować na nowoczesny, skompresowany standard binarny. W większości bibliotek oznacza to napisanie własnego parsera, mapowanie typów danych i walkę z binary serializers. W Astropy możesz to osiągnąć w dokładnie dwóch linijkach kodu. To zasługa Unified I/O Interface. Unified I/O Interface to polimorficzna warstwa obsługi danych. Zamiast zmuszać cię do importowania konkretnego modułu dla każdego typu pliku, Astropy udostępnia generyczne metody read i write bezpośrednio na swoich głównych strukturach danych. Niezależnie od tego, czy masz do czynienia ze standardowym Table, QTable z jednostkami fizycznymi, czy wielowymiarowym arrayem NDData, model interakcji pozostaje identyczny dla zupełnie różnych standardów plików. Istnieje powszechne błędne przekonanie dotyczące ekstrakcji danych. Gdy developerzy muszą odczytać plik FITS, często od razu sięgają po niskopoziomowy moduł astropy dot io dot fits. Ten moduł służy stricte do manipulacji surowymi plikami, jak edycja pojedynczych kart nagłówka czy inspekcja niesformatowanych strumieni bajtów. Jeśli chcesz po prostu wyciągnąć dane tabelaryczne z pliku FITS, nie powinieneś go używać. Zamiast tego używasz metody Table dot read. Omija ona ręczną ekstrakcję nagłówka i automatycznie obsługuje mapowanie danych pod spodem. Kiedy wywołujesz metodę read i przekazujesz ścieżkę do pliku lub otwarty obiekt pliku, Astropy polega na solidnym silniku wnioskowania formatu. Najpierw sprawdza rozszerzenie pliku. Jeśli podasz string kończący się na dot h5 lub dot parquet, kieruje request do odpowiedniego, dedykowanego parsera. Jeśli rozszerzenie jest niejednoznaczne, brakuje go lub jest to po prostu ogólne rozszerzenie tekstowe, silnik schodzi poziom niżej i bada zawartość pliku. Odczytuje pierwsze kilka bajtów danych, szukając znanych sygnatur lub magic numbers, aby niezawodnie zidentyfikować standard. Jeśli automatyczne wnioskowanie całkowicie zawiedzie, omijasz je, przekazując string z argumentem format, jak ascii dot csv, aby wymusić właściwy parser. Oto jak wygląda to w naszym początkowym scenariuszu. Masz tę starą, tekstową tabelę ASCII ze współrzędnymi gwiazd. Wywołujesz QTable dot read i przekazujesz ścieżkę do swojego pliku tekstowego. Astropy wykrywa format ASCII, parsuje kolumny i zwraca w pełni wypełniony obiekt QTable w pamięci. Następnie chcesz zapisać to jako skompresowaną tabelę binarną FITS. Bierzesz ten sam obiekt QTable w pamięci i wywołujesz jego metodę write. Podajesz nową nazwę pliku kończącą się na dot fits i przekazujesz dodatkowy parametr, aby włączyć kompresję. Musisz również przekazać flagę overwrite ustawioną na true, ponieważ metoda write domyślnie bezpiecznie chroni istniejące pliki. Tutaj zaczyna się robić ciekawie. Astropy pod spodem dynamicznie przełącza kontekst z parsowania plain text na złożoną binarną serializację. Protokoły plików pod spodem są zupełnie inne, ale interfejs, którego używasz, pozostaje niezmieniony. Ponieważ interfejs jest podpięty do struktury danych, a nie do formatu pliku, twoje pipeline'y przetwarzania danych stają się odseparowane od nośników danych. Najważniejszy wniosek z tego jest taki, że zmiana sposobu, w jaki twoja aplikacja przechowuje i udostępnia dane, wymaga zmiany rozszerzenia pliku w pojedynczym stringu, zamiast przepisywania całego pipeline'u do pobierania danych. To wszystko na dziś. Dzięki za wysłuchanie — idź zbuduj coś fajnego.

Cześć, tu Alex z DEV STORIES DOT EU. Astropy: Python dla astronomii, odcinek 8 z 15. Standard plików FITS powstał w latach osiemdziesiątych dla systemów Fortran. Przechowuje on metadane w sztywnych, osiemdziesięciobajtowych blokach, wzorowanych bezpośrednio na fizycznych kartach perforowanych. Praca ze strukturami kart perforowanych we współczesnym kodzie rzadko bywa przyjemna. Astropy ukrywa tę złożoność, tłumacząc te bloki na natywne struktury, i właśnie dlatego ten odcinek skupia się na demistyfikacji nagłówków FITS oraz HDU. Pomyśl o pliku FITS jak o kontenerze. Wewnątrz tego kontenera znajdują się Header Data Units, powszechnie znane jako HDU. Każdy plik FITS musi zawierać co najmniej jedno z nich, nazywane Primary HDU. Często to Primary HDU zawiera wyłącznie metadane, podczas gdy właściwe obrazy lub tabele binarne znajdują się bezpośrednio za nim jako Extension HDUs. Kiedy otwierasz plik FITS za pomocą Astropy, biblioteka parsuje ten kontener i zwraca ci obiekt HDUList. Nawigujesz po tym obiekcie używając standardowej notacji nawiasowej, żeby wybierać poszczególne HDU. Oto kluczowa rzecz, jeśli chodzi o indeksowanie. Oficjalny standard FITS sztywno używa indeksowania od jedynki ze względu na swoje korzenie w Fortranie. Jednak ponieważ Astropy to biblioteka Pythona, wymusza indeksowanie od zera. Primary HDU zawsze znajduje się pod indeksem zero, a pierwsze rozszerzenie pod indeksem jeden. To prosty szczegół, ale zapominanie o nim powoduje ciągłe błędy off-by-one. Każdy obiekt HDU zawiera atrybut header. To właśnie tam żyją te stare, osiemdziesięciobajtowe bloki. W terminologii FITS każda linijka metadanych nazywana jest kartą. Kompletna karta zawiera keyword, wartość, a czasami opisowy komentarz. Astropy przetwarza te karty i wystawia ci header jako obiekt, który zachowuje się dokładnie tak samo jak standardowy słownik w Pythonie. Jeśli potrzebujesz czasu ekspozycji, po prostu przekazujesz keyword EXPTIME do headera. Modyfikowanie wartości działa w ten sam sposób. Przypisujesz nową wartość do keyworda za pomocą znaku równości. Jeśli musisz też zaktualizować komentarz na tej konkretnej karcie, przypisujesz tuplę zawierającą zarówno nową wartość, jak i nowy string z komentarzem. Astropy automatycznie przepakowuje te dane z powrotem do wymaganego, osiemdziesięciobajtowego standardu pod spodem. To tłumaczenie działa bez zarzutu, dopóki nie natrafisz na dane legacy. Starsze pliki FITS często łamią ten rygorystyczny standard. Mogą zawierać keywordy, które są zbyt długie lub mają niedozwolone znaki. Ponieważ Astropy domyślnie rygorystycznie waliduje headery, próba otwarcia niezgodnego pliku często natychmiast rzuci wyjątkiem. Zamiast porzucać plik, możesz sobie z tym poradzić używając metody verify. Powiedzmy, że otwierasz stare zdjęcie z teleskopu i trafiasz na błąd walidacji dotyczący formatowania. Przechwytujesz obiekt pliku i wywołujesz jego metodę verify, przekazując string fix jako argument. Astropy przeskanuje wszystkie karty headera, automatycznie naprawi problemy z formatowaniem tam, gdzie to możliwe, i wyciszy błędy dla uszkodzonych pól, które naprawi. Kiedy header jest już ustabilizowany, możesz bezpiecznie zaktualizować zepsutą kartę OBSERVER poprawnym stringiem, a następnie zapisać swoją oczyszczoną HDUList z powrotem na dysk. Zawsze traktuj aktualizacje metadanych FITS jako proste operacje na słowniku, ale miej w pogotowiu metodę verify na moment, gdy dane legacy złamią zasady. Jeśli chcesz pomóc w utrzymaniu podcastu, wyszukaj DevStoriesEU na Patreonie. Dzięki za wysłuchanie. Do usłyszenia następnym razem!

Cześć, tu Alex z DEV STORIES DOT EU. Astropy: Python dla astronomii, odcinek dziewiąty z piętnastu. Nie potrzebujesz superkomputera, żeby przeanalizować stugigabajtowy obraz. Potrzebujesz tylko sposobu, żeby oszukać system operacyjny i zmusić go do odczytania dokładnie tych pikseli, które cię interesują. Obsługa ogromnych plików FITS i cloud storage to dokładnie ten mechanizm, którego użyjesz, żeby to osiągnąć. Kiedy pracujesz z ogromnymi astronomicznymi arrayami, próba załadowania całego pliku do pamięci natychmiast zcrashuje twój proces. Astropy unika tego, korzystając z funkcji zwanej memory mapping. Kiedy otwierasz plik FITS, możesz przekazać argument o nazwie memmap ustawiony na True. Memory map nie wczytuje danych obrazu do twojego fizycznego RAM-u. Zamiast tego mapuje plik na dysku twardym bezpośrednio do przestrzeni adresowej pamięci wirtualnej twojego komputera. Kiedy odwołujesz się do konkretnego slice'a arraya, twój system operacyjny pobiera z dysku tylko ten konkretny blok danych. Masz wygodę udawania, że cały plik jest załadowany, ale ponosisz koszt pamięci fizycznej tylko za te piksele, które aktywnie przetwarzasz. Takie zachowanie wprowadza bardzo częstą pułapkę. Możesz otworzyć plik FITS, przypisać array z obrazem do zmiennej, a następnie wywołać close na obiekcie pliku. Oczekujesz, że file handle zostanie zwolniony, a zasoby uwolnione. Tak się nie dzieje. Ponieważ memory maps opierają się na tym, że system operacyjny linkuje plik ze zmienną, plik pozostaje otwarty i zablokowany tak długo, jak długo w twojej sesji Pythona istnieje jakakolwiek referencja do tego arraya. Żeby faktycznie zwolnić zasoby i całkowicie zamknąć file handle, musisz jawnie usunąć swoją zmienną z danymi, używając standardowego polecenia delete w Pythonie. To załatwia sprawę plików lokalnych, ale współczesne datasety astronomiczne często znajdują się na zdalnych serwerach. Pobieranie setek gigabajtów tylko po to, żeby sprawdzić mały obszar, to marnowanie bandwidthu i czasu. Astropy obsługuje zdalne dane, integrując się z biblioteką file system spec. Kiedy otwierasz plik, przekazujesz argument o nazwie use fsspec ustawiony na True. To mówi bibliotece, żeby traktowała lokalizacje w cloud storage dokładnie tak samo jak dyski lokalne. Weźmy na przykład dwustu megabajtowy obraz z Kosmicznego Teleskopu Hubble'a, hostowany w publicznym buckecie Amazon S3. Potrzebujesz tylko małego wycinka dziesięć na dwadzieścia pikseli wokół konkretnej gwiazdy. Najpierw wywołujesz fits open, przekazując uniform resource identifier dla S3 zamiast lokalnej ścieżki do pliku, razem z use fsspec ustawionym na True. Astropy łączy się z bucketem i pobiera tylko bloki nagłówka FITS. To pozwala mu zrozumieć strukturę pliku bez dotykania właściwych danych obrazu. Następnie przechodzisz do odpowiedniego rozszerzenia obrazu i robisz slice na arrayu z danymi używając standardowego indeksowania, pobierając tylko swój blok dziesięć na dwadzieścia. I tu zaczyna się robić ciekawie. Astropy tłumaczy ten slice arraya na konkretne requesty HTTP typu byte range. Twój komputer łączy się z Amazon S3, prosi tylko o fizyczne bajty odpowiadające tym dwustu pikselom i pobiera dokładnie ten mały chunk. Dostajesz swój wycinek natychmiast, podczas gdy pozostałe sto dziewięćdziesiąt dziewięć megabajtów pliku zostaje na serwerze nietknięte. Połączenie lokalnego memory mapping ze zdalnym streamingiem byte range oznacza, że twoje skrypty analityczne są ograniczone tylko przez dane, które aktywnie przetwarzasz, a nigdy przez całkowity rozmiar samego pliku. Chciałbym poświęcić chwilę, żeby podziękować ci za słuchanie — to bardzo nam pomaga. Trzymaj się!

Cześć, tu Alex z DEV STORIES DOT EU. Astropy: Python dla astronomii, odcinek 10 z 15. Jeśli zrobisz slice na standardowym numerycznym arrayu, dostaniesz z powrotem tylko surowe piksele. Ale dane z teleskopu to nigdy nie jest po prostu macierz liczb. Kiedy kadrujesz obraz, żeby przyjrzeć się pojedynczej gwieździe, twoje granice błędów, maski martwych pikseli i współrzędne nieba muszą pozostać idealnie wyrównane, inaczej cała twoja analiza się posypie. Właśnie dlatego używamy Gridded Data: klas NDData i CCDData. W swojej istocie, Astropy dostarcza klasę bazową NDData jako standardowy kontener na astronomiczne Gridded Data. O ile NDData ogarnia ogólną strukturę, to do rzeczywistych obrazów optycznych lub w podczerwieni, zazwyczaj użyjesz jej wyspecjalizowanej podklasy o nazwie CCDData. Ten kontener istnieje po to, aby powiązać twoje surowe wartości pikseli bezpośrednio z ich właściwościami fizycznymi. Przejdźmy przez inicjalizację obiektu CCDData dla surowej ekspozycji z teleskopu. Nie przekazujesz tak po prostu dwuwymiarowej siatki liczb. Przekazujesz surową siatkę danych i musisz przypisać fizyczną jednostkę, taką jak elektrony czy jednostki analogowo-cyfrowe. Następnie dołączasz maskę boolean. Jeśli podczas ekspozycji wysokoenergetyczny promień kosmiczny uderzy w twój detektor, flagujesz te konkretne zrujnowane piksele jako true w osobnym arrayu maski i przekazujesz to bezpośrednio do obiektu CCDData. Potem wchodzi śledzenie błędów. Dołączasz array niepewności. Dla naszego surowego obrazu możesz obliczyć szum Poissona i dołączyć go używając klasy Standard Deviation Uncertainty lub klasy Variance Uncertainty. Teraz twoje wartości jasności, twoje jednostki, flagi uszkodzonych pikseli i limity szumu statystycznego są spięte razem jako jeden zunifikowany obiekt. To prowadzi do częstego nieporozumienia. Kiedy masz już ten w pełni załadowany obiekt, nie próbuj używać standardowych operatorów matematycznych, takich jak zwykły znak plus czy minus, do przetwarzania obrazu. Jeśli spróbujesz normalnej arytmetyki na arrayach, żeby odjąć ciemną klatkę tła, zgubisz swoje niepewności. Zamiast tego musisz użyć wbudowanych metod arytmetycznych dostarczanych przez klasę, takich jak funkcje add, subtract, multiply i divide. I tu robi się ciekawie. Kiedy wywołasz metodę subtract, Astropy nie tylko odejmuje wartości pikseli. Automatycznie propaguje twoje niepewności wariancji przez całą operację, używając standardowych reguł statystycznych, co daje matematycznie poprawny profil szumu w wynikowym obrazie. Później w swoim workflow możesz zorientować się, że twój pełny obraz z teleskopu jest zbyt duży i chcesz przeanalizować tylko jedną galaktykę znajdującą się w prawym górnym rogu. Osiągniesz to używając narzędzia o nazwie Cutout2D. Podajesz swój główny obiekt CCDData, dokładne współrzędne środka twojej docelowej galaktyki oraz rozmiar bounding boxa, którego chcesz wyekstrahować. Ponieważ spakowałeś wszystko w kontenerze CCDData, Cutout2D automatycznie ogarnia tę złożoną synchronizację. Zwraca nowy, mniejszy obiekt. Robi slice na pikselach obrazu, ale też automatycznie przycina maskę promieniowania kosmicznego i array niepewności wariancji do dokładnie tych samych wymiarów. Co kluczowe, transformuje też bazowy world coordinate system. Współrzędne piksela zero-zero w twoim nowym cutoucie poprawnie mapują się na dokładnie tę samą rektascensję i deklinację, co w głównym obrazie. Traktując dane pikseli, fizyczne marginesy błędu i współrzędne przestrzenne jako jedną niepodzielną całość, te klasy zapobiegają cichemu uszkodzeniu danych, gdy twój obraz przechodzi przez złożone pipeline'y analityczne. To wszystko w tym odcinku. Dzięki za wysłuchanie i budujcie dalej!

Cześć, tu Alex z DEV STORIES DOT EU. Astropy: Python dla astronomii, odcinek 11 z 15. Każdy piksel na detektorze teleskopu jest płaskim, dyskretnym kwadratem, ale niebo to ciągła, matematycznie złożona, zakrzywiona sfera. Odwzorowanie punktu z tego płaskiego detektora z powrotem na jego rzeczywiste położenie we wszechświecie to skomplikowany problem geometryczny. World Coordinate Systems, czyli WCS, to mechanizm, który dekoduje tę geometrię. WCS działa jak ostateczny pomost między sprzętem a fizyką. Zapewnia matematyczną transformację wymaganą do przekształcenia współrzędnych piksela we współrzędne globalne, takie jak rektascensja i deklinacja. W danych astronomicznych te reguły transformacji są zazwyczaj przechowywane jako standardowe metadane w nagłówku pliku FITS. Nagłówek zawiera określone słowa kluczowe definiujące piksel referencyjny, fizyczne współrzędne tego piksela oraz macierz obrotu lub skalowania używaną przez teleskop. Astropy odczytuje te słowa kluczowe i buduje aktywny obiekt transformacji, który modeluje całą płaszczyznę ogniskową. Zanim przejdziemy do matematyki, musimy wyjaśnić stałe źródło nieporozumień związanych z indeksowaniem. Standard FITS definiuje współrzędne pikseli jako indeksowane od jedynki, co oznacza, że pierwszy piksel na detektorze to piksel numer jeden. Python, a co za tym idzie NumPy, jest indeksowany od zera. Astropy rozwiązuje ten dualizm za pomocą dwóch różnych warstw. Starsze, niskopoziomowe API nie jest zunifikowanym systemem indeksowania; wymaga od ciebie jawnego przekazania argumentu origin o wartości zero lub jeden za każdym razem, gdy transformujesz współrzędną. Jednak nowoczesny, wysokopoziomowy Shared Python Interface działa w całości w oparciu o konwencję Pythona indeksowania od zera. Oczekuje od ciebie pikseli indeksowanych od zera i wewnętrznie automatycznie obsługuje przesunięcie względem standardu FITS. Oto kluczowa sprawa. Wysokopoziomowe API sprawia, że konwersja współrzędnych jest niezwykle zwięzła. Załóżmy, że zlokalizowałeś jasną gwiazdę w swojej tablicy obrazu na pikselu x równym 30 i y równym 40, i musisz znaleźć jej rzeczywiste położenie w przestrzeni. Najpierw odczytujesz nagłówek pliku FITS za pomocą narzędzi input-output Astropy. Następnie inicjalizujesz obiekt WCS, przekazując ten nagłówek bezpośrednio do klasy WCS. Na koniec wywołujesz metodę o nazwie pixel to world na tym obiekcie WCS, przekazując swoje wartości pikseli x i y wynoszące 30 i 40. Metoda wykonuje obliczenia projekcji i zwraca standardowy obiekt SkyCoord z Astropy. Ten obiekt zawiera fizyczne współrzędne i jest w pełni świadomy swojego układu odniesienia, takiego jak ICRS. Piękno tego współdzielonego interfejsu polega na tym, że chroni cię przed surowymi liczbami. Zamiast zwracać generyczną tablicę floatów reprezentujących abstrakcyjne stopnie, daje ci bogate obiekty, które rozumieją swoje własne fizyczne jednostki i układy współrzędnych. Możesz wziąć ten SkyCoord i natychmiast użyć go do cross-referencji z katalogiem gwiazd. System działa dokładnie tak samo w drugą stronę. Jeśli masz współrzędne znanej galaktyki i chcesz dokładnie określić, które piksele zajmuje ona na matrycy twojej kamery, wywołujesz metodę world to pixel na swoim obiekcie WCS. Przekazujesz swój SkyCoord, a ona zwraca dokładne pozycje pikseli x i y jako floaty. Wysokopoziomowe API WCS izoluje logikę twojej aplikacji od leżącej pod spodem matematyki projekcji, co oznacza, że twój kod konwersji pixel-to-sky pozostaje identyczny, niezależnie od tego, czy pracujesz z płaską mapą radiową, czy z mocno zniekształconą mozaiką optyczną o szerokim polu widzenia. To wszystko w tym odcinku. Dzięki za wysłuchanie i twórz dalej!

Cześć, tu Alex z DEV STORIES DOT EU. Astropy: Python dla astronomii, odcinek 12 z 15. W wielu bibliotekach naukowych równanie matematyczne, które chcesz obliczyć, jest tightly coupled z algorytmem używanym do jego optymalizacji. Jeśli chcesz zmienić sposób działania optymalizacji, często musisz przepisać to, jak zdefiniowałeś swoją matematykę. Astropy całkowicie eliminuje ten problem dzięki swojemu podejściu do modeli analitycznych i fittingu. Główną filozofią projektową subpackage'u modeling w Astropy jest ścisłe separation of concerns. Matematyczna definicja twojego równania to jeden obiekt. Silnik algorytmiczny, który fituje to równanie do twoich danych, to zupełnie osobny obiekt. Oznacza to, że możesz zdefiniować swoją matematykę raz, a potem przetestować ją z kilkoma różnymi algorytmami fittingu, po prostu przekazując model do innego fittera. Astropy dostarcza dziesiątki predefiniowanych modeli matematycznych. Jeśli modelujesz stały trend, używasz modelu Linear1D. Jeśli badasz linię emisyjną w widmie, sięgasz po model Gaussian1D. Te obiekty modeli enkapsulują swoje parametry, takie jak amplituda, mean i odchylenie standardowe. Zanim przyjrzymy się procesowi fittingu, musimy omówić częste źródło nieporozumień. W Astropy modele są obiektami callable. Przekazujesz array współrzędnych bezpośrednio do zinstancjonowanego modelu, a on ewaluuje matematykę, żeby zwrócić odpowiednie wartości. Co najważniejsze, kiedy optymalizujesz model, fitter nie mutuje twojego oryginalnego obiektu początkowego. Zawsze zwraca zupełnie nową instancję zfitowanego modelu. Twój initial guess jest zachowany dokładnie tak, jak go zdefiniowałeś. Wyobraź sobie scenariusz, w którym masz zaszumione jednowymiarowe dane w postaci arraya, reprezentujące jakąś cechę widma. Najpierw inicjalizujesz model Gaussian1D z przybliżonymi wartościami początkowymi dla amplitudy, parametru mean i szerokości. Ponieważ Astropy oddziela matematykę od optymalizatora, przypinasz swoje fizyczne ograniczenia bezpośrednio do parametrów modelu. Załóżmy, że znasz już dokładną współrzędną środka tej linii widmowej. Odwołujesz się do parametru mean w swoim modelu i ustawiasz jego property fixed na True. Algorytm optymalizacji zostawi teraz tę wartość w spokoju. Możesz również ustalić matematyczne granice. Ustawiając dolną granicę na zero dla parametru amplitudy, wymuszasz na algorytmie odrzucenie wszelkich rozwiązań, które dają ujemny pik. Kiedy twój model początkowy ma już wszystkie ograniczenia, wprowadzasz fittera. Dla równań nieliniowych, takich jak Gaussian, instancjonujesz fittera najmniejszych kwadratów Levenberga-Marquardta, znanego w Astropy jako LevMarLSQFitter. Wykonujesz fit, wywołując ten obiekt fittera i przekazując mu swój początkowy model Gaussian wraz z poziomymi i pionowymi arrayami danych. Algorytm wykonuje się i zwraca zupełnie nowy model Gaussian1D, zawierający zoptymalizowane wartości parametrów. Ponieważ ten nowy model jest bezpośrednio callable, po prostu przekazujesz do niego swój oryginalny poziomy array, żeby wygenerować gładką matematyczną krzywą, którą możesz narysować na tle swoich zaszumionych danych. Oto kluczowa sprawa. Przechowując ograniczenia w modelu, zamiast przekazywać je do solvera, algorytmy fittingu pozostają generyczne. Skupiasz swój wysiłek na zakodowaniu fizycznej rzeczywistości swojego problemu w modelu matematycznym, pozwalając Astropy na podmianę logiki optymalizacji w tle, bez psucia twojego pipeline'u. To wszystko w tym odcinku. Dzięki za wysłuchanie i budujcie dalej!

Cześć, tu Alex z DEV STORIES DOT EU. Astropy: Python dla astronomii, odcinek 13 z 15. Zamiast pisać ręcznie ogromną, piętnastoparametrową funkcję matematyczną, żeby dopasować ją do zaszumionego widma, co powiesz na to, by po prostu połączyć podstawowe kształty jak klocki Lego i pozwolić Pythonowi zająć się rachunkiem różniczkowym? Właśnie to omówimy dzisiaj w kontekście Compound Models i Custom Fits. W Astropy rzadko musisz budować złożone modele analityczne od podstaw. Bierzesz proste, predefiniowane bloki i łączysz je za pomocą standardowych operatorów arytmetycznych Pythona, takich jak dodawanie, odejmowanie, mnożenie czy dzielenie. Kiedy dodajesz do siebie dwa modele Astropy, nie otrzymujesz statycznego arraya z wyliczonymi wartościami. Otrzymujesz zupełnie nowy, w pełni funkcjonalny obiekt modelu. Ta złożona struktura potrafi ewaluować samą siebie, obliczać swoje pochodne i śledzić każdy parametr z oryginalnych modeli bazowych. Wyobraź sobie konkretny scenariusz. Masz widmo zawierające dwie wyraźne linie emisyjne, leżące na płaskim kontinuum tła. Chcesz sfittować całą tę strukturę jednocześnie. Zaczynasz od zainstancjonowania podstawowego modelu wielomianowego, który posłuży jako twoja płaska linia bazowa. Następnie tworzysz instancje dwóch oddzielnych, jednowymiarowych modeli Gaussa, które będą reprezentować te dwie linie emisyjne. Aby utworzyć swój ostateczny profil widmowy, po prostu definiujesz nową zmienną, która równa się wielomian plus pierwszy Gauss plus drugi Gauss. Astropy automatycznie łączy je w jedno złożone drzewo ewaluacji. To wprowadza częstą pułapkę związaną z dostępem do parametrów. Kiedy tworzysz ten złożony model, możesz się zastanawiać, jak wyizolować parametr amplitude drugiej linii emisyjnej. Ponieważ oba to modele Gaussa, oba mają parametr o nazwie amplitude. Astropy rozwiązuje tę kolizję, automatycznie dodając numeryczne sufiksy na podstawie kolejności, w jakiej modele zostały połączone. Parametry pierwszego Gaussa zmieniają nazwy na amplitude zero, mean zero i standard deviation zero. Drugi Gauss otrzymuje amplitude one, mean one i tak dalej. Jeśli kiedykolwiek pogubisz się w tym, który parametr należy do którego komponentu, możesz sprawdzić atrybut parameter names swojego złożonego modelu, aby zobaczyć dokładną, wygenerowaną listę. Teraz druga kwestia, czyli dopasowywanie danych, które niosą ze sobą jednostki fizyczne. Pomiary astronomiczne to nie tylko surowe floaty. Twoją zmienną niezależną może być długość fali w angstremach, a zmienną zależną gęstość strumienia w janskych. Modele Astropy radzą sobie z tym elegancko za pomocą obiektu Quantity. Kiedy przekazujesz swoje arraye z danymi do fittera, przekazujesz obiekty Astropy Quantity bezpośrednio, bez usuwania jednostek. Fitter analizuje jednostki twoich danych wejściowych i strukturę twojego złożonego modelu. Wyłapuje niezgodności wymiarowe jeszcze zanim fit w ogóle się rozpocznie. Kiedy fit osiągnie zbieżność, parametry w wynikowym modelu będą automatycznie zawierać poprawne jednostki fizyczne. Twoje parametry mean z Gaussa zaktualizują się do angstremów, a parametry amplitude do janskych. Nie musisz pisać własnej logiki konwersji ani usuwać jednostek przed fittowaniem, tylko po to, by później je ponownie dołączyć. Złożony model wymusza spójność wymiarową w całym procesie. Oto kluczowy wniosek. Kiedy używasz znaku plus między dwoma modelami, nie tylko chainujesz ze sobą funkcje. Konstruujesz jedno, ujednolicone równanie, które zachowuje ścisłą świadomość jednostek i identyfikowalność parametrów od surowych danych aż do ostatecznego fita. To tyle na dzisiaj. Do usłyszenia następnym razem!

Cześć, tu Alex z DEV STORIES DOT EU. Astropy: Python dla astronomii, odcinek 14 z 15. Masz czternaście tysięcy nierównomiernie rozłożonych w czasie zdjęć gwiazdy z teleskopu. Gdzieś w tym szumie kryje się spadek jasności o zero przecinek zero jeden procenta, spowodowany przez obcą planetę przechodzącą na jej tle. Oto dokładny algorytm, jak go znaleźć. Ten odcinek dotyczy analizy szeregów czasowych i polowania na egzoplanety. Astropy obsługuje ten workflow za pomocą klasy TimeSeries. Zanim przejdziemy dalej, wyjaśnijmy pewne powszechne nieporozumienie. TimeSeries nie jest zupełnie nową strukturą danych z własnymi regułami. Jest po prostu podklasą QTable. Oznacza to, że każda znana ci metoda manipulacji tabelą, operacja na kolumnach i technika maskowania nadal działa idealnie. Jedyna różnica polega na tym, że pierwsza kolumna jest ściśle wymuszana jako obiekt Time z Astropy. Ta zasada gwarantuje, że twoje timestampy i pomiary flux pozostaną idealnie wyrównane, niezależnie od tego, czy obserwacje są równomiernie rozłożone, czy całkowicie losowe. Aby zacząć polowanie na egzoplanetę, najpierw ładujesz krzywą blasku. Astropy oferuje wbudowane readery, pozwalające przekazać plik FITS z teleskopu Kepler bezpośrednio do funkcji read klasy TimeSeries. Automatycznie ustawia ona kolumnę Time i zaciąga pomiary światła, zazwyczaj nazywane flux. Dane z Keplera są niezwykle gęste, czasami zawierają tysiące punktów danych z przestrzeni kilku miesięcy. Te surowe dane często zawierają szum o wysokiej częstotliwości pochodzący ze statku kosmicznego lub aktywności samej gwiazdy. Możesz je wygładzić używając downsamplingu poprzez agregację. Definiujesz rozmiar binu czasowego, na przykład dziesięć minut, i przekazujesz funkcję agregującą, taką jak mean. Astropy grupuje timestampy w te biny i uśrednia flux, zmniejszając rozmiar datasetu i tłumiąc losowy szum bez wymazywania właściwego sygnału tranzytu. Masz teraz czyste dane, ale tranzyty egzoplanety są ukryte gdzieś na ogromnej osi czasu. Aby znaleźć planetę, potrzebujesz periodogramu. Możesz kojarzyć periodogram Lomba-Scargle'a, który świetnie nadaje się do znajdowania gładkich, ciągłych fal sinusoidalnych, takich jak światło pulsującej gwiazdy. Ale planeta przechodząca na tle gwiazdy nie tworzy fali sinusoidalnej. Tworzy płaską linię, nagły spadek, płaskie dno i nagły wzrost. Sygnał to box. Z powodu tego kształtu, używasz periodogramu Box Least Squares, czyli BLS. Przekazujesz swoją kolumnę time i kolumnę flux do funkcji BLS. Algorytm następnie sprawdza całą siatkę możliwych okresów orbitalnych, testując na przykład wszystko od orbity jednodniowej do pięćdziesięciodniowej. Dla każdej testowanej częstotliwości, przesuwa matematyczny box po danych, próbując dopasować głębokość i czas trwania potencjalnego tranzytu planety. Zwraca widmo mocy pokazujące, jak dobrze ten box dopasował się przy każdej pojedynczej częstotliwości. Po prostu wyciągasz okres, który wygenerował najwyższy pik mocy. To jest twoja podejrzewana orbita egzoplanety. Kiedy masz już ten dokładny okres, musisz go zweryfikować wizualnie. Bierzesz swój oryginalny TimeSeries i wywołujesz metodę fold, przekazując okres, który właśnie odkryłeś. Folding bierze każdą pojedynczą obserwację z przestrzeni miesięcy lub lat i mapuje ją na pojedynczy cykl orbitalny. Zamiast chronologicznej osi czasu, twoja oś pozioma staje się fazą, w zakresie od zera do jednego. Za każdym razem, gdy planeta przechodziła na tle gwiazdy w trakcie trwania misji, te pojedyncze punkty danych są układane jeden na drugim w dokładnie tej samej fazie. To jest ta najważniejsza część. Kiedy wygenerujesz plot tego TimeSeries po operacji fold, losowy rozrzut na osi czasu znika, a dokładnie w środku twojego wykresu pojawia się czysty, niezaprzeczalny spadek w kształcie litery U. Właśnie użyłeś geometrii i czasu, aby wyciągnąć niewidzialny świat z szumu. Dzięki za spędzenie ze mną tych kilku minut. Do usłyszenia następnym razem, trzymaj się.

Cześć, tu Alex z DEV STORIES DOT EU. Astropy: Python dla astronomii, odcinek 15 z 15. Rozwiązywanie metryki rozszerzającego się wszechświata zazwyczaj wymaga ręcznego obliczania ogromnych całek eliptycznych. Albo możesz po prostu zaimportować jeden moduł i pozwolić Pythonowi wykonać obliczenia. Dzisiaj przyjrzymy się tematowi Obliczenia kosmologiczne: Mierzenie wszechświata. Subpakiet cosmology w Astropy zamyka ogólną teorię względności i metrykę Friedmanna-Lemaitre'a-Robertsona-Walkera w prostych wywołaniach funkcji. Zamiast pisać własne integratory do mapowania redshiftu na fizyczną odległość, definiujesz model kosmologiczny, a biblioteka zajmuje się geometrią pod spodem. Kosmologia w Astropy to po prostu obiekt Pythona. Możesz go zbudować od zera używając klasy FlatLambdaCDM. Przekazujesz jej stałą Hubble'a, na przykład siedemdziesiąt, i początkową gęstość materii, na przykład zero przecinek trzy. To daje ci przestrzennie płaski wszechświat napędzany przez ciemną energię i zimną ciemną materię. Jednak rzadko musisz wpisywać te parametry samodzielnie. Astropy zawiera standardowe, wbudowane realizacje oparte na największych przeglądach nieba. Po prostu importujesz Planck13 albo WMAP9 z modułu cosmology i od razu masz w pełni skonfigurowany model gotowy do obliczeń. A oto kluczowa rzecz, jeśli chodzi o state. Parametry obiektu cosmology w Astropy są ściśle immutable. Jeśli zainicjalizujesz model, a potem zdecydujesz, że chcesz podkręcić gęstość materii, nie możesz zaktualizować tego atrybutu in place. Próba zrobienia tego wyrzuci error. Zamiast tego wywołujesz metodę clone na swoim istniejącym modelu, przekazując nową wartość parametru jako argument. To zwraca zupełnie nową instancję cosmology z twoimi zaktualizowanymi wartościami. Weźmy konkretny scenariusz z użyciem wbudowanego modelu Planck13. Załóżmy, że obserwujesz galaktykę z redshiftem równym dwa. Chcesz poznać jej lookback time, czyli ile lat zajęło światłu dotarcie do twojego teleskopu. Bierzesz swój obiekt Planck13, wywołujesz na nim metodę lookback time i przekazujesz jej dwójkę. Metoda zwraca wartość czasu w gigalatach. Używasz dokładnie tego samego wzorca, żeby obliczyć luminosity distance. Wywołujesz metodę luminosity distance ze swoim redshiftem, a Astropy zwraca odległość w megaparsekach, uwzględniając ekspansję wszechświata. To tyle, jeśli chodzi o przejście od inputów do outputów, ale co w odwrotną stronę? Czasami masz fizyczny pomiar i musisz znaleźć odpowiadający mu redshift. Powiedzmy, że chcesz poznać dokładny redshift, przy którym wszechświat miał dokładnie dwa miliardy lat. Nie możesz po prostu przekazać wieku do standardowych metod. Zamiast tego importujesz funkcję o nazwie z at value. Przekazujesz jej metodę, którą chcesz odwrócić, czyli metodę age twojego modelu Planck13, i przekazujesz jej docelową wartość dwóch gigalat. Astropy odpala pod spodem numeryczną procedurę szukania miejsc zerowych i zwraca precyzyjny redshift. Konwersja między redshiftem a fizycznym czasem lub odległością to podstawa astronomii pozagalaktycznej, a ten moduł daje ci przetestowane source of truth, dzięki czemu możesz skupić się na danych zamiast na debugowaniu całek. Ponieważ to już ostatni odcinek naszej serii o Astropy, zachęcam cię do przejrzenia oficjalnej dokumentacji, wypróbowania tych narzędzi w praktyce, albo odwiedzenia DEV STORIES DOT EU, żeby zaproponować tematy do naszej kolejnej serii. Dzięki za spędzenie ze mną tych kilku minut. Do usłyszenia następnym razem, trzymaj się!