Differences

This shows you the differences between two versions of the page.

--- kvalobs:kvalobs:qabase [2010-09-23 08:49:20]
vegardb
+++ — (current)
@@ Line 1: / Line 1: @@
-====== qabase ======
-Dette er dokumentasjon for den nye versjonen av qabase, som ikke er i drift enda.
-qbase 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.
-Akkurat nå går det en testversjon av qabase på dev-vm185. For å få tilgang til den: Se på [[http://dev-vm185|denne siden]]
-===== Forskjeller mellom gamle og nye qabase =====
-En liste over alle kjente forskjeller mellom gamle og nye qabase finner du [[kvalobs:qabase:forskjeller_gammel_ny|her]].
-===== Valg av hvilke sjekker som skal kjøres =====
-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, gjøres ingenting.
-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.
-  * Det vil ikke bli forsøkt å kjøre sjekker som krever parametre som observasjonen, i følge obs_pgm-tabellen, ikke skal rapportere. Et unntak fra denne reglen er stasjoner med stationid>10000000 (som er skip). For disse vil man forsøke å kjøre alle sjekker.
-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.
-===== Valg av data for sjekkene =====
-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//.
-===== Valg av spesifikke level/sensor/typeid =====
-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.
-===== Inndata til skript =====
-Selve skriptene hentes fra tabellen //algorithms// i kvalobs-databasen. Disse skriptene er ikke komplette. De må fylles med data fra observasjoner, metadata og modelldata.
-==== Abstrakt signatur ====
-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:
-<code>obs;X,Y;;-120|meta;R1,R2;;</code>
-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.
-==== Konkret signatur ====
-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:
-<code>obs;UN;;0,-120|meta;UN_max;;</code>
-==== Tilgjengelige variabler i skriptene ====
-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;;'':
-<code># general
-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);</code>
-Alle skript begynner med 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 kvalobs:kvalobs-flagg#manglende_observasjon_missing|flaggdokumentet]]
-  * **X_controlinfo** oppgir flagg fra tidligere sjekker. Hvert tidsskritt består av 16 verdier, og er dokumentert i [[kvalobs:kvalobs-flagg|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.
-===== Returverdier fra skriptene =====
-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.
-===== Skriving av resultater til databasen =====
-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.
-===== Logging =====
-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:
-<code>
-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.
-</code>
-Til slutt kommer en oppsummering av hvilken data som blir lagt tilbake til kvalobs.
-[[kvalobs:qabase-log-example|Her]] er et eksempel på en slik logg.