qabase

qbase er ansvarlig for å kjøre alle sjekkene på observasjoner. Programmet kan startes for å kontrollere en enkel observasjon, eller kjøres som en demon.

Hvis du ønsker å kjøre qabase for å kontrollere en enkel observasjon, kan du kjøre qabase –help for å finne ut av detaljene. Dette dokumentet handler kun om hvordan qabase oppfører seg når en observasjon skal sjekkes.

En liste over alle kjente forskjeller mellom gamle og nye qabase finner du her.

Når en observasjon kommer inn til kvalobs, begynner qabase å se på denne. Følgende kriterier bestemmer om dataene skal sjekkes, og eventuelt hvilke sjekker som skal kjøres:

• Hvis observasjonen er del av en aggegert verdi (med typeid<0) gjøres ingenting.
• Hvis noe av dataen i observasjonen er HQC-korrigert (fhqc>0), gjøres ingenting.
• Hvis stasjonen ikke er med i obs_pgm, gjøres ingenting. Unntak: hvis stationid>10000000 (som er skip) og stasjonen er i stasjonstabellen vil man forsøke å kjøre alle sjekker.

I utgangspunktet kjøres alle sjekker som er definert i checks-tabellen med stasjonsid=observasjonens stasjon, eller stasjonsid=0. Det er imidlertid visse sjekker som lukes ut:

• checks-tabellen i kvalobs har en active-kolonne, formattert som en cron-string. Kun sjekker med active-string som passer til den gitte observasjonstiden vil bli kjørt.

I tillegg til dette fins en spesialregel, som jeg ønsker å fjerne etter at sjekkskriptene har blitt oppdatert:

• Sjekker som krever modelldata vil ikke kjøres dersom modelldata mangler i databasen.

Denne spesialregelen eksisterer fordi sjekkene som bruker modellverdi ikke sjekker om modellverdiene faktisk eksisterer. Man risikerer derfor å forkaste verdier fordi observasjonen ligger langt unna -32767.

Data som hentes til sjekkene velges utfra kolonnen original i data-tabellen. Den eneste måten å få informasjon om tilstanden til korrigert-verdien er ved å inspisere den medfølgende X_missing-variabelen. Denne gir dataens flaggverdi for fmis.

Alle skriptene har også en variabel som heter obs_missing. Denne inneholder antallet observasjoner i skriptet som mangler originalverdi.

Grunnlagsdata for sjekkene velges i utgangspunktet med den laveste level og sensor som er tilgjengelig for hver parameter. Dersom man ønsker å sjekke andre level eller sensorer, må man eksplisitt oppgi dette i sjekksignaturen i checks-tabellen.

Den typeid som tilhører observasjonen som sjekkes vil foretrekkes når man velger data for sjekkene. Hvis den etterspurte dataen ikke fins til denne typeid, vil data med høyest typeid velges til sjekkene. Også her kan sjekksignaturen overstyre hvilken typeid man vil ha for en parameter.

Før alle sjekkene kjøres nullstilles de fleste kontrollflaggene til den observasjonen som skal sjekkes. Unntaket fra dette er fmis (PS: og fd ser det ut som), som beholdes intakt. I tillegg vil fpre bevares, dersom den har verdien 7.

Selve skriptene hentes fra tabellen algorithms i kvalobs-databasen. Disse skriptene er ikke komplette. De må fylles med data fra observasjoner, metadata og modelldata.

Spesifikasjonen for hva slags data hvert skript trenger fins i signature-feltet i tabellen algorithms. Dette er en tekststreng, formatert for å maskinleses. Strengen består av opptil fire seksjoner - en for hver type data et skript kan trenge. De fire seksjonene er:

• obs - observasjonsparamete, som skal kontrolleres. Data herfra hentes dra data-tabellen.
• refobs - Data som ikke kan representeres som tall. Skal ikke kontrolleres direkte. Data herfra hentes fra tabellen text_data.
• model - Modelldata. Hentet fra tabellen model.
• meta - metadata til sjekker - for eksempel grenseverdier. Hentet fra tabellen station_param.

Signaturen til an algoritme er bygd opp av en eller flere av disse seksjonene, og hver seksjon er skilt med tegnet '|'. Hver seksjon består igjen av opptil fire subseksjoner, som følger:

• Seksjonsidentifikator - en av de fire seksjonene nevnt over.
• Abstrakt parameternavn - navnet på en eller flere parametre, som refereres i sjekkskriptet.
• Ekstra stasjoner - foreløpig ikke i bruk.
• Tidsinterval - et mål på hvor langt bak i tid man trenger data for. I minutt.

Hver av de fire subseksjonene skilles med et semikolon (;).

En abstrakt signatur kan for eksempel se slik ut:

obs;X,Y;;-120|meta;R1,R2;;

Dette betyr at det medfølgende skriptet trenger tilgang til to parametre, kalt X og Y, for to timer bak i tid. I tillegg trenger de metadata, som i skriptet kalles R1 og R2.

I tillegg til en abstrakt signatur trengs en konkret signatur. Disse fins i tabellen checks, og angir nøyaktig hvilke data et skript skal fylles med.

Den konkrete signaturen har samme syntaks som den abstrakte, med unntak av spesifikasjonen av parameternavn. Hvert parameternavn må referere til en parameter i tabellen param. I tillegg kan spesifikke typeid, sensor og levels spesifiseres her.Dette gjøres ved å skille disse fra hverandre vha. ampersand (&). For eksempel kan et krav om temperatur i ti meters høyde med sensor 1 og typeid 111 spesifiseres på denn måten: TA&10&1&111.

En komplett konkret signatur kan for eksempel se slik ut:

obs;UN;;0,-120|meta;UN_max;;

Basert på signaturen, vil data genereres for hvert skript. Det vil ikke ha noen effekt å endre denne dataen. Se lengre ned i dette dokumentet for hvordan man kommuniserer resultater av sjekkene.

Her er et eksempel på definerte variabler i et skript, bygd opp av den abstrakte signaturen obs;X;;|meta;X_1,X_2,X_3,X_4,X_5,X_6;;, og den konkrete signaturen obs;AA;;|meta;AA_max,AA_highest,AA_high,AA_low,AA_lowest,AA_min;;:

# general
my $station_latitude = 64.4014;
my $station_longitude = 10.455;
my @obstime = (2010, 9, 23, 6, 0, 0);

# obs
my $obs_missing = 0;
my $obs_numtimes = 1;
my @X = (6);
my @X_controlinfo = (0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0);
my @X_missing = (0);
my @obs_timeoffset = (0);

# meta
my $meta_missing = 0;
my $meta_numtimes = 1;
my @X_1 = (9);
my @X_2 = (8);
my @X_3 = (8);
my @X_4 = (0);
my @X_5 = (0);
my @X_6 = (0);
my @meta_timeoffset = (0);

Alle skript begynner med lengde- og breddegrad for stasjonen. I tillegg fins alltid obstime - en liste bestående av observasjonens år, måned, dag, time, minutt og sekund.

Resten av parametrene er generert på grunnlag signaturen og dataen i databasen.

• obs_missing er antallet manglede observasjoner i listen
• obs_numtimes er antall tidsskirtt vi har data for
• obs_timeoffset lister opp alle tidsskrittene, med avvik fra observasjonsterminen.
• X er verdien til den rapporterte dataen, som i dette tilfellet er AA (Barografkurvens forløp). Den ligger i en liste, slik at flere tidsskritt kan ligge her
• X_missing er en oppsummering av manglende-status for hver verdi. Se fmis i flaggdokumentet
• X_controlinfo oppgir flagg fra tidligere sjekker. Hvert tidsskritt består av 16 verdier, og er dokumentert i flaggdokumentet. Ved flere tidsskritt vil flaggene legges etter hverandre, uten noe skille mellom dem

En tilsvarende oppdeling gjelder for meta, men her mangler flagg og manglende-status.

Det fins tre typer returverdier fra skriptene:

• corrected
• flag
• missing

Hvis missing settes til 2 eller 3, gir dette en implisitt endring av corrected til -32766 eller -32767.

Den gamle returverdien subcheck er fjernet, siden det ikke er noen sjekker som bruker den.

Returverdiene returneres som en liste, som fylles med par, først en parameteridentifikator, beskrevet under, og deretter en ny verdi.

Parameteridentifikatoren angir nøyaktig hva som skal ha en ny verdi. Den kan for eksempel se slik ut: X_1_0_flag. Dette betyr at parameteren X i for tidsskritt indeks 1 har fått tildelt et flagg, angitt i neste element i returlista. Det siste tallet i identifikatoren (0) gjelder stasjon og brukes ikke, men er fremdeles med av historiske årsaker.

Når en sjekk gjør endringer i data (flagg eller verdi), skrives ikke dette umiddelbart til databasen. Endringene vil først bli synlige for omverdenen etter at alle sjekker for en observasjon har kjørt.

Det fins to typer logger fra qabase. En fra selve programmet, for bruk av utviklere, samt en type logger for hver observasjon.

Hver observasjon som sjekkes får en egen loggfil, i tekst-format (ikke html). Disse blir lagt i en katalogstruktur som følger: LOGDIR/STASJON/DATO/log-TID.TYPEID.log

Innholdet i disse loggene er som data for hver sjekk som har kjørt, listet fortløpende. Formatet er som følger:

Sjekknavn
Abstrakt signatur fra algorithm-tabellen i kvalobs-databasen
Konkret signatur fra checks-tabellen i kvalobs-databasen
Hele sjekkskriptet
Resultatet av sjekken - først returverdiene som sjekken spesifiserte dem, så en oppsummering av kvalobs-dataen.

Til slutt kommer en oppsummering av hvilken data som blir lagt tilbake til kvalobs.

Her er et eksempel på en slik logg.