Implementation of parallel support in OpenDiHu nested solvers using the preCICE adapter

Abstract

Recent hardware advancements mostly hinge on adding more cores to the architecture, with increasing support for additional random access memory. This requires scalable software that make the most out of the cores available, especially for simulation software, which run in HPC server cluster on not just multiple cores, but rather multiple CPUs with intercommunication enabled by MPI. One such simulation software is OpenDiHu, designed to be scaled to more than 10000 cores for modeling skeletal muscles, neural activation and EMG signals. It is currently possible to run the OpenDiHu mechanics solver in parallel if the solver is used as a standalone component, running the solver in parallel with preCICE is currently not possible. We first present a revised algorithm for calculating boundary conditions, that enabled parallel support for mechanics solver coupled with preCICE by looking into their respective ghost values and show that this reduces the execution time by up to 80% depending on the simulation experiment. Afterwards we present a new extendible component for creating checkpoints in a predefined interval, a common technique for increasing the resiliency of simulation software against hard failures. We are able to restart a given simulation at the last successfully written checkpoint. We then implement multiple different checkpointing backends based on two different file formats HDF5, JSON with options that allow us to combine data into a single checkpoint and write this checkpoint collaboratively using MPI-IO as well as an option for an independent writer, where each rank writes their own respective data to an independent file. Last but not least, we present the correctness of these implementations and compare the overall overhead for writing checkpoints for all implementations. The results show that implementations that use the MPI-IO writer result in an overall worse performance, with the highest overhead, in our tests on NFS4 mount points while we see the best performance, with the lowest overhead of around 1 to 2 percent points for independent checkpointing with HDF5 on a local EXT4 mounted disk. Furthermore, we evaluate if loading a checkpoint preforms better than rerunning the simulation from scratch, with an overall cost of rerunning that takes 180 times longer than loading a checkpoint. We also provide a recommendation that the HDF5 based checkpointing backend should be preferred with independent checkpoints onto a local hard drive or better a network attached storage. The later will simplify restoring a checkpoint when multiple compute nodes are participating in the simulation. Die jüngsten Hardware-Fortschritte beziehen sich hauptsächlich darauf, mehr Cores zu der Architektur hinzuzufügen und die zunehmende Unterstützung von mehr random access memory. Dies erfordert skalierbare Software, die das meiste aus den verfügbaren Kernen herausholt, insbesondere für Simulationssoftware, da diese in HPC-Serverclustern nicht nur auf mehreren Cores, sondern auf mehreren CPUs mit Interkommunikation über MPI läuft. OpenDiHu ist so eine Simulationssoftware, die für eine Skalierung auf mehr als 10000 Kerne zur Modellierung von Skelettmuskeln, neuronaler Aktivierung und EMG-Signalen ausgelegt ist. Derzeit ist es möglich, den OpenDiHu mechanics solver parallel laufen zu lassen, wenn dieser solver als eigenständige Komponente verwendet wird. Die parallele Ausführung des solvers mit preCICE ist derzeit nicht möglich. Wir stellen zunächst eine überarbeitete Version des Algorithmus für die Berechnung der boundary conditions vor, der die parallele Unterstützung für den mit preCICE gekoppelten mechanics solver ermöglicht, indem wir ihre jeweiligen ghost values berücksichtigen. Wir zeigen, dass dies die Ausführungszeit je nach Simulationsexperiment um bis zu 80% reduziert. Anschließend stellen wir eine neue, erweiterbare Komponente vor, mit der Checkpoints in einem vordefinierten Intervall erstellt werden können. Dies ist eine gängige Technik, um die Widerstandsfähigkeit von Simulationssoftware gegenüber harten Ausfällen zu erhöhen. Wir sind in der Lage, eine bestimmte Simulation am letzten erfolgreich geschriebenen Kontrollpunkt neu zu starten. Dann implementieren wir mehrere verschiedene Checkpoint Backends, die auf zwei verschiedenen Dateiformaten basieren: HDF5 und JSON, mit mehreren unterschiedlichen Optionen, die es uns ermöglichen, Daten in einem einzigen Checkpoint zu kombinieren und diesen Checkpoint kollaborativ mit MPI-IO zu schreiben, sowie eine Option für einen unabhängigen writer, bei dem jeder Rang seine eigenen Daten in eine unabhängige Datei schreibt. Zu guter Letzt präsentieren wir die Korrektheit dieser Implementierungen und vergleichen den Gesamtaufwand für das Schreiben von Checkpoints für alle Implementierungen. Die Ergebnisse zeigen, dass Implementierungen, die den MPI-IO writer verwenden, in unseren Tests auf NFS4 Dateisystemen zu einer insgesamt schlechteren Leistung mit dem höchsten Overhead führen, während wir die beste Leistung mit dem geringsten Overhead von etwa 1 bis 2 Prozentpunkten für unabhängiges Checkpoints mit HDF5 auf einem lokalen EXT4-Dateisystem sehen. Darüber hinaus bewerten wir, ob das Laden eines Checkpoints besser performt als das erneute Ausführen der Simulation. Dabei fällt auf, dass das erneute Ausführen um die 180-mal länger dauern als das Laden eines Checkpoints. Außerdem empfehlen wir, dass das HDF5-basierte Checkpointing-Backend mit unabhängigen Checkpoints auf einer lokalen Festplatte oder besser einem an das Netzwerk angeschlossenen Speicher bevorzugt werden sollte, dass vereinfacht das spätere laden von einem Checkpoint, wenn mehrere unterschiedliche Rechenknoten an der Simulation beteiligt sind.