Programmpaket Turbomole

Prof. Dr. Bernd Hartke, Universität Kiel, hartke@phc.uni-kiel.de
Programmpaket Turbomole
Informationsquellen für Turbomole
• homepage: www.turbomole.de ( = www.turbomole.com)
mit Manual im html-Format: http://www.turbomole.de/MANUAL/DOK.html
und kleiner FAQ-Liste
• lokales Manual: im pdf-Format auf dirac in $TURBODIR/DOK/DOK.pdf
( = /home/software/turbomole_5.71/TURBOMOLE/DOK/DOK.pdf)
• einige Beispiel-inputs im Manual
• direkter e-mail-Kontakt zu den Entwicklern via info@turbomole.com
• mailing list (?)
Obligatorische Zitate:
• im Manual (Kapitel 1.3)
• am Anfang des outputs jedes Teil-Programms

Prof. Dr. Bernd Hartke, Universität Kiel, hartke@phc.uni-kiel.de
Verfügbare Methoden:
• Kraftfeldberechnungen mit UFF (universal force field)
• HF, DFT, MP2 in den üblichen Varianten
• coupled-cluster in der CC2-Näherung, inkl. Behandlung angeregter Zustände
• TD-HF und TD-DFT sowie CC2 für angeregte Zustände
• zahlreiche Eigenschaften
• NMR-shifts
• Solvatationsmodell COSMO
• direkte ab-initio-Dynamik (freie Dynamik und Simulated Annealing)
• spezielle Turbomole-Basissätze (SV(P), TZVPP, . . . ) sowie Dunnings korrelationskonsistente
Basen (cc-pVnZ und aug-pVnZ)
• Stuttgart-ECPs
• distributed-memory-Parallelisierung der wichtigsten Methoden bzw. Programmteile

Prof. Dr. Bernd Hartke, Universität Kiel, hartke@phc.uni-kiel.de
Input-Vorbereitung
Turbomole-Besonderheiten:
• besteht aus mehreren, separaten Programmen: dscf, ridft, mpgrad, . . .
• alle Programme werden über ein gemeinsames file ” control“ gesteuert
• textmenü-basiertes Interface ” define“ kann verwendet werden,
– um den ersten input aufzusetzen, inkl. Moleküldefinition usw.,
– aber auch zur Modifikation des control-files zwischen aufeinander folgenden
Läufen, z.B. zwischen dscf und ricc2.
• Vorsicht:
– per define werden auch Anfangs-MOs (initial guess) für HF bzw. DFT generiert
(defaultmäßig durch eine EHT-Rechnung).
– im control-file können auch andere Informationen auftauchen, z.B. die Hesse-
Matrix nach einem Lauf von aoforce, und an andere Programme weitergegeben
werden.
Empfohlener Umgang mit define:
• XYZ-file mit Molekülkoordinaten erzeugen (egal wie) (interaktive Erzeugung der
Koordinaten innerhalb von define ist möglich, aber umständlich)
• mit Zusatzprogramm x2t ins Turbomole-Format konvertieren und im von Turbomole
erwarteten file ” coord“ ablegen:
x2t > coord
• define aufrufen und ” coord“-file einlesen sowie die weiteren define-Menüs bearbeiten
– entweder interaktiv,
– oder (für wiederholte Produktionsläufe und/oder in shell/PBS-scripts) den von
define erwarteten input (inklusive Leerzeilen!) in ein file schreiben (z.B.
define.in) und define nicht-interaktiv laufen lassen:
define < define.in
Visualisierung von Resultaten:
Kein eigenes graphisches backend vorhanden. An einigen Stellen output für Molden oder
gOpenMol generierbar, z.B.:
• Zusatzprogramm tm2molden (Manual 1.5, S. 19) kann Geometrie- und MO-Daten
in ein Molden-input-file ausgeben
• keyword $pointval kann u.a. MO-Daten für gOpenMol generieren (Manual 12.2.15,
S. 202; siehe auch die ausführliche Beschreibung in Kapitel 10, S. 139–141).

Prof. Dr. Bernd Hartke, Universität Kiel, hartke@phc.uni-kiel.de
Turbomole-jobs auf dirac:
define braucht keine signifikanten Ressourcen ⇒ kann interaktiv auf dem master-Knoten
laufen. (Alternative: ” define < define.in“ in ein script aufnehmen.) Wie bei Gaussian und
Molpro: Start-Skript ” turbo_script“ sucht automatisch nach einem freien scratch-directory.
Aus diversen technischen Gründen funktioniert ” turbo_script“ ansonsten etwas anders
als bei Gaussian und Molpro. Wichtigste Unterschiede aus Benutzersicht:
• Der komplette Inhalt des aktuellen directories wird in das zugewiesene scratchdirectory
kopiert und der job läuft dann in diesem Knoten-lokalen scratch-directory.
Daher:
– Im aktuellen directory sieht man keine Veränderungen, während der job läuft.
– Nach Beendigung (oder Absturz) erscheint ein neues Unterverzeichnis ” RESULTS“,
in das alle möglicherweise relevanten output-files aus dem scratch-directory
kopiert werden. Wichtig: Der Benutzer muß selber dafür sorgen, daß es dieses
Unterverzeichnis vorher noch nicht gibt, sonst können alte oder neue Resultate
verloren gehen.
• Man braucht nicht nur ein, sondern zwei scripts, um einen turbomole-job auf dirac
abzuschicken (die Namen der Skripte sind beliebig; hier heißen sie script1 und
script2):
script1: wechselt vom home-directory ins gewünschte directory und ruft dann das ” turbo
script“ mit script2 als Argument, also:
cd irgendein_verzeichnis
turbo_script script2
script2: enthält die eigentlichen turbomole-Anweisungen, eine oder auch mehrere, inklusive
Optionen und ggf. Ausgabeumleitung (wer will, kann hier sogar shell-Befehle
mit aufnehmen).
Ein einfachstes Beispiel wäre also:
dscf
Ein komplizierteres:
define < define.in > define.out
ridft > ridft.out
aoforce > aoforce.out
define < define2.in > define2.out
jobex -c 250 -statpt -level cc2 > jobex.out

Prof. Dr. Bernd Hartke, Universität Kiel, hartke@phc.uni-kiel.de
Zusätzliches Problem: An mehreren Stellen im control-file können scratch-files für verschiedene
Programm-Module mit verschiedener keyword-Syntax vereinbart sein:
• dscf und ridft: twoint-file mit $scfintunit, Manual S. 161–162;
und weitere scratch-files mit $scratch files, Manual S. 164
• mpgrad und rimp2: $mointunit, Manual S. 181
• ricc2: $TMPDIR, Manual S. 182
• relax: $scratch files, Manual S. 194
• mpshift: $scratch files, Manual S. 206–207
Ein spezielles, selbstgeschriebenes Filter-script ” mod_control.pl“ versucht, in beliebigen
control-files alle diese Angaben automatisch um einen vorgegebenen scratch-directory-Pfad
zu ergänzen. Syntax:
mod_control.pl /scratch/dir/path/ < control_in > control_out
Dieses script wird automatisch vom script turbo_script ausgeführt, vor dem eigentlichen
Aufruf des Turbomole-Programm-Moduls. In Zweifelsfällen kann man aber mod_control.pl
auch interaktiv mit obiger Syntax aufrufen, um zu überprüfen, ob das erzeugte, modifizierte
control-file tatsächlich korrekt ist.
Paralleljobs:
• distributed memory (PVM, MPI) ⇒ keine maschinen-technischen Beschränkungen
wie bei SMP-Gaussian
• Programmablauf auf Effizienz der vorhandenen Kommunikations-hardware abstimmbar
(Manual Kapitel 12.2.18, S. 207–210)
• Parallelläufe auch auf über das Institut oder den Campus verteilten, Ethernetvernetzten
PCs denkbar
• parallelisierte Programm-Module: dscf, grad, ridft, rdgrad, mpgrad, ricc2
• Parallelversion auf dirac z.Z. noch nicht implementiert
• am HLRN möglich (siehe dortige online-Dokumentation)

Prof. Dr. Bernd Hartke, Universität Kiel, hartke@phc.uni-kiel.de
Abläufe einiger Standard-Rechnungen in Turbomole:
HF- oder DFT-Rechnungen:
Grundablauf:
1. Vorbereitung mit define:
2. dann
• Geometrie (s.o.)
• Basis (SV(P) ist voreingestellt und gut genug für erste Tests)
• eht-initial-guess (in einfachen closed-shell-Fällen keine Änderungen nötig)
• für HF-SCF: nichts weiter nötig (defaults in der Regel o.k.)
für DFT: im Untereintrag dft des letzten Menüs DFT einschalten (und ggf.
anderes Funktional als BP86 wählen)
• entweder single-point-Rechnung mit dscf
(ggf. gefolgt von einer Frequenzanalyse mit aoforce, NMR-shifts mit mpshift,
ricc2 oder Rechnungen für angeregte Zustände)
• oder Geometrieoptimierung mit jobex (ohne weitere Optionen)
RI-HF und -DFT-Rechnungen:
Unterschiede im Grundablauf zu normalem HF/DFT:
• im letzten define-Menü die rijk- bzw. ri-Option anwählen:
– memory auf sinnvollen Wert erhöhen
– Auxiliar-Basis wählen (in der Regel die, die für die normale Basis optimiert
wurde!)
– RI einschalten
Bei sehr großen Molekülen (empfohlen für ≥ 1000 Basisfunktionen) ggf. marij
dazuschalten (Multipolapproximation für Coulomb-Integrale).
• ridft statt dscf
• jobex mit Option -ri
Man kann erwarten, daß RI-Rechnungen ca. 10-mal schneller sind als konventionelle
Rechnungen, bei insignifikantem Verlust an Genauigkeit.

MP2-Rechnungen:
Grundablauf:
Prof. Dr. Bernd Hartke, Universität Kiel, hartke@phc.uni-kiel.de
1. mit define einen HF-SCF-Lauf vorbereiten
2. per Hand(!) die Option $denconv 1.e-7 im control-file hinzufügen
3. dscf-Lauf durchführen
4. mit Hilfsprogramm mpgrad das control-file auf den MP2-Lauf vorbereiten (define
kann das nicht!); mpgrad -h für eine Kurzbeschreibung eingeben; Beispiel:
mp2prep -e -m 500 -p 1000 /scratch1/hartke/bla
Dabei wählt -e eine Energie-Berechnung (-g liefert zusätzlich den Gradienten), das
memory wird auf 500 MB beschränkt und der Plattenplatz auf 1000 MB.
Achtung: scratch-directory-Angabe möglichst kurz halten, weil mp2prep die Zeilen
auf 80 Zeichen abschneidet, aber viel Leerraum einfügt; dummerweise kann es kein
Phantasiename sein, weil mp2prep prüft, ob das directory vorhanden ist (und es
ggf. anlegt).
Empfehlung: wie in obigem Beispiel. In einem batch-Lauf auf dirac wird das dann
von turbo_script ohnehin richtiggestellt.
5. den Eintrag $statistics off im control-file auf $statistics mpgrad ändern
6. mpgrad interaktiv und im Vordergrund laufen lassen (ohne queue); es ermittelt
dann nur die erforderlichen scratch-file-Größen und setzt das control-file wieder auf
$statistics off zurück
7. dann erst entweder
• eine single-point-Rechnung mit mpgrad starten
• oder eine Geometrieoptimierung mit jobex -level mp2

RI-MP2-Rechnungen:
Grundablauf:
Prof. Dr. Bernd Hartke, Universität Kiel, hartke@phc.uni-kiel.de
1. mit define einen HF-SCF-Lauf vorbereiten; gleichzeitig(!) kann man schon die für
RI-MP2 nötigen Optionen setzen: Untermenü mp2 im letzten define-Menü ist dafür
zuständig (nicht für konventionelles MP2!):
• freeze: core-Orbitale einfrieren (define bietet dafür vernünftige Vorschläge an)
• cbas: Auxiliar-Basen aussuchen (passend zur Hauptbasis!)
• memory: auf vernünftigen Wert setzen
2. per Hand(!) die Option $denconv 1.e-7 im control-file hinzufügen
3. dscf-Lauf durchführen
4. (wenn man nicht unter (1) schon die nötigen RI-MP2-Optionen gesetzt hat, kann
man das auch an dieser Stelle noch tun, mit rimp2prep oder mit define; ein
statistics-Lauf ist nicht nötig)
5. dann entweder
• eine single-point-Rechnung mit Modul rimp2 starten
• oder eine Geometrieoptimierung mit jobex -ri -level mp2
Wie bei HF/DFT beschleunigt die RI-Behandlung die Rechnung um ca. einen Faktor 10.
Gleichzeitig kann rimp2 die frozen-core-Näherung auch für den Gradienten, im Gegensatz
zu mpgrad.
⇒ Einzige Gründe, mit Turbomole mpgrad statt rimp2 zu verwenden: Keine passenden
Auxiliar-Basen vorhanden, oder Referenzrechnungen (z.B. Vergleich zu konventionellem
MP2 oder zu anderen Programmpaketen)
RI-CC2-Grundzustandsrechnungen:
Grundablauf wie bei RI-MP2; Unterschiede:
• Untermenü cc2 statt mp2 im letzten define-Menü anwählen
• dort neben freeze, cbas und memory auch setzen:
– tmpdir: beliebiger dummy-Eintrag, wird vom turbo_script korrigiert ($TMPDIR-
Zeile muß allerdings vorhanden sein!)
– ricc2: mindestens ” cc2“ (als ” wavefunction model“) wählen, bei Geometrieoptimierung
zusätzlich ” geoopt cc2“
• single-point-Rechnung mit ricc2
• Geometrieoptimierung mit jobex -level cc2

Prof. Dr. Bernd Hartke, Universität Kiel, hartke@phc.uni-kiel.de
Optimierung von Übergangszuständen:
1. Anfangsgeometrie erzeugen (raten, QST2 in Gaussian, Potentialflächen-scan entlang
interessanter Koordinaten, . . . )
2. ridft-Rechnung durchführen (s.o.)
3. aoforce-Rechnung anschließen (siehe Manual; einziger wichtiger Punkt: im controlfile
mit $maxcor-Option ausreichend memory zur Verfügung stellen)
4. resultierende Frequenzen überprüfen: genau eine imaginäre?!
Wenn nicht, zurück zu (1)
5. mit define die eigentliche Optimierung vorbereiten (für RI-DFT, RI-MP2 oder RI-
CC2, s.o.), dabei im letzten Menü das Untermenü stp anwählen und (wenigstens)
itvc auf 1 setzen (defaults der anderen Optionen ggf. ausreichend)
6. jobex starten mit Option -statpt (und ggf. weiteren Optionen, je nach Theorie-level)
7. auch bei Konvergenz im output statpt.out auf Warnhinweise achten, daß mehr
als eine imaginäre Frequenz vorliegt
8. für resultierende Geometrie Frequenzrechnung (1-3) wiederholen.
angeregte Zustände:
mit escf, egrad, ricc2: siehe Manual. . .
Eigenschaften, NMR-shifts,. . . :
siehe Manual. . .

Praxistips:
Prof. Dr. Bernd Hartke, Universität Kiel, hartke@phc.uni-kiel.de
• Meldungen wie ” dscf ended normally“ landen verwirrenderweise im qsub-Error-output.
• immer redundante interne Koordinaten definieren! (ired im Geometrie-Menü von
define), sonst bekommt man kartesische und die sind ineffizient in Geometrieoptimierungen.
• ggf. muß im control-file etwas ” per Hand“ ergänzt werden; z.B.: ich weiß nicht,
wo man im define das keyword $denconv setzen kann; $denconv 1.e-7 ist aber
(manchmal?) nötig für mp2 und ricc2!
• aus dem Manual wird nicht ganz genau klar, wann bei Optimierungen relax und
wann statpt einzusetzen ist (mit den entsprechenden flags beim jobex-script). Für
Minimierungen ist relax gut geeignet, während Optimierungen zu Sattelpunkten
(mit den im Skript beschriebenen Vorsichtsmaßnahmen) anscheinend nur für statpt
funktionieren.
• Einzelprogramme mit Option ” -h“ starten → Kurzerläuterungen, die aber teilweise
mehr/aktuellere Informationen enthalten als das Manual; z.B. verrät jobex -h, daß
es eine Option -inihs gibt, mit der man es sich angeblich ersparen kann, bei
vor statpt-Sattelpunkt-Optimierung einen aoforce-Lauf per Hand zu starten (diese
Option fehlt im Manual). Dies scheint aber nicht wirklich zu funktionieren. . .
• es gibt einige kleine Zusatzprogramme zu Turbomole, s. Manual Kapitel 1.5, S. 17–19;
von Ermittlung einfacher Geometrieparameter bis zur Berechnung thermodynamischer
Daten
• wenn define zwischen einzelnen Modulen zur Modifikation des control-files verwendet
wird, wird empfohlen, das zu ändernde control-file vorher umzubenennen (oder
dem neuen einen anderen Namen zu geben)
• obwohl RI-HF möglich ist, ist RI-DFT mit Hybrid-Funktionalen, die HF-exchange-
Terme enthalten, anscheinend nicht möglich

Fallstudie:
Prof. Dr. Bernd Hartke, Universität Kiel, hartke@phc.uni-kiel.de
Ethylformiat-Pyrolyse: Ameisensäureethylester → Ameisensäure + Ethen
↓
↓