Traffic weather warning

[enevala]

Merge traffic weather warning to master

[mpartio]

Minulta meni hetki ennen kuin ymmärsin mistä tässä funktiossa on kyse. Tämä siis vastaa smarttool kutsua

sumt(-2, 0, par317_ec)

Eli lasketaan summa kolmelta viimeiseltä tunnilta nykyinen tunti mukaanluettuna. Smarttool tekee aikainterpolaation jos dataa ei ole olemassa. luatool-koodissa taas käytetään "multiplier" muuttujaa jolla kerrotaan viimeisen tunnin arvo, jos data ei ole tunnin aikaresoluutiossa.

Minä tekisin tämän kohdan seuraavasti: Haetaan datat kolmelta tunnilta ja pyydetään Himania tekemään aikainterpolaatio. Jos data on tunnin resoluutiossa, Himan palauttaa sen interpoloimatta. Eli o muuttuja näyttäisi tältä:

local o = {
    forecast_time = prod_time,
    level = level(HPLevelType.kHeight, level_height),
    forecast_type = ftype,
    time_interpolation = true              <----- tämä on lisätty
  }

Ja fetch_radiation_data() ei tarvitse multiplieriä enää.

  o.param = param('RADGLO-WM2', aggregation(HPAggregationType.kAverage, agg_duration), processing_type())

  -- Fetch radiation data
  return fetch_multiple_radiation(o, prod_time)

[mpartio]

Kaksi kysymystä:

1. Miksi käytetään aina EC:n lumisadetta eikä MEPS:n lumisadetta silloin kun ennustepituus on < 66h?
2. Mitä tarkoittaa tuo että "validation time can't be shifted", ja miksi siitä johtuen pitkillä ennustepituuksilla snr6 ja snr12 ovat nollia?

Yksi huomio:

Makrossa on katsottu lumisadetta eteen- ja taaksepäin; tässä koodissa otetaan vain kertymä (eli katsotaan vain taaksepäin). Mietin että seuraako tästä se että lua-koodi ei anna varoitusta silloin jos lumisade on tulossa, eli käytännössä Himanin antama varoitus olisi viivästynyt ajallisesti makron varoitukseen verrattuna.

Kun makrossa on näin: SumT(-1, +1, par264_EC), niin sen voisi kääntää Himaniin niin että hakisi SN-3-MM tunnilta +1. Samaten SumT(-3, +3, par264_EC) voisi olla SN-6-MM tunnilta +3 (se ei vastaisi täysin samaa koska se olisi 6h kertymä eikä 7h mutta olisi varmasti riittävän lähellä) ja SumT(-6, +6, par264_EC olisi SN-12-MM tunnilta +6.

[enevala]

Tässä kohdassa ajatuksena on siirtää lumisadekertymää eteenpäin, jotta varoitus ei viivästy. Riveillä 309-312 kertymiä siirretään move_valid_time()-funktiolla 1, 2 tai 5 tuntia eteenpäin. Näin tehdään vain jos EC-step on alle 85, koska sen jälkeen stepit ovat yli tunnin, joten (ainakin luulisin) valid-aikaa ei voi siirtää eteenpäin, koska näitä aikoja ei enää ole. Vaikka stepit tarkistetaan EC-ajoista, data tulee silti ennen MEPS 66 steppiä MEPS:stä pri2_time-muuttujan mukaan.

1. Ennen 66h käytetään MEPS lumisadetta. Haettu lumiparametri riippuu pri2_time-muuttujasta, joka asetetaan rivillä 288 MEPS-stepin mukaan.
2. Tämä johtuu oletuksestani, että steppien kasvaessa valid-aikoja puuttuu eikä niitä pysty enää siirtämään tulevaisuuteen, kuten ennen EC-steppiä 85.

[mpartio]

Olen hiukan hidas niin kertaan vielä. Eli pri2_ftype määrittää miltä ennustetyypiltä lumisade haetaan. pri2_time määrittää ajan mutta sehän voi olla (teoriassa ainakin) sama molemmilla tuottajilla. Esim 00 -analyysi löytyy sekä ec:ltä että mepsiltä, mutta näistä tuottajista vain toinen on deterministinen ja toinen parven kontrolli ja siksi haku menee oikeaan paikkaan.

Mutta jäin vielä miettimään tuota validtimen siirtämistä. Tämä varoitus-data lasketaan viren päälle joka on taas rakennettu ec:n ja mepsin päälle, eli kaikki ajat joille varoitus lasketaan on myös olemassa muilta tuottajilta. Eli jos vaikka ennustetunti olisi 101, niin edellinen tunti on 98 ja seuraava 104. Tässä tapauksessa miksi et ottaisi dataa seuraavasti:

• snr3 tunnilta 101
• snr6 tunnilta 104
• snr12 tunnilta 109

[enevala]

Joo siis tosiaan se pri2_ftype, myös vaikuttaa haettuun ennusteeseen! Eli juuri, kuten sanoit pri2_time ja pri2_ftype määrittelee datan tuottajan.

Joo noinhan se kannattaa tehdä! Jotenkin ajattelin, että yhden tai kahden tunnin siirto eteenpäin ei onnistu, ni en edes miettiny niitä seuraavia ennusteita :D Siirrän niitä ton verran eteenpäin. Kun steppi on 6h ja ennustetunti esimerkiksi 161, niin kertymäajat voisi olla:

• snr3 tunnilta 161
• snr6 tunnilta 167 (menee vähän pitkälle, mutta 161 kertymä saattais olla vähän myöhässä varoituksen kannalta?)
• snr12 tunnilta 167

[mpartio]

Tuo kuulostaa järkevältä kompromissilta. snr3 ja snr12 ottavat kuitenkin huomioon menneen sateen kun snr6 tässä tapauksessa keskittyy vain tulevaan sateeseen.