VASP mit Grafikprozessorbeschleunigung

Anleitung für grafikprozessorfähige Anwendungen lesen und direkt beginnen

VASP

VASP (Vienna Ab Initio Simulation Package) ist eine Anwendung für elementare Berechnungen der Elektronenstruktur auf atomarer Ebene durch Lösungsnäherung an die Schrödingergleichung. Die Anwendung nutzt dabei sowohl die standardmäßige Dichtefunktionaltheorie sowie fortschrittliche Funktionen wie Hybridfunktionale, Greensche Funktionen (GW-Näherung und Random-Phase-Approximation gemäß Fluktuations-Dissipations-Theorem mit adiabatischer Verbindung – ACFDT-RPA) sowie die MP2-Störungstheorie (Møller-Plesset-Störungstheorie zweiter Ordnung).

Im Vergleich zu reinen CPU-Systemen läuft VASP auf Systemen mit NVIDIA Tesla P100-Grafikprozessoren bis zu ca. 10-mal schneller. Dadurch lassen sich in der gleichen Zeit rechenintensivere und zugleich präzisere Methoden einsetzen.

VASP läuft auf Grafikprozessoren bis zu 10-mal schneller

Installation

Systemanforderungen

VASP wird in Form von Quellcode verteilt und verfügt über einige Übersetzungs- und Laufzeitabhängigkeiten. In dieser Anleitung gehen wir davon aus, dass folgende Software-Pakete bereits auf Ihrem Linux-System installiert sind und dass die jeweiligen Umgebungsvariablen bereits konfiguriert sind:

  1. Intel Compiler Suite (insbesondere Fortran, C/C++ und MKL)
  2. Intel MPI
  3. NVIDIA CUDA 8.0

In den meisten Fällen wurden diese Pakete durch die Administratoren auf Ihrem Supercomputer installiert und lassen sich über ein Modulsystem laden. Die Installation dieser Pakete wird in dieser Anleitung nicht abgedeckt. Wenden Sie sich bei Bedarf daher an Ihr Cluster-Support-Team.

Die neueste Version des VASP-GPU-Ports lässt sich mit der PGI-Compiler-Suite kompilieren. Eine Community Edition der Suite ist kostenlos verfügbar. Da viele VASP-Anwender jedoch den Intel-Compiler verwenden, gehen wir auch in dieser Anleitung von diesem Compiler aus.

Download und Kompilierung

ALLE ERFORDERLICHEN QUELLEN HERUNTERLADEN

VASP ist kommerzielle Software. Als Inhaber einer normalen VASP-Lizenz können Sie die neueste Version des GPU-Ports herunterladen. Lizenzen können Sie auf dieser Seite erwerben. Geben Sie rechts unter „Community Portal“ Ihre Anmeldedaten ein und klicken Sie auf „Login“, um den Download-Bereich aufzurufen. Klicken Sie auf „VASP5“ und wählen Sie den Ordner „src“ aus. Sie müssen folgende Dateien herunterladen (Stand beim Verfassen dieses Texts):

vasp.5.4.4.tar.gz

Sehen Sie regelmäßig auf der VASP-Website nach, ob es aktuelle Patches oder neue Versionen gibt.

EXTRAHIEREN UND PATCHEN

Extrahieren Sie zunächst den heruntergeladenen VASP-Quellcode:

tar xfz vasp.5.4.4.tar.gz

Wechseln Sie dann zum soeben extrahierten Verzeichnis mit den Quellen und wenden Sie die Patches an:

cd vasp.5.4.4

Für das VASP-Makefile sind zur Anpassung an Ihre lokale Software-Umgebung einige Änderungen erforderlich. VASP umfasst mehrere Makefile-Vorlagen für verschiedene Konfigurationen. Sie befinden sich im Unterordner „arch/“. Kopieren Sie aus dem Ordner „arch/“ ein geeignetes „makefile.include“ (in dieser Anleitung verwenden wir den Fortran-Compiler von Intel sowie NVIDIA CUDA auf einem Linux-System):

cp arch/makefile.include.linux_intel makefile.include

Wenn Sie das „makefile.include“ anpassen müssen, finden Sie unten im Abschnitt Fehlerbehebung hilfreiche Informationen.

Die meisten Optionen in „makefile.include“ funktionieren umgehend nach der Installation, da sie die erforderlichen Werte in den Umgebungsvariablen automatisch erkennen. Allerdings ist es in jedem Fall sinnvoll, für die Variable GENCODE_ARCH in der soeben kopierten Datei einen für Ihre Grafikprozessoren geeigneten Wert festzulegen. Überprüfen Sie die Compute Capability (CC) Ihrer Grafikkarte(n) und bearbeiten Sie „makefile.include“ mit einem Editor, wie nano, vim oder emacs, die auf vielen Systemen standardmäßig verfügbar sind:

nano makefile.include

Wir verwenden NVIDIA P100-Karten und kompilieren daher für Compute Capability 6.0, um die beste Leistung zu erzielen. Daher können wir die Standardzeile GENCODE_ARCH verwenden, die folgendermaßen aussieht:

GENCODE_ARCH  := -gencode=arch=compute_30,code=\"sm_30,compute_30\" \
-gencode=arch=compute_35,code=\"sm_35,compute_35\" \
-gencode=arch=compute_60,code=\"sm_60,compute_60\"

Die Einbeziehung von Flags für nicht verwendete Compute Capabilities (z. B. 3.5) hat keine negativen Auswirkungen, ermöglicht jedoch im Gegenzug die Ausführung der resultierenden Binärdatei auf weiteren Grafikprozessorarchitekturen. Wenn der Ziel-Grafikprozessor eine andere Compute Capability hat, müssen Sie die Zeile entsprechend anpassen. Wenn Sie beispielsweise auch einen V100 verwenden möchten (mit CUDA 9), muss die Zeile folgendermaßen lauten:

GENCODE_ARCH  := -gencode=arch=compute_30,code=\"sm_30,compute_30\" \
-gencode=arch=compute_35,code=\"sm_35,compute_35\" \
-gencode=arch=compute_60,code=\"sm_60,compute_60\" \
-gencode=arch=compute_70,code=\"sm_70,compute_70\"

Erstellen Sie nun den GPU-Port von VASP, indem Sie Folgendes ausführen. Dabei dürfen Sie „-j“ jedoch nicht verwenden, weil VASP keine parallele Erstellung unterstützt:

make gpu

Wenn die Kompilierung erfolgreich war, finden Sie die grafikprozessorbeschleunigte Version von VASP unter „bin/vasp-gpu“. Mit folgendem Befehl können Sie nachprüfen, ob die Binärdatei erstellt wurde:

ls -l bin/vasp-gpu

Wenn die Erstellung fehlschlägt, lesen Sie den Abschnitt Erstellungsvariablen anpassen unter Fehlerbehebung.

Wenn die Erstellung erfolgreich war, erstellen Sie im Anschluss den GPU-Port von VASP, der nicht-kollineare Berechnungen ermöglicht (wenn LNONCOLLINEAR=.TRUE. oder LSORBIT=.TRUE. in der INCAR), wenn als Ziel „gpu_ncl“ verwendet wird. Die Punktvariante Γ von VASP wird auf dem Grafikprozessor noch nicht unterstützt.

 

Sie können auch die reinen CPU-Versionen (std, ncl, gam) erstellen:

make gpu_ncl std ncl gam

Dadurch erhalten Sie die im Folgenden aufgelisteten Binärdateien. In dieser Anleitung werden jedoch nur „vasp_gpu“ und optional „vasp_std“ verwendet:

Tabelle 1: Überblick über die ausführbaren Dateien, die für VASP erstellt werden

vasp_std Default version of VASP
vasp_ncl Special version required to run calculations with LNONCOLLINEAR=.TRUE. or LSORBIT=.TRUE. in the INCAR
vasp_gam Special version that saves memory and computations for calculations at Γ only.
vasp_gpu Same as vasp_std, but with GPU acceleration
vasp_gpu_ncl Same as vasp_ncl, but with GPU acceleration

Wir empfehlen die Installation der VASP-Binärdateien unter einem Pfad außerhalb des Erstellungsverzeichnisses, z. B. unter „~/bin“. Dadurch vermeiden Sie, dass die Dateien versehentlich durch zukünftige Versionen überschrieben werden:

mkdir -p ~/bin
cp bin/vasp* ~/bin

POTCAR-DATENBANK INSTALLIEREN

VASP verwendet Daten in Tabellenform zur Glättung der Allelektronen-Wellenfunktionen. Sie werden häufig als Pseudopotenziale bezeichnet. Diese Pseudopotenziale können Sie herunterladen.

Geben Sie rechts unter „Community Portal“ Ihre Anmeldedaten ein und klicken Sie auf „Login“, um den Download-Bereich aufzurufen. Klicken Sie dann auf „Potentials“ und beginnen Sie mit „LDA“. Laden Sie alle Dateien, die Sie dort finden, herunter, und gehen Sie mit den Ordnern „PBE“ und „PW91“ genauso vor.

Dadurch erhalten Sie folgende Dateien:

  1. potpaw_PBE.tgz
  2. potpaw_PBE.54.tar.gz
  3. potpaw_PBE.52.tar.gz
  4. potpaw_LDA.tgz
  5. potpaw_LDA.54.tar.gz
  6. potpaw_LDA.52.tar.gz
  7. potpaw_GGA.tar.gz
  8.  potUSPP_LDA.tar.gz
  9. potUSPP_GGA.tar.gz

Entpacken Sie sie mithilfe dieses Skripts: extractPOTCARs.sh.

Alle Skripte aus dieser Anleitung stehen als Download zur Verfügung. Sie können das Repository auch direkt auf Ihr Dateisystem klonen. Verwenden Sie hierfür:

Ausführung von Aufgaben

Erste grafikprozessorbeschleunigte VASP-Berechnung

Bei ein paar Optionen in der Hauptsteuerdatei INCAR müssen für den GPU-Port von VASP ein paar spezielle Aspekte berücksichtigt werden. Die GPU-Version von VASP gibt Fehler- und Warnmeldungen aus, wenn die Einstellungen in der Datei INCAR nicht unterstützt oder nicht empfohlen werden.

Ignorieren Sie Meldungen im Zusammenhang mit Grafikprozessoren nicht, sondern ergreifen Sie geeignete Maßnahmen. In diesem Abschnitt werden die für den Grafikprozessor relevanten INCAR-Einstellungen erläutert.

Beschränken Sie sich bei der ALGO-Flag auf folgende Optionen:

  1. Normal
  2. Fast
  3. Veryfast

Andere in VASP verfügbare Algorithmen wurden nicht umfassend getestet. Ihre Funktionsfähigkeit kann nicht garantiert werden und möglicherweise sind ihre Ergebnisse nicht korrekt. Zudem müssen Sie folgende Einstellungen in der INCAR-Datei verwenden:

  1. LREAL = .TRUE. oder LREAL = A
  2. NCORE = 1

Zum Einstieg stellen wir als Beispiele ein paar Berechnungen vor, anhand derer wir später zeigen werden, wie Sie im Vergleich zur einfachen Konfiguration bessere Leistung erzielen. Auf git repository finden Sie ein paar Beispiele für Eingabedateien. Rufen Sie das richtige Verzeichnis auf und sehen Sie sich die Datei INCAR kurz an. Sie sehen, dass sie den oben aufgeführten Optionen entspricht:

cd gpu-vasp-files/benchmarks

Aus urheberrechtlichen Gründen müssen Sie die erforderlichen POTCAR-Dateien selbst generieren. Wir gehen nun davon aus, dass Sie die Pseudopotenzial-Datenbank wie dargestellt heruntergeladen und installiert haben und die Dateien sich im Verzeichnis „~/vasp/potcars/“ befinden. Die als Beispiele verwendeten Eingabedateien verfügen über ein Skript, das die Generierung automatisch durchführt. Hierfür muss es jedoch den Pfad zur POTCAR-Datenbank kennen:

cd siHugeShort
bash generatePOTCAR.sh ~/vasp/potcars

Dann können Sie mit Ihrer ersten grafikprozessorbeschleunigten VASP-Berechnung beginnen:

~/bin/vasp_gpu

Dadurch wird lediglich ein Prozess gestartet, bei dem nur ein Grafikprozessor und eine CPU-Recheneinheit verwendet wird, unabhängig davon, wie viele auf Ihrem System verfügbar sind. Eine solche Ausführung nimmt unter Umständen relativ viel Zeit in Anspruch, zeigt jedoch, dass alles funktioniert. Um zu prüfen, ob der Grafikprozessor aktiv verwendet wird, geben Sie

nvidia-smi -l

in einen Terminal ein, der mit demselben Knoten verbunden ist, auf dem der Prozess ausgeführt wird. Sie sollten nun Ihren VASP-Prozess unter den aufgeführten Prozessen sowie die Auslastung des Grafikprozessors sehen. Drücken Sie Strg+C, um die Wiedergabe zu unterbrechen.

Einzelnen Rechenknoten verwenden

Wie die Standardversion von VASP ist der GPU-Port mit MPI parallelisiert und kann den Rechen-Workload auf mehrere CPUs, Grafikprozessoren und Knoten verteilen. In dieser Anleitung verwenden wir Intel MPI. Die beschriebenen Methoden sind jedoch auch mit anderen MPI-Implementierungen kompatibel. In der Dokumentation zu Ihrer jeweiligen MPI-Implementierung finden Sie die entsprechenden Befehlszeilenoptionen.

VASP unterstützt eine ganze Reihe an Funktionen und Algorithmen und hat daher ein sehr vielseitiges Berechnungsprofil. Je nachdem, welche Berechnungen Sie konkret durchführen, benötigen Sie möglicherweise andere Parameter, um die Ausführungszeiten zu minimieren. Diese Aspekte werden auch in den GPU-Port übernommen.

In dieser Anleitung stellen wir verschiedene Methoden zur Beschleunigung der Grafikprozessorausführungen vor. Da es jedoch keine allgemeingültige optimale Konfiguration gibt, müssen Sie Ihre Fälle einzeln beurteilen und die Konfiguration ermitteln, die jeweils die beste Leistung ermöglicht.

Zuerst wird überprüft, wie viele Grafikprozessoren Ihr Knoten unterstützt und welche:

nvidia-smi –L

An der Ausgabe dieses Befehls sehen wir, dass vier Tesla P100-Grafikprozessoren zur Verfügung stehen. Außerdem sind ihre UUIDs aufgelistet, die wir später verwenden werden:

GPU 0: Tesla P100-PCIE-16GB (UUID: GPU-74dff14b-a797-85d9-b64a-5293c94557a6)
GPU 1: Tesla P100-PCIE-16GB (UUID: GPU-576df4e5-8f0c-c773-23d2-7560fd29542e)
GPU 2: Tesla P100-PCIE-16GB (UUID: GPU-cff44500-e07e-afef-8231-0bdd32dde61f)
GPU 3: Tesla P100-PCIE-16GB (UUID: GPU-54c0a6db-b406-3e24-c28b-0b517549e824)

Typischerweise müssen Grafikprozessoren Daten zwischen ihrem eigenen Speicher und dem Hauptspeicher übertragen. Auf Mehrsockelsystemen hängt die Übertragungsleistung vom Pfad ab, den die Daten nehmen werden. Im besten Fall besteht eine direkte Busverbindung zwischen den beiden separaten Speicherbereichen. Im ungünstigsten Fall muss der CPU-Prozess auf Speicher zugreifen, der sich physisch in einem RAM-Modul befindet, das dem anderen CPU-Sockel zugeordnet ist. Diesen Speicher muss der Prozess dann auf den Grafikprozessorspeicher kopieren, auf den wiederum nur über eine PCIe-Verbindung zugegriffen werden kann, die vom anderen CPU-Sockel gesteuert wird. Informationen zur Bus-Topologie können Sie mithilfe von folgendem Befehl abrufen:

nvidia-smi topo -m

Da die grafikprozessorbeschleunigte VASP-Anwendung direkte Kommunikation zwischen Grafikprozessoren (noch) nicht unterstützt, kann der Großteil der Ausgabe ignoriert werden, in dem steht, welche Grafikprozessorpaare am schnellsten (PIX oder sogar NV#) bzw. am langsamsten (SOC) miteinander kommunizieren könnten:

  GPU0 GPU1 GPU2 GPU3 mlx5_0 CPU Affinity
GPU0 X SOC SOC SOC SOC 0-15
GPU1 SOC X PHB PHB PHB 16-31
GPU2 SOC PHB X PIX PHB 16-31
GPU3 SOC PHB PIX X PHB 16-31
mlx5_0 SOC PHB PHB PHB X  

Die letzte Spalte („CPU Affinity“) ist wichtig, da Sie darin sehen, auf welchen CPU-Recheneinheiten die MPI-Ränge idealerweise ausgeführt werden sollten, wenn sie mit einem bestimmten Grafikprozessor kommunizieren. Wie wir sehen können, sind alle CPU-Recheneinheiten im ersten Sockel (0–15) in der Lage, direkt mit GPU 0 zu kommunizieren. Bei den CPUs im zweiten Sockel (16–31) ist die Leistung erwartungsgemäß jedoch am besten, wenn sie mit den GPUs 1, 2 und 3 kombiniert werden.

Benchmarks

Erwartete Leistung

Wenn Sie die Ausführungszeiten bei Durchläufen mit verschiedenen Konfigurationen vergleichen möchten, sind unvorhergesehene Abweichungen unbedingt zu vermeiden. NVIDIA-Grafikprozessoren bieten Möglichkeiten, die Taktraten auf Basis der aktuellen thermischen und Rechenlast vorübergehend zu steigern oder zu reduzieren. Diese Maßnahmen wirken sich zwar positiv auf den Energieverbrauch aus. Beim Benchmarking können sie jedoch zu irreführenden Ergebnissen führen, die auf eine etwas höhere Varianz der Ausführungszeiten bei mehreren Durchläufen zurückzuführen sind. Um vergleichbare Ergebnisse für das Benchmarking zu erhalten, versuchen wir also, diese Funktion auf allen Karten des Systems zu deaktivieren.

Wenn Sie mit dem Benchmarking fertig sind, können Sie die Karten zurücksetzen, sodass sie die Anpassung auf alle unterstützten Frequenzen ohne Einschränkungen vornehmen können:

HINWEIS ZU DEN LEISTUNGSZAHLEN

Obwohl die Leistungszahlen auf Produktionssystemen generiert wurden, sollen sie lediglich als Anhaltspunkt dienen und die im Folgenden vorgestellten Methoden demonstrieren. Da viele Faktoren Einfluss auf die Leistung von CPUs und Grafikprozessoren haben, weicht die Leistung auf Ihrem System möglicherweise von den Werten ab.

Die einfachste Methode: ein Prozess pro Grafikprozessor

Die einfachste Methode, mit der sich alle vier Grafikprozessoren auf unserem System nutzen lassen, ist Folgende: Sie starten vier MPI-Prozesse von VASP. Das Mapping, bei dem festgelegt wird, auf welchen CPU-Recheneinheiten die Prozesse ausgeführt werden, erfolgt dann automatisch:

mpirun -n 4 ~/bin/vasp_gpu

Die Intel MPI-Umgebung ordnet Prozesse und CPU-Recheneinheiten automatisch fest einander zu. Das Betriebssystem kann diese Prozesse dann während der Ausführung der Aufgabe nicht auf andere Recheneinheiten verlagern, wodurch nachteilige Szenarien für die Datenbewegung verhindert werden. Dennoch kann hier eine suboptimale Lösung die Folge sein, da die MPI-Implementierung die Grafikprozessor-Topologie nicht kennt. Diese feste Zuordnung von Prozessen können wir durch Erhöhen der Verbosität näher untersuchen:

mpirun -n 4 -genv I_MPI_DEBUG=4 ~/bin/vasp_gpu

Durch den Vergleich dieser Ausgabe mit unseren Ergebnissen zur Verbindungstopologie erkennen wir, dass das Ergebnis nicht ideal ist:

...

[0] MPI startup():
Rank
Pid
Node name
Pin cpu

 
[0] MPI startup():
0
41587
hsw227
{16,17,18,19,20,21,22,23}

 
[0] MPI startup():
1
41588
hsw227
{24,25,26,27,28,29,30,31}

 
[0] MPI startup():
2
41589
hsw227
{0,1,2,3,4,5,6,7}

 
[0] MPI startup():
3
41590
hsw227
{8,9,10,11,12,13,14,15}


Using device 0 (rank 0, local rank 0, local size 4) : Tesla P100-PCIE-16GB

Using device 1 (rank 1, local rank 1, local size 4) : Tesla P100-PCIE-16GB

Using device 2 (rank 2, local rank 2, local size 4) : Tesla P100-PCIE-16GB

Using device 3 (rank 3, local rank 3, local size 4) : Tesla P100-PCIE-16GB

...

Rang 0 verwendet GPU 0, ist jedoch an die weiter entfernten CPU-Recheneinheiten 16–23 gebunden. Das gleiche Problem tritt bei Rang 2 und 3 auf. Nur Rang 1 verwendet GPU 1 und ist den Recheneinheiten 24–31, die optimale Übertragungsleistung bieten, fest zugeordnet.

Sehen wir uns nun einige Zahlen zur tatsächlichen Leistung an. Bei Verwendung aller 32 Recheneinheiten der beiden Intel® Xeon® E5-2698 v3-CPUs unseres Systems ohne Grafikprozessorbeschleunigung dauerte es 607,142 s bis zum Abschluss des Benchmarks siHugeShort.1 Durch die Verwendung von vier Grafikprozessoren in diesem Standardszenario, das jedoch suboptimal ist, verkürzt sich die Ausführungszeit auf 273,320 s, was einer Beschleunigung um das 2,22-Fache entspricht. Mithilfe folgender Messwerte in VASP finden Sie schnell heraus, wie lange Ihre Berechnung gedauert hat.

1 Wenn Sie die rein CPU-basierte Version von VASP bereits erstellt haben, sehen Sie mithilfe von folgendem Befehl, wie lange der Prozess auf Ihrem System dauert: mpirun -n 32 -env I_MPI_PIN_PROCESSOR_LIST=allcores:map=scatter ~/bin/vasp_std

grep Elapsed\ time OUTCAR

VASP ordnet die Grafikprozessoren den MPI-Rängen konsekutiv zu und überspringt dabei Grafikprozessoren mit unzureichenden Compute Capabilities (sofern vorhanden). Dadurch und durch die Verwendung der folgenden Syntax können wir die Zuordnung von Prozessen zu CPUs manuell festlegen und die Ränge so verteilen, dass jeder Prozess den Grafikprozessor mit dem kürzesten Speicherübertragungspfad verwendet:

mpirun -n 4 -genv I_MPI_DEBUG=4 -env I_MPI_PIN_PROCESSOR_LIST=0,16,21,26 ~/bin/vasp_gpu

Diese Methode führt auf unserem System zu keiner Verbesserung (Laufzeit von 273,370 s). Dies ist wahrscheinlich auf eine unausgewogene Verwendung gemeinsamer CPU-Ressourcen wie Speicherbandbreite und Caches (3 Prozesse mit einer gemeinsamen CPU) zurückzuführen. Als Kompromiss können Sie die Ränge gleichmäßig über die CPU-Sockel verteilen. Dabei darf jedoch nur ein Rang den langsameren Speicherpfad zum Grafikprozessor verwenden:

mpirun -n 4 -genv I_MPI_DEBUG=4 -env I_MPI_PIN_PROCESSOR_LIST=0,8,16,24 ~/bin/vasp_gpu

Mit einer Laufzeit von 268,939 s verbessert sich dieser Benchmark dadurch leicht um etwa 3 %. Wenn Ihr Workload jedoch höhere Ansprüche an Speicherübertragungen stellt, ist der Vorteil vielleicht jedoch noch größer.

Insbesondere wenn es sehr viele Ränge gibt, kann die manuelle Festlegung der Verteilung sehr zeitraubend sein. Oder für Sie ist eine gleichmäßige Aufteilung der CPU-Ressourcen wichtiger als die Speicherübertragungen auf Ihrem System. Mit folgendem Befehl werden die Ränge konsekutiv zugeordnet, wobei die Aufteilung gemeinsamer Ressourcen weitgehend vermieden wird:

mpirun -n 4 -genv I_MPI_DEBUG=4 -env I_MPI_PIN_PROCESSOR_LIST=allcores:map=scatter ~/bin/vasp_gpu

Das Ergebnis ist eine Laufzeit von 276,299 s. Dieser Ansatz ist unter Umständen besonders sinnvoll, wenn einige CPU-Recheneinheiten ungenutzt bleiben. Sie können ihn gezielt einsetzen, wenn ein einzelner Prozess pro Grafikprozessor eine Grafikprozessorressource, die die Leistung beschränkt, voll auslastet. Eine weitere Überlastung des Grafikprozessors würde sich dann negativ auf die Leistung auswirken. Dies sehen wir im Beispiel mit dem siHugeShort-Benchmark. Auf unserem System werden wir kein besseres Ergebnis erzielen. Sie können die folgenden Optionen jedoch gerne selbst testen. Generell raten wir jedoch davon ab, verfügbare CPU-Recheneinheiten zu verschwenden, solange die Grafikprozessoren nicht überlastet sind. Führen Sie einfach eigene Tests durch, um Genaueres herauszufinden.

Die zweiteinfachste Methode: mehrere Prozesse pro Grafikprozessor

Um zu demonstrieren, wie wir mehr CPU-Recheneinheiten verwenden können, als Grafikprozessoren verfügbarer sind, nehmen wir nun einen anderen Benchmark her: silicaIFPEN. Wenn wir nur die 32 CPU-Recheneinheiten verwenden, dauert seine Ausführung 710,156 s. Mit den vier P100-Grafikprozessoren, einem MPI-Rang pro Grafikprozessor und dem Kompromiss im Hinblick auf die Prozesszuordnung, dauert die Ausführung 241,674 s, ist also 2,9-mal schneller. NVIDIA-Grafikprozessoren können von mehreren Prozessen gleichzeitig verwendet werden. Um diese Funktion zu nutzen, müssen alle Grafikprozessoren auf den standardmäßigen Rechenmodus („default“) gesetzt werden:

Danach führen wir die eigentliche Berechnung durch:

mpirun -n 8 -env I_MPI_PIN_PROCESSOR_LIST=0,8,16,24,4,12,20,28 ~/bin/vasp_gpu

Für den Benchmark silicaIFPEN verbesserte sich die Laufzeit auf unserem System auf 211,576 s, wenn sich 12 Prozesse die vier P100-Grafikprozessoren teilten (also 3 Prozesse pro GPU). Dies entspricht einer Beschleunigung um das 3,36-Fache. Werden auf jedem Grafikprozessor vier oder mehr Prozesse ausgeführt, wirkt sich dies jedoch negativ auf die Laufzeit aus. Der Vergleich in der Tabelle unten zeigt, dass auch eine manuelle Zuordnung der Prozesse keinen Vorteil mehr bringt.

Tabelle 2: Vergleich zwischen der Ausführungsdauer des Benchmarks silicaIFPEN in Abhängigkeit von der Anzahl der MPI-Prozesse pro Grafikprozessor

MPI ranks per GPU Total MPI ranks Elapsed time (map:scatter) Elapsed time (map:ideal)
0 32 (CPU only) 710.156 s  
1 4 242.247 s 241.674 s
2 8 214.519 s 212.389 s
3 12 212.623 s 211.576 s2
4 16 220.611 s 224.013 s3
5 20 234.540 s  
6 24 243.665 s  
7 28 259.757 s  
8 32 274.798 s  

2 mpirun -n 12 -env I_MPI_PIN_PROCESSOR_LIST=0,8,16,24,3,11,19,27,6,14,22,30 ~/bin/vasp_gpu
3 mpirun -n 16 -env I_MPI_PIN_PROCESSOR_LIST=0,8,16,24,2,10,18,26,4,12,20,28,6,14,22,30 ~/bin/vasp_gpu

Sobald der kritische Punkt erreicht ist, wird die Leistung durch jeden zusätzlichen Prozess pro Grafikprozessor noch stärker beeinträchtigt. Doch weshalb? Immer wenn ein Grafikprozessor den Kontext wechseln muss, also die Übernahme durch einen anderen Prozess ermöglichen muss, entsteht ein harter Synchronisierungspunkt. Daher ist es nicht möglich, dass sich die Anweisungen für verschiedene Prozesse auf dem Grafikprozessor überschneiden. Wird diese Funktion also zu häufig genutzt, kann der gewünschte Effekt irgendwann ins Gegenteil umschlagen. Die Abbildung unten soll dies verdeutlichen.

Zusammenfassend stellen wir fest. Es lohnt sich, zu testen, bis zu welchem Punkt sich eine übermäßige Auslastung bei Ihren Berechnungen positiv auswirkt. Natürlich lasten sehr große Berechnungen einen Grafikprozessor eher mit einem einzelnen Prozess aus als kleinere. Wir möchten Ihnen jedoch nochmals mit Nachdruck empfehlen, Ihre eigenen Tests durchzuführen.

VASP läuft auf Grafikprozessoren bis zu 10-mal schneller

NVIDIA MPS: Überschneidung bei gemeinsamer Nutzung von Grafikprozessoren möglich

Diese Methode ähnelt der zuvor beschriebenen stark. Dabei wird jedoch das Problem, dass sich die Anweisungen für mehrere Prozesse auf einem Grafikprozessor nicht überschneiden dürfen, gelöst, wie in der zweiten Zeile dargestellt. Wir empfehlen, die Grafikprozessoren auf einen Rechenmodus mit exklusiver Prozesszuordnung zu konfigurieren, wenn MPS verwendet werden:

Um diese Möglichkeit zu nutzen, müssen Sie lediglich den MPS-Server starten, bevor Sie wie gewohnt mit den MPI-Aufgaben beginnen:

nvidia-cuda-mps-control -d
mpirun -n 8 -env I_MPI_PIN_PROCESSOR_LIST=allcores:map=scatter ~/bin/vasp_gpu
echo quit | nvidia-cuda-mps-control

Mit dem ersten Befehl wird der MPS-Server im Hintergrund gestartet (Daemon-Modus). Wenn der Server läuft, werden die Anweisungen, die bei der gemeinsamen Nutzung eines Grafikprozessors durch mehrere Prozesse ausgegeben werden, zunächst an den Server gesendet und demselben Kontext zugeordnet, bevor sie an den Grafikprozessor weitergeleitet werden. Im Gegensatz zum vorherigen Abschnitt gehören die Anweisungen aus Sicht des Grafikprozessors nun zum selben Prozess und Kontext und können sich daher überschneiden. Dies ist mit der Verwendung von Streams innerhalb einer CUDA-Anwendung vergleichbar. Mithilfe von „nvidia-smi -l“ können Sie nachprüfen, ob jeweils nur ein einzelner Prozess auf einen Grafikprozessor zugreift.

Wird der GPU-Port von VASP in diesem Modus ausgeführt, trägt dies also möglicherweise zu einer besseren Auslastung der Grafikprozessoren bei, wenn die Ressourcen eines Grafikprozessors durch einen einzelnen Prozess nicht ausgelastet sind. Dies wollen wir mit einem dritten Beispiel verdeutlichen, nämlich der Berechnung B.hR105, bei der ein exakter Austausch innerhalb der HSE06-Funktion verwendet wird. Wir haben sie mit jeweils einer unterschiedlichen Anzahl an MPI-Rängen pro Grafikprozessor ausgeführt, sowohl mit als auch ohne MPS.

Tabelle 3: Vergleich zwischen der Ausführungsdauer des Benchmarks B.hR105 in Abhängigkeit von der Anzahl der MPI-Prozesse pro Grafikprozessor, jeweils mit und ohne MPS für NSIM=4

MPI ranks per GPU Total MPI ranks Elapsed time without MPS Elapsed time with MPS
0 32 (CPU only) 1027.525 s
1 4 213.903 s 327.835 s
2 8 260.170 s 248.563 s
4 16 221.159 s 158.465 s
7 28 241.594 s 169.441 s
8 32 246.893 s 168.592 s

Das wichtigste Ergebnis: Mit dem MPS verbessert sich die Ausführungszeit gegenüber dem besten Ergebnis ohne MPS (213,903 s) um 55,4 s (26 %) auf 158,456 s. Vier Ränge pro Grafikprozessor im Szenario ohne MPS sind ein kritischer Punkt. Mit MPS erzielt man hingegen die beste Leistung, wenn so viele Prozesse gestartet werden, wie CPU-Recheneinheiten verfügbar sind.

Wir haben Berechnungen mit 3, 5 und 6 Rängen pro Grafikprozessor absichtlich übersprungen, da die Anzahl der in diesem Beispiel verwendeten Bands (224) nicht durch die sich ergebende Anzahl der Ränge teilbar ist. Daher würde VASP sie automatisch erhöhen, wodurch der Workload steigt. Wenn für Sie nur die Dauer, die bis zur Lösung vergeht, interessant ist, empfehlen wir Ihnen, mit dem Parameter NSIM etwas zu experimentieren. Wenn wir ihn auf 32 einstellen und nur einen Prozess pro Grafikprozessor verwenden (also ohne MPS), können wir die Berechnungszeit auf 108,193 s reduzieren, also um das etwa Zehnfache beschleunigen.

Erweitert: eine MPS-Instanz pro Grafikprozessor

Für bestimmte Konfigurationen, insbesondere auf älteren CUDA-Versionen, ist es unter Umständen von Vorteil, mehrere Instanzen des MPS-Daemon zu starten, also zum Beispiel einen MPS-Server pro Grafikprozessor. Dieser Vorgehensweise erfordert jedoch mehr Interaktionen, da Sie für jeden MPI-Prozess angeben müssen, welchen MPS-Server er verwenden soll. Außerdem muss jede MPS-Instanz einem anderen Grafikprozessor zugeordnet werden. Besonders bei Verwendung von P100 mit CUDA 8.0 raten wir von dieser Methode ab. Das heißt aber nicht unbedingt, dass sie für Ihre Zwecke überhaupt nicht in Frage kommt. Starten Sie die MPS-Instanzen mit folgendem Skript:

Damit diese Methode funktioniert, muss der GPU-Port von VASP über den Umweg eines Wrapper-Skripts gestartet werden. Dadurch werden die Umgebungsvariablen so festgelegt, dass jeder Prozess die richtige Instanz der MPS-Server verwendet, die wir zuvor gestartet haben. runWithMultipleMPSservers-RR.sh.

Das Skript generiert im Grunde eine Liste mit den Pfaden zum Festlegen der Umgebungsvariablen, die darüber entscheiden, welche MPS-Instanz verwendet wird. Mit der viertletzten Zeile (myMpsInstance=...) wird diese Instanz dann in Abhängigkeit von der ID des lokalen MPI-Prozesses ausgewählt. Wir haben uns für ein Rundlauf-Verfahren entschieden, bei dem die Prozesse 1 bis 4 auf die Grafikprozessoren 0 bis 3 verteilt werden. Prozess 5 verwendet dann wieder GPU 0, ebenso wie Prozess 9. Die Prozesse 6 und 10 werden GPU 1 zugeordnet usw. Wenn Sie die Binärdatei für die GPU-Version von VASP unter einem anderen Pfad installiert haben, passen Sie die Zeile, die mit „runCommand“ beginnt, entsprechend an. Danach können wir mit der Berechnung beginnen:

mpirun -n 16 -env I_MPI_PIN_PROCESSOR_LIST=allcores:map=scatter ./runWithMultipleMPSservers-RR.sh

Wenn Sie einen oder mehrere MPS verwenden, sollten Sie berücksichtigen, dass diese Server selbst die CPU verwenden. Wenn Sie also so viele Prozesse starten, wie CPU-Recheneinheiten verfügbar sind, führt dies möglicherweise zu einer CPU-Überlastung. Daher ist es eventuell sinnvoll, eine oder zwei Recheneinheiten für den oder die MPS zu reservieren.

Wenn die Berechnung abgeschlossen ist, werden die MPS-Instanzen durch folgendes Skript bereinigt.

Mehrere Rechenknoten verwenden

EIN PROZESS PRO GRAFIKPROZESSOR

Im Prinzip gelten alle Ausführungen zur Verwendung von Grafikprozessoren, die sich alle auf demselben Knoten befinden, auch für Konfigurationen mit mehreren Rechenknoten. Die beste Vorgehensweise, die Sie für die Prozesszuordnung auf Ihrem System ermittelt haben, ist also wahrscheinlich auch für Systeme mit mehreren Knoten optimal. Im Folgenden gehen wir von einer Hostfile-Konfiguration aus, in der alle Knoten für die Aufgabe aufgelistet sind. In unserem Fall haben wir zwei Knoten verwendet. Die Hostfile sieht folgendermaßen aus:

hsw224
hsw225

Wenn Sie die Prozesszuordnung manuell vornehmen, unterscheidet sich der Befehl nur leicht von demjenigen im vorherigen Kapitel:

mpirun -f hostfile -n 8 -ppn 4 -genv I_MPI_DEBUG=4 -env I_MPI_PIN_PROCESSOR_LIST=0,8,16,24 ~/bin/vasp_gpu

Laut der Debugging-Ausgabe der MPI-Implementierung werden die Prozesse auf zwei Knoten aufgeteilt und residieren wie erwartet auf den CPU-Recheneinheiten:

[0] MPI startup(): Rank Pid Node name Pin cpu
[0] MPI startup(): 0 38806 hsw224 0
[0] MPI startup(): 1 38807 hsw224 8
[0] MPI startup(): 2 38808 hsw224 16
[0] MPI startup(): 3 38809 hsw224 24
[0] MPI startup(): 4 49492 hsw225 0
[0] MPI startup(): 5 49493 hsw225 8
[0] MPI startup(): 6 49494 hsw225 16
[0] MPI startup(): 7 49495 hsw225 24

Die Ausgabe der GPU-Version von VASP bestätigt, dass auch die Grafikprozessoren wie beabsichtigt den MPI-Rängen zugeordnet werden:

Using device 0 (rank 0, local rank 0, local size 4) : Tesla P100-PCIE-16GB
Using device 1 (rank 1, local rank 1, local size 4) : Tesla P100-PCIE-16GB
Using device 2 (rank 2, local rank 2, local size 4) : Tesla P100-PCIE-16GB
Using device 3 (rank 3, local rank 3, local size 4) : Tesla P100-PCIE-16GB
Using device 0 (rank 4, local rank 0, local size 4) : Tesla P100-PCIE-16GB
Using device 1 (rank 5, local rank 1, local size 4) : Tesla P100-PCIE-16GB
Using device 2 (rank 6, local rank 2, local size 4) : Tesla P100-PCIE-16GB
Using device 3 (rank 7, local rank 3, local size 4) : Tesla P100-PCIE-16GB

Die Leistung für den Benchmark siHugeShort verbessert sich auf 258,917 s. Der Vergleich mit der Laufzeit von  268,939 s auf einem einzelnen Knoten zeigt, dass die Verwendung keinesfalls gerechtfertigt ist. Für den Benchmark silicaIFPEN erhalten wir jedoch eine deutliche Verbesserung von 241,674 s auf 153,401 s, wenn wir acht P100-Grafikprozessoren anstatt nur vier verwenden (1 MPI-Prozess pro Grafikprozessor).

MEHRERE PROZESSE PRO GRAFIKPROZESSOR

Wenn wir uns die vorherigen Abschnitte ansehen, ist der Übergang auf mehrere Knoten mit mehreren Prozessen pro Grafikprozessoren der logische nächste Schritt:

mpirun -f hostfile -n 16 -ppn 8 -genv I_MPI_DEBUG=4 -env I_MPI_PIN_PROCESSOR_LIST=0,8,16,24,4,12,20,28 ~/bin/vasp_gpu

Wenn Sie alle CPU-Recheneinheiten verwenden möchten, verwenden Sie folgenden Befehl:

mpirun -f hostfile -n 64 -ppn 32 -genv I_MPI_DEBUG=4 -env I_MPI_PIN_PROCESSOR_LIST=allcores:map=scatter ~/bin/vasp_gpu

Wenn wir die Anzahl der Ränge pro Grafikprozessor erhöhen, unterscheidet sich das Ergebnis beim Benchmark silicaIFPEN etwas vom Szenario mit einem einzelnen Knoten, in dem die schnellste Konfiguration 211,576 s dauerte: Wenn auf jedem Grafikprozessor zwei Prozesse ausgeführt werden, verbessert sich die Laufzeit nur geringfügig auf 149,818 s. Wurde ein Prozess pro Grafikprozessor ausgeführt betrug der entsprechende Wert 153,401 s. Eine weitere Überlastung der Grafikprozessoren macht sich auch hier negativ bemerkbar, da sich die Laufzeit bereits bei drei Prozessen pro Grafikprozessor auf 153,516  erhöht. Bei 64 Rängen insgesamt beträgt die Dauer 231,015 s. In diesem Fall reichen also ein bis zwei Prozesse pro Grafikprozessor bereits aus.

NVIDIA MPS AUF MEHREREN KNOTEN

Die Verwendung einer einzelnen MPS-Instanz pro Knoten ist trivial, sobald die Instanzen gestartet wurden. Bei einigen Job-Schedulern gibt es Optionen, die dies übernehmen. SLUM bietet manchmal zum Beispiel „--cuda-mps“ an. Wenn in Ihrem Cluster eine entsprechende Option zur Verfügung steht, sollten Sie unbedingt davon Gebrauch machen. Gehen Sie wie im vorherigen Abschnitt beschrieben vor.

Doch was, wenn Ihr Scheduler keine solche Möglichkeit bietet? Achten Sie in solchen Fällen darauf, dass auf jedem Knoten eine (genau eine) MPS-Instanz gestartet wird, bevor VASP aufgerufen wird. Verwenden Sie hierfür folgendes Skript: runWithOneMPSPerNode.sh.

Auch hier müssen Sie die Variable „runCommand“ am Anfang des Skripts anpassen, wenn Sie die Binärdatei für die grafikprozessorbeschleunigte VASP-Anwendung unter einem anderen Pfad gespeichert haben. Mit den darauf folgenden Variablen wird der lokale Rang auf jedem Knoten berechnet, da die MPI-Implementierung von Intel Informationen nicht so einfach preisgibt. Durch das Skript wird auf dem ersten Rang jedes Knotens ein MPS-Server gestartet, damit der MPS-Prozess nicht an denselben Kern gebunden ist, an den später ein VASP-Prozess gebunden wird. Dieser Schritt ist entscheidend. Denn der MPS kann mehr als eine Recheneinheit verwenden und wäre durch die Verwendung nur einer Recheneinheit eingeschränkt. Verschärfen würde sich die Situation dadurch, dass der MPS mit VASP um CPU-Zyklen auf dieser Recheneinheit konkurrieren würde. Das Skript führt VASP weiter aus und stoppt den MPS anschließend.

Wie Sie im Abschnitt „Erweitert“ vielleicht schon gesehen haben, müssen Sie das Skript mithilfe des Befehls „mpirun“ aufrufen. Der Befehl „mpirun“ funktioniert genauso wie im Szenario ohne MPS. Hier rufen wir jedoch das Skript anstatt der VASP-Binärdatei auf:

mpirun -f hostfile -n 24 -ppn 12 -genv I_MPI_DEBUG=4 -env I_MPI_PIN_PROCESSOR_LIST=allcores:map=scatter ./runWithOneMPSPerNode.sh

Im Hinblick auf den Benchmark B.hR105 verbessert sich die Laufzeit auf einem einzelnen Knoten durch den MPS. Dies gilt auch für Systeme mit zwei Knoten: Durch Aktivierung des MPS verkürzt sich die Berechnungszeit. Und die Verwendung von mehr Rängen pro Grafikprozessor wirkt sich bis zu einem gewissen (Über-)Sättigungspunkt positiv aus. Auf unserem System lag der kritische Punkt bei vier Rängen pro Grafikprozessor. Die Laufzeit betrug hier 104,052 s. Im Vergleich zur Baseline auf einem einzelnen Haswell-Knoten entspricht dies einer 9,05-fachen Beschleunigung. Im Vergleich zur Verwendung aller 64 CPU-Recheneinheiten wird hier immer noch eine 6,61-fache Beschleunigung erzielt.

Wenn wir NSIM=32 mit vier Rängen pro Grafikprozessor auf jedem der beiden Knoten ohne MPS verwenden, dauert die Berechnung nur 71,222 s.

Tabelle 4: Vergleich zwischen der Ausführungsdauer des Benchmarks B.hR105 in Abhängigkeit von der Anzahl der MPI-Prozesse pro Grafikprozessor, jeweils mit und ohne MPS für NSIM=4 bei Verwendung von 2 Knoten.

MPI ranks per GPU Total MPI ranks Elapsed time without MPS Elapsed time with MPS
0 32 (CPU only – 1 node) 1027.525 s
0 64 (CPU only) 763.939 s4
1 8 127.945 s 186.853 s
2 16 117.471 s 110.158 s
4 32 130.454 s 104.052 s
7 56 191.211 s 148.662 s
8 64 234.307 s5 182.260 s

4, 5 Here 256 bands were used, which increases the workload.

VASP läuft auf Grafikprozessoren bis zu 10-mal schneller

Empfohlene Systemkonfigurationen

Hardwarekonfiguration

Workstation

Parameter
Specs

CPU Architecture

x86_64

System Memory

32-64 GB

CPUs

8 Cores, 3+ GHz
10 cores, 2.2+ GHz
16 Cores, 2+ GHz

GPU Model

NVIDIA Quadro GP100

GPUs

2-4

Servers

Parameter
Specs

CPU Architecture

x86_64

System Memory

64-128 GB

CPUs

16+ Cores, 2.7+ GHz

GPU Model

NVIDIA Tesla P100, V100

GPUs per Node

2-4

Softwarekonfiguration

Software stack

Parameter
Version

OS

Linux 64

GPU Driver

352.79 or newer

CUDA Toolkit

8.0 or newer

Compiler

PGI Compiler 16.10
Intel Compiler Suite 16

MPI

OpenMPI
Intel MPI

Fehlerbehebung

ERSTELLUNGSVARIABLEN ANPASSEN (optional)

Möglicherweise weicht Ihre lokale Softwareumgebung von den Umgebungen ab, die vom VASP-Erstellungssystem automatisch unterstützt werden. In diesem Fall schlägt die Erstellung fehl und Sie müssen an „makefile.include“ kleinere Anpassungen vornehmen. Öffnen Sie „makefile.include“ in einem Editor Ihrer Wahl (nano, vim und emacs stehen beispielsweise standardmäßig auf vielen Systemen zur Verfügung) und nehmen Sie die erforderlichen Änderungen vor (siehe unten):

nano makefile.include

Wenn Sie an einer beliebigen Datei Änderungen vorgenommen haben, führen Sie folgenden Befehl aus, um die Erstellung von Beginn an durchzuführen:

make veryclean

Im Folgenden sind ein paar typische Fehlermeldungen und die entsprechenden Fehlerbehebungen aufgeführt:

mpiifort: Command not found

Diese Fehlermeldung sehen Sie, wenn der MPI-sensible Intel Fortran-Compiler auf Ihrem System einen anderen Namen als erwartet hat. Ändern Sie in „makefile.include“ alle Vorkommen von „mpiifort“ in den Namen, der auf Ihrem System verwendet wird (z. B. mpif90).

# error "This Intel is for use with only the Intel compilers!"

Zum Beheben dieses Fehlers sind zwei Schritte erforderlich. Bearbeiten Sie zunächst „makefile.include“ und fügen Sie der NVCC-Variable „add -ccbin=icc“ hinzu. Die Zeile lautet dann folgendermaßen:

NVCC := $(CUDA_ROOT)/bin/nvcc -ccbin=icc

Danach müssen Sie eine zweite Datei bearbeiten:

nano src/CUDA/common.mk

Dort sehen Sie folgenden Abschnitt:

# Compilers

NVCC ?= $(CUDA_INSTALL_PATH)/bin/nvcc

CXX := g++ -fPIC -DADD_ -Wall -openmp -DMAGMA_WITH_MKL -DMAGMA_SETAFFINITY -DGPUSHMEM=300 -DHAVE_CUBLAS

CC := gcc -fPIC -DADD_ -Wall -openmp -DMAGMA_WITH_MKL -DMAGMA_SETAFFINITY -DGPUSHMEM=300 -DHAVE_CUBLAS

#CXX := icc -fPIC -DADD_ -Wall -openmp -DMAGMA_WITH_MKL -DMAGMA_SETAFFINITY -DGPUSHMEM=300 -DHAVE_CUBLAS

#CC := icc -fPIC -DADD_ -Wall -openmp -DMAGMA_WITH_MKL -DMAGMA_SETAFFINITY -DGPUSHMEM=300 -DHAVE_CUBLAS

LINK := g++ -fPIC

Ändern Sie ihn, so dass er folgendermaßen aussieht:

# Compilers

NVCC ?= $(CUDA_INSTALL_PATH)/bin/nvcc

#CXX := g++ -fPIC -DADD_ -Wall -openmp -DMAGMA_WITH_MKL -DMAGMA_SETAFFINITY -DGPUSHMEM=300 -DHAVE_CUBLAS

#CC := gcc -fPIC -DADD_ -Wall -openmp -DMAGMA_WITH_MKL -DMAGMA_SETAFFINITY -DGPUSHMEM=300 -DHAVE_CUBLAS

CXX := icc -fPIC -DADD_ -Wall -openmp -DMAGMA_WITH_MKL -DMAGMA_SETAFFINITY -DGPUSHMEM=300 -DHAVE_CUBLAS

CC := icc -fPIC -DADD_ -Wall -openmp -DMAGMA_WITH_MKL -DMAGMA_SETAFFINITY -DGPUSHMEM=300 -DHAVE_CUBLAS

LINK := g++ -fPIC

/usr/local/cuda//bin/nvcc: Command not found

Diese Meldung sehen Sie, wenn „make“ den NVIDIA CUDA-Compiler nvcc nicht finden kann. Korrigieren Sie den Pfad in folgender Zeile:

CUDA_ROOT := /usr/local/cuda/

Wenn CUDA_ROOT als Umgebungsvariable festgelegt ist, können Sie ihn alternativ auch auskommentieren. Verwenden Sie dabei # als erstes Symbol in der Zeile.

No rule to make target `/cm/shared/apps/intel/composer_xe/2015.5.223/mkl/interfaces/fftw3xf/libfftw3xf_intel.a', needed by `vasp'. Stop.

Wahrscheinlich wurde Ihr lokales MKL ohne Unterstützung für die FFTW3-Schnittstelle als statische Bibliothek installiert. Wenn Sie die Zeile mit Bezug auf diese statische Bibliothek auskommentieren, indem Sie ganz am Anfang # einfügen, wird die analoge dynamische Bibliothek eingezogen. Auskommentieren Sie die Zeile, die OBJECTS_GPU zugeordnet ist (und direkt darauf folgt) und nicht nur die Zeile nach OBJECTS.

Andere Fehlermeldungen

Wenn Ihr System die zu Beginn aufgeführten Anforderungen erfüllt, müssen Sie wahrscheinlich in der Datei „makefile.include“ nur einen Pfad zu einer Bibliothek anpassen. Weitere Erläuterungen zu den darin definierten Variablen finden Sie unter http://cms.mpi.univie.ac.at/wiki/index.php/Installing_VASP.

Ihre ideale Grafikprozessorlösung