×Diese Seite wurde maschinell aus dem Englischen übersetzt und kann Fehler enthalten. Englisches Original

Allgemeine Struktur & UML

aXqua besteht aus drei Teilen, die unabhängig voneinander verwendet werden können: eine Bibliothek, die Modelle erstellt und auswertet, ein Job-System, das Simulationen als eigenständige Prozesse ausführt, und das QGIS-Plugin als Benutzeroberfläche.

Pakete von aXqua in der Notation der Unified Modeling Language (UML). Ein gestrichelter Pfeil zeigt von einem Paket zu einem Paket, das es verwendet. Das Plugin ist durch einen festen Pfeil verbunden, weil es die Bibliothek nicht als Programmcode verwendet: Es startet das Programm axqua und liest die Dateien, die das Programm schreibt.

Das Diagramm zeigt die drei Designregeln, die unten angegeben sind: kein Pfeil führt vom Kern zu einem Backend, keiner verbindet die beiden Backends und das Plugin Flussabschnitte die Bibliothek nur über die Kommandozeile. Die Diagramme dieses Abschnitts werden aus dem Quellcode mit dem Skript scripts/build_uml.py generiert und zeigen daher den Code so, wie er ist.

Klassendiagramme der zentralen Datenstrukturen sind Teil der Seiten, die sie dokumentieren:

• die Fallbeschreibung, mit einer Klasse pro Block einer Fall-Datei (Klassen der Fallbeschreibung (axqua.config). Die Klasse Config enthält eine Klasse pro Block einer Fall-Datei, und einige Blöcke enthalten weitere Klassen, zum Beispiel eine Klasse pro Kalibrierparameter.);

• das Profil des Computers und die Nachrichten der Überprüfungen (Klassen, die den Computer und die Nachrichten von aXqua beschreiben. Das Profil (AxquaProfile) enthält eine Bindung pro Simulationscode. Die fünf Fehlertypen werden von einem allgemeinen Fehlertyp abgeleitet.);

• die Simulationscodes hinter einer Schnittstelle und ihre Fähigkeiten (Die Simulationscodes hinter einer Schnittstelle. Beide Backends werden von BaseBackend abgeleitet, was die Schnittstelle SolverBackend erfüllt. BackendSpec beschreibt ein Backend und seine Fähigkeiten, ohne es zu laden.);

• ein Job, von seiner Einreichung bis zu seinem Ergebnis (Klassen eines Jobs. JobSpec ist die Beschreibung, die eingereicht wird, mit einer Klasse von Optionen pro Art von Job. JobStatus ist der Zustand, den der laufende Job meldet, mit einer Klasse von Fortschritten pro Art von Job. Die vier Launcher erfüllen die Schnittstelle JobLauncher und lösen einen Job unter Linux, unter Windows und im Windows-Subsystem für Linux ab.).

Die Klassendiagramme verwenden drei Arten von Verbindungen. Ein Pfeil mit einem hohlen Dreieck zeigt von einer spezialisierten Klasse zu der allgemeinen Klasse, von der es abgeleitet ist. Eine Linie mit einem gefüllten Diamanten verbindet eine Klasse mit ihren Komponenten, mit dem Diamanten an der Klasse, die sie enthält. Ein gestrichelter Pfeil mit einem hohlen Dreieck zeigt von einer Klasse zu einer Schnittstelle, die die Klasse erfüllt. Das Label über einem Klassennamen, zum Beispiel «dataclass» oder «enumeration», gibt den Typ der Klasse an.

Entwurfsregeln

Drei Regeln bestimmen die Struktur. Jeder von ihnen wird durch einen automatisierten Test erzwungen, der den Quellcode liest.

1. Der Kern hängt nicht von einem Simulationscode ab. axqua.core beschreibt den Wasserkörper der freien Oberfläche und die Modellierungsaufgabe. Die Backends in axqua.solvers hängen vom Kern ab, niemals umgekehrt. Ein weiterer Simulationscode kann daher hinzugefügt werden, ohne den Kern zu ändern.

2. Die Backends sind nicht voneinander abhängig. Das TELEMAC Backend und das OpenFOAM Backend importieren sich nicht gegenseitig. Schritte, die beide Codes beinhalten, wie das TELEMAC-Warm-up eines OpenFOAM-Modells, werden eine Ebene oben koordiniert (axqua.prerun, axqua.workflow).

3. Das Plugin importiert die Bibliothek nicht. QGIS verfügt über eine eigene Python-Installation, während die Bibliothek mehrere Geodatenpakete und die Umgebung eines Simulationscodes benötigt. Das Plugin nennt daher das Programm axqua als separaten Prozess und tauscht nur kleine Informationen mit ihm aus: eine Job-ID, einen Zustand, einen Dateipfad. Ergebnisdaten gehen nie durch das Plugin. QGIS öffnet die Ergebnisdateien selbst.

Eine Konsequenz der dritten Regel ist, dass eine Simulation nicht davon abhängt, dass QGIS geöffnet ist. Das Plugin reicht einen Job ein und zeigt seinen Status an, aber der Job gehört dem Betriebssystem.

Packungen

Paket	Inhalt
axqua.config	Die Fallbeschreibung als Python-Datenklassen, mit Lesen und Schreiben der Fall-Datei (Konfiguration).
axqua.core	Geodaten, Raster, Ränder, Strukturen, das SELAFIN-Dateiformat, Fähigkeiten, die Registrierung von Backends, Fehlertypen und die Umgebungen der Simulationscodes (Solver-Agnostischer Kern).
axqua.solvers.telemac	Rechennetz Generation, Randbedingungen, Steuerdateien, läuft und Auswertung für TELEMAC (TELEMAC Backend).
axqua.solvers.openfoam	Rechennetz-Generierung, Anfangsfelder, Wörterbücher, Runs und Auswertung für OpenFOAM (OpenFOAM Backend).
axqua (oben)	Schritte, die unabhängig vom Simulationscode sind oder beide Codes beinhalten: Geländeverarbeitung, Messungen, Studien und Kalibrierung (Workflow, Studien und Kalibrierung).
axqua.jobs	Identität, Speicherung, Ausführung und Ablösung von Jobs (Jobsystem).
axqua.postproc	Zahlen aus den Ergebnissen (Postprocessing).
qgis_plugin/axqua	Das QGIS-Plugin (QGIS Plugin).

Die Backends werden über die Eingangspunktgruppe axqua.solvers des Python-Pakets registriert. Ein weiterer Simulationscode kann als separates Python-Paket vorgesehen sein, das sich in dieser Gruppe registriert.

Kapazitäten

Jedes Backend gibt an, welche Simulationstypen es unterstützt, zum Beispiel eine stetige 2D-Simulation oder eine Netzkonvergenzstudie. Für einen gegebenen Fall meldet aXqua jede Fähigkeit auf drei unabhängigen Ebenen:

• implemented: das Backend unterstützt die Fähigkeit (yes, no oder n/a, wenn die Fähigkeit für den Code nicht vorhanden ist);

• configured: die Fallakte fordert dies an;

• built und run: die Eingabedateien und die Ergebnisdateien existieren.

Der Befehl axqua case-status <case-file> --json gibt diese Informationen zurück. Das Plugin verwendet es, um zu entscheiden, welche Funktionen es für einen Fall anbietet.

Lizenzen

Die Bibliothek wird unter der BSD 3-Clause-Lizenz vertrieben. Das QGIS-Plugin wird unter der GNU General Public License, Version 2 oder höher vertrieben, da es die Programmierschnittstelle von QGIS verwendet.