Prognozy numeryczne od kuchni: co dzieje się z danymi, zanim zobaczysz ikonki w aplikacji

Dlaczego ikonka z aplikacji to tylko wierzchołek góry lodowej

Ta sama lokalizacja, ta sama godzina, trzy różne aplikacje pogodowe – i trzy różne wartości temperatury czy szansy opadu. Z perspektywy użytkownika wygląda to jak bałagan. Z perspektywy meteorologii numerycznej to tylko naturalny efekt bardzo złożonego łańcucha przetwarzania danych, który zaczyna się na stacjach pomiarowych, radarach i satelitach, a kończy się na kolorowej ikonce w telefonie.

Interfejs użytkownika jest brutalnie uproszczony: kilka liczb, ikona chmurki, kropel deszczu albo słoneczko. Tymczasem pod spodem pracują gigantyczne modele numeryczne, które rozwiązują równania fizyki atmosfery na superkomputerach, integrują dane z tysięcy źródeł i próbują przełożyć dynamiczny, chaotyczny system atmosferyczny na coś, co da się pokazać w jednym małym kafelku.

Temperatura w aplikacji to najczęściej interpolowana (czyli przeliczona z siatki modelu na konkretny punkt) wartość z prognozy numerycznej plus korekty lokalne. Opad to z kolei wynik całego łańcucha: od pola wilgotności i ruchów wznoszących w modelu, przez parametryzację (modelowy „przepis” na chmury i deszcz), po postprocessing, który dopasowuje suche liczby do znanych błędów modelu i historii pomyłek. Wiatr, chmury, odczuwalna temperatura – wszystko jest pochodną tego samego procesu.

Telefon pokazuje zwykle lokalną prognozę punktową, często przeliczoną z modelu o rozdzielczości kilku kilometrów (albo większej) i dodatkowo „wygładzoną” przez algorytmy aplikacji. Z drugiej strony stoją surowe prognozy globalne, które „widzą” Ziemię w krokach po kilkanaście–kilkadziesiąt kilometrów, a wysokość Tatr czy gęstość zabudowy dużego miasta są w nich tylko przybliżeniem. Pomiędzy jednym a drugim odbywa się ogrom pracy: downscaling (zagęszczanie informacji), korekcje statystyczne, łączenie wielu modeli (ansamble).

Różnice między aplikacjami biorą się głównie z trzech warstw decyzyjnych:

• jakie modele numeryczne dana aplikacja wykorzystuje (globalne, regionalne, mieszane),
• jak wygląda ich postprocessing – czyli jak poprawiają „surowe” wyjścia modelu na podstawie stacji lokalnych i historii błędów,
• jakie uproszczenia stosuje interfejs – np. czy ikona deszczu zapala się już przy 20% prawdopodobieństwa opadu, czy dopiero przy 60%.

Zrozumienie, co dzieje się „po drodze” z danymi meteorologicznymi, pozwala inaczej spojrzeć na te kolorowe ikonki: nie jak na absolutną prawdę, lecz jako na wygodny, mocno skompresowany widok bardzo złożonego systemu obliczeń.

Surowe dane meteorologiczne – co ląduje w „kotle” modelu

Każda prognoza numeryczna zaczyna się od tego, co atmosfera robi „tu i teraz”. Aby to uchwycić, zbiera się dane z dziesiątek rodzajów sensorów. Problem w tym, że pomiary są nierówne w przestrzeni, zanieczyszczone błędami i często niekompletne. Model numeryczny nie może po prostu wczytać pliku z danymi i wystartować – musi dostać z nich spójny, trójwymiarowy obraz stanu atmosfery.

Źródła danych obserwacyjnych

Najbardziej intuicyjnym źródłem są stacje naziemne. To one mierzą temperaturę, wilgotność, ciśnienie, wiatr i opad w zadanych punktach. Dzielą się na stacje synoptyczne (pełny zestaw parametrów, często co godzinę lub częściej) i klimatologiczne (rzadziej, mniejszy zestaw elementów). Ich największa zaleta to dokładność i względna stabilność. Największa wada – punktowość. Jedna stacja opisuje realnie obszar rzędu kilku kilometrów wokół siebie i to też nieidealnie, bo inna będzie na lotnisku, inna w centrum miasta, a jeszcze inna na wzgórzu.

Kolejny filar to radary meteorologiczne. Nie mierzą „deszczu” wprost, tylko odbiciowość (siłę powrotnego sygnału mikrofalowego od hydrometeorów, czyli kropli, kryształków lodu, gradu). Z tego przy użyciu algorytmów wnioskuje się intensywność opadu, typ zjawiska (deszcz, śnieg, burza) i jego strukturę w przestrzeni. Radar ma zasięg rzędu kilkuset kilometrów, ale jest wrażliwy na przesłonięcia (góry, wysokie budynki), zakłócenia i wymaga kalibracji. Mimo to to podstawowe narzędzie do śledzenia układów opadowych, zwłaszcza konwekcyjnych (burze).

Dla atmosfery w pionie potrzebne są sondowania aerologiczne – klasyczne balony meteorologiczne z radiostacją. Wypuszczane zwykle co 12 godzin, mierzą profil temperatury, wilgotności, wiatru i ciśnienia od powierzchni aż po stratosferę. Dane z balonów są kluczowe dla analizy warstwy granicznej, inwersji, stabilności atmosfery i strumieni odrzutowych (jet stream). Ponieważ balonów jest mało, szczególnie na oceanach i w biedniejszych regionach, sama ich sieć nie wystarczyłaby do dobrego stanu początkowego.

Uzupełnieniem są boje oceaniczne i pomiary morskie, które dostarczają informacji o temperaturze powierzchni morza, falowaniu i wietrze nad wodą. Do tego dochodzą pomiary z samolotów (systemy typu AMDAR) – samoloty pasażerskie przekazują profil temperatury i wiatru podczas startu i lądowania oraz dane z wysokości przelotowych, co znacząco poprawia znajomość stanu atmosfery nad głównymi korytarzami lotniczymi.

Na końcu są sieci amatorskie – stacje domowe (np. Netatmo, Davis) połączone w sieci współdzielące dane. Z punktu widzenia numerycznej prognozy są to dane bardzo „brudne”: z różną jakością sensorów, złym montażem (zawieszona stacja nad betonowym dachem, w słońcu, bez osłony) i często błędną lokalizacją GPS. Część systemów assimilacji zaczyna wykorzystywać takie dane, ale dopiero po mocnym filtrowaniu i z niską wagą w stosunku do innych źródeł.

Satelity meteorologiczne – oko na całą planetę

Bez satelitów meteorologicznych nie byłoby nowoczesnej prognozy. Dają one quasi-ciągły obraz całego globu, uzupełniając dziury w sieciach naziemnych i oceanicznych. Dzielą się na dwie główne klasy: geostacjonarne (zawieszone „nad jednym punktem” równika, cały czas patrzące na ten sam fragment Ziemi) oraz polarno-orbitalne (krążące po orbitach przecinających bieguny, skanujące Ziemię pasami).

Satelita nie mierzy „temperatury” czy „wilgotności” bezpośrednio. Rejestruje radiancje – natężenie promieniowania w różnych pasmach widma (kanałach spektralnych). Dopiero systemy naziemne przeliczają te radiancje na produkty meteorologiczne. Inne kanały są wrażliwe na chmury niskie, inne na wysokie cirrusy, inne na parę wodną w różnych warstwach atmosfery, a jeszcze inne na temperaturę powierzchni lądu lub morza.

Satelity geostacjonarne (np. nad Europą) dają bardzo częste aktualizacje – obraz co kilka minut. Świetnie nadają się do śledzenia rozwoju chmur, frontów, systemów burzowych. Satelity polarne oferują wyższą rozdzielczość przestrzenną i lepsze dane o stanie atmosfery w pionie, ale przelatują nad danym punktem tylko co jakiś czas. Modele numeryczne korzystają intensywnie z radiancji satelitarnych w assimilacji danych, szczególnie nad oceanami, gdzie brak jest naziemnych pomiarów.

Różne kanały spektralne przekładają się na różne typy informacji:

• kanały w podczerwieni – „temperatura jasnościowa” chmur i powierzchni, profil temperatury, wykrywanie wysokich chmur lodowych,
• kanały w zakresie pary wodnej – rozkład pary wodnej w troposferze, dynamika strumieni odrzutowych,
• kanały w zakresie widzialnym – struktura chmur w dzień, pokrywa śnieżna, dym, pył,
• pasy mikrofalowe – informacje o opadzie, zawartości wody ciekłej i lodu w chmurach, także pod cienkimi chmurami.

Jakość i „brudność” danych wejściowych

Surowe dane meteorologiczne są pełne problemów, które trzeba rozwiązać, zanim trafią do modelu. Klasyka to błędy pomiarowe – rozkalibrowany sensor temperatury, anemometr zablokowany lodem, zapchany deszczomierz. Dochodzą błędy lokalizacji (zły GPS), złe metadane (wysokość stacji, typ podłoża), a nawet błędy komunikacyjne, które zmieniają jednostki lub format danych.

Na poziomie regionu pojedyncza stacja potrafi poważnie „zepsuć” obraz. Wyobraźmy sobie stację w centrum miasta, która w upalny dzień, stojąc nad gorącym asfaltem, raportuje temperaturę o kilka stopni wyższą niż otaczające ją stacje na peryferiach. Jeśli system jakości nie wychwyci takiej anomalii, assimilacja danych może przesunąć w górę temperaturę w całej okolicy, co wypaczy pole temperatury początkowej i wpłynie na prognozę dla wielu punktów siatki modelu.

Zdarzają się też brakujące pomiary – awaria stacji, przerwa w komunikacji satelitarnej, błąd w bazie danych. Systemy assimilacji są na to przygotowane: potrafią operować na „nierównych” zestawach danych, ale mniejsza ilość wiarygodnych obserwacji w danym regionie automatycznie obniża jakość analizy, a więc także dalszej prognozy.

Wszystko to sprawia, że pierwszą krytyczną fazą prognozy jest nie licznie równań, ale czyszczenie i weryfikacja danych. To tutaj decyduje się, które obserwacje są na tyle wiarygodne, by zagrały dużą rolę w kształtowaniu stanu początkowego, a które zostaną odrzucone lub silnie zważone.

Assimilacja danych – jak z mętnego obrazu zrobić spójny stan atmosfery

Gdyby spróbować wprost „wrysować” dane obserwacyjne w siatkę modelu, skończyłoby się to katastrofą: w jednych miejscach mielibyśmy nadmiar informacji, w innych gigantyczne luki, a między nimi ostre, fizycznie nierealistyczne skoki wartości. Assimilacja danych jest odpowiedzią na ten problem – to zestaw metod, które łączą obserwacje z prognozą tła w spójny, fizycznie sensowny obraz całej atmosfery.

Na czym polega assimilacja danych pogodowych

Stan początkowy atmosfery w modelu to trójwymiarowa „migawka”: temperatura, ciśnienie, wilgotność, prędkość i kierunek wiatru, zawartość chmur, stan powierzchni morza, gleby itd. w każdej komórce siatki. Żaden system obserwacyjny nie daje takiego obrazu bezpośrednio. Mamy tylko „strzępy” informacji: tu termometr na lotnisku, tam profil z balonu, gdzie indziej radiancje satelitarne.

Assimilacja danych (ang. data assimilation) tworzy z tych strzępów analizę – najlepsze dostępne oszacowanie stanu atmosfery, biorąc pod uwagę:

• obserwacje o różnej jakości i różnej gęstości,
• tło (background) – czyli krótkoterminową prognozę z poprzedniego uruchomienia modelu,
• szacunki błędów – zarówno w obserwacjach, jak i w tle.

Dlaczego nie można po prostu zastąpić wartości w siatce tym, co pokazują czujniki? Bo większość komórek siatki nie ma żadnej obserwacji w pobliżu, a nawet tam, gdzie są, obserwacje nie obejmują wszystkich parametrów ani całej kolumny atmosfery. Model musi „wiedzieć”, jak rozsądnie rozłożyć wpływ pojedynczej obserwacji w przestrzeni, pionie i czasie, zachowując jednocześnie dynamikę atmosfery.

Metody assimilacji w uproszczeniu: 3D/4D-Var i filtry ansamblowe

W praktyce używa się dwóch głównych rodzin metod. Pierwsza to metody wariacyjne (3D-Var, 4D-Var). W dużym uproszczeniu szukają one takiego stanu atmosfery, który minimalizuje pewną funkcję kosztu: jest możliwie bliski tłu (bo tło też niesie informację fizyczną) i możliwie dobrze pasuje do obserwacji, z uwzględnieniem ich błędów. 3D-Var robi to w jednym momencie czasu, 4D-Var w całym przedziale czasowym (oknie assimilacji), analizując, jak stan atmosfery ewoluuje zgodnie z modelem.

Druga rodzina to metody ansamblowe, np. filtr Kalmana w wersji ansamblowej (EnKF). Zamiast jednej prognozy tła, model uruchamia się wiele razy z minimalnie różnymi warunkami startowymi i/lub parametrami (to właśnie ansambl). Z tego zestawu prognoz wyciąga się statystykę błędów – jak wartości różnych parametrów w różnych punktach są ze sobą powiązane. Następnie aktualizuje się ten ansambl pod wpływem obserwacji, poprawiając prognozę w sposób statystycznie optymalny.

W obu podejściach kluczowe jest rozróżnienie między:

• tłem (background) – poprzednią prognozą, zwykle na kilka–kilkanaście godzin do przodu,
• analizą (analysis) – skorygowanym stanem po uwzględnieniu obserwacji.

Nowa prognoza numeryczna startuje z analizy. Jakość analizy przekłada się niemal liniowo na jakość prognozy, szczególnie na najbliższe godziny.

Jak obserwacje „rozlewają się” po całym polu atmosfery

Jedna obserwacja nie zmienia tylko jednego „pikselka” w modelu. Informacja z czujnika jest rozprzestrzeniana w przestrzeni zgodnie z założonymi korelacjami błędów. Jeśli stacja naziemna pokazuje, że jest chłodniej niż w tle, system assimilacji:

• skoryguje temperaturę w kilku–kilkunastu sąsiednich komórkach siatki w poziomie,
• częściowo wpłynie na temperaturę w pionie (w dolnych warstwach troposfery),
• może pośrednio zmienić wiatr i wilgotność, jeśli statystyka błędów wskazuje, że te pola są ze sobą skorelowane.

Dla satelitów sprawa jest bardziej złożona, bo pojedyncza radiancja jest wypadkową sygnału z całej grubej warstwy atmosfery. Assimilacja używa tzw. operatorów obserwacyjnych (ang. observation operators), które przeliczają stan modelu (profil temperatury, wilgotności, chmur) na „symulowaną radiancję”. Dopiero różnica między radiancją zmierzoną i symulowaną (tzw. innowacja) służy do korekty stanu.

Tip: w nowoczesnych systemach więcej informacji z satelitów assimiluje się jako radiancje surowe, a nie gotowe produkty typu „temperatura na 850 hPa”. Omija się w ten sposób dodatkową warstwę przetwarzania, która wnosi własne błędy.

Okna czasowe i opóźnienia: prognoza żyje w „strefie buforowej”

Obserwacje nie napływają jednocześnie. Dane z radaru mogą być dostępne po kilku minutach, z sondy atmosferycznej po kilkudziesięciu, a z niektórych satelitów nawet z większym opóźnieniem. System assimilacji działa więc w oknie czasowym (ang. assimilation window) – przedziale, w którym dopuszcza się obserwacje do jednej analizy.

Dla globalnych modeli to okno często ma 6 godzin, dla bardzo krótkoterminowych prognoz (nowcasting) – 1 godzinę lub mniej. W metodach 4D-Var i ansamblowych progresja stanu atmosfery w czasie jest jawnie uwzględniana: obserwacja wykonana o 13:15 wpływa na stan o 12:00 i 15:00 zgodnie z dynamiką modelu, a nie „na sztywno” w jednym momencie.

Tutaj pojawia się klasyczny kompromis:

• chcemy jak najwięcej obserwacji (dłuższe okno),
• ale też jak najmniejsze opóźnienie w publikacji prognozy (krótsze okno).

Dlatego na przykład prognoza z globalnego modelu dostępna w aplikacji o 13:30 mogła korzystać z danych obserwacyjnych dochodzących do centrów obliczeniowych jeszcze po 12:00, a sama analiza mogła powstać dopiero kilkadziesiąt minut później.

Dlaczego prognoza nie „skacze” za każdym nowym pomiarem

Gdyby system każdą nową obserwację traktował jak absolutną prawdę, prognoza zmieniałaby się chaotycznie z godziny na godzinę. Assimilacja projektuje się tak, aby wprowadzać zmiany płynnie i zgodnie z fizyką.

Rolę filtra pełnią m.in.:

• macierze błędów – opisują, jak ufa się tłu i obserwacjom; jeśli dany typ danych był w przeszłości zawodny, jego wpływ jest mniejszy,
• kontrola jakości on-line – obserwacje z dużymi innowacjami (drastycznie niezgodne z tłem) są odrzucane lub osłabiane,
• konsystencja dynamiczna – nie dopuszcza się stanów, które złamałyby podstawowe równania (np. skrajne gradienty pola ciśnienia).

Dzięki temu w praktyce zmiany między kolejnymi runami modelu są zwykle niewielkie, o ile nie pojawi się nowy, silny sygnał obserwacyjny (np. eksplozja chmurowa nad obszarem wcześniej bez danych radarowych).

Wnętrze modelu numerycznego – jak rozwiązuje się równania atmosfery

Po uzyskaniu analizy model dostaje „startowy snapshot” atmosfery i zaczyna go przepuszczać przez zestaw równań opisujących ruchy płynów, termodynamikę, promieniowanie, wilgoć i procesy mikro-fizyczne w chmurach. W praktyce to tysiące równań z wieloma sprzężeniami zwrotnymi, rozwiązywanych na superkomputerach.

Równania ruchu: prawo zachowania energii, masy i pędu

Podstawą większości modeli pogodowych jest zestaw równań znanych jako równania Naviera-Stokesa w wersji dla atmosfery, uzupełniony o:

• równanie ciągłości masy (powietrza i pary wodnej),
• równanie stanu gazu (relacja między temperaturą, ciśnieniem i gęstością),
• równanie pierwszej zasady termodynamiki (bilans energii),
• równania dla składników śladowych (para wodna, lód, ciekła woda, czasem aerozole).

W czystej postaci ten układ jest zbyt złożony, by dało się go liczyć dla całej Ziemi w rozsądnych czasach. Stosuje się więc uproszczenia – np. aproksymację hydrostatyczną w wielu modelach globalnych (zakłada się równowagę między ciśnieniem a grawitacją w pionie), co jest w większości sytuacji bardzo dobre, choć słabiej opisuje silne prądy wstępujące w burzach.

Discretization: zamiana równań ciągłych na „klocki” na siatce

Atmosfera jest ciągła, ale komputer pracuje na skończonej liczbie komórek. W modelu definiuje się więc siatkę numeryczną:

• w poziomie – kwadraty lub heksagony o wymiarze od kilkudziesięciu kilometrów (modele globalne) do kilkuset metrów (modele lokalne),
• w pionie – kilkadziesiąt warstw od powierzchni do górnej stratosfery lub mezosfery.

Równania różniczkowe zamienia się na równania różnicowe – zamiast pochodnych pojawiają się różnice między sąsiednimi komórkami. To tzw. discretization, realizowana różnymi schematami numerycznymi: finite-difference, finite-volume, czasem spektralnymi (rozwinięcie pola w funkcje bazowe, np. harmoniczne sferyczne).

Uwaga: wybór schematu jest krytyczny. Zbyt prosty może wprowadzać sztuczne oscylacje (tzw. „zeby” w polu temperatury), zbyt złożony – będzie za wolny obliczeniowo. Twórcy modeli przez lata „stroją” te schematy, testując je na realnych sytuacjach pogodowych.

Krok czasowy – jak daleko w przyszłość wolno „skoczyć” naraz

Aby liczyć ewolucję stanu atmosfery, model przesuwa się w czasie krokami: 1 minuta, 2 minuty, czasem kilka sekund w modelach bardzo wysokiej rozdzielczości. Długość kroku ogranicza kryterium stabilności Couranta-Friedrichsa-Lewy’ego (CFL). W dużym uproszczeniu: informacja (np. fala, podmuch wiatru) nie może w jednym kroku przeskoczyć dalej niż jedna komórka siatki, bo obliczenia staną się niestabilne.

Dla modeli globalnych z siatką kilkudziesięciu kilometrów kroki mogą być większe, bo sygnały pokonują stosunkowo małą odległość w jednostce czasu w stosunku do rozmiaru komórki. W modelach „burzowych” z oczkiem 1 km trzeba już liczyć znacznie częściej. To jeden z powodów, dla których zwiększanie rozdzielczości drastycznie podnosi koszt obliczeń – nie tylko jest więcej komórek, ale też więcej kroków czasowych.

Procesy „podsiatkowe” – parametryzacje

Siatka modelu nie rozwiązuje wszystkiego. Zjawiska mniejsze niż rozmiar komórki – np. pojedyncze komórki burzowe w modelu o oczku 7 km – trzeba uwzględnić pośrednio, przez parametryzacje. To zestaw równań empirycznych opisujących statystyczny wpływ małych struktur na większą skalę.

Do najważniejszych procesów parametryzowanych należą:

• konwekcja głęboka – rozwój chmur Cb i burz, wymiana ciepła i wilgoci w pionie,
• turbulencja i mieszanie w warstwie granicznej (niższe 1–2 km atmosfery),
• mikrofizyka chmur (w prostszych modelach) – przejścia między parą wodną, kropelkami i kryształkami lodu,
• promieniowanie – wymiana energii między powierzchnią, atmosferą i kosmosem w różnych pasmach widma.

Parametryzacje są jednym z głównych źródeł niepewności. Dwie wersje tego samego modelu, różniące się tylko schematem konwekcji, mogą produkować zupełnie inny obraz opadów i burz. Stąd pojawiają się „mody” na konkretne konfiguracje, które w danym regionie dają najlepsze wyniki.

Fizyka powierzchni – co się dzieje na styku z lądem i morzem

Model atmosferyczny sprzęga się z modelem powierzchni. Ten moduł śledzi m.in.:

• temperaturę gleby na różnych głębokościach,
• zawartość wody w glebie i śniegu,
• temperaturę powierzchni morza (SST) i lodu morskiego,
• strumienie ciepła jawnego i utajonego (parowanie, kondensacja).

Przykład z praktyki: jeśli model zaniża wilgotność gleby po długiej suszy, będzie generował za małe parowanie i za wysoką temperaturę powietrza w słoneczny dzień. A to przekłada się potem na dynamikę warstwy granicznej, rozwój chmur kłębiastych i lokalne burze.

Równoległość obliczeń – jak superkomputer liczy prognozę w czasie „użytkowym”

Dzisiejsze prognozy nie byłyby możliwe bez masywnej równoległości. Siatka modelu jest dzielona na tysiące fragmentów, z których każdy liczy inny procesor lub węzeł superkomputera. Między krokami czasowymi sąsiadujące fragmenty wymieniają dane o stanie na brzegach (tzw. halo exchange).

Równocześnie działają różne moduły fizyczne (promieniowanie, konwekcja, mikrofizyka), które również są równoleglone wewnętrznie. Kod jest pisany tak, aby maksymalnie wykorzystać pamięć współdzieloną i komunikację między węzłami (MPI, OpenMP), co często staje się większym wyzwaniem inżynierskim niż sama matematyka równań.

Typy modeli pogodowych – globalne, regionalne i bardzo lokalne

Pod nazwą „prognoza numeryczna” kryje się cały ekosystem modeli, różniących się zasięgiem, rozdzielczością i przeznaczeniem. Aplikacja w telefonie zwykle korzysta z kombinacji kilku z nich, czasem nawet nie informując, który model stoi za danym produktem.

Modele globalne – duży obraz, mniejsza rozdzielczość

Modele globalne opisują całą atmosferę wokół Ziemi. Przykłady to ECMWF, GFS, ICON czy JMA. Typowe cechy:

• siatka o oczku od kilkunastu do kilkudziesięciu kilometrów,
• horyzont prognozy do 10–16 dni (czasem więcej w trybach eksperymentalnych),
• pełna dynamika planetarna: fale Rossby’ego, prądy strumieniowe, cyklony tropikalne.

Modele globalne są podstawą całego łańcucha prognoz. Dostarczają warunków brzegowych dla modeli regionalnych: mówią, co dzieje się na krawędziach ich domeny (napływ mas powietrza, fronty, pola ciśnienia).

Z punktu widzenia użytkownika ich główna zaleta to spojrzenie szerokokątne: dobrze opisują, czy nad Europą Zachodnią buduje się blokada wyżowa, czy znad Atlantyku wejdzie aktywny cyklon, ile dni z rzędu można spodziewać się zachmurzenia. Gorzej radzą sobie z detalami lokalnymi, jak pojedyncze burze czy mgły w dolinach.

Modele regionalne – zoom na kontynent lub kraj

Na bazie globalnych prognoz uruchamia się modele mezoskalowe (regionalne) obejmujące np. Europę, Europę Środkową albo samą Polskę. Tu typowa rozdzielczość to 2–7 km.

Różnice względem modeli globalnych:

• lepsze odwzorowanie orografii (gór, dolin, wybrzeży),
• dokładniejsze pola wiatru przy powierzchni i rozkład temperatury,
• często bardziej zaawansowane schematy opadów i konwekcji, dostrojone do konkretnego regionu.

Modele regionalne zazwyczaj wymagają warunków brzegowych co kilka godzin z modelu globalnego. Co istotne, jeśli globalny model „spóźni” się z nadejściem frontu o 100 km, regionalny też nie wyczaruje go we właściwym miejscu – dostanie już przesunięty układ jako dane na brzegu swojej domeny.

Przykład: model globalny prognozuje, że aktywny front chłodny wejdzie nad Polskę wieczorem. Model regionalny doda do tego znacznie więcej szczegółów – strukturę strefy konwekcyjnej, dokładniejszy przebieg opadów, siłę szkwałów. Ale jeśli w globalnym modelu front „rozpadnie się” za wcześnie, regionalny też będzie miał zbyt słaby sygnał na południowo-wschodnim krańcu domeny.

Modele konwekcyjnie rozwiązywane – skala burz

Modele „storm-resolving” – kiedy siatka widzi pojedynczą burzę

Przy rozdzielczości rzędu 1–3 km modele zaczynają samodzielnie rozwiązywać konwekcję głęboką. Oznacza to, że chmury Cumulonimbus (burzowe) nie są już opisane parametryzacją, tylko pojawiają się jako struktury w samym polu prędkości, temperatury i wilgotności.

Konsekwencje są dość konkretne:

• znacznie lepsze odwzorowanie linii szkwału, mezocyklonów czy wędrujących układów MCS,
• możliwość prognozowania rozkładu opadu w skali pojedynczych powiatów, a nie całych województw,
• wrażliwość na drobne różnice w stanie początkowym – dwie symulacje startujące z minimalnie innych danych potrafią „przesunąć” komórki burzowe o kilkadziesiąt kilometrów.

Modele tego typu (np. AROME, ICON-D2, lokalne konfiguracje WRF czy COSMO) są typowo uruchamiane na 24–48 godzin do przodu. Dalsze wybieganie w przyszłość mija się z celem, bo błędy inicjalizacji i chaos konwekcji szybko „rozmazują” precyzyjny obraz.

Przykład z praktyki: wieczorna prognoza burz na kolejny dzień. Model globalny pokazuje tylko „pas podwyższonej niestabilności” nad południem kraju. Model konwekcyjny dzieli to na konkretne struktury: linię burz wzdłuż Karpat, rozproszone burze w centrum, potencjalne wtórne komórki za głównym frontem. To właśnie te produkty trafiają potem w prognozy ostrzeżeń czy mapki z gradem i silnym wiatrem.

Modele miejskie i „street-scale” – gdy liczy się ulica, a nie województwo

Na końcu skali są modele o oczku rzędu kilkuset metrów lub mniej, często sprzęgnięte z modelem zabudowy (budynki, ulice, parki). Ich zadaniem jest opis zjawisk takich jak:

• miejskie wyspy ciepła (różnica temperatury między centrum a przedmieściami),
• dyspersja zanieczyszczeń w kanionach ulicznych,
• lokalne zawirowania wiatru wokół wysokich budynków, istotne np. dla planowania wiatraków czy bezpieczeństwa konstrukcji.

Takie modele działają zazwyczaj na bardzo małych domenach (pojedyncze miasta) i krótkich horyzontach prognozy, ale za to mogą wykorzystywać szczegółową bazę danych o wysokości zabudowy, typach nawierzchni czy pokryciu zielenią. Są też coraz częściej sprzęgane z danymi z sensorów miejskich (sieci stacji niskokosztowych, czujniki na latarniach itp.).

Łańcuch modeli – od globalnego do twojej dzielnicy

W praktycznym systemie prognozowania pojedyncza prognoza to efekt działania całego łańcucha modeli. Typowy scenariusz wygląda następująco:

1. Model globalny liczy prognozę dla całej Ziemi i udostępnia ją co 6 godzin.
2. Na jej podstawie startuje model regionalny dla danego kontynentu lub kraju.
3. Z modelu regionalnego pobiera się warunki brzegowe i inicjalizuje modele konwekcyjne o wysokiej rozdzielczości.
4. Na końcu prognozy z wielu modeli są łączone i przetwarzane na „produkty” – mapy, ikonki, indeksy zagrożeń.

Opóźnienie czasowe (tzw. latencja) wynika z faktu, że każdy poziom łańcucha musi poczekać na poprzedni. Dlatego świeża prognoza wysokiej rozdzielczości nigdy nie jest dostępna od razu po obserwacjach – najpierw swoje muszą policzyć modele globalne.

Postprocessing – surowa prognoza kontra rzeczywistość

Wyjście modelu numerycznego to nie jest jeszcze to, co widzisz jako „pogodę” w aplikacji. Między nimi działa warstwa postprocessingu, często dużo sprytniejsza niż same ikonki sugerują.

Najważniejsze elementy tego etapu to:

• interpola­cja przestrzenna – przeliczenie prognozy z siatki modelu na konkretne współrzędne (twoja miejscowość, punkt na mapie),
• korekta orograficzna – uwzględnienie różnicy między wysokością terenu w modelu a rzeczywistą,
• korekta statystyczna – tzw. MOS (Model Output Statistics), czyli poprawki oparte na wieloletnim porównaniu modelu z pomiarami,
• diagnozowanie dodatkowych parametrów – indeksy burzowe, rodzaj opadu (śnieg/deszcz/mżawka), rodzaj zachmurzenia.

Przykład: model w komórce o oczku 5 km „widzi” średnią wysokość terenu 300 m n.p.m., tymczasem twoja stacja stoi w dolinie na 180 m. System postprocessingu przelicza temperaturę, wykorzystując gradient termiczny w pionie (np. 0,6–0,7°C na 100 m) i koryguje prognozę o ok. 1°C w górę. Bez tej poprawki prognoza dla doliny byłaby zbyt chłodna.

Interpola­cja czasowa – skąd się biorą godzinowe prognozy

Wiele modeli udostępnia wyjście co 3 godziny, czasem co godzinę. Aplikacje lub serwisy chcą jednak prezentować prognozę godzinową. W grę wchodzi więc interpolacja w czasie:

• dla parametrów powoli zmieniających się (temperatura, ciśnienie) stosuje się zazwyczaj interpolację liniową lub splajny,
• dla opadów i zachmurzenia – bardziej złożone metody, bo deszcz nie rośnie liniowo od 0 do 10 mm, tylko pojawia się i znika w impulsach.

Tip: jeśli aplikacja pokazuje „0,1 mm opadu o 13:00, 0,1 mm o 14:00, 0,1 mm o 15:00”, a model w rzeczywistości miał 0 mm o 12:00 i 0,3 mm o 15:00, to prawdopodobnie widzisz efekt gładkiej interpolacji w czasie, a nie faktyczną „mżawkę co godzinę”.

Downscaling – sztuczne zwiększanie szczegółowości

Gdy rozdzielczość modelu jest zbyt mała, aby odwzorować lokalne efekty (np. górskie doliny, brzeg morza), stosuje się downscaling – przeskalowanie prognozy na gęstszą siatkę lub pojedyncze punkty. Są dwa główne podejścia:

• dynamical downscaling – uruchomienie dodatkowego, małego modelu o bardzo wysokiej rozdzielczości, „wpiętego” w większy model,
• statistical downscaling – użycie relacji statystycznych (np. regresji, metod uczenia maszynowego) między dużą skalą a lokalnymi obserwacjami.

Drugie podejście jest tańsze obliczeniowo i często stosowane w aplikacjach konsumenckich. Jeśli przez kilka lat zbierano dane z twojej stacji i pola z modelu globalnego nad tym punktem, można nauczyć model korekcyjny: „gdy globalny model mówi X, realnie obserwujemy Y”. To tłumaczy, czemu dwie aplikacje, korzystając z tego samego GFS czy ECMWF, potrafią dawać inne liczby dla tej samej miejscowości.

Ensembles – wiele prognoz zamiast jednej

Aby oszacować niepewność, centra meteorologiczne uruchamiają zestawy prognoz (ensembles). Zamiast jednej prognozy model startuje kilkanaście lub kilkadziesiąt razy z minimalnie innymi warunkami początkowymi albo parametrami fizycznymi.

W praktyce z takiej paczki prognoz wyciąga się m.in.:

• średnią – wygładzony scenariusz „najbardziej typowy”,
• percentyle (np. 10, 90) – zakres możliwych wartości,
• prawdopodobieństwa zdarzeń – np. szansa, że temperatura spadnie poniżej 0°C, że suma opadu przekroczy 20 mm, że wiatr przekroczy 20 m/s.

To właśnie z ensembles biorą się produkty w stylu „prawdopodobieństwo deszczu 70%”. W tle oznacza to, że w 7 na 10 realizacji zespołu w danym miejscu i czasie pojawił się opad. Interpretacja jest subtelna: nie znaczy to, że będzie padać przez 70% czasu, tylko że scenariusz „deszczowy” jest dominujący.

Łączenie prognoz z wielu modeli – multi-model blend

Jedna aplikacja może korzystać z kilku różnych modeli jednocześnie. Popularne jest blendowanie multi-model – łączenie prognoz z ECMWF, GFS, ICON, lokalnych modeli konwekcyjnych oraz statystycznych poprawek w jeden „produkt końcowy”.

Strategie łączenia bywają różne:

• prosta średnia arytmetyczna kilku modeli,
• średnia ważona (lepszy model w danym regionie dostaje większą wagę),
• systemy uczenia maszynowego, które uczą się, który model „ma rację” przy określonych typach sytuacji synoptycznej.

Efekt uboczny: dwie różne aplikacje, korzystające z tych samych modeli bazowych, ale innego algorytmu łączenia, potrafią podawać różną temperaturę o 2–3°C czy inne prawdopodobieństwo opadu. Źródłem różnicy nie jest więc sam model numeryczny, tylko warstwa decyzyjna nad nim.

Prognozy punktowe vs. prognozy obszarowe

Model podaje wartości dla komórek siatki, czyli obszarów, a nie idealnych punktów. Gdy aplikacja wyświetla prognozę „dla twojej lokalizacji”, zwykle dzieje się jedno z dwóch:

• brana jest najbliższa komórka siatki i przypisywana do twoich współrzędnych,
• wykonywana jest interpolacja z kilku sąsiednich komórek, z uwzględnieniem wysokości terenu i pokrycia.

Ma to szczególne znaczenie w terenach górskich i przybrzeżnych. Jedna komórka może obejmować i dolinę, i fragment grzbietu, albo obszar lądu i morza. Prognoza temperatury czy wiatru będzie więc pewnym „uśrednieniem” warunków. Jeśli stoisz dokładnie w dolinie osłoniętej lasem, twoje odczucie pogody może odbiegać od wartości numerycznych.

Skąd biorą się ikonki – tłumaczenie liczb na „słowa” pogody

Na końcu całego łańcucha stoi dość prosty, ale kluczowy krok: mapowanie pól modelu na kategorie pogodowe. Dla każdej godziny w danym punkcie system patrzy na kilka parametrów:

• sumę opadu (i jego formę: deszcz, śnieg, mieszany),
• rodzaj i wysokość zachmurzenia (warstwy niskie, średnie, wysokie),
• porywy wiatru, burze (np. obecność wyładowań w polu modelu lub wysoki indeks niestabilności),
• temperaturę i punkt rosy (wilgotność).

Na podstawie prostych reguł decyzyjnych wybierana jest ikonka: „słońce”, „słońce z chmurką”, „deszcz”, „burza z deszczem”, „śnieg”. Różne serwisy stosują różne progi – dla jednych 0,1 mm/h to już „deszcz”, dla innych dopiero 0,3 mm/h. Stąd sytuacje, gdy dwie aplikacje przy tych samych polach numerycznych będą pokazywać różne ikonki (jedna „pochmurno”, druga „przelotne opady”).

Granice numerycznych prognoz – skąd bierze się chaos

Atmosfera jest układem chaotycznym w sensie matematycznym. Niewielkie błędy w stanie początkowym – szum pomiarowy, dziury w danych, przybliżenia w asymilacji – z czasem rosną wykładniczo. To klasyczny efekt motyla.

W praktyce wygląda to tak, że:

• w pierwszych 1–3 dniach prognoza jest zwykle dobrze „związana” z rzeczywistością – poszczególne modele różnią się detalami, ale scenariusz synoptyczny jest wspólny,
• między 4 a 7 dniem zaczynają się rozjazdy – jeden model widzi przejście głębokiego niżu, inny powolną blokadę wyżową,
• po 7–10 dniach sens mają już głównie prognozy probabilistyczne i uśrednione; pojedyncza ikonka typu „deszcz za 9 dni o 14:00” jest w zasadzie losowa.

To ograniczenie nie wynika z „słabości komputerów”, tylko z natury równań opisujących atmosferę. Większa moc obliczeniowa pozwala zwiększyć rozdzielczość i poprawić krótkoterminową prognozę, ale horyzont przewidywalności (rzędu 10–14 dni) przesuwa się tylko minimalnie.

Rola obserwacji bieżących – korekta „na żywo”

Między kolejnymi głównymi przebiegami modeli globalnych i regionalnych pojawiają się aktualizacje krótkoterminowe, oparte na danych radarowych, satelitarnych i z sieci stacji. Działają dwa mechanizmy:

• nowcasting – ekstrapolacja obecnych struktur (opad, burze, fronty) na najbliższe 1–3 godziny, często bez pełnego modelu dynamicznego,
• rapid update cycles – małe modele liczone co 1–3 godziny, które „dociągają” prognozę do najnowszych obserwacji.

Dzięki temu aplikacja może w ciągu dnia delikatnie korygować prognozę, np. przesuwając godzinę nadejścia opadu czy burzy, nawet jeśli główny przebieg modelu globalnego pozostaje ten sam. Dla użytkownika wygląda to jak „prognoza zmieniła się w ciągu dnia”, a w tle po prostu działa inny poziom systemu.

Najczęściej zadawane pytania (FAQ)

Dlaczego różne aplikacje pogodowe pokazują inną temperaturę i opady dla tej samej miejscowości?

Najczęstsza przyczyna to używanie różnych modeli numerycznych. Jedna aplikacja może bazować na globalnym modelu o oczku siatki kilkanaście kilometrów, inna na regionalnym o rozdzielczości kilku kilometrów, a kolejna mieszać wyniki z kilku modeli (tzw. ansambl). Każdy z tych modeli inaczej rozwiązuje równania fizyki atmosfery i inaczej „widzi” teren, więc dostaje się nieco inne prognozy temperatury, opadu czy wiatru.

Dodatkowo każda aplikacja inaczej obrabia (postprocessing) dane z modelu: koryguje je pomiarami ze stacji, stosuje własne statystyczne poprawki błędów i w inny sposób interpoluje wartości do konkretnego punktu na mapie. Na końcu dochodzi warstwa interfejsu – np. w jednej aplikacji ikonka deszczu pojawia się przy 20% szans opadu, a w innej dopiero przy 60%, choć same „surowe” liczby z modelu są podobne.

Skąd aplikacje pogodowe biorą dane do prognozy?

Prognozy w aplikacjach są pochodną dużych systemów numerycznych, które jako wejście dostają rzeczywiste pomiary z wielu źródeł. To m.in. stacje naziemne (temperatura, wilgotność, ciśnienie, wiatr, opad), radary meteorologiczne (strukturę i intensywność opadu), sondowania balonowe (profil atmosfery w pionie), boje oceaniczne i sensory na statkach, a także dane z samolotów pasażerskich.

Drugim filarem są satelity meteorologiczne – geostacjonarne i polarne. Nie mierzą one „pogody” wprost, tylko promieniowanie (radiancje) w różnych kanałach widma. Z tych sygnałów systemy naziemne odtwarzają m.in. rozkład chmur, pary wodnej i temperatury powierzchni. Wszystkie te dane są łączone i filtrowane w procesie zwanym asymilacją danych, który buduje spójny trójwymiarowy obraz stanu atmosfery, od którego startuje model.

Co to znaczy, że prognoza w aplikacji jest „interpolowana z siatki modelu”?

Model numeryczny liczy atmosferę na dyskretnej siatce punktów, np. co 2,5 km lub co 10 km w poziomie, i na wielu poziomach w pionie. Nie zna więc warunków „dokładnie na twoim balkonie”, tylko w najbliższym punkcie siatki. Interpolacja to matematyczne przeliczenie wartości z tych węzłów siatki na konkretny punkt, który wybierasz w aplikacji (np. środek miasta czy współrzędne GPS telefonu).

W praktyce aplikacja bierze kilka najbliższych punktów z modelu i na ich podstawie szacuje temperaturę, wiatr czy opad dla zadanej lokalizacji. Potem często dodaje lokalne poprawki, np. inne korekty dla centrum miasta i inny schemat dla terenów górskich, bazując na historii błędów modelu w danym miejscu.

Co to jest postprocessing prognozy i po co się go robi?

Postprocessing to etap „po modelu”, w którym surowe wyniki z superkomputera są dopasowywane do rzeczywistości i do potrzeb użytkownika. Obejmuje m.in. korekcje statystyczne (modelowana temperatura vs. temperatura faktycznie mierzona na stacjach), usuwanie systematycznych błędów (np. zbyt chłodne noce w dolinach) oraz przeliczenie pola modelowego na prognozy punktowe i godzinowe.

Na tym etapie powstają też produkty „użytkowe”: odczuwalna temperatura, indeksy burzowe, mapy opadu w formie czytelnych animacji, a także proste ikonki w aplikacjach. Bez postprocessingu dostałbyś zestaw surowych pól numerycznych, które są mało intuicyjne nawet dla meteorologa, a co dopiero dla przeciętnego użytkownika.

Jaką rolę w prognozach odgrywają radary i satelity meteorologiczne?

Radary dostarczają bardzo szczegółowego obrazu opadu i burz w czasie niemal rzeczywistym. Mierzą odbiciowość sygnału mikrofalowego, z której wylicza się intensywność deszczu czy śniegu, a także lokalizację i ruch komórek burzowych. Są kluczowe dla prognoz bardzo krótkoterminowych (tzw. nowcasting), np. czy za godzinę nadciągnie ulewa nad konkretne miasto.

Satelity z kolei dają szeroki, globalny obraz: strukturę chmur, frontów, układów niżowych i wyżowych, a także rozkład pary wodnej w troposferze. Dzięki nim modele lepiej „widzą” atmosferę nad oceanami i słabo monitorowanymi regionami. Dane radarowe i satelitarne są intensywnie używane w asymilacji danych, a część aplikacji pokazuje je także bezpośrednio w formie map opadu lub zachmurzenia.

Dlaczego aplikacja pokazuje deszcz, a za oknem jest sucho (albo odwrotnie)?

Opad w modelu jest wynikiem całego łańcucha obliczeń: od wilgotności i ruchów wznoszących powietrza, przez parametryzację chmur (uproszczone „przepisy” na procesy w chmurze), po postprocessing, który przekłada to na konkretną wartość mm/h i ikonę w aplikacji. Na każdym etapie mogą pojawić się niedokładności – np. model nie złapie małej, lokalnej burzy albo przeszacuje rozwój chmur konwekcyjnych.

Dodatkowo prognozy opadów są silnie zależne od rozdzielczości modelu. Jeżeli siatka ma np. 10 km, to pojedyncza komórka burzowa o średnicy kilku kilometrów może być w modelu „rozmyta” albo w ogóle nie trafić dokładnie nad twoją ulicę, choć w pobliżu pada. Tip: jeśli zależy ci na deszczu „tu i teraz”, patrz nie tylko na ikonki, ale też na radar opadów – tam widać realny ruch chmur.

Czy dane ze stacji amatorskich (domowych) poprawiają prognozy w aplikacjach?

Sieci stacji domowych (np. Netatmo, Davis) potrafią bardzo zagęścić pomiary, zwłaszcza w miastach. Problem w tym, że te dane są zwykle „brudne”: różna jakość sensorów, złe miejsce montażu (nad betonowym dachem, przy ścianie, bez osłony), błędna lokalizacja GPS. Dlatego w systemach numerycznych używa się ich ostrożnie, po silnym filtrowaniu jakościowym i z niską wagą w porównaniu ze stacjami zawodowymi.

Niektóre aplikacje korzystają z takich sieci głównie do pokazywania bieżących warunków „z sąsiedztwa” i do lokalnych korekt temperatury. Trzeba jednak pamiętać, że pojedyncza amatorska stacja może kłamać o kilka stopni, jeśli jest źle zamontowana – dlatego ważniejszy jest obraz z wielu stacji w okolicy niż pojedynczy pomiar.

Opracowano na podstawie

• Numerical Weather and Climate Prediction. Cambridge University Press (2010) – Podstawy modeli numerycznych, równania, siatki, parametryzacje
• Data Assimilation: Making Sense of Observations. Springer (2007) – Metody asymilacji danych obserwacyjnych w modelach NWP
• Guide to Meteorological Instruments and Methods of Observation (WMO-No. 8). World Meteorological Organization (2018) – Standardy pomiarów na stacjach naziemnych i aerologicznych
• The Use of Satellite Data in Weather Prediction. EUMETSAT – Rola radiancji satelitarnych i produktów pochodnych w prognozie
• Radar Meteorology: A First Course. Wiley-Blackwell (2010) – Zasady działania radarów, odbiciowość, szacowanie opadów
• Global Data Assimilation and Prediction System Documentation. NOAA National Weather Service – Opis operacyjnych systemów NWP i asymilacji danych
• ECMWF Forecast User Guide. European Centre for Medium-Range Weather Forecasts – Opis globalnych prognoz, rozdzielczości, produktów punktowych
• High-Resolution Numerical Weather Prediction: Techniques and Applications. Royal Meteorological Society – Downscaling, modele mezoskalowe, prognozy lokalne