Hva teller som ekstremvær

For å finjustere Bris på ekstremer må jeg først kunne peke på hvilke tilstander som er ekstreme. Det høres trivielt ut og er det ikke. Oversampling må trekke dem oftere enn deres naturlige frekvens, og en terskelvektet skår må få vite hvor tersklene ligger. Begge trenger et etterprøvbart svar, ikke en håndplukket liste over døgn jeg husker.

Dette innlegget er metoden, og feilen den fant i datasettene den skulle måle.

Tre mål, fordi ingen av dem alene er riktig

Skriptet regner ut tre tall for hver tilstand.

Andel punkter over sin egen persentil. For hvert gitterpunkt regnes en klimatologisk 99-persentil over de tilstandene der punktet faktisk fikk nedbør. En tilstand får så andelen av punkter som ligger over sin egen terskel. Dette finner utbredt, regionalt uvanlig nedbør.

Maksimum. Det våteste punktet i hele feltet. Dette finner intense, lokale hendelser som et arealsnitt skjuler fullstendig.

Areal over en absolutt terskel. Andelen av området over 10, 20, 30 eller 50 millimeter. Dette er målet som kobles rett på en twCRPS-terskel, siden det er samme størrelse skåren vektes på.

Persentilene regnes per gitterpunkt, ikke som ett tall for hele feltet. Vestlandet får flere ganger så mye nedbør som innlandet. Én absolutt terskel ville valgt Vestlandet om høsten hver eneste gang og kalt det et funn. Å spørre om dette punktet har en uvanlig dag er den samme logikken som stasjonsarbeidet bruker på målerne.

Persentilen regnes dessuten bare over tilstander der punktet var vått. De fleste seks-timers perioder er tørre de fleste steder, så en persentil over alt er dominert av nuller og sier ingenting.

Hva rangeringen ser ut som

Under er det scripts/find_extreme_states.py produserer for den globale halvdelen av år 1: kraftigste seks-timers nedbør i noe gitterpunkt, per døgn.

Merk hva dette diagrammet ikke viser. Det er den globale halvdelen, og et sted på kloden regner det alltid kraftig, så variasjonen er liten. Andelen punkter over egen persentil spenner bare 2,3 ganger fra laveste til høyeste døgn. På det nordiske MEPS-området, der ett værsystem kan dekke hele feltet, blir spredningen langt større. Det er nettopp derfor rangeringen må kjøres på MEPS.

Og det er der det stopper.

Datasettene har ingen nedbør

Skriptet nekter å rangere et felt som er identisk null. Den porten slo ut med en gang. Alle tre MEPS-datasettene, 756 GB til sammen, har null nedbør. Feltet finnes, er endelig overalt, og er null overalt. Det samme gjelder de to strålingsfeltene.

Årsaken er i oppskriften. MEPS-siden leser precipitation_amount_acc, som akkumulerer fra modellstart. Hver tilstand hentes som sin egen syklus sitt steg 0, og der er akkumulert nedbør null per definisjon.

Det er en direkte konsekvens av t0-rettelsen jeg gjorde forrige uke. Den sørget for at hver tilstand er en ekte analyse og ikke en seks timers prognose, og fikset temperaturens opphav. Samtidig garanterte den at alle akkumulasjonsfelt ble tomme. Jeg byttet én korrekthetsfeil mot en annen og målte bare den første.

Et datasett bygget før den rettelsen viser mekanismen direkte. Der er de to tilstandene steg 0 og steg 6 av samme kjøring:

Den globale halvdelen er derimot i orden. Den henter akkumulasjonene fra prognoser og differensierer dem, som er den riktige framgangsmåten, og har ekte nedbør opp til 170 millimeter.

Hvorfor ingen sjekk fanget det

Dette er den delen som er verdt å ta med seg videre.

Jeg har brukt uker på å bygge porter mot nettopp denne typen feil. Byggejobben måler hvor stor andel av hver tilstand som er et endelig tall og nekter å melde OK hvis noe er tomt. Den har fanget et helt NaN-datasett, en måned som ble nullet av én dårlig dag, og et forsøk som så ferdig ut og ikke var det.

Den fanget ikke dette, og grunnen er enkel: null er et endelig tall. Et felt av nuller har middel, maksimum og persentil, og alle er null. Det passerer enhver sjekk som spør om verdiene er tall.

Rådet jeg avsluttet forrige innlegg med var altså ikke strengt nok. Å måle at feltet inneholder tall er ikke nok. Man må måle at det inneholder vær.

Det er nå bygget inn: skriptet stopper med en egen returkode og en forklaring, ikke med en tom liste. En rangering av et nullfelt ville sett ut som en liste over helt ordinære dager, ikke som en feil, og det er den farligste formen en feil kan ta.

Hva som må skje før halen kan måles

MEPS-oppskriften må hente nedbøren som en faktisk seks-timers akkumulasjon. Feltet for en tilstand klokka T er akkumulert nedbør ved steg 6 fra syklusen som startet klokka T minus seks timer, ikke steg 0 fra syklusen som startet klokka T. Det er en annen fil og et annet steg enn analysefeltene, så det er en reell endring i oppskriften og ikke en justering.

De tre MEPS-årene må så bygges på nytt. Det er rundt tretten timer maskintid.

Enhetene må også avklares før halvdelene settes sammen. MEPS bærer nedbør i kilogram per kvadratmeter, altså millimeter, mens den globale siden bærer den i meter som resten av IFS. Skriptet gjetter enheten fra størrelsesorden og sier hva det gjettet, framfor å anta i stillhet. Det er en midlertidig løsning, ikke en god en.

Kjøre den selv

sbatch --export=ALL,DATASET=$BRIS_DATA_DIR/meps-2p5km-year1-6h-v1.zarr,\
OUT=$HOME/bris-runs/extremes/meps-year1.json \
    bris/slurm/find_extremes.sbatch

Jobben leser hele datasettet, siden hver tilstand er én komprimert blokk som inneholder alle 98 variablene og nedbør alene ikke kan hentes ut uten å pakke ut resten. Et år er rundt 257 GB lesing. Returkode 3 betyr at feltet er tomt for vær, og det er et resultat, ikke en krasj.