Ein Modul ist ein Modellbaustein, der die Prozesse genau einer übergeordneten Modellebene beschreibt. Dabei werden Eingangsdaten, die von übergeordneten Modellebenen geliefert werden unter Nutzung von prozessbeschreibenden Funktionen in Ausgangsdaten transformiert. Diese Ausgangsdaten wiederum werden über ArcEGMO an nachfolgende Modellebenen und zur Ergebnisauswertung an RESULT (s. Kapitel 6) weitergegeben. Dementsprechend ist sowohl die Zeit- und Ortsschrittsteuerung wie auch die Parameterermittlung in die übergeordnete Modellebene integriert.

Diese Trennung der Funktionen zwischen Modellebenen und Modulen erlaubt mehr oder weniger umfangreiche Modifikationen der zur Verfügung gestellten Basismodule. Probleme sind dann zu erwarten, wenn umfängliche neue Modelle integriert werden sollen, denen eine andere Modellphilosophie zugrunde liegt.

Für Weiterentwicklungen des Systems ArcEGMO ist deshalb zu klären, ob einem Modul in Zukunft auch die Ermittlung der Modellparameter inklusive der Speicherbereitstellung zugeordnet wird. Dies erhöht wesentlich den Programmieraufwand für den Modellentwickler, gleichzeitig ergeben sich aber auch variablere Gestaltungsmöglichkeiten. Inwiefern es erforderlich wird, die Zeit- und Ortsschrittsteuerung den Modulen zuzuordnen, kann derzeit nicht abgeschätzt werden.

Unter obigen Gesichtspunkten ist klar, dass die folgende Beschreibung der Modulbibliothek genauso wie die Beschreibung der Modellebenen im Kapitel 7 nur eine vorübergehende sein kann.

Abbildung 8.2‑1 zeigt die Verzeichnisstruktur der Modulbibliothek, die jeweils einer Modellebene ein Verzeichnis zuordnet. Das zusätzliche Verzeichnis COMMON ist für Modellbausteine vorgesehen, die so allgemeiner Natur wie z.B. der Einzelspeicher sind, dass sie von verschiedenen Modulen genutzt werden.

Abbildung 8.2‑1: Verzeichnisstruktur der Modulbibliothek

Lies den Rest dieses Eintrags »

Über Einträge in der Modulsteuerdatei …ARC_EGMOMODUL.STE können einem Modul Parameter, Steuergrößen oder sonstige Werte zugeordnet werden. Dazu ist, analog dem Beispiel in Abbildung 8.4‑1, ein Block in der Steuerdatei einzurichten. Dieser Block sollte mit einem eindeutigen Steuerwort wie dem Modulnamen eingeleitet werden. Die eigentliche Steuerinformation, hier ein Faktor zur Skalierung des Rückgangsverhaltens des Abflusses, wird über ein Schlüsselwort definiert.

Q_ELS
RUECKGANGSFAKTOR 0.002

Abbildung 8.4‑1: Auszug aus der Modulsteuerdatei

Tabelle 8.4‑1: Routinen zur Modulsteuerung

Für den Zugriff auf die Steuerinformationen vom Programm aus stehen eine Reihe von Routinen zur Verfügung, die in Tabelle 8.4‑1 aufgelistet sind und die detaillierter (mit Prototypen) im Kapitel „Schnittstellen“ dokumentiert sind.

Der kleine Programmauszug aus Q_ELS.C in Abbildung 8.4‑2 zeigt beispielhaft die Nutzung dieser Routinen. Über den Modulnamen „q_els“ und das Schlüsselwort „RUECKGANGSFAKTOR“ wird der gewünschte Eintrag selektiert und der Wert von 0.002 auf die double-Variable kfak geschrieben. Wurde der angegebene Eintrag nicht gefunden, liefert die Routine als Rückgabewert „0“, so dass dann gemäß dem Vergleich im Beispiel kfak mit einem Standardwert (hier 0.1) belegt wird.

Abbildung 8.4‑2: Auszug aus der Programmdatei Q_ELS.C

Die Integration von Verwaltungsmöglichkeiten für alle Datenarten und -strukturen, die im Zusammenhang mit einer hydrologischen Flussgebietsmodellierung denkbar sind, ist weder möglich noch wäre sie aufgrund der damit verbundenen Redundanzen effektiv.

Reicht der vom Rahmenprogramm verwaltete Datenfundus für ein einzubindendes Modul nicht aus, so sind die benötigten Spezialdaten auf Modulebene zu verwalten.

Dafür werden die im Folgenden beschriebenen Routinen bereitgestellt, die neben der Eingabe und Auswertung dieser Daten auch die Verwaltung des benötigten Speicherplatzes unterstützen (allokieren, adressieren und freigeben).

Um die Verarbeitung nicht integrierter Daten innerhalb von Modulen zu gestatten, wurden eine Reihe von Routinen mit dem Ziel geschaffen, auch dem in der Programmierung nicht so versierten Nutzer ein möglichst einfaches Datenhandling zu gestatten.

8.5.1 Zeitinvariante Daten

Eine wesentliche Aufgabe der in Tabelle 8.5‑1 aufgeführten Routinen ist es, neue Datentabellen einzulesen, die analog den im Kapitel 4.5 aufgeführten Relate-Tabellen strukturiert sind, oder auf zusätzliche (vom Rahmenprogramm nicht eingelesene) Attribute in vorhandenen Relate-Tabellen zuzugreifen.

Tabelle 8.5‑1: Routinen zur Verwaltung von Relate-Tabellen

8.5.2 Zeitvariante Daten

Eine Beschreibung zur Definition und Anwendung von zeitvarianten Daten ist in Kapitel 5.5 zu finden.

8.5.2.1 Routinen zur Verwaltung von Zeitreihen

Die Routine ReadZRelTab liest Zeitfunktionen ein, deren Werte je nach Berechnungsfortschritt bzw. dem aktuellen Datum in der Simulation auf die dafür vorgesehenen Variablen gebunden werden.

Tabelle 8.5‑2: Routinen zur Verwaltung von Zeitreihen

8.5.2.2 Unterstützte Zeitfunktionen

Unterstützt werden äquidistante und nicht äquidistante Zeitfunktionen.

Die nicht äquidistanten Zeitfunktionen beschreiben über Stützstellen vorzugebende Verläufe. Zwischen den Stützstellen wird linear interpoliert oder eine Stufenfunktion aufgebaut. Bei der Stufenfunktion gilt ein Wert solange, bis er durch einen neuen ersetzt wird.

Die Zeitfunktionen für Kennwerte von Relateklassen befinden sich im Verzeichnis ../zeit.dat/ascii.rel/.

8.5.2.3 Analytische Zeitfunktionen

Analytische Funktionen werden aufgrund der Vielzahl denkbarer Ansätze nicht direkt unterstützt. Diese sind vom Modulentwickler selbst zu programmieren, wobei jedoch die Parameterverwaltung für solche Funktionen durch die Nutzung der in Kapitel 8.5.1 (attributbezogene Kennwerte) oder Kapitel 8.4 (globale bzw. attributunabhängige Parameter) unterstützt wird.

Die folgende Tabelle beinhaltet die Module der Standardbibliothek und eine Kurzcharakteristik ihrer Funktion. Ausführlich werden diese Module im Teil Module dieser Dokumentation beschrieben.

Tabelle 8.6‑1: Module der einzelnen Modellebenen