Einer der großen Vorteile, die sich hhpberlin von der Verwendung der Microsoft Entwicklungsplattform verspricht ist die Möglichkeit, parallel im Cluster zu debuggen. Für den Anfang soll dabei der in Visual Studio 2008 (und 2005) integrierte MPI Clusterdebugger verwendet werden. Später wird als Alternative das Visual Studio Plugin DDKLite von Allinea evaluiert.
Um den Visual Studio Debugger einzusetzen muss er zuerst ausgewählt werden. Und dabei habe ich eine Überraschung erlebt. Hier die Einstellungsseite eines Visual C++ Projekts, Debugging Tab:
Wie man sieht kann man einfach den MPI Clusterdebugger auswählen.
Jetzt dieselbe Seite für ein Intel Fortran Projekt wie FDS5:
Wie man sieht - keine Möglichkeit, den MPI Debugger auszuwählen.
Aber aber einen Trick gefunden: FDS5 verwendet eine statische C++-Library. Diese kompiliere ich mit dem Visual C++ Compiler (nicht Intel C++). Der Trick ist nun, diese Library statt des eigentlichen Executable-Projekts als Startobjekt festzulegen und alle Debuggingeinstellungen da zu machen. Dem Debugger ist es egal, aus welchem Projekt er gestartet wird.
Die nächste Aufgabe war es, geeignete Einstellungen für den Debugging-Dialog zu finden. Dazu muss der Debugger einen Job im HPC-Scheduler erzeugen. Der Scheduler verteilt die einzelnen Prozesse auf die Clusterknoten und der Debugger hängt sich an diese Prozesse an. Die alte Anweisung für Compute Cluster Server 2003 funktioniert mit HPC Server 2008 nicht mehr!
Stattdessen muss man den Debugger einen HPC Scheduler Job erzeugen lassen.
Hier die Konfiguration:
Durch diese Parameter wird ein Debug-Job im Cluster erzeugt.
Ehe nun das Debuggen losgehen kann sind einige Einstellungen auf den ausgewählten Knoten erforderlich.
Eine Einstellung, die von den persönlichen Präferenzen abhängt ist die Frage, ob der Debugger beim Anhalten im Breakpoint alle Prozesse unterbrechen soll oder nur den, der auf den Breakpoint gelaufen ist. Das kann man unter Extras-Optionen-Debugging-Allgemein einstellen:
Ist all das konfiguriert kann man Breakpoints setzen und dann einfach das Projekt starten. Der Debugger erzeugt den Job im Cluster und verbindet sich dann mit den einzelnen Prozessen:
Sinnvoll ist es dann, als erstes eine Überwachung auf den MPI Rank zu setzen (das ist die MPI-eigene ID des jeweiligen Prozesses), damit man in jedem Breakpoint sofort sieht in welchem Prozess man ist.
Nach dem Beenden des Debuggens darf man nicht vergessen, den Job im HPC Job Scheduler zu beenden, sonst bleiben die knoten blockiert und man kann weder noch einmal debuggen noch andere Rechnungen ausführen.
Wer übrigens wissen will, wie man den MPI Debugger lokal für mehrere Prozesse einsetzt: Das ist hier dokumentiert. Dabei dann die Teile zum Remote Debug Monitor ignorieren.
Gruß, Steffen