Benutzung von ABAQUS im RRZN und HLRN

Hier finden Sie Hinweise zur Nutzung von ABAQUS im RRZN und HLRN.

Es werden die folgenden Themen behandelt:

Benutzung von ABAQUS im RRZN und HLRN

Plattformen im RRZN

Verfügbare Plattformen und Versionen der Compute-Server im RRZN Plattformen.

Alle ABAQUS-Produkte sind auf dem Linux-Cluster ausführbar. Auf diesem System ist ABAQUS insbesondere für große FE-Modelle im Parallelbetrieb einsetzbar. Die Compute-Server führen die FE-Analyse im Batchbetrieb mittels PBS-Skript durch. Die gegenwärtig verfügbaren Versionen sind 6.9-2, 6.9-3, 6.10-2, 6.10-3, 6.11-1, 6.11-3 und 6.12-1.

Der Einsatz von ABAQUS auf dem Linux-Cluster wird im Kapitel Nutzung von ABAQUS auf dem RRZN-Cluster beschrieben.

HLRN-II-Parallelrechnersystem (MPP SGI ICE8200-Plus + SMP Server Altix XE250)

Im HLRN (Hochleistungsrechnen Nord - ein Norddeutscher Verbund für Hoch- und Höchstleistungsrechnen) ist ABAQUS auf den Parallerechnersystemen ICE und XE von SGI verfügbar. Das HLRN-II-Rechnersystem im RRZN ist ein MPP-System (1280 Knoten je 8 Prozessor-Cores, 16/32 GB Hauptspeicher) und ein SMP-System (47 Knoten je 8 Prozessor-Cores, 64 GB Hauptspeicher) mit 10616 Prozessoren. Ein identisches System steht noch einmal im HLRN/ZIB in Berlin. Alle ABAQUS-Produkte sind auf dem HLRN-System ausführbar. Auf dem HLRN-System ist ABAQUS insbesondere für sehr große FE-Modelle nur im Parallelbetrieb einsetzbar. Die Login-Knoten des HLRN-Systems dienen als Dialogrechner für das Pre- und Postprocessing während die Compute-Nodes des HLRN-Systems als Compute-Server die FE-Analyse im Batchbetrieb durchführen. Die gegenwärtig verfügbare Version ist 6.10-1.

Die Zulassung für dieses Höchstleistungsrechnersystem erfolgt mittels eines Projektantrages, der von einen Wissenschaftlichen Ausschuss begutachtet und gegebenfalls bewilligt wird. Voraussetzung sind sehr hohe Rechenzeitanforderungen.

Der Einsatz von ABAQUS auf dem HLRN-System wird im Kapitel Nutzung von ABAQUS auf dem HLRN-Rechner beschrieben. Weitere Hinweise finden Sie unter ABAQUS im HLRN auf den WEB-Seiten im HLRN.

Nutzungsbedingungen

Die Nutzung von ABAQUS im RRZN und HLRN ist streng begrenzt auf die Lehre und akademische Forschung für nur nichtindustriell finanzierte Projekte.

Aufruf von ABAQUS

Compute-Server im RRZN

Als Batchsystem wird auf dem RRZN-Cluster Torque verwendet. Der Aufruf des ABAQUS-Skript-Kommandos muss in eine Skriptdatei integriert werden. Details zur Skriptdatei findet man im Abschnitt PBS-Skripte. Die Initialisierung erfolgt in der Module-Technik wie folgt:

module avail (zeigt alle verfügbaren Module-Files an)

module load abaqus (für die Standard-Version). zurzeit 6.12-1

module load abaqus/6121 (für die Version 6.12). Release 6.12-1

module load abaqus/6113 (für die Version 6.11). Release 6.11-3

module load abaqus/6111 (für die Version 6.11). Release 6.11-1

module load abaqus/6103 (für die Version 6.10). Release 6.10-3

module load abaqus/6102 (für die Version 6.10). Release 6.10-2

module load abaqus/693 (für die Version 6.9). Release 6.9-3

module load abaqus/692 (für die Version 6.9). Release 6.9-2

Skript-Aufruf für die Srtandard-Version: abaqus job= ..........

Skript Aufruf für Versionen 6.9-3: abq693 job= ........

MPP- und SMP-System im HLRN-II

Da als Batchsystem Torque zur Verfügung steht, muss ein PBS-Skript vorbereitet werden. Details zur Skriptdatei findet man im Abschnitt PBS-Skript. Die Initialisierung erfolgt in der Module-Technik wie folgt:

module avail (zeigt alle verfügbaren Module-Files an)

module load abaqus (für die Standard-Version) zurzeit 6.10-1

module load abaqus/681 (für die Version 6.8-1)

ABAQUS-Skript-Parameter

ABAQUS wird gestartet, indem der Benutzer nach der Initialisierung von ABAQUS ( init_abaqus bzw. module load abaqus) die Ausführungsprozedur abaqus exekutiert. Diese sucht und wertet bis zu drei Environment-Files (ABAQUS Systeminstallationsverzeichnis, $HOME und $WORK des Benutzers) aus, in denen die Systemparameter gesetzt werden. Die ABAQUS-Ausführungsprozedur generiert das Skript job-name.com für den Python-Interpreter, der die einzelnen Schritte des ABAQUS-Jobs initiiert und ausführt. In diesem Abschnitt werden die wichtigsten Prozedurparameter beschrieben. Eine ausführliche Beschreibung der Prozedurparameter finden Sie im Analysis User's Manual, Volume I, Kapitel 3.2.2. Nur die für eine ABAQUS-Analyse relevanten Parameter müssen spezifiziert werden. Die jeweilige Skriptdatei initiiert die Batchanalyse auf den verschiedenen Systemen.

Für die Parallelausführung von ABAQUS sind die Parameter cpus, parallel, domains, mp_mode und standard_parallel relevant. Weitere Details zum Verständnis der Parallelausführung in ABAQUS/Standard und ABAQUS/Explicit finden Sie in der Online-Dokumentation im ABAQUS Analysis User's Manual im Kapitel 11.9.

Zusammenfassung der Kommandoparameter

abaqus

job=

job-name

[analysis | datacheck | parametercheck | syntaxcheck | continue |
convert={

} | rocover |

information={

}]
[input=

input-file

]
[user={

source-file

object-file

}]
[oldjob=

oldjob-name

] [fil={

}]
[globalmodel=

results file-name

output database file-name

]
[cpus=

number-of-cpus

]
[parallel={

}]
[domains=

number-of-domains

]
[mp_mode={

}]

[standard_parallel={

}]
[memory=

memory-size

]
[interactive | background | queue=[

queue-name

] [after=

time

]]
[double] [scratch=

scratch-dir

]
[output_precision={

}] [convert_sdi={

}]

[active_topology

Parameterbeschreibung:

job

Kombination beliebiger alphanumerischer Zeichen. Jobs, die gleichzeitig im selben Verzeichnis rechnen, müssen unterschiedliche Job-Identifikationen haben. Alle Dateien, die durch ABAQUS erzeugt werden, enthalten in der Namensgebung diesen Job-Identifier gefolgt durch eine Namenserweiterung .ext. (Erläuterung hierzu siehe Konventionen der Datenamen).

analysis

Durchführung einer vollständigen ABAQUS-Analyse (oder einer Restart-Analyse).

datacheck

Es wird nur ein Datacheck-Lauf durchgeführt. Alle Dateien zur Fortsetzung einer ABAQUS-Analyse (mit der Option continue) werden abgespeichert.

parametercheck

Parameterprüfung (*PARAMETER Option) bei parametrischen Studien mit ABAQUS/Design. Es wird keine Analyse oder Datacheck durchgeführt.

continue

Fortsetzung der ABAQUS-Analyse nach einem Datacheck-Lauf.

syntaxcheck

Syntaxprüfung der Eingabedatei. Diese Option benötigt keine Netzwerklizenz. Keine Analyse wird durchgeführt und die Option continue kann nicht zur Fortsetzung einer Analyse verwendet werden. Nur die .dat und .odb Dateien werden generiert.

information

Hilfreiche Informationen über die Installation und die Anwendung von ABAQUS. Standardmäßig wird die Information auf den Bildschirm ausgegeben. Bei Angabe des job-Parameters läuft der Job im Background und die Ausgabe des Textes erfolgt in die Datei

information=environment

abaqus_v6.env

information=local

information=memory

abaqus_v6.env

große FE-Modelle

information=release

Release Notes

information=support

Informationen zur Diagnoseunterstützung für den ABAQUS-Support.

information=system

information=all

input

Dateiname mit den Eingabedaten für ABAQUS. Ohne diese Option wird nach einer Datei job-name.inp im aktuellen Arbeitsverzeichnis gesucht.

user

Option zur Spezifikation einer FORTRAN-Quellcodedatei oder einer Objektcodedatei, die alle User Subroutinen für die Analyse enthält. Diese Datei job-name.f wird kompiliert und in das ABAQUS-Executable eingebunden oder die Datei job-name.o wird in das ABAQUS-Executable eingebunden. Bei häufiger Verwendung der User Subroutine kann mittels abaqus make eine Shared Library generiert werden; diese wird dann mit der Environment-Variable usub_lib_dir definiert und die user-Option ist nicht mehr erforderlich.

oldjob

Diese Option spezifiziert den Job-Identifier eines vorhergehenden Jobs (ohne File-Extension), mit Hilfe derer ein Restart-Job gestartet werden kann. Diese Option wird verlangt, falls die *RESTART, *POST OUTPUT, *SYMMETRIC MODEL GENERATION oder *IMPORT Option in der Eingabedatei (.inp) spezifiziert worden ist. Diese Optionen bewirken das Lesen der Restart- (.res) und/oder Result-Datei (.fil). Der oldjob-Identifier muss unterschiedlich zum aktuellen Job-Identifier sein.

fil

Option ausschließlich für Restart-Jobs. Die Angabe bewirkt, ob ein existierendes Result File ("oldjob-Identifier.fil") in einem Restart-Job erweitert werden soll oder ob ein neues Result File (fil=new) erzeugt werden soll. Für ABAQUS/Explicit ist fil=new nicht erlaubt. Spezifikation ist nur erforderlich bei einer *RESTART,READ-Analyse zur Erweiterung eines alten Result File bzw. zur Erzeugung einer neuen Ergebnisdatei.

cpus

Diese Option spezifiziert die Anzahl der Prozessoren, die während der Jobabarbeitung verwendet werden sollen, wenn Parallelverarbeitung spezifiziert worden ist. Die maximale Anzahl von Prozessoren beträgt für ABAQUS gegenwärtig 16 (auf dem HLRN-Rechner 32).

parallel

Parameter zur Spezifikation der Methode für die Parallelverarbeitung in ABAQUS/Explicit. Für ABAQUS/Explicit sind die Werte domain und loop anwendbar. Es ist eine Thread-basierte und MPI-basierte Methode implementiert. Auf Shared-Memory-Rechnern ist nur die Loop-Level-Implementierung verfügbar. Die parallele Implementierung der Gebietszerlegung ist sowohl auf Shared-Memory als auch auf Rechner-Cluster verfügbar.

parallel=domain

parallel=loop

domains

Spezifikation der Anzahl paralleler Domains in ABAQUS/Explicit. Ist der Wert größer als 1 wird die Gebietszerlegung durchgeführt ohne Rücksicht auf die Werte von parallel und cpus. Bei Angabe von parallel=domain muss die Anzahl der domains gleichmäßig auf die Anzahl der cpus verteilt werden. Es ist sowohl die Tread-basierte Methode als auch die MPI-basierte Methode für die Gebietszerlegung implementiert.

mp_mode

Bei mp_mode=mpi wird die MPI-basierte Parallelisierungsmethode verwendet, falls diese anwendbar ist. Wenn mp_mode=threads gesetzt wird, wird die Thread-basierte Parallelisierungsmethode angewendet. Standard ist mpi auf allen Plattformen außer Windows. Der iterative Gleichungslöser (*STEP,SOLVER=DDM) erzeugt automatisch eine Gebietszerlegung und unterstützt sowohl die MPI-basierte als auch die Thread-basierte Parallelisierung. Der direkte Gleichungslöser und der Lanczos-Solver nutzen nur die Thread-basierte Parallelisierung und laufen daher nur auf Shared-Memory-Rechnern.

standard_parallel

Diese Option spezifiziert die parallele Ausführungsweise in ABAQUS/Standard. Die möglichen Werte sind all und solver. Bei standard_parallel=all werden sowohl die Elementoperationen als auch der Solver parallel ausgeführt. Wenn standard_parallel=solver gesetzt ist, wird nur der Solver parallel ausgeführt. Der Standard ist standard_parallel=all auf allen Plattformen, wo die MPI-basierte Parallelisierung unterstützt wird. Die Parallelausführung der Elementoperationen wird nur von der MPI-basierten Methode unterstützt.

memory

Option zur Spezifikation des Memorybedarfs für den Input-Prozessor ABAQUS/Pre. Der Standard für diesen Parameter kann auch mit dem pre_memory-Parameter in der Environment-Datei gesetzt werden.

interactive

Diese Option startet einen Job, der interaktiv abläuft. Für ABAQUS/Standard wird die Log-Datei auf dem Bildschirm ausgegeben; für ABAQUS/Explicit werden die Status- und Log-Datei auf dem Bildschirm ausgegeben. Diese Anwendung ist nur für sehr kleine Testbeispiele sinnvoll anwendbar. Ungeignet für Analysen im Parallel-Mode, d. h. cpus muss immer auf 1 gesetzt werden.

background

Diese Option erlaubt die Analyse von kleinen FE-Modellen im Background. Ungeeignet für Analysen im Parallel-Mode, d. h. cpus muss immer auf 1 gesetzt werden.

queue

Diese Option wird zurzeit im RRZN und HLRN nicht mehr unterstützt.

Hinweise zum Einsatz von ABAQUS auf dem HLRN-System finden Sie im Kapitel Nutzung von ABAQUS auf dem HLRN-Rechner und unter ABAQUS im HLRN auf den Web-Seiten im HLRN.

double

Diese Option ist nur für ABAQUS/Explicit verfügbar; sie bewirkt, dass bei Verwendung einer expliziten dynamischen Prozedur die Analyse mit doppelter Genauigkeit (64-Bit) ausgeführt wird und zwar auf Systemen, wo die Standardlänge eines Gleitkommawortes in einfacher Genauigkeit 32-Bit beträgt. Mit Hilfe des ABAQUS-Environment- Parameters explicit_precision=DOUBLE_PRECISION kann die Ausführung in doppelter Genauigkeit ebenfalls aktiviert werden. Standardwert von explicit_precision ist SINGLE_PRECISON.

ABAQUS-Environment-File

Die ABAQUS-Prozedur verarbeitet aus einer System-Environment-Datei vordefinierte Systemparameter, die verschiedene Aspekte bei der Ausführung eines ABAQUS-Jobs steuern. Die Konfiguration der Environment-Definitionen kann vom Benutzer selbst beeinflusst werden, um somit die modellabhängige Leistungsverbesserung während der ABAQUS-Analyse abzustimmen. Drei Verzeichnisse werden nach der Environment-Datei abaqus_v6.env in folgender Reihenfolge durchsucht:

ABAQUS-Installationsverzeichnis: hier befindet sich das Standard-Environment-File mit den Host-Level-Defintionen für das spezifizierte Rechnersystem.
$HOME-Verzeichnis des Benutzers: diese Environment-Datei ist optional und überschreibt die Systemdefinitionen der Standard-Environment-Datei (User-Level-Einvironment-Definitionen).
aktuelles Arbeitsverzeichnis ($WORK): diese Environment-Datei ist ebenfalls optional und überschreibt gegebenenfalls Definitionen der beiden vorhergehenden Dateien (Job-Level-Environment-Definitionen).

Einträge im Environment-File werden stets in der Form parameter=wert vorgenommen. Kommentare werden durch das Nummernzeichen (#) eingeleitet, d.h. alle Zeichen, die einem Nummernzeichen (#) folgen, werden ignoriert. wert darf also nicht das Nummernzeichen enthalten. Leerzeilen werden ebenfalls ignoriert. Die Environment-Datei verwendet die Syntax der Programmiersprache Python; der Name der Environment-Datei lautet: abaqus_v6.env.

Beispiel einer Benutzer-Environment-Datei:

# 
#         USER ABAQUS ENVIRONMENT FILE: Version 6.7-4
#
# Memory-Anforderung für ein FE-Modell mit 800 MByte
#
# pre_memory = "400 mb" 
# standard_memory = "800 mb" 
# explicit_precision = SINGLE_PRECISION  
#

Ab Version 6.8-1 erfolgt die Allokierung des Memory automatisch; eine Anforderung per Environment-Variable ist nicht mehr erforderlich. Die Variable standard_memory wird in Vers. 6.8-1 nicht mehr unterstützt. Die Variable lautet hier nur noch memory.

Die Ausgabe der vordefinierten Parameter der Standard-Environment-Datei erfolgt mit Hilfe des folgenden Aufrufes des ABAQUS-Skriptes:

abaqus information=environment

(siehe Analysis User's Manual, Volume I, Kap. 3.3.1 ff.)

Laufzeitverhalten großer FE-Modelle: Memory- und I/O-Probleme

Dieser Abschnitt gilt nur für ABAQUS Release 6.7-4 und niedriger. Für Release ab 6.8-1 wird der Memory-Bedarf automatisch angepasst, die Umgebungsvariable standard_memory wird hier nicht mehr unterstützt.

Standardmäßig wird ein ABAQUS-Job mit maximal 600 MByte Speicherbedarf ausgeführt. Wenn jedoch ein zu großes FE-Modell mit nur dieser Speicheranforderung läuft, wird ABAQUS mit diesem Speichermangel so umgehen, dass intensive I/O-Aktivitäten im Scratch-Verzeichnis erfolgen. Dies ist sehr ineffektiv und zur Verbesserung dieser Situation müssen so viele Daten wie möglich im Speicher gehalten werden. Eine wesentliche Verbesserung des Laufzeitverhaltens kann man erreichen, indem man bestimmte Systemparameter im Environment-File neu spezifiziert und mit höheren Werten vorbesetzt. Die folgenden Abschnitte beschreiben diese Änderung im Detail. (siehe auch ABAQUS/Standard User's Manual, Volume I, Kapitel 3.4.1)

Solver für Standard und Explicit

Der Parameter standard_memory definiert den maximalen Speicher, der benutzt werden kann. Den aktuellen Speicher, den ein Job benötigt, wird durch den Label MEMORY AND DISK ESTIMATE in der Datei job-name.dat am Ende der Ausgabe des Input Processing angezeigt. Dieser Schätzwert für die Memory-Anforderung eines FE-Modells wird auch in einer Datacheck-Analyse berechnet. In der Schätzung werden zwei Werte angegeben, die für standard_memory relevant sind. Der erste Wert unter dem Label MINIMUM MEMORY REQUIRED spezifiziert den Wert für standard_memory, wobei nur die kritischen Scratch-Daten im Memory gehalten werden. Ein ABAQUS-Job muss mindestens diese Memory-Anforderung erfüllen, sonst erfolgt ein Jobabbruch. Ein zweiter relevanter Wert in der Schätzung wird unter dem Label MEMORY TO MINIMIZE I/O aufgelistet. Dieser Wert für standard_memory stellt sicher, dass alle Scratch-Daten, sowohl kritische als auch generische, im Memory gehalten werden können. In jedem Fall sollte der Wert von standard_memory in der Environment-Datei mindestens auf diesen errechneten Schätzwert für die I/O-Minimisierung gesetzt werden.

Ein ABAQUS-Batch-Job benötigt somit folgenden Speicherbedarf in MBytes:

standard_memory = MEMORY TO MINIMIZE I/O + Memory des Executable

D.h. zum Beispiel: Für ein FE-Modell ergibt eine Datacheck-Analyse einen Speicherbedarf für "Memory to Minimize I/O" von 750 MByte. Der Speicherbedarf für ein ABAQUS-Executable erfordert ca. 200 Mbyte. Daraus ergibt sich ein Mindestwert für den Speicherbedarf für dieses Beispiel von standard_memory = "950 mb".

Der Standardwert im Environment-File für standard_memory ist wie folgt vorbesetzt:

standard_memory = "600 mb"

Siehe dazu auch die folgende Informationsdatei, die mit dem nachfolgenden Kommando generiert wird:

abaqus information=memory

Input Processing: Pre-Phase

Der relevante Parameter für diesen Verarbeitungsschritt lautet pre_memory. Der maximale Speicherbedarf, den der Pre-Prozessorprozess benötigt, ergibt sich aus der Größe eines FE-Modells.

Der Standardwert für pre_memory ist wie folgt vorbelegt:

pre_memory = "600 mb"

Dieser Wert ist für die meisten FE-Probleme ausreichend. Richtwerte für sehr große FE-Modelle siehe Tabelle 3.4.1-1 im Analysis User's Manual, Volume I.

ABAQUS/CAE und ABAQUS/Viewer

ABAQUS/CAE

ABAQUS/CAE (Complete ABAQUS Environment) ist eine interaktive Umgebung zum Erzeugen, Starten, Überwachen und zur Ergebnisauswertung von ABAQUS-Simulationen. ABAQUS/CAE ist in verschiedene Module unterteilt, wobei jedes Modul einen logischen Aspekt des Modellierungsprozesses definiert; z. B., Definition der Geometrie, Definition der Materialeigenschaften, Netzgenerierung, Starten von Analyse-Jobs und Interpretation von Ergebnissen. Im Produkt ABAQUS/CAE ist das Produkt ABAQUS/Viewer integriert.

Beispiel: Aufruf

abaqus cae [database=database-file][replay=job-name.rpy]
[recover=job-name.jnl]

Beschreibung der Skript-Parameter

database

Diese Option spezifiziert die Modell-Database-Datei (job-name.cae) oder die Output-Database- Datei (job-name.odb).

replay

Der Name einer Datei, von der Eingabekommandos für CAE eingelesen werden können. Die Dateiextension lautet: .rpy

recover

Diese Option spezifiziert eine Datei, von der die Modell-Database-Datei wiederhergestellt werden kann. Das Journal-File hat die Dateiextension .jnl.

Job Manager

Dieses Module ermöglicht neben dem Start eines Interaktiven Jobs, auch die Erstellung einer Input-Datei. Im Module Job Manger wird mit "Write Input" eine Input-Datei geschrieben, ohne Start der Analyse. Die Input-Datei mit der Dateiextension .inp, kann für die Analyse im Batchbetrieb verwendet werden.

ABAQUS/Viewer

Interaktiver Postprozessor mit einer intuitiven grafischen Benutzerschnittstelle zur Darstellung von FE-Ergebnissen nach einer ABAQUS-Analyse. ABAQUS/Viewer verwendet die Output-Database-Datei (job-name.odb), in der die Ergebnisse der Analyse-Module enthalten sind. Die .odb-Datei ist in einem neutralen Binärdateiformat erzeugt, daher können die Ergebnisse einer ABAQUS-Analyse auf jeder Plattform, auf der ABAQUS/Viewer installiert ist, verarbeitet werden. Abaqus/Viewer ist eine Teilmenge von Abaqus/CAE, die nur das Visualisierungs-Modul enthält

Beispiel: Aufruf

abaqus viewer [database=job-name.odb] [replay=job-name.rpy]

Beschreibung der Skript-Parameter

database

Der Name der Output-Database-Datei (job-name.odb)

replay

Der Name einer Datei, von der Eingabekommandos für CAE eingelesen werden können. Die Dateiextension lautet: .rpy

Installationshinweis für ABAQUS/CAE bzw. ABAQUS/Viewer

a) Installation auf einem Unix-Rechner bei Zugriff vom PC unter Windows:

Die interaktiven Programme ABAQUS/Viewer und ABAQUS/CAE verwenden die Grafik-Bibliothek OpenGL. Falls die grafische Leistung von OpenGL wegen des X-Servers X-Win32 nicht vollständig unterstützt wird, müssen Sie gegebenenfalls auf X11 umschalten.

Umschalten von OpenGL auf X11 ist wie folgt möglich:

Im Hauptmenue View auswählen und dort Graphics Option anklicken. In der dann dargestellten Dialogbox den Driver X11 aktivieren. Diese grafischen Parameter erlauben das Arbeiten mit dem gegenwärtigen Release von X-Win32. Eine gute Alternative ist die kostenlose NX Client Software.

b) Zugriff auf CAE oder Viewer vom PC unter Linux:

Ebenfalls problemlos laufen Viewer und CAE unter Linux bei folgender Hardware:

Linux Version: Suse 7.2 oder höher

X-Server: Xfree 4, (3D anschalten)

Abhängig von der Grafikkarte müssen die neuesten Grafiktreiber verwendet werden, z.B., bei Grafikkarten von Nvidia müssen die Treiber von der Nvidia-Homepage geholt werden.

Beispiele für ABAQUS-Aufrufe

ABAQUS/Standard

Die Beispiele (c1,c4,c5) können wie folgt aus der Archivierungsdatei extrahiert werden:

module load abaqus

abaqus fetch job=c1
abaqus fetch job=c4
abaqus fetch job=c5

Es folgen einige Aufrufbeispiele des ABAQUS-Skriptes:

ABAQUS-Aufruf mit Erzeugung einer fil- und odb-Datei (c1.fil, c1.odb) und Ablauf im Background:
abaqus job=c1 analysis background
ABAQUS-Aufruf einer nichtlinearen dynamischen Analyse mit Erzeugung einer Restart-Datei (c4.res) und einer fil-Datei (c4.fil):

abaqus job=c4 analysis background
Fortsetzung der Analyse von Beispiel c4 mit Erzeugung einer neuen Restart-Datei (c5.res) und einer erweiterten fil-Datei (c5.fil) und Ablauf im Background:

abaqus job=c5 analysis oldjob=c4 fil=append background

Beschreibung der Beispiele c1,c4 und c5

c1 is a small displacement structural analysis. For this case ABAQUS will create an output listing (c1.dat), a file output file (c1.fil) and the status, message and log files.

This is a nonlinear dynamic analysis of an extended version of the model c1. The job will create an ouput listing (c4.dat), a file output file (c4.fil) and a restart file (c4.res). The job ends because the *STEP option does not provide enough increments to complete the simulation time requested. c5 is a restart job to finish the required simulation time.

This job continues the analysis of example c4. The job needs the file output file (c4.fil) and the restart file (c4.res) from c4. It will create an output listing (c5.dat), a new restart file (c5.res) and a file output file (c5.fil) which includes the results from both the c4 and c5 run.

ABAQUS/Explicit

Das Beispiel beam1 kann wie folgt aus einer Archivierungsdatei extrahiert werden:

module load abaqus

abaqus fetch job=beam1

Es folgen einige Aufrufbeispiele des ABAQUS-Skriptes:

ABAQUS/Explicit-Analyse mit Konvertierung aller relevanten Dateien (State-, Package- und selected Results-Datei):
abaqus job=beam1 analysis convert=all background
ABAQUS/Explicit-Analyse ohne Konvertierung aller relevanten Dateien jedoch Analyse mit doppelter Genauigkeit:
abaqus job=beam1 analysis double background
Konvertierung der ABAQUS/Explicit selected Results-Datei nach einer wie im Beispiel zuvor bereits durchgeführten Analyse im Background:
abaqus job=beam1 convert=select background

Weitere Beispiele zur Verwendung des abaqus-Kommandos siehe auch Analysis User's Manual, Volume I, Kapitel 3.1.1.

Konventionen der ABAQUS-Dateinamen

Das abaqus-Skript generiert verschieden Dateien. Einige existieren nur während der ABAQUS- Analyse und werden nach Beendigung eines Laufes gelöscht. Andere Dateien enthalten Analyse-, Postprocessing- und Translationsergebnisse und bleiben für die Anwendung anderer Analyseoptionen (z. B. Restart, Postprocessing) erhalten. Dieses Kapitel beschreibt die Dateien, die durch ABAQUS generiert werden.
Jeder der folgenden Namen enthält vorangestellt den Namen des Job-Identifier job=job-name und eine Namenserweiterung (.ext), die von ABAQUS vergeben wird: job-name.ext

ABAQUS-Skript:

Name         Beschreibung

.com         Kommandodatei

ABAQUS/Standard und ABAQUS/Explicit:

.inp         Analyse-Eingabedatei
.dat         druckfähige Ausgabedatei
.f           User Subroutine
.fil         Ergebnisdatei (*FILE-Kommando)
.fin         Ergebnisdatei nach Verwendung von abaqus ascfil
.fct         Sparse Solver Factor File (temporär)
.opr         Sparse Solver Operator File
.sol         Sparse Solver Scratch File
.uft         Scratch File für den unsymmetrischen Solver
.eig         Lanczos-Eigenvektordatei (temporär)
.lnz         Lanczos-Vektordatei (temporär)
.scr         Lanczos Scratch File
.res         Restart File
.odb         Output Database für ABAQUS/CAE
.mdl         Model File
.sup         Substrukturdatei 
.sta         Status-Datei
.msg         Message File   
.log         Job-Protokoll  
.lck         Lock File Output Database (temporär)           
.023         Communications File

ABAQUS/Explicit:

.abq         State File
.pac         Package File: Modellinformationen
.sel         Selected Results File

ABAQUS/CAE und (ABAQUS/Viewer):

.jnl         Journal File (Wiederherstellung der Modell-Datenbank)
.cae         Model Database
.odb         Output Database
.rpy         Kommandodatei

ABAQUS/Design:

.psf         Python Skriptdatei zur Parametrisierung
.par         modifizierte Version der parametrisierten Eingabe
.pmg         Message File bei Parametrisierung
.var         Eingabevariationen bei Parametrisierung

ASCFIL-Skript:

.fil         Result File (*FILE-Kommando)
.fin         Result File (ASCII)

Daneben gibt es noch eine Reihe von weiteren Dateien in ABAQUS/Standard und ABAQUS/Explicit sowie in den diversen ABAQUS-Prozeduren wie Append, Ascfil, Fetch, Fromnastran etc. (siehe Analysis User's Manual, Volume I, Kap. 3.5)

Nutzung von ABAQUS auf dem HLRN-System

Für Großprojekte mit sehr großen FE-Modellen kann die Nutzung des HLRN-Rechnersystems erforderlich werden und sinnvoll sein. Für das Antragsverfahren für ein Account im HLRN wird auf die HLRN-Homepage verwiesen.

Die Nutzung des HLRN-Rechnersystems mit dem FE-Produkt ABAQUS beschreibt die folgende Dokumentation.

Nutzung von ABAQUS auf dem RRZN-Cluster

1. Allgemeines

Dieses Kapitel beschreibt die Besonderheiten der Installation und der Nutzung von ABAQUS auf dem RRZN-Cluster-Systemen.

Die Software-Pakete werden auf dem Linux-Cluster über die Module-Technik verfügbar gemacht. Mit dem module-Befehl werden Umgebungen für spezifische Software-Pakete eingerichtet oder auch wieder entfernt. Eine Übersicht gibt das Kommando module avail. Für weitere Informationen über das Module-Konzept auf dem Cluster wird auf die Seite Module verwiesen.

Das Programmsystem ABAQUS steht daher nach dem Kommando

module load abaqus

zur Benutzung zur Verfügung.

2. Benutzung von ABAQUS auf dem RRZN-Cluster

Im Allgemeinen kann ABAQUS auf verschiedene Art und Weise verwendet werden:

interaktiv oder im Background (Dialogbetrieb)
im Batch, seriell oder parallel

Der Prä- und Postprozessor ABAQUS/CAE bzw. der Postprozessor ABAQUS/Viewer können mit einer grafischen Nutzer-Schnittstelle (GUI) genutzt werden. Die nächsten Abschnitte beschreiben die Vorgehensweisen für den Zugriff auf ABAQUS unter X11.

2.1 Interaktive Nutzung des Prä-/Postprozessors ABAQUS/CAE

1. Setzen der Umgebung:

module load abaqus

Eventuell ist es zusätzlich nötig, auf Ihrer Workstation xhost auf Orac oder Avon zu setzen und gegebenfalls auch auf dem Cluster selbst die DISPLAY-Variable auf die Adresse Ihrer Workstation zu setzen.

2. Aufruf von ABAQUS/CAE

 abaqus cae [database=database-file]   (default)

2.1 Aufruf von ABAQUS/CAE - Version 10.1-2

module load abaqus/6102

abq6102 cae [database=database-file] (Vers. 10.1-2)

2.2 Nutzung von ABAQUS im seriellen Modus im Dialogbetrieb

Die Nutzung von ABAQUS im Dialogbetrieb ist nur eingeschränkt sinnvoll unter Berücksichtigung der folgenden Randbedingungen:

nur für (sehr) kleine FE-Modelle
nur im seriellen Modus (cpus=1)

2.2.1 Interaktive Nutzung von ABAQUS im seriellen Modus

Die FE-Analyse wird durch den folgenden Aufruf von ABAQUS interaktiv und seriell auf dem Login-Knoten des Clusters ausgeführt:

 abaqus job=job-name analysis cpus=1 interactive

Diese Vorgehensweise ist nur für ganz kleine FE-Modelle, die wenige Ausgabedaten und nur wenig Rechenzeit benötigen, sinnvoll. Für größere FE-Modelle ist die Nutzung der Rechenknoten im Batchbetrieb (siehe Abschnitte 3.4 ff.) erforderlich.

2.2.2 Nutzung von ABAQUS im seriellen Mode im Background

Die FE-Analyse wird durch den folgenden Aufruf von ABAQUS seriell auf dem Login-Knoten im Background ausgeführt:

 abaqus job=job-name analysis cpus=1 background

Diese Vorgehensweise ist ebenfalls nur für kleine FE-Modelle, die nur wenig Rechenzeit benötigen, erlaubt. (Batch-Jobs siehe die nächsten Abschnitte).

2.3 Nutzung von ABAQUS im Batchbetrieb

Die FE-Analyse mit ABAQUS sollte nur für ganz kleine FE-Modelle im Dialogbetrieb (siehe Abschnitte 3.2 und 3.3) auf dem Login-Knoten des Clusters ausgeführt werden. Für größere FE-Modelle ist dagegen die Nutzung von ABAQUS auf den Rechnenknoten des Clusters unbedingt erforderlich. Diese Rechenknoten sind nicht direkt erreichbar, sondern nur im Batchbetrieb. Im Folgendem wird beschrieben, wie ABAQUS im seriellen oder parallelen Modus auf den Rechenknoten des Clusters durchgeführt werden kann. Die zur Verfügung stehenden Ressourcen pro Knoten auf den RRZN-Computeservern, finden Sie unter Rechnerressourcen.

Zur Abgabe von Batch-Jobs steht auf den RRZN-Computeservern das Batchsystem Torque/PBS zur Verfügung. Drei Schritte sind im Batchbetrieb auszuführen:

1. Ein ausführbares Shellskript (d.h. ein PBS-Batchskript), das PBS-Kommandos, den Aufruf von ABAQUS und das Setzen der Umgebung enthält, ist vorzubereiten.

2. Vom Login-Knoten Orac oder Avon wird das Batchskript (z.B. jobskript) abgeschickt:

qsub jobskript

b) Serieller Modus versus paralleler Modus:

Der serielle Modus sollte immer für alle mittelgroßen bis großen FE-Modelle verwendet werden. Dies sind FE-Modelle mit einer Anzahl von bis zu ca. 100000 Freiheitsgraden. Bei sehr großen FE-Modellen (über 100000 Freiheitsgrade) ist häufig das Rechnen im parallelen Modus (d.h. auf mehreren Prozessoren gleichzeitig) besser geeignet, um schneller das Ergebnis der Analyse zu erhalten. Die Wallclock-Zeit verkürzt sich dabei im Idealfall proportional zur Anzahl der beteiligten Prozessoren.

Da bei Anwendungen mit ABAQUS/Explicit die Gebietszerlegungsmethode angewendet wird, ist hier der Einsatz des parallelen Modus schon bei mittelgroßen Modellen sinnvoll.

2.3.1 Nutzung von ABAQUS im Batchbetrieb im parallelen Modus

Die Parallelisierung in ABAQUS ist mittels zweier verschiedener Verfahren implementiert: Thread- und MPI-basierte Parallelisierung. ABAQUS kann sowohl auf Shared-Memory-Rechnern (Thread- und MPI-basiert) als auch auf Rechner-Cluster (MPI-basiert) parallel ausgeführt werden. Folgende Berechnungen werden in ABAQUS bei der Parallelverarbeitung unterstützt:

ABAQUS/Standard:

direkter Gleichungslöser (SPARSE Solver)
iterativer Gleichungslöser
Lanczos-Eigenlöser
Elementoperationen

ABAQUS/Explicit:

alle Berechnungen, Ausnahme: Input-Präprozessor und Packager-Modul
starke Laufzeitreduktion bei einer großer Anzahl von Knoten und Elementen
starke Laufzeitreduktion bei einer großer Anzahl von Inkrementen
verfügbar für Shared-Memory-Rechner und Rechner-Cluster
Parallelisierung durch automatische Gebietszerlegung oder Loop-Level-Methode

Weitere Details zur Parallelausführung in ABAQUS/Standard und ABAQUS/Explicit insbesondere die jeweils unterstützte Parallelisierungsmethode für die verschiedenen Gleichungslöser und die Ausnahmen und Besonderheiten beim direkten Gleichungslöser mit unsymmetrischen Matrizen auf einem Rechner-Cluster (also knotenübergreifend) finden Sie in der Online-Dokumentation im Analysis User's Manual unter "Parallelausführung in ABAQUS" im Abschnitt 11.9.

ABAQUS kann sowohl auf nur einem Rechenknoten des Clusters mit parallelen Prozessen als auch knotenübergreifend mit vielen parallelen Prozessen verwendet werden.

Batch-Skript auf dem RRZN-Cluster

Im Folgenden wird ein PBS-Jobskript für das Batchsystem Torque/PBS auf den RRZN-Computeservern beschrieben:

#!/bin/ksh
#
#PBS -S /bin/ksh
#PBS -N abaqus
#PBS -l nodes=1:ppn=2,walltime=01:00:00
# Ressourcenanforderung: 1 Knoten, 2 Prozessoren, 1 Std. Rechenzeit
#PBS -l mem=4000mb
#PBS -o std_inst.log
#PBS -e std_inst.aus
#PBS -m e
#PBS -M ...........@.......uni-hannover.de
#PBS -q all

# Wechsel in das Working Directory
cd $PBS_O_WORKDIR
#
# Bestimmung der Anzahl der Prozessoren für den cpus-Parameter bei Parallelverarbeitung
#
np=`expr $(cat $PBS_NODEFILE | wc -l)`
#
# Initialisierung der Modulefiles
. /usr/share/Modules/init/ksh

# Modulefile für das Release 6.11-3
module load abaqus/6113

Aufruf für einen seriellen Job
abaqus job=std_user analysis cpus=1 interactive

Erforderliches Modulefile bei Nutzung von User Subroutinen in Fortran
module load ifort

Ab ABAQUS Vers. 6.11 wird der Intel Compiler Vers. 11 unterstützt.
Das entsprechende Modulefile wird aufgerufen mit

module load ifort/11.1.046

Aufruf für seriellen Job mit einer User Subroutine
abaqus job=std_user analysis user=sub_user.f cpus=1 interactive

Aufruf für parallelen Job
abaqus job=std_user analysis cpus=$np standard_parallel=all interactive

Aufruf von ABAQUS mit MPI im Distributed Memory Modus

Hier wird beschrieben, wie ABAQUS im parallelen Modus auf mehreren Knoten im Batch-Jobs aufgerufen werden kann.

Batchskript für Knotenübergreifende MPI-Jobs
#PBS -l nodes=2:ppn=4,walltime=10:00:00
# Ressourcenanforderung: 2 Knoten, 4 Prozessoren, 10 Std. Rechenzeit

Skript zum erstellen einer hostliste für MPI-Jobs auf dem Server
create_abaqus_host_list

Aufruf für parallelen Job mit mpi
abaqus job=std_user analysis cpus=$np standard_parallel=all mpi_mode=mpi interactive

Gestartet wird der Job interaktiv auf Orac und Avon

qsub <jobskript>

Leibniz Universität IT Services - URL: www.rrzn.uni-hannover.de/abaquav63.html

Fischer, Letzte Änderung: 06.07.2012
Copyright Gottfried Wilhelm Leibniz Universität Hannover