http://www.heise.de/tr/Supercomputer-der-naechsten-Generation–/artikel/108451
“Trotz der Leistungsfähigkeit heutiger Supercomputer sind sie noch immer nicht in der Lage, Algorithmen auszuführen, die das Wetter in einer Auflösung bis herunter auf einem Kilometer vorhersagen können.”
Global nicht, aber lokal! Nesting wird mit keinem Wort erwaehnt.
Zur Evaluierung der raeumlichen Verteilung der Veraenderungen der Temperatur-/ und Windverteilung sollen Karten der Differenzen der mittleren Windgeschwindigkeiten und Temperaturen fuer die zwei Zeitscheiben erstellt werden.
Es entstehen also 2 Karten.
Benoetigte Skripte:
Erstellen der dreimonatigen Mittelwerte fuer Temperatur und Windgeschwindigkeit. Berechnen der Differenzen. Darstellung als Karte inklusive kartenueblicher Elemente.
Das vorrangige Interesse der Diplomarbeit liegt in moeglichen Veraenderungen der Parameter |v| und T bzw. RAIN. Es soll eine Veraenderung der Verteilung der Windgeschwindigkeiten abgeprueft werden. Diese soll sowohl optisch als Darstellung der Wingeschwindigkeits-Verteilungskurven als auch statistisch als Vergleich der Mittelwerte durchgefuehrt werden. Das gleiche gilt fuer die Temperaturverteilungen, wobei hier allerdings zwischen Tag (0600 - 1800) und Nacht (1800 - 0600) unterschieden wird.
Wobei sich die Frage stellt, ob es nicht korrekter ist, “Nacht” mit Sonnenuntergang bis Sonnenaufgang zu beschreiben. Das allerdings herauszufiltern ist wohl recht aufwendig. –> Alternative Berechnung aus Sonnenstandsrechnern: 0600 - 2100 Tag, 2100 - 0600 Nacht.
Notwendige Skripte:
Erzeugen eines Histogramms mit definierten Schrittweiten aus den out01 Daten fuer beide Zeitscheiben. Im Histogramm befinden sich die Daten jeweils eines Monats, so dass im Endeffekt 3 Histogramm erzeugt werden. Darstellung dieser Histogramme in einem Plot fuer jew. 2 Zeitscheiben.
Berechnen eines U-Tests (oder eines anderen, schaeferen parameterfreien Mittelwerttests) auf dem 5% zum Abtesten der Signifikanz moeglicher Trends.
Erweiterung des ersten Skripts um die Moeglichkeit, je nach Zeitpunkt ein anderes Histogramm zu befuellen.
Modellierung
5km C20_1 Laeufe fertig gerechnet.
1km A1B_1 Laeufe fertig gerechnet.
1km C20_1 Laeufe fertig gerechnet.
Alle Modelldaten fertig prozessiert.
Alle Modelllaeufe gestartet.
Alle Modellierprozeduren beschrieben.
Text
Einleitung geschrieben.
Alle Literaturquellen vorhanden und formatiert.
Zusammenfassung geschrieben.
Erste Druckversion fertig.
Theorie
Beschreibung konvektiver Prozesse fertig geschrieben.
Parametrisierung als Vorgehensweise zur Abbildung subskaliger Prozesse geschrieben.
Auswertung
Alle Auswertungsskripte geschrieben.
Methodik der Auswertung geschrieben.
Festgelegt (schriftlich), was an Auswertung gemacht wird.
Vergleich mit Beobachtungen
Konzept (schriftlich) fertig.
Skripte bereit.
Numerische (Klima/Wetter-)modelle benoetigen einen Startzustand um zu beginnen. Normalerweise werden dazu groeber aufgeloeste globale (oder wie in meinem Fall regionale) Modelldaten verwendet, die dann auf das feinere Gitter interpoliert werden.
Auch waehrend des Modellaufes werden externe Parameter benoetigt. Grossskalige Phaenomene wie Fronten sind nicht auf einem kleinen Modellgebiet abbildbar. Diese werden allerdings trotzdem durch die allgemeine Zirkulation ins Modellgebiet advehiert und wirken wetter(bestimmend/beeinflussend). Diese grosskaligen Phaenomene muessen dem Ausschnittsmodell “mitgeteilt” werden. Dazu werden verschiedenen Prozeduren verwendet. Das forcing, also der Antrieb des Modells wird ueber verschiedene Assimilationsprozeduren auf das Modell uebertragen. Wichtige “Buzzwords” hierbei sind 1D-Var, 3D-Var, 4D-Var, Optimal interpolation, Nudging, Spectral nudging.
Warum sollte ich jetzt nachtraeglich also meine Modellrechnungen an externe Modelldaten angleichen muessen? Der erste Grund ist oben bereits genannt: Grossskalige Phaenomene koennen in einem Ausschnittmodell nicht abgebildet werden, koennen aber trotzdem wetterbestimmend sein. Ein weiterer Grund laesst sich wie folgt beschreiben: Da die Modelle nicht immer korrekt arbeiten kann (wird) es durchaus vorkommen, das das modellierte Wetter mit dem beobachteten nicht mehr uebereinstimmt. Dies ist schon in Anbetracht der Unzahl von fuer das Wettergeschehen relevanten Einflussfaktoren unmittelbar einsichtig. Zwar sind schon einige der relevanten Faktoren beruecksichtigt, jedoch fehlen auch noch Faktoren, die einen deutlichen Einfluss auf die Prognose haben (i. e. Bodenfeuchte, Wolkenmikrophysik…). Diesen Fehler will man dadurch ausgleichen, dass die Modelle alle 1 / 3 / 6 / 12 h an Beobachtungsdaten angeglichen werden (z. B. durch nudging).
Nun stellt sich die Frage, wie oft sollte dieses forcing bei einer hochaufgeloesten Simulation wie der meinen durchgefuehrt werden?
Ordinary least squares regression minimiert die (zur Achse der unabhaengigen Variablen) senkrechten (Fehler-)abstaende. Das ist aber in letzter Instanz nur dann korrekt, wenn diese (unabhaengige) Variable keine Streuung beinhaltet (Datum, sicher bekannter Wert). Ansonsten ist es genauer, die Fehler gegenueber einer Achse zu minimieren, die eher dem Varianzenverhaeltnis entspricht. (z. B. deren Steigung dem Verhaeltnis der typischen Varianzen der Variablen entspricht)… Das nennt sich dann “Total least squares regression”.
Der Status der Modellierung sieht folgendermassen aus:
Nachdem also die Antriebsdaten auf 5km noch nicht vollstaendig vorhanden sind werde ich die notwendigen Monate (der Kontrolllaeufe) selbst rechnen. Damit dauert das noch etwas, ich kann mir aber selbst ueberlegen was ich rechnen will. Die Frage ist: Wie kann ich meine Daten validieren. Inwiefern kann ich mehr als eine “das Modell sagt die Windextrema nehmen relativ zum vergangenen Zeitpunkt zu” Aussage treffen? Ich muesste eine dritte Zeitscheibe einfuehren, die ich auch validieren kann. Dann werden die vergangene sowie die aktuelle Zeitscheibe miteinander verglichen. Fuer beide Zeitpunkte habe ich im Idealfall auch noch Messdaten. Dann werden die Trends der zwei Vergangenheitsexperimente mit realen (i. e. gemessenen) Trends verglichen. Daraus werde ich dann die zukuenftigen Trends extrapolieren.
Das ist zwar nicht schoen, aber da es sich um ein zukuenftiges Ereignis handelt nicht anders zu machen. Wichtig ist eben die Frage welche Art von Beziehung zwischen den Modellergebnissen und den realen Gegebenheiten herrscht.
Klartext:
Es ist nicht klar ob die Ergebnisse der Modellierung etwas mit der Realitaet zu tun haben. Es ist auch nicht bewiesen dass die vorhergesagten Trends den Trends (zumindest deren Richtung) der Realitaet entsprechen. Deswegen ist eine Validierung der Ergebnisse notwendig.
Zur Validierung eines Trends stellt sich als erstes die Frage, welche Art von Verbindung denn zwischen Modellrechnungen und der Realitaet herrscht. Trends zweier Groessen zu korrelieren (und dann in die Zukunft zu extrapolieren) bedarf der Anwendung einer Regressionsrechnung.
Notwendige Parameter einer Regressionsrechnung sind zwei Reihen modellierter Groessen. Da die Art des Zusammenhangs unbekannt ist und die Auspraegungen gering (3 Zeitscheiben) wird ein linearer Zusammenhang angenommen. (Nebenbei: Ein Korrelationskoeffizient kann zwar berechnet werden, ist aber zum Beispiel im Falle des Pearsonschen Produktmomentkorrelationskoeffizienten nicht aussagekraeftig, da die Bedingungen (NV, Unabh.) nicht erfuellt sind…)
Die Interpolation wird zwischen den zwei in der Vergangenheit modellierten Zeitscheiben soll die Gerade liefern, die die Modellierung der Zukunft mit der Realitaet verbindet.
http://www.grida.no/climate/ipcc/emission/098.htm
The A1 marker scenario (Jiang et al., 2000) was created with the AIM model, an integrated assessment model developed by NIES, Japan (see Appendix IV). The A1 scenario family is characterized by:
The first group of A1 scenarios, which includes the A1B marker, assumes “balanced”6 progress across all resources and technologies from energy supply to end use, as well as “balanced” land-use changes.
The B1 marker scenario (de Vries et al., 2000) was developed using the IMAGE 2.1 model (see Appendix IV). Earlier versions of the model were used in the first IPCC scenario development effort (SA90). B1 illustrates the possible emissions implications of a scenario in which the world chooses consistently and effectively a development path that favors efficiency of resource use and “dematerialization” of economic activities. The scenario entails in particular:
Damit das Ganze auch flott laeuft benutze ich den HPC am Deutschen KlimaRechenZentrum in Hamburg (www.dkrz.de). Da ich dort nicht der Einzige bin braucht es ein Queueing-system.
qsub -> submit jobs
qstat -> status von jobs
qdel -> jobs loeschen
Wichtig: qstat -q pp oder #PBS -q pp, damit die sequentiellen Jobs nicht in der dicken Parallelqueue landen…
Hab mal spasseshalber ein “tar tf” auf ein 20 GB Archiv losgeschickt.
LMGRID sagt:
startlat_tot=-1.6, startlon_tot=-7.85,
pollat=39.25, pollon=-162.0,
dlon=0.012, dlat=0.012,
ie_tot=200, je_tot=200, ke_tot=40,
Damit modellieren wir mit einer Auflösung von rund 1,3 km. Der verschobene Pol (der nicht in der Mitte des Modellgebiets liegt) wurde gewählt, da er dem Pol der Eingangsdaten (Modellierung mit 5km von Anne Paetzold) entspricht. Da sich das Modellgebiet am Rande des Eingangsmodells befindet konnte ich somit die verlorene Fläche aufgrund nicht paralleler Modellgrenzen minimal halten. Ich habe einen Rand von mindestens 5 (groben) Modellpunkte gelassen, um Randeffekte in den Eingangsdaten zu minimieren.
