Aktionen

Erfassung der Metadaten einer Simulation

Aus BAWiki

Die Erfassung setzt in der Prozessierungskette bei der Simulation ein. Die Modellierungsverfahren UnTRIM und UnTRIM2 verarbeiten die Meta-Informationen in den nachfolgenden Teilmodellen:

1. Anleitung

Die Metadaten sind als Umgebungsvariablen zu setzen, die von den drei genannten Teilmodellen ausgelesen werden. Das Setzen der Variablen verteilt sich auf das eigentliche Run-Skript, mit dem ein Simulationslauf gestartet wird und das Auftragsskript, s. Abb. 1.

Abb. 1: Shellskripte zum Erfassen der DMQS-Metadaten eines Simulationslaufes


Das Auftragsskript wird einmalig zu Beginn eines Auftags erstellt und bei jedem Simulationslauf referenziert. Die folgenden Metadaten sind im Auftragsskript an den Auftrag anzupassen:

  • DMQS_PSP: Auftragsnummer aus EWisA
  • DMQS_TITLE: Auftragstitel aus EWisA
  • DMQS_SUMMARY: Kurzbeschreibung, bis zu 240 Zeichen
  • DMQS_CREATOR_NAME: "<name>, <vorname>, <optional_Titel>" der für den Auftrag verantwortlichen Person
  • DMQS_CREATOR_EMAIL: Mailadresse der für den Auftrag verantwortlichen Person
  • DMQS_CREATOR_ROLE: Rolle der für den Auftrag verantwortlichen Person
  • DMQS_GEO_ID: Auftragsweit gültiger Geografischer Identifikator. Eine Liste mit erlaubten Wasserstraßennamen und -IDs findet sich BAW-intern unter %PROGHOME%\cfg\dmqs\geo\valid_geo_ids.dat .


Im Falle einer mFUND-Förderung sind diese Metadaten anzugeben:

  • MFUND_PROJECT: Name des mFUND-geförderten Projekts
  • MFUND_ID: mFund-Förderkennzeichen

Seit Januar 2020 sind CONTRIBUTOR_NAME, CONTRIBUTOR_ROLE und ACKNOWLEDGMENT nicht mehr zu anzugeben, da sie vermeidbare personenbezogene Daten enthalten.

Eine ausführliche Vorlage steht unter $PROGHOME/bin/dmqs/set_dmqs_template.sh,

Die folgenden Metadaten beschreiben einen Simulationslauf.

Abb. 2: DMQS-Metadaten zur Beschreibung eines Simulationslaufes vom Auftrag bis zum Run



Die folgenden Metadaten sind in den jeweiligen Run-Skripten des Typs SLURM explizit zu setzen.

  • DMQS_VARIANT: Eine Variante ist eine Modellgeometrie. Innerhalb eines Auftrags gibt es häufig eine Ist-Variante, die die aktuelle Geometrie beschreibt und eine Ausbauvariante mit den gleichen Koordinaten in der Horizontalen, aber veränderten Tiefenwerten. Eine horizontal, bspw. für eine Sturmflutuntersuchung erweiterte Topografie, ist ebenfalls als eigenständige Variante zu kennzeichnen. Auch Ausprägungen des SubGrids oder der Randkanten (offen/geschlossen) stellen jeweils eigenständige Varianten dar. - DMQS_VARIANT wird mit einer Liste der für diesen Auftrag gültigen Varianten abgeglichen, so dass von der Simulation bis hin zum Metadaten-Informationssystem (MIS) der BAW konsistente Namen gewährleistet sind.
  • DMQS_SCENARIO: Ein Szenario beinhaltet die Anfangs- und Randwerte sowie die Parametrisierungen einer Simulation. Der Wind während eines Sturmtiefs kann bspw. ein Randwert sein, der Diffusionskoeffizient dient als Beispiel für eine Parametrisierung. - DMQS_SCENARIO wird mit einer Liste der für diesen Auftrag gültigen Szenarien abgeglichen, damit konsistente Werte vorliegen.
  • Ergänzung zu den beiden vorangehenden Elementen: Es sollten "sprechende" Namen vergeben werden, deren Bedeutung selbsterklärend ist. Die zu verwendenden Namen können vom den Auftrag bearbeitenden Team festgelegt werden. Aus softwaretechnischen Gründen können sie im weiteren Verlauf nicht mehr verändert werden. Gleichwohl gibt es die Möglichkeit eine Variante abschließend im MIS um eine Beschreibung zu ergänzen. Die Namen dürfen weder Blanks noch Sonderzeichen wie Ä, Ö, Ü, a, ö, ü oder ß enthalten.
  • RUN: Der Name eines Simulationslaufs kann weitere Anfangs- und Randwerte und Parametrisierungen, auch des Kompilats etc. bezeichnen. Die Verwendung von Umlauten und ß ist nicht gestattet.
  • DMQS_RUN_COMMENT: Freitext zur Beschreibung von RUN.


2. Vorlagen

2.1. Run-Skripte unter $PROGHOME/examples/slurm

  • Pre- / Postprocessing: run_prepos_application_n_threads_omp_bull.sh
  • UnTRIM 16 Cores: run_untrim_16threads_omp_bull.sh
  • UnTRIM 32 Cores: run_untrim_32threads_omp_bull.sh

2.2. Auftragsskript

  • $PROGHOME/bin/dmqs/set_dmqs_template.sh

2.3. Listen mit gültigen Namen:

  • $PROGHOME/cfg/dmqs/variant/01_template.dat; vom Team vereinbarte Variantennamen
  • $PROGHOME/cfg/dmqs/scenario/01_template.dat; vom Team vereinbarte Szenariennamen
  • $PROGHOME/cfg/dmqs/geo/valid_geo_ids.dat; Für Norddeutschland ausgesuchte Geografische Identifikatoren

2.4. Testverzeichnisse aus Simulation und Postprocessing zur freien Verfügung

  • Startverzeichnis: $PROGHOME/examples/dmqs
  • UnTRIM: $PROGHOME/examples/dmqs/01_simulation/work/piz/scena1/r033
  • Analyse: $PROGHOME/examples/dmqs/02_ncanalyse/work/piz/scena1/r033


3. Qualitätssicherung mit Checksummen und Filecontent

NEU ab Januar 2020: Die User können zur Qualitätssicherung Checksummen aus Eingabedateien bilden und und den Inhalt der Dateien nachträglich rekonstruieren, s. QS mit Checksummen und Filecontent.

4. Für Interessierte: weitere automatisch erfasste Metadaten

Weitere Metadaten werden, u.a. der Simulationszeitraum und die Abmessungen des Modellgebietes. Die meisten Metadatenelemente gehen als CF-Attribute in die NetCDF-Datei ein, bspw.:

  • uuid: eindeutige ID der NetCDF-Ergebnisdatei als Hash-Code, z.B. "72B01725-81D2-4AE5-BB57-942055541386"

Nicht-standardisierte Attribute sind:

  • dmqs_run_uuid: UUID des Simulationslaufes, in allen NetCDF-Ergebnisdateien des Laufs identisch.
  • max_source_dimensionality: maximale Dimensionalität der Modellrechnung (kann von der der Datei abweichen).

Hinzu kommen DMQS-Variablen, die mit jedem Prozessierungsschritt automatisch ergänzt werden.

  • dmqs_steering: Pfad und Name der Eingabesteuerdatei im Arbeitsverzeichnis
  • dmqs_data_path_file: Pfad und Name der Ergebnisdatei im Arbeitsverzeichnis
  • dmqs_method: Name und Version der Methode
  • dmqs_execution_start: Datums- und Zeitstempel zu Beginn der Laufzeit
  • dmqs_sim_time_step: Rechenzeitschritt der ursprünglichen Simulation
  • dmqs: DMQS-Containervariable mit Referenzen auf die anderen DMQS-Variablen.

Dmqs_steering enthält in den hydrodynamischen Ergebnissen einen String mit Pfad und Namen der Steuerdatei des Hydrodynamik-Paketes, bspw.:

  • $PROGHOME/examples/dmqs/work/01_simulation/piz/scena1/r033/untrim.piz.dat
  • Ein Postprozessor wie NCANALYSE wird die Variable dmqs_steering um einen eigenen String mit Pfad und Namen der eigenen Steuerdatei ergänzen:
  • $PROGHOME/examples/dmqs/work/02_simulation/piz/scena1/r033/ncanalyse_LZKB.dat
  • Da die Steuerdateien i.d.R. mehrfach verschoben werden, führen diese Angaben selten zum Ziel und es sollte, wie unter 3. beschrieben, der Filecontent genutzt werden.

-> Erfassung von Analyse-Metadaten