Accesso []

Questa pagina è in sola lettura. Puoi visualizzare il sorgente, ma non puoi modificarlo. Contatta l'amministratore se pensi che ci sia un errore.
<html><center><b> <font face="Cursive" color="#606060" size="2">
Progetto HPC <em>- Calcolo Scientifico dell'Università e dell'INFN di Parma -</em>
<br><font size="5"> Guida Utente (Versione Slurm) </font></font> </b></center></html>
[[https://www.hpc.unipr.it/dokuwiki/doku.php?id=calcoloscientifico:guidautente_slurm_en|{{ :calcoloscientifico:english_flag.png?nolink&33 | Click here for english version}}]]

** [[ calcoloscientifico:progetto | Descrizione del Progetto  ]]  **


===== Accesso =====

Per poter accedere alle risorse occorre essere inseriti nel database LDAP del servizio HPC.
Le richieste di accesso o in generale di assistenza vanno inviate a es_calcolo@unipr.it.

Una volta abilitati l'accesso avviene via SSH sull'host di login

  ssh <nome.cognome>@login.hpc.unipr.it 

L'accesso con password è consentito solo all'interno della rete di Ateneo (160.78.0.0/16) e della rete del Gruppo Collegato INFN di Parma (192.135.11.0/24). Al di fuori di questo contesto è necessario utilizzare la [[http://noc.unipr.it/public/vpn/home|VPN]] di Ateneo oppure l'accesso con chiave pubblica.  

==== Accesso password-less tra i nodi ====

** Per utilizzare il cluster è necessario eliminare la necessità di utilizzare la password tra i nodi**, utilizzando l'autenticazione a chiave pubblica. Occorre generare su login.hpc.unipr.it la coppia di chiavi, senza passphrase,  e aggiungere la chiave pubblica nel file di autorizzazione (authorized_keys):

Generazione delle chiavi. Accettare i default premendo invio. 
  ssh-keygen -t rsa

Copia della chiave pubblica in authorized_keys:

  cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys

==== Accesso dall'esterno con chiave pubblica ====

Occorre generare la coppia di chiavi con il client SSH. La chiave privata dovrebbe essere protetta da una passphrase adeguata (non è obbligatorio ma è consigliato). La chiave pubblica deve
essere inserita tra le vostre chiavi autorizzate (.ssh/authorized_keys) sull'host di login.

Se utilizzate il client SSH per Windows **PuTTY** (http://www.putty.org) è
 necessario generare la coppia di chiavi pubblica e privata con PuTTYgen e salvarle su un file.
La chiave privata deve essere inserita nella configurazione di Putty (o WinSCP): 
  Configuration -> Connection -> SSH -> Auth -> Private key file for authentication
La chiave pubblica deve essere inserita nel file .ssh/authorized_keys di login.hpc.unipr.it

Link utili per la configurazione dei cliest SSH: [[ https://kb.iu.edu/d/aews | Linux, MacOS X, PuTTY ]], 
[[ https://kb.iu.edu/d/amzx | Windows SSH Secure Shell ]]

La chiave pubblica del client (esempio ''client_id_rsa.pub'') deve essere inserita
nel file ''~/.ssh/authorized_keys'' della macchina di login:

Copia della chiave pubblica in authorized_keys:

  cat client_id_rsa.pub >> ~/.ssh/authorized_keys

==== Trasferimento di file ====

SSH è l'unico protocollo per la comunicazione con l'esterno e può essere utilizzato anche per il trasferimento dei file. 
In ambiente unix-like (Linux, MacOS X) si possono usare i comandi scp o sftp.

In ambiente Windows il programma più utilizzato è WinSCP (https://winscp.net/eng/docs/lang:it). In fase di installazione di WinSCP è possibile importare i profili di Putty.

SSH può essere utilizzato anche per il mount di un file-system remoto utilizzando SshFS (vedi http://www.fis.unipr.it/dokuwiki/doku.php?id=calcoloscientifico:guidautente#sshfs)

===== Hardware =====

L'attuale cluster è composto dai nuovi nodi di calcolo e dai nodi del preesistente cluster di Fisica / INFN.

{{:calcoloscientifico:hpcschema2018.png?200|}}

**Nuovi nodi di calcolo**

  * Cluster1 ([[ https://ark.intel.com/products/91766/Intel-Xeon-Processor-E5-2683-v4-40M-Cache-2_10-GHz | BDW]])
    * 8 nodi con 2 Intel Xeon  E5-2683v4 (2x16 cores, 2.1GHz, 40MB smartcache),  128 GB RAM (E4)
    * 9 nodi con 2 Intel Xeon  E5-2680v4 (2x14 cores, 2.4GHz, 35MB smartcache),  128 GB RAM (DELL R730)
    * 1 nodo con 2 Intel Xeon  E5-2683v4 (2x16 cores, 2.1GHz, 40MB smartcache), 1024 GB RAM (E4 - FAT MEM)
    * 1 nodo con 4 Intel Xeon  E7-8880v4 (4x22 cores, 2.2GHz, 55MB smartcache),  512 GB RAM (HP - FAT CORES)

  * Cluster2 ([[http://www.nvidia.com/object/tesla-p100.html | GPU]])
    * 2 nodi con 2 Intel Xeon  E5-2683v4 (2x16 cores, 2.1GHz), 128 GB RAM, 7 GPU NVIDIA P100-PCIE-12GB (Pascal architecture).
  * Cluster3 ([[https://ark.intel.com/it/products/94035/Intel-Xeon-Phi-Processor-7250-16GB-1_40-GHz-68-core | KNL]])
    * 4 nodi con 1 Intel Xeon PHI 7250 (1x68 cores, 1.4GHz, 16GB MCDRAM), 192 GB RAM.

Dettaglio dei nodi:

[[ http://www.fis.unipr.it/dokuwiki/doku.php?id=calcoloscientifico:nodicalcolo | Elenco  ]]
-
[[  http://cm01.hpc.unipr.it/ganglia/ |  Utilizzo  ]]  (intranet)

Prestazioni di picco (doppia precisione):

  1 Nodo BDW -> 2x16 (cores) x 2.1 (GHz) x 16 (AVX2) = 1 TFlops, Max memory Bandwidth = 76.8 GB/s
  1 GPU P100 -> 4.7 TFlops
  1 nodo KNL -> 68 (cores) x 1.4 (GHz) x 32 (AVX512) = 3 TFlops, Max memory bandwidth = 115.2 GB/s 

** Interconnessione con [[https://www.intel.com/content/www/us/en/high-performance-computing-fabrics/omni-path-edge-switches-100-series.html | Intel OmniPath ]] **

Prestazioni di picco: 

  Bandwidth: 100 Gb/s, Latency: 100 ns.

**[[ calcoloscientifico:benchmarks | Benchmarks: IMB, NBODY, HPL]]**

===== Software =====

Il sistema operativo per tutte le tipologie di nodi è CentOS 7.X.

Ambiente Software (librerie, compilatori e tools): 
[[ http://www.hpc.unipr.it/dokuwiki/doku.php?id=calcoloscientifico:softwareapplicativo | Elenco ]]

Alcuni componenti software  devono essere caricati per poter essere utilizzati.

Per elencare i moduli disponibili:

  module avail
  
Per caricare / scaricare un modulo (esempio intel):

  module load   intel 
  module unload intel
  
Per elencare i moduli caricati:

  module list

===== Storage =====

Il nodo di login e i nodi di calcolo condividono le seguenti aree di storage:

^ Mount Point  ^ Env. Var.   ^    Backup  ^ Quota (3)  ^  Nota  ^ Supporto ^
^ /hpc/home      | $HOME    |  si   | 50 GB  |  Programmi e dati  |  SAN  |  
^ /hpc/group      | $GROUP   |  si   | 100 GB  |  Programmi e dati  |  SAN  |  
^ /hpc/scratch   | $SCRATCH |  no  | 10M files,  max 1 mese (non attivo)  |  Dati run-time   |  SAN  | 
^ /hpc/archive   | $ARCHIVE    |   no   |     |  Archivio  |  NAS/tape/cloud (1)  |  
^ /hpc/share  |     |      |     |  Software applicativo e database |  SAN  |  

<note>

(1) Archive: attivato nel 2019\\
</note>

[[ http://www.fis.unipr.it/dokuwiki/doku.php?id=calcoloscientifico:priv:cluster:storage | Area privata ]]



===== Acknowledgement=====
<note>

Ricordarsi di citare  il progetto nelle pubblicazioni  tra gli  Acknowlegements:

**// This research benefits from the HPC (High Performance Computing) facility of the University of Parma, Italy //**

Old sentence, do no use:
//Part of this research is conducted using the High Performance Computing (HPC) facility of the University of Parma.  //


Gli autori sono pregati di comunicare i riferimenti delle pubblicazioni , che verranno elencati sul sito.
</note>


===== Sottomissione dei job con Slurm - Workload Manager=====

Le code sono gestite con [[ https://slurm.schedmd.com | Slurm - WM ]].
I job vengono sottomessi sulla coda di routing e smistati automaticamente su una coda di esecuzione in base alle risorse richieste.


==== Code Batch ====

<note warning>
Work in progress
</note>

La sottomissione avviene sulla coda di routing "route". Il job verra' automaticamente riaccodato su una coda di esecuzione in base ai requisiti specificati nello script di sottomissione.  

^ Nome     ^  tipo      ^ Cluster ^ cores   ^ Max Walltime ^ Max Running ^ Priority ^ Mem ^ 
| route    | routing    |  coda di default  ||||||
| debug    | esecuzione | BDW     | min=1 max=32     | 00:30:00  | 6  | 70 | max=64 GB   |
| prod     | esecuzione | BDW     | min=2 max=64     | 48:00:00  | 8  | 50 | max=64 GB   |
| bigprod  | esecuzione | BDW     | min=2 max=64     | 168:00:00 | 2  | 30 | max=64 GB   |
| serial   | esecuzione | BDW     | max=1            | 48:00:00  | 12 | 30 | max=64 GB   |
| fat      | esecuzione | BDW FAT | max=1            | 48:00:00  | 12 | 30 |             |

 ===== nuova tabella temporanea =====

^Cluster  ^Partizione  ^QoS            ^Core           ^Max Walltime       ^Max Running  ^Max Memory ^Priority ^
| BDW     | bdw        | ....          | ......        | 0-00:30:00 minuti |             |           |
|         |            |               |               |                   |
| KNL     | knl        | ....          | ......        | 0-00:30:00 minuti |
|         |            |               |               |                   |
| GPU     | gpu        | ....          | ......        | 0-00:30:00 minuti |
|         |            |               |               |                   |
|         | mngt       | riservato     |               |                   |
|         |            |               |               |                   |  
|         | mngt       | riservato     |               |                   |
Area privata 
[[calcoloscientifico:priv:cluster:pbspro| PBSpro]] -
[[calcoloscientifico:priv:cluster:slurm|  Slurm]]

==== Comandi utili ====  == __modifiche in corso__ ==

Visualizza in forma sintetica lo stato delle code:

<code>
sinfo
</code>

Visualizza in dettaglio lo stato delle singole code:

<code>
scontrol show partition
</code>

Elenco dei nodi e loro stato:

<code>
sinfo -all
</code>

Per la sottomissione di un job:

<code>
srun <opzioni>                # modalità interattiva
sbatch <opzioni> script.sh    # modalità batch
</code>

Visualizza i job in coda:

<code>
squeue
</code>

Visualizzare il credito ore residuo per account oppure utente:
<code>
module load perl                                       # carica il modulo per il linguaggio perl
sbalance --account <nome account> --user <nome utente> # visualizza il credito disponibile e residuo
</code>
<note>
Il risultato viene espresso con l'unità di misura kSU: 1 SU (service units) = 1 ora di walltime in un core-cpu,
quindi per esempio 1 kSU corrisponde a 1000 ore-cpu.
</note>
=== Opzioni principali ===

**-p <nomeNodo/partizione>** dove p indica la selezione del tipo di nodo/partizione (bdw | knl | gpu | fat | std)

È l'opzione più importante poiché permette di indicare le risorse richieste:
  * **-Nx**: dove x sta per il numero di chunk (gruppi di core sullo stesso nodo)
  * **-ny**: dove y sta per il numero di core per nodo (default 1)
  * **--gres=gpu:tesla:X**: dove X sta per il numero di GPU per nodo (risorse consumabili)
  * ** --mem=<size{units}>**: memoria richiesta per nodo 
  * **--ntasks=Y**: dove Y sta per il numero di processi MPI per nodo
  * **--cpus-per-task=Z**: dove Z sta per il numero di thread OpenMP per processo
  * **--exclusive**: alloca gli host in modo esclusivo (non condivisi con altri job)
  * ** -q, --qos=<qos>**: scelta del QoS

Il cluster di default è std (standard) che sul cluster nuovo può essere bdw o fat.

Esempi di selezione delle risorse:

<code>-p nomecluster_partizione -Nx -ny </code> 
dove x = chunk e y = core

Esempio:
<code>-p bdw -N1 -n2</code>

**--time <day-hour:minute:second>**
Tempo massimo di esecuzione del job. Questo dato seleziona la coda da utilizzare. Default: 0-00:72:00

Esempio per il valore 30 minuti:

<code>--time 0-00:30:00</code>

**-A <account name>**

consente di specificare l'account (OBBLIGATORIO!) a cui addebitare l'utilizzo delle risorse. Esempi
<code>
-A nome.cognome 
-A G_HPC17A
</code>

**--account=<nomeaccount>**

consente di eseguire il job utilizzando il gruppo secondario specificato. 

**-oe**

redirige lo standard error sullo standard output.

**--mail-user=<indirizzo mail>**

L'opzione --mail-user permette di indicare uno o più indirizzi e-mail, separati da virgola, che riceveranno le notifiche del gestore di code.

<note>
Se l'opzione non viene specificata, il sistema di code spedisce le notifiche all'indirizzo e-mail di Ateneo dell'utente. Nel caso degli ospiti le notifiche vengono inviate all'indirizzo e-mail personale dell'utente.
</note>

**--mail-type=<FAIL, BEGIN, END, NONE, ALL>**

L'opzione --mail-type permette di indicare gli eventi che generano l'invio della notifica:
  * **FAIL**: notifica in caso di interruzione del job
  * **BEGIN**: notifica all'avvio del job
  * **END**: notifica alla fine del job
  * **NONE**: nessuna notifica
  * **ALL**: tutte le possibile notifiche

<note>
Se l'opzione non viene specificata, il sistema di code spedisce le notifiche solo in caso di interruzione del job.
</note>

Esempio:

<code>
--mail-user=mario.rossi@unipr.it
--mail-type=BEGIN,END
</code>
===== Job interattivi =====

==== DA CONTINUARE E RIVEDERE ====

Per verificare l'elenco delle risorse assegnate si può utilizzare la sottomissione interattiva con opzione -I.
Una volta entrati in modo interattivo il comando **cat $SLURM_JOB_NODELIST** visualizza l'elenco delle risorse assegnate.
Il comando **squeue -al**  lista maggiori dettagli riguardo le risorse assegnate.

<code bash>
srun -N <numero di nodi> -n <numero cpu> -q <QOS> -C <tipo di nodo> -t <wall time> -L <file system>
cat $SLURM_JOB_NODELIST
scontrol show job <jobID>
exit
</code>

Esempi:

<code bash>
# 1 gruppo (chunk) di 2 CPU tipo BDW e file system Scratch
srun -N1 -n2 -p bdw -L SCRATCH

# 2 chunk da 2 CPU di tipo KNL e file system Scratch (possono stare sullo stesso nodo)
srun -N2 -n2 -p knl -L SCRATCH

# I chunk devono stare su nodi diversi
srun -N2 -n2 -p knl --scatter

# 1 chunk con 2 GPU sul cluster GPU
srun -N1 -p gpu --gres=gpu:2 -L SCRATCH

# 2 chunk ciascuno con 2 GPU su nodi diversi
srun -N2 --gres=gpu:2 -p gpu --scatter

# --ntask=Y dice a MPI quanti processi devono essere attivati per ogni chunk
srun -N2 -n1 –ntasks=1: -p bdw
</code>

===== Batch job ===== ====SLURM FATTO =====

Occorre creare uno shell script che include le opzioni SLURM e i comandi che devono essere eseguiti sui nodi.

per sottomettere il job e relativo addebito di risorse:

  sbatch -A <nome account> scriptname.sh

Ad ogni job viene assegnato un identificativo numerico univoco  <Job Id>.

Al termine dell'esecuzione verranno creati i due file contenenti stdout e stderr nella directory da cui è stato sottomesso il job.

Per default i due file prendono il nome dello script con una estensione aggiuntiva:

  Stdout: <script.sh>.o<job id> 
  Stderr: <script.sh>.e<job id>

==== Job seriali, compilatore GNU ==== ==== SLURM FATTO ====

Compilazione dell'esempio mm.c per il calcolo del  prodotto di due matrici:

  cp /hpc/share/samples/serial/mm.* .
  g++ mm.cpp -o mm

Script ''mm.bash'' per la sottomissione dell'eseguibile seriale ''mm'':

<code bash>

#!/bin/bash

# Richiedi un chunk con 1 CPU
#SBATCH -p bdw -N1 -n32

# Dichiara che il job durerà al massimo 30 minuti (giorni-ore:minuti:secondi)
#SBATCH --time 0-00:30:00

#stampa il nome del nodo assegnato
cat $SLURM_JOB_NODELIST

# Entra nella directory che contiene lo script
cd "$SLURM_SUBMIT_DIR"

#esegui il programma
./mm

</code>

Sottomissione:

  sbatch -A <nome account> mm.bash

Visualizza  <job id> e lo stato:
  squeue

Per cancellare eventualmente il job in esecuzione:

  scancel <Job id>

==== Job seriali, compilatore Intel ==== ==== FATTO SLURM ====

Compilazione dell'esempio cpi_mc.c per il calcolo di Pi Greco:

  cp /hpc/share/samples/serial/cpi/cpi_mc.c .
  module load intel
  icc cpi_mc.c -o cpi_mc_int

Script ''cpi_mc.bash'' per la sottomissione dell'eseguibile seriale ''cpi_mc_int'':

<code bash>
#!/bin/bash

#stampa il nome del nodo assegnato
cat $SLURM_JOB_NODELIST

#carica il modulo del compilatore Intel
module load intel

# Entra nella directory che contiene lo script
cd "$SLURM_SUBMIT_DIR"

#esegui il programma

N=10000000
./cpi_mc_int  -n $N

</code>

Sottomissione:

  sbatch -A <nome account> cpi_mc.bash

==== Job seriali, compilatore PGI ==== ==== SLURM FATTO ====

Compilazione dell'esempio cpi_sqrt.c per il calcolo di Pi Greco:

  cp /hpc/share/samples/serial/cpi/cpi_sqrt.c .
  module load pgi
  pgcc cpi_sqrt.c -o cpi_sqrt_pgi

Script ''cpi_sqrt_pgi.bash'' per la sottomissione dell'eseguibile seriale ''cpi_sqrt_pgi'':

<code bash>

#!/bin/bash

# Opzioni SLURM di default. Si possono omettere
#SBATCH -p bdw -N1 -n32
#SBATCH --time 0-00:30:00

# Stampa il nome del nodo assegnato
cat $SLURM_JOB_NODELIST

module load pgi
# Entra nella directory che contiene lo script
cd "$SLURM_SUBMIT_DIR"

N=10000000

./cpi_sqrt_pgi -n $N

</code>

  sbatch -A <nome account> cpi_sqrt_pgi.bash

==== Job OpenMP con GNU 4.8 ==== ==== SLURM FATTO ====

  cp /hpc/share/samples/omp/omp_hello.c .
  gcc -fopenmp omp_hello.c -o omp_hello

Script ''omp_hello.bash'' con la richiesta di 32 CPU in uso esclusivo.

<code bash>

#!/bin/bash

#SBATCH -p bdw -N1 -n32
#SBATCH --exclusive
#SBATCH --time 0-00:30:00

#Unisci strerr con stdout
#SBATCH -oe

cat $SLURM_JOB_NODELIST

echo  #OMP_NUM_THREADS : $OMP_NUM_THREADS

cd "$SLURM_SUBMIT_DIR"
./omp_hello

</code>

==== Job OpenMP con Intel ==== ==== SLURM FATTO ====

  module load intel 
  cp /hpc/share/samples/omp/mm/omp_mm.cpp .


Script ''mm_omp.bash'' con la richiesta di 1 nodo intero con almeno 32 core:

<code bash>
#!/bin/bash

#SBATCH -p bdw -N1 -n32
#SBATCH --time 0-00:30:00
#SBATCH -oe

#SBATCH --account=<account>

cat $SLURM_JOB_NODELIST
cd "$SLURM_SUBMIT_DIR"

module load intel
icpc -qopenmp omp_mm.cpp -o omp_mm

# Per variare il numero di threads:
export OMP_NUM_THREADS=8

echo  OMP_NUM_THREADS : $OMP_NUM_THREADS

./omp_mm

</code>

==== Job OpenMP con PGI ==== ===== FATTO SLURM ====

  cp /hpc/share/samples/omp/mm/omp_mm.cpp .

Script ''omp_mm_pgi.bash''. Il cluster BDW è composto da nodi con 32 cores. 
La variabile OMP_NUM_THREADS è per default pari al numero di core. Se vogliamo un numero di thread diverso lo possiamo indicare nella riga --cpus-per-task

<code bash>
#!/bin/sh

#SBATCH -p bdw -N1 -n32
#SBATCH --cpus-per-task=4
#SBATCH --time 0-00:30:00
#SBATCH -oe

cat $SLURM_JOB_NODELIST
cd "$SLURM_SUBMIT_DIR"

module load pgi

pgc++ -mp omp_mm.cpp -o omp_mm_pgi

echo  OMP_NUM_THREADS : $OMP_NUM_THREADS

./omp_mm_pgi


</code>


  sbatch -A <nome account> omp_mm_pgi.bash

==== Job OpenMP con GNU 5.4 ==== ====SLURM FATTO ====

  cp /hpc/share/samples/omp/cpi/* .

  sbatch -A <nome account> cpi2_omp.bash

  python cpi2_omp.py

==== Job MPI, GNU OpenMPI ==== ==== SLURM FATTO ====

  module load gnu openmpi
  cp /hpc/share/samples/mpi/mpi_hello.c .
  mpicc mpi_hello.c -o mpi_hello

Script ''mpi_hello.sh '' per l'utilizzo della versione GNU OpenMPI:

<code bash>
#!/bin/bash

# 4 chunk da 16 CPU ciascuno. Esegui un processo MPI per ogni CPU
#SBATCH -p bdw -N4 -n16
#SBATCH -n 16
#SBATCH --time 0-00:30:00
#SBATCH -oe

echo "### SLURM_JOB_NODELIST ###"
cat $SLURM_JOB_NODELIST
echo "####################"

module load gnu openmpi

cd "$SLURM_SUBMIT_DIR"
mpirun  mpi_hello


</code>

  sbatch -A <nome account> mpi_hello.bash
==== Job MPI con Intel MPI ==== ==== SLURM FATTO ====

  module load intel intelmpi
  which mpicc
   
  cp /hpc/share/samples/mpi/mpi_mm.c .
  mpicc mpi_mm.c -o mpi_mm_int

Script ''mpi_mm_int.sh '' per l'utilizzo di Intel MPI:

<code bash>

#!/bin/sh

# 4 chunk da 16 CPU ciascuno. Esegui un processo MPI per ogni CPU
#SBATCH -p bdw -N4 -n16
#SBATCH -n 16
#SBATCH --time 0-00:30:00
#SBATCH -oe

echo "### SLURM_JOB_NODELIST ###"
cat $SLURM_JOB_NODELIST
echo "####################"

module load intel intelmpi

cd "$SLURM_SUBMIT_DIR"
mpirun  mpi_mm_int

</code>

==== Job MPI con PGI ==== ==== SLURM FATTO ====

  module load pgi openmpi
  which mpicc 
  
  cp /hpc/share/samples/mpi/mpi_hello.c .
  mpicc mpi_hello.c -o mpi_hello_pgi

Script ''mpi_hello_pgi.sh '' per l'utilizzo di openmpi di PGI:

<code bash>


#!/bin/sh

#SBATCH -p bdw -N4 -n16
#SBATCH --time 0-00:30:00
#SBATCH -oe

echo "### SLURM_JOB_NODELIST ###"
cat $SLURM_JOB_NODELIST
echo "####################"

NPUSER=$(cat $SLURM_JOB_NODELIST | wc -l)

module load cuda pgi openmpi

cd "$SLURM_SUBMIT_DIR"
mpirun -hostfile $SLURM_JOB_NODELIST --npernode 1  mpi_hello_pgi
</code>

==== Job MPI + OpenMP con GNU OpenMPI ==== ==== SLURM FATTO ====

<code>
module load gnu openmpi
cp -p /hpc/share/samples/mpi+omp/mpiomp_hello.c .
mpicc -fopenmp mpiomp_hello.c -o mpiomp_hello_gnu
</code>

Script mpiomp_hello_gnu per l'utilizzo di OpenMPI di PGI:

<code bash >

#!/bin/sh

# 4 chunk da 16 CPU ciascuno, 1 processo MPI per ogni chunk, 16 thread OpenMP per processo
#SBATCH -p bdw -N4 -n16
#SBATCH -n 4
#SBATCH --cpus-per-task=16      # Numero di threads OpenMP per ogni processo MPI
#SBATCH --time 0-00:30:00
#SBATCH -oe

echo "### SLURM_JOB_NODELIST ###"
cat $SLURM_JOB_NODELIST
echo "####################"

module load gnu openmpi

cd "$SLURM_SUBMIT_DIR"
mpirun mpiomp_hello_gnu

</code>
==== Job MPI + OpenMP con Intel MPI  ==== ==== SLURM FATTO ====

<code>
module load intel intelmpi
cp /hpc/share/samples/mpi+omp/mpiomp-hello.c .
mpicc -qopenmp mpiomp_hello.c -o mpiomp_hello_int
</code>

<code bash >

#!/bin/sh

# 4 chunk da 16 CPU ciascuno, 1 processo MPI per ogni chunk, 16 thread OpenMP per processo
#SBATCH -p bdw -N4 -n16
#SBATCH -n 1
#SBATCH --cpus-per-task=16      # Numero di threads OpenMP per ogni processo MPI
#SBATCH --time 0-00:30:00
#SBATCH -oe

echo "### SLURM_JOB_NODELIST ###"
cat $SLURM_JOB_NODELIST
echo "####################"

module load intel intelmpi

cd "$SLURM_SUBMIT_DIR"
mpirun mpiomp_hello_int

</code>

===== Utilizzo del cluster KNL  =====  ==== SLURM FATTO SE VIENE ATTIVATO KNL ====

Il compilatore da utilizzare è intel.

La selezione del cluster KNL avviene specificando -p knl come risorsa richiesta. 

Il massimo numero di core (ncpus) selezionabili per nodo è 68. 
Ogni core fisico include 4 core virtuali  con tecnologia hyperthreading, per un totale di 272  per nodo.


<code bash>

#!/bin/sh

# 4 nodi interi. Esegui un processo MPI per ogni nodo e 128 thread per processo

#SBATCH -p knl -N4 -n1
#SBATCH -n 4
#SBATCH --cpus-per-task=128      # Numero di threads OpenMP per ogni processo MPI
#SBATCH --time 0-00:30:00
#SBATCH -oe

#SBATCH -t 0-00:30:00
#SBATCH -oe

echo "### SLURM_JOB_NODELIST ###"
cat $SLURM_JOB_NODELIST
echo "####################"

module load intel intelmpi
 
cd "$SLURM_SUBMIT_DIR"

cp /hpc/share/samples/mpi+omp/mpiomp_hello.c .
mpicc -qopenmp mpiomp_hello.c -o mpiomp_hello_knl
mpirun  mpiomp_hello_knl

</code>

===== Utilizzo del cluster GPU  ===== == SLURM FATTO MA DA RIVEDERE BENE ==

Il cluster GPU è costituito da 2 macchine con 7 GPU ciascuna. Le GPU di una singola macchina sono identificate da un ID numerico intero che va da 0 a 6.

Il compilatore da utilizzare è nvcc:

[[http://docs.nvidia.com/cuda/cuda-compiler-driver-nvcc/index.html|NVIDIA CUDA Compiler]]

Esempio di compilazione:

<code bash>
cp /hpc/share/samples/cuda/hello_cuda.cu .
module load cuda
nvcc hello_cuda.cu -o hello_cuda
</code>

La selezione del cluster GPU avviene specificando -p gpu e --gres=gpu:<1-5> tra le risorse richieste.

Esempio di sottomissione su 1 delle 5 GPU disponibili in un singolo nodo del cluster GPU:

<code bash>

#!/bin/sh

# 1 nodo con 1 GPU

#SBATCH -p gpu -N1
#SBATCH --gres=gpu:tesla:1
#SBATCH --time 0-00:30:00
#SBATCH -oe


echo "### SLURM_JOB_NODEFILE ###"
cat $SLURM_JOB_NODEFILE
echo "####################"

module load cuda

cd "$SLURM_SUBMIT_DIR"
./hello_cuda

</code>

Esempio di sottomissione del benchmark N-BODY su tutte e 5 le GPU disponibili in un singolo nodo del cluster GPU:

<code bash>

#!/bin/sh

# 1 nodo con 5 GPU

#SBATCH -p gpu -N1
#SBATCH --gres=gpu:tesla:5
#SBATCH --time 0-00:30:00
#SBATCH -oe

echo "### SLURM_JOB_NODEFILE ###"
cat $SLURM_JOB_NODEFILE
echo "####################"

module load cuda

cd "$SLURM_SUBMIT_DIR"
/hpc/share/tools/cuda-9.0.176/samples/5_Simulations/nbody/nbody -benchmark -numbodies 1024000 -numdevices=5
</code>

Nel caso di N-BODY il numero di GPU da utilizzare viene specificato utilizzando l'opzione -numdevices (il valore specificato non deve superare quello del numero di GPU richieste con l'opzione ngpus).

In generale gli ID delle GPU da utilizzare vengono ricavati dal valore della variabile d'ambiente CUDA_VISIBLE_DEVICES.

Nel caso dell'ultimo esempio si ha

<code>
CUDA_VISIBLE_DEVICES=0,1,2,3,4
</code>

 
===== Lavoro di gruppo ===== ==== SLURM FATTO ====

Per condividere i file tra i membri di un gruppo è necessario distinguere il tipo di attivita':

Nella **modalità interattiva** sul nodo di login il comando ''newgrp'' modifica il gruppo primario e  i permessi dei nuovi file:

  newgrp <nomegruppo>

Il comando newgrp sul cluster HPC esegue automaticamente anche il comando per entrare nella directory di gruppo ( /hpc/group/<nomegruppo> ) : 

  cd "$GROUP" 

Nella **modalità Batch** occorre indicare il gruppo da utilizzare con la seguente direttiva:  

  #SBATCH --account=<account>

===== Scaling test ===== ==== SLURM FATTO ====

Per lanciare in sequenza una batteria di run in serie nello stesso job, 
 ad esempio per verificare lo scaling di un algoritmo:

  cp /hpc/share/samples/serial/cpi/cpi_mc.c .
  gcc cpi_mc.c o cpi_mc

Script launch_single.sh
<code>
#!/bin/bash

cd "$SLURM_SUBMIT_DIR"

for N in $(seq 1000000 1000000 10000000)
do
CMD="./cpi_mc -n $N"
echo "# $CMD"
eval $CMD  >> cpi_mc_scaling.dat
done

</code>

  sbatch -A <nome account> launch_single.sh
  
Gli output dei diversi run vengono scritti nel file cpi_mc_scaling.dat.

Per generare un plot dello scaling possiamo utilizzare la libreria matplotlib di python:

  cp /hpc/share/samples/serial/cpi/cpi_mc_scaling.py .

  python cpi_mc_scaling.py

===== Job Array  =====  === SLURM FATTO ===

Utilizzando un'unico script SLURM è possibile sottomettere una batteria di Job, che possono essere eseguiti in parallelo,  specificando un parametro numerico diverso per ogni job sottomesso. 

L'opzione -J consente di specificare la sequenza numerica dei parametri. Ad ogni lancio il valore del 
parametro è contenuto nella variabile $SLURM_ARRAY_TASK_ID

Esempio:

Lancia N job per il calcolo di Pi greco con un numero di intervalli crescente da 100000 a 900000 con incremento di 10000:

  cp /hpc/share/samples/serial/cpi/cpi_mc .
  gcc cpi_mc.c o cpi_mc


Script slurm_launch_parallel.sh
<code bash>
#!/bin/sh

#SBATCH -J 100000-900000:10000
cd "SLURM_SUBMIT_DIR"
CMD="./cpi_mc -n ${SLURM_ARRAY_TASK_ID}"
echo "# $CMD"
eval $CMD
</code>

  sbatch -A <nome account> slurm_launch_parallel.sh
  
Riunisci gli output:

  grep -vh '^#' slurm_launch_parallel.sh.o*.*

===== Job MATLAB ===== === SLURM FATTO ===

[[https://www.mir.wustl.edu/Portals/0/Documents/Uploads/CHPC/PCT_Masterclass.pdf|Parallel Computing with MATLAB]]

== Esecuzione di un programma seriale MATLAB ==

  cp /hpc/share/samples/matlab/pi_greco.m .

Script matlab.sh

<code bash>

#!/bin/sh


#SBATCH -p bdw -N1 -n1
#SBATCH --time 0-00:30:00

cd "$SLURM_SUBMIT_DIR"

module load matlab

matlab -nodisplay -r pi_greco

</code>

  sbatch -A <nome account> matlab.sh

== Esecuzione di un job parallelo con MATLAB ==

  cp /hpc/share/samples/matlab/pi_greco_parallel.m .

Script ''matlab_parallel.sh''. //**La versione di Matlab installata sul cluster consente l'utilizzo massimo di  cores dello stesso nodo.**// qua bisogna specificare quanti core utilizzabili...ho messo 4 per il momento

<code bash>

#!/bin/sh


#SBATCH -p bdw -N1 -n4
#SBATCH --time 0-00:30:00

cd "$SLURM_SUBMIT_DIR"

module load matlab

matlab -nodisplay -r pi_greco_parallel

</code>

  sbatch -A <nome account> matlab_parallel.sh

== Esecuzione di un programma MATLAB su GPU == 

  cp /hpc/share/samples/matlab/matlabGPU.m . # ---- da fare ---- 

Script matlabGPU.sh

<code bash>

#!/bin/bash

#SBATCH -p bdw -N1 -n1
#SBATCH --gres=gpu:tesla:1
#SBATCH --time 0-00:30:00

cd "$SLURM_SUBMIT_DIR"

module load matlab cuda

matlab -nodisplay -r matlabGPU.m

</code>

   sbatch -A <nome account> matlabGPU.sh

===== Job MPI Crystal14 ===== === CARTELLA DA CREARE E SCRIPT DA PROVARE ===

Script ''crystal14.sh'' per la sottomissione della versione MPI di Crystal14. Richiede 4 nodi da 8 core ed avvia 8 processi MPI per nodo:

<code bash>
#!/bin/sh

#SBATCH --job-name="crystal14" #Nome del job
#SBATCH -p bdw -N4 -n8 #Richiesta risorse
#SBATCH -n8
#SBATCH --time 0-168:00:00

# input files directory
CRY14_INP_DIR='input'

# output files directory
CRY14_OUT_DIR='output'

# input files prefix
CRY14_INP_PREFIX='test'

# input wave function file prefix
CRY14_F9_PREFIX='test'

source /hpc/share/applications/crystal14

</code>

Si consiglia di creare una cartella per ogni simulazione. In ogni cartella deve essere presente una copia dello script ''crystal14.sh''.

<note>
Lo script contiene la definizione di quattro variabili:

  * **CRY14_INP_DIR**: il file o i file di input devono trovarsi nella sottocartella 'input' della cartella corrente. Per utilizzare la directory corrente commentare la riga con la definizione della variabile CRY14_INP_DIR. Per cambiare sottocartella modificare il valore della variabile CRY14_INP_DIR.
  * **CRY14_OUT_DIR**: i file di output verranno creati nella sottocartella 'output' della cartella corrente. Per utilizzare la directory corrente commentare la riga con la definizione della variabile CRY14_OUT_DIR. Per cambiare sottocartella modificare il valore della variabile CRY14_OUT_DIR.
  * **CRY14_INP_PREFIX**: il file o i file di input hanno un prefisso che deve coincidere con il valore della variabile CRY14_INP_PREFIX. La stringa 'test' è puramente indicativa e non corrisponde ad un caso reale.
  * **CRY14_F9_PREFIX**: il file di input, con estensione 'F9', è il risultato di una precedente elaborazione e deve coincidere con il valore della variabile CRY14_F9_PREFIX. La stringa 'test' è puramente indicativa e non corrisponde ad un caso reale.

Lo script ''crystal14.sh'' include, a sua volta, lo script di sistema ''/hpc/share/applications/crystal14''. Quest'ultimo non può essere modificato dall'utente.
</note>

== Sottomissione dello script di shell ==

Spostarsi nella cartella che contiene ''crystal14.sh'' e lanciare il comando seguente per sottomettere lo script al job scheduler:

<code>
sbatch ./crystal14.sh
</code>

== Analisi dei file prodotti da Crystal14 durante l'esecuzione del job ==

Durante l'esecuzione del job viene creata una cartella temporanea ''tmp'' che contiene i due file:

<code>
nodes.par
machines.LINUX
</code>

Il file ''nodes.par'' contiene i nomi dei nodi che partecipano al calcolo parallelo.

Il file ''machines.LINUX'' contiene i nomi dei nodi che partecipano al calcolo parallelo con una molteplicità pari al numero di processi MPI avviati sul nodo.

Per individuare le cartelle temporanee prodotte da Crystal14 durante l'esecuzione del job, lanciare il comando seguente direttamente dal nodo di login:

<code>
eval ls -d1 /hpc/node/wn{$(seq -s, 81 95)}/$USER/crystal/* 2>/dev/null
</code>

<note>
Fare attenzione perché il precedente comando contiene i nomi dei nodi di calcolo attualmente disponibili. Questo elenco ed il corrispondente comando potranno cambiare in futuro.
</note>

Per verificare il contenuto dei file prodotti da Crystal14 durante l'esecuzione del job, l'utente può spostarsi in una delle cartelle evidenziate dal precedente comando.

Al termine dell'esecuzione del job, i due file ''machines.LINUX'' e ''nodes.par'' vengono cancellati. La cartella temporanea ''tmp'' viene cancellata solo se è vuota.

Non è dunque necessario accedere con SSH ai nodi che partecipano all'elaborazione per verificare il contenuto dei file prodotti da Crystal14.

===== Job Gromacs ===== === INVARIATO ===

Per definire la variabile d'ambiente GMXLIB aggiungere le righe seguenti al file ''$HOME/.bash_profile'':

<code bash>
GMXLIB=$HOME/gromacs/top

export GMXLIB
</code>

<note>
Il percorso ''$HOME/gromacs/top'' è puramente indicativo. Modificatelo secondo le vostre preferenze.
</note>

==== Job Gromacs OpenMP ==== === SLURM FATTO ===

Script ''mdrun_omp.sh'' per richiedere in esclusiva un nodo con 32 core ed avviare 16 thread OpenMP:

<code bash>

#!/bin/sh

#SBATCH -p bdw -N1 -n32
#SBATCH --cpus-per-task=16      # Numero di threads OpenMP
#SBATCH --exclusive
#SBATCH --time 0-24:00:00

test "$SLURM_ENVIRONMENT" = 'SLURM_BATCH' || exit

cd "$SLURM_SUBMIT_DIR"

module load gnu openmpi
source '/hpc/share/applications/gromacs/5.1.4/mpi_bdw/bin/GMXRC'

gmx mdrun -s topology.tpr -pin on

</code>

<note>
In questo modo verrà avviato un solo processo MPI e si otterranno prestazioni non ottimali.
</note>

==== Job Gromacs MPI ed OpenMP ==== === SLURM FATTO ===

Script ''mdrun_mpi_omp.sh'' per richiedere in esclusiva un nodo con 32 core ed avviare 8 processi MPI (il numero di thread OpenMP verrà calcolato automanticamente):

<code bash>

#!/bin/sh

#SBATCH -p bdw -N2 -n32
#SBATCH -n 8
#SBATCH --exclusive
#SBATCH --time 0-24:00:00

test "$SLURM_ENVIRONMENT" = 'SLURM_BATCH' || exit

cd "$SLURM_SUBMIT_DIR"

module load gnu openmpi
source '/hpc/share/applications/gromacs/5.1.4/mpi_bdw/bin/GMXRC'

NNODES=$(cat $SLURM_JOB_NODELIST | sort -u | wc -l)
NPUSER=$(cat $SLURM_JOB_NODEFILE | wc -l)
OMP_NUM_THREADS=$((OMP_NUM_THREADS/(NPUSER/NNODES)))

mpirun gmx mdrun -s topology.tpr -pin on

</code>

<note>
In questo modo verranno avviati più processi MPI e si otterranno prestazioni ottimali.
</note>

===== Job Abaqus =====

==== Job Abaqus MPI ==== === SLURM FATTO ===
 
Esempio di script ''abaqus.sh'' per eseguire Abacus su 1 nodo, 32 core, 0 GPU:

<code>

#!/bin/bash

# walltime -t / --time : tempo di esecuzione stimato, max 240 ore (meglio una stima per eccesso che effettiva)

#SBATCH -p bdw -N1 -n32
#SBATCH --time 0-240:00:00 
#oppure --time 10-00:00:00

cat $SLURM_JOB_NODELIST

# Moduli necessari per l'esecuzione di Abacus
module load gnu intel openmpi

cd "$SLURM_SUBMIT_DIR"

abaqus j=testverita cpus=32
# j= nomefile.inp

</code>
==== Job Abaqus MPI con GPU ==== ==== SLURM FATTO SE ATTIVATO CLUSTER GPU ??? ====

Esempio di script ''abaqus-gpu.sh'' per eseguire Abacus su 1 nodo, 6 core, 1 GPU:

<code>
#!/bin/bash

# walltime -t : tempo di esecuzione stimato, max 240 ore (meglio una stima di poco superiore a effettiva)

#SBATCH -p gpu -N1 -n6
#SBATCH --gres=gpu:tesla:1
#SBATCH --time 0-00:30:00

cat $SLURM_JOB_NODELIST

# Moduli necessari per l'esecuzione di Abacus
module load gnu intel openmpi cuda

cd "$SLURM_SUBMIT_DIR"

abaqus j=testverita cpus=6 gpus=1
# j= nomefile.inp

</code>

===== SSHFS ===== === DA FARE ===

Per scambiare dati con una macchina remota su cui è installato un server ssh è possibile utilizzare [[ https://wiki.archlinux.org/index.php/Sshfs | SSHFS ]].

SSHFS è un file-system per sistemi operativi Unix-like (MacOsX, Linux, BDS). Questo file system permette di montare in locale una cartella posizionata su un host in cui gira SSH server. Questo software implementa il modulo del Kernel FUSE.

Attualmente è installato solo su login.pr.infn.it. In alternativa può essere installato sulla macchina linux remota per accedere ai propri dati sul cluster.

Per utilizzarlo:

<code>
mkdir remote # creiamo il mount-point 
sshfs <remote-user>@<remote-host>:<remote-dir> remote # mount del file-system remoto 
df -h # vedi i file-system montati 
ls remote/ 
fusermount -u remote # smonta il file-system 
</code>

===== VTune =====

VTune e' un perfomance profiler di Intel ed e' disponibile sul cluster HPC. 

Informazioni generali di Intel : https://software.intel.com/en-us/get-started-with-vtune-linux-os


Guida locale [[vtune]] (work in progress)
===== Guide CINECA =====

  * {{:calcoloscientifico:hpc-access.pdf| Access to HPC resources in Italy and Europe }}  
  * [[https://wiki.u-gov.it/confluence/display/SCAIUS/UG3.1%3A+MARCONI+UserGuide | Marconi UserGuide ]]
  * [[https://wiki.u-gov.it/confluence/display/SCAIUS/UG2.4%3A+Data+storage+and+FileSystems | Marconi storage]]
  * [[https://wiki.u-gov.it/confluence/display/SCAIUS/Migration+from+PBS+to+SLURM+@+Cineca | Migration from PBS to SLURM @ Cineca ]]

===== Altre risorse  =====

[[ https://hpc.llnl.gov/training/tutorials | LLNL HPC tutorials ]]