COSMOpilot

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?

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.

Nachdem die Probleme mit int2lm jetzt behoben sind läuft der lmrun fehlerfrei durch. Das Problem war: Wenn man lfilter_oro nicht .true. setzt verrechnet sich src/src_read_ext.f90 beim Berechnen des aus dem Grib zu lesenden Ausschnitts -> undefined Werte in hsurf etc… Das scheint mir ein Bug zu sein.