GrADS - GFS-ennusteet

Aloittaja weatherc, maanantai, 21.09.2009, 19:16

« edellinen - seuraava »

0 Jäsenet ja 1 Vieras katselee tätä aihetta.

meteorologi

Nyt se taisi ruveta pelittämään. Millä komennolla sait muuten äskeisen sääkartan Skandivnaviasta?

weatherc

LainaaNyt se taisi ruveta pelittämään.
Hieno homma. Nyt sitten vaan muokkaamaan sitä jos haluaa. Itse asiassa se ole niin vaikeaa kun rupee tutkimaan miten se on tehty. Muuten tuo "nordicweather.net"-teksti löytyy suunnilleen riviltä 695
Vinkkinä, kun rupee muokkaamaan niin kannattaa tallentaa toimiva backup ensin jotta on johon palata jos muokkaus menee plörinäksi.

Huomasit varmaan että tuossa gfshd:n "Salo 2009092112 24 60.3 y"-rivissä on yksi arvo enemmän kun alkuperäisessä, se on vaan että päivämäärä ja tunti on eroteltu, NOAA:n plvelimella kun filun nimi on hiemän monimutkaisempi kun alkuperäisessä. Eli järjestys on "Paikka Pvm Tunti Lon Lat Metriset". Koordinaatit ei muuten tarvi olla kun puolen asteen tarkkuudella.

LainaaMillä komennolla sait muuten äskeisen sääkartan Skandivnaviasta?
Itse asiassa siihen tarvitaan koko kasa komentoja :)
Mutta tein skriptin joka sisältää ne kaikki ja siten ei tarvinnut kun ajaa yksi komento :) Slriptin taka-ajatuksena on myös että sais tallennettua koko liutan karttoja samalla komennolla, toistaiseksi ei se osaa sitä vielä.

Se on toistaiseksi täysin hard-koodattu tuohon yhteen ajankohtaan tuosta yhdestä ennustemallista joten siitä ei ole iloa vielä. Väriskaala on kopsattu NWN:än numeroista :)

Mutta esim OpenGrADS:in sivuilla löytyy infoa mm. Sääkeskusken tekemistä systeemeistä (http://opengrads.org/doc/udxt/saakeskus/) ja sitä sivua kun plärää alas kohtaan "Examples" ja siitä raapustaa 10 ensimmäistä komentoa ruutuun (musita muokata päivämäärä) niin pitäisi ilmestyä kartta :)

meteorologi

Juu, paljon kiitoksia avusta. Eiköhän se tästä eteenpäin ole jo selvää.

Ja lopuksi tyhmä kysymys: tekeekö Grads itse nuo ennusteet pelkästä sääanalyysista, vai hankkiiko se valmiit "raakaennusteet" NOAA:lta, ja tekee ennusteista käyttäjän haluamat grafiikat?

Voiko noita kosteuskäyrien pampuloita muokata mitenkään?

weatherc

#13
LainaaJa lopuksi tyhmä kysymys: tekeekö Grads itse nuo ennusteet pelkästä sääanalyysista, vai hankkiiko se valmiit "raakaennusteet" NOAA:lta, ja tekee ennusteista käyttäjän haluamat grafiikat?

Se hakee nuo "raakaennusteet" NOAA:lta, gfs-filut sisltävät kaikki nuo infot, ja ainoastaan piirtää grafiikat + tekee käyttäjn muut laatimat komennot ja laskelmat.

LainaaVoiko noita kosteuskäyrien pampuloita muokata mitenkään?
Noita voi muokata ihan millaiseksi haluaa, kuten poistaa kokonaisia käppyröitä tai tehdä bar-käppyröitä tai mitä sitten haluaa. Se on 100%:sesti käyttäjän muokattavissa. Esim kosteus-käppyrän pampulat löytyvät riviltä 475 komennosta 'set cmark 2', menemällä tuonne GrADS:in dokumentaatio-sivulle (http://www.iges.org/grads/gadoc/gadocindex.html) ja sieltä kohtaan "cmark" löytyy vaihtoehdot.  ;D

Tämä on just se mikä tekee tämän niin uskomattomaksi löydöksi, sillä voi tehdä millaiset käppyrät haluaa (lähes) mistä arvoa tahansa, NOAA:n gfs:ssä on 227 eri arvoa mitä valita josta mun versio meteogrammista käyttää noin 15 arvoa. Dataa löytyy 3 tunnin välein eli 8 dataa per päivä per arvo.
:)

wilei

Hauskaa, että (Open)GrADS ja sen suomat mahdollisuudet on hoksattu myös laajemmin :)

Täytyy kyllä todeta, että omakohtaisten kokemusten (FLC:n karttojen suunnittelun ja toteutuksen) perusteella ko. softa on erittäin mielenkiintoinen ja sen kanssa saa kyllä aikaa palamaan. Ja yhtään suurempien karttamassojen toteuttaminen onkin sitten jo hivenen työläämpää. Knoppina mainittakoon, että esim. FLC:n karttojen työstö kestää tälläi "talviaikaan" noin 50min / GFS-ajo. Kesällä, kun palvelimella on enemmän kuormaa (sama palvelin siis hoitaa sekä tuon GrADS ajon että www-puolen) ajo voikin kestää jo reilusti toistatuntia. Näin vaikka suurin hidaste koko hommassa on datan lataaminen (jota yhtä malliajoa kohden ladataan noin 800megaa). FLC:ssä erilaisia karttoja on nyt tarjolla 32 kpl ja jokaista (pl. sade-ennusteen sisältävät, koska precip. tietoa ei GFS -ennusteissa ole ajankohdalle Z+0) kartta on Z+72 saakka 3h resoluutiolla, eli 24kpl; kaikkiaan siis karttoja pyöräytetään yhden ajon aikana noin 720kpl. Muutama siis.

Pari yleistä vinkkiä:
1) GFS -ennusteiden data kannattaa aina hakea suoraan NOAA:n palvelimilta, jos vain mahdollista. Tähän perusteluna se, että monella muulla palvelimella dataa on karsittu tai muutoin editoitu (laskettu joitain arvoja valmiiksi tai tehty yksikkömuunnoksia), joiden takia niiden käyttö on riskaabelia. Lisäksi kovin harvan ns. kolmannenosapuolen tarjoaman palvelimen paukut riittää siihen, että sieltä dataa luukutetaan yhtään suurempia määriä. Paras lähde on siis NOAAn uusi OPeNDAP -yhdistelmäpalvelin, jolta saa lähes kaiken NOAAn jakaman vapaan materiaalin (ei tarkoittaen että kaikki on käytettävissä ihan miten sattuu, käyttöehdot on jokaiselle aineistolle omansa). Palvelimen osoite, josta data löyty on: h t t p ://nomads . ncep . noaa . gov : 9 0 9 0 /dods/   (sry. osoite "rikottu" tarkoituksella, ettei hakukoneet sitä pommita :)).

2) OpenGrADSista kannattaa olla aina uusin versio, eli 2 alpha -sarjaa. Harmillisesti GrADS:in a6 ja/tai a7 versioita sisältävää ei ole vielä ole OpenGrADSista julkaistu, joten on tyytyminen a5 versioon, ellei sitten itse halua rakennella ja kääntää systeemiä. Itse odotan erityisesti a6 -versiota kovasti, koska ko. versio tuo 99 värin sijaan mahdollisuuden määritellä 255 väriä, ja tuohan mahdollistaa äärimmäisten hyvien väriliukujen käytön ennustekartoissa. Eli myös karttojen visuaalinen näyttävyys ja selkeys on tärkeää.

3) Parhaat ohjeet ovat löydettävissä täältä: http://www.iges.org/grads/gadoc/gadocindex.html  Tuo ohjeisto on GrADSille, mutta koska OpenGrADS pohjautuu GrADSiin (ja vain täydentää sitä valmiin scriptein+yms.) niin samat ohjeet pätevät myös siihen. Osa komennoista on versiosidonnaisia, eli ei kaikki ei välttämättä toimi OG:n jäljessä laahauksen takia. Ja lopuksi: Harjoitus tekee mestarin, eli ohjeita lukemalla, niiden sisällön sisäistämällä ja yksinkertaisesti vain kokeilemalla kokeilemisen perään oppii parhaiten. Tietysti siitä, että ymmärtää lukemansa ja tekemänsä on apua kummasti :P


Lainaus käyttäjältä: Meteorologi - tiistai, 22.09.2009, 21:54
Ja lopuksi tyhmä kysymys: tekeekö Grads itse nuo ennusteet pelkästä sääanalyysista, vai hankkiiko se valmiit "raakaennusteet" NOAA:lta, ja tekee ennusteista käyttäjän haluamat grafiikat?

Olen aikojen saatossa oppinut sellaisen, että yksikään kysymys tai kysyjä ei ole tyhmä, vain vastaajat voivat olla :P
Mutta vastaus:

GrADS ei itsessään tee ennusteita, vaan ennusteet on laadittu NOAA:n puolesta (mallien prosessoinnin statuksen näkee täältä: http://www.nco.ncep.noaa.gov/pmb/nwprod/prodstat/). NOAA siis ajaa GFS -mallin 6h välein ja mallin suoritus alkaa ajanhetkillä 00Z, 06Z, 12Z ja 18Z (Z eli ns. Zulu-time, eli käytännössä UTC-aika) ja se kestää noin 3-4 tuntia. Tuon jälkeen, kun NOAAn "superkoneet" ovat mallin pureskelleet ja tuloksena on GFS-ennuste, se siirtyy jakoon. Sen voi ladata joko tuolta OPeNDAP -palvelimelta, tai sitten ihan FTP:llä tiedostoina omalle koneelleen (myös erilaisia www-käyttöliittymiä on tarjolla valmiiden karttojen saantiin). Kokoa yhdellä ennusteajon datalla on muutama giga. Eli (Open)GrADS käyttää raakadataa, joka on siis neliulotteista numeerista dataa joka on sidottu paikkakoordinaatistoon (keskimäärin 0.5asteen resoluutiolla, saatavilla myös 1asteen ja 2.5asteen tarkkuuteen yleistetyt aineistot) ja korkeustasoon ja toisaalta myös aikaan (resoluutio siis 3h).

GrADS kykenee tekemään vaikeitakin laskutoimituksia datalle, sen ohella että se voi visualisoida sen. Esimerkiksi kastepistettä ei GFS -datasta löydy, vaan se täytyy itse laskea. Sama koskee vaikkapa LLS/DLS -ennusteita (Low Level Shear ja Deep Level Shear) joiden laskentakaavat löytyvät näppärästi valmiina scripteinä OpenGrADSista (tästä kiitos Sääkeskukselle). Eli kuten GrADS nimi aukikirjoitettuna (Grid Analysis and Display System) kertoo, GrADS on tehty hila-muotoiden datan analysointiin ja esittämiseen.

weatherc

Tervetuloa ja kiitos hyvästä infosta :)

Jotta ei innokkaat pelästy niin sanottakoon että OpenGrads ei näköjään lataa dataa muutoin kun mitä tarvitsee eli se ei lataa tuota wilein mainitsemaa 800 megaa ensi työkseen. Mulla nyt kasassa skripti jossa on 8 eri karttaa ja se tekee ne noin parissa minuutissa kun ottaa yhden aikasekvenssin per kartta, en ole vielä kokeillut että kuin kauan kestää tehdä esim. 24 sekvenssiä (72 tuntia) muuta kun yhdellä kartalla kun kokeilin itse skriptiä.
Sen huomasin tuon meteogrammin kanssa että mitä enemmän tekee laskelmia sen kauemmin se (luonnollisesti) kestää tehdä niitä.

Lainaa2) OpenGrADSista kannattaa olla aina uusin versio, eli 2 alpha -sarjaa. Harmillisesti GrADS:in a6 ja/tai a7 versioita sisältävää ei ole vielä ole OpenGrADSista julkaistu, joten on tyytyminen a5 versioon, ellei sitten itse halua rakennella ja kääntää systeemiä. Itse odotan erityisesti a6 -versiota kovasti, koska ko. versio tuo 99 värin sijaan mahdollisuuden määritellä 255 väriä, ja tuohan mahdollistaa äärimmäisten hyvien väriliukujen käytön ennustekartoissa. Eli myös karttojen visuaalinen näyttävyys ja selkeys on tärkeää.

Juu, sitä täälläkin odotellaan jo, a5-versio täällä on käytössä. Mulla tuli jo melkeen nuo 99 väriä täyteen, ei ole kun kymmenkunta enää vapaana  8)
Tuo 255 väriä:hän tarkoittaa kaikkia värejä rgb-skaalassa :)

wilei

Lainaus käyttäjältä: weatherc - keskiviikko, 23.09.2009, 11:43
Jotta ei innokkaat pelästy niin sanottakoon että OpenGrads ei näköjään lataa dataa muutoin kun mitä tarvitsee eli se ei lataa tuota wilein mainitsemaa 800 megaa ensi työkseen. Mulla nyt kasassa skripti jossa on 8 eri karttaa ja se tekee ne noin parissa minuutissa kun ottaa yhden aikasekvenssin per kartta, en ole vielä kokeillut että kuin kauan kestää tehdä esim. 24 sekvenssiä (72 tuntia) muuta kun yhdellä kartalla kun kokeilin itse skriptiä.
Sen huomasin tuon meteogrammin kanssa että mitä enemmän tekee laskelmia sen kauemmin se (luonnollisesti) kestää tehdä niitä.

Ilmaisin siis itseäni hieman epäselvästi :) Eli GrADS (riippumatta olipa variantti Open taihi ei) lataa suoria netti"lähteitä" käytettäessä vain kulloiseekin tarvittavan datan. Eli ensiksi luodaan yhteys palvelimelle, jonka jälkeen dataa ladataan sen mukaan mitä piirretään ja miten paljon. Ainoana heikkoutena on oikeastaan se, että GrADS ei osaa välimuistittaa dataa. Eli käytännössä tämä merkitsee sitä, että jos tekee meteogrammeja ja karttoja, jotka sisältävät molemmat vaikkapa lämpötilatiedon, niin se lämpödata ladataan erikseen sekä meteogrammeja että karttoja varten. Nopeimmillaan FLC:nkin kohdalla yksittäiset kartat pyörähtävät GrADSilla valmiiksi alta sekunnin, mutta kokonaisuuden prosessointi kestää pitkään, eikä vähäisimpänä tätä hidasta datan jatkuva lataaminen rapakon takaa (l. USA:sta), jonne verkon latenssit ovat kohtalaisen suuret ja verkot suhteellisen ruuhkaisia. Sen sijaan CPU:ta GrADS ei oikeastaan nimeksikään käytä, ainakin kun puhutaan yksinkertaisista kartoista :) DLS/tms. suuria datamääriä ja paljon erilaisia suureita ja laskutoimituksia sisältävien karttojen osalta hommahan on toinen, mutta silloinkin valtaosa ajasta tuntuu menevän datan hakuun.

Toisaalta kannattaa huomioida, etenkin jos suurempaa määrää karttoja/meteogrammeja aikoo tehdä ja useammin, että miten sitä GrADS:ia pyöritellään. Eli vaikka OpenGrADSille löytyy PHP-kirjasto, en suosittele sen käyttöä. PHP kun ei ole laisinkaan sopiva tuohon hommaan; PHP:n osalta CPU käyttö tuppasi testeissä olemaan 100% tasoa ja itse GrADS -prosessin (jota PHP:sta käytettiin pipen kautta) vain muutamia prosentteja hajanaisesti. FLC:n tarpeisiin olen tehnyt "pienen" PHP -scriptan, joka tekee joukon tarkistuksia ja sen jälkeen tuottaa GrADS -scriptin, joka sisältää yksinkertaisesti kaikkien karttojen teon yksittäisinä komentojoukkoina. Kaiken suorittamisesta sitten vastaa simppeli BASH -scripti :)

Voin antaa jotain vinkkejä tuohon vielä lisää, jos tarvetta/halua on...

Lainaus käyttäjältä: weatherc - keskiviikko, 23.09.2009, 11:43
Juu, sitä täälläkin odotellaan jo, a5-versio täällä on käytössä. Mulla tuli jo melkeen nuo 99 väriä täyteen, ei ole kun kymmenkunta enää vapaana  8)
Tuo 255 väriä:hän tarkoittaa kaikkia värejä rgb-skaalassa :)

99 väriä on kyl käsittämättömän vähän, eikä se riitä oikein mihinkään. 255 on jo huima parannus, ja esim. tekemäni paletin värit ovat hyvä "setti" :) Ainoa vain, että OpenGrADSista sais vaan todellakin tulla se a6 tai a7 pohjainen jo ulos, mutta kehitys vain tuntuu jämähtäneen paikoilleen :|
Knoppina mainittakoon, että 255 väriin ei kyllä koko rgb -skaalaa saa; RGB-väriskaala kun sisältää sen 2563 eli 16,7miljoonaa väriä ;)

weatherc

Jups, 12 karttatyypin setti valmiina :)
Ihan simppeliähän tuo karttojen väsääminen on kun ensin sai ensimmäisen kasaan ja löysi jujut että mikä komento tekee mitäkin.
Nyt vielä skriptin testi-ajo jossa laaditaan 24 karttaa per tyyppi. Tarvis varmaan siirtää koko höskä tuolle alhaalla olevalle webkamera-koneelle jotta se saa porskutta rauhassa ja Fling-FTP puskemaan ne serverille.

Ajattelin laittaa SystemSchedulerin käynnistämään ajon bat-filun avulla joka vääntää ensin kasaan päivämäärän sekä tunnin.

LainaaToisaalta kannattaa huomioida, etenkin jos suurempaa määrää karttoja/meteogrammeja aikoo tehdä ja useammin, että miten sitä GrADS:ia pyöritellään. Eli vaikka OpenGrADSille löytyy PHP-kirjasto, en suosittele sen käyttöä. PHP kun ei ole laisinkaan sopiva tuohon hommaan; PHP:n osalta CPU käyttö tuppasi testeissä olemaan 100% tasoa ja itse GrADS -prosessin (jota PHP:sta käytettiin pipen kautta) vain muutamia prosentteja hajanaisesti.

Hyvä tietää että tuo versio kannattaa unohtaa saman tien, sitä kyllä pikkasen arvelinkin että PHP syö ihan likaa tehoja tätä varten, varsinkin silloin kun muutenkin on liikennettä sivuilla.

Lainaa99 väriä on kyl käsittämättömän vähän, eikä se riitä oikein mihinkään. 255 on jo huima parannus, ja esim. tekemäni paletin värit ovat hyvä "setti" Ainoa vain, että OpenGrADSista sais vaan todellakin tulla se a6 tai a7 pohjainen jo ulos, mutta kehitys vain tuntuu jämähtäneen paikoilleen :|
Knoppina mainittakoon, että 255 väriin ei kyllä koko rgb -skaalaa saa; RGB-väriskaala kun sisältää sen 2563 eli 16,7miljoonaa väriä

No joo, tais olla aivot lomalla mulla tuossa  :)
Itse aloitin paletin laatimisen NWN:än kartan numeropaletista josta sain hyvän pohjan copy-pstella php-skriptistä jolla ne tein. ja "pikkasen" muokkaen sitä niin ihan kohtalaisen hyväksi tuli.

meteorologi

Tuulen suuntaa ei taida saada mitenkään meteogrammiin? Tuulen suuntaa ei löydy NOAA:n datasta.

wilei

Lainaus käyttäjältä: Meteorologi - keskiviikko, 23.09.2009, 16:51
Tuulen suuntaa ei taida saada mitenkään meteogrammiin? Tuulen suuntaa ei löydy NOAA:n datasta.

Tuulen suuntaa ei GFS -datasta löydy suoraan sellaisenaan, kuten ei myöskään tuulennopeutta. Tähän on yksinkertainen selitys; tuuli ilmaistaan suuntavektoreilla. Eli tuulesta löytyy erikseen sen "X ja Y -komponentit", tässä tapauksessa U ja V -komponentit. Muuttujat ovat ugrdprs ja vgrdprs (HUOM! nämä kaksi sisältävät tuulen eri painetasoilla! Mutta esim. 10m "pintatuuli" löytyy muuttujista ugrd10m ja vgrd10m. Eli tarkista tarvittavat muuttujat DODs:in info-sivulta!).

Tuulidatan luonteesta johtuen, karttaesityksiä varten sille on ihan oma tyyppinsä, streamline, eli kyseessä on virtauskuvio, joka ei sisällä mitään tietoa tuulennopeudesta. Eli jotta kartalta näkyisi myös nopeus, täytyy kartalle ensiksi piirtää shaded eli värjätty tuulennopeus ja sen päällä virtauskuvio, joka sitten kertoo suunnan. Puhdas nopeus saadaan laskettua mag() -funktiolla. Suunta tietoa varten täytyy vähän kahlata nettiä; senkin sieltä saa, mutta enpä muista heti että miten.

Toisaalta jos halutaan kartta, jossa tuuli (suunta ja nopeus) esitetään "väkäsin", niin tällöin oikea karttamuoto on tserbarb. Tällöin tuloksena siis sellainen esitys, kuin vaikkapa Wetterzentralenin tuulikartoissa on.