El cluster usa SLURM como gestor de recursos.

• Para correr un trabajo, primero se necesita crear un script de lanzamiento que describa los recursos requeridos por el trabajo y las tareas que realiza.

• Para encolar un trabajo cuyo submit script es submit.sh, corra sbatch que luego de encolar el trabajo le devolverá un número que lo identifica.

$ sbatch submit.sh
Submitted batch job 38517

• Para eliminar un trabajo de la cola o cancelar su ejecución, utilice scancel y el identificador del trabajo.

$ scancel 38517

• Para ver todos los trabajos en las distintas colas de trabajos, utilice squeue. El programa muestra distinta información sobre cada trabajo:
  • PARTITION: La cola en la que está.
  • JOBID: El identificador.
  • PRIO: La prioridad para que tiene para ser lanzado.
  • NAME: El nombre.
  • USER: El usuario que lo encoló.
  • TIME: El tiempo que lleva ejecutando.
  • NO: La cantidad de nodos que se estima que va a ocupar o que ya ocupa.
  • CPU: La cantidad de cores totales que se estima que va a ocupar o que ya ocupa.
  • GRES: Los aceleradores que pidió.
  • NODELIST(REASON): Los nodos en los que está corriendo el trabajo, o la razón por la que no se está ejecutando todavía. Algunas razones comunes son:
    • (Resources): No hay recursos libres en el cluster para ejecutarlo.
    • (Priority): Hay trabajos con mayor prioridad esperando a ser ejecutados.
    • (AssociationJobLimit): El usuario ya excede la cantidad de trabajos máxima en ejecución simultánea.
    • (JobHeldUser): El usuario ha suspendido el trabajo.
    • (JobHeldAdmin): Un administrador ha suspendido el trabajo.
    • (launch failed requeued held): SLURM encontró un error al iniciar el trabajo y lo ha suspendido.

 $ squeue
 PARTITION   JOBID PRIO       NAME     USER ST       TIME NO CPU  GRES NODELIST(REASON)
 multi       55060 7353      seed1 usuario1 PD       0:00  4  80 (null (Resources)
 mono        55079 6659     e05.e2 usuario2 PD       0:00  1   8 gpu:0 (AssocMaxJobsLimit)
 multi       55081 6538       neb1 usuario3 PD       0:00  2  40 (null (Priority)
 gpu         55008 6281     br_190 usuario4 PD       0:00  1   1 gpu:1 (AssocMaxJobsLimit)
 multi       54915    0 Au3Ir5TiO2 usuario5 PD       0:00  2  40 (null (launch failed requeued held)
 multi       55059 7347      seed3 usuario1  R       9:39  4  80 (null mendieta[11-12,19-20]
 multi       54959 7167       neb2 usuario3  R 3-03:53:18  2  40 (null mendieta[13-14]
 mono        55073 7038     e03.e2 usuario2  R    3:25:40  1   8 gpu:0 mendieta01
 mono        55025 6777 e09.new.e2 usuario2  R 1-21:49:42  1   8 gpu:0 mendieta08
 gpu         55007 6113     br_170 usuario4  R    3:25:53  1  16 gpu:1 mendieta05
 gpu         55005 5718     br_220 usuario4  R 3-18:08:02  1  16 gpu:1 mendieta02
 phi         55048    2     Alpha2 usuario6  R 3-09:12:45  1 228 (null mendieta17-mic0
 phi         55138    1       M283 usuario6  R   10:30:57  1 228 (null mendieta11-mic0

Un script de lanzamiento es un archivo que contiene:

• Lineas #SBATCH que describen los recursos que requiere un trabajo. Cuando se encuentra una línea de la sección siguiente, el resto de las líneas #SBATCH son ignoradas.

• El script para un shell UNIX (generalmente bash) propiamente dicho, que enumera las tareas a ejecutar cuando el cluster corre el trabajo.

La primera línea del archivo siempre debe indicar el shell para el que está escrito el script:

#!/bin/bash

El trabajo debe tener un nombre, que le sirva para identificarlo.

#SBATCH --job-name=nombre

Se le puede pedir al manejador de recursos que notifique por email al usuario sobre actualizaciones del estado de su trabajo.

#SBATCH --mail-type=ALL

#SBATCH --mail-user=direccion@de.email

Luego se deben enumerar los recursos requeridos por el trabajo.

Los distintos recursos de cómputo de los clusters del CCAD son accesibles a través de colas de trabajos, que son líneas de espera en las que trabajos con requerimientos similares se ubican hasta que les toque su turno y los recursos requeridos estén disponibles. Las colas disponibles y sus límites dependen del cluster:

• Colas de Mendieta

Para seleccionar la cola C:

#SBATCH --partition=C

Cada trabajo en ejecución consiste en una cantidad de procesos corriendo simultáneamente.

• Los procesos se distribuyen en uno o más nodos de cómputo (computadoras del cluster) según la disponibilidad de recursos.
• En las aplicaciones MPI, la cantidad de procesos es el parámetro -np pasado a mpirun o mpiexec.
• En el script, la cantidad P de procesos del trabajo se define con la línea:

#SBATCH --ntasks=P

• Alternativamente se puede pedir una distribución exacta y equitativa de procesos entre nodos del cluster, especificando explícitamente la cantidad de nodos N y cantidad de procesos por nodo PPN:

#SBATCH --nodes=N
#SBATCH --ntasks-per-node=PPN

Cada proceso del trabajo puede dividirse en más de un hilo de ejecución. * En las aplicaciones OpenMP, la cantidad de hilos por proceso está definida en la variable de entorno OMP_NUM_THREADS. * A cada hilo del trabajo se le asigna un core de algún procesador del cluster. * En el script, la cantidad H de hilos por proceso se define con la línea:

#SBATCH --cpus-per-task=H

Entonces, si un trabajo pide P procesos con H hilos cada uno, requerirá P * H cores para correr.

Es necesario especificar el tiempo máximo de ejecución del trabajo. Si el trabajo se excede de este tiempo, el manejador de recursos mata los procesos en ejecución y cancela el trabajo. Este tiempo debería ser lo más cercano posible al tiempo de ejecución real del trabajo. El formato del campo esdías-horas:minutos.

#SBATCH --time=dd-hh:mm

Algunos de los clusters del CCAD disponen de coprocesadores para cómputo (GPUs y Xeon Phi). Los aceleradores se piden por nodo, y son visibles a todos los procesos corriendo dentro del mismo nodo. Para pedir G GPUs por nodo:

#SBATCH --gres=gpu:G

Primero es necesario importar la configuración de las variables de entorno compartida por todos los usuarios:

. /etc/profile

Una vez cargado el entorno por defecto tenemos acceso al sistema de módulos, por lo que cargamos los requeridos por el programa a correr:

module load modulo/del/programa

Luego podemos configurar variables de entorno que afecten el funcionamiento de nuestro programa.

Un caso común es el de las aplicaciones OpenMP, que deben configurar la variable OMP_NUM_THREADS al mismo valor que fue dado en #SBATCH --cpus-per-task.

export OMP_NUM_THREADS=$SLURM_CPUS_PER_TASK

Finalmente se lanza el programa. Para esto se debe utilizar ''srun'', que suplanta la funcionalidad de mpirun o mpiexec lanzando tantos procesos como sean necesarios en los recursos asignados al trabajo.

srun programa

#!/bin/bash

### Configuración del trabajo

### Nombre de la tarea
#SBATCH --job-name=espresso

### Cola a usar (gpu, mono, multi)
#SBATCH --partition=multi

### Cantidad de nodos a usar
#SBATCH --nodes=1

### Cores a utilizar por nodo = procesos por nodo * cores por proceso
#SBATCH --ntasks-per-node=64
### Cores por proceso (para MPI+OpenMP)
#SBATCH --cpus-per-task=1

### Tiempo de ejecucion. Formato dias-horas:minutos.
### short:  <= 1 hora
### multi:  <= 2 días
#SBATCH --time 2-0:00

#---------------------------------------------------

# Script que se ejecuta al arrancar el trabajo

# Cargar el entorno del usuario incluyendo la funcionalidad de modules
# No tocar
. /etc/profile

# Configurar OpenMP y otras bibliotecas que usan threads
# usando los valores especificados arriba
export OMP_NUM_THREADS=$SLURM_CPUS_PER_TASK
export MKL_NUM_THREADS=$SLURM_CPUS_PER_TASK

# Cargar los módulos para la tarea
module load quantum-espresso/6.7

# Lanzar el programa
srun pw.x -nk 1 -inp input > output

#!/bin/bash
#SBATCH --job-name=gmx
#SBATCH --ntasks=1
#SBATCH --cpus-per-task=10
#SBATCH --gpus-per-task=1
#SBATCH --partition=multi

. /etc/profile
module load gromacs
srun gmx_mpi mdrun -nb gpu -pme gpu -bonded gpu -update gpu -ntomp ${SLURM_CPUS_PER_TASK} (...)

conda activate <env>
salloc -p multi -N 1 --gres=gpu:1
srun hostname  # <= NRO_NODO
srun jupyter notebook --no-browser --port 9999 --ip 0.0.0.0

y luego

ssh -L 9999:10.10.10.$NRO_NODO:9999 $USER@mendieta.ccad.unc.edu.ar

Una guía exaustiva sobre este tema fue elaborada por la usuaria Karen Palacio y puede ser consultada aqui.

¿Por qué SLURM no toma en cuenta el tiempo de ejecución solicitado?

En las nuevas versiones de SLURM todas las directivas del preámbulo se deben especificar en un solo bloque, es decir que apenas detecta un comando SLURM considera que llegó al final del preámbulo. Por ejemplo, el siguiente script considerará el tiempo de ejecución solicitado por el usuario, en este caso 7 días:

#!/bin/bash
#SBATCH --job-name=test
#SBATCH --partition=mono
#SBATCH --ntasks=4
#SBATCH --cpus-per-task=2
#SBATCH --time 7-0:00:00

Mientras que el siguiente script tomará como tiempo de ejecución aquel indicado en la configuración por defecto de la cola, porque la instrucción --time no va a ser tomada en consideración:

#!/bin/bash
#SBATCH --job-name=test
#SBATCH --partition=mono
#SBATCH --ntasks=4
#SBATCH --cpus-per-task=2

export MYVAR="Hello"
#SBATCH --time 7-0:00:00

¿Cómo sé si SLURM tomó en consideración todas las instrucciones especificadas en el preámbulo?

Es posible utilizar el comando scontrol para verificar que el gestor de recursos haya encolado el trabajo de acuerdo a lo solicitado en el preámbulo:

scontrol show job $JOBID 

Donde la variable $JOBID debe ser reemplazada por el numero del job.