Mehrere Meshes und MPI in FDS: Berechnungen beschleunigen

fdsrun-Redaktion · 6. November 2026 · 6 Min. Lesezeit

Warum ein großes Mesh langsam rechnet, wie Sie das Modell aufteilen, MPI-Prozesse ausbalancieren und ab wann weitere Kerne nichts mehr bringen.

Ein FDS-Modell auf einem einzigen Mesh rechnet auf einem Prozessorkern, auch wenn der Rechner sechzehn hat. Um mehr Kerne zu nutzen, müssen Sie die Domäne in mehrere Meshes (&MESH) aufteilen und FDS mit MPI starten — dann rechnet jeder Prozess seinen Teil des Modells. Eine gute Aufteilung verkürzt die Rechenzeit um ein Mehrfaches oder mehr als das Zehnfache; eine schlechte bringt fast nichts.

Regel 1: gleich viele Zellen pro Prozess

MPI-Prozesse rechnen parallel, tauschen aber in jedem Zeitschritt Daten an den Mesh-Grenzen aus und warten aufeinander. Hat ein Prozess doppelt so viele Zellen wie die anderen, stehen die übrigen die Hälfte der Zeit still. Die NIST-Dokumentation sagt es deutlich: Damit MPI gut funktioniert, braucht jeder Prozess eine vergleichbare Zellenanzahl — und selbst dann sind zwei Prozesse nicht in der halben Zeit fertig, weil Kommunikation und zusätzliche Randzellen hinzukommen (FDS User Guide, Abschnitte 6.3.3 und 3.3.1).

Ein einfacher Test: Teilen Sie die Gesamtzahl der Zellen durch die Anzahl der Prozesse und vergleichen Sie das Ergebnis mit dem größten Mesh. Ist das größte Mesh deutlich größer als der Durchschnitt, bestimmt es das Tempo.

Regel 2: mehrere kleine Meshes können sich einen Prozess teilen

Mit dem Parameter MPI_PROCESS in der Zeile &MESH weisen Sie mehrere Meshes einem Prozess zu. Das lohnt sich, wenn die Meshes unterschiedlich groß sind: Kleine Meshes werden so gruppiert, dass jeder Prozess eine ähnliche Summe erhält. Benachbarte Meshes auf demselben Prozess tauschen Daten direkt aus, ohne MPI-Kommunikation. Die Prozessnummern müssen fortlaufend und aufsteigend sein und bei 0 beginnen.

fdsrun erledigt das automatisch: Vor dem Start verteilt das Portal die Meshes so auf die Prozesse, dass der am stärksten belastete Prozess möglichst wenige Zellen hat, und zeigt, wie sich die prognostizierte Zeit mit der Prozessanzahl ändert.

Regel 3: Mesh-Grenzen

• An einer Grenze sollten die Zellen denselben Querschnitt oder ein ganzzahliges Verhältnis haben (z. B. 1:2).
• Beobachten Sie VELOCITY_ERROR an den Grenzen in CHID.out. Erreicht FDS ständig MAX_PRESSURE_ITERATIONS (Standard 10), erhöhen Sie den Wert oder ändern Sie die Einstellungen des Drucklösers (User Guide, Abschnitte 6.3.4 und 21.1).
• In der Praxis legt man eine Mesh-Grenze besser nicht durch den Brandplume selbst — dort sind die Gradienten am größten.

Wie viele Prozesse sinnvoll sind

Jeder weitere Prozess bringt weniger: Kommunikation und Randzellen nehmen zu. In unseren Kalibrierungsrechnungen auf einem einzelnen Cloud-Server (FDS 6.10.1) stieg die Beschleunigung ab etwa 16 Prozessen nicht mehr, und Server mit dedizierten Kernen waren bei einem Mehrfachen des Preises nicht schneller als geteilte. Für typische Gebäudemodelle liefern daher meist 8–16 gut ausbalancierte Prozesse das beste Verhältnis von Zeit zu Kosten.

OpenMP (Threads innerhalb eines Prozesses) beschleunigt eine Berechnung laut NIST höchstens etwa um den Faktor zwei; meist ist es besser, die Domäne in mehr Meshes aufzuteilen und einen Thread pro Prozess zu verwenden.

Beispiel

Checkliste vor dem Start

• die Meshes haben ähnliche Zellenanzahlen (oder sind mit MPI_PROCESS gruppiert);
• die Grenzen haben passende oder ganzzahlige Zellverhältnisse, ohne überlappende Meshes;
• die Anzahl der Prozesse übersteigt nicht die Anzahl der Meshes;
• DT_RESTART ist gesetzt, damit sich eine lange Berechnung fortsetzen lässt.

Das kostenlose Werkzeug unten prüft alle diese Punkte — zusammen mit der prognostizierten Zeit für die beste Prozessanzahl.

Quellen: FDS User Guide (NIST SP 1019), Kapitel 3 und Abschnitte 6.3.3, 6.3.4, 21.1; eigene Messungen von fdsrun. FDS und Smokeview sind Software des National Institute of Standards and Technology; das NIST steht in keiner Verbindung zu fdsrun.