Massively Parallel GPU ODE Solver

Massiv-Parallel-GPU-ODE-Solver

GPU-beschleunigter Integrator für eine große Anzahl unabhängiger gewöhnlicher Differentialgleichungssysteme

Module:

Einzelsystem pro Thread v3.1

Es löst eine große Anzahl von Instanzen desselben ODE-Systems mit unterschiedlichen Anfangsbedingungen und/oder Parametersätzen.

Gekoppelte Systeme pro Block v1.0

Es löst eine große Anzahl von Instanzen eines gekoppelten Systems (bestehend aus vielen Subsystemen) mit unterschiedlichen Anfangsbedingungen und/oder Parametersätzen.

Versionshinweise:

18. August 2020.

Einzelsystem pro Thread v3.1:

• Unterstützung für einfache und doppelte Genauigkeit.
• Verbessertes/überarbeitetes Handbuch, z. B. eine detailliertere Installationsanleitung für Windows-Benutzer.
• Einbindung der Batch-Datei make.bat zur Vereinfachung des Kompilierungsprozesses unter Windows.
• Ein neues Tutorial (Tutorial 5) wurde hinzugefügt, um ein Beispiel mit Instanzen mit sehr großen Zeitskalenunterschieden zu testen. Die Leistungskurve von MPGOS wird mit den Programmpaketen odeint (C++) und DifferentialEquations.jl (Julia) verglichen. MPGOS ist diesen Paketen überlegen.
• Auch das Tutorial 6 (Stoßdynamik) wird um Leistungskurven erweitert, siehe vorheriger Punkt. In diesem Fall ist MPGOS das einzige Programmpaket, das in der Lage ist, Systeme mit Stoßdynamik (auf GPUs) zu bewältigen. Daher wurden Leistungsvergleiche nur mit CPU-Versionen von odeint und DifferentialEquations.jl durchgeführt.
• Kleinere Änderungen: Klare Trennung der TimeDomain- und ActualState-Variablen.

Gekoppelte Systeme pro Block v1.0:

• Dieses erste MPGOS-Modul ist fertig. Der Code soll eine große Anzahl von Instanzen eines gekoppelten Systems (bestehend aus vielen Subsystemen, sogenannten Einheiten) mit unterschiedlichen Anfangsbedingungen und/oder Parametersätzen lösen.
• Das Modul übernimmt nahezu alle Funktionen des Moduls Single System Per-Thread v3.1. Es gibt einige Besonderheiten, z. B. ist die Ereignisbearbeitung nur auf Einheitsebene möglich; nur explizite Kopplung kann in Matrixform behandelt werden; Für Einzelheiten wird der interessierte Leser auf das Handbuch verwiesen.
• Es werden zwei Tutorial-Beispiele bereitgestellt.

14. Februar 2020.

Einzelsystem pro Thread v3.0:

• Massive Leistungsverbesserungen. Die eingeführte Template-Metaprogrammierungstechnik ermöglichte es uns, einen hochoptimierten Code zu erstellen. Die durchschnittliche Versickerung beträgt das Dreifache, während sie bei niedrigdimensionalen Systemen sogar eine Größenordnung betragen kann.

10. Oktober 2019.

Einzelsystem pro Thread v2.1:

• Bei der Template-Metaprogrammierung wird der Code vollständig mit Vorlagen versehen, um während der Kompilierungszeit hochspezialisierten Solver-Code zu generieren (abhängig vom Algorithmus und der Notwendigkeit der Ereignisbehandlung und der dichten Ausgabe). Dementsprechend wird das Dateisystem überarbeitet.
• Kleine Erweiterung: Möglichkeit, gemeinsam genutzte Integer-Parameter und Integer-Zubehör zu verwenden, um komplexe Indizierungstechniken für komplizierte Systeme effizient umzusetzen.

13. August 2019.

Einzelsystem pro Thread v2.0:

• Dichte Ausgabe wird jetzt mit wenigen Einschränkungen unterstützt, siehe Handbuch. Dies ist z. B. Voraussetzung für die Lösung von Verzögerungsdifferentialgleichungen.
• Der Code und seine Schnittstelle sind stark vereinfacht und übersichtlich. Beispielsweise wurde der Problempool vollständig aus dem Code entfernt (er wurde aus historischen Gründen beibehalten) und viele mögliche Optionen sind jetzt an das Solver-Objekt gebunden, die alle mit einer einzigen Mitgliedsfunktion eingerichtet werden können.
• Auch das Handbuch wurde entsprechend den Rückmeldungen neu strukturiert und vereinfacht.

9. April 2019.

Einzelsystem pro Thread v1.1:

• Jedem Solver-Objekt kann ein Gerät (GPU) zugeordnet werden. Somit erfolgt die Geräteauswahl nun automatisch.
• Für jedes Solver-Objekt wird automatisch ein CUDA-Stream erstellt.
• Neuer Satz von Mitgliedsfunktionen zur Überlappung von CPU-GPU-Berechnungen und zur einfachen Verteilung der Arbeitslast auf verschiedene GPUs in einem einzelnen Knoten. Dazu gehören asynchrone Speicher- und Kerneloperationen sowie Synchronisierungsmöglichkeiten zwischen CPU-Threads und GPU-Streams.
• In jeder Integrationsphase kann eine aktive Anzahl von Threads angegeben werden, um den Tailing-Effekt bequem zu bewältigen.
• Es wurden zwei neue Tutorial-Beispiele hinzugefügt: a) überlappende CPU- und GPU-Berechnungen mit mehreren Solver-Objekten, b) Verwendung mehrerer GPUs, die auf einem einzelnen Computer/Knoten verfügbar sind.

14. Februar 2019.

Einzelsystem pro Thread v1.0:

• Dieses erste MPGOS-Modul ist fertig. Der Code soll eine große Anzahl unabhängiger, aber identischer (die Parametersätze und Anfangsbedingungen können unterschiedlich sein) ODE-Systeme auf GPUs lösen.
• Benutzerfreundlichkeit. Auch für Einsteiger in die C++-Programmierung reicht ein kurzer Kurs aus, um das Programmpaket zu nutzen.
• Es gibt ein ausführliches Handbuch mit Tutorial-Beispielen. Daher kann der Benutzer ganz einfach sein eigenes Projekt durch Kopieren und Einfügen von Codeblöcken erstellen.
• Effizientes und robustes Event-Handling.
• Benutzerdefinierte Aktion nach jedem Zeitschritt für mehr Flexibilität.
• Benutzerdefinierte „Interaktionen“ nach jedem erfolgreichen Zeitschritt oder jeder Ereignisbehandlung (sehr nützlich, z. B. für Aufpralldynamiken, siehe Tutorial-Beispiele im Handbuch).
• Möglichkeit, die Speicherhierarchie der GPU ohne explizite Kenntnis der Details zu nutzen.
• Vom Benutzer programmierbarer Parameter für flexible Implementierungen und Speicherung spezieller Eigenschaften einer Flugbahn.
• Nur explizite Löser: Runge-Kutta 4. Ordnung mit festem Zeitschritt und Runge-Kutta-Cash-Karp-Methode 4. Ordnung mit eingebetteter Fehlerschätzung 5. Ordnung. (Aufgrund des komplexen Kontrollflusses impliziter Löser sind explizite Löser manchmal sogar bei steifen Problemen besser als die impliziten.)
• Es werden nur arithmetische Operationen mit doppelter Genauigkeit unterstützt.
• Es werden nur die Endpunkte jeder Integrationsphase gespeichert (um die Geschwindigkeit zu verbessern). Dies stellt jedoch selten ein Problem dar, da die vom Benutzer programmierbaren Parameter und die oben genannten benutzerdefinierten Interaktionen es ermöglichen, die komplexesten Eigenschaften einer Flugbahn zu speichern, siehe Dokumentation.