Slik hentet jeg tre år med treningsdata

Finjustering av Bris trenger data i det formatet modellen ble trent på. Det er ikke én fil man laster ned, men to halvdeler fra to helt ulike arkiver, satt sammen til ett felt. Denne uka hentet jeg tre år av begge. Dette er oppskriften, inkludert de fire feilene som kostet til sammen over tjue timer, fordi de er den mest nyttige delen.

Alt under kjører på eX3, en delt klynge med Slurm. Skriptene ligger i extreme-bris.

Hva som faktisk trengs

Bris er en strukket-gitter-modell. Hver tilstand er ett felt på 1 359 281 punkter, satt sammen av to kilder:

De to hentes hver for seg og føyes sammen med cutout i anemoi. Du trenger begge. Har du bare den ene, har du ingenting å finjustere på, uansett hvor komplett den er.

Steg 1: les sjekkpunktet, ikke dokumentasjonen

Det første jeg gjorde galt tidligere i prosjektet var å gjette variabellisten. Sjekkpunktet vet det selv:

python scripts/inspect_checkpoint.py $BRIS_CKPT -o ~/bris-runs/ckpt-metadata.json

Den gir oppløsning, tidssteg, variabler, trykknivåer og navnene på datasettene modellen ble trent på. Alt nedstrøms utledes av den filen. Skriver du variabellisten for hånd, får du et datasett som laster fint og som modellen avviser.

Steg 2: generer oppskrifter

anemoi bygger datasett fra en YAML-oppskrift. To skript lager dem:

• scripts/make_era5_recipe.py lager den globale oppskriften ut fra sjekkpunktets metadata. Til tross for navnet tar den --source od for operasjonell analyse.
• scripts/make_year_recipes.py deler perioden i tre årsbiter og skriver seks oppskrifter, en MEPS og en global per år.

python scripts/make_year_recipes.py \
    --missing ~/bris-runs/recipes/missing-year1.txt \
    --missing ~/bris-runs/recipes/missing-year2.txt \
    --missing ~/bris-runs/recipes/missing-year3.txt \
    -o ~/bris-runs/recipes

Årsbitene er ikke kosmetiske. En feil koster én bit i stedet for alt, framdriften blir synlig, og det nyeste året lander først. anemoi åpner flere zarr-er som ett datasett med concat, så oppdelingen koster ingenting ved trening.

Nyeste år er bevisst først. Fra rundt mai 2025 har MEPS-arkivet alle åtte daglige sykluser; før det er det tynnet til 00, 06, 12 og 18. Bare i det utynnede vinduet kan treningspar bygges med tre timers forskyvning, som dobler antall eksempler nettopp der oversampling trenger å finne ekstremer.

Steg 3: finn hullene før byggingen går på dem

Dette steget fantes ikke da jeg begynte, og det er det jeg ville lagt til først om jeg gjorde det på nytt.

En årsbygging bruker fem timer på henting og dør så på én manglende syklus. Verre er dagene som svarer, men svarer kort: 31. januar 2026 serverer trykknivåfiler med seks nivåer der alle andre dager har tretten. Den dagen lastet, skrev NaN, og bestod enhver strukturell sjekk.

srun -p defq -n1 -c4 -t 60 python scripts/scan_meps_archive.py \
    --start 2025-09-08T00:00:00 --end 2026-09-06T18:00:00 \
    -o ~/bris-runs/recipes/missing-year1.txt

Skriptet henter én katalogside per dag, så én liten header per trykknivåfil, og skriver ut datoene som mangler eller er for tynne. Resultatet for tre år:

Datoene føres inn i oppskriftens missing-blokk. Da registrerer anemoi dem som manglende i stedet for å dø på den ene og stille nulle den andre.

Kjør skanningen fra en beregningsnode. Login-noden står bak en TLS-avlyttende proxy som Python ikke stoler på, mens curl gjør det, så en skanning derfra ser ut til å virke og gir feil svar.

Én advarsel om hvordan et slikt skript skal skrives. Min første versjon returnerte «borte» for enhver forespørsel som ikke gikk gjennom. Da den traff proxyen, erklærte den alle 1456 tilstander manglende og skrev en fil som ville tømt hele oppskriften. En utilgjengelig tjener er ikke et tomt arkiv. Alt som ikke er en ren 200 eller en ren 404 telles nå for seg og hindrer at listen skrives.

Steg 4: bygg som en Slurm-jobb

sbatch --export=ALL,RECIPE=$HOME/bris-runs/recipes/meps-year1.yaml,\
OUT=$HOME/bris-data/meps-2p5km-year1-6h-v1.zarr,THREADS=4 \
    bris/slurm/build_dataset.sbatch

Jobbskriptet gjør fire ting utover å kalle anemoi.

Det legger mellomlageret på hjemmeområdet. earthkit skriver hvert hentede felt til en temp-katalog og rydder aldri. På en beregningsnode er det en lokal partisjon på 40 GB. Et års global analyse trenger rundt 75. Den første MARS-byggingen døde på No space left on device etter fem timer.

Det beholder mellomlageret mellom kjøringer. earthkits standardpolicy er off, altså fersk temp-katalog per kjøring, så hver feil kaster alt som er hentet. Med user og en fast sti overlever det. Da jeg måtte kjøre år 1 på nytt, leste den de åtte ferdige månedene fra disk: fire av tretten grupper på femten minutter, mot tre timer og et kvarter over nett.

Det bruker tråder, ikke prosesser. Kostnaden er nesten utelukkende venting. Hver MEPS-tilstand åpner én aggregering som beskriver 67 underliggende filer, og å tolke den er dyrere enn å overføre tallene. Tråder slipper GIL-en under nettverks-I/O. Hold antallet lavt: thredds er en delt offentlig tjeneste.

Det måler hvor mye av resultatet som er tall. Dette er den viktigste linjen i hele skriptet:

=== declared missing: 6
=== with data: 1450 of 1450
=== OK

Et datasett med riktig form, riktige datoer og riktig variabelantall kan være fullstendig NaN. Det skjedde, kjørte en prognose til COMPLETED, og skrev 350 MB med ingenting. Rapporter aldri en bygging som brukbar uten å måle hvor stor andel som er et endelig tall. Sier siste linje NOT USABLE, er datasettet tomt uansett hva Slurm mener.

Framdrift underveis:

bash scripts/build_progress.sh

Det leser anemois egne ferdigflagg, ett per månedsgruppe. Ikke stol på framdriftslinjen i loggen: den starter på nytt for hver gruppe, og med fire tråder viser fronten den arbeideren som ligger lengst framme. Fire minutter inn leste den desember og meldte jobben 23 prosent ferdig. Ingenting var bygget.

Steg 5: kontroller uavhengig

Jobbens egen port er nødvendig og ikke tilstrekkelig. Etter hver bygging leser jeg noen faktiske tall:

z = zarr.open(path, mode="r")
i = {str(x)[:16]: n for n, x in enumerate(z["dates"][:])}
t2 = list(z.attrs["variables"]).index("2t")
for lab in ["2026-01-15T12:00", "2026-07-15T12:00"]:
    a = np.asarray(z["data"][i[lab], t2, 0, ::50], dtype="float64")
    print(lab, np.nanmean(a), np.isfinite(a).mean())

Årstidskontrasten skal være der: rundt 272 K i januar og 290 K i juli. De erklærte hullene skal være NaN, og nabotilstandene på hver side skal være ekte tall. Det siste er poenget. Da januargruppen feilet, var hele måneden tom, ikke bare den ene dårlige dagen.

De fire feilene, og hva de lærte meg

Patcher i to filer. anemoi-datasets 0.5.24 trenger fem kjøretidsrettelser. De lå fordelt på to wrappere, og hvilke du fikk avhang av hvilken som kjørte. Slurm-jobben kalte den som manglet nettopp akkumulasjonsrettelsen, og ti minutters MARS-henting gikk tapt fordi fiksen fantes i feil fil. Alle fem ligger nå i scripts/anemoi_patches.py, anvendt av begge.

Disken. Beskrevet over. Symptomet kom etter fem timer, årsaken var synlig fra første minutt om noen hadde sett etter.

Én dårlig dag koster hele måneden. anemoi bygger en månedsgruppe som én enhet. De fire sykluser 31. januar med for få trykknivåer nullet alle 124 januartilstandene. Å erklære dem manglende reddet de 120 andre.

En strøm som ble lagt ned. Den dyreste. En ti timers MARS-bygging døde på Expected 90, got 33 for mai 2026. Det ser ut som manglende data, og den nærliggende reaksjonen er å erklære måneden manglende. Det ville vært galt. ECMWF la ned scda-strømmen 12. mai 2026, og 06Z- og 18Z-syklusene flyttet inn i oper. anemoi vet det ikke og sender fortsatt alle slike forespørsler til scda.

Jeg sonderte MARS for å finne grensen, én forespørsel per strøm og måned med expect: any og et område på ett rutepunkt, som holder overføringen på kilobyte:

De to strømmene møtes eksakt. Å erklære fire måneder manglende ville kastet ekte data for et navnebytte. Rettelsen velger strøm etter dato, og datoen ligger i scripts/check_scda_stream.py som en kjørbar sjekk med ni testtilfeller på begge sider av grensen. En dato er nettopp den slags konstant som blir avrundet bort av noen som ikke vet at den er målt.

Hva det kostet

Til sammen 756 GB og 4 281 brukbare tilstander for den lokale halvdelen. Den globale blir rundt 152 GB per år. Hele grunnlaget lander på i overkant av 1,2 TB.

MARS er tregere enn thredds og styres av ECMWFs kø, ikke av maskinen din. Hver månedsgruppe brukte mellom 30 og 78 minutter, nesten alt venting. Regn med et døgn per år.

Hva som kom ut av det

Alt over handler om å få dataene ned og verifisert. Hva de faktisk inneholder, og hvordan man avgjør statistisk hvilke døgn som teller som ekstremvær, står i Hva teller som ekstremvær. Det innlegget avdekker også en feil i akkurat de datasettene denne guiden beskriver hvordan man bygger.

Det korteste rådet

Om du bare tar med deg én ting: mål hvor stor andel av datasettet som er et endelig tall, og la byggingen feile høyt hvis den ikke er det. Alle de dyreste feilene i denne uka hadde samme form. Noe var tomt, alt annet så riktig ut, og bare et tall kunne skille dem.