31.03.2020 Ab dem heutigen 12Z-Lauf wird der Input der GFS-Daten von 3-stündlich auf stündlich geändert. NOAA hat diese Umstellung zwar schon vor Längerem durchgeführt, jedoch habe ich bis jetzt nie einen Vergleich gemacht, da ich keine große Verbesserung erwartet habe. Nun habe ich es doch mal getestet und muss sagen, dass die Ergebnisse schon doch um einiges besser sind. Daher ab jetzt stündlicher GFS-Input. Kleiner Nachteil: Der Download dauert nun in der Früh eine Stunde statt 20 Minuten und am Abend 4 Stunden statt einer Stunde und 20 Minuten (der NOAA-FTP-Server gibt am Abend nur 20 Mbit/s her). Allerdings ist mir nun auch aufgefallen, dass die GFS-Daten mittlerweile etwas früher online sind (vermutlich seit Umstellung zu FV3). Ich habe das Download-Skript (das mit mehreren Verbindungen gleichzeitig lädt) so umgestellt, dass es in der richtigen Reihenfolge downloadet (der Einfachheit halber war das davor etwas anders programmiert). So kann nun mit dem Download sogar schon zu einem Zeitpunkt begonnen werden, an dem erst ein Teil der Daten online ist, da die verbleibenden noch online kommen bevor sie zum Download an der Reihe sind. Insgesamt kann so der Download eine Stunde früher beginnen.
Damit haben wir beim 00Z-Lauf sogar einen Gewinn von 20 Minuten und beim 12Z-Lauf einen Verlust von einer Stunde und 40 Minuten.
17.03.2020: Es wurde eine Funktion hinzugefügt, die die Differenz zwischen Modell- und echter Höhe ermittelt und dann mit 1° pro 100 m bei der Temperatur dazurechnet. Das musste man bis jetzt ungefähr schätzen, jetzt wird es automatisch gemacht. Damit werden genauere Temperatur-Vorhersagen erzielt.
Zusätzlich wurde ein Fehler bei der Koordinatenermittlung behoben: Bis jetzt wurde einfach das erste Ergebnis der Nominatim-API (OpenStreetMap) verwendet, was aber zu Fehlern geführt hat. Denn häufig werden Boundary-Objekte zurückgeliefert (die Fläche der Gemeinde beispielsweise), bei denen kein Center Point definiert ist. Sprich, der Center Point wird automatisch berechnet und liegt dann irgendwo im Nirgendwo. Besonders blöd ist das natürlich bei Orten, die in den Bergen liegen, da dann die Höhe stark abweicht. Für Imst wurden beispielsweise die Koordinaten zwischen den Gipfeln Hahnleskopf und Arzeinkopf zurückgegeben. Ich habe den Code also so umgeändert, dass so lange zum nächsten Suchergebnis gesprungen wird, bis ein Objekt gefunden wird, das nicht dem Typ Boundary entspricht. So funktioniert es, denn i.d.R. sind im OpenStreetMap auch die Orte selbst als Punkt eingezeichnet.
01.03.2020: Da ich aktuell eine Ausbildung absolviere, die der Staat nicht bezahlt, bin ich auf Geldleistungen meiner Verwandten angewiesen. Somit muss ich Strom sparen (bis jetzt 30€/Monat nur für Wetterberechnungen) und kann daher keine 1.3km-Läufe mehr berechnen. Das ist aber kein Problem, denn meine aktuellsten Untersuchungen haben gezeigt, dass die 1.3km-Domain eigentlich nur bei stark konvektiven Wetterereignissen Verbesserung bringt (also fast nur im Sommer). Bei normalen Wetterbedingungen wird eher sogar zu wenig Niederschlag vorhergesagt. Die Umstellung bringt den Vorteil, dass die Veröffentlichung nun immer um ca. 5 Stunden früher stattfindet.
25.12.2019: Seit heute wird der akkumulierte Niederschlag in den Meteogrammen pro Tag zurückgesetzt. Somit lassen sich die Tagessummen leicht ablesen.
22.11.2019: Das System wurde auf WRF 4.1.2 umgestellt und ist somit am neuesten Stand. Testläufe haben ergeben, dass die neuere Version spürbar bessere Ergebnisse bringt. Getestet wurden Niederschlag und Bewölkung. Der erste Lauf, der mit der neuen Version berechnet wurde ist 22.11.2019 00Z (1.3km wegen Zeitmangel nicht berechnet).
Kontakt: thomas.testor.33[at]gmail.com (At-Zeichen nicht angezeigt, weil ich sonst Spam bekommen würde.)
Gesetzlich verpflichtende Angaben:
Mein Name: Thomas Testor
Mein Wohnort: normalerweise Innsbruck, aktuell wegen einer Ausbildung Imst
News-Archiv/Meilensteine:
14.06.2019: Es sind ein paar Läufe ausgefallen, da die NOAA auf ihrem FTP-Server eine neue Dateinamen-Syntax eingeführt hat, die in meiner selbst geschriebenen Automatisierung natürlich angepasst werden musste.
Auch die vertikalen Schichten der GFS-Grib-Dateien wurden von 32 auf 34 erhöht (da das FV3-GFS nun operationell läuft). Das musste ich natürlich auch anpassen.
Vor ein paar Tagen wurden auch die Parameter Niederschlag 6h und Niederschlag 24h eingeführt. Diese können bspw. dazu verwendet werden, die Modell-Ergebnisse mit SYNOP-Daten zu vergleichen, um so eine zeitlich begrenzte Verifizierung durchzuführen. Evtl. reiche ich noch den Parameter Niederschlag 12h nach.
10.02.2019: Vor einigen Tagen wurde das Modell zur neuesten Version 4.0.3 upgedatet. Zuletzt wurde 3.9 verwendet. Mit der Version 4.0.1 habe ich mit einem eigenen Testsystem in den letzten Monaten mehrere Tests durchgeführt: keine wirklichen Veränderungen. Jetzt mit 4.0.3 sind die Unterschiede etwas größer, aber immer noch nicht von Bedeutung. Es kann aber gut sein, dass sich eine signifikante Verbesserung erst bei hochkonvektiven Ereignissen im Sommer zeigt.
Eigentlich wurde das Update durchgeführt, weil sich am Testsystem eine bessere Performance gezeigt hat. Leider ging dies über das operationelle System nach hinten los (hier wird MPI mit 3 Rechnern verwendet). Um dem neuen Schema für vertikale Schichten gerecht zu werden, wurden anfangs 33 Schichten verwendet, was sich mit der am Testsystem ermittelten Performance hätte ausgehen müssen. Da es sich nicht ausgegangen ist wurden die Schichten nun wieder auf 30 vermindert und so kommen wir wieder fast auf die 3,5 Tage. Ich denke so kann man es jetzt mal lassen. Ich bin gespannt, wie die Ergebnisse des 4.0.3 im Sommer ausfallen.
04.02.2019: Es wurde ein eigentlich peinlicher Fehler behoben: Bis jetzt wurde die Temperatur nicht für 2m über dem Boden, sondern für irgendeine andere Höhe angegeben. Alle Karten die ab heute veröffentlicht werden sind richtig. Da die Meteogramme individuell generiert werden sind dort alle richtig.
12.01.2019: Mittlerweile kann man sagen, dass alle Fehler der Umstellung ausgemerzt sind. Es hat sich auch herausgestellt, dass der angestrebte Zeitplan funktioniert: 3,5 Tage bei der 4km- und 1,5 Tage bei der 1.3km-Domain. Die 1.3km-Domain startet 12h verzögert.
07.01.2019: Wie üblich läuft so eine große Umstellung nicht sofort fehlerfrei, daher sind die Läufe teils ausgefallen, teils nicht vollständig berechnet. Heute wurden einige Fehler beseitigt - mal schauen ob es ab morgen fehlerfrei läuft.
06.01.2019: Seit gestern Abend ist die mehrtägige Umstellung für einen leiseren Betrieb fertig (es sind dennoch nur wenige Läufe ausgefallen). Es wurden größere Kühlkörper, größere Lüfter und schließlich SSDs eingebaut. Das hat auch den positiven Nebeneffekt, dass nun die Meteogramme um ein Vielfaches schneller laden. Diese brauchen statt 20 - 30 Sekunden nur noch 1 - 2 Sekunden, was eine Verbesserung um Faktor 17 bedeutet.
Diese Verbesserung bedeutet auch, dass die Systeme von nun an wieder in der Nacht laufen können, denn sie sind selbst unter Volllast fast mucksmäuschenstill. D.h. ab heute werden die Läufe pro Tag wieder auf 2 reduziert, jedoch wird die Abdeckung der 1.3km-Domain auf Österreich erweitert. Wahrscheinlich werden die 12/4km-Läufe dann immer 3,5 Tage und die 1,3km-Läufe immer 1,5 Tage (Start des Vorhersage-Zeitraums um 12 Stunden verzögert) lang sein. Darüber werde ich noch informieren und wahrscheinlich diesmal auch in einer Grafik veranschaulichen.
28.11.2018: Seit einigen Wochen gibt es nun wieder eine sehr hochauflösende Domain (1.3km). Diesmal nur für das Bundesland Tirol und nur für einen Tag, da sonst die Vorhersagen zu lange brauchen würden.
Ebenso seit ein paar Wochen gibt es nun zwei Bewölkungs-Parameter: Bewölkung (clfr; berechnet aus Luftfeuchtigkeit) und Bewölkung 2 (cldfra; eigentliche Wolkenausgabe des WRF). Damit lässt sich mehr über die Treffsicherheit sagen. Am besten müsste ein Schnitt aus beiden Werten sein.
28.10.2018: Nach drei Tagen intensiver Arbeit kann ich nun stolz meine neuen Meteogramme präsentieren. Diese sind modern mit Mouseover-Anzeige und responsive (vielen Dank an Chart.js). Auch hier lassen sich die letzten 9 Läufe anzeigen. Die Position lässt sich entweder mittels Koordinaten oder mittels des Ortsnamens angeben. Vielen Dank auch hier für das äußerst nützliche Tool Nominatim von OpenStreetMap.
15.10.2018: Die Anzahl der vertikalen Schichten wurde von 35 auf 30 heruntergesetzt. Laut meinen Überprüfungen geht sich somit bei gleicher Qualität (in den meisten Fällen) nun auch am Abend ein voller Lauf aus (annähernd 3 Tage). Auch die Veröffentlichungs-Zeitpunkte sind nun etwas früher.
06.10.2018: Noch eine neue Funktion: Es gibt jetzt über der Modellgrafik eine Zeitangabe. Somit sieht man auch den Wochentag und man sieht die Zeitangabe auch dann, wenn man in die Karte hineinzoomt.
Des Weiteren befindet sich das Menü nun auf der linken Seite wenn die Breite ausreicht. So muss man nicht ständig hin- und herscrollen, wenn man den Parameter oder Ähnliches ändern möchte.
06.10.2018: Leider gab es in der zuletzt eingeführten Funktion noch einen kleinen Fehler bei dem die Lauf-Informationen fälschlicherweise aus dem Cache abgerufen wurden. Dieser ist jetzt behoben.
Dass mehrere Läufe ausgefallen sind hängt mit einer anderen Änderung zusammen, die jetzt auch abgeschlossen ist und für mehr Stabilität während der Berechnung sorgen soll.
02.10.2018: Die im letzten Kommentar erwähnte Funktion zum automatischen Wechseln des Laufes mit gleichbleibendem Termin wurde nun fertiggestellt. Mit diesem hochwertigen Feature verfüge ich nun über ein Alleinstellungsmerkmal, denn so etwas habe ich in dieser Form noch nirgends gesehen und ich habe mir schon nahezu alle ortsrelevanten Wetterwebsites angeschaut. So ähnlich gibt es das nur bei Kachelmannwetter und weatheronline.co.uk, jedoch ist das Schalten durch die Läufe wesentlich umständlicher wie bei mir. Bei mir erfolgt das einfach und schnell durch einen Tastendruck.
02.10.2018: In Zukunft soll es nicht mehr nur die letzten 4 sondern die letzten 9 Läufe zum Abruf geben. So können für einen bestimmten Termin alle verfügbaren Läufe abgerufen werden, daher diese Anzahl. Das Vergleichen von Läufen für denselben Termin gibt Aussage über die Treffsicherheit der Prognose. Die Website wird auch noch so programmiert, dass das Hin- und Herschalten zwischen den Läufen so funktioniert, dass man auf demselben Termin bleibt.
10.09.2018: Es sind vereinzelt Läufe ausgefallen. Das lag an einer nicht einwandfrei arbeitenden Zeitschaltuhr (eigentlich WLAN-Schalsteckdose). Ich habe nun eine richtige Zeitschaltuhr angeschlossen, die eigentlich funktionieren müsste. Damit sollten wieder alle Läufe gewöhnlich veröffentlicht werden.
28.08.2018: Es ist wieder WRF 3.9 im Einsatz.
25.08.2018: Habe nun herausgefunden, dass das neue WRF 4.0 doch nicht so gut zu sein scheint. Allerdings würde ich das gerne über einen längeren Zeitraum testen bevor ich wieder die ältere Version verwende. Also wird es noch einige Tage 4.0-Vorhersagen geben.
21.08.2018: Da mich die Experimente mit dem neuen WRF-Modell 4.0 sehr positiv überrascht haben, habe ich mich dazu entschlossen, den regelmäßigen Betrieb wieder aufzunehmen. Die Hitzeentwicklung in meiner Wohnung durch die Rechner macht mittlerweile auch keinen Unterschied mehr, da es auch ohne diese Rechner schon so heiß ist, dass man einen Ventilator braucht. Ich freue mich, diese hochqualitativen Daten wieder anbieten zu können. Kachelmannwetter hat zwar auch sehr genaue Daten, jedoch ist die Kartenbedienung ein einziger Krampf und für 7 ? im Monat bekommt man nur eine lächerliche GIF-Download-Funktion, die ewig lange lädt. Da ist die Bedienung bei mir wirklich komfortabler, da sie auf Effizienz ausgelegt wurde. Wenn Sie sich also für professionelle und hochwertige Wettervorhersage-Daten für den Alpenraum und rundherum interessieren, sind Sie hier genau richtig. Und bei mir bekommen Sie das kostenlos.
Übrigens: Die Verwendung von hohen Auflösungen wie etwa 1,3 bzw. 2km bringen nur in seltenen Fällen bessere Ergebnisse und ziehen die Läufe unnötig in die Länge. Das hier ist denke ich jetzt die beste Lösung - die Daten sind bei der Veröffentlichung relativ aktuell.
20.7.18: Zuletzt wurde das Wettermodell eingestellt. Da ich immer wieder vereinzelt Experimente mit ihm durchführe, habe ich mir gedacht, das könnte man ja auch online stellen, vielleicht interessiert es ja jemanden.
29.05.2018: Das System war heute immer noch nicht ganz fehlerfrei. Wenn ab jetzt alles funktioniert sind nur die heutigen 00Z- und 06Z-Läufe verzögert.
28.05.2018: Der heutige 06Z-Lauf hat nur bis morgen 15 Uhr (17 Uhr Lokalzeit) berechnet. Das liegt an einem kleinen Fehler in der Konfiguration - der aktuell in Berechnung befindliche Lauf, der heute noch erscheint, sollte dann korrekt berechnet werden.
28.05.2018: Aus finanziellen Gründen musste ich die Rechner aus der Lagerbox aussiedeln und dachte dann, dass ich den Service wegen der hohen Lautstärke der Rechner in meinem Wohnbereich einstellen muss. Heute jedoch kam mir zum Glück der Gedanke, dass ich nur noch 12- und 4km-Domänen berechnen kann. Das geht viel schneller, das heißt die Lärmbelästigung hält sich in Grenzen (unter anderem auch, weil ich einen Weg gefunden habe, den Server leiser zu machen). Die 2km-Domain war nur in gewissen Fällen besser als die 4km-Domain, das heißt, es ist kein großes Problem, wenn diese wegfällt. Großer Vorteil ab heute: Das Datenmaterial ist bei der Veröffentlichung viel aktueller und wir haben nun drei Läufe pro Tag, d.h. evtl. ist diese Konfiguration sogar die bessere (bis jetzt war ich besessen von hohen räumlichen Auflösungen).
09.05.2018: Die meisten der letzten ca. 5 Läufe waren nicht vollständig oder gar nicht berechnet. Das müsste daran gelegen haben, dass das GFS-Modell in letzter Zeit offenbar länger zum Berechnen braucht. Es wurde also der gesamte Zeitablauf meines Wettermodells um 10 Minuten in die Zukunft verschoben. Die Änderungen zeigen sich dann mit Veröffentlichung des Laufes 09.05. 00Z.
01.04.2018: Das Wettermodell scheint nun wieder normal zu funktionieren. Vor ein paar Tagen wurde nocheinmal eine Änderung gemacht: Durch den verbesserten Zeitablauf konnten die Veröffentlichungs-Zeitpunkte folgendermaßen geändert werden:
2km: ca. 30min früher
4km: ca. 1h 15min früher
12km: ca. 1h 30min früher
Um nochmal auf die Änderung vom 25.3. zurückzukommen:
Bis dorthin war das so: Gewisse Scripte öffneten zur parallelen Abarbeitung mehrere Terminals (in der GUI), es konnte aber nicht überprüft werden, ob die Terminals schon fertig sind um im Script fortzufahren. Daher musste eine entsprechend großzügige Wartezeit festgelegt werden, damit auch Schwankungen das System nicht gefährdeten.
Jetzt funktioniert das Ganze so: Die parallel abzuarbeitenden Scripte/Prozesse werden in den Hintergrund geschickt und das Mutter-Script sozusagen wartet, bis diese ausgeführt worden sind. Sobald also der letzte Prozess, der in den Hintergrund geschickt wurde fertig ist, fährt das Mutter-Script in seiner Arbeit fort. Das funktioniert also trotz Schwankungen in der Abarbeitungsdauer der Kind-Scripte ohne irgendwelche Pufferzeiten. Somit haben wir einen besseren Zeitablauf und daher glücklicherweise diese früheren Veröffentlichungszeiten.
Hinweis zur Zukunft dieses Services:
Die Wettervorhersage soll in Zukunft noch genauer werden. Das kann man auf zwei Arten machen:
- Erhöhung der vertikalen Schichten, Erhöhung der Auflösung, Erhöhung der Domaingröße, evtl. auch Verringerung der Timestep-Dauer
- erhebliche Verschnellerung des Berechnungsvorganges, sodass die Daten bei der Veröffentlichung wesentlich weniger alt sind und man auch noch einen 06Z- und 18Z-Lauf einführen kann.
Für welchen Weg ich mich entscheide bzw. ob es eine Kombination aus Beidem wird, wird sich in Zukunft zeigen.
25.03.2018: Es wurde eine Optimierung der Scripte, die für die Automatisierung zuständig sind, vorgenommen. Dadurch wurde der Zeitablauf verbessert und das System läuft nun völlig ohne GUI (Denn die GUI bereitete in den letzten Tagen erhebliche Kapazitätsprobleme.). Allerdings kommt es dadurch immer noch teilweise zu Ausfällen. Ich bitte darum diese zu entschuldigen - vielen Dank!
01.10.2017: Änderungen in den letzten Tagen:
-mp_physics auf WSM6 geändert, da bei Thompson eigenartige Effekte an den Rändern der Bewölkung aufgetreten ist.
-Umstellung bei der Bewölkung auf das ARWpost-field clfr, das deutlich realisitischer ist. Bitte beachten Sie, dass tiefe Wolken nur bis 2km Höhe gehen und dass daher bei den Bergen oft Lücken angezeigt werden. Den Ausschnitt den man über Bayern manchmal sieht (ich vermute bei Hochnebel) kann ich mir allerdings nicht erklären. Ich habe schon einiges durchprobiert, bringe ihn aber nicht weg. Diesbezüglich habe ich WRFhelp kontaktiert und warte auf eine Antwort. Clfr kann keine Total clouds anzeigen, daher gibt es jetzt die Aufteilung auf tief, mittel, hoch.
-Vertikale Schichten auf 35 erhöht, da die Rechner noch nicht die ganze Zeit ausgelastet waren. Das ist jetzt immer noch nicht ganz der Fall, daher habe ich sie jetzt auf 40 erhöht.
01.08.2017: Die letzten drei 4km-Läufe wurden verkürzt ausgegeben. Das liegt wahrscheinlich an der Feedback-Option, die ich testweise aktiviert hatte - daher habe ich sie nun wieder deaktiviert.
30.07.2017:
- Die Domainkonfiguration wurde optimiert.
- Die Küstenlinien sind verpixelt da an den GFS-Daten etwas geändert wurde. Daher wurde WPS auf V3.9.0.1 aktualisiert - ab der Veröffentlichung morgen in der Früh sollte der Fehler nicht mehr auftreten.
- Seit 5 Läufen werden nun 45 vertikale Schichten und Timesteps von 60s verwendet. Davor mit 50 Schichten und 72s ist das Modell immer nach einer gewissen Zeit abgestürzt. Bei den letzten 5 Läufen ist das nicht mehr passiert.
Übrigens ist der Ping über LWL nich viel besser (fast gleich gut). Der hohe Ping lag an der Netzwerkbrücke für die virtuelle Maschine. Seit 20.07. ist nichts mehr virtualisiert und das parallele Rechnen funktioniert sehr gut.
21.07.2017: Die aktuellen Verzögerungen treten wegen folgender Umstellung auf:
Ab heute gibt es einen 00Z- und einen 12Z-Lauf. Beide haben die gleiche Zeitraum-Konfiguration. Das heißt es wird erstmals zweimal täglich ein Update der 2km-Domain geben.
Dafür verringt sich die Vorhersagedauer der 4- und 12-km-Domain auf 3,5 Tage. Diese Konfiguration ist meiner Meinung nach besser, da die Vorhersagen so jenachdem wann sie angeschaut werden aktueller sind und da Vorhersagen für den 4. und 5. Tag eh nur noch mit 65- bis 50-prozentiger Wahrscheinlichkeit stimmen.
20.07.2017: Da eine umfangreiche Umstellung vorgenommen werden musste sind einige Läufe ausgefallen. Jetzt allerdings ist es fertig und das Modell rechnet nun auf beiden Rechnern.
16.07.2017: Infiniband über Kupfer hat zum Zusammenschalten der beiden Rechner nicht so wirklich funktioniert (zu hoher Ping), daher warte ich momentan auf die bestellten Teile für eine Übertragung über einen LWL. Diese sollten am Dienstag und am Mittwoch eintreffen.
alter PC: Intel i7 der 3. Generation
neuer PC: AMD Ryzen 7 1800X
08.07.2017: Der neue Rechner ist nun da und das Modell wurde bereits so angepasst, dass es auf beiden Rechnern laufen kann. Das wird jedoch erst ab ca. Dienstag so gemacht, denn dann kommen die Infiniband-Karten, die ich zum Vernetzen der PCs benötige. Das heißt fürs Erste haben wir "nur" die 1,8-fache Leistung und ab Dienstag sollten wir dann die 2,8-fache Leistung haben. Das heißt, voraussichtlich wird die Berechnung ab Dienstag wieder nach dem üblichen Zeitplan erfolgen.
alter PC: Intel i7 der 3. Generation
neuer PC: AMD Ryzen 7 1800X
06.07.2017: Da das Modell durch die Erhöhung der vertikalen Schichten und der Verringerung der Timestep-Dauer um einiges längsamer geworden ist wurde bereits neue Hardware bestellt, mit der die alte in den nächsten Tagen ergänzt werden soll (Rechenverbund). In den nächsten Monaten wird die Rechenleistung wahrscheinlich Schritt für Schritt erhöht für noch genauere Wettervorhersagen.
Übrigens konnte der Zeitplan im Positiven angepasst werden, da der FTP-Server der NOAA, von dem ich meine Eingabedaten bekomme, nun nicht mehr 30 sondern 90 Mbit/s bietet.
04.07.2017: Durch die Erhöhung der veritkalen Schichten von 30 auf 50 ist das Modell nicht mehr stabil gelaufen. Daher musste die Timestep-Dauer verringert werden. So braucht das Modell viel länger zum Berechnen, daher muss erst ermittelt werden, wie lang die Wettervorhersagen in Zukunft sein können.
02.07.2017: Erhöhung der vertikalen Schichten von 30 auf 50 für noch genauere Wettervorhersagen. Wegen der begrenzten Rechenleistung (wird wahrscheinlich noch aufgestockt) sind jetzt nur noch 3,5 Tage beim Hauptlauf und 1,80 Tage beim Nachmittagslauf möglich.
26.06.2017: Update des Wettermodells von 3.7.1 auf 3.9.
ca. Feber 2017: Vollständige Automatisierung des Wettermodells durch Linux-Scripte (davor war nur teilweise automatisiert). Dadurch wurden fixe Veröffentlichungszeiten und ein weiterer Nachmittagslauf möglich.
Zeit unbekannt: Hinzugabe einer 12km-Domäne für noch genauere Vorhersagen.
ca. Feber 2016: Start dieses Wettermodells. Es gab beinahe tägliche Updates mit einem Vorhersagezeitraum von 5,5 Tagen bei der 4km-Domäne und 1,80 Tagen bei de 2km-Domäne.