Thomas Zeiser

Some comments by Thomas Zeiser about HPC@RRZE and other things

Content

Rechnerzuwachs und Generationswechsel bei den HPC-Clustern am RRZE

Vorarbeiten

Kabeltrassen, Stromverteilung und Kaltwasserverrohrung im Doppelboden.

Rechnerzuwachs klingt doch recht bescheiden, aber so sind wir eben. Dennoch ist am RRZE seit Wochen eine deutlich erhöhte Betriebsamkeit und Bautätigkeit zu beobachten. Es werden dicke Wasserrohre (15 cm Durchmesser) geschleppt und vom Keller bis in den ersten Stock verlegt und zusammengeschweißt, die Decken durchlöchert (Kernbohrungen mit bis ca. 25 Durchmesser für die Kaltwasserrohre inkl. deren Isolierung), neue Stromleitungen (Kabel mit ca. 5cm Durchmesser) verlegt und Vorbereitungen für einen neuen Trafo getroffen, der Doppelboden in Teilen des Rechnerraums verstärkt, etc. — nicht zuletzt wurde zuvor bereits der ehemalige Medizinbereich im Rechnerraum freigeräumt und auch einige ISER-Stücke mussten für die HPC-Installation weichen (finden aber z.T. in anderen Bereichen des Rechnerraums wieder Unterschlupf).

Anlieferung der Rechenknoten

... bis auf 5 Paletten war der gesamte Inhalt des Lasters für uns -- aber es war nicht der einzige LKW, der mit harter Ware für uns vorgefahren ist.


Anlieferung der Racks. Überall wo jetzt noch Löcher in den Bodenplatten zu sehen sind, werden Racks stehen.

Seit einer Woche Rollen nun schon immer wieder LKWs mit IT-Equipment an; inzwischen dürften es mehr als 60 Paletten mit Rechenknoten, Servern, Festplatten, Netzkomponenten, vielen vielen Kabeln, Racks und Kühleinheiten gewesen sein — so 5-10 Tonnen dürften da schon zusammengekommen sein.

Möglich wurde all dies durch einen Forschungsgroßgeräteantrag, zusätzliche Mittel von einigen Lehrstühlen und auch noch Restmittel aus dem Konjunkturpaket-II (letzteres speziell auch für diverse Bau-/Infrastrukturmaßnahmen), etc. …

Der neue HPC-Rechner wird LiMa heißen

  • Das Akronym LiMa entstand zunächst durch die Abkürzung zweier Leuchtturmprojekte aus dem Forschungsgroßgeräteantrag.
  • Wikipedia hat für Lima (mit kleinem “M”) auch viele Optionen zu Auswahl:
    Angefangen von der Hauptstadt Perus und weiterer Städte weltweit (geographische Angaben sind ja durchaus beliebt zur Benennung von IT-Dingen, vgl. nicht zuletzt Intel/AMD-Prozessoren),
    … über die malaysische/indonesische Zahl “fünf” oder die tibetische Bezeichnung für eine aus mindestens fünf verschiedenen Metallen bestehende Legierung zur Herstellung von Statuen und Glocken (wir haben mindestens fünf zentrale Bestandteile: Rechenknoten, Hochgeschwindigkeitsnetzwerk, paralleles Filesystem, Software und Stromversorgung/Kühlung)
    … bis hin zum Buchstaben “L” im ICAO-Buchstabieralphabet.
  • Nachdem der LiMa-Cluster aber etwas größer wird als TinyBlue, verglichen mit großen Clustern (z.B. JuRoPa am JSC/FZ-Jülich) aber noch klein ist, kann LiMa auch für Little Machine stehen. Hieran erkennt man die fränkische Bescheidenheit. Obwohl LiMa zum Zeitpunkt der Inbetriebnahme der leistungsstärkste Rechner (bezogen auf die Peak-Performance und wohl auch die Linpack-Leistung) sein wird und mit seinen 63.8 TFlop/s Peak einen (kleinen) Vorsprung vor dem HLRB-II mit 62.3 TFop/s hat, erscheint “SuperFranke”, “SuperERL” oder gar “SuperFranconianAdvancedCluster” (in Anlehnung an SuperMUC, dem aktuellen Beschaffungsprojekt am LRZ) unpassend und übertrieben …

Mal abwarten, welche Erklärung sich für das Akronym letztendlich durchsetzen wird …

Zurück zu den harten Fakten des LiMa-Clusters

Im Rahmen eines europaweiten Ausschreibungsverfahrens wurde die HPC-Lösung mit dem besten Preis-Leistungsverhältnis bestimmt, wobei das Gesamtbudget vorgegebenem war. Neben der Menge der Hardware spielte dabei insbesondere auch die zugesicherte Leistung für einen typischen Erlanger Applikationsmix eine zentrale Rolle. Neun Firmen haben Ende Mai gültige Angebote abgegeben. Als Gewinner der Ausschreibung und somit Lieferant des LiMa-Clusters ist NEC hervorgegangen (Link zur NEC-PRessemeldung).

Der jetzt installierte Cluster stammt aus der NEC LX-2400 HPC-Cluster-Serie und umfasst:

  • 500 Rechenknoten mit jeweils zwei Intel Xeon 5650 Prozessoren (6-Core Westmere 2,66 GHz), 24 GB DDR3 RAM, QDR-Infiniband, ohne lokale Festplatte; jeweils 4 Rechenknoten sind dabei in einem 2U hohen Gehäuse untergebracht (“Twin2”); insgesamt sind es also 6000 (physikalische) Rechenkerne und knapp 12 TB (verteilter) Hauptspeicher
  • paralleles Filesystem (NEC LXFS = auf Lustre-Basis) mit 120 TB Nutzkapazität auf rund 180 Festplatten (inkl. RAID6-Parity-Platten und Hot-Spare-Platten) und einer aggregierten Bandbreite von 3 GB/s zur kurzfristigen Ablage von Simulationsdaten
  • QDR-Infiniband-Netzwerk mit vollständiger Fat-Tree Topologie ohne Ausdünnungen
  • 11 geschlossene Racks mit beigestellten Kühleinheiten (=> Rechenknoten); 3 offene Racks (=> Netzwerkkomponenten, Storage, Login- und Managementserver)
  • CentOS 5.5 als Betriebssystem, torque/maui als Batchsystem, …

Aktueller Stand der LiMa-Installation

Verlegung der Infiniband-Verkabelung.

Die NEC-Mitarbeiter kämpfen derzeit noch fleißig mit dem Verlegen der Kabel (insgesamt knapp 2000 Stück; insbesondere die Infiniband-Kabel sind dabei auch noch unhandlich dick) …

Auch die Kaltwasserverrohrung vom Keller bis hoch in den Rechnerraum im 1. OG ist noch nicht vollständig fertiggestellt.

Die Arbeiten gehen aber grundsätzlich zügig voran. Die erste Inbetriebnahme wird jedoch trotzdem noch ein paar Tage auf sich warten lassen — rechtzeitig vor der Frist für die Einreichung zur nächsten Top500-Liste, die im November veröffentlicht wird, sollte jedoch alles laufen. Nicht dass wir auf den Linpack-Wert besonders scharf sind, aber es schadet sicherlich nicht, wenn Franken mal wieder im vorderen Mittelfeld der Top500 sichtbar ist …

Auf die Frage, wann denn der reguläre Benutzerbetrieb beginnt, gibt es eine sehr einfache FAQ-Antwort: wenn alles fertig ist und stabil läuft. Nicht früher und auch nicht später. Weitere Fragen nach einem Termin erübrigen sich damit hoffentlich.

Komplementäre Ergänzung durch TinyFat

Parallel zu LiMa wurden in einem weiteren gekühlten Rack dicke Knoten für Anwender mit hohem Hauptspeicherbedarf beschafft und durch das RRZE installiert:

  • 17 Knoten (HL DL385G7) mit jeweils zwei 8-Core AMD MagnyCours Prozessoren (2,3 GHz), 128 GB Hauptspeicher und ebenfalls QDR-Infiniband
  • 1 Knoten (HP DL580G7) mit vier 8-Core Intel Nehalem EX Prozessoren und 512 GB (=0.5 TB) Hauptspeicher

TinyFat — der Ursprung für den Namen dürfte klar sein — geht in den Betrieb, sobald die Kühlung der Knoten sichergestellt ist, d.h. die Kühleinheiten mit Kaltwasser aus der zentralen Kälteversorgung verbunden sind.

Betriebsende für (weitere) Teile des “Cluster32” steht bevor

Bereits im vergangenen Jahr musste der älteste Teil des alten Cluster32 (“Transtec-Cluster”) mit den snode0xx-Knoten für TinyBlue weichen. Nachdem jetzt insbesondere mit LiMa so viel neue Hardware gekommen ist, wird in den nächsten Monaten wohl der nächste Teil des “Cluster32” außer Betrieb genommen werden. Insbesondere die beiden Racks mit den snode1xx-Knoten sind nach über 5 Jahren Betrieb nicht mehr wirklich auf der Höhe der Zeit, obwohl die Knoten durchaus noch immer gut ausgelastet sind. Neun (seit der letzten Abschaltung evtl. auch ein paar mehr) der ursprünglich einmal 64 Knoten mit je zwei “Nocona”-CPUs (d.h. der ersten Generation von Intel NetBurst-Prozessoren mit “EM64T”) sind aufgrund von Hardwaredefekten sowieso bereits aus …

2009 ist also die 32-bit Ära bei uns mit der Abschaltung der snode0xx-Knoten zu Ende gegangen, 2010 wird mit der Abschaltung der snode1xx-Knoten dann auch noch die Single-Core-Ära für HPC@RRZE beendet werden. Willkommen im reinen Multi-/ManyCore-Zeitalter

Details zur Abschaltung werden aber noch rechtzeitig folgen.

slight change of the Intel compiler modules: MKL modules loaded automatically

Starting from today, our intel64 compiler modules for version 11.0 and 11.1 of the Intel compilers will automatically load the MKL module corresponding to the bundled version in the Intel Processional Compilers, too.

  • If you do not use MKL, this change will not affect you.
  • If you want (or have) to use a different version of MKL, you have to load the MKL module before loading the compiler module OR you have to unload the automatically loaded MKL module before loading your desired version.

Motivation for this change was to make the compiler option -mkl work properly (or at least better), i.e. give the user a reasonable chance to find the MKL libraries at runtime. You still have to load the compiler (or mkl) module at runtime OR you have to add -Wl,-rpath,$MKLPATH explicitly to your linker arguments …

Zuwachs im TinyGPU-Cluster

TinyGPU hat Zuwachs bekommen: tg010. Die Hardware-Ausstattung und aktuell auch die Software dieses “Fermi-Knotens” sind anders als bei den restlichen acht Knoten:

  • Ubuntu 10.04 LTS (statt 8.04 LTS) als Betriebssystem.
    Hinweis: Um lokal auf tg010 mit Intel Compilern <= 11.1 übersetzen zu können, muss [derzeit] das gcc/3.3.6 Modul geladen werden, da sonst libstdc++.so.5 nicht gefunden wird, da diese Bibliothek in Ununtu 10.04 nicht mehr enthalten ist. Das gcc/3.3.6-Modul wird nur zum Übersetzen benötigt – fertige Intel-Binaries laufen auch ohne problemlos.
  • Die Nvidia-Treiberversion ist inzwischen auf allen Knoten identisch; aktuell: 256.40 / seit 8. Sept. 2010 überall 256.53
  • /home/hpc und /home/vault sind (nur) per NFS gemountet (und nativ via GPFS-Cross-Cluster-Mount)
  • Dual-Socket-System mit Intel Westmere X5650 (2.66 GHz) Prozessoren mit 6 physikalischen Kernen pro Socket (statt Dual-Socket-System mit Intel Nehalem X5550 (2.66 GHz) mit 4 physikalischen Kernen pro Socket)
  • 48 GB DDR3 RAM (statt 24 GB DDR3 RAM)
  • 1x NVidia Tesla C2050 (“Fermi” mit 3 GB GDDR5 mit ECC)
  • 1x NVidia GTX 280 (Consumer-Karte mit 1 GB RAM – war früher im Testcluster)
  • 2 weitere PCIe2.0 16x Slots werden in Q4 wohl noch mit NVidia C2070 Karten (“Fermi” mit 6 GB GDDR5 mit ECC) bestückt werden
  • statt 2x NVidia Tesla M1060 (“Tesla” mit 4 GB RAM) wie in den restlichen TinyGPU-Knoten
  • SuperServer 7046GT-TRF / X8DTG-QF mit Dual Intel 5520 (Tylersburg) Chipset statt SuperServer 6016GT-TF-TM2 / X8DTG-DF mit einem Intel 5520 (Tylersburg) Chipset

Um den “Fermi-Knoten” anzufordern, müssen Jobs :ppn=24 verwenden (statt :ppn=16) und explizit in die neue TinyGPU-Queue fermi submittiert werden. Das Laufzeitlimit ist wie üblich 24h. Ob ECC auf der Fermi-Karte aktuell ein- oder ausgeschaltet ist, wird beim Jobstart angezeigt.

Remotevisualisierung mit VirtualGL

Das RRZE hat seit Ende 2009 acht Rechenknoten mit jeweils zwei NVIDIA Tesla M1060 Grafikkarten (baugleich zur C1060 jedoch rein passiv gekühlt) und DDR-Infiniband-Vernetzung: TinyGPU-Cluster

Diese Rechner können nicht nur als Rechenknechte (via CUDA oder OpenCL) genutzt werden, sondern auch zur Remote-Visualisierung mittels VirtualGL). Das LRZ betreibt zum gleichen Zweck bereits seit längerer Zeit einige leistungsfähige Systeme: LRZ-Dienst Visualisierung

Das GPU-Cluster am RRZE ist als experimentelles Forschungscluster ausgelegt. Daher ist, sowohl was CUDA/OpenCL als auch die Remote-Visualisierung betrifft, stets mit Änderungen zu rechnen, insbesondere da derzeit die Umstellung von CUDA-Tookit 2.3 auf Version 3.0 ansteht, was mit einem Upgrade des NVIDIA-Kernel-Treibers verbunden ist. (Update August 2010: inzwischen läuft sogar schon 3.1)

Um VirtualGL nutzen zu können, muss auf dem lokalen Rechner entweder VirtualGL (inkl. TurboJPEG oder libjpeg-turbo) oder aber TurboVNC (oder TigerVNC) installiert sein. Wenn dann eine Remote-Visualisierung ansteht, besorgt man sich auf TinyGPU am besten einen interaktiven Batchjob (ggf. auf einem bestimmten Knoten, da VirtualGL derzeit nicht auf allen Knoten installiert ist). Während der Batchjob läuft, kann man sich auf dem entsprechenden Knoten auch direkt per SSH einloggen. Sofern man VirtualGL nativ verwendet (bietet sich von Linux-Clients aus an), so verwendet man ein vglconnect -s kennung@tgXXX um auf den reservierten Knoten zu kommen. Dort kann man dann die Grafik-intensive Applikation mit vglrun ./a.out starten. (Für STAR-CCM+ muss vglrun -nodl starccm+ verwendet werden, wenn STAR-CCM+ im parallelen Modus laufen soll.) Wie man die beide GPUs via VirtualGL sinnvoll nutzen kann, ist derzeit noch unklar.

Bezüglich der aktuellen Konfiguration und weiterer Nutzungshinweise wenden Sie sich bitte an die HPC-Gruppe.

Seit 19. Juli 2010 muss die Eigenschaft virtualgl explizit von den Jobs angefordert werden, damit beim Jobstart ein X-Server gestartet wird.

Defaults or special options of different MPI implementations to remember

More and more MPI implementations try to scope with the increasing complexity of modern cluster nodes. However, sometimes these automatic defaults are counterproductive when trying to pinpoint special effects …

Things to remember:

  • Open MPI:
  • Mvapich2:
    • recent version of mvapich2 default to MV2_ENABLE_AFFINITY=1 which enables internal pinning and overwrites any taskset given on the command line. Either use MV2_CPU_MAPPING (containing colon-separated CPU numbers) to make the correct pinning or set MV2_ENABLE_AFFINITY=0 and do external pinning. RRZE’s mpirun wrapper (as of Feb. 2010) disables the internal mvapich2 affinity routines to make our -pin argument work (again).
    • pinning of hybrid codes (mvapich2 + OpenMP) using RRZE’s pin_omp: PINOMP_SKIP=1,2 (cf. http://www.blogs.uni-erlangen.de/JohannesHabich/stories/3414/#4721)
      The resulting command line can be rather length: e.g. env PINOMP_SKIP=1,2 OMP_NUM_THREADS=4 KMP_AFFINITY=disabled mpirun -npernode 2 -pin 0,1,2,3_4,5,6,7 env LD_PRELOAD=/apps/rrze/lib/ptoverride-ubuntu64.so ./a.out
  • Intel MPI:
    • starting large jobs over Infiniband: using the socket connection manager (SCM) instead of the default connection manager (CMA) might improve the start-up sequence. One might try env I_MPI_DEVICE=rdssm:OpenIB-mthca0-1 on Woody and TinyGPU, env I_MPI_DEVICE=rdssm:ofa-v2-mthca0-1 on Townsend or I_MPI_DEVICE=rdssm:OpenIB-mlx4_0-1 on TinyBlue or TinyFat.
      (The newer syntax to use together with I_MPI_FABRICS is I_MPI_DAPL_PROVIDER or I_MPI_DAPL_UD_PROVIDER.)
      Thanks to Intel for pointing out this OFED/Intel-MPI option. Unfortunately, there is only very little OFED documentation on the differences between CMA and SCM: http://www.openfabrics.org/downloads/dapl/documentation/uDAPL_release_notes.txt (Release notes from December 2009 for OFED-1.5).
      UCM might be even more scalable; use I_MPI_DAPL_UD=enable I_MPI_FABRICS=shm:dapl. — on Townsend, Woody and Tiny{Blue,FAT,GPU} UCM is available if the experimental “dapl” moule is loaded before any Intel MPI module.
    • bug (at least) in Intel MPI 3.1.0.038: connections to MPD daemons may fail if $TMPDIR is set to something different than /tmp
    • bug in Intel MPI 4.0.0.025: Intel’s mpirun as shortcut for mpdboot - mpiexec - mpdallexit cannot read properly from STDIN; the problem is the newly with this release introduced sequence of mpiexec "$@" & wait $! instead of the traditional mpiexec "$@". RRZE’s PBS-based mpirun is not affected by this problem.
    • incompatibilities between RRZE’s PBS-based mpirun (i.e. Pete Wyckoff’s mpiexec) and I_MPI_DEVICE=rdssm: from time to time we observe that processes hang either during startup (at MPI_Init or at the first larger scale communication) or even more often at MPI_Finalize. I_MPI_DEVICE=rdma usually does not have these problems but is noticeable slower for certain applications. As the behavior is non-deterministic, it’s hard/impossible to debug and as the PBS-based start mechanism is not supported by Intel we cannot file a problem report neither. And of course Intel’s extensions of the PMI startup protocol also not publically documented …
    • you have recent Qlogic Infiniband HCA? I_MPI_FABRICS=tmi I_MPI_TMI_PROVIDER=psm should be appropriate (PS: I_MPI_FABRICS is the replacement for I_MPI_DEVICE introduced with Intel-MPI 4.0)
  • HP-MPI:
    • The environment variable MPIRUN_OPTIONS can be used to pass special options to HP-MPI, e.g. "-v -prot" to be verbose and report the used interconnect; –"-TCP -netaddr 10.188.84.0/255.255.254.0" to force TCP and select a specific interface (e.g. for IPoIB).
    • HP-MPI has its own pinning mechanism; cf. page 16/17 of /apps/HP-MPI/latest/doc/hp-mpi.02.02.rn.pdf dor details; MPIRUN_OPTIONS="-cpu_bind=v,map_cpu:0,2,1,3" should be fine for regular jobs on Woody. If you require a lot of memory and would like to use only one MPI process per socket, the correct option should be MPIRUN_OPTIONS="-cpu_bind=v,map_cpu:0,1"
  • Parastation MPI as e.g. used on JUROPA of FZ-Jülich
    • Any pointer to pinning mechanisms for processes would highly be appreciated.
    • The latest versions (cf. psmgmt 5.0.32-0) have the environment variable __PSI_CPUMAP which can be set to individual cores or core ranges, e.g. "0,2,4,6,1,3,5,7" or "0-3,7-4".
  • to be continued

minor modifications to RRZE’s mpirun wrapper

For certain applications and processor numbers, there were problems with hanging MPI processes in the startup phase when using Intel MPI together with PBS’s mpiexec and I_MPI_DEVICE=rdssm. Therefore, we changed the default I_MPI_DEVICE for Woody, Townsend and TinyBlue from rdssm to rdma. In practice, one should not see any difference as rdssm with recent versions of Intel MPI did not use shm but rdma also within the node.

Single node jobs on Woody and TinyBlue using Intel MPI and our mpirun wrapper will from now on use shm by default if exactly one node was requested for the PBS jobs.

additional settings for mvapich2:

To make our -pin argument work with recent mvapich2 versions, we recently added a default of MV2_ENABLE_AFFINITY=0 to our mpirun wrapper.

Pinning of MPI processes

RRZE’s mpirun-wrapper which can be used with Intel-MPI, MPICH, MVAPICH, MVAPICH2 has the option -pin which enables explicit pinning of processes to certain cores. See mpirun -h on one of RRZE’s cluster systems for details.

Open-MPI cannot (yet) be used with RRZE’s mpirun-wrapper. However, Open-MPI’s mpirun (or mpiexec) already has a lot of very nice features, including support for explicit pinning. using the --rankfile xyz command line option. This option works even if the job is running under control of PBS/torque. The only cumbersome task is to create the rankfile, however, you do not need to know how the CPUs are numbers in a multi-core, multi-socket system as Open-MPI used logical descriptions, i.e. socket number and core number within the socket. The syntax of the rankfile is as follows (check the Open-MPI manpage of mpirun for details):

          rank 0=w0101 slot=0:0
          rank 1=w0101 slot=0:1
          rank 2=w0101 slot=1:0
          rank 3=w0101 slot=1:1

which bind rank0 to the first CPU in socket 0, rank1 to the second CPU of socket0, etc. Of course the hostname (w0101 in the example) must match the list of nodes you got from the queuing system – and you need one line per MPI rank, i.e. 256 lines if running on 64 nodes with 4 cores each). As also ranges of CPUs can be specifid (see manpage for details; section “Specifying Ranks”), this mechanism should also work quite well for hybrid codes (i.e. MPI+OpenMP) although the OpenMPI threads not bound themselves to explicit cores but only altogether to groups of cores … Additional effort (e.g. based on the pthread-overload.c library used by RRZE’s pin_omp) would be required to explicitly ping hybrid OpenMPI threads, too.

Further information on the usage of pinning on the RRZE clusters is described in http://www.blogs.uni-erlangen.de/JohannesHabich/stories/3414/ (using RRZE’s recommended/supported mpirun-wrapper and Intel-MPI)

combining several sequential jobs in one PBS job to fill a complete node

Sometimes trivial parallelism is the most efficient way to parallelize work, e.g. for parameter studies with a sequential program. If only complete nodes may be allocated on a certain cluster, several sequenatial runs can very easily be bundled into one job file:

[shell]
#!/bin/bash -l
# allocate 1 nodes (4 CPUs) for 8 hours
#PBS -l nodes=1:ppn=4,walltime=08:00:00
# job name
#PBS -N xyz
# first non-empty non-comment line ends PBS options

# jobs always start in HOME
# but we want to go to the directory where we submitted the job
cd $PBS_O_WORKDIR

# run 4 sequential parameter studies in parallel and bind eachone
# to a specific core
(taskset -c 0 ./a.out input1.dat ) &
(taskset -c 1 ./a.out input2.dat ) &
(taskset -c 2 ./a.out input3.dat ) &
(taskset -c 3 ./a.out input4.dat ) &

# wait for all background processes to finish (“wait” is a bash built-in)
wait
[/shell]

The bash builtin wait ensures that all background processes have finished once wait returns.

For this to work efficiently, of course all parameter runs should take about the same time …

Installation of OpenFOAM-1.5 on Woody

Using pre-built binaries

Does not work as SuSE SLES10SP1 is too different …; one very strange thing is that the gcc-4.3.1 included in the ThridParty packages does work in 32-bit but complains about an incompatible library in 64-bit mode although the library is a correct 64-bit *.so

Building from sources using the Intel Compiler (10.1)

Fails due to problems with C++ templates, etc.

Building gcc-4.3.x manually

Has too many dependencies to quickly do it (MPFR and GNUMP – the SuSE SLES10SP1 versions are too old)

Building from sources using gcc-4.2.2

Requires a patch for autoRefineDriver.C to avoid fatal “invalid conversion” error message; cf. http://openfoam.cfd-online.com/cgi-bin/forum/show.cgi?tpc=126&post=24786)

Some general tricks

  • use WM_COMPILER_INST=System to specify that the system’s gcc should be used and not one which is part of OpenFOAM
  • use WM_NCOMPPROCS to specify the number of CPUs on which make may run concurrently (i.e. the value for make’s -j parameter)
  • at least for building ParaView, cmake (and of course Qt-4.3.x) must be available; it is likely that PV3FoamReader must be compiled afterwards (cf. OF-Readme) and it also depends on cmake
  • when building ParaView, CMAKE_HOME and W_COMPILER_DIR must be set as some sed commands fail otherwise

Running Turobomole 5.10 in parallel on RRZE’s clusters

Recent versions of Turbomole come bundled with HP-MPI. This allows using different types of network interconnects for parallel runs and HP-MPI is supposed to select the fastest one available – but sometimes HP-MPI requires manual intervention to select to correct interconnect … As parallel runs of Turbomole also require one control process, additional intervention is required to avoid overbooking of the CPUs.

Here is a short receipt for RRZE’s clusters:

[shell]
#!/bin/bash -l
#PBS -lnodes=4:ppn=4,walltime=12:00:00
#PBS -q opteron
#… further PBS options as desired

module load turbomole-parallel/5.10

# shorten node list by one
. /apps/rrze/bin/chop_nodelist.sh

# prevent IB initialization attempts if IB is not available
ifconfig ib0>& /dev/null
if [ $? -ne 0 ]; then
export MPIRUN_OPTIONS=”-v -prot -TCP”
fi

# now call your TM binaries (jobx or whatever)
[/shell]

manually setting the TM architecture: As the s2 queue of the Transtec cluster has access to 32 and 64-bit nodes since recently, it may be a good idea to restrict the Turbomole binary to the 32-bit version which can run on both types of nodes by including export TURBOMOLE_SYSNAME="i786-pc-linux" in the PBS job script.

pinning with HP-MPI: As Turbomole internally uses HP-MPI, the usual pinning mechanisms of RRZE’s mpirun cannot be used with Turbomole. If you want to use pinning, you have to check the HP-MPI documentation and use their specific command line or environment variables! Cf. page 16/17 of /apps/HP-MPI/latest/doc/hp-mpi.02.02.rn.pdf.