Bris på eX3: miljøet står, dataene mangler

Målet for dagen var enkelt: få én Bris-prognose ut av MET sitt publiserte sjekkpunkt, kjørt på Simula sin eX3-klynge. Det målet ble ikke nådd, men alt som ligger foran datasteget er nå verifisert, og underveis dukket det opp flere ting som endrer planen.

Tilgang

Jeg har fått tilgang til eX3, og satt det opp for tilgang både on prem, men også hvor enn ellers jeg befinner meg.

Miljø

To ting måtte løses før miljøet lot seg bygge.

eX3 gjør TLS-inspeksjon: utgående HTTPS signeres på nytt av en lokal CA som ligger i systemets sertifikatlager. curl og git fungerer derfor, mens verktøy som har med seg sine egne rotsertifikater feiler. uv bruker webpki og stoppet på invalid peer certificate: UnknownIssuer. Løsningen er å peke uv, requests og curl mot systemets sertifikatpakke — altså å stole på det maskinen allerede stoler på, ikke å slå av verifisering.

I tillegg peker låsefilen fra MET på inferenspakken over SSH:

bris = { git = "ssh://git@github.com/metno/bris-inference.git", rev = "d1d27c1..." }

Det krever en GitHub-SSH-nøkkel på beregningsnoden. Siden repoet er offentlig, kan transporten skrives om til HTTPS med insteadOf. Da står URL-strengen i uv.lock urørt, og --locked validerer fortsatt.

Etter dette bygger miljøet, og sjekkpunktet laster.

Hva sjekkpunktet faktisk sier

Anemoi lagrer variabellisten og indeksgruppene i selve sjekkpunktet. Det er den autoritative kilden — YAML-filene sier bare hva MET tilfeldigvis kjørte med.

Tre tall som er lette å blande sammen: 89 felter må ligge i datasettet, 95 går inn i modellen (89 minus de tre diagnostiske, pluss ni forcings som regnes ut ved innlasting), og 87 kommer ut. Tallet 87, som har vært brukt i notatene mine, er altså outputtallet.

multistep_input er 2. Én prognose trenger to påfølgende analysetidspunkt, t-6t og t0, på begge sider av rutenettet. Det er et korrekthetskrav, ikke en detalj: én tilstand vil enten feile eller stille produsere et ubrukelig første steg.

Nedbør er en diagnostisk variabel

Dette er det mest interessante funnet for oppgaven. tp predikeres, men mates aldri tilbake inn i modellens tilstand. Et tail-aware twCRPS-ledd på nedbør virker dermed på et diagnostisk hode, med en kortere og mer isolert gradientvei enn en prognostisk variabel ville hatt.

Det er verdt å vite før tapsfunksjonen designes, og det taler for at en finjustering begrenset til dekoderen er en fornuftig avgrensning.

Hvorfor 600 hPa mangler

Treningskonfigurasjonen dropper u/v/w/q/z/t på 600 hPa uten forklaring. HourGlass-artikkelen (Ingstad et al., arXiv:2607.11457) oppgir grunnen i forbifarten, når de forklarer hvorfor Bris-HourGlass ikke kunne finjusteres fra den globale modellen: MEPS har ikke variablene på 600 hPa. Mangelen er arkivmessig, ikke et modelleringsvalg, og ethvert MEPS-datasett bygget her vil arve den.

Problemet: datasettene finnes ikke

Ingen av de to artiklene har en data availability-erklæring. HourGlass publiserer kun kode. Det finnes ingen anemoi-formaterte zarr-datasett å laste ned:

• ingen met-no-datasett på Hugging Face
• ECMWFs objektlager svarer 403
• data.met.no publiserer MEPS som GRIB/NetCDF, ikke anemoi-format

Steget er altså å bygge datasett, ikke å laste dem ned.

Det gode er at omfanget er langt mindre enn det høres ut som. Inferens trenger initialbetingelser, ikke treningsarkivet: to tilstander, 89 felter, omtrent 1,1 GB til sammen. Treningsarkivet er på TB-skala. Forskjellen er fire år mot to tidspunkt.

Det som gjenstår

Rutenettet må stemme eksakt — men det er nå løst. switch_graph er null, så modellen bruker grafen som ligger i sjekkpunktet, med faste nodeposisjoner. Det samme forholdet som gjør dette til en hard begrensning, løser det også: en Anemoi-graf bærer eksplisitte lat/lon-koordinater for hver node, så definisjonen lå allerede i filen jeg hadde lastet ned.

Utlest og delt opp gir det:

MEPS-domenet etter trim_edge: 50 spenner 51,119–74,131 °N og 13,150 °V–49,418 °Ø. Utstrekningen før trimming er dermed 949 × 1069, som er nøyaktig det CRPSFFTLoss antydet. De 5 480 globale punktene som forsvinner under LAM-en stemmer med de ~5 350 man venter av fotavtrykket mot en 31 km-celle — overskuddet er det et krumt Lambert-domene skjærer ut av et gaussisk rutenett.

Ingen av dette måtte spørres om.

Hvor kommer normaliseringsstatistikken fra? Avklart, og svaret er sjekkpunktet. Normaliseringen går gjennom self.model.pre_processors, og modellen settes til checkpoint.model — så prosessorene, med treningsstatistikken i seg, kommer fra vektene. Utenfor legacy-modulen finnes ikke én referanse til statistics i bris-inference.

Det betyr at statistikk regnet over to tilstander er ufarlig: anemoi-datasets skriver den inn i zarr-en, men ingenting ved inferens leser den. Dette var den ene identifiserte feilmodusen som ville fullført tilsynelatende vellykket og likevel skrevet fysisk gale felter. Den gjelder ikke.

Den gjelder derimot fortsatt for trening. Finjustering går gjennom anemoi-training, som er en annen kodesti og som faktisk leser datasettets statistikk.

Hvor mange GPU-er trengs egentlig? Konfigurasjonen fra MET ber om num_gpus_per_model: 4 og num_members: 2, altså åtte kort — nøyaktig én hgx2q-node. Det er tallene de kjørte med på Leonardos 64 GB-kort under trening. Om modellen lar seg kjøre usharded på ett kort ved inferens er uprøvd.

ERA5 som erstatning for operasjonell analyse. Den atmosfæriske N320-komponenten MET brukte er MARS-klasse od, som jeg ikke har tilgang til. Planen er å bruke offentlig ERA5 i stedet. Samme rutenett og samme variabler, men modellen er trent på od, så det er et distribusjonsskifte. Godt nok til å avgjøre om modellen kjører og gir fysiske felter — ikke godt nok til å oppgi et verifikasjonsresultat.

Neste steg

Rutenettet er lest ut, så neste steg er MEPS-oppskriften mot det offentlige arkivet på thredds.met.no. Koordinatene fra sjekkpunktet er fasiten å validere mot — nodeekkefølgen inkludert, siden det er den modellen indekseres på.

MET er fortsatt verdt å kontakte, men for spørsmålet som ikke lar seg lese ut av filene: om ERA5 er en akseptabel erstatning for od, og om de vil dele datasettene direkte. Ikke for rutenettet.