MasterSim Benutzerhandbuch

Einige Funktionen in MasterSim sind (aus meiner Sicht) sehr praktisch und gibt es so in anderen Co-Simulations-Masterprogrammen nicht.

Es gibt eine besondere Funktion in MasterSim, welche hilfreich für die Verwendung von FMUs ist, welche eigene Ausgabedaten schreiben. MasterSim erstellt für jede FMU Instanz/jeden Slave ein beschreibbares, slave-spezifisches Ausgabeverzeichnis. Der Pfad zu diesem Verzeichnis setzt MasterSim im Parameter ResultsRootDir. Falls ein Slave einen solchen Parameter definiert, erhält die FMU über den Parameter ein verlässliches, gültiges Verzeichnis zum Hineinschreiben seiner Daten (siehe auch Abschnitt Verzeichnis Slaves).

Zyklen bei der Definition von verknüpften Slaves können explizit definiert werden und reduzieren damit dem Aufwand für iterative Masteralgorithmen (siehe auch Abschnitt Zyklen).

MasterSim beinhaltet eine Zeitmessung und Erfassung der Ausführungshäufigkeiten für einzelne Funktionen. Dies ist hilfreich, zeitkritische Simulationen zu optimieren oder Fehler zu finden (siehe Abschnitt Simulations-Statistik/Zusammenfassung).

Verknüpfungen zwischen Ausgangs- und Eingangsvariablen können in MasterSim mit Umrechnungsfaktoren und Verschiebungen definiert werden, was besonders für Einheitenumrechnungen und Flussverknüpfungen mit Vorzeichenumkehr praktisch ist (siehe Abschnitt Verbindungsgraph).

Das ist eine recht direkte Vorgehensweise:

Dies ist ein sehr einfacher Fall und, wenn von FMUs unterstützt, durchaus eine praktikable Methode. In MasterSim müssen nur die den veröffentlichten Parametern zugewiesenen Werte geändert werden (dies kann auch direkt in der Projekt-Datei getan werden, z. B. auch mit Skripten) und die Simulation kann wiederholt werden.

Dies ist einer der häufigsten Fälle. Hier bleiben die Namen der Eingangs- und Ausgangsgrößen unverändert (d.h. die FMU-Schnittstelle bleibt unverändert). Auch die publizierten Parameter bleiben gleich. Jedoch ändert sich das interne Verhalten aufgrund der Anpassung des internen Modellverhaltens, wonach die FMU nochmals exportiert wurde. Da MasterSim selbst die FMU-Archive nur über einen Dateipfad referenziert, können FMU-Dateien in solchen Fällen einfach ersetzt und der Simulator ohne weitere Anpassungen gestartet werden.

In dieser Situation, in der ein Parameter in MasterSim konfiguriert worden ist, der nicht länger existiert (oder dessen Name geändert wurde), muss die entsprechende Definition in der Projekt-Datei geändert oder von der Benutzeroberfläche entfernt werden.

Wenn eine importierte FMU einen Teil ihrer Schnittstelle ändert (z. B. Ein- oder Ausgangsgrößen wurden modifiziert), dann wird dies in der Benutzeroberfläche durch Hervorhebung der falschen/nun fehlenden Verbindungen angezeigt. Wenn nur Variablennamen verändert wurden, editieren Sie am besten die Projekt-Datei und benennen dort die Größenbezeichnung um. Ansonsten sollte man einfach die Verbindung entfernen und eine neue erzeugen.

Wenn sich der Variablentyp einer Eingangs-/Ausgangsgröße ändert, sodass eine ungültige Verbindung entsteht (oder die Kausalität geändert wird), dann zeigt die Benutzeroberfläche die ungültige Verbindung nicht unbedingt direkt an. Allerdings wird das Befehlszeilenprogramm des MasterSimulator den Fehler während der Initialisierung anzeigen und abbrechen. Auch hier ist empfehlenswert, die fehlerhafte Verbindung zu löschen und neu zu erstellen.

Die erste Aufgabe des Simulators ist es, für alle Slaves konsistente Anfangswerte zu erhalten. Das ist bereits eine nicht-triviale Aufgabe und nicht in allen Fällen überhaupt möglich. Die einzige Prozedur, die sowohl für FMI 1 und FMI 2-Slaves zum Einsatz kommen kann, ist das schrittweise Lesen und Setzen von Eingangs- und Ausgangsgrößen in allen Slaves. Dieses wird wiederholt, bis keine Änderungen mehr beobachtet werden.

Der Algorithmus in MasterSim ist:

Der Berechnungsalgorithmus für die Anfangsbedingungen ist derzeit ein Gauss-Jacobi-Algorithmus und als solcher nicht übermäßig stabil oder effizient.

MasterSim behandelt die Simulationszeit in der Programmoberfläche als gegeben in Sekunden.

Die Simulationszeit wird in der Benutzeroberfläche und der Projektdatei in Sekunden eingetragen (oder irgend einer anderen unterstützten Einheit, die in Sekunden umgewandelt werden kann). Während der Simulation werden alle erfassten Zeiten (Start- und Endzeit und die Zeitstufengrößen und Größenbegrenzung) zuerst in Sekunden umgewandelt und danach ohne irgend eine weitere Einheitenumrechnung benutzt.

Beispiel: Wenn Sie einen Endzeitpunkt auf 1 h festlegen, wird der Master bis zur Simulationszeit 3600 (s) laufen, welche dann als Endzeitpunkt des Kommunikationsintervals im letzten doStep()-Aufruf gesendet wird.

Das gesamte Simulationszeit-Intervall wird an die Slaves im setupExperiment()-Aufruf weitergegeben. Wenn Sie die Startzeit anders als mit 0 festlegen, wird der Master-Simulator sein erstes Kommunikationsintervall zu diesem Zeitpunkt starten (der Slave braucht dies, um den setupExperiment()-Aufruf korrekt zu verarbeiten und den Slave zum Startzeitpunkt zu initialisieren).

Die Endzeit der Simulation wird zur FMU auch per setupExperiment()-Aufruf übermittelt (das Argument stopTimeDefined ist durch MasterSim immer auf fmiTrue gesetzt).

Wenn der Algorithmus nicht innerhalb des vorgegebenen Wiederholungslimits konvergiert, wird die Kommunikationsschrittlänge um den Faktor 5 reduziert:

Der Faktor 5 ist so ausgewählt, dass die Zeitschrittgröße schnell reduziert werden kann. Falls zum Beispiel eine Unstetigkeit auftritt, z. B. ausgelöst durch eine stufenweise Änderung diskreter Signale, muss der Simulator die Zeitschritte schnell auf einen niedrigen Wert reduzieren, um die Unstetigkeit zu passieren.

Die Schrittgröße wird dann mit der unteren Schrittlängengrenze verglichen (Parameter hMin). Dies ist notwendig, um zu verhindern, dass die Simulation in extrem langsamen Zeitschritten stecken bleibt. Falls der Fehlerkontrollalgorithmus die Schrittgröße unter den Wert von hMin reduziert würde, wird die Simulation abgebrochen.

In manchen Fällen kann die Interaktion zwischen zwei Slaves das Konvergieren jedweder Master-Algorithmen verhindern (sogar beim Newton-Algorithmus). Dennoch kann in diesen Fällen der verbleibende Fehler unerheblich sein und die Simulation kann in winzigen Schritten langsam über die problematische Zeit hinweggehen und danach die Schritte wieder vergrößern. In diesen Fällen können Sie den Parameter hFallBackLimit festlegen, welcher größer sein muss als hMin. Wird h auf einen Wert unter diese zulässige Kommunikationsschrittlänge reduziert, wird der Master-Algorithmus nach Durchlaufen alle Iterationen den Schritt als erfolgreich akzeptieren. Der Schritt wird dadurch als sich angenähert behandelt und die Simulation geht zum nächsten Intervall weiter.

Die Publikation

Nicolai, A.: Co-Simulations-Masteralgorithmen - Analyse und Details der Implementierung am Beispiel des Masterprogramms MASTERSIM, http://nbn-resolving.de/urn:nbn:de:bsz:14-qucosa2-319735

illustriert das Verhalten der Simulation beim Benutzen dieser Parameter.

Wenn eine Fehlertestmethode (ErrorControlMode) festgelegt ist, folgt nach einem konvergiertem Schritt eine lokale Fehlerschätzung. Derzeit basiert diese Fehlerprüfung auf der Schritt-Verdopplungs-Technik und kann als solche nur eingesetzt werden, wenn die Slaves die FMI 2.0 Funktionalität zum Speichern/-Rücksetzen des Zustands unterstützen.

Grundsätzlich läuft der Test folgendermaßen ab:

Die mathematischen Formeln und detaillierte Beschreibungen der Fehlertests sind in der folgenden Publikation dokumentiert:

Nicolai, A.: Co-Simulation-Test Case: Predator-Prey (Lotka-Volterra) System (siehe MasterSim Dokumentations-Webpage).

Die Fehlersuche nutzt die Parameter relTol und absTol um die akzeptable Differenz zwischen Voll- und Halbschritt einzugrenzen (oder deren Anstiege). Abhängig von der lokalen Fehlerschätzung existieren zwei Optionen:

Basis-Algorithmus:

Gauss-Jacobi wird stets ohne Iteration ausgeführt. Wie in der Publikation gezeigt (siehe oben), ergibt es wirklich keinen Sinn, eine Iteration zu nutzen.

Basis-Algorithmus:

Durch die Aktualisierung der Variablenliste nach jedem Slave erhalten die nachfolgenden Slaves bereits aktualisierte Größen für den Kommunikationsschritt, welches das Gauss-Seidel-Verfahren auszeichnet.

Basis-Algorithmus:

Zyklen werden genauso behandelt wie beim Gauss-Seidel-Algorithmus.

Beim Öffnen eines Beispiels von der Startseite/Beispielseite werden Sie aufgefordert, das Projekt zunächst in einer benutzerdefinierten Stelle zu sichern (Beispiele sind im Installationsverzeichnis abgelegt, welches gewöhnlich schreibgeschützt ist).

Hier ist eine Liste der nützlichen programmweiten Tastaturkürzel:

Im unteren linken Teil der Ansicht befindet sich eine Kontext-abhängige Eingabe für Projektkommentare (falls nichts gewählt ist), Slave-Eigenschaften (falls ein Slave markiert ist) oder Verbindungseigenschaften (falls eine Verbindung markiert ist).

Neue Slaves werden durch das Auswählen von fmu- oder csv- oder tsv-Dateien zugefügt. MasterSim nutzt automatisch den Basisnamen der ausgewählten Datei als ID-Namen für den Slave. Falls bereits ein solcher ID-Name existiert, fügt MasterSim eine Nummer zum Basisnamen hinzu. In jedem Fall müssen die Slave-ID-Namen einzigartig innerhalb des Projekts sein.

Unterhalb der Tabelle mit den verwendeten Slaves ist eine Liste der von den FMUs publizierten Parameter. Die Liste gilt für den gegenwärtig ausgewählten Slave. Ein Simulations-Slave kann in der Slave-Tabelle oder durch Anklicken eines Blocks in der Netzwerkansicht ausgewählt werden.

Parameter können durch Doppeklicken der Wertezelle editiert werden. Das Löschen des Inhalts der Zelle setzt die Parameter auf ihre standardmäßigen Werte zurück.

Die Netzwerkansicht (9) zeigt ein simples Schema aller FMU-Slaves und ihrer Verbindungen. Diese Netzwerkansicht ist optional und wird für die Simulation nicht wirklich gebraucht. Dennoch ist die visuelle Darstellung des Simulations-Szenarios wichtig für die Kommunikation und die Prüfung der Eingabe.

Das Netzwerk zeigt Blöcke (je importiertem Simulator/Slave), und in jedem Block eine oder mehrere Anschlussstellen/Sockel (engl. socket). Diese Sockel zeigen die Eingangs-/Ausgangsvariablen eines jeden Simuations-Slaves an. Die Blöcke werden in unterschiedlichen Farben angezeigt, welche individuelle Blockzustände anzeigen.

Blöcke können markiert und dann mit der Maus verschoben werden. Ebenso können Verbindungslinien verschoben werden.

Der Block-Bearbeitungsdialog erlaubt Ihnen, die grundlegende, rechteckige Gestalt der FMU festzulegen und die Abschlüsse zu auszurichten. Der Block-Bearbeitungsdialog wird entweder direkt nach dem Import einer FMU geöffnet oder indem Sie auf einen Block in der Netzwerkansicht doppelklicken.

Diese Funktion ist sehr hilfreich, wenn FMUs miteinander verbunden werden sollen, deren Ausgangs- und Eingangsvariablen den gleichen Namen haben. Dies ist insbesondere hilfreich, wenn Sie viele Eingangs- und Ausgangsvariablen zwischen zwei Slaves verbinden müssen. Falls Sie FMUs mit passender Namensgebung der Variablen erzeugen, können Sie den folgenden Ablauf nutzen:

Eine Verbindung wird erstellt, wenn:

Beispiel 1 verdeutlicht eine solche automatische Verknüpfung.

Falls Sie die Umwandlung einer Einheit oder andere Änderungen (Zeichenumkehrung, Skalierung) zwischen Ausgangs- und Eingangsvariablen vornehmen wollen, können Sie in der dritten Spalte der Tabelle (6) doppelklicken, um einen Dialog für das Bearbeiten der Umrechungsoperation zu öffnen (siehe Abschnitt Verbindungsgraph für eine detaillierte Beschreibung).

Wenn kein Arbeitsverzeichnis vorgegeben wird, wird der Verzeichnis-Pfad zum Arbeitsverzeichnis aus dem Pfad zur Projektdatei ohne Dateierweiterung generiert. Zum Beispiel:

Im Abschnitt Struktur und Inhalt des Arbeitsverzeichnis wird der Inhalt und die Struktur des Arbeitsverzeichnisses erklärt.

MasterSimulator schreibt Fortschrittsinformationen/Warnungen und Fehlermeldungen in das Konsolenfenster und in die Datei <working-dir>/logs/screenlog.txt. Die Menge an geschriebenem Text und die Detailstufe wird durch den --verbosity-level Parameter kontrolliert, welcher die Menge der erzeugten Fehler-/Analyseinformationen festlegt.

Bei der Detailstufe 0 (--verbosity-level=0) wird so ziemlich je Ausgabe abgeschaltet. Die Detailstufe 1 ist der Standard mit normalen Fortschrittsmeldungen. Nutzen Sie eine höhere Ausgabedetailstufe zur Analyse der integrierten Algorithmen oder zur Eingrenzung von Fehlern.

Normalerweise bleibt das Konsolenfenster (bei Windows) am Ende der Simulation offen. Man kann aber durch Angabe des -x Befehlszeilenschalters das Fenster nach Ende der Simulation automatisch schließen lassen.

Dieses Verzeichnis beinhaltet 3 Dateien:

Das Format der Datei progress.txt ist recht simpel:

Die Datei besitzt 3 Spalten, getrennt durch ein Tabulatorzeichen. Die Datei wird bei laufender Simulation geschrieben und aktualisiert und kann von anderen Werkzeugen genutzt werden, um den Gesamtfortschritt aufzugreifen und Fortschrittsdiagramme zu erzeugen. (Geschwindigkeit/Prozentsatz etc.)

Die Bedeutung der verschiedenen Werte im summary.txt werden im Abschnitt Simulations-Statistik/Zusammenfassung erklärt.

Innerhalb dieses Verzeichnis werden die importierten FMUs extrahiert, jedes in ein Unterverzeichnis mit dem Basisdatei der FMU (part1.fmu → part1).

Wenn ein MasterSim-Projekt auf verschiedene FMUs desselben Basisnamen Bezug nimmt, welche zum Beispiel in verschiedenen Unterverzeichnissen stehen, wird es den Pfadnamen anpassen. Beispiel:

Grundsätzlich wird jede FMU-Datei nur einmal entpackt.

Oft schreiben nicht-triviale Simulations-Slaves ihre eigenen Ausgabedateien, anstatt die gesamten Ausgabedaten per FMU-Ausgabevariablen zum Master zu verschieben. Bei FMUs, in denen partielle Differentialgleichungen gelöst werden, und Feldausgaben mit mehreren tausenden Datenpunkten je Zeitschritt erzeugt werden, wäre dies auch nicht sinnvoll (oder effizient). Für das Schreiben derartiger Ausgaben bräuchte die FMU einen Zielpfad, in den die FMU schreiben darf.

Da eine FMU mehrere Male instanziiert werden kann (d.h. mehrere Slaves werden aus der gleichen FMU-Datei erzeugt), ist die feste Programmierung eines Ausgabepfads innerhalb der FMU im Allgemeinen keine gute Idee (obgleich gegenwärtig noch immer häufige Praxis). Die Ausgaben der unterschiedlichen Slaves würden sich sonst gegenseitig überschreiben.

Ausgaben ins gegenwärtige Arbeitsverzeichnis zu schreiben ist ebenso ungeschickt, da das Arbeitsverzeichnis zwischen den Aufrufen der FMUs eventuell durch den Master geändert werden muss. Dadurch sollte der Zugriff auf das Arbeitsverzeichnis am besten vermieden werden.

Leider unterstützt der FMU-Standard keine Option, einem Slave ein gültiges Ergebnis-/Arbeitsverzeichnis zu übergeben. MasterSim behebt das Problem, indem es Slave-spezifische Verzeichnispfade in einem Parameter, genannt ResultsRootDir, angibt. Dazu braucht die FMU lediglich diesen Zeichenketten-Parameter zu deklarieren. Man kann in MasterSim den Wert dieses Parameters natürlich wie bei allen anderen Parametern manuell festlegen. Wenn allerdings kein Wert in der Projekt-Datei für diesen Parameter festgelegt ist, wird MasterSim den für den Slave erzeugten Pfad im Arbeitsverzeichnis eintragen. Die FMU kann den von MasterSim erzeugten Slave-spezifischen Pfad nutzen und Ausgaben oder andere Daten dort hinein schreiben.

MasterSim erstellt zwei Ergebnisdateien innerhalb des results-Unterverzeichnis:

Abhängig davon, ob synonyme Variablen in der ModelDescription (siehe unten) definiert sind, die Datei synonymous_variables.txt.

Zeichenketten-Ausgabe-Dateien werden nur erzeugt, wenn tatsächlich Ausgaben dieses Datentyps von Slaves erzeugt werden.

Die Ergebnisdateien haben die Erweiterung csv, nutzen aber Tabulatorzeichen als Trennzeichen. In der ersten Spalte steht immer der Zeitpunkt. Im Spaltenkopf jeder Spalte kann in [] die Zeiteinheit angegeben werden.

Beispiel values.csv-Datei:

Das Dateiformat entspricht dem der csv-Dateien, die als Datei-Lese-Slaves genutzt werden, siehe Abschnitt CSV-Datei-Lese-Slaves, mit:

Den FMI- Variablennamen sind die entsprechenden Slave-Namen vorangestellt. Die Einheiten sind in Klammern angegeben und für einheitslose ganzzahlige und boolesche Datentypen, wird die Einheit [-] genutzt.

MasterSim beinhaltet eine interne Zeitmessfunktion, welche die Ausführungszeiten der verschiedenen Teile der Software überwachen. Ebenso werden Ausführungshäufigkeiten für verschiedene wichtige Funktionen gezeigt. Die Statistik wird ins Konsolenfenster (bei verbosity-level > 0) und in die Log-Datei screenlog.txt geschrieben. Dabei wird folgendes Format verwendet (die unteren Zeilen beginnend ab "Part1" sind projektspezifisch).

Die selben Statistikdaten werden in die summary.txt-Logsdatei kopiert, dabei aber in ein eher maschinenfreundliches Format (mit Zeitangaben immer in Sekunden bzw. der jeweils verwendeten Master-Zeiteinheit):

Die Werte bedeuten im Einzelnen:

Die übrigen Zeilen zeigen Dauer und Aufrufhäufigkeiten individuell für jeden Slave. Die Zeilen zeigen die genutzte Zeit in den Funktionsaufrufen doStep(), getState() und setState() und die jeweilige Häufigkeit des Aufrufs. Die den Zustand betreffenden Funktionen (state) werden nur für iterierende Master-Algorithmen genutzt, falls die FMUs diese FMI 2 Funktionalität unterstützt. Es ist zu beachten, dass diese Funktionen sowohl vom Master-Algorithmus als auch vom Fehlertest aufgerufen werden (wenn eingeschaltet).

Das Schreiben von Ausgaben (Output writing) und Ausführen des Master-Algorithmus (Master-Algorithm) sind die beiden Hauptkomponenten des MasterSimulator-Pogramms, sodass ihre addierten Zeiten nahe der Gesamtlaufzeit liegen sollten.

Die dritte Spalte in der Konsolen-Ausgabe-Statistik beinhaltet Zähler. Der Zähler für den Master-Algorithmus ist die Gesamtzahl der Ausführungen des Master-Algorithmus, also die Gesamtschrittzahl bzw. Gesamtzahl an erfolgreich absolvierten Kommunikationsintervallen. Neuversuche und Wiederholungen innerhalb des Master-Algorithmus werden hier nicht beachtet.

Die folgenden Optionen werden zumeist für die Validierungs-Prozedur verwendet.

Abhängig von den gewählten Optionen, müssen einige Fähigkeiten durch die FMUs unterstützt werden, siehe dazu Erläuterungen in Abschnitt Master-Algorithmen. Grundsätzlich muss für die Verwendung eines iterierenden Master-Algorithmus oder für die Fehlerprüfung und Zeitschrittanpassung eine FMU den FMI 2 Standard und die Funktionalität für das Holen und Zurücksetzen des Zustands implementieren.

Bisweilen ist es sinnvoll/notwendig, vorgegebene Zeitreihen als Eingangsgrößen für FMUs bereitszustellen. Diese können in einer Datendatei bereitgestellt werden. Eine solche Datendatei (Erweiterung mit tsv oder csv) kann man wie eine FMU auswählen. MasterSim wird eine solche Datei wie eine FMU behandeln, und daraus CSV-Datei-Lese-Slaves erstellen, die lediglich Ausgabevariablen bereitstellen.

Effektiv unterstützt MasterSim zwei Varianten von CSV/TSV-Dateien (Dateierweiterung ist dabei egal). In beiden Varianten werden Zahlen immer im englischen Zahlenformat erwartet. Beim Einlesen wird zuerst versucht, eine durch Tabulatoren getrennte Spaltenstruktur zu erkennen, indem die ersten beiden Zeilen mit Tabulatorzeichen aufgeteilt werden. Wenn dies mehr als zwei Spalten ergibt und die Anzahl an Spalten in beiden Zeilen (in Kopf- und erster Datenzeile) übereinstimmt, wird eine Tabulator-getrennte CSV/TSV-Variante erkannt. Andernfalls wird eine CSV-Datei im "Excel"-Format erwartet (siehe unten).

Die Zeitpunkte können in beliebigen Intervallen angegeben sein. MasterSim geht davon aus, dass Sekunde als Basis-Zeiteinheit verwendet wird. Das bedeutet, dass Variablen intern zu einer Simulationszeit in Sekunden ausgetauscht werden. Wenn eine Eingangsdatei eine andere Einheit für die Zeit festlegt, konvertiert MasterSim diese Zeitangaben beim Einlesen der Datei in Sekunden.

Die folgenden Zeiteinheiten werden von MasterSim erkannt:

Während der Simulation, wenn der Datei-Lese-Slave ausgewertet wird, gelten die folgenden Regeln: für die Berechnung der Ergebnisgrößen.

Sie können Parameter der FMUs (oder konkreter, die der individuellen FMU-Slaves) festlegen, indem Sie das parameter-Schlüsselwort benutzen.

Definition der Syntax:

Für boolesche Parameter müssen Sie true als Wert verwenden (Kleinschreibung beachten) oder irgend einen anderen Wert (zum Beispiel false) für falsch.

Für ganzzahlige Werte (Typ Integer) müssen Sie einfach den Wert als Ziffer festlegen.

Werte für Parameter vom Typ Real" werden in der Einheit erwartet, die in der modelDescription.xml-Datei für den entsprechenden Parameter festgelegt worden sind. Eine Einheitenumrechnung wird hier nicht unterstützt.

Für String-Parameter wird alles nach dem Variablennamen als Zeichenkette angesehen (bis zum Ende der Zeile). Beispiel:

Leerstellen können enthalten sein. Aber die Rückwärts-Schrägstrich-Zeichen (backslash) müssen als \\ kodiert sein. Dies ist notwendig, damit Sonderzeichen wie Zeilenumbrüche durch \n kodiert werden können, wie im folgenden Beispiel gezeigt:

Dies wird den folgenden String setzen:

platform ist (gegenwärtig) eine von: linux64, win32,win64 und darwin64

Jede Testreihe hat eine Reihe von Unterverzeichnissen:

Innerhalb der Testreihe können verschiedene ähnliche Testfälle mit modifizierten Parametern oder angepassten Problemlösungs-Szenarien gespeichert sein. Testfälle werden in der Regel als Testreihen gruppiert, wenn sie die gleichen FMUs oder andere Eingangsdateien benutzen.

Für jeden Testfall existiert eine MasterSim-Projektdatei mit der Erweiterung msim. Das Skript, welches die Testfälle durchführt, verarbeitet alle msim-Dateien, die in der Unterverzeichnisstruktur unter der aktuellen Plattform gefunden werden.

Um die Überprüfung in einem Testfall zu bestehen, muss eine Reihe von Referenzergebnissen vohanden sein, die in einem Unterverzeichnis mit folgendem Namen gespeichert sind:

Zum Beispiel:

Diese Verzeichnisse sind grundsätzlich nach einer durchlaufenen Simulation umbenannte Arbeitsverzeichnisse, in denen alles außer summary.txt und values.csv beseitigt worden ist.

Die Tests laufen automatisch nach Erstellen der Software ab. Ansonsten kann man die Testreihe auch über ein Skript selbst starten (je nach Plattform):

Aus einem Testverzeichnis heraus kann man das Script update_reference_results.py aufrufen und dabei die plattformspezifische Verzeichnisendung als Argument angeben.

Beispielsweise würde der Aufruf aus dem Verzeichnis

so aussehen:

Das Script aktualisiert nun alle Referenzergebnisse in diesem Verzeichnis. Falls die Referenzergebnisse mehrerer Testreihen bearbeitet/aktualisiert werden sollen, so führt man das Skript update_reference_results_in_subdirs.py aus einem der oberen Verzeichnisse durch, zum Beispiel von: data/tests/linux64 (anderen Scriptnamen beachten!):

Ein geeigneter Weg, um eine einfache, sehr spezielle Test-FMU zu erhalten, ist die Verwendung des FMI Code Generator-Werkzeugs. Es ist ein Python-Skript mit einer grafischen Benutzeroberfläche, in der FMU-Variablen und -Eigenschaften festgelegt werden können. Mit dieser Information erstellt der Code-Generator ein Quelltextverzeichnis mit einer Programm-Quelltextvorlage und den benötigten Skripten für das Erstellen und Verpacken der FMUs. Damit ist es sehr einfach, eigene FMUs zu erstellen (siehe auch Dokumentation/Tutorial auf der Webseite https://github.com/ghorwin/FMICodeGenerator).

Zunächst wird ein Modelica-Modell erstellt.

Zum Beispiel:

Die MasterSim-Bibliothek und die Simulationsprojekte hängen von folgenden Bibliotheken ab, wobei abgesehen von Qt alle im Quelltext-Repository enthalten sind. Somit ist es nicht notwendig, irgendwelche Bibliotheken separat zu installieren:

MasterSimulator und MasterSimulatorUI

nur MasterSimulatorUI

Die frei verfügbare Version der Bibliotheken (mit Ausnahme von Qt) sind im Unterverzeichnis third-party abgelegt.

Die Entwicklung mit Qt Creator wird unterstützt (und explizit empfohlen) und Projektdateien stehen zur Verfügung. Individuelle Projektdateien befinden sich in Unterverzeichnissen:

Ausführbare Programme werden abgelegt in: