meteo

A leendő meteorológusok képzésük során számos alkalommal találkozhatnak műszerekkel, főleg a műszertanról szóló előadásokon a kivetítőn (meg a zh-kérdésekben), némileg ritkábban az ezek keretében szervezett állomás-látogatásokon. A legtöbben persze akkor szembesülnek csak igazán velük, amikor szakdolgozóként, vagy akár az egyetem után a munka keretében kell foglalkozniuk velük. Kevésbé népszerű Magyarországon az egyetemi képzésben kevésbé népszerű a mikrometeorológia, ahol talán a legkomolyabb műszertechnológia fejlődött ki, hiszen igen nagy az igény e téren a gyors válaszidejű (másodpercenként 10-20 mérést végző), és nagy pontosságú (század fok, század m/s, stb.) műszerek iránt. Felmerülhet azonban, hogy mik a legfontosabb meteorológiai műszerek e téren? Egy év kutatómunka után egyértelmű választ kaptunk a kérdésre: az ÓRA!!!

Történt egyszer, hogy egy mérési kampány során sok műszer sok adatot sokáig, és sokszor mért. Egész pontosan a 2015-ös Szegedi Határréteg-mérési Expedícióról van szó, ahol kb. két és fél hónapig mértünk egy nemzetközi kutatócsoport tagjaiként. A rengeteg műszer adatait több adatrögzítő rögzítette.

Sok kutatótársam között sokfelé lettek szétosztva a keletkezett adathalmazok. Én a BME által üzemeltetett CSAT3 (angol gyártmány) és a mi METEK-USA1 (amerikai - ki gondolná a nevéből) szenzorunk, utóbbi csak szelet és hőmérsékletet mért, előbbi sok mást is. A CSAT3 adatait CR3000 (ugyanattól a cégtől) adatgyűjtő rögzítette, míg utóbbit egy laptopon futó program. Ezek az adatrögzítők rögzítették az időpontokat. A két műszer kb. 15 méterre van egymástól nyugat-keleti irányban.

Ez eddig rendben...

Előbbi 2015.06.26-án 11:00:12,6-kor kezdett mérni (tizedmásodperc pontossággal, UTC-ben), és rögtön a 2877-dik adatot rögzítette. Hmm...

Utóbbi 2015.06.30-án 19:12:52-kor (ez nem rögzített sorszámot), de helyi idő szerint. Ugyanis hiába állították be, hogy UTC-ben, tized pontossággal írja ki az időpontokat, a gép egész pontosan és HLT-ben írta ki. Hmm...

Ezeket még nem lenne gond megoldani. A nagyobb baj, hogy az utóbbi esetben, bár a mérések tizedmásodpercenként zajlottak, a legritkább esetben volt pont 10 adat egy másodpercen belül. Gyakran 9, 11, de olykor akár 7, vagy 15 adat is került ugyanahhoz a másodperchez. Hmm...

Persze ekkor még azt gondoltuk, hogy ezek majd kiegyenlítik egymást, de kiderült, hogy az óránként kiírt fájlokban kivetel nélkül 36005, vagy 36006 darab adat van. Na ez már komoly problémát jelentett, a hiba azonban az volt, hogy első körben abban állapodtunk meg, hogy dobjuk ki ezeket a "lelógó" adatokat, és írjuk újra az órát "kézzel". Így helyrekerült az adatsor, a másikkal együtt futott, csak az észlelésekkel nem. Hmm...

Július 8-án este zivatarlánc érkezett, ezért villámvédelmi okokból éjfél után kikapcsoltuk az egész műszerparkot. Persze mikor néhányan a mobilnetes okostelós csúcstechnikán keresztül néztük éjfélkor a radaron, hogy a lánc végén megszűnt a keletkezés, és pont elmegy mellettünk, elfelejtettük nézni, hogyan lép be a fényszennyezésbe egy peremfelő, s a követező radarkockán ki is vágott irányunkba egy cella, így mire kocsival megtettük az 1,4km-t a reptérig, már a jég esett, s a kikapcsolás már a cella elvonulása ideje alatt történt. Siker... (Hajnali 3 körül azért egy újabb zivatar megnyugtatott, hogy nem hiába áztunk. A visszakapcsolás reggel fél nyolc körül történt.)

Mi lett a következménye? Amikor átírtam az egész pontosságú időt kézzel, ugyanúgy futottak az idők a két műszer adataiban (utóbb kiderült, véletlenül). Mégis, az adatsor közepe táján, mikor egy zivatar hatását kerestem, csak több óra elcsúszással találtam meg (sőt, sokáig sehol). Egész pontosan 7 és fél óra. Nos, a zivatar alatt kb. 7 órát állt a rendszer, és utólag megtudtam, hogy 6-án kora délután volt fél óra áramszünet.

És a csoda: a METEK szenzorben ezek a szünetek benne voltak, az egymás utáni adatok között eltelt időkülönbség az adatok időpontjai között is eltel. A CR3000 gépkönyve szerint a másik esetben is így kellett volna lennie, de nem így volt. Szépen folytatta az időpontokat ott, ahol a kikapcsoláskor abbahagyta.

Összegyűjtöttem tehát a METEK adatokból a szüneteket, kiszámoltam kb. a hosszukat, és betoldottam a megfelelő helyekre a megfelelő számú adathiányt jelző sort. Ezek után végre a "számogatást" (tudományos igényű adatfeldolgozást) megkezdhettem... Volna. Ugyanis az első alkalommal, amikor nyers egyperces átlagokat számoltam, a következőket kép tárult elém:

Néhány helyen utánanéztem, és nem találtam konkrét okát az elcsúszásnak. Egyedül a CR3000 fálmentési időszakaiban keletkező gondolhattunk, de akkor sem volt világos, hogy miért a METEK késik, és nem fordítva? Aztán kiderült, hogy semmi köze a mentésekhez. Kezdett úgy látszani a dolog, hogy az eddigiek csak apró hibák voltak, amiket csettintésre kijavítottunk.

Így Ellenőriztem végül az autokorreláció menetét (ha kiválasztok mindkettőből egy időszeletet, és az egyiket a másik előtt tologatom, az eltolás függvényében kiszámolom a korrelációt, és ezt az egyik kezdőidőpontja, és a két kezdőidőpont közötti különbség függvényének tekintem). Ennek egy maximumának kell lennie annál az eltolásnál, amikor a két adatsor "összecsúszik", ez mondja meg, mennyit kell beletolni a rossz órájú adatsorba. Az eredményt magunk sem hittük el:

Annak a sárga sávnak vízszintesnek kellene lennie, lehetőleg a nullánál. Vagy ha nem ott, az sem olyan nagy baj. Vagy ha egy-egy helyen hirtelen elugrál, még azt is elviseljük. Na de így???

Mik lettek ennek a tanulságai?

1. Már kezdetben is volt egy kb. 5 perces eltolás, ami azért furcsa, mert mindkét rögzítő kezdőidőpontját ugyanannak az embernek ugyanahhoz az órájához állítottuk. Kiderült, hogy a METEK adatait rögzítő program a laptop rendszeridejét használta.
2. Megállapítottuk tehát, hogy a laptop órája két és fél hónap alatt kb. 15-20 percet késik (a CR3000-hez képest), melyet megerősítettünk számítással is: ha 36000 helyett 36005 db. adat van minden órában, az 100 nap alatt 12000-rel több, mint kéne, ami 20 perc.
3. Az eltolódás folytonos, amit csak úgy magyarázhatunk, hogy a két 10Hz-es adatrögzítési frekvenciák közül valójában az egyik egy kicsit több. Vagy a másik kevesebb. (Természetesen elsőre a helytelent állapítottam meg, miután összecsúsztattam az adatsorokat, az észlelésekkel még mindig nem stimmelt. Ugyanis a jót toltam a rosszhoz.)
4. Még az elelkedés mértéke sem teljesen konstans, de jobb híján (vagy inkább kedv híján) egyenest illesztettem az eltolódásra. Azt kaptam, hogy a laptop órája kb. 5000 másodperc alatt egy másodpercet késik (egészen pontosan minden 4924-edik adat "fölösleges"). Vagyis az a 10Hz egy kicsit több. (Témavezetőnk szerint ez nem lehet, mert a műszer gyártói "az Elnök emberei".) Ezt kihasználva azért mégis össze tudtam tolni az adatsort.

A fő tanulság pedig a következő:

Mindig vigyünk magunkkal nagy pontosságú, hitelesített órát, és igyekezzünk folyamatosan ellenőrizni, hogy az adatrögzítők órái elcsúsznak-e hozzá képest. Ha ezt Szegeden megtettük volna, egyből tudtuk volna, hogy hol keressük a hibát. Ha van ilyen óránk, akkor az ilyen provlémákat nagyon egyszerű felfedezni. Ennek segítségével nem csak a meteorológiai adatsoroknak, hanem a helyi tömegközlekedési járművek érkezésének időpontjait is össze tudjuk korreláltatni a menetrendben kiírtakkal. Így a tudományos közönségnek tartott előadások mellett a központi pályaudvar forgalmi irodáján tartandó "vitakonferenciák" esetére is hasznos eszközzé válhat.

Az óra fontos...