Thomas Zeiser

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

Content

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)

local OpenFOAM mailing list

OpenFOAM is a widely used open-source software for computational fluid dynamics (CFD). There is also a growing number of groups on our campus which use or at least give OpenFOAM a try. I never applied OpenFOAM for CFD simulations myself – I only spent lots of hours installing it on RRZE’s clusters. But from what I heard from actual users, documentation seems to be rather poor resulting in a slow learning curve. To facilitate and stimulate a coordinated communication and self-help of the different OpenFOAM users and groups at the University of Erlangen-Nuremberg, a local mailing list has been set up. OpenFOAM users from outside of the University of Erlangen-Nuremberg are also welcome if they give a substantial contribution – but keep in mind that this local mailing list is not an official OpenFOAM support forum.

The subscription policy for the mailing list is “open”, i.e. everyone can directly subscribe/unsubscribe. Posts to the mailing list are only allowed from registered users (i.e. from the email address used for subscription) – all other messages require approval by the moderator to prevent spam.

For further information and (un)subscription, please visit the webpage of the rrze-openfoam-user mailing list.

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 …

Arbeitspakete im Projekt SKALB und erste Aufgaben

Das BMBF-Projekts SKALB gliedert sich in fünf große Arbeitspakete, die jeweils von mindestens drei Projektpartnern gemeinschaftlich bearbeitet werden. Alleine hierdurch wird die interdisziplinäre Vernetzung deutlich. Die ersten Aufgaben für die einzelnen Arbeitspakete sind im folgenden ohne Anspruch auf Vollständigkeit kurz beschrieben.

Arbeitspaket I: Portierung und Optimierung von LB-Applikationen auf massiv parallele HPC-Systeme

Zentraler Punkt dieses Arbeitspakets ist die Portierung und Optimierung der eingesetzten Simulationscodes auf eine breite Palette modernster hochparalleler HPC-Systeme. Der erste Schritt dabei ist eine Bestandsaufnahme hinsichtlich der seriellen und parallelen Performance. Begleitet werden die Arbeiten zur effizienten Implementierung von LB-Applikationen für bereits bestehende sehr große HPC-Systemen durch umfangreiche Aktivitäten zu den Themen alternative parallele Programmiermodelle sowie neue Programmier- und Optimierungsansätze für zukünftige Multi- und Many-Core Standardprozessoren.

Arbeitspaket II: Weiterentwicklung von LB-Methoden für praktische Anwendungen auf hochskalierenden Systemen

Zentrale Punkte dieses Arbeitspakets sind Gebietszerlegung/Gebietspartitionierung, (dynamische) Lastbalanzierung, aber auch Fragen des Pre- und Postprocessings.

Arbeitspaket III: Verbesserte numerische Ansätze für LB-Methoden

In gängigen LB-Ansätzen kann jeder einzelne Zeit- und Teilschritt mit sehr hoher computational Effizienz durchgeführt werden, aber die numerische Effizienz ist aufgrund der Explizitheit vieler Zugänge und Beschränkung auf regelmäßige Gitterstrukturen noch nicht optimal. Moderne und sehr leistungsfähige Diskretisierungs- und Lösungstechniken für Partielle Differentialgleichungen, die von der Mathematik in den letzten Jahren entwickelt und inzwischen für andere CFD-Verfahren erfolgreich angewendet werden konnten, haben ihren Weg allerdings noch kaum in den Bereich der LB-Verfahren gefunden und sollen in diesem Arbeitspunkt untersucht werden.

Arbeitspaket IV: Hardwarenahe Implementierung für Nicht-Standardprozessoren

Aktuelle Hardwaretrends sollen in diesem Projekt nicht nur für Standardprozessoren im Umbruch (“Multi-Core”), sondern auch für Nicht-Standardarchitekturen berücksichtigt werden. Aufgrund der Erfahrungen der beteiligten Gruppen wurde sich für die Verwendung von Grafikprozessoren (GPUs) als Repräsentant zukünftiger Many-Core-Architekturen und den Cell-Prozessor als Prototyp heterogener Multi-Core-Prozessoren entschieden.

Arbeitspaket V: Benchmarking und Showcases

Das Spektrum der Showcases wird große Teile typischer Industrieanwendungen abdecken, die jedoch auch unterschiedliche Strömungsregimes repräsentieren und damit auch unterschiedliche methodische Ansätze erfordern. Als Testcases, die dokumentiert werden sollen, wurden vorläufig ausgewählt:

  • Grundlagenuntersuchungen im Bereich turbulenter Strömungen
  • Strömungen in porösen Medien und hierarchischen Katalysatoren
  • Mehrphasenströmungen und nicht-newtonsche Fluide
  • Strömungen mit freien Oberflächen (LB-Flachwassermodelle sowie volle 3D-Modelle).
  • Wassertransport in Brennstoffzellen
  • Blutfluss in Aneurysmen

Erfolgreiches SKALB-KickOff-Meeting

Am 16.2.2009 fand im eStudio des RRZE das KickOff-Meeting des vom BMBF geförderten Projekts SKALB statt. Neben Vertretern aller geförderten Gruppen (RRZE, LSS, HLRS, iRMB, TU-Do, IANUS) war auch Dr. Aßelmeyer-Maluga vom Projektträger anwesend. Neben formalen Dingen wie dem Austausch der unterschriebenen Seiten der Kooperationsvereinbarung und Hinweisen des Projektträgers zu unseren Pflichten, wurde auch inhaltlich intensiv gearbeitet und u.a. die Arbeiten der nächsten Monate abgestimmt.

Regelmäßige Videokonferenzen und persönliche Treffen in Kleingruppen werden in den nächsten Monaten folgen.

Für Dienstag den 30. Juni 2009 ist derzeit das nächste größere und dann auch öffentliche Treffen geplant zu dem dann insbesondere auch Vertreter des assoziierten Partner eingeladen werden.

Teilnehmer des SKALB-KickOff-Meetings am 16.2. in Erlangen

Pressemeldung der TU-Dortmund zu SKALB

Auf den Webseiten der TU-Dortmund ist eine weitere Pressemeldung zu SKALB zu finden: http://www.tu-dortmund.de/uni/Infobrief_Rektorat/infobrief_2009_01/SKALB/index.html

Auch im ITM-Update 02/09 Nr. 6 ist ein Artikel über SKALB zu finden: http://www.itmc.uni-dortmund.de/en/docman/itm_update/dokumente_itmupdate_nr6/Dokumente_ITMUpdate_nr6.pdf

weitere Pressemeldung aus Dortmund: … und noch eine Meldung bei "der-Innovationsstandort.de" über SKALB.

persönlicher Kommentar zu den Meldungen aus Dortmund:
Die vielfältigen PR-Aktivitäten in Dortmund sind ja sehr lobenswert. Nur schade, dass ich jedes mal bei "Im Projekt arbeiten Wissenschaftlerteams unter der Leitung von Prof. Dr. Stefan Turek (Fakultät für Mathematik der TU Dortmund) und Dr. Ramin Yahyapour (IT und Medien Centrum der TU Dortmund) gemeinsam mit Kollegen der Universitäten und Rechenzentren Erlangen-Nürnberg, Stuttgart und Braunschweig." ins Stutzen komme. Bezieht sich das "unter Leitung von" jetzt nur auf die Arbeitsgruppen an der TU-Dortmund oder generell auf das gesamte Projekt? Koordinator des Gesamtprojekts ist auf jeden Fall Dr. Gerhard Wellein vom RRZE der Uni-Erlangen. Naja, was soll’s. Unsere Pressemeldungen sind vielleicht auch manchmal etwas missverständlich.

Termin des SKALB-Kick-Off-Meetings steht

Ort und Termin für das Kick-Off-Meeting zum BMBF-Projekt “SKALB” stehen nun fest: 16.2.2009 am RRZE in Erlangen.

Das Kick-Off-Meeting dient im Wesentlichen der internen Koordination. Daher ist diese Auftaktveranstaltung nicht-öffentlich. Außer Mitarbeitern aus den geförderte Gruppen wird daher nur ein Vertreter des Projektträgers als “Externer” teilnehmen.

Künftige Treffen sollen dann dagegen weitgehend auch für die diversen assoziierten Projektpartner und ggf. andere Interessierte offen sein.

Bei Fragen bezügl. SKALB wenden Sie sich bitte an skalb(at)rrze.uni-erlangen.de.