Radarfremskrivning: Udvidelser til forbedring af kvalitet

Transkript

1 Radarfremskrivning: Udvidelser til forbedring af kvalitet Kasper Holmberg Laursen IMM-B.Eng

2 Technical University of Denmark Informatics and Mathematical Modelling Building 321, DK-2800 Kongens Lyngby, Denmark Phone , Fax

3 1 Abstrakt Ved radarfremskrivning forstås en udregning, ud fra de seneste radarbilleder, af fremtidige radarbilleder inden for en kort tidshorisont. Dette giver rimeligt præcise forudsigelser om det kommende vejr inden for nogle få timer. Der er mange muligheder for at udvide eksisterende metoder til radarfremskrivning. I dette projekt vil jeg specifikt undersøge temaerne skalaudglatning samt vækst og forfald. Formålet med implementationen af disse er at øge kvaliteten af fremskrivningen. Skalaudglatning Fremskrivningen af radardata er baseret på et vektorfelt der beskriver nedbørsbevægelsen over Danmark. Det er vigtigt at vektorfeltet er kontinuerligt da stærkt afvigende vektorer dels kan give problemer for fremskrivningsalgoritmen, dels påvirker kvaliteten negativt. I denne del af opgaven vil jeg designe og implementere en løsning som udglatter vektorfeltet under hensyntagen til skala. Basalt set er idéen at beregne udglattede felter i forskellige opløsninger, for så at kombinere disse til det endelige felt. Vækst og forfald Konvektiv nedbør er et særligt problem ved fremskrivning af radarbilleder. Typisk fremskrives udelukkende bevægelsen af den forhåndenværende nedbør, men ikke vækst og forfald af nedbørsområdet. I denne del af opgaven vil jeg designe og implementere en løsning for dette. Idéen er at finde forskelle i densiteten mellem observerede radarbilleder og udregne hvorledes disse forskelle kommer til at påvirke fremskrivningen. Er mængden af nedbør f.eks. faldet mellem to billeder trækkes yderligere densitet fra i fremskrivningen af de efterfølgende billeder.

4 2 Litteraturliste Improving the nowcasting of precipitation in an Alpine region with an enhanced radar echo tracking algorithm (S. Mecklenburg, J. Joss, W. Schmid 21 September 2000) Nowcasting of Motion and Growth of Precipitation with Radar over a Complex Orography (L.Li,W. Schmid, J. Joss 1 November 1994) Binary Classification (Wikipedia.org) Detection of Weather Radar Clutter, IMM-PHD (T. Bøvith 2008)

5 3 Indholdsfortegnelse Abstrakt...1 Litteraturliste Indledning Regnvejrsprognoser i Danmark Prognosemodeller Sammenligning af Modeller Vejrradarer Støj DMIs Vejrradarer Radarfremskrivning Beskrivelse af Radarfremskrivning Parametre Begrænsninger Mulige Udvidelser Opbygning af Programmet Analyse Tidsplan Risikoanalyse Radardata Verifikation Kravspecifikation Skalaudglatning Vækst og Forfald Skalaudglatning Metode Effekter af boxsize Implementering Test Parameter Test Forbedrings Test Vækst og Forfald Metode Implementering Test Konklusion Skalaudglatning Vækst og Forfald Afsluttende Ord...43

6 4 Bilag A computetracking kode...44 Bilag B Skalaudglatning Verifikationer...48 Bilag C Vækst og Forfald Verifikationer...52

7 1 1 Indledning Denne rapport er en del af mit afgangsprojekt på Diplomingeniør It retningen ved DTU. Den dokumenterer den opgave, jeg har udviklet for Dansk Meteorologisk Institut (DMI) i perioden 13 September 6. December. Opgaveformuleringen er udarbejdet i samarbejde med min vejleder på DMI, Kim Roland Rasmussen, som jeg også har arbejdet sammen med i løbet af mine 20 ugers praktik på DMI. Mine forudsætninger for dette projekt er dels mit praktik ophold på DMI og dels min uddannelse på DTU. Projektet er en udvidelse af et allerede eksisterende projekt, som er blevet til som en del af min praktik hos DMI. Udvidelserne er udarbejdet af mig selv på DMI og rapporten er skrevet løbende undervejs, delvis hjemmefra og delvis på DMI. 1.1 Regnvejrsprognoser i Danmark Vejret har altid haft interesse for de fleste mennesker, da både dårligt og godt vejr kan have stor indflydelse på os i løbet af vores dag. I særdeleshed er regn og sne det, vi er mest interesserede i at vide hvor og hvornår opstår. Ved hjælp af meteorologi forsøger vi at forudse vejret, men alle os der har kigget på en femdøgnsprognose ved godt at det bestemt ikke er lige til. Specielt er det besværligt at forudse om det kommer til at regne eller ej i et givent område, på et givent tidspunkt. At det er svært at forudsige vejret, er et faktum de fleste af os er bekendt med. Hvad mange sikkert ikke ved er, at vejret som regel passer rimelig godt overens med hvad der er spået, blot med en forskydning på op mod 50 kilometer. For de fleste af os er vejret kun et spørgsmål om, hvor rart det er at være

8 2 udenfor. Om det er fordi vi er på vej hjem fra arbejde eller ude for at handle, eller hvis vi gerne vil en tur i Dyrehaven handler det om at vi hellere vil have sol end regn. Men inden for industrien er der mange, der har et meget stort behov for at vide præcist hvor og hvornår der kommer nedbør. Blandt andet kan store mængder regn give nogle alvorlige problemer for spildevands rensningsanlæg og byggepladser. 1.2 Prognosemodeller Når man taler om prognoser skelner man mellem langtidsprognoser og korttidsprognoser. Altså mellem prognoser, der beskriver vejret lang tid ud i fremtiden eller kort tid ud i fremtiden. De prognosemodeller, der primært benyttes i dag, laver langtidsprognoser. Formålet med langtidsprognoser er naturligvis at kunne forudse vejret i god tid. Desværre er det jo ikke så lige til at forudse og en langtidsprognose vil derfor have en forøget sandsynlighed for at være forkert på den jo længere ud i fremtiden vi kommer. Langstidsprognoserne udregnes ud fra en masse forskellig data opsamlet af radarer, satellitter og vejrstationer. Det gør at udregningen af prognosen er tidskrævende og derfor ikke udføres særlig ofte. Korttidsprognoser derimod kan kun fortælle os noget om vejret inden for en meget kort tidshorisont. Korttidsprognoser kaldes også for nowcasting. Fordelen i nowcasting er den tid udregningen tager. Nowcasting er ofte en simplere løsning end langtidsprognoserne og kan derfor udregnes meget hurtigere. Et eksempel på nowcasting er radarfremskrivning som denne afhandling kommer til at arbejde med. Radarfremskrivning i sin simpleste form udregner prognoser kun ved hjælp af radarbilleder. Det gør at udregningen kun tager et øjeblik. Nærmere beskrivelse af radarfremksrivning findes i næste kapitel. Hvorfor bruger man så den ene og den anden type prognoser? Hvad kan de i forhold til hinanden og hvilke begrænsninger har de? Dette bliver diskuteret i næste afsnit Sammenligning af Modeller På grund af de mange forskellige data, der benyttes i langtidsprognonserne, og på grund af det store område, de som oftest dækker, er det nødvendigt for disse pronoser at køre med en meget grov opløsning. Det betyder, at selvom forudsigelser af f.eks. regnvejr er forholdsvis præcise i modellen, er det måske langt fra præcist ude i den virkelige verden, da en lille forskydning i modellen

9 f.eks. kan betyde at regnvejret ender 50 kilometer nord for hvor vi troede det endte. Til sammenligning har nowcasting metoder ofte en langt højere opløsning. Radarfremskrivning, som dette projekt omhandler, er simpelthen nødt til at have en højere opløsning for overhovedet at kunne fungere. Det betyder at hvis der opstår en lille forskydning i forhold til forudsigelsen vil det også kun være en lille forskydning ude i den virkelige verden. En lille forskydning kan i nowcasting modeller være alt fra 500 meter til nogle kilometer. Dette betyder altså at nowcasting ofte vil være noget mere præcis omkring lige hvor der kommer nedbør. Til gengæld er forudsigelser fra nowcasting meget lidt præcise når man kommer blot nogle få timer frem i tiden og det er her at langtidsprognoserne har fordelen. Senere i denne rapport vil man tydeligt kunne se hvor hurtigt præcisionen falder i nowcasting. Vejret ændrer sig hele tiden. Det gør langtidsprognoserne til gengæld ikke. De indeholder en masse data i deres udregninger og tager derfor lang tid at udregne. Hvis der er et markant omslag i vejret, som ikke var forventet, kort tid efter en kørsel af sådan en model, vil der kunne være meget store afvigelser, når vi nærmer os den næste kørsel. Langtidsprognoserne køres typisk en gang hver 6. time. Nowcasting hedder netop dette fordi det køres nu. Disse modeller er nemlig langt hurtigere at udregne og kan derfor køres lige så ofte man har lyst til. Det bliver derfor lige så ofte man har nye data. Forskellen på forudsigelserne fra en langtidsmodel og en nowcasting-model vil derfor ofte være ca det samme kort tid efter en kørsel af langtidsprognoserne, men når vi nærmer os den anden ende vil nowcasting have en klar fordel, da den rent faktisk følger med i udviklingen i vejret. Optimalt set bør man benytte sig af både langtidsprognoser og korttidsprognoser, da de hver især kan noget den anden ikke kan. 3

10 4 1.3 Vejrradarer Vejrradarer virker ved at sende elektromagnetiske stråler ud i atmosfæren. Strålerne reflekteres hvis de møder noget og radaren er så i stand til at opfange det der reflekteres og er i stand til, ud fra styrken af det signal, den modtager, at bestemme hvad det er, den er stødt på. Radarerne kan altså finde ud af hvor der er nedbør og hvilken type det er (sne, slud, regn) da de forskellige nedbør partikler er meget forskellige i densitet og derfor giver forskelligt ekko. Illustration 1:Her ses en typisk radaropstilling Støj Radarstøj, som oftest kaldet clutter, skyldes mange forskellige ting. Radarernes stråler reflekteres af alle objekter og vil derfor også få ekko fra fugle og insekter. Solens stråler kan også i nogle tilfælde skabe forstyrrelser som vil blive opfanget som ekko af radarerne. Der findes flere andre former for clutter, nogle som er mere hyppige end dem som allerede er nævnt. Ligeledes findes der flere måder at skille sig af med de fejlagtige observationer som er konsekvensen. Der er skrevet adskillige artikler omkring clutter og hvordan man håndtere det, en af dem er Thomas Bøviths, Detection of Weather Radar Clutter. For at kunne bruge radarbilleder til at forudsige vejret med, er det altså vigtigt at få fjernet clutter først, så man ikke får regnet på noget som slet ikke findes. Hvilke data, der benyttes i dette projekt, og hvordan clutter håndteres, kommer jeg lidt nærmere ind på senere i kapitlet Analyse.

11 DMIs Vejrradarer De radardata, der benyttes i dette projekt, stammer fra DMIs verjradarer. DMI har 5 radarer opstillet ved Rømø, Sindal, Stevns, Virring og Bornholm (Se illustration 2). Radarerne dækker tilsammen hele Danmark og en del af både Norge, Sverige og Tyskland. Illustration 2:Viser placeringen af DMIs vejrradarer

12 6 2 Radarfremskrivning Radarfremskrivning kan hjælpe med at fortælle mere præcist hvor og hvornår der vil være nedbør inden for en kort tidshorisont. Dette er information, som er aldeles vigtig for mange. Blandt andet kan landbrug, byggepladser og spildevands rensnings anlæg være aldeles interesseret i at vide præcist hvornår det kommer til at regne, eller ikke gør. DMI har allerede et radarfremskrivnings projekt, som ikke er taget i brug endnu. Projektet blev udviklet i samarbejde mellem DMI og mig selv i løbet af min praktik. 2.1 Beskrivelse af Radarfremskrivning Radarfremskrivning fungerer ved at se på de seneste to nedbørsbeskrivende radarbilleder og sammenligne dem. Det ældste af de to billeder deles op i felter og hvert felt genfindes i det nyeste billede. Dette gøres ved hjælp af korrelation således at indholdet af feltet matcher så godt som muligt på et lige så stort område i det nyere billede. Afstanden fra feltets oprindelige position til hvor det har flyttet sig til beskrives ved en vektor og der dannes på denne måde et vektorfelt som beskriver bevægelsen af nedbør på billedet. Når et vektor felt er fundet fremskrives nedbøren på det nyeste billede efter disse så et nyt billede skabes. Der benyttes en matematisk model kaldet CFD (computational fluid dynamics) til at bevæge nedbøren gennem de strømninger der er repræsenteret via vektorfeltet. På denne måde bliver nedbøren altså flyttet fremad i den, eller de, retninger der er udregnet i første skridt. Herefter er det blot et spørgsmål om at gemme informationen i nye billeder.

13 2.2 Parametre Ved kørsel af radarfremskrivningen er der nogle forskellige parametre der kan indstilles. En stor del af parametrene er til forskellige matematiske modeller som SOR (successive overrelaxation) og CFD (computational fluid dynamics). Disse parametre er ikke de interessante. De er udvalgt netop til dette formål og bør egentlig kun ændres, hvis man vil opnå nogle andre ting med programmet. De interessante parametre har med selve kvaliteten af fremskrivningen at gøre. Box.size og box.searchrange har direkte indflydelse på hvordan bevægelsesfeltet kommer til at se ud, og er nogle af de mere interessante at justere på. Der findes også en række parametre til at styre outputtet. Standard outputtet kommer til at være i filformat, da programmet ellers ikke har produceret noget. Der er dog også implementeret et grafisk output, sådan at det nemt ses hvordan nedbøren har flyttet sig fra billede til billede. Dette er brugt til at få overblik over hvordan forskellige parametre påvirker fremskrivningen. Via parametrene kan man også give information om tiden mellem to radarbilleder og opløsningen på dem. 2.3 Begrænsninger Fordi radarfremskrivning virker ved udelukkende at kigge på eksisterende nedbør og ikke noget andet, er der en række begrænsninger forbundet med det. Det er ikke muligt for radarfremskrivning at forudse, at der pludselig opstår regn et sted. At en sky, der tidligere ikke har afgivet regn, begynder på dette kan altså ikke forudses af radarfremskrivningen. Dette skyldes, at der kun kigges på eksisterende nedbør som flyttes i samme retning det hidtil har haft. Der er behov for langt flere input hvis man skal kunne forudse hvornår regnen opstår. Ofte er skysystemer så store at de dækker mere end hele Danmark. DMIs radarer har en begrænset rækkevidde hvilket kommer til at have indflydelse på fremskrivningens evner. Hvis et skysystem, der afgiver nedbør, rækker ud over radarernes rækkevidde, vil fremskrivningen ikke kunne forudse regn i udkanten, da der ikke er nogen information om nedbør at fremskrive dertil. 2.4 Mulige Udvidelser Der er mange mulige udvidelser til radarfremskrivningen, som den eksisterer nu. Herunder vil jeg nævne nogle forskellige udvidelser, som jeg har kigget på i forhold til dette projekt, og komme lidt ind på hvilken effekt de kunne have. 7

14 8 Udglatning af vektorfelt: Det er nødvendigt for fremskrivningen af radarbillederne at det vektorfelt der udregnes er nogenlunde kontinuerligt. Når der udregnes vektorer vil der som regel være nogle vektorer der adskiller sig meget fra de andre. Derfor udføres der en udglatning af vektorerne inden de fremskrives. Udglatningen kan derimod være meget bedre. Der er mange måder at udglatte vektorfeltet på, og en af dem er skalaudglatning. Dette går ud på at danne flere vektorfelter i forskellige opløsninger og lave et gennemsnit af vektorerne således at de vektorer der skiller sig ud rettes op og et mere kontinuerligt vektorfelt derved dannes. Skalaudglatning er en af de to forbedringer jeg vil arbejde med i denne opgave. Ekstra information: Radarfremskrivningen tager som tidligere nævnt kun input fra radarbilleder. Det er muligt at hente informationer andetsteds fra. F.eks. kan satellitbilleder fortælle om der er skysystemer uden for radarernes rækkevidde og man kan på den måde komme uden om den begrænsning der ligger i fremskrivning af nedbør ved radarernes kanter. Langtidsprognoserne kan også give information, der svarer til satellitbilledernes. Man kan også indhente information fra vejrstationer rundt omkring i landet. Vindstyrke kan være særdeles brugbart at tage som input, da man derved har lettere ved at forudse hvor langt nedbøren kan have flyttet sig. Billedserie til vektorfelt dannelse: I stedet for kun at benytte de seneste to radarbilleder til at skabe vektorfeltet kunne man gøre brug af flere af de seneste billeder og på den måde se på hvordan vektorfeltet ændrer sig fra billede til billede. Man vil på den måde kunne se tendenser i ændringerne og undgå at lave et vektorfelt der pludselig peger i en anden retning i de forrige. Det vil også kunne bruges til at skabe et mere kontinuerligt vektorfelt som tidligere omtalt. Vækst og forfald: Regnvejr er ikke konstant. Det aftager og tiltager og gør det derved endnu sværere at forudse. Radarfremskrivningen tager ikke højde for vækst og forfald, men det er muligt at kigge på densiteten af nedbør i billederne og sammenligne den. På den måde vil man så kunne tage denne del med i sin fremskrivning og derved få et endnu mere præcist billede af fremtiden. Vækst og forfald er den anden af de to forbedringer, jeg vil arbejde med i opgaven. Varierende vektorfelt: Gennem flere kørsler med forskellige parametre har det vist sig at en fremskrivning der bruger en grovere opløsning i felter ofte er mere præcis jo længere ud i fremtiden fremskrivningen kommer. Dette kan man bruge til at konstruere de forskellige skridt i fremskrivningen med forskellig opløsning. Det er nødvendigt med en hel del test for at nå frem til nogle gode

15 parametre, men det vil give muligheden for et bedre resultat i enden. Denne udvidelse vil til gengæld kun påvirke de senere skridt i fremskrivningen og ikke ret meget de tidlige og slet ikke det første. 2.5 Opbygning af Programmet På illustration 3 ses folderstrukturen i programmet. Billedet er taget direkte fra Eclipse Navigator. 9 Jeg vil ikke komme nærmere ind på nogle af de foldere der ligger uden for source, men vil give en kort gennemgang af hvad hver af folderne under radarnowcasting inden i source indeholder og hvad filerne i dem arbejder med i programmet samt en kort beskrivelse af nogle af de fritstående filer. config: Indeholder filer til konfiguration af programmet. Klasserne der ligger heri indeholder information indhentet fra radarnowcasting.properties.

16 10 imagaio: Indeholder filer til skrivning og læsning af Tga filer. model: En nærmere beskrivelse af denne mappe kommer længere nede. radar: Indeholder filer til behandling af de data imageio indlæser. test: Indeholder filer brugt til tidligere test. util: Indeholder forskellige utilities. RadarNowcasting.java: Indeholder programmets main funktion. Klassen indhenter konfigurations information og opretter derefter en instans af Assimilation.java. Når denne har gjort sit arbejde findes relevant information og sendes videre til en instans af Forecast.java og herefter er programmet afsluttet. Assimilation.java: Indeholder en controller, en model og et view. De filer den benytter ligger i folderen model. Assimilation delen er ansvarlig for at indsamle oplysninger. Disse oplysninger er i form af et bevægelsesfelt. Forecast.java: Indeholder en controller, en model og et view. De filer den benytter ligger i folderen model. Forecast delen er ansvarlig for at lave selve fremskrivningen ved hjælp af de oplysninger Assimilation delen har indsamlet. På illustration 4 kan opbygningen af assimilation og forecast ses som beskrevet ovenfor. Derudover vil jeg lige give en kort gennemgang af de øvrige mapper herinde. Nogle af filerne hedder Khl forrest. Disse filer er dem jeg har arbejdet mest med. De er kopieret og omdøbt så det er muligt at kører programmet som det fandtes før og som det er efter jeg har redigeret i det. Under assimilation ses filerne KhlAssimilationController.java og KhlAssimilationModel.java. De kommer til at være mine udgaver af CotrecAssimilationController.java og CotrecAssimilationModel.java. Der er ligeledes et par filer i forecast som er navngivet på denne måde. Khl er mine initialer og jeg har valgt at beholde denne navngivning for at gøre det nemt at finde frem til de væsentlige ændringer jeg har lavet når dette skal flyttes over til det operationelle program. engine/flow: Disse to indeholder funktionaliteten til selve fremskrivningen. Filerne i disse to foldere er dem der udregner bevægelsesfeltets påvirkning på nedbøren. grid: Heri ligger grid klassen. Grid klassen er den der indeholder data for alle de forskellige felter. Nedbør, bevægelse og hvad der ellers måtte være. gui: Indeholder alle filerne til det grafiske output. math: Indeholder nogle implementerede matematiske formler som f.eks. SOR successive overrelaxation. scene: Indeholder hjælpe filer til gui. Filerne heri indeholder de data gui viser.

17 Illustration 4:Viser den indre struktur i model folderen 11

18 12 3 Analyse 3.1 Tidsplan Uge 1 Uge 2 Uge 3 Uge 4 Uge 5 Uge 6 Uge 7 Uge 8 Uge 9 Uge 10 Uge 11 Uge 12 Analyse Research Design / Implementering Test Rapport Jeg har valgt at gøre mine to delopgaver færdige en af gangen. Derfor er tidsplanen opdelt som den er. Analyse: En stor del af dette bliver at sætte mig ind i den eksisterende kode. Jeg har sat god tid af til dette da det uden tvivl vil komme til gavn senere når jeg skal til at implementere. Research: Jeg har allerede artikler liggende som jeg har set på. Det betyder at jeg ved hvilke der er relevante for mig og nogenlunde hvad det er jeg skal lave og hvordan. Det kommer nemt til at spare mig noget tid at jeg har arbejdet med projektet i min praktikperiode og jeg har pga. dette kun afsat meget lidt tid til research.

19 Design / Implementering: Jeg har valgt at slå disse to sammen fordi mit projekt er redigering i/tilføjelser til, den eksisterende kode. Selvom der er meget få design overvejelser er der stadig nogle og jeg vil ikke helt undlade at tage højde for at det kan tage noget af min tid. Jeg regner dog med at den tid jeg kommer til at bruge på selve design delen er ubetydelig i det store billede. Test: Der kommer til at skulle testes en hel masse. Det er nødvendigt at forsøge at finde frem til de bedste parametre at bruge og det kan uden tvivl tage sin tid. Derfor har jeg sat godt med tid af til test. Jeg er opmærksom på at en meget stor del af min opgave nok er selve testen og at finde de rigtige input der giver de bedst mulige resultater. Desuden er det nødvendigt at finde ud af om de her tilføjelser rent faktisk gør fremskrivningen bedre eller ej. Jeg forventer en del flere parametre jeg skal tage stilling til i den første del af opgaven, hvorfor jeg har afsat mere tid til test i denne. Rapport: Jeg forventer at skrive dele af rapporten undervejs. En god del af rapporten vil også blive skrevet i analyse perioden og ellers løbende blive tilføjet på, efterhånden som projektet skrider frem. 3.2 Risikoanalyse Fordi jeg har arbejdet med dette projekt i min praktikperiode føler mig rimeligt sikker på at være i besiddelse af alt jeg får brug for til udfærdigelsen af mit projekt. Jeg forventer at skulle have et par møder med min vejleder i forbindelse med begyndelsen af hvert af mine delprojekter, så her er der mulighed for at kunne komme bagud hvis han har en travl periode. Dette kommer jeg nemt uden om hvis jeg sørger for at aftale møderne i god tid eller have andet jeg kan foretage mig i mellemtiden. Ud over dette tror jeg den største tidssluger kan komme til at være at sætte mig ind i den eksisterende kode. Jeg har allerede artikler som jeg kender udmærket og skal derfor ikke bruge så meget tid på informationssøgning. Alt i alt føler jeg mig rimeligt sikker på at hvis bare jeg kan holde mig almindeligt til tidsplanen burde der ikke komme nogle uforudsete forsinkelser. 3.3 Radardata De data jeg kommer til at arbejde med i projektet er sammensatte radarbilleder der er filtreret for eventuel støj. Der er andre eksisterende programmer der håndterer radarbillederne og leverer dem filtrerede. På trods af dette er der højst sandsynligt stadig noget støj tilbage 13

20 14 på billederne. Til gengæld er der også den mulighed at en af radarerne ikke virker. Det sker fra tid til anden at en af radarerne står ud i et par timer og det giver nogle problemer i fremskrivningen da resultatet pludselig kan se meget anderledes ud skulle en af radarerne stå ud. Den simpleste og nok bedste løsning på dette er simpelt hen ikke at lave nogen fremskrivning når en radar er nede. En anden mulighed er at lave et estimat ud fra det delvise radarbillede man får og de tidligere fremskrevne billeder. Det er ikke så lige til og der skal udarbejdes en algoritme for at løse problemet. I denne afhandling arbejder jeg med specifikke dele af projektet og jeg vil derfor ikke beskæftige mig med dette problem. Det antages derfor at der hverken er støj på billederne eller nogen af radarerne står ud. Alle de data jeg vil benytte mig af vil være data hvor alle radarerne fungerer som de skal. Jeg har udvalgt fire specifikke tidspunkter som jeg vil arbejde med og teste på i løbet af projektet. De er udvalgt så de adskiller sig en god del fra hinanden på flere punkter, så jeg på den måde får testet på flere forskellige vejrsituationer. Illustration 5 viser et billede af de fire tidspunkter jeg har udvalgt. Der er ikke nogen information om vindretning på disse billeder. Jeg har til gengæld observeret resultaterne af fremskrivning på alle tidspunkterne og har en idé om hvordan vinden bevæger sig. Kl. 05:20 d. 28/ På dette billede ses et rimelig jævnt nedbørsfelt hvor vinden bærer i østlig retning. Det jævne felt giver mulighed for en rimeligt præcis fremskrivning, også ud i de senere skridt. Kl. 02:10 d. 30/ Her er en lille mængde solid nedbør. Vinden har en overordnet østgående retning, men det lader til den er noget omskiftelig. I hvert fald opstår der nogle virvler under fremskrivningen af dette billede, hvilket er hvad der gør det interessant. Kl. 16:00 d. 01/ Nedbøren her er let og noget skiftende. Det giver stor mulighed for nogle dårlige resultater fra fremskrivningen. Vinden har en sydvestlig retning. Kl. 03:20 d. 01/ Her ses et meget ujævnt nedbørsfelt. Det er interessant fordi det kan have stor betydning for hvor god fremskrivningen bliver med forskellige parametre. Vinden er østgående.

21 Illustration 5:Billedet øverst til venstre viser det tidligste tidspunkt, efterfulgt af billedet øverst til højre, så nederst til venstre og til sidst nederst til højre. 15

22 Verifikation Da jeg startede projektet fandt jeg en lille implementering af verifikation af de fremskrevne radarbilleder. Verifikationen kigger på de 15 billeder der er fremskrevet og sammenligner med de 15 observerede tilsvarende billeder. Verifikations programmet har output i en txt fil der ser ud som følgende: # RadarNowcasting Verification # # Length - forecast length # Time - forecast time # NCC - cross correlation # Spec - specificity (TN/(TN+TP)) # Sens - sensitivity (TP/(TP+FN)) # TP - % true positive # FN - % false negative # FP - % false positive # TN - % true negative # Heri er en liste over hvad de forskellige udtryk betyder og dem vil jeg lige uddybe. Length: Viser hvilket skridt i fremkrivningen der er tale om. Altså billede #xx. Time: Er tidspunktet billedet er observeret/estimeret til. NCC: Viser korrelationen mellem de to billeder. Hvis denne er 1 er de to billeder helt ens.

23 Specificity: Viser hvor stor en del af de faktisk tomme pixels der er fundet. Sensitivity: Viser hvor stor en del af de faktisk fyldte pixels der er fundet. +Prd: Positive Predictive Value, viser hvor stor en del af de estimerede fyldte pixels der er rigtige. -Prd: Negative Predictive Value, viser hvor stor en del af de estimerede tomme pixels der er rigtige. TP: Viser hvor stor en procentdel af de pixels der er estimeret nedbør i der stemte overens med observationen. FN: Viser hvor stor en procentdel af de pixels der ikke var estimeret nedbør i der modsagde observationen. FP: Viser hvor stor en procentdel af de pixels der er estimeret nedbør i der modsagde observationen. TN: Viser hvor stor en procentdel af de pixels der ikke var estimeret nedbør i der stemte overens med observationen. Denne verifikation vil blive brugt primært til test af begge de to delprojekter, men har også dannet grundlag for nogle af de beslutninger jeg har taget undervejs da visse tendenser kan ses når man får kørt programmet tilstrækkeligt mange gange. 3.5 Kravspecifikation Skalaudglatning Der skal laves en reimplementering af søge funktionen. Denne skal kunne søge flere gange i forskellig opløsning, samt lave et gennemsnit af de forskellige resultater. Parametre skal indlæses via radarnowcasting.properties ligesom alle andre parametre. Til test er det nødvendigt at implementere en gui til at kunne se vektorerne. Jeg regner med at kunne genbruge det der findes i forvejen. Derudover findes der verifikationsprogrammet omtalt tidligere i dette kapitel. Det vides ikke rigtigt hvor stor en forbedring af kvaliteten der kan forventes efter dette er implementeret, men jeg vil benytte verifikationsprogrammet til at vurdere om mine resultater rent faktisk har givet en forbedring, og om det er en forbedring der er til at mærke. 17

24 18 Det er også nødvendigt at finde de korrekte parametre at bruge. Dette bør igen gøres via verifikationsprogrammet. Om muligt skal der findes nogle præcise parametre og ellers overvejes en måde at sætte dem på så man får så godt et resultat som muligt, så ofte som muligt Vækst og Forfald Der skal tilføjes til søgefunktionen så den kan finde forskellen i densitet i de to billeder. Det fundne vækst felt skal derefter flyttes over til selve fremskrivningen som sørger for at hvert skridt bliver lagt sammen med vækstfeltet. Eventuelle parametre skal indlæses via radarnowcasting.properties. Som med skalaudglatning ved jeg ikke hvor stor en forbedring jeg bør forvente, men jeg vil benytte mig af verifikationsprogrammet til at vurdere resultaterne.

25 19 4 Skalaudglatning 4.1 Metode Forskellen på skalaudglatning og det eksisterende program er basalt set at metoden til at finde bevægelsesfeltet køres flere gange under skalaudglatning blot med forskellige parametre. Den simple løsning vil derfor være enten at kalde funktionen flere gange eller omskrive den til en rekursiv funktion. I begge tilfælde vil der være noget omskrivnings arbejde. Den eksisterende kode i CotrecAssimilationModel.java opererer primært i funktionen computetracking. Da kaldet til den er udefra kommende er det mest hensigtsmæssigt at omskrive funktionen til en rekursiv i stedet for at kalde den flere gange. På denne måde holdes al funktionaliteten inden for samme klasse. Efter at have besluttet mig for at benytte en rekursiv funktion blev overvejelsen om hvordan dataene skal håndteres det næste. Da der skal regnes gennemsnit på datasættene er det nødvendigt at gemme dem og klassen bruger på forhånd en global array Grid klasse som den redigerer i. I første omgang vil jeg forsøge mig med at lade funktionen returnere et array Grid således at jeg hele tiden vil have den forrige og den nuværende. Dette skulle være nok til at regne et gennemsnit. Med disse overvejelser på plads startede jeg på omskrivningen af funktionen. Overvejelser omkring parametre gjorde jeg meget kort da det er så godt som umuligt at sige noget om hvad der er bedst og jeg vil dedikere en stor del af min test til at forsøge at finde de mest optimale. Jeg vil alligevel kommentere lidt på dem her. De parametre jeg forestiller mig bliver relevante er:

26 20 Forøgelse: Hvor meget skal hvert skridt forøge boxsize med? Antal Forøgelser: Hvor mange skridt skal der tages? Min første indskydelse er at fordoble boxsize ved hvert skridt. Altså gøre hver kasse fire gange så stor. Det vil fint passe fire hele kasser ind i hver kasse fra det tidligere skridt. Antallet af forøgelser er svært, men man må se på boxsize og størrelserne af billederne. Standard boxsize er på 15 pixels og radarbillederne er 446x370. Det betyder at allerede efter to forøgelser vil der være ca 6x7 bokse. En yderligere forøgelse vil derfor ikke længere være hensigtsmæssig. På baggrund af dette er det måske en idé at bruge en mindre forøgelse, men det vil vise sig i testen og i første omgang vil jeg bruge 2 forøgelser med dobbelt boxsize. 4.2 Effekter af boxsize Hele skalaudglatningen er baseret på boxsize og hvilke effekter forskellige størrelser af denne har på fremskrivningen. Når man ser på forskellene mellem fremskrivningerne er der nogle ting der meget tydeligt skiller sig ud. Typisk vil en lavere boxsize være bedre, indtil et vist punkt nås hvor der bliver for mange matches til hver box. Men når man kigger på verifikationerne vil man også kunne se at en større boxsize giver et bedre resultat når man kommer ud i de senere fremskrevne billeder. I tilfælde med stabilt vejr vil en større boxsize være bedst på alle dele af fremskrivningen. Desværre vil den store boxsize give meget dårlige resultater hvis vejret er mere utilregneligt. Herunder er et eksempel på forskellen i verifikationen hvis man benytter en boxsize 15 og en boxsize 30.

27 21 Cotrec Model, boxsize : Cotrec Model, boxsize : Bare ved at se på NCC fra hver verifikation kan vi se at med den lave boxsize får vi bedre resultater på de første billeder, men dårligere resultater senere. Og hvis vi kigger på de andre tal understøtter de dette.

28 22 Der er også tydelige spor at se i fremskrivningen hvis man kigger direkte på nedbørsbillederne. På illustration 6 ses: Øverst til venstre: Det 15. skridt i fremskrivningen med boxsize 15. Øverst til højre: Det 15. skridt i fremskrivningen med boxsize 30. Nederst til venstre: Det 15. skridt i fremskrivningen med boxsize 60. Nederst til højre: det oprindelige billede der er fremskrevet ud af. Illustration 6:Viser forskellen på resultatet af en fremskrivning ved forskellig boxsize Her kan man tydeligt se forskellene. På det første billede(øverst til venstre) kan man tydeligt se at nedbørsfeltets form har ændret sig markant. Samtidig er det hele flyttet en del til højre, eller mod øst.

29 Det andet billede har ikke ændret sig nær så meget, men har beholdt den samme overordnede østgående retning. Det tredje billede har næsten ikke ændret sig, men har dog fortsat østpå som de to andre billeder. 23 Illustration 7:Viser de fundene vektorer inden udglatning ved forskellig boxsize På illustration 7 kan man se søge kasserne. Billederne viser også at de ikke nødvendigvis finder noget de samme steder. Specielt er det svært ved de større bokse når nedbørsområdet i dem er småt. I de to med mindst boxsize kan man se større afvigelse i vektorernes retninger.

30 24 Illustration 8:Viser bevægelsesfelterne udregnet på baggrund af vektorerne fra det forrige set. Her kan man stadig se at billedet med størst boxsize er noget mere kontinuerligt end de to andre. De andre har simpelthen flere detaljer med. Alle detaljerne er ikke nødvendigvis rigtige og det er derfor vi forsøger os med et gennemsnit. Ifølge verifikationen giver de forskellige boxsize bedre resultater i forskellige skridt i fremskrivningen. Dette er hvad der danner basis for skalaudglatning.

31 Implementering Bilag A indeholder koden fra funktionen computetracking. Herunder vil jeg have nogle udklip som jeg vil kommentere på. Den første ændring jeg måtte lave i forhold til de tanker jeg havde gjort mig var at oprette en privat klasse der kunne indeholde noget mere data end et array Grid. Dette skyldes at jeg var nødt til at gemme nogle offset værdier da disse også ændrede sig ved hver rekursion. Da der i toppen af den oprindelige computetracking oprettes nogle midlertidige Grids måtte det rekursive kald komme før dette. // figure out where the boxes in densityfield0 have moved to in densityfield1 public Data computetracking(grid density0, Grid density1, CotrecParameters parameters) { Data data = new Data(); if(increment<parameters.numberofincrements) { increment++; data = computetracking(density0, density1, parameters); } enlargeddensityfield0 = null; enlargeddensityfield1 = null; boxgrid = null; prepareboxandtrackinggrids(density0, density1, increment(parameters.boxsize, increment, parameters.incrementby), increment(parameters.boxgridspacing, increment, parameters.incrementby)); Jeg oprettede en global variabel, increment, som skulle hjælpe mig med at holde styr på hvilken nummer forøgelse jeg var i gang med. 0 svarer til ingen forøgelse og er derved det sidste skridt. CotrecParameters indeholder parametrene om antallet og størrelsen af forøgelserne. Koden ovenover forøger increment og kalder funktionen igen indtil increment er lige med antallet af forøgelser fra parametrene. Efter if-klammerne nulstilles et par variable og funktionen der opsætter de før omtalte Grids kaldes. Herefter følger erklæringerne af variable og dernæst selve søge funktionaliteten. Denne har jeg ikke ændret i og den kan derfor findes i bilaget. Søge funktionaliteten opretter et array grid kaldet boxgrid med boxgrid[0] som u komponenter og boxgrid[1] som v komponenter til vektorerne i bevægelses feltet. Efter søgningen laves et gennemsnit af vektorerne hvis vi ikke er på øverste skridt.

32 26 //adjust vectors according to last recursion if(increment<parameters.numberofincrements) { double u; double v; } for(int i=1; i <= boxgrid[0].getisize(); i++) { for(int j=1; j <= boxgrid[0].getjsize(); j++) { u = boxgrid[0].get(i, j); v = boxgrid[1].get(i, j); if(u!= 0 v!= 0) { double p[] = {0d,0d}; boxgrid[0].getrealpoint(i, j, p); p[0] = p[0] + data.xoffset; p[1] = p[1] + data.yoffset; u = (u + data.boxgrid[0].getnearestneighborvalue(p[0], p[1]))/2d; v = (v + data.boxgrid[1].getnearestneighborvalue(p[0], p[1]))/2d; boxgrid[0].set(i, j, u); boxgrid[1].set(i, j, v); } } } Her oprettes en dobbelt løkke som henter u og v komponenterne fra det nyligt udregnede boxgrid et sæt af gangen. Hvis de ikke begge er nul findes x og y koordinaterne for punktet og disse bruges til at hente u og v komponenterne fra det tidligere boxgrid, altså det fra data klassen, og lave et gennemsnit af de to. Til sidst i funktionen gemmes det fundne bevægelses felt i et andet Grid. Inden dette erstattes alle nulvektorer med nogle gennemsnitsvektorer. Jeg sørger for at ende mit rekursive forløb umiddelbart efter at nulvektorerne er blevet erstattet da der ikke er nogen grund til at lave arbejdet med at oprette det endelige Grid flere gange. Dette gør jeg her: //end recursive if(increment > 0) { increment--; return data; } Selve parametrene omkring søgeboksen og hvor mange gange den skal forøges bruges inde i selve søgefunktionaliteten. Det ligger i en del af alle de variable der initialeres i starten. Jeg lavede derfor en lille funktion som kunne forøge boxsize og andre variabler med den mængde der nu engang stod i mine CotrecParameters.

33 27 private int increment(int d, int increment, int incby) { return d+increment*incby; } Ud over denne funktionaliteten i computetracking måtte jeg implementere en gui til at vise mig de bevægelsesfelter jeg havde fundet frem. Bevægelsesfelterne ændrer sig markant inden de kan ses på det tilhørende forecast view og det var derfor nødvendigt at lave et assimilation view også. Dette view har genereret flere af de billeder der er inkluderet i rapporten. 4.4 Test Testen har to formål. Det ene formål er at finde frem til de mest optimale parametre. Det andet er at få et overblik over forskellene i udfaldet af fremskrivningen mellem den tidligere implementering og den jeg har udarbejdet. Herfra omtales de to forskellige implementeringer som Cotrec og ScaleSmooth. Cotrec er den tidligere implementation. Jeg har udvalgt fire forskellige tidspunkter til mine test. For hver af dem har jeg kørt ScaleSmooth adskillige gange med en lang række forskellige parametre. Allerede efter de første par kørsler af programmet fandt jeg ud af at en gennemsnitsvektor ikke var helt hensigtsmæssig. Det bevægelsesfelt der findes ved den laveste boxsize er som regel det bedste. Da jeg oprindeligt havde valgt at vægte hvert felt lige fandt jeg at det derved i flere tilfælde forringede kvaliteten. På grund af implementeringen lavede jeg en nem rettelse til dette. Jeg valgte at vægte de to felter der arbejdes på (der arbejdes hele tiden kun på to af gangen) lige meget. Da tidligere felter allerede har fået lavet et gennemsnit bliver de derved ikke vægtet lige så meget som det nyeste. Gennemsnittet regnes gennem en rekursiv funktion der sætter hver vektor lig med gennemsnittet af sig selv og den forrige. Eksempel ved 3 forøgelser: V 4 = V 4 V 3 = (V 3 + V 4 )/2 V 2 = (V 2 + V 3 )/2 V 1 = (V 1 + V 2 )/2 V x er vektorene i bevægelses feltet. V 4 er den sidste forøgelse.

34 28 Det kan tydeligt ses nu at forøgelse 2 og 3 kommer til at have væsentligt mindre indflydelse end grundfeltet. De bidrager dog stadig med en overordnet retning for vektorerne. Dette hjælper derved til at holde vektorerne i nogenlunde samme retning således at ingen er rigtigt modvisende i forhold til de andre. Det blev også tidligt klart at en fordobling af boxsize ikke var det mest praktiske. I stedet lavede jeg en ekstra parameter der bestemmer hvor meget der forøges med ved hvert skridt. Det viste sig hurtigt at være en vigtig beslutning da der er meget varierende kvalitet af resultatet med forskellig størrelse forøgelser Parameter Test Til denne test er der mange verifikationer at kigge på. Jeg har lagt dem alle i Bilag B. Herunder vil jeg notere de verifikationer der har givet de bedste resultater. Selve verifikationerne kan enten ses i bilaget eller i næste test hvor de sammenlignes med Cotrec verifikationerne : 3 forøgelser af 10 3 forøgelser af : 3 forøgelser af : 3 forøgelser af : 3 forøgelser af 25 Jeg fandt hurtigt ud af at 3 forøgelser var det bedste. Ikke så meget fordi flere forøgelser gav dårligere resultater, men de gav heller ikke bedre. En af grundene til dette er naturligvis måden jeg valgte at vægte hver forøgelses betydning for gennemsnitsvektoren Forbedrings Test I denne test sammenlignes cotrec modellens resultater med det bedste resultat fra ScaleSmooth for hver af de fire udvalgte tidspunkter.

35 29 Cotrec Model, boxsize : ScaleSmooth Model, 3 forøgelser af : Her ses en lille forbedring i første skridt som vokser jo længere vi kommer hen i fremskrivningen. I sidste skridt ses en forøgelse i NCC fra til 0.478, hvilket må siges at være en klar forbedring.

36 30 Cotrec Model, boxsize : ScaleSmooth Model, 3 forøgelser af : Her er der næsten ingen forandring i første skridt. Nogle få minimale ændringer i præcisionen. Efterhånden som vi kommer længere hen i fremskrivningen er der dog noget større afvigelse, men intet i nærheden af den forbedring vi så før.