NLHPC - Contribuciones del usuario [es]

SISTEMA GESTOR DE RECURSOS

2024-05-03T13:58:02Z

Jmorales: /* Particiones SLURM */

== SLURM Workload Manager ==
Es un sistema de programación de trabajos y gestión de clústeres de código abierto, tolerante a fallas y altamente escalable para clústeres Linux grandes y pequeños.

Como administrador de carga de trabajo de clúster, Slurm tiene tres funciones clave. Primero, asigna acceso exclusivo y / o no exclusivo a los recursos (nodos de cómputo) a los usuarios durante un período de tiempo para que puedan realizar el trabajo. En segundo lugar, proporciona un marco para iniciar, ejecutar y monitorear el trabajo (normalmente un trabajo paralelo) en el conjunto de nodos asignados. Finalmente, arbitra la contención de recursos mediante la gestión de una cola de trabajo pendiente.

SLURM es el gestor de colas instalado en muchos de los súper computadores del [https://www.top500.org/ TOP500], y también en el clúster del NLHPC. Si Ud. quiere lanzar tareas dentro de Leftaru, debe hacerlo a través de Slurm.

== Conceptos clave ==
SLURM gestiona trabajos de usuario que tienen las siguientes características clave:

* Conjunto de recursos solicitados:
** Número de recursos informáticos: nodos (incluidas todas sus CPUs y núcleos) o CPUs (incluidos todos sus núcleos) o solo núcleos
** Cantidad de memoria: por nodo o por CPU (lógica)
** Tiempo necesario para que las tareas del usuario completen su trabajo
* Una partición de nodo solicitada (cola de trabajos)
* Un nivel de calidad de servicio (QoS) solicitado que otorga a los usuarios accesos específicos
* Una cuenta solicitada con recursos limitados

De manera predeterminada, los usuarios envían trabajos a una partición particular (marcada como tal para todos los usuarios) y bajo una cuenta particular (preestablecida por usuario).

== Particiones SLURM ==

<table class="wikitable" style="width: 60%;">
<tr>
<td><b>Nombre Particion</b></td>
<td><b>Nodos</b></td>
<td><b>CPUs</b></td>
<td><b>RAM</b></td>
<td><b>Descripción</b>
</td></tr>
<tr>
<td>main</td>
<td>27</td>
<td>256</td>
<td>768GB</td>
<td>
</td></tr>
<tr>
<td>general</td>
<td>48</td>
<td>44</td>
<td>187GB</td>
<td>
</td></tr>
<tr>
<td>largemem</td>
<td>9</td>
<td>44</td>
<td>765GB</td>
<td>
</td></tr>
<tr>
<td>v100</td>
<td>2</td>
<td>44</td>
<td>187GB</td>
<td>4 GPUs Nvidia Tesla V100.
</td></tr>
<tr>
<td>mi100</td>
<td>1</td>
<td>128</td>
<td>502GB</td>
<td>2 GPUs AMD Instinct MI100.
</td></tr>
<tr>
<td>debug</td>
<td>2</td>
<td>48</td>
<td>768GB</td>
<td>Destinados a pruebas de máximo 30 minutos.
</td></tr></table>

== Introducción a los comandos slurm ==
<table class="wikitable" style="width: 60%;">
<td><b>Comando SLURM</b></td>
<td><b>Descripción</b>
</td></tr>
<tr>
<td>srun</td>
<td>ejecutar un comando en nodos de cómputo asignados.
</td></tr>
<tr>
<td>sbatch</td>
<td>presentar un script de trabajo
</td></tr>
<tr>
<td>squeue</td>
<td>Mostrar estado de los trabajos en la cola.
</td></tr>
<tr>
<td>scancel</td>
<td>eliminar un trabajo.
</td></tr>
<tr>
<td>sinfo</td>
<td>Muestra el estado de los nodos de cómputo.
</td></tr></table>
Estos son los comandos básicos utilizados para realizar la mayoría de las operaciones básicas con SLURM.

=== Estado de nodos ===
Para consultar el uso de nuestra infraestructura y qué particiones están más libres, le recomendamos el comando sinfo:

<pre># sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
all up infinite 16 mix cn[001,005-006,010,034-035,037,041,045,050,057,108,121],sn[012,016,037]
all up infinite 95 alloc cn[011-033,038-044,046-049,071-120],cnf[001-004],sn[001-011,038-041,043-044]
all up infinite 33 idle fn[001-009],gn[001-002],sn[018-035,045-048]
main* up infinite 20 alloc mn[001-011,014-022]
main* up infinite 7 idle [012-013,023-027]
debug up infinite 4 idle leftraru[1-2]
general up infinite 4 mix sn[012,016,037,042]
general up infinite 22 alloc sn[001-011,013-015,017,036,038-041,043-044]
general up infinite 22 idle sn[018-035,045-048]
largemem up infinite 9 idle fn[001-009]
v100 up infinite 2 idle gn[001-002]
mi100 up infinite 1 idle gna001
</pre>

Fijándose en el texto resaltado de la salida del comando sinfo, se puede comprobar que en la partición main hay 20 nodos que están completamente ocupados (estado alloc), 7 nodos que están libres (idle); por otro lado, en la partición general hay 22 nodos completamente ocupados, 4 parcialmente ocupados y 22 libres. Dado este escenario, está claro que debería de lanzar sus ejecuciones en los nodos de la partición general, por las razones anteriormente expuestas.

Para lanzar en la partición general, debe tener en cuenta que tiene que indicar en su script que se use dicha partición en vez de, probablemente, main. Por supuesto, en esta partición cambian las características técnicas, se pasan a tener 44 cores por nodo (en vez de 256 en main) y una capacidad RAM de 187GB (en vez de 768GB en main). Puede ver más información de las particiones en este link(agregar link), donde podrá revisar que con la inclusión de Guacolda hemos añadido nodos con hasta 765GB de memoria RAM y nodos con GPUs Nvidia Tesla V100 y AMD Instinct MI100 .

Para ver los nodos disponibles y poder determinar en que partición lanzar los trabajos se recomienda utilizar el siguiente comando.

<pre>[prueba@leftraru1 ~]$ sinfo -o "%10P %6D %10t %10m %c" -t idle| egrep "PARTITION|main|general|largemem|v100"
PARTITION NODES STATE MEMORY CPUS
main* 27 idle 768000 256
general 2 idle 187000 44
largemem 7 idle 765000 44
v100 1 idle 187000 44
mi100 1 idle 515047 128
</pre>

El comando anterior muestra que main tiene 27 nodos libres, en este caso es recomendado lanzar en en main para evitar que el trabajo quede en cola por falta de recursos en otros nodos.

Otro Ejemplo, se muestra sólo una partición específica

<pre>[prueba@leftraru1 ~]$ sinfo -p main
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
main* up infinite 15 mix mn[001-008,014-020]
main* up infinite 12 idle mn[009-013,021-027]
</pre>

=== Comprobación del estado de tareas ===
squeue - Muestra el estatus de los trabajos

<pre>squeue # tus trabajos
squeue -u <username> # trabajos por usuario <username>
</pre>

squeue: Comprobar estados de los trabajos

<div style="" class="mw-highlight mw-content-ltr" dir="ltr">
<pre>
JOBID PARTITION NAME USER ST TIME NODES NODELIST(REASON)
13951858_1 general test1 test1 R 1-18:35:14 2 cn[009-010]
13951857_2 general test2 test1 R 1-18:36:11 2 cn[099-100]
13956453 gpu test3 test3 R 1-03:42:08 1 cn039
13956449 largemem test4 test4 R 1-05:42:08 1 cn044
</pre>

Puede utilizar squeue para saber el estado de una o varias de sus tareas

<pre>
$ squeue -o "%.15i %.6P %.8j %.20S %.11M %.11L %.20V %.10Q %.4C %.2D %.6m" -S -t,-Q
JOBID PARTIT NAME START_TIME TIME TIME_LEFT SUBMIT_TIME PRIORITY CPUS NO MIN_ME
10837561 general TEST1 2018-06-18T18:51:01 19:00:31 2-04:59:29 2018-06-18T18:51:01 119972 1 1 1000M
10838562 general TEST2 2018-06-19T11:30:47 2:20:45 2-21:39:15 2018-06-19T11:30:46 119946 1 1 1000M
</pre>

para mas opciones puede revisar con el comando [https://slurm.schedmd.com/squeue.html man squeue] las opciones restantes.

=== Códigos de ESTADO de los trabajos ===

Los trabajos suelen pasar por varios estados durante su ejecución. Los estados típicos son PENDIENTE, EN EJECUCIÓN, SUSPENDIDO, FINALIZANDO y TERMINADO. A continuación se explica cada estado.

'''BF''' BOOT_FAIL
Trabajo finalizado debido a un fallo de arranque, normalmente debido a un fallo de hardware (por ejemplo, no se puede arrancar el nodo o bloque y el trabajo no se puede volver a poner en cola).

'''CA''' CANCELADO
El trabajo ha sido cancelado explícitamente por el usuario o el administrador del sistema. El trabajo puede haberse iniciado o no.

'''CD''' TERMINADO
El trabajo ha terminado todos los procesos en todos los nodos con un código de salida de cero.

'''CF''' CONFIGURANDO
Al trabajo se le han asignado recursos, pero están esperando a que estén listos para su uso (por ejemplo, arrancando).

'''CG''' COMPLETANDO
El trabajo está en proceso de finalización. Algunos procesos en algunos nodos pueden estar aún activos.

'''DL''' FECHA LÍMITE
El trabajo ha finalizado en la fecha límite.

'''F''' FALLÓ
Trabajo finalizado con un código de salida distinto de cero u otra condición de fallo.

'''NF''' NODO_FAIL
Trabajo finalizado debido al fallo de uno o más nodos asignados.

'''OOM''' OUT_OF_MEMORY
El trabajo ha experimentado un error de memoria insuficiente.

'''PD''' PENDIENTE
El trabajo está pendiente de asignación de recursos.

'''PR''' PREEMPTED
El trabajo ha finalizado debido a una espera.

'''R''' EN MARCHA
El trabajo tiene actualmente una asignación.

'''RD''' RESV_DEL_HOLD
El trabajo se está reteniendo después de que se eliminara la reserva solicitada.

'''RF''' REQUEUE_FED
El trabajo está siendo solicitado por una federación.

'''RH''' REQUEUE_HOLD
Se está volviendo a poner en cola un trabajo retenido.

'''RQ''' REQUEUED
Se está poniendo en cola un trabajo que se está completando.

'''RS''' CAMBIO DE TAMAÑO
El trabajo está a punto de cambiar de tamaño.

'''RV''' REVOCADO
El trabajo se ha retirado del clúster debido a que otro clúster ha iniciado el trabajo.

'''SI''' SEÑALANDO
El trabajo está siendo señalizado.

'''SE''' SPECIAL_EXIT
El trabajo se ha puesto en cola en un estado especial. Este estado puede ser establecido por los usuarios, normalmente en EpilogSlurmctld, si el trabajo ha terminado con un valor de salida particular.

'''SO''' STAGE_OUT
El trabajo está preparando los archivos.

'''ST''' PARADO
El trabajo tiene una asignación, pero la ejecución se ha detenido con la señal SIGSTOP. Los CPUS han sido retenidos por este trabajo.

'''S''' SUSPENDIDO
El trabajo tiene una asignación, pero se ha suspendido la ejecución y se han liberado CPUs para otros trabajos.

'''TO''' TIMEOUT
El trabajo ha finalizado al alcanzar su límite de tiempo.

=== Cancelar un trabajo ===
Con scancel se puede cancelar un trabajo en ejecución
<pre>scancel <jobID> # Matar proceso <jobID>. (puede obtener el ID del job con "squeue")
scancel -u <username> # Matar proceso por usuario <username>.
</pre>
<pre>[prueba@leftraru1 ~]$ squeue -u prueba
JOBID PARTITION NAME USER ST TIME NODES NODELIST(REASON)
45594 main TEST prueba R 0:59 3 mn[001-003]
</pre>
<pre>[prueba@leftraru1 ~]$ scancel 45594
[prueba@leftraru1 ~]$ squeue -u prueba
JOBID PARTITION NAME USER ST TIME NODES NODELIST(REASON)
[prueba@leftraru1 ~]$
</pre>

=== Ver estado de trabajos ===
Para revisar el detalle de las opciones de un trabajo: scontrol show job

<pre>
$ scontrol show job 10837561
JobId=10837561 JobName=TEST1
UserId=usuario(1000) GroupId=group(1000) MCS_label=N/A
Priority=1100 Nice=0 Account=account QOS=120
JobState=RUNNING Reason=None Dependency=(null)
Requeue=0 Restarts=0 BatchFlag=1 Reboot=0 ExitCode=0:0
DerivedExitCode=0:0
RunTime=19:03:08 TimeLimit=3-00:00:00 TimeMin=N/A
SubmitTime=2018-06-18T18:51:01 EligibleTime=2018-06-18T18:51:01
StartTime=2018-06-18T18:51:01 EndTime=2018-06-21T18:51:01 Deadline=N/A
PreemptTime=None SuspendTime=None SecsPreSuspend=0
Partition=main AllocNode:Sid=leftraru2:5471
ReqNodeList=(null) ExcNodeList=(null)
NodeList=cn021
BatchHost=cn021
NumNodes=1 NumCPUs=1 NumTasks=1 CPUs/Task=1 ReqB:S:C:T=0:0:*:*
TRES=cpu=1,mem=1000M,node=1
Socks/Node=* NtasksPerN:B:S:C=1:0:*:* CoreSpec=*
Nodes=cn021 CPU_IDs=1 Mem=1000 GRES_IDX=
MinCPUsNode=1 MinMemoryCPU=1000M MinTmpDiskNode=0
Features=(null) DelayBoot=00:00:00
Gres=(null) Reservation=(null)
OverSubscribe=OK Contiguous=0 Licenses=matlab Network=(null)
Command=/home/usuario/script.sh
WorkDir=/home/usuario/
StdErr=/home/usuario/10837561_%x.err
StdIn=/dev/null
StdOut=/home/usuario/10837561_%x.out
Power=
BatchScript=
</pre>

Para ver el script asociado a un trabajo: scontrol write batch_script <job_id> -

<pre>
$ scontrol write batch_script 10837561 -
#!/bin/bash
#SBATCH -J nombre_del_trabajo
#SBATCH -p main
#SBATCH -n 1
#SBATCH --ntasks-per-node=1
#SBATCH --mail-user=usaurio@correo.cl
#SBATCH --mail-type=ALL
#SBATCH -o nombre_del_trabajo%j_%x.out
#SBATCH -e nombre_del_trabajo%j_%x.err
#SBATCH --license=matlab

ml MATLAB/2017a

matlab -nodisplay -nosplash -nodesktop < programa.m
</pre>

== Ejecutando trabajos ==
Actualmente contamos con 2 metodos de enviar trabajos bajo SLURM: '''sbatch''' and '''srun'''. A veces puede ser ventajoso ejecutar un solo comando en el clúster como prueba o realizar rápidamente una operación con recursos adicionales. 'srun' permite a los usuarios hacer esto, y comparte las mismas variables que 'sbatch' . STDOUT y STDERR para un trabajo 'srun' serán redirigidos a la pantalla del usuario. Ctrl-C cancelará un trabajo srun. '''sbatch''' enviará un script de trabajo para que lo ejecute el clúster. Los scripts de trabajo bajo SLURM son simplemente scripts de shell (* .sh) con un conjunto de solicitudes de recursos en la parte superior del script.

Uso básico de srun:

<pre>
srun <algúnComando>
</pre>

Ejemplo de salida (ejecutando el comando "hostname" para saber en que nodo se está ejecutando):
<pre> $ srun hostname
cn003
</pre>

Para enviar un script de trabajo a SLURM:
<pre>sbatch nombreScript.sh</pre>

Example output:
<pre>$ sbatch test-job.sh
Submitted batch job 1169</pre>

=== Variables Slurm ===
Las variables en esta sección son obligatorias, y SLURM las determina para determinar dónde y cuándo se ejecutarán sus trabajos. Si no asigna un valor para estos, el planificador asignará a sus trabajos el valor predeterminado. Si no solicita específicamente recursos para un trabajo, se le asignará un conjunto de recursos predeterminados. Para obtener una lista de todas las variables disponibles, consulte la documentación de SLURM en http://slurm.schedmd.com/sbatch.html. Las variables de este artículo estaban cubiertas porque eran las más relevantes para los casos de uso típicos.

<table class="wikitable" style="width: 100%;">
<tr>
<td><b>Comando SLURM</b></td>
<td><b>Descripción</b>
</td></tr>
<tr>
<td>--mem-per-cpu=<megabytes></td>
<td>Memoria requerida para el trabajo por CPU (en MegaBytes). El valor predeterminado es 1024 MB.
</td></tr>
<tr>
<td>-p <partition>, --partition=<partition></td>
<td>Enviar un trabajo a una partición específica.
</td></tr>
<tr>
<td>-n, --ntasks=<cantidad de tareas></td>
<td>Número de tareas que serán asignadas para el trabajo.
</td></tr>
<tr>
<td>-c <cpus></td>
<td>Esta es la cantidad de CPU que necesita su trabajo. Tenga en cuenta que SLURM es relativamente generoso con las CPU, y el valor especificado aquí es el número "mínimo" de CPU que se asignará a su trabajo. Si hay CPU adicionales disponibles en un nodo más allá de lo solicitado, su trabajo recibirá esas CPU hasta que otros trabajos las necesiten. El valor predeterminado es 1 CPU. Intentar usar más CPU de las que se le asignaron dará como resultado que sus procesos adicionales se turnen en la misma CPU (ralentizando su trabajo).
</td></tr>
<tr>
<td>-J <name>, --jobname=<name></td>
<td>Especifica un nombre a tu trabajo.
</td></tr>
<tr>
<td>--mail-type=BEGIN,END,FAIL,ALL<b> and </b>--mail-user=<emailAddress></td>
<td>Enviar por correo electrónico cuando su trabajo comienza / termina / falla. Puede especificar varios valores para esto (separados por comas) si es necesario.
</td></tr>
<tr>
<td>-o <STDOUT_log>, --output=<STDOUT_log></td>
<td>Redirija la salida a los archivos de registro que especifique. Por defecto, ambos, STDOUT and STDERR son enviados a este archivo. Puedes especificar %j como parte del nombre de archivo de registro para indicar la ID del trabajo (como ejemplo, "#SBATCH -o ouptut_%j.o" redirigiría la salida a "output_123456.o").
</td></tr>
<tr>
<td>-e <STDERR_log>, --error=<STDERR_log></td>
<td>Redireccionar STDERR a un archivo separado. Funciona exactamente igual que "-o".
</td></tr>
<tr>
<td>-t <days-hours:minutes:seconds></td>
<td>Walltime para tu trabajo. La duración del Walltime es el tiempo que espera que su trabajo se ejecute.
</td></tr>
<tr>
<td>-a, --array=<índices></td>
<td>Envía una lista (arreglo) de trabajos identicos. Solo aplica para sbatch.
</td></tr></table>

Los scripts de trabajo especifican los recursos solicitados y otras consideraciones especiales con comentarios especiales "#SBATCH" en la parte superior de un script de trabajo. Aunque muchas de estas opciones son opcionales, las varibles que se ocupan de solicitudes de recursos (CPU, memoria y tiempo) son obligatorias. Todas las variables deben agregarse a sus scripts de la siguiente manera:

<pre>#SBATCH <variable></pre>
Para especificar un nombre al job, por ejemplo, debe agregar lo siguiente a su secuencia de comandos:

<pre>#SBATCH --job-name=nombreDeTrabajo</pre>

===Enviar un script===
<pre>
#!/bin/bash
#SBATCH -J example
#SBATCH -p general
#SBATCH -n 1
#SBATCH --output=example_%j.out
#SBATCH --error=example_%j.err
#SBATCH --mail-user=user@example.com
#SBATCH --mail-type=ALL
</pre>

Como debe comenzar un script en Linux:
<pre>
#!/bin/bash
</pre>

Nombre del trabajo:
<pre>
#SBATCH -J example
</pre>

Nombre la partición donde desea ejecutar el Job:
<pre>
#SBATCH -p general
</pre>

Número de tareas:
<pre>
#SBATCH -n 1
</pre>

Log de salida:
<pre>
#SBATCH -o example_%j.out
</pre>

Log de error:
<pre>
#SBATCH -e example_%j.err
</pre>

Correo para notificaciones:
<pre>
#SBATCH --mail-user=user@example.com
</pre>

Enviar correo en todos casos (verificar opciones arriba):
<pre>
#SBATCH --mail-type=ALL
</pre>

=== Programar tarea (uso de scrontab) ===
'''scrontab''' es una implementación del clásico planificador de tareas de linux '''crontab''' donde se guarda un listado de comandos a ejecutar en un tiempo determinado por el usuario.

Para acceder a scrontab utilice el siguiente comando:
<pre>
[prueba@leftraru1 ~]$ scrontab -e
</pre>

Esto le permitirá editar su archivo scrontab, asignando recursos como también el momento en que desea ejecutar su tarea. La estructura base a utilizar es la siguiente:
<pre>
#SCRON -J mi_tarea
#SCRON -p main
#SCRON -n 1
#SCRON -c 1
#SCRON --mem-per-cpu=2300
#SCRON --mail-user=foo@bar.com
#SCRON --mail-type=ALL
#SCRON -o mi_tarea_%j.out
#SCRON -e mi_tarea_%j.err
# Example of job definition:
# .---------------- minute (0 - 59)
# | .------------- hour (0 - 23)
# | | .---------- day of month (1 - 31)
# | | | .------- month (1 - 12) OR jan,feb,mar,apr ...
# | | | | .---- day of week (0 - 6) (Sunday=0 or 7) OR sun,mon,tue,wed,thu,fri,sat
# | | | | |
# * * * * * command to be executed
</pre>

* '''minute''' - Corresponde al minuto en que se va a ejecutar el script, valor de 0 a 59.
* '''hour''' - Hora de ejecución, formato 24 horas, valor de 0 a 23, donde 0 son las 12:00 AM.
* '''day of month''' - Día del mes, la tarea se puede ejecutar cada x día, valor de 1 a 31.
* '''month''' - La tarea se puede ejecutar cada x mes, valor de 1 a 12.
* '''day of week''' - Día de la semana, valor de 0 a 6, donde 0 es Domingo.
* '''command to be executed''' - Script a ejecutar por el usuario.

Ejemplo envío de trabajo slurm:

Para la asignación de recursos, utilizaremos la directriz '''#SCRON''', que utiliza los mismos parámetros usados por '''#SBATCH'''.

Luego de asignar los recursos debemos especificar el tiempo, en este caso la tarea será ejecutada todos los días cada 20 minutos, luego debemos indicar el script enviado por el usuario y guardamos los cambios en el archivo.

<pre>
*/20 * * * * /home/prueba/ejemplo/script.sh
</pre>

Es importante destacar que el script a lanzar '''/home/prueba/ejemplo/script.sh''' debe tener permisos de ejecución.

Para revisar el listado de tareas existentes en nuestro scrontab, ejecutamos el comando:
<pre>
[prueba@leftraru1 ~]$ scrontab -l
*/20 * * * * /home/prueba/ejemplo/script.sh
</pre>

Para borrar el contenido de nuestro scrontab:
<pre>
[prueba@leftraru1 ~]$ scrontab -r
</pre>

'''Información a considerar:'''

* Generar archivos de salida correctamente
** Para que el archivo error y out de tu script se generen en el directorio solicitado, ejemplo, /home/prueba/ejemplo/ en tu script debe estar presente el comando cd “/home/prueba/ejemplo”, esto hará que scrontab se posicione dentro del directorio de salida.
* Es distinto el tiempo de programar el envío de una tarea (scrontab) a que una tarea inicie en el clúster (running), ya que esto dependerá de los recursos libres que existan en ese momento en el clúster.
* Para revisar las tareas programadas debe ejecutar en cualquier nodo login el comando '''scrontab -l''' o revisar con el comando '''squeue''':

<pre>
[prueba@leftraru1 ~]$ squeue
24293471 main /home/eg prueba PD 0:00 1 (BeginTime)
</pre>

== Checkpointing ==
Es la acción de guardar el estado de un proceso en ejecución en un archivo de imagen de punto de control. Este proceso se puede reiniciar más tarde desde el archivo del punto de control, continuando la ejecución desde donde se detuvo, en la misma computadora o en una diferente.

=== ¿Por qué utilizarlo? ===
* Permite ejecuciones de tarea largas que superen el tiempo de ejecución permitido en el cluster (30 días)
* Estar preparados ante fallas del sistema que nos puedan hacer perder resultados de nuestras simulaciones

=== Utilización ===
Lo primero que debemos hacer en nuestro script es cargar el módulo de Mana:
<pre>
ml mana/3.0.0
</pre>
Este módulo provee 3 ejecutables que necesitaremos:

* '''mana_coordinator:''' Coordina los checkpoints entre los distintos procesos
* '''mana_launch:''' Inicia un proceso con checkpoint
* '''mana_restart:''' Reinicia la ejecución desde una imagen del checkpoint

Necesitaremos 2 scripts para trabajar con checkpoints: Inicio y reinicio

=== Script de inicio (inicio.sh) ===
<pre>
#!/bin/bash
##---------------SLURM Parameters - NLHPC ----------------
#SBATCH -J Testcheckpoint
#SBATCH -p general
#SBATCH -n 44
#SBATCH --ntasks-per-node=44
#SBATCH --mem-per-cpu=4363
#SBATCH --mail-user=test@nlhpc.cl
#SBATCH --mail-type=ALL
#SBATCH -o Testcheckpoint_%j.out
#SBATCH -e Testcheckpoint_%j.err

# ----------------Modules----------------------------
ml mana/3.0.0
# ----------------Command--------------------------
#Checkpointing cada 1 hora
mana_cooridinator -i3600
#Ejecutamos nuestra tarea con checkpointing
srun mana_launch ./ejecutable
</pre>

=== Script de reinicio (reinicio.sh) ===
<pre>
#!/bin/bash
##---------------SLURM Parameters - NLHPC ----------------
#SBATCH -J Testcheckpoint
#SBATCH -p general
#SBATCH -n 44
#SBATCH --ntasks-per-node=44
#SBATCH --mem-per-cpu=4363
#SBATCH --mail-user=test@nlhpc.cl
#SBATCH --mail-type=ALL
#SBATCH -o Testcheckpoint_%j.out
#SBATCH -e Testcheckpoint_%j.err

# ----------------Modules----------------------------
ml mana/3.0.0
# ----------------Command--------------------------
#Checkpointing cada 1 hora
mana_cooridinator -i3600
#Reiniciar nuestra tarea desde los archivos de checkpoint
srun mana_restart
</pre>

Para correr estos scripts se puede hacer utilizando la funcionalidad de dependencias de SLURM:
<pre>
[test@leftraru2 test]$ sbatch inicio.sh
Submitted batch job 23574685
[test@leftraru2 test]$ sbatch --dependency=afterok:23574685 reinicio.sh
</pre>

== Trabajos ==
=== Trabajos paralelos ===
Muchos de los trabajos que se ejecutan en un clúster de producción implicarán más de un procesador (CPU, núcleo). Dichos trabajos paralelos deben solicitar la cantidad de recursos necesarios a través de opciones adicionales. Los más comunes son:

Para diferentes tipos de trabajos paralelos, se especificarán diferentes opciones. Los trabajos paralelos más comunes son trabajos de MPI (memoria distribuida), trabajos de subprocesos múltiples (memoria compartida) y los llamados híbridos que son una combinación de los dos. Analicemos por separado con un n ejemplo para cada uno.

=== Ejecución de programas con MPI ===
MPI (interfaz de paso de mensajes) es la API de comunicación estándar para trabajos paralelos de memoria distribuida capaz de implementarse en un clúster. Para programar dicho trabajo, es necesario especificar la cantidad de nodos del clúster que se utilizarán y la cantidad de procesos (tareas) que se ejecutarán en cada nodo.

El siguiente es un ejemplo de ejecución de un programa compilado con Open MPI:

#!/bin/bash
#SBATCH -J example_mpi
#SBATCH -p general
#SBATCH -n 264
#SBATCH --ntasks-per-node=44
#SBATCH --output=example_%j.out
#SBATCH --error=example_%j.err
#SBATCH --mail-user=user@example.com
#SBATCH --mail-type=ALL

srun ./mpi_test
A continuacion se explica línea por líneael script.

Como empieza un shell script en Linux:
<pre>
#!/bin/bash
</pre>

Nombre del Job:
<pre>
#SBATCH -J example_mpi
</pre>

Nombre la particion donde se desea ejecutar el trabajo:
<pre>
#SBATCH -p general
</pre>

Número de tareas. Debe de ser un número múltiplo del número de CPUs máximo que tenga un node de la partición donde se lanza:
<pre>
#SBATCH -n 264
</pre>

Con esto se fuerza a que se lancen 44 tareas MPI en cada uno de los nodos, ocupando de este modo nodos completos. En este caso 6 nodos completos:
<pre>
#SBATCH --ntasks-per-node=44
</pre>

Log de salida:
<pre>
#SBATCH -o example_%j.out
</pre>

Log de error:
<pre>
#SBATCH -e example_%j.err
</pre>

Correo para notificaciones:
<pre>
#SBATCH --mail-user=user@example.com
</pre>

Envía correo en todos los casos:
<pre>
#SBATCH --mail-type=ALL
</pre>

Programa para ejecutar:
<pre>
srun ./mpi_test
</pre>

'''Nota''': no se carga específicamente el módulo "mpi" ya que se carga siempre por defecto.

Para enviarlo al clúster debe ejecutar el comando: ''sbatch script.sh''. El ejemplo anterior ejecutará una tarea OpenMPI con 264 procesos reservando 264 cores para ello.

=== Trabajos multiproceso OpenMP ===
Los trabajos paralelos diseñados para ejecutarse en un sistema multi-core (shared-memory) suelen ser "multi-threaded". La programación de un job de este tipo requiere especificar el número de núcleos que se utilizan para acomodar los subprocesos.

OpenMP es el conjunto común de variables de compilación para facilitar el desarrollo de programas multi-threaded. Un script típico de SLURM para un programa de este tipo se ve así:
<pre>
#!/bin/bash
#SBATCH -J OMPtest
#SBATCH -p general
#SBATCH -n 1
#SBATCH -c 44
#SBATCH --ntasks-per-node=44
#SBATCH --mem-per-cpu=1024
#SBATCH -o example_%j.out
#SBATCH -e example_%j.err
#SBATCH --mail-user=user@example.com
#SBATCH --mail-type=ALL

OMP_NUM_THREADS=$SLURM_CPUS_PER_TASK time ./omp-program
</pre>

Como debe comenzar un script en Linux:
<pre>
#!/bin/bash
</pre>

Nombre del Job:
<pre>
#SBATCH -J OMPtest
</pre>

Nombre la particion donde desea ejecutar el Job:
<pre>
#SBATCH -p general
</pre>

Número de trabajos:
<pre>
#SBATCH -n 1
</pre>

Número de tareas:
<pre>
#SBATCH -c 44
</pre>

Con esto se fuerza a que se agrupen las 44 tareas en un nodo (en OpenMP no hay comunicación entre nodos, por lo que todas las tareas deben estar en el mismo nodo o no funcionaría):
<pre>
#SBATCH --ntasks-per-node=44
</pre>

Memoria por core (MBytes):
<pre>
#SBATCH --mem-per-cpu=1024
</pre>

Log de salida:
<pre>
#SBATCH -o example_%j.out
</pre>

Log de error:
<pre>
#SBATCH -e example_%j.err
</pre>

Correo para notificaciones:
<pre>
#SBATCH --mail-user=user@example.com
</pre>

Enviar correo en todos los casos:
<pre>
#SBATCH --mail-type=ALL
</pre>

Programa para ejecutar:
<pre>
OMP_NUM_THREADS=$SLURM_CPUS_PER_TASK time ./omp-program
</pre>

Cuando se utiliza un programa OpenMP, el número de subprocesos (y, por lo tanto, el número requerido de núcleos) se especifica a través de la variable de entorno OMP_NUM_THREADS que, por lo tanto, aparece en el script frente a la llamada al programa. Lo estamos configurando en la variable interna SLURM_CPUS_PER_TASK que se establece a través de la opción "-c" (a 44 en nuestro ejemplo, que sería el número total de cores de un nodo de la partición "general").

La opción "-n" se mantiene en 1 para indicar un único trabajo principal que tiene 44 tareas. Para asegurarnos que todas las tareas se ejecutan en el mismo nodo, se añade la opción "--ntasks-per-node" con el máximo número de cores que tiene un nodo de la partición donde se está lanzando el trabajo.

=== Ejecución de tareas en GPUs ===
<pre>
#!/bin/bash
#SBATCH -J ejemplo_gpus
#SBATCH -p v100
#SBATCH -n 1
#SBATCH -o ejemplo_%j.out
#SBATCH -e ejemplo_%j.err
#SBATCH --mail-user=correo@gmail.com
#SBATCH --mail-type=ALL
#SBATCH --mem-per-cpu=4300
#SBATCH --gres=gpu:1

./programa
</pre>

Inicio de un bash script en Linux:
<pre>
#!/bin/bash
</pre>

Nombre del trabajo:
<pre>
#SBATCH -J ejemplo_gpus
</pre>

Nombre la partición donde se ejecuta el trabajo:
<pre>
#SBATCH --partition=v100
</pre>

Número de tareas:
<pre>
#SBATCH -n 1
</pre>

Log de salida:
<pre>
#SBATCH -o ejemplo_%j.out
</pre>

Log de error:
<pre>
#SBATCH -e ejemplo_%j.err
</pre>

Correo para notificaciones:
<pre>
#SBATCH --mail-user=user@example.com
</pre>

Enviar correo en todos los casos:
<pre>
#SBATCH --mail-type=ALL
</pre>

Memoria por CPU (MB):
<pre>
#SBATCH --mem-per-cpu=4365
</pre>

Cantidad utilizada de GPUs. El parámetro gpu:1 indica la cantidad de tarjetas a utilizar (cada nodo tiene 2 GPUs):
<pre>
#SBATCH --gres=gpu:1
</pre>

Programa para ejecutar:
<pre>
./programa
</pre>

=== Job Arrays ===
Cuando se ejecutan cientos o miles de simulaciones que utilizan la misma cantidad de recursos, puede ser una ventaja ejecutar estas simulaciones como un "job array". Los job array le permiten enviar miles de dichos trabajos (llamados "job steps") con un solo script. A cada simulación se le asignará un valor único para la variable de entorno SLURM_ARRAY_TASK_ID. Puede usar esta variable para leer parámetros para pasos individuales de una línea dada de un archivo.

=== Caso de uso de un Script Job Array (Gaussian) ===
Tenemos usuarios que actualmente envían varias simulaciones al clúster que son similares en cuanto al uso de recursos, pero, la diferencia es que solo cambia la entrada que le entregan al programa. Para esta situación, recomendamos hacer uso de un script Job Array.

En este ejemplo crearemos un script job array para el software Gaussian, el cual, realizará 63 simulaciones, cada una de estas utilizará 8 cores y podrá alcanzar un uso máximo de 8 Gb de memoria ram. Para este caso utilizaremos la partición slims donde cada nodo tiene 46 Gb de memoria ram y 20 cores.

Script:
<pre>
#!/bin/bash
# ----------------SLURM Parameters----------------
#SBATCH -J prueba
#SBATCH -p slims
#SBATCH -n 1
#SBATCH -c 8
#SBATCH --mem-per-cpu=1000
#SBATCH --mail-user=prueba@nlhpc.cl
#SBATCH --mail-type=ALL
#SBATCH --array=1-63
#SBATCH -o prueba_%A_%a.out
#SBATCH -e prueba_%A_%a.err
#-----------------Toolchain---------------------------
ml purge
ml intel/2019b
# ----------------Módulos-----------------------------
ml g16/B.01
# ----------------Comandos--------------------------
file=$(ls Child_10_*.com | sed -n ${SLURM_ARRAY_TASK_ID}p)
srun g16 $file
</pre>

'''
Descripción de comandos utilizados en script:'''

Inicio de un bash script en Linux:
<pre>
#!/bin/bash
</pre>

Nombre de la simulación:
<pre>
#SBATCH -J prueba
</pre>

Nombre la partición donde se ejecuta la simulación:
<pre>
#SBATCH -p slims
</pre>

Número de tareas (1 tarea va a ejecutar 63 simulaciones):
<pre>
#SBATCH -n 1
</pre>

Core’s por tareas (cada tarea utilizará un máximo 8 cores):
<pre>
#SBATCH -c 8
</pre>

Memoria ram por cpu (cada tarea utilizará un máximo 8 Gb de ram):
<pre>
#SBATCH –mem-per-cpu=1000
</pre>

Correo para activar el envío de notificaciones:
<pre>
#SBATCH --mail-user=prueba@nlhpc.cl
</pre>

Permitir envío de notificaciones:
<pre>
#SBATCH --mail-type=ALL
</pre>

Se generan 63 simulaciones diferentes:
<pre>
#SBATCH --array=1-63
</pre>

Log de salida: (ejemplo: prueba_18455017_1.out)

* %A corresponde al Job ID de nuestra tarea que le asignará Slurm → 18455017.
* %a corresponde a la simulación X de nuestra tarea que le asignará Slurm → 1.
<pre>
#SBATCH -o prueba_%A_%a.out
</pre>

Log de errores: (ejemplo: prueba_18455017_1.err)

* %A corresponde al Job ID de nuestra tarea que le asignará Slurm → 18455017.
* %a corresponde a la simulación X de nuestra tarea que le asignará Slurm → 1.

<pre>
#SBATCH -e prueba_%A_%a.err
Toolchain: en este apartado, limpiaremos nuestro entorno de software no deseados y luego escogemos la herramienta informática con la cual está compilado el software Gaussian (nosotros utilizamos el compilador Intel/2019b).

#-----------------Toolchain---------------------------
ml purge
ml intel/2019b
Módulos: cargamos el software Gaussian versión 16/B.0.

# ----------------Módulos-----------------------------
ml g16/B.01
Comandos: aquí definimos los comandos a ejecutar.

# ----------------Comandos--------------------------
file=$(ls Child_10_*.com | sed -n ${SLURM_ARRAY_TASK_ID}p)
srun g16 $file
</pre>
file= variable que va a listar los archivos de entrada que comiencen por Child_10_ y terminen en .com

[[Archivo:Child.png|no]]

sed -n ${SLURM_ARRAY_TASK_ID}p) ← Sed imprimirá las líneas de cada archivo de entrada y la variable $SLURM_ARRAY_TASK_ID asumirá estas entradas como matriz de simulación en nuestro job array, en este ejemplo tenemos 63 archivos de entrada.

Para más detalles sobre los archivos stdin, stdout y stderr de una simulación % A será reemplazado por el valor de SLURM_ARRAY_JOB_ID que es el Job ID de nuestra tarea y %a será reemplazado por el valor de SLURM_ARRAY_TASK_ID que corresponde a la simulación X de nuestra tarea.

Srun g16 $file: ejecutará el comando gaussian g16 interpretando la variable $file en los nodos de cómputo asignados.

Enviar el script:
<pre>
[prueba@leftraru1 ~]$ sbatch prueba.sh
</pre>

=== Ejecución de una tarea que ocupa mucha RAM por CPU ===
Debemos tener en cuenta que la RAM que SLURM reserva por defecto son 1000 MB. Un típico error de cancelación de tarea por falta de memoria es el siguiente:
<pre>
/tmp/slurmd/job136839939/slurm_script: line 15: 23547 Killed ./programa.sh
slurmstepd: error: Detected 1 oom-kill event(s) in step 136839939.batch cgroup. Some of your processes
may have been killed by the cgroup out-of-memory handler.
</pre>

Si su tarea ocupa más de la memoria por defecto, puede utilizar el siguiente parámetro:
<pre>
#SBATCH --mem-per-cpu=2300 #Máxima RAM por CPU
</pre>
Esto hará que SLURM reserve más RAM por CPU para sus tareas.

Tenga en cuenta que nuestros nodos tienen 46 GB de memoria RAM (Partición slims), 187 GB (Partición general) y 765 GB (Partición largemem) por nodo. [https://wiki.nlhpc.cl/Hardware_Disponible Más información].

Otra forma de reservar memoria es utilizando el siguiente parámetro:

<pre>
#SBATCH --mem=2300
</pre>
En este caso SLURM realizará una reserva de memoria de 2300 MB pero por la totalidad del trabajo.

Los parámetros anteriores al igual que el número de CPUs que se van a usar, hay que afinarlos lo mejor posible. Para ello lo que se puede hacer es hacer pruebas en los nodos logins, sin lanzar en las colas, y así estudiar el uso de RAM y CPU por parte de sus procesos.

=== Ejecución de una tarea con Dependencias ===
Las dependencias de trabajos se utilizan para aplazar el inicio de un trabajo hasta que se satisfagan las dependencias especificadas. Se especifican con la opción --dependency en el siguiente formato:
<pre>
sbatch --dependency=<type:job_id[:job_id][,type:job_id[:job_id]]> ...
</pre>
Los tipos de dependencias son las siguientes:

* '''after''':jobid[:jobid...] - el trabajo puede empezar después de que los trabajos especificados comiencen
* '''afterany''':jobid[:jobid...] - el trabajo puede empezar después de que los trabajos especificados terminen
* '''afternotok''':jobid[:jobid...] - el trabajo puede empezar después que los trabajos especificados terminan fallidamente
* '''afterok''':jobid[:jobid...] - el trabajo puede empezar después que los trabajos especificados terminan exitósamente

La manera más simple de usar una dependencia del tipo afterok:
<pre>
[prueba@leftraru1 ~]$ sbatch job1.sh
Submitted batch job 21363626
[prueba@leftraru1 ~]$ sbatch --dependency=afterok:21363626 job2.sh
</pre>

Ahora cuando job1.sh termine correctamente, el job2.sh entrará en ejecución. Si job1.sh termina fallidamente, job2.sh no entrará en ejecución nunca pero sí quedará en cola (debe cancelarse manualmente el trabajo).

== Prioridad de tarea ==
Cómo ver la prioridad del trabajo. Los factores que determinan la prioridad del trabajo, incluyendo la fórmula y pesos.

=== Factores que determinan prioridad de tarea ===
<table class="wikitable" style="width: 60%;">
<tr>
<td><b>Comando SLURM</b></td>
<td><b>Descripción</b>
</td></tr>
<tr>
<td>Edad</td>
<td>la cantidad de tiempo que el trabajo ha estado esperando en la cola.
</td></tr>
<tr>
<td>Tamaño de la tarea</td>
<td>número de nodos solicitados por el trabajo.
</td></tr>
<tr>
<td>Partición</td>
<td>prioridad para una partición determinada.
</td></tr>
<tr>
<td>Prioridad Baja</td>
<td>Mientras más tareas se ejecuten en el cluster, menor será la prioridad.
</td></tr>
<tr>
<td>Prioridad Alta</td>
<td>Mientras menos tareas se ejecuten en el clúster, más alta es la prioridad.
</td></tr></table>

== Prioridad de tarea ==
Cómo ver la prioridad del trabajo. Los factores que determinan la prioridad del trabajo, incluyendo la fórmula y pesos.

=== Factores que determinan prioridad de tarea ===
* Edad - la cantidad de tiempo que el trabajo ha estado esperando en la cola
* Tamaño Oficio - número de nodos solicitados por el trabajo
* Partición - prioridad para una partición determinada
* Contribución de prioridades basada en los recursos informáticos utilizados por los miembros de un grupo de investigación en los últimos 30 días - Fairshare.
* Mientras más tareas se ejecuten en el cluster, menor será la prioridad.
* Mientras menos tareas se ejecuten en el clúster, más alta es la prioridad.
Fórmula Prioridad de tarea
<pre>
Job_priority =
(PriorityWeightAge) * (age_factor) +
(PriorityWeightFairshare) * (fair-share_factor) +
(PriorityWeightJobSize) * (job_size_factor) +
(PriorityWeightPartition) * (partition_factor) +
(PriorityWeightQOS) * (QOS_factor)
</pre>

== Visualización de sus Tareas ==
Si Ud. necesita visualizar información acerca de sus tareas de forma interactiva, puede utilizar el comando smap:

smap -i 3

[[Archivo:Smap.png|no|700px]]

De esta forma, tendrá una actualización cada 3 segundos de sus tareas en ejecución incluyendo los nodos en los cuales se encuentran ejecutándose.

== Bibliografía ==
[http://slurm.schedmd.com/documentation.html Manual Oficial de Slurm]

[https://slurm.schedmd.com/scrontab.html Documentación scrontab]

Uso Filesystem Local

2024-05-03T13:50:02Z

Jmorales: /* Pasos a seguir */

== Introducción ==

El siguiente procedimiento indica los pasos necesarios para poder utilizar el '''filesystem local''' y ejecutar tareas mediante el uso de SLURM.

Este uso está pensado para aplicaciones como '''Siesta''', '''Orca''', '''Gaussian''' entre otras.

== Pasos a seguir ==

Para considerar el uso del '''filesystem local''', es necesario comprender qué debemos hacer:

# Copiar nuestros archivos desde nuestra carpeta personal a un directorio local
# Ejecutar nuestra simulación
# Copiar los resultados del directorio local a nuestra carpeta personal

Con esto en mente, se puede realizar un script similar a:

<pre>
#!/bin/bash
#SBATCH -J ejemplo
#SBATCH -p main
#SBATCH -n 1
#SBATCH -c 1
#SBATCH --mem-per-cpu=2300
#SBATCH --mail-user=foo@example.com
#SBATCH --mail-type=ALL
#SBATCH -o ejemplo_%j.out
#SBATCH -e ejemplo_%j.err

# Carga de módulos necesarios
ml MODULO

# Creación de carpeta local
LOCAL_DIR="/tmp/${SLURM_JOB_ID}"
mkdir $LOCAL_DIR

# Copiamos nuestros archivos o carpeta al directorio creado
cp -r $HOME/mis_archivos/ $LOCAL_DIR
cd $LOCAL_DIR/mis_archivos

# Ejecutamos nuestra simulación
srun aplicación mi_input > mi_output

# Copiamos los resultados obtenidos a nuestra carpeta de origen
cp -r mi_output $LOCAL_DIR/mis_archivos
</pre>

En el ejemplo anterior, se ejecuta una tarea bajo la partición '''main'''.

El comando '''ml MODULO''' hace referencia a que '''''debe cargar los módulos que usted necesite'''''.

Posterior a eso, se creará una carpeta bajo '''/tmp''' que tendrá como nombre el '''Job ID''' de su tarea, y se copiará la carpeta '''mis_archivos''' a la nueva carpeta creada.

Y se finaliza accediendo a la carpeta copiada en el '''filesystem''' local.

Posterior a eso, se ejecutará la aplicación según el módulo cargado (en este ejemplo llamado '''srun aplicación'''), el cual almacenará el resultado obtenido en el archivo '''mi_output'''.

Una vez que haya finalizado la tarea, es importante que el usuario almacene en su carpeta '''personal''' los resultados obtenidos, para eso se copia el archivo obtenido a su carpeta personal.

Es de suma importancia el último paso, ya que de no copiar los resultados estos se perderán.

Una vez que la tarea haya finalizado, [[SISTEMA_GESTOR_DE_RECURSOS|SLURM]] eliminará las carpetas y el contenido de '''/tmp'''.

== Consideraciones ==

El lector debe considerar qué el ''script'' presentado en la sección anterior es un ejemplo y deberá realizar las modificaciones necesarias para:

* Crear una carpeta con la variable $SLURM_JOB_ID permite que no exista conflicto de nombres con otras posibles carpetas ya existentes
* Cargar los módulos y librerías específicas a su necesidad
* Puede copiar archivos y/o carpetas de manera particular y/o recursiva según corresponda
* Ejecutar la aplicación que requiera, indicando el/los comando/s necesarios según el módulo cargado anteriormente
* Deberá copiar ''de regreso'' los resultados obtenidos a su carpeta personal para evitar pérdida de datos obtenidos

== Enlaces ==

Puede ver ejemplos del uso de este procedimiento en otras páginas de la wiki como por ejemplo:

* [[Siesta]]
* [[MATLAB_Distrib_Computing]]

Jupyter bajo Conda

2024-05-03T13:49:15Z

Jmorales: /* Identificación de nodo en el que nos encontremos */

= Introducción =

El siguiente procedimiento le permitirá instalar Jupyter Notebook en un entorno Conda, para eventualmente acceder desde su computadora local y utilizarlo.

Recomendamos la lectura de la página de la Wiki sobre Conda en el siguiente [https://wiki.nlhpc.cl/Uso_de_conda enlace] donde aprenderá a utilizar los módulos necesarios, crear entornos virtuales e instalar software.

= Creación de entorno virtual de Conda e instalación de Jupyter =

Crearemos un entorno virtual y posterior a eso instalaremos Jupyter de la siguiente manera:

[dbowman@leftraru1 ~]$ conda create -n mi_entorno_con_jupyter
Collecting package metadata (current_repodata.json): done
Solving environment: done
## Package Plan ##
environment location: /home/eosorio/.conda/envs/mi_entorno_con_jupyter
Proceed ([y]/n)?
Preparing transaction: done
Verifying transaction: done
Executing transaction: done

Luego activaremos nuestro entorno virtual con:

[dbowman@leftraru1 ~]$ conda activate mi_entorno_con_jupyter

E instalaremos jupyter ejecutando:

[dbowman@leftraru1 ~]$ conda install -y jupyter

Si todo resulta de manera exitosa veremos un resultado similar a:

Downloading and Extracting Packages
jsonpointer-2.0 | 9 KB | ######################################### | 100%
jedi-0.19.0 | 825 KB | ######################################### | 100%
webcolors-1.13 | 18 KB | ######################################### | 100%
isoduration-20.11.0 | 17 KB | ######################################### | 100%
jupyterlab_server-2. | 59 KB | ######################################### | 100%
async-lru-2.0.4 | 15 KB | ######################################### | 100%
uri-template-1.3.0 | 23 KB | ######################################### | 100%
ipywidgets-8.1.0 | 111 KB | ######################################### | 100%
fqdn-1.5.1 | 14 KB | ######################################### | 100%
arrow-1.2.3 | 92 KB | ######################################### | 100%
sip-6.7.11 | 569 KB | ######################################### | 100%
openssl-3.1.2 | 2.5 MB | ######################################### | 100%
jsonschema-with-form | 7 KB | ######################################### | 100%
jupyter_events-0.7.0 | 21 KB | ######################################### | 100%
notebook-7.0.1 | 3.1 MB | ######################################### | 100%
Preparing transaction: done
Verifying transaction: done
Executing transaction: done

= Ejecución de Jupyter =

A continuación deberemos realizar dos pasos:

# Identificar el nodo en el que nos encontramos
# Ejecutar jupyter

== Identificación de nodo en el que nos encontremos ==

Para identificar el nodo en el que nos encontremos ejecutaremos:

[dbowman@leftraru1 ~]$ hostname
leftraru2

La respuesta será uno de los nodos de acceso correspondientes a leftraru1 o leftraru2.

En nuestro ejemplo obtuvimos <code>leftraru2</code>, dato que utilizaremos prontamente.

== Ejecutar Jupyter ==

En este paso ejecutaremos Jupyter indicando un puerto específico para posteriormente poder conectarnos desde nuestra computadora local.

El comando a utilizar es:

[dbowman@leftraru1 ~]$ jupyter-notebook --no-browser --port 2346

Obtendremos mucha información, pero nos deberemos fijar en la información similar a:

[C 2023-08-02 17:09:07.819 ServerApp]
To access the server, open this file in a browser:
file:///home/dbowman/.local/share/jupyter/runtime/jpserver-60187-open.html
Or copy and paste one of these URLs:
http://localhost:2346/tree?token=918029e46e54957ac797882f1
http://127.0.0.1:2346/tree?token=918029e46e54957ac797882f1

Deberemos tener en cuenta la información <code>http://localhost:2346/tree?token=918029e46e54957ac797882f1</code> para nuestros próximos pasos.

= Accediendo a Jupyter desde nuestra computadora local =

Los siguientes pasos son realizados en una terminal '''desde''' nuestra computadora local.

Los datos que necesitaremos son:

* Nombre de host en donde ejecutamos los pasos anteriores
* URL de acceso al ejecutar Jupyter en el cluster

Estos datos fueron obtenidos desde la sección anterior, lo que nos permitirá:

# Crear un túnel de acceso
# Acceder a Jupyter

== Creación de túnel de acceso ==

En pasos previos obtuvimos que el nombre de host <code>leftraru2</code>, con lo que podremos ejecutar desde nuestra computadora local un túnel SSH de la siguiente manera:

[david@HAL ~]$ ssh -NL 2346:localhost:2346 -l dbowman leftraru2.nlhpc.cl

Se le solicitará su contraseña del cluster y si la autenticación es exitosa, se creará un túnel desde nuestra computadora al cluster bajo nuestro usuario y el host donde hemos estado trabajando.

En el caso de haber obtenido otro nombre de host, por ejemplo <code>leftraru2</code>, deberemos indicar dicho nombre de host en el comando ejecutado.

== Accediendo a Jupyter ==

Una vez que hemos lanzado el túnel, deberemos acceder mediante nuestro navegador preferido a la URL obtenida previamente.

En nuestro caso bastará abrir: '''<code>http://localhost:2346/tree?token=918029e46e54957ac797882f1</code>'''

Y ya podrá acceder a utilizar Jupyter desde su navegador.

= Lanzando tareas de Jupyter en los nodos de cómputo =

Debemos tener en consideración que el uso de Jupyter suele realizarse mayormente de manera interactiva, lo que requerirá los cuatro pasos anteriores que hemos realizado:

# Identificación de host en el cluster
# Ejecutar Jupyter y tomar nota de URL de acceso
# Crear túnel SSH desde nuestra computadora al cluster
# Acceder a Jupyter

También es importante notar que estamos usando un entorno virtual, por lo que para ejecutar deberemos considerar lo siguiente:

* Reservar recursos
* Activar entorno de conda utilizado
* Lanzar tarea a los nodos de cómputo
** Esta tarea se ejecutará pero no podrá ser utilizada de manera interactiva

Entonces, si queremos lanzar nuestro archivo <code>HolaJupyter.ipynb</code> creado en nuestro '''notebook''', podremos crear un script similar a:

#!/bin/bash
#---------------Script SBATCH - NLHPC ----------------
#SBATCH -J jupyter-desde-sbatch
#SBATCH -p main
#SBATCH -n 1
#SBATCH -c 1
#SBATCH --mem-per-cpu=2300
#SBATCH --mail-user=dbowman@hal.com
#SBATCH --mail-type=ALL
#SBATCH -o jupyter-desde-sbatch_%j.out
source /home/dbowman/.bashrc
eval "$(/home/lmod/software/Core/Miniconda3/4.5.12/bin/conda shell.bash hook)"
conda activate mi_entorno_con_jupyter
jupyter nbconvert --to notebook --execute HolaJupyter.ipynb --output=jupyter-output.ipynb

Esto nos entregará información en el archivo de salida de la tarea <code>jupyter-desde-sbatch_234234.out</code> similar a:
[NbConvertApp] Converting notebook HolaJupyter.ipynb to notebook
0.00s - Debugger warning: It seems that frozen modules are being used, which may
0.00s - make the debugger miss breakpoints. Please pass -Xfrozen_modules=off
0.00s - to python to disable frozen modules.
0.00s - Note: Debugging will proceed. Set PYDEVD_DISABLE_FILE_VALIDATION=1 to disable this validation.
0.00s - Debugger warning: It seems that frozen modules are being used, which may
0.00s - make the debugger miss breakpoints. Please pass -Xfrozen_modules=off
0.00s - to python to disable frozen modules.
0.00s - Note: Debugging will proceed. Set PYDEVD_DISABLE_FILE_VALIDATION=1 to disable this validation.
[NbConvertApp] Writing 1187 bytes to jupyter-output.ipynb

Y el archivo de salida llamado <code>jupyter-output.ipynb</code> tendrá un contenido similar a:

{
"cells": [
{
"cell_type": "code",
"execution_count": 1,
"id": "7832632e-7aeb-48d5-97f5-4aed8644fb0b",
"metadata": {
"execution": {
"iopub.execute_input": "2023-08-02T22:06:21.689494Z",
"iopub.status.busy": "2023-08-02T22:06:21.689137Z",
"iopub.status.idle": "2023-08-02T22:06:21.701830Z",
"shell.execute_reply": "2023-08-02T22:06:21.700906Z"
}
},
"outputs": [
{
"name": "stdout",
"output_type": "stream",
"text": [
"Hola Jupyter!\n"
]
}
],
"source": [
"print(\"Hola Jupyter!\")"
]
},
...
}

= Conclusión =

El uso de Jupyter puede resultar de gran ayuda, y en conjunto con la potencia de los nodos de cómputo se transforma en una herramienta útil y flexible.

Se tiene una curva de aprendizaje inicial poco sencilla al requerir de varios pasos, pero una vez dominado, podrá repetir sus pasos una y otra vez según sus requerimientos.

= Más información =

Puede leer sobre Conda en el siguiente [https://wiki.nlhpc.cl/Uso_de_conda enlace].

Puede leer sobre Jupyter en la página web oficial en el siguiente [https://docs.jupyter.org/en/latest/ enlace].

Jupyter bajo Conda

2024-05-03T13:48:44Z

Jmorales: /* Creación de túnel de acceso */

= Introducción =

El siguiente procedimiento le permitirá instalar Jupyter Notebook en un entorno Conda, para eventualmente acceder desde su computadora local y utilizarlo.

Recomendamos la lectura de la página de la Wiki sobre Conda en el siguiente [https://wiki.nlhpc.cl/Uso_de_conda enlace] donde aprenderá a utilizar los módulos necesarios, crear entornos virtuales e instalar software.

= Creación de entorno virtual de Conda e instalación de Jupyter =

Crearemos un entorno virtual y posterior a eso instalaremos Jupyter de la siguiente manera:

[dbowman@leftraru1 ~]$ conda create -n mi_entorno_con_jupyter
Collecting package metadata (current_repodata.json): done
Solving environment: done
## Package Plan ##
environment location: /home/eosorio/.conda/envs/mi_entorno_con_jupyter
Proceed ([y]/n)?
Preparing transaction: done
Verifying transaction: done
Executing transaction: done

Luego activaremos nuestro entorno virtual con:

[dbowman@leftraru1 ~]$ conda activate mi_entorno_con_jupyter

E instalaremos jupyter ejecutando:

[dbowman@leftraru1 ~]$ conda install -y jupyter

Si todo resulta de manera exitosa veremos un resultado similar a:

Downloading and Extracting Packages
jsonpointer-2.0 | 9 KB | ######################################### | 100%
jedi-0.19.0 | 825 KB | ######################################### | 100%
webcolors-1.13 | 18 KB | ######################################### | 100%
isoduration-20.11.0 | 17 KB | ######################################### | 100%
jupyterlab_server-2. | 59 KB | ######################################### | 100%
async-lru-2.0.4 | 15 KB | ######################################### | 100%
uri-template-1.3.0 | 23 KB | ######################################### | 100%
ipywidgets-8.1.0 | 111 KB | ######################################### | 100%
fqdn-1.5.1 | 14 KB | ######################################### | 100%
arrow-1.2.3 | 92 KB | ######################################### | 100%
sip-6.7.11 | 569 KB | ######################################### | 100%
openssl-3.1.2 | 2.5 MB | ######################################### | 100%
jsonschema-with-form | 7 KB | ######################################### | 100%
jupyter_events-0.7.0 | 21 KB | ######################################### | 100%
notebook-7.0.1 | 3.1 MB | ######################################### | 100%
Preparing transaction: done
Verifying transaction: done
Executing transaction: done

= Ejecución de Jupyter =

A continuación deberemos realizar dos pasos:

# Identificar el nodo en el que nos encontramos
# Ejecutar jupyter

== Identificación de nodo en el que nos encontremos ==

Para identificar el nodo en el que nos encontremos ejecutaremos:

[dbowman@leftraru1 ~]$ hostname
leftraru2

La respuesta será uno de los nodos de acceso correspondientes a leftraru1, 2, 3 o 4.

En nuestro ejemplo obtuvimos <code>leftraru2</code>, dato que utilizaremos prontamente.

== Ejecutar Jupyter ==

En este paso ejecutaremos Jupyter indicando un puerto específico para posteriormente poder conectarnos desde nuestra computadora local.

El comando a utilizar es:

[dbowman@leftraru1 ~]$ jupyter-notebook --no-browser --port 2346

Obtendremos mucha información, pero nos deberemos fijar en la información similar a:

[C 2023-08-02 17:09:07.819 ServerApp]
To access the server, open this file in a browser:
file:///home/dbowman/.local/share/jupyter/runtime/jpserver-60187-open.html
Or copy and paste one of these URLs:
http://localhost:2346/tree?token=918029e46e54957ac797882f1
http://127.0.0.1:2346/tree?token=918029e46e54957ac797882f1

Deberemos tener en cuenta la información <code>http://localhost:2346/tree?token=918029e46e54957ac797882f1</code> para nuestros próximos pasos.

= Accediendo a Jupyter desde nuestra computadora local =

Los siguientes pasos son realizados en una terminal '''desde''' nuestra computadora local.

Los datos que necesitaremos son:

* Nombre de host en donde ejecutamos los pasos anteriores
* URL de acceso al ejecutar Jupyter en el cluster

Estos datos fueron obtenidos desde la sección anterior, lo que nos permitirá:

# Crear un túnel de acceso
# Acceder a Jupyter

== Creación de túnel de acceso ==

En pasos previos obtuvimos que el nombre de host <code>leftraru2</code>, con lo que podremos ejecutar desde nuestra computadora local un túnel SSH de la siguiente manera:

[david@HAL ~]$ ssh -NL 2346:localhost:2346 -l dbowman leftraru2.nlhpc.cl

Se le solicitará su contraseña del cluster y si la autenticación es exitosa, se creará un túnel desde nuestra computadora al cluster bajo nuestro usuario y el host donde hemos estado trabajando.

En el caso de haber obtenido otro nombre de host, por ejemplo <code>leftraru2</code>, deberemos indicar dicho nombre de host en el comando ejecutado.

== Accediendo a Jupyter ==

Una vez que hemos lanzado el túnel, deberemos acceder mediante nuestro navegador preferido a la URL obtenida previamente.

En nuestro caso bastará abrir: '''<code>http://localhost:2346/tree?token=918029e46e54957ac797882f1</code>'''

Y ya podrá acceder a utilizar Jupyter desde su navegador.

= Lanzando tareas de Jupyter en los nodos de cómputo =

Debemos tener en consideración que el uso de Jupyter suele realizarse mayormente de manera interactiva, lo que requerirá los cuatro pasos anteriores que hemos realizado:

# Identificación de host en el cluster
# Ejecutar Jupyter y tomar nota de URL de acceso
# Crear túnel SSH desde nuestra computadora al cluster
# Acceder a Jupyter

También es importante notar que estamos usando un entorno virtual, por lo que para ejecutar deberemos considerar lo siguiente:

* Reservar recursos
* Activar entorno de conda utilizado
* Lanzar tarea a los nodos de cómputo
** Esta tarea se ejecutará pero no podrá ser utilizada de manera interactiva

Entonces, si queremos lanzar nuestro archivo <code>HolaJupyter.ipynb</code> creado en nuestro '''notebook''', podremos crear un script similar a:

#!/bin/bash
#---------------Script SBATCH - NLHPC ----------------
#SBATCH -J jupyter-desde-sbatch
#SBATCH -p main
#SBATCH -n 1
#SBATCH -c 1
#SBATCH --mem-per-cpu=2300
#SBATCH --mail-user=dbowman@hal.com
#SBATCH --mail-type=ALL
#SBATCH -o jupyter-desde-sbatch_%j.out
source /home/dbowman/.bashrc
eval "$(/home/lmod/software/Core/Miniconda3/4.5.12/bin/conda shell.bash hook)"
conda activate mi_entorno_con_jupyter
jupyter nbconvert --to notebook --execute HolaJupyter.ipynb --output=jupyter-output.ipynb

Esto nos entregará información en el archivo de salida de la tarea <code>jupyter-desde-sbatch_234234.out</code> similar a:
[NbConvertApp] Converting notebook HolaJupyter.ipynb to notebook
0.00s - Debugger warning: It seems that frozen modules are being used, which may
0.00s - make the debugger miss breakpoints. Please pass -Xfrozen_modules=off
0.00s - to python to disable frozen modules.
0.00s - Note: Debugging will proceed. Set PYDEVD_DISABLE_FILE_VALIDATION=1 to disable this validation.
0.00s - Debugger warning: It seems that frozen modules are being used, which may
0.00s - make the debugger miss breakpoints. Please pass -Xfrozen_modules=off
0.00s - to python to disable frozen modules.
0.00s - Note: Debugging will proceed. Set PYDEVD_DISABLE_FILE_VALIDATION=1 to disable this validation.
[NbConvertApp] Writing 1187 bytes to jupyter-output.ipynb

Y el archivo de salida llamado <code>jupyter-output.ipynb</code> tendrá un contenido similar a:

{
"cells": [
{
"cell_type": "code",
"execution_count": 1,
"id": "7832632e-7aeb-48d5-97f5-4aed8644fb0b",
"metadata": {
"execution": {
"iopub.execute_input": "2023-08-02T22:06:21.689494Z",
"iopub.status.busy": "2023-08-02T22:06:21.689137Z",
"iopub.status.idle": "2023-08-02T22:06:21.701830Z",
"shell.execute_reply": "2023-08-02T22:06:21.700906Z"
}
},
"outputs": [
{
"name": "stdout",
"output_type": "stream",
"text": [
"Hola Jupyter!\n"
]
}
],
"source": [
"print(\"Hola Jupyter!\")"
]
},
...
}

= Conclusión =

El uso de Jupyter puede resultar de gran ayuda, y en conjunto con la potencia de los nodos de cómputo se transforma en una herramienta útil y flexible.

Se tiene una curva de aprendizaje inicial poco sencilla al requerir de varios pasos, pero una vez dominado, podrá repetir sus pasos una y otra vez según sus requerimientos.

= Más información =

Puede leer sobre Conda en el siguiente [https://wiki.nlhpc.cl/Uso_de_conda enlace].

Puede leer sobre Jupyter en la página web oficial en el siguiente [https://docs.jupyter.org/en/latest/ enlace].

Siesta

2024-05-02T21:59:20Z

Jmorales: /* Ejemplo de Lanzador */

== ¿Qué es? ==
SIESTA (Spanish Initiative for Electronic Simulations with Thousands of Atoms) es un método original y una implementación de software para efectuar cálculos de estructura electrónica y simulaciones de dinámica molecular ab initio para moléculas y sólidos.

== Modulos ==
Se encuentra disponible en:

=== [https://wiki.nlhpc.cl/Environment_Modules Environment Modules] ===
* siesta/3.2
* siesta/4.0
* siesta/trunk-462
* siesta/trunk-663
== Ejemplo de Lanzador ==
Ejemplo de SBATCH para enviar al cluster:
<pre>
#!/bin/bash
#SBATCH --job-name="siesta"
#SBATCH --partition="general"
#SBATCH --nodes=6 # lo máximo seria 6, lo mínimo 1
#SBATCH --ntasks-per-node=20 # ocuparía 120 cores en total
#SBATCH --mem-per-cpu=4363
#SBATCH --output=%x_%j.out
#SBATCH --error=%x_%j.err
#SBATCH --exclude=cnf[001-004]

module load siesta/trunk-663
export OMP_NUM_THREADS=1

DTMP="/tmp/${SLURM_JOB_ID}" # recomendamos siempre trabajar en el /tmp del nodo local (al menos 200G disponibles en general)
mkdir $DTMP # creamos el directorio
cp ejemplo.fdf *psf *DM $DTMP # copiamos los archivos fuente hacia /tmp
cd $DTMP # entramos al directorio
srun siesta < ejemplo.fdf # la salida del programa queda en el archivo de log
cp * $HOME/siesta/ # copiamos a nuestro $HOME los resultados
cd $HOME/siesta/
</pre>

Al terminar la ejecución [https://wiki.nlhpc.cl/SISTEMA_GESTOR_DE_RECURSOS#SLURM_Workload_Manager Slurm] elimina todos los archivos del usuario en /tmp

== Referencias ==
* [https://cfd.direct/openfoam/linux-guide/ Siesta Web Page]
* [https://wiki.rc.usf.edu/index.php/SIESTA#Submitting_Jobs Submitting Jobs]
* [http://hpc.mediawiki.hull.ac.uk/Applications/Siesta hpc.mediawiki.hull.ac.uk/Applications/Siesta]

Monitoreo

2024-05-02T21:58:42Z

Jmorales: /* ¿Como listo las tareas? */

== ¿Como listo las tareas? ==
Ejecuto el comando [https://slurm.schedmd.com/squeue.html squeue] para conocer por ejemplo el estado, tiempo de ejecución e identificador de los trabajos [https://wiki.nlhpc.cl/SISTEMA_GESTOR_DE_RECURSOS SLURM]
<pre>
[usuario@leftraru1 ~]$ squeue -o "%.15i %.6P %.8j %.20S %.11M %.11L %.20V %.2t %.10q %.4C %.2D %.7W %N " -S -t,-Q

JOBID PARTIT NAME START_TIME TIME TIME_LEFT SUBMIT_TIME ST QOS CPUS NO LICENSE NODELIST
12863561 general test04 2024-02-08T13:57:53 1-20:25:20 1-03:34:40 2018-07-08T13:57:26 R 120 5 1 (null) cn000
12864082 general test02 2024-02-09T10:44:15 23:38:58 2-00:21:02 2018-07-09T10:43:51 R 120 10 1 (null) cn001
12865333 general test01 2024-02-10T17:16:38 0:00 3-00:00:00 2018-07-10T09:30:22 PD 120 10 1 (null)
12865334 general test06 2024-02-10T17:49:42 0:00 3-00:00:00 2018-07-10T09:38:13 PD 120 10 1 (null)
12865335 general test09 2024-02-11T07:42:16 0:00 3-00:00:00 2018-07-10T09:28:05 PD 120 20 1 (null)
</pre>

== ¿Como monitoreo los recursos utilizados por mi tarea? ==
=== Conectándose al nodo ===
Siempre y cuando tengamos tareas corriendo en un nodo, podemos entrar en este vía SSH.

==== * uptime ====
Para conocer la carga del nodo, cuantos procesos por core existen actualmente.
<pre>
[usuario@leftraru1 ~]# ssh cn109
usuario@cn000 s password:
[usuario@cn000 ~]# uptime
10:40:59 up 27 days, 16:46, 1 user, load average: 17.04, 13.76, 13.09
</pre>

==== * User Stats ====
Este script permite revisar:

===== La memoria por core (en kb) =====
<pre>
[usuario@cn000 ~]$ /home/apps/nlhpc/bin/user_stats.sh mem
00 371695616
01 373268480
02 367038464
03 363290624
04 367382528
</pre>

===== Cantidad de procesos por core =====
<pre>
[usuario@cn000 ~]$ /home/apps/nlhpc/bin/user_stats.sh load
00 1
01 2
02 1
03 1
04 1
</pre>

==== * htop ====
Es un visor de procesos en linux, basado en ncurses.
<pre>
[usuario@cn109 ~]# htop
</pre>

[[Archivo:Htop.png|no|htop]]

.

=== A través de Ganglia ===
Ganglia es un sistema de monitoreo distribuido para sistemas HPC, por cada uno de los nodos de cómputo de las diferentes particiones están disponibles los gráficos de memoria, carga, porcentaje de cpu usada, tráfico, etc.

[[Archivo:Ganglia.png|no|300px]]

=== A través de [http://dashboard.nlhpc.cl/ Dashboard] ===
Panel de visualización del estado de los nodos. Muestra una vista rápida del estado de los nodos (de login y de cómputo) y uso general del cluster, ademas de encontrar el listado de tareas en ejecución, pendientes, históricos.

=== En el correo de notificación ===
Al terminar una tarea se adjuntan las siguientes gráficas:

==== Porcentaje de uso por core ====
[[Archivo:Correo CPU.png|no]]

==== Memoria utilizada por core ====
[[Archivo:Correo MEMxCPU.png|no]]

==== Archivo report.log ====
<pre>
job_id=12668XXX user=usuario mail=None start_time=2018-07-09T06:51:34 running_time=3:53:28 cores_total=10 nodes_raw=cn094 alarm_cpu=True alarm_memory=False watch|avg|std|ptotal=10800|30|20|50 ptcw=70 command=/home/usuario/tarea.sh nodes={'cn094': {'mem': '10000', 'cpu': [0, 2, 3, 4, 5, 6, 7, 8, 9, 10]}} alarm_count=1 last_time=1531147611 iter=2 job_cancel=None modules=[]
n=cn094

mem max:3586 resv:10000
cpu=10 avg=91.00 std=45.77 / all avg=0.00 std=0.00
cpu= 0 avg=98.19 std=44.53 / all avg=0.00 std=0.00
* cpu= 3 avg=0.56 std=0.50 / all avg=0.47 std=0.50
* cpu= 2 avg=0.86 std=0.35 / all avg=0.66 std=0.47
* cpu= 5 avg=0.64 std=0.48 / all avg=0.49 std=0.50
* cpu= 4 avg=0.53 std=0.50 / all avg=0.40 std=0.49
cpu= 7 avg=82.11 std=48.93 / all avg=0.00 std=0.00
* cpu= 6 avg=0.56 std=0.50 / all avg=0.45 std=0.50
* cpu= 9 avg=0.47 std=0.50 / all avg=0.36 std=0.48
* cpu= 8 avg=0.72 std=0.45 / all avg=0.79 std=0.41
</pre>

* En mem max:'''3586''' resv:10000 se destaca que el máximo de memoria utilizada por la tarea ha sido de 3568M
* Por cada una de los cores se despliega: el uso promedio de cada core, la desviación estándar en las últimas 3 horas / del total de tiempo de ejecución.

SISTEMA GESTOR DE RECURSOS

2024-04-29T22:02:04Z

Jmorales: /* Programar tarea (uso de scrontab) */

== SLURM Workload Manager ==
Es un sistema de programación de trabajos y gestión de clústeres de código abierto, tolerante a fallas y altamente escalable para clústeres Linux grandes y pequeños.

Como administrador de carga de trabajo de clúster, Slurm tiene tres funciones clave. Primero, asigna acceso exclusivo y / o no exclusivo a los recursos (nodos de cómputo) a los usuarios durante un período de tiempo para que puedan realizar el trabajo. En segundo lugar, proporciona un marco para iniciar, ejecutar y monitorear el trabajo (normalmente un trabajo paralelo) en el conjunto de nodos asignados. Finalmente, arbitra la contención de recursos mediante la gestión de una cola de trabajo pendiente.

SLURM es el gestor de colas instalado en muchos de los súper computadores del [https://www.top500.org/ TOP500], y también en el clúster del NLHPC. Si Ud. quiere lanzar tareas dentro de Leftaru, debe hacerlo a través de Slurm.

== Conceptos clave ==
SLURM gestiona trabajos de usuario que tienen las siguientes características clave:

* Conjunto de recursos solicitados:
** Número de recursos informáticos: nodos (incluidas todas sus CPUs y núcleos) o CPUs (incluidos todos sus núcleos) o solo núcleos
** Cantidad de memoria: por nodo o por CPU (lógica)
** Tiempo necesario para que las tareas del usuario completen su trabajo
* Una partición de nodo solicitada (cola de trabajos)
* Un nivel de calidad de servicio (QoS) solicitado que otorga a los usuarios accesos específicos
* Una cuenta solicitada con recursos limitados

De manera predeterminada, los usuarios envían trabajos a una partición particular (marcada como tal para todos los usuarios) y bajo una cuenta particular (preestablecida por usuario).

== Particiones SLURM ==

<table class="wikitable" style="width: 60%;">
<tr>
<td><b>Nombre Particion</b></td>
<td><b>Nodos</b></td>
<td><b>CPUs</b></td>
<td><b>RAM</b></td>
<td><b>Descripción</b>
</td></tr>
<tr>
<td>main</td>
<td>27</td>
<td>256</td>
<td>768GB</td>
<td>
</td></tr>
<tr>
<td>general</td>
<td>48</td>
<td>44</td>
<td>187GB</td>
<td>
</td></tr>
<tr>
<td>largemem</td>
<td>9</td>
<td>44</td>
<td>765GB</td>
<td>
</td></tr>
<tr>
<td>v100</td>
<td>2</td>
<td>44</td>
<td>187GB</td>
<td>4 GPUs Nvidia Tesla V100.
</td></tr>
<tr>
<td>mi100</td>
<td>1</td>
<td>128</td>
<td>502GB</td>
<td>2 GPUs AMD Instinct MI100.
</td></tr>
<tr>
<td>debug</td>
<td>4</td>
<td>20</td>
<td>59GB</td>
<td>Destinados a pruebas de máximo 30 minutos.
</td></tr></table>

== Introducción a los comandos slurm ==
<table class="wikitable" style="width: 60%;">
<td><b>Comando SLURM</b></td>
<td><b>Descripción</b>
</td></tr>
<tr>
<td>srun</td>
<td>ejecutar un comando en nodos de cómputo asignados.
</td></tr>
<tr>
<td>sbatch</td>
<td>presentar un script de trabajo
</td></tr>
<tr>
<td>squeue</td>
<td>Mostrar estado de los trabajos en la cola.
</td></tr>
<tr>
<td>scancel</td>
<td>eliminar un trabajo.
</td></tr>
<tr>
<td>sinfo</td>
<td>Muestra el estado de los nodos de cómputo.
</td></tr></table>
Estos son los comandos básicos utilizados para realizar la mayoría de las operaciones básicas con SLURM.

=== Estado de nodos ===
Para consultar el uso de nuestra infraestructura y qué particiones están más libres, le recomendamos el comando sinfo:

<pre># sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
all up infinite 16 mix cn[001,005-006,010,034-035,037,041,045,050,057,108,121],sn[012,016,037]
all up infinite 95 alloc cn[011-033,038-044,046-049,071-120],cnf[001-004],sn[001-011,038-041,043-044]
all up infinite 33 idle fn[001-009],gn[001-002],sn[018-035,045-048]
main* up infinite 20 alloc mn[001-011,014-022]
main* up infinite 7 idle [012-013,023-027]
debug up infinite 4 idle leftraru[1-2]
general up infinite 4 mix sn[012,016,037,042]
general up infinite 22 alloc sn[001-011,013-015,017,036,038-041,043-044]
general up infinite 22 idle sn[018-035,045-048]
largemem up infinite 9 idle fn[001-009]
v100 up infinite 2 idle gn[001-002]
mi100 up infinite 1 idle gna001
</pre>

Fijándose en el texto resaltado de la salida del comando sinfo, se puede comprobar que en la partición main hay 20 nodos que están completamente ocupados (estado alloc), 7 nodos que están libres (idle); por otro lado, en la partición general hay 22 nodos completamente ocupados, 4 parcialmente ocupados y 22 libres. Dado este escenario, está claro que debería de lanzar sus ejecuciones en los nodos de la partición general, por las razones anteriormente expuestas.

Para lanzar en la partición general, debe tener en cuenta que tiene que indicar en su script que se use dicha partición en vez de, probablemente, main. Por supuesto, en esta partición cambian las características técnicas, se pasan a tener 44 cores por nodo (en vez de 256 en main) y una capacidad RAM de 187GB (en vez de 768GB en main). Puede ver más información de las particiones en este link(agregar link), donde podrá revisar que con la inclusión de Guacolda hemos añadido nodos con hasta 765GB de memoria RAM y nodos con GPUs Nvidia Tesla V100 y AMD Instinct MI100 .

Para ver los nodos disponibles y poder determinar en que partición lanzar los trabajos se recomienda utilizar el siguiente comando.

<pre>[prueba@leftraru1 ~]$ sinfo -o "%10P %6D %10t %10m %c" -t idle| egrep "PARTITION|main|general|largemem|v100"
PARTITION NODES STATE MEMORY CPUS
main* 27 idle 768000 256
general 2 idle 187000 44
largemem 7 idle 765000 44
v100 1 idle 187000 44
mi100 1 idle 515047 128
</pre>

El comando anterior muestra que main tiene 27 nodos libres, en este caso es recomendado lanzar en en main para evitar que el trabajo quede en cola por falta de recursos en otros nodos.

Otro Ejemplo, se muestra sólo una partición específica

<pre>[prueba@leftraru1 ~]$ sinfo -p main
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
main* up infinite 15 mix mn[001-008,014-020]
main* up infinite 12 idle mn[009-013,021-027]
</pre>

=== Comprobación del estado de tareas ===
squeue - Muestra el estatus de los trabajos

<pre>squeue # tus trabajos
squeue -u <username> # trabajos por usuario <username>
</pre>

squeue: Comprobar estados de los trabajos

<div style="" class="mw-highlight mw-content-ltr" dir="ltr">
<pre>
JOBID PARTITION NAME USER ST TIME NODES NODELIST(REASON)
13951858_1 general test1 test1 R 1-18:35:14 2 cn[009-010]
13951857_2 general test2 test1 R 1-18:36:11 2 cn[099-100]
13956453 gpu test3 test3 R 1-03:42:08 1 cn039
13956449 largemem test4 test4 R 1-05:42:08 1 cn044
</pre>

Puede utilizar squeue para saber el estado de una o varias de sus tareas

<pre>
$ squeue -o "%.15i %.6P %.8j %.20S %.11M %.11L %.20V %.10Q %.4C %.2D %.6m" -S -t,-Q
JOBID PARTIT NAME START_TIME TIME TIME_LEFT SUBMIT_TIME PRIORITY CPUS NO MIN_ME
10837561 general TEST1 2018-06-18T18:51:01 19:00:31 2-04:59:29 2018-06-18T18:51:01 119972 1 1 1000M
10838562 general TEST2 2018-06-19T11:30:47 2:20:45 2-21:39:15 2018-06-19T11:30:46 119946 1 1 1000M
</pre>

para mas opciones puede revisar con el comando [https://slurm.schedmd.com/squeue.html man squeue] las opciones restantes.

=== Códigos de ESTADO de los trabajos ===

Los trabajos suelen pasar por varios estados durante su ejecución. Los estados típicos son PENDIENTE, EN EJECUCIÓN, SUSPENDIDO, FINALIZANDO y TERMINADO. A continuación se explica cada estado.

'''BF''' BOOT_FAIL
Trabajo finalizado debido a un fallo de arranque, normalmente debido a un fallo de hardware (por ejemplo, no se puede arrancar el nodo o bloque y el trabajo no se puede volver a poner en cola).

'''CA''' CANCELADO
El trabajo ha sido cancelado explícitamente por el usuario o el administrador del sistema. El trabajo puede haberse iniciado o no.

'''CD''' TERMINADO
El trabajo ha terminado todos los procesos en todos los nodos con un código de salida de cero.

'''CF''' CONFIGURANDO
Al trabajo se le han asignado recursos, pero están esperando a que estén listos para su uso (por ejemplo, arrancando).

'''CG''' COMPLETANDO
El trabajo está en proceso de finalización. Algunos procesos en algunos nodos pueden estar aún activos.

'''DL''' FECHA LÍMITE
El trabajo ha finalizado en la fecha límite.

'''F''' FALLÓ
Trabajo finalizado con un código de salida distinto de cero u otra condición de fallo.

'''NF''' NODO_FAIL
Trabajo finalizado debido al fallo de uno o más nodos asignados.

'''OOM''' OUT_OF_MEMORY
El trabajo ha experimentado un error de memoria insuficiente.

'''PD''' PENDIENTE
El trabajo está pendiente de asignación de recursos.

'''PR''' PREEMPTED
El trabajo ha finalizado debido a una espera.

'''R''' EN MARCHA
El trabajo tiene actualmente una asignación.

'''RD''' RESV_DEL_HOLD
El trabajo se está reteniendo después de que se eliminara la reserva solicitada.

'''RF''' REQUEUE_FED
El trabajo está siendo solicitado por una federación.

'''RH''' REQUEUE_HOLD
Se está volviendo a poner en cola un trabajo retenido.

'''RQ''' REQUEUED
Se está poniendo en cola un trabajo que se está completando.

'''RS''' CAMBIO DE TAMAÑO
El trabajo está a punto de cambiar de tamaño.

'''RV''' REVOCADO
El trabajo se ha retirado del clúster debido a que otro clúster ha iniciado el trabajo.

'''SI''' SEÑALANDO
El trabajo está siendo señalizado.

'''SE''' SPECIAL_EXIT
El trabajo se ha puesto en cola en un estado especial. Este estado puede ser establecido por los usuarios, normalmente en EpilogSlurmctld, si el trabajo ha terminado con un valor de salida particular.

'''SO''' STAGE_OUT
El trabajo está preparando los archivos.

'''ST''' PARADO
El trabajo tiene una asignación, pero la ejecución se ha detenido con la señal SIGSTOP. Los CPUS han sido retenidos por este trabajo.

'''S''' SUSPENDIDO
El trabajo tiene una asignación, pero se ha suspendido la ejecución y se han liberado CPUs para otros trabajos.

'''TO''' TIMEOUT
El trabajo ha finalizado al alcanzar su límite de tiempo.

=== Cancelar un trabajo ===
Con scancel se puede cancelar un trabajo en ejecución
<pre>scancel <jobID> # Matar proceso <jobID>. (puede obtener el ID del job con "squeue")
scancel -u <username> # Matar proceso por usuario <username>.
</pre>
<pre>[prueba@leftraru1 ~]$ squeue -u prueba
JOBID PARTITION NAME USER ST TIME NODES NODELIST(REASON)
45594 main TEST prueba R 0:59 3 mn[001-003]
</pre>
<pre>[prueba@leftraru1 ~]$ scancel 45594
[prueba@leftraru1 ~]$ squeue -u prueba
JOBID PARTITION NAME USER ST TIME NODES NODELIST(REASON)
[prueba@leftraru1 ~]$
</pre>

=== Ver estado de trabajos ===
Para revisar el detalle de las opciones de un trabajo: scontrol show job

<pre>
$ scontrol show job 10837561
JobId=10837561 JobName=TEST1
UserId=usuario(1000) GroupId=group(1000) MCS_label=N/A
Priority=1100 Nice=0 Account=account QOS=120
JobState=RUNNING Reason=None Dependency=(null)
Requeue=0 Restarts=0 BatchFlag=1 Reboot=0 ExitCode=0:0
DerivedExitCode=0:0
RunTime=19:03:08 TimeLimit=3-00:00:00 TimeMin=N/A
SubmitTime=2018-06-18T18:51:01 EligibleTime=2018-06-18T18:51:01
StartTime=2018-06-18T18:51:01 EndTime=2018-06-21T18:51:01 Deadline=N/A
PreemptTime=None SuspendTime=None SecsPreSuspend=0
Partition=main AllocNode:Sid=leftraru2:5471
ReqNodeList=(null) ExcNodeList=(null)
NodeList=cn021
BatchHost=cn021
NumNodes=1 NumCPUs=1 NumTasks=1 CPUs/Task=1 ReqB:S:C:T=0:0:*:*
TRES=cpu=1,mem=1000M,node=1
Socks/Node=* NtasksPerN:B:S:C=1:0:*:* CoreSpec=*
Nodes=cn021 CPU_IDs=1 Mem=1000 GRES_IDX=
MinCPUsNode=1 MinMemoryCPU=1000M MinTmpDiskNode=0
Features=(null) DelayBoot=00:00:00
Gres=(null) Reservation=(null)
OverSubscribe=OK Contiguous=0 Licenses=matlab Network=(null)
Command=/home/usuario/script.sh
WorkDir=/home/usuario/
StdErr=/home/usuario/10837561_%x.err
StdIn=/dev/null
StdOut=/home/usuario/10837561_%x.out
Power=
BatchScript=
</pre>

Para ver el script asociado a un trabajo: scontrol write batch_script <job_id> -

<pre>
$ scontrol write batch_script 10837561 -
#!/bin/bash
#SBATCH -J nombre_del_trabajo
#SBATCH -p main
#SBATCH -n 1
#SBATCH --ntasks-per-node=1
#SBATCH --mail-user=usaurio@correo.cl
#SBATCH --mail-type=ALL
#SBATCH -o nombre_del_trabajo%j_%x.out
#SBATCH -e nombre_del_trabajo%j_%x.err
#SBATCH --license=matlab

ml MATLAB/2017a

matlab -nodisplay -nosplash -nodesktop < programa.m
</pre>

== Ejecutando trabajos ==
Actualmente contamos con 2 metodos de enviar trabajos bajo SLURM: '''sbatch''' and '''srun'''. A veces puede ser ventajoso ejecutar un solo comando en el clúster como prueba o realizar rápidamente una operación con recursos adicionales. 'srun' permite a los usuarios hacer esto, y comparte las mismas variables que 'sbatch' . STDOUT y STDERR para un trabajo 'srun' serán redirigidos a la pantalla del usuario. Ctrl-C cancelará un trabajo srun. '''sbatch''' enviará un script de trabajo para que lo ejecute el clúster. Los scripts de trabajo bajo SLURM son simplemente scripts de shell (* .sh) con un conjunto de solicitudes de recursos en la parte superior del script.

Uso básico de srun:

<pre>
srun <algúnComando>
</pre>

Ejemplo de salida (ejecutando el comando "hostname" para saber en que nodo se está ejecutando):
<pre> $ srun hostname
cn003
</pre>

Para enviar un script de trabajo a SLURM:
<pre>sbatch nombreScript.sh</pre>

Example output:
<pre>$ sbatch test-job.sh
Submitted batch job 1169</pre>

=== Variables Slurm ===
Las variables en esta sección son obligatorias, y SLURM las determina para determinar dónde y cuándo se ejecutarán sus trabajos. Si no asigna un valor para estos, el planificador asignará a sus trabajos el valor predeterminado. Si no solicita específicamente recursos para un trabajo, se le asignará un conjunto de recursos predeterminados. Para obtener una lista de todas las variables disponibles, consulte la documentación de SLURM en http://slurm.schedmd.com/sbatch.html. Las variables de este artículo estaban cubiertas porque eran las más relevantes para los casos de uso típicos.

<table class="wikitable" style="width: 100%;">
<tr>
<td><b>Comando SLURM</b></td>
<td><b>Descripción</b>
</td></tr>
<tr>
<td>--mem-per-cpu=<megabytes></td>
<td>Memoria requerida para el trabajo por CPU (en MegaBytes). El valor predeterminado es 1024 MB.
</td></tr>
<tr>
<td>-p <partition>, --partition=<partition></td>
<td>Enviar un trabajo a una partición específica.
</td></tr>
<tr>
<td>-n, --ntasks=<cantidad de tareas></td>
<td>Número de tareas que serán asignadas para el trabajo.
</td></tr>
<tr>
<td>-c <cpus></td>
<td>Esta es la cantidad de CPU que necesita su trabajo. Tenga en cuenta que SLURM es relativamente generoso con las CPU, y el valor especificado aquí es el número "mínimo" de CPU que se asignará a su trabajo. Si hay CPU adicionales disponibles en un nodo más allá de lo solicitado, su trabajo recibirá esas CPU hasta que otros trabajos las necesiten. El valor predeterminado es 1 CPU. Intentar usar más CPU de las que se le asignaron dará como resultado que sus procesos adicionales se turnen en la misma CPU (ralentizando su trabajo).
</td></tr>
<tr>
<td>-J <name>, --jobname=<name></td>
<td>Especifica un nombre a tu trabajo.
</td></tr>
<tr>
<td>--mail-type=BEGIN,END,FAIL,ALL<b> and </b>--mail-user=<emailAddress></td>
<td>Enviar por correo electrónico cuando su trabajo comienza / termina / falla. Puede especificar varios valores para esto (separados por comas) si es necesario.
</td></tr>
<tr>
<td>-o <STDOUT_log>, --output=<STDOUT_log></td>
<td>Redirija la salida a los archivos de registro que especifique. Por defecto, ambos, STDOUT and STDERR son enviados a este archivo. Puedes especificar %j como parte del nombre de archivo de registro para indicar la ID del trabajo (como ejemplo, "#SBATCH -o ouptut_%j.o" redirigiría la salida a "output_123456.o").
</td></tr>
<tr>
<td>-e <STDERR_log>, --error=<STDERR_log></td>
<td>Redireccionar STDERR a un archivo separado. Funciona exactamente igual que "-o".
</td></tr>
<tr>
<td>-t <days-hours:minutes:seconds></td>
<td>Walltime para tu trabajo. La duración del Walltime es el tiempo que espera que su trabajo se ejecute.
</td></tr>
<tr>
<td>-a, --array=<índices></td>
<td>Envía una lista (arreglo) de trabajos identicos. Solo aplica para sbatch.
</td></tr></table>

Los scripts de trabajo especifican los recursos solicitados y otras consideraciones especiales con comentarios especiales "#SBATCH" en la parte superior de un script de trabajo. Aunque muchas de estas opciones son opcionales, las varibles que se ocupan de solicitudes de recursos (CPU, memoria y tiempo) son obligatorias. Todas las variables deben agregarse a sus scripts de la siguiente manera:

<pre>#SBATCH <variable></pre>
Para especificar un nombre al job, por ejemplo, debe agregar lo siguiente a su secuencia de comandos:

<pre>#SBATCH --job-name=nombreDeTrabajo</pre>

===Enviar un script===
<pre>
#!/bin/bash
#SBATCH -J example
#SBATCH -p general
#SBATCH -n 1
#SBATCH --output=example_%j.out
#SBATCH --error=example_%j.err
#SBATCH --mail-user=user@example.com
#SBATCH --mail-type=ALL
</pre>

Como debe comenzar un script en Linux:
<pre>
#!/bin/bash
</pre>

Nombre del trabajo:
<pre>
#SBATCH -J example
</pre>

Nombre la partición donde desea ejecutar el Job:
<pre>
#SBATCH -p general
</pre>

Número de tareas:
<pre>
#SBATCH -n 1
</pre>

Log de salida:
<pre>
#SBATCH -o example_%j.out
</pre>

Log de error:
<pre>
#SBATCH -e example_%j.err
</pre>

Correo para notificaciones:
<pre>
#SBATCH --mail-user=user@example.com
</pre>

Enviar correo en todos casos (verificar opciones arriba):
<pre>
#SBATCH --mail-type=ALL
</pre>

=== Programar tarea (uso de scrontab) ===
'''scrontab''' es una implementación del clásico planificador de tareas de linux '''crontab''' donde se guarda un listado de comandos a ejecutar en un tiempo determinado por el usuario.

Para acceder a scrontab utilice el siguiente comando:
<pre>
[prueba@leftraru1 ~]$ scrontab -e
</pre>

Esto le permitirá editar su archivo scrontab, asignando recursos como también el momento en que desea ejecutar su tarea. La estructura base a utilizar es la siguiente:
<pre>
#SCRON -J mi_tarea
#SCRON -p main
#SCRON -n 1
#SCRON -c 1
#SCRON --mem-per-cpu=2300
#SCRON --mail-user=foo@bar.com
#SCRON --mail-type=ALL
#SCRON -o mi_tarea_%j.out
#SCRON -e mi_tarea_%j.err
# Example of job definition:
# .---------------- minute (0 - 59)
# | .------------- hour (0 - 23)
# | | .---------- day of month (1 - 31)
# | | | .------- month (1 - 12) OR jan,feb,mar,apr ...
# | | | | .---- day of week (0 - 6) (Sunday=0 or 7) OR sun,mon,tue,wed,thu,fri,sat
# | | | | |
# * * * * * command to be executed
</pre>

* '''minute''' - Corresponde al minuto en que se va a ejecutar el script, valor de 0 a 59.
* '''hour''' - Hora de ejecución, formato 24 horas, valor de 0 a 23, donde 0 son las 12:00 AM.
* '''day of month''' - Día del mes, la tarea se puede ejecutar cada x día, valor de 1 a 31.
* '''month''' - La tarea se puede ejecutar cada x mes, valor de 1 a 12.
* '''day of week''' - Día de la semana, valor de 0 a 6, donde 0 es Domingo.
* '''command to be executed''' - Script a ejecutar por el usuario.

Ejemplo envío de trabajo slurm:

Para la asignación de recursos, utilizaremos la directriz '''#SCRON''', que utiliza los mismos parámetros usados por '''#SBATCH'''.

Luego de asignar los recursos debemos especificar el tiempo, en este caso la tarea será ejecutada todos los días cada 20 minutos, luego debemos indicar el script enviado por el usuario y guardamos los cambios en el archivo.

<pre>
*/20 * * * * /home/prueba/ejemplo/script.sh
</pre>

Es importante destacar que el script a lanzar '''/home/prueba/ejemplo/script.sh''' debe tener permisos de ejecución.

Para revisar el listado de tareas existentes en nuestro scrontab, ejecutamos el comando:
<pre>
[prueba@leftraru1 ~]$ scrontab -l
*/20 * * * * /home/prueba/ejemplo/script.sh
</pre>

Para borrar el contenido de nuestro scrontab:
<pre>
[prueba@leftraru1 ~]$ scrontab -r
</pre>

'''Información a considerar:'''

* Generar archivos de salida correctamente
** Para que el archivo error y out de tu script se generen en el directorio solicitado, ejemplo, /home/prueba/ejemplo/ en tu script debe estar presente el comando cd “/home/prueba/ejemplo”, esto hará que scrontab se posicione dentro del directorio de salida.
* Es distinto el tiempo de programar el envío de una tarea (scrontab) a que una tarea inicie en el clúster (running), ya que esto dependerá de los recursos libres que existan en ese momento en el clúster.
* Para revisar las tareas programadas debe ejecutar en cualquier nodo login el comando '''scrontab -l''' o revisar con el comando '''squeue''':

<pre>
[prueba@leftraru1 ~]$ squeue
24293471 main /home/eg prueba PD 0:00 1 (BeginTime)
</pre>

== Checkpointing ==
Es la acción de guardar el estado de un proceso en ejecución en un archivo de imagen de punto de control. Este proceso se puede reiniciar más tarde desde el archivo del punto de control, continuando la ejecución desde donde se detuvo, en la misma computadora o en una diferente.

=== ¿Por qué utilizarlo? ===
* Permite ejecuciones de tarea largas que superen el tiempo de ejecución permitido en el cluster (30 días)
* Estar preparados ante fallas del sistema que nos puedan hacer perder resultados de nuestras simulaciones

=== Utilización ===
Lo primero que debemos hacer en nuestro script es cargar el módulo de Mana:
<pre>
ml mana/3.0.0
</pre>
Este módulo provee 3 ejecutables que necesitaremos:

* '''mana_coordinator:''' Coordina los checkpoints entre los distintos procesos
* '''mana_launch:''' Inicia un proceso con checkpoint
* '''mana_restart:''' Reinicia la ejecución desde una imagen del checkpoint

Necesitaremos 2 scripts para trabajar con checkpoints: Inicio y reinicio

=== Script de inicio (inicio.sh) ===
<pre>
#!/bin/bash
##---------------SLURM Parameters - NLHPC ----------------
#SBATCH -J Testcheckpoint
#SBATCH -p general
#SBATCH -n 44
#SBATCH --ntasks-per-node=44
#SBATCH --mem-per-cpu=4363
#SBATCH --mail-user=test@nlhpc.cl
#SBATCH --mail-type=ALL
#SBATCH -o Testcheckpoint_%j.out
#SBATCH -e Testcheckpoint_%j.err

# ----------------Modules----------------------------
ml mana/3.0.0
# ----------------Command--------------------------
#Checkpointing cada 1 hora
mana_cooridinator -i3600
#Ejecutamos nuestra tarea con checkpointing
srun mana_launch ./ejecutable
</pre>

=== Script de reinicio (reinicio.sh) ===
<pre>
#!/bin/bash
##---------------SLURM Parameters - NLHPC ----------------
#SBATCH -J Testcheckpoint
#SBATCH -p general
#SBATCH -n 44
#SBATCH --ntasks-per-node=44
#SBATCH --mem-per-cpu=4363
#SBATCH --mail-user=test@nlhpc.cl
#SBATCH --mail-type=ALL
#SBATCH -o Testcheckpoint_%j.out
#SBATCH -e Testcheckpoint_%j.err

# ----------------Modules----------------------------
ml mana/3.0.0
# ----------------Command--------------------------
#Checkpointing cada 1 hora
mana_cooridinator -i3600
#Reiniciar nuestra tarea desde los archivos de checkpoint
srun mana_restart
</pre>

Para correr estos scripts se puede hacer utilizando la funcionalidad de dependencias de SLURM:
<pre>
[test@leftraru2 test]$ sbatch inicio.sh
Submitted batch job 23574685
[test@leftraru2 test]$ sbatch --dependency=afterok:23574685 reinicio.sh
</pre>

== Trabajos ==
=== Trabajos paralelos ===
Muchos de los trabajos que se ejecutan en un clúster de producción implicarán más de un procesador (CPU, núcleo). Dichos trabajos paralelos deben solicitar la cantidad de recursos necesarios a través de opciones adicionales. Los más comunes son:

Para diferentes tipos de trabajos paralelos, se especificarán diferentes opciones. Los trabajos paralelos más comunes son trabajos de MPI (memoria distribuida), trabajos de subprocesos múltiples (memoria compartida) y los llamados híbridos que son una combinación de los dos. Analicemos por separado con un n ejemplo para cada uno.

=== Ejecución de programas con MPI ===
MPI (interfaz de paso de mensajes) es la API de comunicación estándar para trabajos paralelos de memoria distribuida capaz de implementarse en un clúster. Para programar dicho trabajo, es necesario especificar la cantidad de nodos del clúster que se utilizarán y la cantidad de procesos (tareas) que se ejecutarán en cada nodo.

El siguiente es un ejemplo de ejecución de un programa compilado con Open MPI:

#!/bin/bash
#SBATCH -J example_mpi
#SBATCH -p general
#SBATCH -n 264
#SBATCH --ntasks-per-node=44
#SBATCH --output=example_%j.out
#SBATCH --error=example_%j.err
#SBATCH --mail-user=user@example.com
#SBATCH --mail-type=ALL

srun ./mpi_test
A continuacion se explica línea por líneael script.

Como empieza un shell script en Linux:
<pre>
#!/bin/bash
</pre>

Nombre del Job:
<pre>
#SBATCH -J example_mpi
</pre>

Nombre la particion donde se desea ejecutar el trabajo:
<pre>
#SBATCH -p general
</pre>

Número de tareas. Debe de ser un número múltiplo del número de CPUs máximo que tenga un node de la partición donde se lanza:
<pre>
#SBATCH -n 264
</pre>

Con esto se fuerza a que se lancen 44 tareas MPI en cada uno de los nodos, ocupando de este modo nodos completos. En este caso 6 nodos completos:
<pre>
#SBATCH --ntasks-per-node=44
</pre>

Log de salida:
<pre>
#SBATCH -o example_%j.out
</pre>

Log de error:
<pre>
#SBATCH -e example_%j.err
</pre>

Correo para notificaciones:
<pre>
#SBATCH --mail-user=user@example.com
</pre>

Envía correo en todos los casos:
<pre>
#SBATCH --mail-type=ALL
</pre>

Programa para ejecutar:
<pre>
srun ./mpi_test
</pre>

'''Nota''': no se carga específicamente el módulo "mpi" ya que se carga siempre por defecto.

Para enviarlo al clúster debe ejecutar el comando: ''sbatch script.sh''. El ejemplo anterior ejecutará una tarea OpenMPI con 264 procesos reservando 264 cores para ello.

=== Trabajos multiproceso OpenMP ===
Los trabajos paralelos diseñados para ejecutarse en un sistema multi-core (shared-memory) suelen ser "multi-threaded". La programación de un job de este tipo requiere especificar el número de núcleos que se utilizan para acomodar los subprocesos.

OpenMP es el conjunto común de variables de compilación para facilitar el desarrollo de programas multi-threaded. Un script típico de SLURM para un programa de este tipo se ve así:
<pre>
#!/bin/bash
#SBATCH -J OMPtest
#SBATCH -p general
#SBATCH -n 1
#SBATCH -c 44
#SBATCH --ntasks-per-node=44
#SBATCH --mem-per-cpu=1024
#SBATCH -o example_%j.out
#SBATCH -e example_%j.err
#SBATCH --mail-user=user@example.com
#SBATCH --mail-type=ALL

OMP_NUM_THREADS=$SLURM_CPUS_PER_TASK time ./omp-program
</pre>

Como debe comenzar un script en Linux:
<pre>
#!/bin/bash
</pre>

Nombre del Job:
<pre>
#SBATCH -J OMPtest
</pre>

Nombre la particion donde desea ejecutar el Job:
<pre>
#SBATCH -p general
</pre>

Número de trabajos:
<pre>
#SBATCH -n 1
</pre>

Número de tareas:
<pre>
#SBATCH -c 44
</pre>

Con esto se fuerza a que se agrupen las 44 tareas en un nodo (en OpenMP no hay comunicación entre nodos, por lo que todas las tareas deben estar en el mismo nodo o no funcionaría):
<pre>
#SBATCH --ntasks-per-node=44
</pre>

Memoria por core (MBytes):
<pre>
#SBATCH --mem-per-cpu=1024
</pre>

Log de salida:
<pre>
#SBATCH -o example_%j.out
</pre>

Log de error:
<pre>
#SBATCH -e example_%j.err
</pre>

Correo para notificaciones:
<pre>
#SBATCH --mail-user=user@example.com
</pre>

Enviar correo en todos los casos:
<pre>
#SBATCH --mail-type=ALL
</pre>

Programa para ejecutar:
<pre>
OMP_NUM_THREADS=$SLURM_CPUS_PER_TASK time ./omp-program
</pre>

Cuando se utiliza un programa OpenMP, el número de subprocesos (y, por lo tanto, el número requerido de núcleos) se especifica a través de la variable de entorno OMP_NUM_THREADS que, por lo tanto, aparece en el script frente a la llamada al programa. Lo estamos configurando en la variable interna SLURM_CPUS_PER_TASK que se establece a través de la opción "-c" (a 44 en nuestro ejemplo, que sería el número total de cores de un nodo de la partición "general").

La opción "-n" se mantiene en 1 para indicar un único trabajo principal que tiene 44 tareas. Para asegurarnos que todas las tareas se ejecutan en el mismo nodo, se añade la opción "--ntasks-per-node" con el máximo número de cores que tiene un nodo de la partición donde se está lanzando el trabajo.

=== Ejecución de tareas en GPUs ===
<pre>
#!/bin/bash
#SBATCH -J ejemplo_gpus
#SBATCH -p v100
#SBATCH -n 1
#SBATCH -o ejemplo_%j.out
#SBATCH -e ejemplo_%j.err
#SBATCH --mail-user=correo@gmail.com
#SBATCH --mail-type=ALL
#SBATCH --mem-per-cpu=4300
#SBATCH --gres=gpu:1

./programa
</pre>

Inicio de un bash script en Linux:
<pre>
#!/bin/bash
</pre>

Nombre del trabajo:
<pre>
#SBATCH -J ejemplo_gpus
</pre>

Nombre la partición donde se ejecuta el trabajo:
<pre>
#SBATCH --partition=v100
</pre>

Número de tareas:
<pre>
#SBATCH -n 1
</pre>

Log de salida:
<pre>
#SBATCH -o ejemplo_%j.out
</pre>

Log de error:
<pre>
#SBATCH -e ejemplo_%j.err
</pre>

Correo para notificaciones:
<pre>
#SBATCH --mail-user=user@example.com
</pre>

Enviar correo en todos los casos:
<pre>
#SBATCH --mail-type=ALL
</pre>

Memoria por CPU (MB):
<pre>
#SBATCH --mem-per-cpu=4365
</pre>

Cantidad utilizada de GPUs. El parámetro gpu:1 indica la cantidad de tarjetas a utilizar (cada nodo tiene 2 GPUs):
<pre>
#SBATCH --gres=gpu:1
</pre>

Programa para ejecutar:
<pre>
./programa
</pre>

=== Job Arrays ===
Cuando se ejecutan cientos o miles de simulaciones que utilizan la misma cantidad de recursos, puede ser una ventaja ejecutar estas simulaciones como un "job array". Los job array le permiten enviar miles de dichos trabajos (llamados "job steps") con un solo script. A cada simulación se le asignará un valor único para la variable de entorno SLURM_ARRAY_TASK_ID. Puede usar esta variable para leer parámetros para pasos individuales de una línea dada de un archivo.

=== Caso de uso de un Script Job Array (Gaussian) ===
Tenemos usuarios que actualmente envían varias simulaciones al clúster que son similares en cuanto al uso de recursos, pero, la diferencia es que solo cambia la entrada que le entregan al programa. Para esta situación, recomendamos hacer uso de un script Job Array.

En este ejemplo crearemos un script job array para el software Gaussian, el cual, realizará 63 simulaciones, cada una de estas utilizará 8 cores y podrá alcanzar un uso máximo de 8 Gb de memoria ram. Para este caso utilizaremos la partición slims donde cada nodo tiene 46 Gb de memoria ram y 20 cores.

Script:
<pre>
#!/bin/bash
# ----------------SLURM Parameters----------------
#SBATCH -J prueba
#SBATCH -p slims
#SBATCH -n 1
#SBATCH -c 8
#SBATCH --mem-per-cpu=1000
#SBATCH --mail-user=prueba@nlhpc.cl
#SBATCH --mail-type=ALL
#SBATCH --array=1-63
#SBATCH -o prueba_%A_%a.out
#SBATCH -e prueba_%A_%a.err
#-----------------Toolchain---------------------------
ml purge
ml intel/2019b
# ----------------Módulos-----------------------------
ml g16/B.01
# ----------------Comandos--------------------------
file=$(ls Child_10_*.com | sed -n ${SLURM_ARRAY_TASK_ID}p)
srun g16 $file
</pre>

'''
Descripción de comandos utilizados en script:'''

Inicio de un bash script en Linux:
<pre>
#!/bin/bash
</pre>

Nombre de la simulación:
<pre>
#SBATCH -J prueba
</pre>

Nombre la partición donde se ejecuta la simulación:
<pre>
#SBATCH -p slims
</pre>

Número de tareas (1 tarea va a ejecutar 63 simulaciones):
<pre>
#SBATCH -n 1
</pre>

Core’s por tareas (cada tarea utilizará un máximo 8 cores):
<pre>
#SBATCH -c 8
</pre>

Memoria ram por cpu (cada tarea utilizará un máximo 8 Gb de ram):
<pre>
#SBATCH –mem-per-cpu=1000
</pre>

Correo para activar el envío de notificaciones:
<pre>
#SBATCH --mail-user=prueba@nlhpc.cl
</pre>

Permitir envío de notificaciones:
<pre>
#SBATCH --mail-type=ALL
</pre>

Se generan 63 simulaciones diferentes:
<pre>
#SBATCH --array=1-63
</pre>

Log de salida: (ejemplo: prueba_18455017_1.out)

* %A corresponde al Job ID de nuestra tarea que le asignará Slurm → 18455017.
* %a corresponde a la simulación X de nuestra tarea que le asignará Slurm → 1.
<pre>
#SBATCH -o prueba_%A_%a.out
</pre>

Log de errores: (ejemplo: prueba_18455017_1.err)

* %A corresponde al Job ID de nuestra tarea que le asignará Slurm → 18455017.
* %a corresponde a la simulación X de nuestra tarea que le asignará Slurm → 1.

<pre>
#SBATCH -e prueba_%A_%a.err
Toolchain: en este apartado, limpiaremos nuestro entorno de software no deseados y luego escogemos la herramienta informática con la cual está compilado el software Gaussian (nosotros utilizamos el compilador Intel/2019b).

#-----------------Toolchain---------------------------
ml purge
ml intel/2019b
Módulos: cargamos el software Gaussian versión 16/B.0.

# ----------------Módulos-----------------------------
ml g16/B.01
Comandos: aquí definimos los comandos a ejecutar.

# ----------------Comandos--------------------------
file=$(ls Child_10_*.com | sed -n ${SLURM_ARRAY_TASK_ID}p)
srun g16 $file
</pre>
file= variable que va a listar los archivos de entrada que comiencen por Child_10_ y terminen en .com

[[Archivo:Child.png|no]]

sed -n ${SLURM_ARRAY_TASK_ID}p) ← Sed imprimirá las líneas de cada archivo de entrada y la variable $SLURM_ARRAY_TASK_ID asumirá estas entradas como matriz de simulación en nuestro job array, en este ejemplo tenemos 63 archivos de entrada.

Para más detalles sobre los archivos stdin, stdout y stderr de una simulación % A será reemplazado por el valor de SLURM_ARRAY_JOB_ID que es el Job ID de nuestra tarea y %a será reemplazado por el valor de SLURM_ARRAY_TASK_ID que corresponde a la simulación X de nuestra tarea.

Srun g16 $file: ejecutará el comando gaussian g16 interpretando la variable $file en los nodos de cómputo asignados.

Enviar el script:
<pre>
[prueba@leftraru1 ~]$ sbatch prueba.sh
</pre>

=== Ejecución de una tarea que ocupa mucha RAM por CPU ===
Debemos tener en cuenta que la RAM que SLURM reserva por defecto son 1000 MB. Un típico error de cancelación de tarea por falta de memoria es el siguiente:
<pre>
/tmp/slurmd/job136839939/slurm_script: line 15: 23547 Killed ./programa.sh
slurmstepd: error: Detected 1 oom-kill event(s) in step 136839939.batch cgroup. Some of your processes
may have been killed by the cgroup out-of-memory handler.
</pre>

Si su tarea ocupa más de la memoria por defecto, puede utilizar el siguiente parámetro:
<pre>
#SBATCH --mem-per-cpu=2300 #Máxima RAM por CPU
</pre>
Esto hará que SLURM reserve más RAM por CPU para sus tareas.

Tenga en cuenta que nuestros nodos tienen 46 GB de memoria RAM (Partición slims), 187 GB (Partición general) y 765 GB (Partición largemem) por nodo. [https://wiki.nlhpc.cl/Hardware_Disponible Más información].

Otra forma de reservar memoria es utilizando el siguiente parámetro:

<pre>
#SBATCH --mem=2300
</pre>
En este caso SLURM realizará una reserva de memoria de 2300 MB pero por la totalidad del trabajo.

Los parámetros anteriores al igual que el número de CPUs que se van a usar, hay que afinarlos lo mejor posible. Para ello lo que se puede hacer es hacer pruebas en los nodos logins, sin lanzar en las colas, y así estudiar el uso de RAM y CPU por parte de sus procesos.

=== Ejecución de una tarea con Dependencias ===
Las dependencias de trabajos se utilizan para aplazar el inicio de un trabajo hasta que se satisfagan las dependencias especificadas. Se especifican con la opción --dependency en el siguiente formato:
<pre>
sbatch --dependency=<type:job_id[:job_id][,type:job_id[:job_id]]> ...
</pre>
Los tipos de dependencias son las siguientes:

* '''after''':jobid[:jobid...] - el trabajo puede empezar después de que los trabajos especificados comiencen
* '''afterany''':jobid[:jobid...] - el trabajo puede empezar después de que los trabajos especificados terminen
* '''afternotok''':jobid[:jobid...] - el trabajo puede empezar después que los trabajos especificados terminan fallidamente
* '''afterok''':jobid[:jobid...] - el trabajo puede empezar después que los trabajos especificados terminan exitósamente

La manera más simple de usar una dependencia del tipo afterok:
<pre>
[prueba@leftraru1 ~]$ sbatch job1.sh
Submitted batch job 21363626
[prueba@leftraru1 ~]$ sbatch --dependency=afterok:21363626 job2.sh
</pre>

Ahora cuando job1.sh termine correctamente, el job2.sh entrará en ejecución. Si job1.sh termina fallidamente, job2.sh no entrará en ejecución nunca pero sí quedará en cola (debe cancelarse manualmente el trabajo).

== Prioridad de tarea ==
Cómo ver la prioridad del trabajo. Los factores que determinan la prioridad del trabajo, incluyendo la fórmula y pesos.

=== Factores que determinan prioridad de tarea ===
<table class="wikitable" style="width: 60%;">
<tr>
<td><b>Comando SLURM</b></td>
<td><b>Descripción</b>
</td></tr>
<tr>
<td>Edad</td>
<td>la cantidad de tiempo que el trabajo ha estado esperando en la cola.
</td></tr>
<tr>
<td>Tamaño de la tarea</td>
<td>número de nodos solicitados por el trabajo.
</td></tr>
<tr>
<td>Partición</td>
<td>prioridad para una partición determinada.
</td></tr>
<tr>
<td>Prioridad Baja</td>
<td>Mientras más tareas se ejecuten en el cluster, menor será la prioridad.
</td></tr>
<tr>
<td>Prioridad Alta</td>
<td>Mientras menos tareas se ejecuten en el clúster, más alta es la prioridad.
</td></tr></table>

== Prioridad de tarea ==
Cómo ver la prioridad del trabajo. Los factores que determinan la prioridad del trabajo, incluyendo la fórmula y pesos.

=== Factores que determinan prioridad de tarea ===
* Edad - la cantidad de tiempo que el trabajo ha estado esperando en la cola
* Tamaño Oficio - número de nodos solicitados por el trabajo
* Partición - prioridad para una partición determinada
* Contribución de prioridades basada en los recursos informáticos utilizados por los miembros de un grupo de investigación en los últimos 30 días - Fairshare.
* Mientras más tareas se ejecuten en el cluster, menor será la prioridad.
* Mientras menos tareas se ejecuten en el clúster, más alta es la prioridad.
Fórmula Prioridad de tarea
<pre>
Job_priority =
(PriorityWeightAge) * (age_factor) +
(PriorityWeightFairshare) * (fair-share_factor) +
(PriorityWeightJobSize) * (job_size_factor) +
(PriorityWeightPartition) * (partition_factor) +
(PriorityWeightQOS) * (QOS_factor)
</pre>

== Visualización de sus Tareas ==
Si Ud. necesita visualizar información acerca de sus tareas de forma interactiva, puede utilizar el comando smap:

smap -i 3

[[Archivo:Smap.png|no|700px]]

De esta forma, tendrá una actualización cada 3 segundos de sus tareas en ejecución incluyendo los nodos en los cuales se encuentran ejecutándose.

== Bibliografía ==
[http://slurm.schedmd.com/documentation.html Manual Oficial de Slurm]

[https://slurm.schedmd.com/scrontab.html Documentación scrontab]

SISTEMA GESTOR DE RECURSOS

2024-04-29T22:01:39Z

Jmorales: /* Ver estado de trabajos */

== SLURM Workload Manager ==
Es un sistema de programación de trabajos y gestión de clústeres de código abierto, tolerante a fallas y altamente escalable para clústeres Linux grandes y pequeños.

Como administrador de carga de trabajo de clúster, Slurm tiene tres funciones clave. Primero, asigna acceso exclusivo y / o no exclusivo a los recursos (nodos de cómputo) a los usuarios durante un período de tiempo para que puedan realizar el trabajo. En segundo lugar, proporciona un marco para iniciar, ejecutar y monitorear el trabajo (normalmente un trabajo paralelo) en el conjunto de nodos asignados. Finalmente, arbitra la contención de recursos mediante la gestión de una cola de trabajo pendiente.

SLURM es el gestor de colas instalado en muchos de los súper computadores del [https://www.top500.org/ TOP500], y también en el clúster del NLHPC. Si Ud. quiere lanzar tareas dentro de Leftaru, debe hacerlo a través de Slurm.

== Conceptos clave ==
SLURM gestiona trabajos de usuario que tienen las siguientes características clave:

* Conjunto de recursos solicitados:
** Número de recursos informáticos: nodos (incluidas todas sus CPUs y núcleos) o CPUs (incluidos todos sus núcleos) o solo núcleos
** Cantidad de memoria: por nodo o por CPU (lógica)
** Tiempo necesario para que las tareas del usuario completen su trabajo
* Una partición de nodo solicitada (cola de trabajos)
* Un nivel de calidad de servicio (QoS) solicitado que otorga a los usuarios accesos específicos
* Una cuenta solicitada con recursos limitados

De manera predeterminada, los usuarios envían trabajos a una partición particular (marcada como tal para todos los usuarios) y bajo una cuenta particular (preestablecida por usuario).

== Particiones SLURM ==

<table class="wikitable" style="width: 60%;">
<tr>
<td><b>Nombre Particion</b></td>
<td><b>Nodos</b></td>
<td><b>CPUs</b></td>
<td><b>RAM</b></td>
<td><b>Descripción</b>
</td></tr>
<tr>
<td>main</td>
<td>27</td>
<td>256</td>
<td>768GB</td>
<td>
</td></tr>
<tr>
<td>general</td>
<td>48</td>
<td>44</td>
<td>187GB</td>
<td>
</td></tr>
<tr>
<td>largemem</td>
<td>9</td>
<td>44</td>
<td>765GB</td>
<td>
</td></tr>
<tr>
<td>v100</td>
<td>2</td>
<td>44</td>
<td>187GB</td>
<td>4 GPUs Nvidia Tesla V100.
</td></tr>
<tr>
<td>mi100</td>
<td>1</td>
<td>128</td>
<td>502GB</td>
<td>2 GPUs AMD Instinct MI100.
</td></tr>
<tr>
<td>debug</td>
<td>4</td>
<td>20</td>
<td>59GB</td>
<td>Destinados a pruebas de máximo 30 minutos.
</td></tr></table>

== Introducción a los comandos slurm ==
<table class="wikitable" style="width: 60%;">
<td><b>Comando SLURM</b></td>
<td><b>Descripción</b>
</td></tr>
<tr>
<td>srun</td>
<td>ejecutar un comando en nodos de cómputo asignados.
</td></tr>
<tr>
<td>sbatch</td>
<td>presentar un script de trabajo
</td></tr>
<tr>
<td>squeue</td>
<td>Mostrar estado de los trabajos en la cola.
</td></tr>
<tr>
<td>scancel</td>
<td>eliminar un trabajo.
</td></tr>
<tr>
<td>sinfo</td>
<td>Muestra el estado de los nodos de cómputo.
</td></tr></table>
Estos son los comandos básicos utilizados para realizar la mayoría de las operaciones básicas con SLURM.

=== Estado de nodos ===
Para consultar el uso de nuestra infraestructura y qué particiones están más libres, le recomendamos el comando sinfo:

<pre># sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
all up infinite 16 mix cn[001,005-006,010,034-035,037,041,045,050,057,108,121],sn[012,016,037]
all up infinite 95 alloc cn[011-033,038-044,046-049,071-120],cnf[001-004],sn[001-011,038-041,043-044]
all up infinite 33 idle fn[001-009],gn[001-002],sn[018-035,045-048]
main* up infinite 20 alloc mn[001-011,014-022]
main* up infinite 7 idle [012-013,023-027]
debug up infinite 4 idle leftraru[1-2]
general up infinite 4 mix sn[012,016,037,042]
general up infinite 22 alloc sn[001-011,013-015,017,036,038-041,043-044]
general up infinite 22 idle sn[018-035,045-048]
largemem up infinite 9 idle fn[001-009]
v100 up infinite 2 idle gn[001-002]
mi100 up infinite 1 idle gna001
</pre>

Fijándose en el texto resaltado de la salida del comando sinfo, se puede comprobar que en la partición main hay 20 nodos que están completamente ocupados (estado alloc), 7 nodos que están libres (idle); por otro lado, en la partición general hay 22 nodos completamente ocupados, 4 parcialmente ocupados y 22 libres. Dado este escenario, está claro que debería de lanzar sus ejecuciones en los nodos de la partición general, por las razones anteriormente expuestas.

Para lanzar en la partición general, debe tener en cuenta que tiene que indicar en su script que se use dicha partición en vez de, probablemente, main. Por supuesto, en esta partición cambian las características técnicas, se pasan a tener 44 cores por nodo (en vez de 256 en main) y una capacidad RAM de 187GB (en vez de 768GB en main). Puede ver más información de las particiones en este link(agregar link), donde podrá revisar que con la inclusión de Guacolda hemos añadido nodos con hasta 765GB de memoria RAM y nodos con GPUs Nvidia Tesla V100 y AMD Instinct MI100 .

Para ver los nodos disponibles y poder determinar en que partición lanzar los trabajos se recomienda utilizar el siguiente comando.

<pre>[prueba@leftraru1 ~]$ sinfo -o "%10P %6D %10t %10m %c" -t idle| egrep "PARTITION|main|general|largemem|v100"
PARTITION NODES STATE MEMORY CPUS
main* 27 idle 768000 256
general 2 idle 187000 44
largemem 7 idle 765000 44
v100 1 idle 187000 44
mi100 1 idle 515047 128
</pre>

El comando anterior muestra que main tiene 27 nodos libres, en este caso es recomendado lanzar en en main para evitar que el trabajo quede en cola por falta de recursos en otros nodos.

Otro Ejemplo, se muestra sólo una partición específica

<pre>[prueba@leftraru1 ~]$ sinfo -p main
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
main* up infinite 15 mix mn[001-008,014-020]
main* up infinite 12 idle mn[009-013,021-027]
</pre>

=== Comprobación del estado de tareas ===
squeue - Muestra el estatus de los trabajos

<pre>squeue # tus trabajos
squeue -u <username> # trabajos por usuario <username>
</pre>

squeue: Comprobar estados de los trabajos

<div style="" class="mw-highlight mw-content-ltr" dir="ltr">
<pre>
JOBID PARTITION NAME USER ST TIME NODES NODELIST(REASON)
13951858_1 general test1 test1 R 1-18:35:14 2 cn[009-010]
13951857_2 general test2 test1 R 1-18:36:11 2 cn[099-100]
13956453 gpu test3 test3 R 1-03:42:08 1 cn039
13956449 largemem test4 test4 R 1-05:42:08 1 cn044
</pre>

Puede utilizar squeue para saber el estado de una o varias de sus tareas

<pre>
$ squeue -o "%.15i %.6P %.8j %.20S %.11M %.11L %.20V %.10Q %.4C %.2D %.6m" -S -t,-Q
JOBID PARTIT NAME START_TIME TIME TIME_LEFT SUBMIT_TIME PRIORITY CPUS NO MIN_ME
10837561 general TEST1 2018-06-18T18:51:01 19:00:31 2-04:59:29 2018-06-18T18:51:01 119972 1 1 1000M
10838562 general TEST2 2018-06-19T11:30:47 2:20:45 2-21:39:15 2018-06-19T11:30:46 119946 1 1 1000M
</pre>

para mas opciones puede revisar con el comando [https://slurm.schedmd.com/squeue.html man squeue] las opciones restantes.

=== Códigos de ESTADO de los trabajos ===

Los trabajos suelen pasar por varios estados durante su ejecución. Los estados típicos son PENDIENTE, EN EJECUCIÓN, SUSPENDIDO, FINALIZANDO y TERMINADO. A continuación se explica cada estado.

'''BF''' BOOT_FAIL
Trabajo finalizado debido a un fallo de arranque, normalmente debido a un fallo de hardware (por ejemplo, no se puede arrancar el nodo o bloque y el trabajo no se puede volver a poner en cola).

'''CA''' CANCELADO
El trabajo ha sido cancelado explícitamente por el usuario o el administrador del sistema. El trabajo puede haberse iniciado o no.

'''CD''' TERMINADO
El trabajo ha terminado todos los procesos en todos los nodos con un código de salida de cero.

'''CF''' CONFIGURANDO
Al trabajo se le han asignado recursos, pero están esperando a que estén listos para su uso (por ejemplo, arrancando).

'''CG''' COMPLETANDO
El trabajo está en proceso de finalización. Algunos procesos en algunos nodos pueden estar aún activos.

'''DL''' FECHA LÍMITE
El trabajo ha finalizado en la fecha límite.

'''F''' FALLÓ
Trabajo finalizado con un código de salida distinto de cero u otra condición de fallo.

'''NF''' NODO_FAIL
Trabajo finalizado debido al fallo de uno o más nodos asignados.

'''OOM''' OUT_OF_MEMORY
El trabajo ha experimentado un error de memoria insuficiente.

'''PD''' PENDIENTE
El trabajo está pendiente de asignación de recursos.

'''PR''' PREEMPTED
El trabajo ha finalizado debido a una espera.

'''R''' EN MARCHA
El trabajo tiene actualmente una asignación.

'''RD''' RESV_DEL_HOLD
El trabajo se está reteniendo después de que se eliminara la reserva solicitada.

'''RF''' REQUEUE_FED
El trabajo está siendo solicitado por una federación.

'''RH''' REQUEUE_HOLD
Se está volviendo a poner en cola un trabajo retenido.

'''RQ''' REQUEUED
Se está poniendo en cola un trabajo que se está completando.

'''RS''' CAMBIO DE TAMAÑO
El trabajo está a punto de cambiar de tamaño.

'''RV''' REVOCADO
El trabajo se ha retirado del clúster debido a que otro clúster ha iniciado el trabajo.

'''SI''' SEÑALANDO
El trabajo está siendo señalizado.

'''SE''' SPECIAL_EXIT
El trabajo se ha puesto en cola en un estado especial. Este estado puede ser establecido por los usuarios, normalmente en EpilogSlurmctld, si el trabajo ha terminado con un valor de salida particular.

'''SO''' STAGE_OUT
El trabajo está preparando los archivos.

'''ST''' PARADO
El trabajo tiene una asignación, pero la ejecución se ha detenido con la señal SIGSTOP. Los CPUS han sido retenidos por este trabajo.

'''S''' SUSPENDIDO
El trabajo tiene una asignación, pero se ha suspendido la ejecución y se han liberado CPUs para otros trabajos.

'''TO''' TIMEOUT
El trabajo ha finalizado al alcanzar su límite de tiempo.

=== Cancelar un trabajo ===
Con scancel se puede cancelar un trabajo en ejecución
<pre>scancel <jobID> # Matar proceso <jobID>. (puede obtener el ID del job con "squeue")
scancel -u <username> # Matar proceso por usuario <username>.
</pre>
<pre>[prueba@leftraru1 ~]$ squeue -u prueba
JOBID PARTITION NAME USER ST TIME NODES NODELIST(REASON)
45594 main TEST prueba R 0:59 3 mn[001-003]
</pre>
<pre>[prueba@leftraru1 ~]$ scancel 45594
[prueba@leftraru1 ~]$ squeue -u prueba
JOBID PARTITION NAME USER ST TIME NODES NODELIST(REASON)
[prueba@leftraru1 ~]$
</pre>

=== Ver estado de trabajos ===
Para revisar el detalle de las opciones de un trabajo: scontrol show job

<pre>
$ scontrol show job 10837561
JobId=10837561 JobName=TEST1
UserId=usuario(1000) GroupId=group(1000) MCS_label=N/A
Priority=1100 Nice=0 Account=account QOS=120
JobState=RUNNING Reason=None Dependency=(null)
Requeue=0 Restarts=0 BatchFlag=1 Reboot=0 ExitCode=0:0
DerivedExitCode=0:0
RunTime=19:03:08 TimeLimit=3-00:00:00 TimeMin=N/A
SubmitTime=2018-06-18T18:51:01 EligibleTime=2018-06-18T18:51:01
StartTime=2018-06-18T18:51:01 EndTime=2018-06-21T18:51:01 Deadline=N/A
PreemptTime=None SuspendTime=None SecsPreSuspend=0
Partition=main AllocNode:Sid=leftraru2:5471
ReqNodeList=(null) ExcNodeList=(null)
NodeList=cn021
BatchHost=cn021
NumNodes=1 NumCPUs=1 NumTasks=1 CPUs/Task=1 ReqB:S:C:T=0:0:*:*
TRES=cpu=1,mem=1000M,node=1
Socks/Node=* NtasksPerN:B:S:C=1:0:*:* CoreSpec=*
Nodes=cn021 CPU_IDs=1 Mem=1000 GRES_IDX=
MinCPUsNode=1 MinMemoryCPU=1000M MinTmpDiskNode=0
Features=(null) DelayBoot=00:00:00
Gres=(null) Reservation=(null)
OverSubscribe=OK Contiguous=0 Licenses=matlab Network=(null)
Command=/home/usuario/script.sh
WorkDir=/home/usuario/
StdErr=/home/usuario/10837561_%x.err
StdIn=/dev/null
StdOut=/home/usuario/10837561_%x.out
Power=
BatchScript=
</pre>

Para ver el script asociado a un trabajo: scontrol write batch_script <job_id> -

<pre>
$ scontrol write batch_script 10837561 -
#!/bin/bash
#SBATCH -J nombre_del_trabajo
#SBATCH -p main
#SBATCH -n 1
#SBATCH --ntasks-per-node=1
#SBATCH --mail-user=usaurio@correo.cl
#SBATCH --mail-type=ALL
#SBATCH -o nombre_del_trabajo%j_%x.out
#SBATCH -e nombre_del_trabajo%j_%x.err
#SBATCH --license=matlab

ml MATLAB/2017a

matlab -nodisplay -nosplash -nodesktop < programa.m
</pre>

== Ejecutando trabajos ==
Actualmente contamos con 2 metodos de enviar trabajos bajo SLURM: '''sbatch''' and '''srun'''. A veces puede ser ventajoso ejecutar un solo comando en el clúster como prueba o realizar rápidamente una operación con recursos adicionales. 'srun' permite a los usuarios hacer esto, y comparte las mismas variables que 'sbatch' . STDOUT y STDERR para un trabajo 'srun' serán redirigidos a la pantalla del usuario. Ctrl-C cancelará un trabajo srun. '''sbatch''' enviará un script de trabajo para que lo ejecute el clúster. Los scripts de trabajo bajo SLURM son simplemente scripts de shell (* .sh) con un conjunto de solicitudes de recursos en la parte superior del script.

Uso básico de srun:

<pre>
srun <algúnComando>
</pre>

Ejemplo de salida (ejecutando el comando "hostname" para saber en que nodo se está ejecutando):
<pre> $ srun hostname
cn003
</pre>

Para enviar un script de trabajo a SLURM:
<pre>sbatch nombreScript.sh</pre>

Example output:
<pre>$ sbatch test-job.sh
Submitted batch job 1169</pre>

=== Variables Slurm ===
Las variables en esta sección son obligatorias, y SLURM las determina para determinar dónde y cuándo se ejecutarán sus trabajos. Si no asigna un valor para estos, el planificador asignará a sus trabajos el valor predeterminado. Si no solicita específicamente recursos para un trabajo, se le asignará un conjunto de recursos predeterminados. Para obtener una lista de todas las variables disponibles, consulte la documentación de SLURM en http://slurm.schedmd.com/sbatch.html. Las variables de este artículo estaban cubiertas porque eran las más relevantes para los casos de uso típicos.

<table class="wikitable" style="width: 100%;">
<tr>
<td><b>Comando SLURM</b></td>
<td><b>Descripción</b>
</td></tr>
<tr>
<td>--mem-per-cpu=<megabytes></td>
<td>Memoria requerida para el trabajo por CPU (en MegaBytes). El valor predeterminado es 1024 MB.
</td></tr>
<tr>
<td>-p <partition>, --partition=<partition></td>
<td>Enviar un trabajo a una partición específica.
</td></tr>
<tr>
<td>-n, --ntasks=<cantidad de tareas></td>
<td>Número de tareas que serán asignadas para el trabajo.
</td></tr>
<tr>
<td>-c <cpus></td>
<td>Esta es la cantidad de CPU que necesita su trabajo. Tenga en cuenta que SLURM es relativamente generoso con las CPU, y el valor especificado aquí es el número "mínimo" de CPU que se asignará a su trabajo. Si hay CPU adicionales disponibles en un nodo más allá de lo solicitado, su trabajo recibirá esas CPU hasta que otros trabajos las necesiten. El valor predeterminado es 1 CPU. Intentar usar más CPU de las que se le asignaron dará como resultado que sus procesos adicionales se turnen en la misma CPU (ralentizando su trabajo).
</td></tr>
<tr>
<td>-J <name>, --jobname=<name></td>
<td>Especifica un nombre a tu trabajo.
</td></tr>
<tr>
<td>--mail-type=BEGIN,END,FAIL,ALL<b> and </b>--mail-user=<emailAddress></td>
<td>Enviar por correo electrónico cuando su trabajo comienza / termina / falla. Puede especificar varios valores para esto (separados por comas) si es necesario.
</td></tr>
<tr>
<td>-o <STDOUT_log>, --output=<STDOUT_log></td>
<td>Redirija la salida a los archivos de registro que especifique. Por defecto, ambos, STDOUT and STDERR son enviados a este archivo. Puedes especificar %j como parte del nombre de archivo de registro para indicar la ID del trabajo (como ejemplo, "#SBATCH -o ouptut_%j.o" redirigiría la salida a "output_123456.o").
</td></tr>
<tr>
<td>-e <STDERR_log>, --error=<STDERR_log></td>
<td>Redireccionar STDERR a un archivo separado. Funciona exactamente igual que "-o".
</td></tr>
<tr>
<td>-t <days-hours:minutes:seconds></td>
<td>Walltime para tu trabajo. La duración del Walltime es el tiempo que espera que su trabajo se ejecute.
</td></tr>
<tr>
<td>-a, --array=<índices></td>
<td>Envía una lista (arreglo) de trabajos identicos. Solo aplica para sbatch.
</td></tr></table>

Los scripts de trabajo especifican los recursos solicitados y otras consideraciones especiales con comentarios especiales "#SBATCH" en la parte superior de un script de trabajo. Aunque muchas de estas opciones son opcionales, las varibles que se ocupan de solicitudes de recursos (CPU, memoria y tiempo) son obligatorias. Todas las variables deben agregarse a sus scripts de la siguiente manera:

<pre>#SBATCH <variable></pre>
Para especificar un nombre al job, por ejemplo, debe agregar lo siguiente a su secuencia de comandos:

<pre>#SBATCH --job-name=nombreDeTrabajo</pre>

===Enviar un script===
<pre>
#!/bin/bash
#SBATCH -J example
#SBATCH -p general
#SBATCH -n 1
#SBATCH --output=example_%j.out
#SBATCH --error=example_%j.err
#SBATCH --mail-user=user@example.com
#SBATCH --mail-type=ALL
</pre>

Como debe comenzar un script en Linux:
<pre>
#!/bin/bash
</pre>

Nombre del trabajo:
<pre>
#SBATCH -J example
</pre>

Nombre la partición donde desea ejecutar el Job:
<pre>
#SBATCH -p general
</pre>

Número de tareas:
<pre>
#SBATCH -n 1
</pre>

Log de salida:
<pre>
#SBATCH -o example_%j.out
</pre>

Log de error:
<pre>
#SBATCH -e example_%j.err
</pre>

Correo para notificaciones:
<pre>
#SBATCH --mail-user=user@example.com
</pre>

Enviar correo en todos casos (verificar opciones arriba):
<pre>
#SBATCH --mail-type=ALL
</pre>

=== Programar tarea (uso de scrontab) ===
'''scrontab''' es una implementación del clásico planificador de tareas de linux '''crontab''' donde se guarda un listado de comandos a ejecutar en un tiempo determinado por el usuario.

Para acceder a scrontab utilice el siguiente comando:
<pre>
[prueba@leftraru1 ~]$ scrontab -e
</pre>

Esto le permitirá editar su archivo scrontab, asignando recursos como también el momento en que desea ejecutar su tarea. La estructura base a utilizar es la siguiente:
<pre>
#SCRON -J mi_tarea
#SCRON -p slims
#SCRON -n 1
#SCRON -c 1
#SCRON --mem-per-cpu=2300
#SCRON --mail-user=foo@bar.com
#SCRON --mail-type=ALL
#SCRON -o mi_tarea_%j.out
#SCRON -e mi_tarea_%j.err
# Example of job definition:
# .---------------- minute (0 - 59)
# | .------------- hour (0 - 23)
# | | .---------- day of month (1 - 31)
# | | | .------- month (1 - 12) OR jan,feb,mar,apr ...
# | | | | .---- day of week (0 - 6) (Sunday=0 or 7) OR sun,mon,tue,wed,thu,fri,sat
# | | | | |
# * * * * * command to be executed
</pre>

* '''minute''' - Corresponde al minuto en que se va a ejecutar el script, valor de 0 a 59.
* '''hour''' - Hora de ejecución, formato 24 horas, valor de 0 a 23, donde 0 son las 12:00 AM.
* '''day of month''' - Día del mes, la tarea se puede ejecutar cada x día, valor de 1 a 31.
* '''month''' - La tarea se puede ejecutar cada x mes, valor de 1 a 12.
* '''day of week''' - Día de la semana, valor de 0 a 6, donde 0 es Domingo.
* '''command to be executed''' - Script a ejecutar por el usuario.

Ejemplo envío de trabajo slurm:

Para la asignación de recursos, utilizaremos la directriz '''#SCRON''', que utiliza los mismos parámetros usados por '''#SBATCH'''.

Luego de asignar los recursos debemos especificar el tiempo, en este caso la tarea será ejecutada todos los días cada 20 minutos, luego debemos indicar el script enviado por el usuario y guardamos los cambios en el archivo.

<pre>
*/20 * * * * /home/prueba/ejemplo/script.sh
</pre>

Es importante destacar que el script a lanzar '''/home/prueba/ejemplo/script.sh''' debe tener permisos de ejecución.

Para revisar el listado de tareas existentes en nuestro scrontab, ejecutamos el comando:
<pre>
[prueba@leftraru1 ~]$ scrontab -l
*/20 * * * * /home/prueba/ejemplo/script.sh
</pre>

Para borrar el contenido de nuestro scrontab:
<pre>
[prueba@leftraru1 ~]$ scrontab -r
</pre>

'''Información a considerar:'''

* Generar archivos de salida correctamente
** Para que el archivo error y out de tu script se generen en el directorio solicitado, ejemplo, /home/prueba/ejemplo/ en tu script debe estar presente el comando cd “/home/prueba/ejemplo”, esto hará que scrontab se posicione dentro del directorio de salida.
* Es distinto el tiempo de programar el envío de una tarea (scrontab) a que una tarea inicie en el clúster (running), ya que esto dependerá de los recursos libres que existan en ese momento en el clúster.
* Para revisar las tareas programadas debe ejecutar en cualquier nodo login el comando '''scrontab -l''' o revisar con el comando '''squeue''':

<pre>
[prueba@leftraru1 ~]$ squeue
24293471 slims /home/eg prueba PD 0:00 1 (BeginTime)
</pre>

== Checkpointing ==
Es la acción de guardar el estado de un proceso en ejecución en un archivo de imagen de punto de control. Este proceso se puede reiniciar más tarde desde el archivo del punto de control, continuando la ejecución desde donde se detuvo, en la misma computadora o en una diferente.

=== ¿Por qué utilizarlo? ===
* Permite ejecuciones de tarea largas que superen el tiempo de ejecución permitido en el cluster (30 días)
* Estar preparados ante fallas del sistema que nos puedan hacer perder resultados de nuestras simulaciones

=== Utilización ===
Lo primero que debemos hacer en nuestro script es cargar el módulo de Mana:
<pre>
ml mana/3.0.0
</pre>
Este módulo provee 3 ejecutables que necesitaremos:

* '''mana_coordinator:''' Coordina los checkpoints entre los distintos procesos
* '''mana_launch:''' Inicia un proceso con checkpoint
* '''mana_restart:''' Reinicia la ejecución desde una imagen del checkpoint

Necesitaremos 2 scripts para trabajar con checkpoints: Inicio y reinicio

=== Script de inicio (inicio.sh) ===
<pre>
#!/bin/bash
##---------------SLURM Parameters - NLHPC ----------------
#SBATCH -J Testcheckpoint
#SBATCH -p general
#SBATCH -n 44
#SBATCH --ntasks-per-node=44
#SBATCH --mem-per-cpu=4363
#SBATCH --mail-user=test@nlhpc.cl
#SBATCH --mail-type=ALL
#SBATCH -o Testcheckpoint_%j.out
#SBATCH -e Testcheckpoint_%j.err

# ----------------Modules----------------------------
ml mana/3.0.0
# ----------------Command--------------------------
#Checkpointing cada 1 hora
mana_cooridinator -i3600
#Ejecutamos nuestra tarea con checkpointing
srun mana_launch ./ejecutable
</pre>

=== Script de reinicio (reinicio.sh) ===
<pre>
#!/bin/bash
##---------------SLURM Parameters - NLHPC ----------------
#SBATCH -J Testcheckpoint
#SBATCH -p general
#SBATCH -n 44
#SBATCH --ntasks-per-node=44
#SBATCH --mem-per-cpu=4363
#SBATCH --mail-user=test@nlhpc.cl
#SBATCH --mail-type=ALL
#SBATCH -o Testcheckpoint_%j.out
#SBATCH -e Testcheckpoint_%j.err

# ----------------Modules----------------------------
ml mana/3.0.0
# ----------------Command--------------------------
#Checkpointing cada 1 hora
mana_cooridinator -i3600
#Reiniciar nuestra tarea desde los archivos de checkpoint
srun mana_restart
</pre>

Para correr estos scripts se puede hacer utilizando la funcionalidad de dependencias de SLURM:
<pre>
[test@leftraru2 test]$ sbatch inicio.sh
Submitted batch job 23574685
[test@leftraru2 test]$ sbatch --dependency=afterok:23574685 reinicio.sh
</pre>

== Trabajos ==
=== Trabajos paralelos ===
Muchos de los trabajos que se ejecutan en un clúster de producción implicarán más de un procesador (CPU, núcleo). Dichos trabajos paralelos deben solicitar la cantidad de recursos necesarios a través de opciones adicionales. Los más comunes son:

Para diferentes tipos de trabajos paralelos, se especificarán diferentes opciones. Los trabajos paralelos más comunes son trabajos de MPI (memoria distribuida), trabajos de subprocesos múltiples (memoria compartida) y los llamados híbridos que son una combinación de los dos. Analicemos por separado con un n ejemplo para cada uno.

=== Ejecución de programas con MPI ===
MPI (interfaz de paso de mensajes) es la API de comunicación estándar para trabajos paralelos de memoria distribuida capaz de implementarse en un clúster. Para programar dicho trabajo, es necesario especificar la cantidad de nodos del clúster que se utilizarán y la cantidad de procesos (tareas) que se ejecutarán en cada nodo.

El siguiente es un ejemplo de ejecución de un programa compilado con Open MPI:

#!/bin/bash
#SBATCH -J example_mpi
#SBATCH -p general
#SBATCH -n 264
#SBATCH --ntasks-per-node=44
#SBATCH --output=example_%j.out
#SBATCH --error=example_%j.err
#SBATCH --mail-user=user@example.com
#SBATCH --mail-type=ALL

srun ./mpi_test
A continuacion se explica línea por líneael script.

Como empieza un shell script en Linux:
<pre>
#!/bin/bash
</pre>

Nombre del Job:
<pre>
#SBATCH -J example_mpi
</pre>

Nombre la particion donde se desea ejecutar el trabajo:
<pre>
#SBATCH -p general
</pre>

Número de tareas. Debe de ser un número múltiplo del número de CPUs máximo que tenga un node de la partición donde se lanza:
<pre>
#SBATCH -n 264
</pre>

Con esto se fuerza a que se lancen 44 tareas MPI en cada uno de los nodos, ocupando de este modo nodos completos. En este caso 6 nodos completos:
<pre>
#SBATCH --ntasks-per-node=44
</pre>

Log de salida:
<pre>
#SBATCH -o example_%j.out
</pre>

Log de error:
<pre>
#SBATCH -e example_%j.err
</pre>

Correo para notificaciones:
<pre>
#SBATCH --mail-user=user@example.com
</pre>

Envía correo en todos los casos:
<pre>
#SBATCH --mail-type=ALL
</pre>

Programa para ejecutar:
<pre>
srun ./mpi_test
</pre>

'''Nota''': no se carga específicamente el módulo "mpi" ya que se carga siempre por defecto.

Para enviarlo al clúster debe ejecutar el comando: ''sbatch script.sh''. El ejemplo anterior ejecutará una tarea OpenMPI con 264 procesos reservando 264 cores para ello.

=== Trabajos multiproceso OpenMP ===
Los trabajos paralelos diseñados para ejecutarse en un sistema multi-core (shared-memory) suelen ser "multi-threaded". La programación de un job de este tipo requiere especificar el número de núcleos que se utilizan para acomodar los subprocesos.

OpenMP es el conjunto común de variables de compilación para facilitar el desarrollo de programas multi-threaded. Un script típico de SLURM para un programa de este tipo se ve así:
<pre>
#!/bin/bash
#SBATCH -J OMPtest
#SBATCH -p general
#SBATCH -n 1
#SBATCH -c 44
#SBATCH --ntasks-per-node=44
#SBATCH --mem-per-cpu=1024
#SBATCH -o example_%j.out
#SBATCH -e example_%j.err
#SBATCH --mail-user=user@example.com
#SBATCH --mail-type=ALL

OMP_NUM_THREADS=$SLURM_CPUS_PER_TASK time ./omp-program
</pre>

Como debe comenzar un script en Linux:
<pre>
#!/bin/bash
</pre>

Nombre del Job:
<pre>
#SBATCH -J OMPtest
</pre>

Nombre la particion donde desea ejecutar el Job:
<pre>
#SBATCH -p general
</pre>

Número de trabajos:
<pre>
#SBATCH -n 1
</pre>

Número de tareas:
<pre>
#SBATCH -c 44
</pre>

Con esto se fuerza a que se agrupen las 44 tareas en un nodo (en OpenMP no hay comunicación entre nodos, por lo que todas las tareas deben estar en el mismo nodo o no funcionaría):
<pre>
#SBATCH --ntasks-per-node=44
</pre>

Memoria por core (MBytes):
<pre>
#SBATCH --mem-per-cpu=1024
</pre>

Log de salida:
<pre>
#SBATCH -o example_%j.out
</pre>

Log de error:
<pre>
#SBATCH -e example_%j.err
</pre>

Correo para notificaciones:
<pre>
#SBATCH --mail-user=user@example.com
</pre>

Enviar correo en todos los casos:
<pre>
#SBATCH --mail-type=ALL
</pre>

Programa para ejecutar:
<pre>
OMP_NUM_THREADS=$SLURM_CPUS_PER_TASK time ./omp-program
</pre>

Cuando se utiliza un programa OpenMP, el número de subprocesos (y, por lo tanto, el número requerido de núcleos) se especifica a través de la variable de entorno OMP_NUM_THREADS que, por lo tanto, aparece en el script frente a la llamada al programa. Lo estamos configurando en la variable interna SLURM_CPUS_PER_TASK que se establece a través de la opción "-c" (a 44 en nuestro ejemplo, que sería el número total de cores de un nodo de la partición "general").

La opción "-n" se mantiene en 1 para indicar un único trabajo principal que tiene 44 tareas. Para asegurarnos que todas las tareas se ejecutan en el mismo nodo, se añade la opción "--ntasks-per-node" con el máximo número de cores que tiene un nodo de la partición donde se está lanzando el trabajo.

=== Ejecución de tareas en GPUs ===
<pre>
#!/bin/bash
#SBATCH -J ejemplo_gpus
#SBATCH -p v100
#SBATCH -n 1
#SBATCH -o ejemplo_%j.out
#SBATCH -e ejemplo_%j.err
#SBATCH --mail-user=correo@gmail.com
#SBATCH --mail-type=ALL
#SBATCH --mem-per-cpu=4300
#SBATCH --gres=gpu:1

./programa
</pre>

Inicio de un bash script en Linux:
<pre>
#!/bin/bash
</pre>

Nombre del trabajo:
<pre>
#SBATCH -J ejemplo_gpus
</pre>

Nombre la partición donde se ejecuta el trabajo:
<pre>
#SBATCH --partition=v100
</pre>

Número de tareas:
<pre>
#SBATCH -n 1
</pre>

Log de salida:
<pre>
#SBATCH -o ejemplo_%j.out
</pre>

Log de error:
<pre>
#SBATCH -e ejemplo_%j.err
</pre>

Correo para notificaciones:
<pre>
#SBATCH --mail-user=user@example.com
</pre>

Enviar correo en todos los casos:
<pre>
#SBATCH --mail-type=ALL
</pre>

Memoria por CPU (MB):
<pre>
#SBATCH --mem-per-cpu=4365
</pre>

Cantidad utilizada de GPUs. El parámetro gpu:1 indica la cantidad de tarjetas a utilizar (cada nodo tiene 2 GPUs):
<pre>
#SBATCH --gres=gpu:1
</pre>

Programa para ejecutar:
<pre>
./programa
</pre>

=== Job Arrays ===
Cuando se ejecutan cientos o miles de simulaciones que utilizan la misma cantidad de recursos, puede ser una ventaja ejecutar estas simulaciones como un "job array". Los job array le permiten enviar miles de dichos trabajos (llamados "job steps") con un solo script. A cada simulación se le asignará un valor único para la variable de entorno SLURM_ARRAY_TASK_ID. Puede usar esta variable para leer parámetros para pasos individuales de una línea dada de un archivo.

=== Caso de uso de un Script Job Array (Gaussian) ===
Tenemos usuarios que actualmente envían varias simulaciones al clúster que son similares en cuanto al uso de recursos, pero, la diferencia es que solo cambia la entrada que le entregan al programa. Para esta situación, recomendamos hacer uso de un script Job Array.

En este ejemplo crearemos un script job array para el software Gaussian, el cual, realizará 63 simulaciones, cada una de estas utilizará 8 cores y podrá alcanzar un uso máximo de 8 Gb de memoria ram. Para este caso utilizaremos la partición slims donde cada nodo tiene 46 Gb de memoria ram y 20 cores.

Script:
<pre>
#!/bin/bash
# ----------------SLURM Parameters----------------
#SBATCH -J prueba
#SBATCH -p slims
#SBATCH -n 1
#SBATCH -c 8
#SBATCH --mem-per-cpu=1000
#SBATCH --mail-user=prueba@nlhpc.cl
#SBATCH --mail-type=ALL
#SBATCH --array=1-63
#SBATCH -o prueba_%A_%a.out
#SBATCH -e prueba_%A_%a.err
#-----------------Toolchain---------------------------
ml purge
ml intel/2019b
# ----------------Módulos-----------------------------
ml g16/B.01
# ----------------Comandos--------------------------
file=$(ls Child_10_*.com | sed -n ${SLURM_ARRAY_TASK_ID}p)
srun g16 $file
</pre>

'''
Descripción de comandos utilizados en script:'''

Inicio de un bash script en Linux:
<pre>
#!/bin/bash
</pre>

Nombre de la simulación:
<pre>
#SBATCH -J prueba
</pre>

Nombre la partición donde se ejecuta la simulación:
<pre>
#SBATCH -p slims
</pre>

Número de tareas (1 tarea va a ejecutar 63 simulaciones):
<pre>
#SBATCH -n 1
</pre>

Core’s por tareas (cada tarea utilizará un máximo 8 cores):
<pre>
#SBATCH -c 8
</pre>

Memoria ram por cpu (cada tarea utilizará un máximo 8 Gb de ram):
<pre>
#SBATCH –mem-per-cpu=1000
</pre>

Correo para activar el envío de notificaciones:
<pre>
#SBATCH --mail-user=prueba@nlhpc.cl
</pre>

Permitir envío de notificaciones:
<pre>
#SBATCH --mail-type=ALL
</pre>

Se generan 63 simulaciones diferentes:
<pre>
#SBATCH --array=1-63
</pre>

Log de salida: (ejemplo: prueba_18455017_1.out)

* %A corresponde al Job ID de nuestra tarea que le asignará Slurm → 18455017.
* %a corresponde a la simulación X de nuestra tarea que le asignará Slurm → 1.
<pre>
#SBATCH -o prueba_%A_%a.out
</pre>

Log de errores: (ejemplo: prueba_18455017_1.err)

* %A corresponde al Job ID de nuestra tarea que le asignará Slurm → 18455017.
* %a corresponde a la simulación X de nuestra tarea que le asignará Slurm → 1.

<pre>
#SBATCH -e prueba_%A_%a.err
Toolchain: en este apartado, limpiaremos nuestro entorno de software no deseados y luego escogemos la herramienta informática con la cual está compilado el software Gaussian (nosotros utilizamos el compilador Intel/2019b).

#-----------------Toolchain---------------------------
ml purge
ml intel/2019b
Módulos: cargamos el software Gaussian versión 16/B.0.

# ----------------Módulos-----------------------------
ml g16/B.01
Comandos: aquí definimos los comandos a ejecutar.

# ----------------Comandos--------------------------
file=$(ls Child_10_*.com | sed -n ${SLURM_ARRAY_TASK_ID}p)
srun g16 $file
</pre>
file= variable que va a listar los archivos de entrada que comiencen por Child_10_ y terminen en .com

[[Archivo:Child.png|no]]

sed -n ${SLURM_ARRAY_TASK_ID}p) ← Sed imprimirá las líneas de cada archivo de entrada y la variable $SLURM_ARRAY_TASK_ID asumirá estas entradas como matriz de simulación en nuestro job array, en este ejemplo tenemos 63 archivos de entrada.

Para más detalles sobre los archivos stdin, stdout y stderr de una simulación % A será reemplazado por el valor de SLURM_ARRAY_JOB_ID que es el Job ID de nuestra tarea y %a será reemplazado por el valor de SLURM_ARRAY_TASK_ID que corresponde a la simulación X de nuestra tarea.

Srun g16 $file: ejecutará el comando gaussian g16 interpretando la variable $file en los nodos de cómputo asignados.

Enviar el script:
<pre>
[prueba@leftraru1 ~]$ sbatch prueba.sh
</pre>

=== Ejecución de una tarea que ocupa mucha RAM por CPU ===
Debemos tener en cuenta que la RAM que SLURM reserva por defecto son 1000 MB. Un típico error de cancelación de tarea por falta de memoria es el siguiente:
<pre>
/tmp/slurmd/job136839939/slurm_script: line 15: 23547 Killed ./programa.sh
slurmstepd: error: Detected 1 oom-kill event(s) in step 136839939.batch cgroup. Some of your processes
may have been killed by the cgroup out-of-memory handler.
</pre>

Si su tarea ocupa más de la memoria por defecto, puede utilizar el siguiente parámetro:
<pre>
#SBATCH --mem-per-cpu=2300 #Máxima RAM por CPU
</pre>
Esto hará que SLURM reserve más RAM por CPU para sus tareas.

Tenga en cuenta que nuestros nodos tienen 46 GB de memoria RAM (Partición slims), 187 GB (Partición general) y 765 GB (Partición largemem) por nodo. [https://wiki.nlhpc.cl/Hardware_Disponible Más información].

Otra forma de reservar memoria es utilizando el siguiente parámetro:

<pre>
#SBATCH --mem=2300
</pre>
En este caso SLURM realizará una reserva de memoria de 2300 MB pero por la totalidad del trabajo.

Los parámetros anteriores al igual que el número de CPUs que se van a usar, hay que afinarlos lo mejor posible. Para ello lo que se puede hacer es hacer pruebas en los nodos logins, sin lanzar en las colas, y así estudiar el uso de RAM y CPU por parte de sus procesos.

=== Ejecución de una tarea con Dependencias ===
Las dependencias de trabajos se utilizan para aplazar el inicio de un trabajo hasta que se satisfagan las dependencias especificadas. Se especifican con la opción --dependency en el siguiente formato:
<pre>
sbatch --dependency=<type:job_id[:job_id][,type:job_id[:job_id]]> ...
</pre>
Los tipos de dependencias son las siguientes:

* '''after''':jobid[:jobid...] - el trabajo puede empezar después de que los trabajos especificados comiencen
* '''afterany''':jobid[:jobid...] - el trabajo puede empezar después de que los trabajos especificados terminen
* '''afternotok''':jobid[:jobid...] - el trabajo puede empezar después que los trabajos especificados terminan fallidamente
* '''afterok''':jobid[:jobid...] - el trabajo puede empezar después que los trabajos especificados terminan exitósamente

La manera más simple de usar una dependencia del tipo afterok:
<pre>
[prueba@leftraru1 ~]$ sbatch job1.sh
Submitted batch job 21363626
[prueba@leftraru1 ~]$ sbatch --dependency=afterok:21363626 job2.sh
</pre>

Ahora cuando job1.sh termine correctamente, el job2.sh entrará en ejecución. Si job1.sh termina fallidamente, job2.sh no entrará en ejecución nunca pero sí quedará en cola (debe cancelarse manualmente el trabajo).

== Prioridad de tarea ==
Cómo ver la prioridad del trabajo. Los factores que determinan la prioridad del trabajo, incluyendo la fórmula y pesos.

=== Factores que determinan prioridad de tarea ===
<table class="wikitable" style="width: 60%;">
<tr>
<td><b>Comando SLURM</b></td>
<td><b>Descripción</b>
</td></tr>
<tr>
<td>Edad</td>
<td>la cantidad de tiempo que el trabajo ha estado esperando en la cola.
</td></tr>
<tr>
<td>Tamaño de la tarea</td>
<td>número de nodos solicitados por el trabajo.
</td></tr>
<tr>
<td>Partición</td>
<td>prioridad para una partición determinada.
</td></tr>
<tr>
<td>Prioridad Baja</td>
<td>Mientras más tareas se ejecuten en el cluster, menor será la prioridad.
</td></tr>
<tr>
<td>Prioridad Alta</td>
<td>Mientras menos tareas se ejecuten en el clúster, más alta es la prioridad.
</td></tr></table>

== Prioridad de tarea ==
Cómo ver la prioridad del trabajo. Los factores que determinan la prioridad del trabajo, incluyendo la fórmula y pesos.

=== Factores que determinan prioridad de tarea ===
* Edad - la cantidad de tiempo que el trabajo ha estado esperando en la cola
* Tamaño Oficio - número de nodos solicitados por el trabajo
* Partición - prioridad para una partición determinada
* Contribución de prioridades basada en los recursos informáticos utilizados por los miembros de un grupo de investigación en los últimos 30 días - Fairshare.
* Mientras más tareas se ejecuten en el cluster, menor será la prioridad.
* Mientras menos tareas se ejecuten en el clúster, más alta es la prioridad.
Fórmula Prioridad de tarea
<pre>
Job_priority =
(PriorityWeightAge) * (age_factor) +
(PriorityWeightFairshare) * (fair-share_factor) +
(PriorityWeightJobSize) * (job_size_factor) +
(PriorityWeightPartition) * (partition_factor) +
(PriorityWeightQOS) * (QOS_factor)
</pre>

== Visualización de sus Tareas ==
Si Ud. necesita visualizar información acerca de sus tareas de forma interactiva, puede utilizar el comando smap:

smap -i 3

[[Archivo:Smap.png|no|700px]]

De esta forma, tendrá una actualización cada 3 segundos de sus tareas en ejecución incluyendo los nodos en los cuales se encuentran ejecutándose.

== Bibliografía ==
[http://slurm.schedmd.com/documentation.html Manual Oficial de Slurm]

[https://slurm.schedmd.com/scrontab.html Documentación scrontab]

SISTEMA GESTOR DE RECURSOS

2024-04-29T22:01:12Z

Jmorales: /* Cancelar un trabajo */

== SLURM Workload Manager ==
Es un sistema de programación de trabajos y gestión de clústeres de código abierto, tolerante a fallas y altamente escalable para clústeres Linux grandes y pequeños.

Como administrador de carga de trabajo de clúster, Slurm tiene tres funciones clave. Primero, asigna acceso exclusivo y / o no exclusivo a los recursos (nodos de cómputo) a los usuarios durante un período de tiempo para que puedan realizar el trabajo. En segundo lugar, proporciona un marco para iniciar, ejecutar y monitorear el trabajo (normalmente un trabajo paralelo) en el conjunto de nodos asignados. Finalmente, arbitra la contención de recursos mediante la gestión de una cola de trabajo pendiente.

SLURM es el gestor de colas instalado en muchos de los súper computadores del [https://www.top500.org/ TOP500], y también en el clúster del NLHPC. Si Ud. quiere lanzar tareas dentro de Leftaru, debe hacerlo a través de Slurm.

== Conceptos clave ==
SLURM gestiona trabajos de usuario que tienen las siguientes características clave:

* Conjunto de recursos solicitados:
** Número de recursos informáticos: nodos (incluidas todas sus CPUs y núcleos) o CPUs (incluidos todos sus núcleos) o solo núcleos
** Cantidad de memoria: por nodo o por CPU (lógica)
** Tiempo necesario para que las tareas del usuario completen su trabajo
* Una partición de nodo solicitada (cola de trabajos)
* Un nivel de calidad de servicio (QoS) solicitado que otorga a los usuarios accesos específicos
* Una cuenta solicitada con recursos limitados

De manera predeterminada, los usuarios envían trabajos a una partición particular (marcada como tal para todos los usuarios) y bajo una cuenta particular (preestablecida por usuario).

== Particiones SLURM ==

<table class="wikitable" style="width: 60%;">
<tr>
<td><b>Nombre Particion</b></td>
<td><b>Nodos</b></td>
<td><b>CPUs</b></td>
<td><b>RAM</b></td>
<td><b>Descripción</b>
</td></tr>
<tr>
<td>main</td>
<td>27</td>
<td>256</td>
<td>768GB</td>
<td>
</td></tr>
<tr>
<td>general</td>
<td>48</td>
<td>44</td>
<td>187GB</td>
<td>
</td></tr>
<tr>
<td>largemem</td>
<td>9</td>
<td>44</td>
<td>765GB</td>
<td>
</td></tr>
<tr>
<td>v100</td>
<td>2</td>
<td>44</td>
<td>187GB</td>
<td>4 GPUs Nvidia Tesla V100.
</td></tr>
<tr>
<td>mi100</td>
<td>1</td>
<td>128</td>
<td>502GB</td>
<td>2 GPUs AMD Instinct MI100.
</td></tr>
<tr>
<td>debug</td>
<td>4</td>
<td>20</td>
<td>59GB</td>
<td>Destinados a pruebas de máximo 30 minutos.
</td></tr></table>

== Introducción a los comandos slurm ==
<table class="wikitable" style="width: 60%;">
<td><b>Comando SLURM</b></td>
<td><b>Descripción</b>
</td></tr>
<tr>
<td>srun</td>
<td>ejecutar un comando en nodos de cómputo asignados.
</td></tr>
<tr>
<td>sbatch</td>
<td>presentar un script de trabajo
</td></tr>
<tr>
<td>squeue</td>
<td>Mostrar estado de los trabajos en la cola.
</td></tr>
<tr>
<td>scancel</td>
<td>eliminar un trabajo.
</td></tr>
<tr>
<td>sinfo</td>
<td>Muestra el estado de los nodos de cómputo.
</td></tr></table>
Estos son los comandos básicos utilizados para realizar la mayoría de las operaciones básicas con SLURM.

=== Estado de nodos ===
Para consultar el uso de nuestra infraestructura y qué particiones están más libres, le recomendamos el comando sinfo:

<pre># sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
all up infinite 16 mix cn[001,005-006,010,034-035,037,041,045,050,057,108,121],sn[012,016,037]
all up infinite 95 alloc cn[011-033,038-044,046-049,071-120],cnf[001-004],sn[001-011,038-041,043-044]
all up infinite 33 idle fn[001-009],gn[001-002],sn[018-035,045-048]
main* up infinite 20 alloc mn[001-011,014-022]
main* up infinite 7 idle [012-013,023-027]
debug up infinite 4 idle leftraru[1-2]
general up infinite 4 mix sn[012,016,037,042]
general up infinite 22 alloc sn[001-011,013-015,017,036,038-041,043-044]
general up infinite 22 idle sn[018-035,045-048]
largemem up infinite 9 idle fn[001-009]
v100 up infinite 2 idle gn[001-002]
mi100 up infinite 1 idle gna001
</pre>

Fijándose en el texto resaltado de la salida del comando sinfo, se puede comprobar que en la partición main hay 20 nodos que están completamente ocupados (estado alloc), 7 nodos que están libres (idle); por otro lado, en la partición general hay 22 nodos completamente ocupados, 4 parcialmente ocupados y 22 libres. Dado este escenario, está claro que debería de lanzar sus ejecuciones en los nodos de la partición general, por las razones anteriormente expuestas.

Para lanzar en la partición general, debe tener en cuenta que tiene que indicar en su script que se use dicha partición en vez de, probablemente, main. Por supuesto, en esta partición cambian las características técnicas, se pasan a tener 44 cores por nodo (en vez de 256 en main) y una capacidad RAM de 187GB (en vez de 768GB en main). Puede ver más información de las particiones en este link(agregar link), donde podrá revisar que con la inclusión de Guacolda hemos añadido nodos con hasta 765GB de memoria RAM y nodos con GPUs Nvidia Tesla V100 y AMD Instinct MI100 .

Para ver los nodos disponibles y poder determinar en que partición lanzar los trabajos se recomienda utilizar el siguiente comando.

<pre>[prueba@leftraru1 ~]$ sinfo -o "%10P %6D %10t %10m %c" -t idle| egrep "PARTITION|main|general|largemem|v100"
PARTITION NODES STATE MEMORY CPUS
main* 27 idle 768000 256
general 2 idle 187000 44
largemem 7 idle 765000 44
v100 1 idle 187000 44
mi100 1 idle 515047 128
</pre>

El comando anterior muestra que main tiene 27 nodos libres, en este caso es recomendado lanzar en en main para evitar que el trabajo quede en cola por falta de recursos en otros nodos.

Otro Ejemplo, se muestra sólo una partición específica

<pre>[prueba@leftraru1 ~]$ sinfo -p main
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
main* up infinite 15 mix mn[001-008,014-020]
main* up infinite 12 idle mn[009-013,021-027]
</pre>

=== Comprobación del estado de tareas ===
squeue - Muestra el estatus de los trabajos

<pre>squeue # tus trabajos
squeue -u <username> # trabajos por usuario <username>
</pre>

squeue: Comprobar estados de los trabajos

<div style="" class="mw-highlight mw-content-ltr" dir="ltr">
<pre>
JOBID PARTITION NAME USER ST TIME NODES NODELIST(REASON)
13951858_1 general test1 test1 R 1-18:35:14 2 cn[009-010]
13951857_2 general test2 test1 R 1-18:36:11 2 cn[099-100]
13956453 gpu test3 test3 R 1-03:42:08 1 cn039
13956449 largemem test4 test4 R 1-05:42:08 1 cn044
</pre>

Puede utilizar squeue para saber el estado de una o varias de sus tareas

<pre>
$ squeue -o "%.15i %.6P %.8j %.20S %.11M %.11L %.20V %.10Q %.4C %.2D %.6m" -S -t,-Q
JOBID PARTIT NAME START_TIME TIME TIME_LEFT SUBMIT_TIME PRIORITY CPUS NO MIN_ME
10837561 general TEST1 2018-06-18T18:51:01 19:00:31 2-04:59:29 2018-06-18T18:51:01 119972 1 1 1000M
10838562 general TEST2 2018-06-19T11:30:47 2:20:45 2-21:39:15 2018-06-19T11:30:46 119946 1 1 1000M
</pre>

para mas opciones puede revisar con el comando [https://slurm.schedmd.com/squeue.html man squeue] las opciones restantes.

=== Códigos de ESTADO de los trabajos ===

Los trabajos suelen pasar por varios estados durante su ejecución. Los estados típicos son PENDIENTE, EN EJECUCIÓN, SUSPENDIDO, FINALIZANDO y TERMINADO. A continuación se explica cada estado.

'''BF''' BOOT_FAIL
Trabajo finalizado debido a un fallo de arranque, normalmente debido a un fallo de hardware (por ejemplo, no se puede arrancar el nodo o bloque y el trabajo no se puede volver a poner en cola).

'''CA''' CANCELADO
El trabajo ha sido cancelado explícitamente por el usuario o el administrador del sistema. El trabajo puede haberse iniciado o no.

'''CD''' TERMINADO
El trabajo ha terminado todos los procesos en todos los nodos con un código de salida de cero.

'''CF''' CONFIGURANDO
Al trabajo se le han asignado recursos, pero están esperando a que estén listos para su uso (por ejemplo, arrancando).

'''CG''' COMPLETANDO
El trabajo está en proceso de finalización. Algunos procesos en algunos nodos pueden estar aún activos.

'''DL''' FECHA LÍMITE
El trabajo ha finalizado en la fecha límite.

'''F''' FALLÓ
Trabajo finalizado con un código de salida distinto de cero u otra condición de fallo.

'''NF''' NODO_FAIL
Trabajo finalizado debido al fallo de uno o más nodos asignados.

'''OOM''' OUT_OF_MEMORY
El trabajo ha experimentado un error de memoria insuficiente.

'''PD''' PENDIENTE
El trabajo está pendiente de asignación de recursos.

'''PR''' PREEMPTED
El trabajo ha finalizado debido a una espera.

'''R''' EN MARCHA
El trabajo tiene actualmente una asignación.

'''RD''' RESV_DEL_HOLD
El trabajo se está reteniendo después de que se eliminara la reserva solicitada.

'''RF''' REQUEUE_FED
El trabajo está siendo solicitado por una federación.

'''RH''' REQUEUE_HOLD
Se está volviendo a poner en cola un trabajo retenido.

'''RQ''' REQUEUED
Se está poniendo en cola un trabajo que se está completando.

'''RS''' CAMBIO DE TAMAÑO
El trabajo está a punto de cambiar de tamaño.

'''RV''' REVOCADO
El trabajo se ha retirado del clúster debido a que otro clúster ha iniciado el trabajo.

'''SI''' SEÑALANDO
El trabajo está siendo señalizado.

'''SE''' SPECIAL_EXIT
El trabajo se ha puesto en cola en un estado especial. Este estado puede ser establecido por los usuarios, normalmente en EpilogSlurmctld, si el trabajo ha terminado con un valor de salida particular.

'''SO''' STAGE_OUT
El trabajo está preparando los archivos.

'''ST''' PARADO
El trabajo tiene una asignación, pero la ejecución se ha detenido con la señal SIGSTOP. Los CPUS han sido retenidos por este trabajo.

'''S''' SUSPENDIDO
El trabajo tiene una asignación, pero se ha suspendido la ejecución y se han liberado CPUs para otros trabajos.

'''TO''' TIMEOUT
El trabajo ha finalizado al alcanzar su límite de tiempo.

=== Cancelar un trabajo ===
Con scancel se puede cancelar un trabajo en ejecución
<pre>scancel <jobID> # Matar proceso <jobID>. (puede obtener el ID del job con "squeue")
scancel -u <username> # Matar proceso por usuario <username>.
</pre>
<pre>[prueba@leftraru1 ~]$ squeue -u prueba
JOBID PARTITION NAME USER ST TIME NODES NODELIST(REASON)
45594 main TEST prueba R 0:59 3 mn[001-003]
</pre>
<pre>[prueba@leftraru1 ~]$ scancel 45594
[prueba@leftraru1 ~]$ squeue -u prueba
JOBID PARTITION NAME USER ST TIME NODES NODELIST(REASON)
[prueba@leftraru1 ~]$
</pre>

=== Ver estado de trabajos ===
Para revisar el detalle de las opciones de un trabajo: scontrol show job

<pre>
$ scontrol show job 10837561
JobId=10837561 JobName=TEST1
UserId=usuario(1000) GroupId=group(1000) MCS_label=N/A
Priority=1100 Nice=0 Account=account QOS=120
JobState=RUNNING Reason=None Dependency=(null)
Requeue=0 Restarts=0 BatchFlag=1 Reboot=0 ExitCode=0:0
DerivedExitCode=0:0
RunTime=19:03:08 TimeLimit=3-00:00:00 TimeMin=N/A
SubmitTime=2018-06-18T18:51:01 EligibleTime=2018-06-18T18:51:01
StartTime=2018-06-18T18:51:01 EndTime=2018-06-21T18:51:01 Deadline=N/A
PreemptTime=None SuspendTime=None SecsPreSuspend=0
Partition=slims AllocNode:Sid=leftraru2:5471
ReqNodeList=(null) ExcNodeList=(null)
NodeList=cn021
BatchHost=cn021
NumNodes=1 NumCPUs=1 NumTasks=1 CPUs/Task=1 ReqB:S:C:T=0:0:*:*
TRES=cpu=1,mem=1000M,node=1
Socks/Node=* NtasksPerN:B:S:C=1:0:*:* CoreSpec=*
Nodes=cn021 CPU_IDs=1 Mem=1000 GRES_IDX=
MinCPUsNode=1 MinMemoryCPU=1000M MinTmpDiskNode=0
Features=(null) DelayBoot=00:00:00
Gres=(null) Reservation=(null)
OverSubscribe=OK Contiguous=0 Licenses=matlab Network=(null)
Command=/home/usuario/script.sh
WorkDir=/home/usuario/
StdErr=/home/usuario/10837561_%x.err
StdIn=/dev/null
StdOut=/home/usuario/10837561_%x.out
Power=
BatchScript=
</pre>

Para ver el script asociado a un trabajo: scontrol write batch_script <job_id> -

<pre>
$ scontrol write batch_script 10837561 -
#!/bin/bash
#SBATCH -J nombre_del_trabajo
#SBATCH -p slims
#SBATCH -n 1
#SBATCH --ntasks-per-node=1
#SBATCH --mail-user=usaurio@correo.cl
#SBATCH --mail-type=ALL
#SBATCH -o nombre_del_trabajo%j_%x.out
#SBATCH -e nombre_del_trabajo%j_%x.err
#SBATCH --license=matlab

ml MATLAB/2017a

matlab -nodisplay -nosplash -nodesktop < programa.m
</pre>

== Ejecutando trabajos ==
Actualmente contamos con 2 metodos de enviar trabajos bajo SLURM: '''sbatch''' and '''srun'''. A veces puede ser ventajoso ejecutar un solo comando en el clúster como prueba o realizar rápidamente una operación con recursos adicionales. 'srun' permite a los usuarios hacer esto, y comparte las mismas variables que 'sbatch' . STDOUT y STDERR para un trabajo 'srun' serán redirigidos a la pantalla del usuario. Ctrl-C cancelará un trabajo srun. '''sbatch''' enviará un script de trabajo para que lo ejecute el clúster. Los scripts de trabajo bajo SLURM son simplemente scripts de shell (* .sh) con un conjunto de solicitudes de recursos en la parte superior del script.

Uso básico de srun:

<pre>
srun <algúnComando>
</pre>

Ejemplo de salida (ejecutando el comando "hostname" para saber en que nodo se está ejecutando):
<pre> $ srun hostname
cn003
</pre>

Para enviar un script de trabajo a SLURM:
<pre>sbatch nombreScript.sh</pre>

Example output:
<pre>$ sbatch test-job.sh
Submitted batch job 1169</pre>

=== Variables Slurm ===
Las variables en esta sección son obligatorias, y SLURM las determina para determinar dónde y cuándo se ejecutarán sus trabajos. Si no asigna un valor para estos, el planificador asignará a sus trabajos el valor predeterminado. Si no solicita específicamente recursos para un trabajo, se le asignará un conjunto de recursos predeterminados. Para obtener una lista de todas las variables disponibles, consulte la documentación de SLURM en http://slurm.schedmd.com/sbatch.html. Las variables de este artículo estaban cubiertas porque eran las más relevantes para los casos de uso típicos.

<table class="wikitable" style="width: 100%;">
<tr>
<td><b>Comando SLURM</b></td>
<td><b>Descripción</b>
</td></tr>
<tr>
<td>--mem-per-cpu=<megabytes></td>
<td>Memoria requerida para el trabajo por CPU (en MegaBytes). El valor predeterminado es 1024 MB.
</td></tr>
<tr>
<td>-p <partition>, --partition=<partition></td>
<td>Enviar un trabajo a una partición específica.
</td></tr>
<tr>
<td>-n, --ntasks=<cantidad de tareas></td>
<td>Número de tareas que serán asignadas para el trabajo.
</td></tr>
<tr>
<td>-c <cpus></td>
<td>Esta es la cantidad de CPU que necesita su trabajo. Tenga en cuenta que SLURM es relativamente generoso con las CPU, y el valor especificado aquí es el número "mínimo" de CPU que se asignará a su trabajo. Si hay CPU adicionales disponibles en un nodo más allá de lo solicitado, su trabajo recibirá esas CPU hasta que otros trabajos las necesiten. El valor predeterminado es 1 CPU. Intentar usar más CPU de las que se le asignaron dará como resultado que sus procesos adicionales se turnen en la misma CPU (ralentizando su trabajo).
</td></tr>
<tr>
<td>-J <name>, --jobname=<name></td>
<td>Especifica un nombre a tu trabajo.
</td></tr>
<tr>
<td>--mail-type=BEGIN,END,FAIL,ALL<b> and </b>--mail-user=<emailAddress></td>
<td>Enviar por correo electrónico cuando su trabajo comienza / termina / falla. Puede especificar varios valores para esto (separados por comas) si es necesario.
</td></tr>
<tr>
<td>-o <STDOUT_log>, --output=<STDOUT_log></td>
<td>Redirija la salida a los archivos de registro que especifique. Por defecto, ambos, STDOUT and STDERR son enviados a este archivo. Puedes especificar %j como parte del nombre de archivo de registro para indicar la ID del trabajo (como ejemplo, "#SBATCH -o ouptut_%j.o" redirigiría la salida a "output_123456.o").
</td></tr>
<tr>
<td>-e <STDERR_log>, --error=<STDERR_log></td>
<td>Redireccionar STDERR a un archivo separado. Funciona exactamente igual que "-o".
</td></tr>
<tr>
<td>-t <days-hours:minutes:seconds></td>
<td>Walltime para tu trabajo. La duración del Walltime es el tiempo que espera que su trabajo se ejecute.
</td></tr>
<tr>
<td>-a, --array=<índices></td>
<td>Envía una lista (arreglo) de trabajos identicos. Solo aplica para sbatch.
</td></tr></table>

Los scripts de trabajo especifican los recursos solicitados y otras consideraciones especiales con comentarios especiales "#SBATCH" en la parte superior de un script de trabajo. Aunque muchas de estas opciones son opcionales, las varibles que se ocupan de solicitudes de recursos (CPU, memoria y tiempo) son obligatorias. Todas las variables deben agregarse a sus scripts de la siguiente manera:

<pre>#SBATCH <variable></pre>
Para especificar un nombre al job, por ejemplo, debe agregar lo siguiente a su secuencia de comandos:

<pre>#SBATCH --job-name=nombreDeTrabajo</pre>

===Enviar un script===
<pre>
#!/bin/bash
#SBATCH -J example
#SBATCH -p general
#SBATCH -n 1
#SBATCH --output=example_%j.out
#SBATCH --error=example_%j.err
#SBATCH --mail-user=user@example.com
#SBATCH --mail-type=ALL
</pre>

Como debe comenzar un script en Linux:
<pre>
#!/bin/bash
</pre>

Nombre del trabajo:
<pre>
#SBATCH -J example
</pre>

Nombre la partición donde desea ejecutar el Job:
<pre>
#SBATCH -p general
</pre>

Número de tareas:
<pre>
#SBATCH -n 1
</pre>

Log de salida:
<pre>
#SBATCH -o example_%j.out
</pre>

Log de error:
<pre>
#SBATCH -e example_%j.err
</pre>

Correo para notificaciones:
<pre>
#SBATCH --mail-user=user@example.com
</pre>

Enviar correo en todos casos (verificar opciones arriba):
<pre>
#SBATCH --mail-type=ALL
</pre>

=== Programar tarea (uso de scrontab) ===
'''scrontab''' es una implementación del clásico planificador de tareas de linux '''crontab''' donde se guarda un listado de comandos a ejecutar en un tiempo determinado por el usuario.

Para acceder a scrontab utilice el siguiente comando:
<pre>
[prueba@leftraru1 ~]$ scrontab -e
</pre>

Esto le permitirá editar su archivo scrontab, asignando recursos como también el momento en que desea ejecutar su tarea. La estructura base a utilizar es la siguiente:
<pre>
#SCRON -J mi_tarea
#SCRON -p slims
#SCRON -n 1
#SCRON -c 1
#SCRON --mem-per-cpu=2300
#SCRON --mail-user=foo@bar.com
#SCRON --mail-type=ALL
#SCRON -o mi_tarea_%j.out
#SCRON -e mi_tarea_%j.err
# Example of job definition:
# .---------------- minute (0 - 59)
# | .------------- hour (0 - 23)
# | | .---------- day of month (1 - 31)
# | | | .------- month (1 - 12) OR jan,feb,mar,apr ...
# | | | | .---- day of week (0 - 6) (Sunday=0 or 7) OR sun,mon,tue,wed,thu,fri,sat
# | | | | |
# * * * * * command to be executed
</pre>

* '''minute''' - Corresponde al minuto en que se va a ejecutar el script, valor de 0 a 59.
* '''hour''' - Hora de ejecución, formato 24 horas, valor de 0 a 23, donde 0 son las 12:00 AM.
* '''day of month''' - Día del mes, la tarea se puede ejecutar cada x día, valor de 1 a 31.
* '''month''' - La tarea se puede ejecutar cada x mes, valor de 1 a 12.
* '''day of week''' - Día de la semana, valor de 0 a 6, donde 0 es Domingo.
* '''command to be executed''' - Script a ejecutar por el usuario.

Ejemplo envío de trabajo slurm:

Para la asignación de recursos, utilizaremos la directriz '''#SCRON''', que utiliza los mismos parámetros usados por '''#SBATCH'''.

Luego de asignar los recursos debemos especificar el tiempo, en este caso la tarea será ejecutada todos los días cada 20 minutos, luego debemos indicar el script enviado por el usuario y guardamos los cambios en el archivo.

<pre>
*/20 * * * * /home/prueba/ejemplo/script.sh
</pre>

Es importante destacar que el script a lanzar '''/home/prueba/ejemplo/script.sh''' debe tener permisos de ejecución.

Para revisar el listado de tareas existentes en nuestro scrontab, ejecutamos el comando:
<pre>
[prueba@leftraru1 ~]$ scrontab -l
*/20 * * * * /home/prueba/ejemplo/script.sh
</pre>

Para borrar el contenido de nuestro scrontab:
<pre>
[prueba@leftraru1 ~]$ scrontab -r
</pre>

'''Información a considerar:'''

* Generar archivos de salida correctamente
** Para que el archivo error y out de tu script se generen en el directorio solicitado, ejemplo, /home/prueba/ejemplo/ en tu script debe estar presente el comando cd “/home/prueba/ejemplo”, esto hará que scrontab se posicione dentro del directorio de salida.
* Es distinto el tiempo de programar el envío de una tarea (scrontab) a que una tarea inicie en el clúster (running), ya que esto dependerá de los recursos libres que existan en ese momento en el clúster.
* Para revisar las tareas programadas debe ejecutar en cualquier nodo login el comando '''scrontab -l''' o revisar con el comando '''squeue''':

<pre>
[prueba@leftraru1 ~]$ squeue
24293471 slims /home/eg prueba PD 0:00 1 (BeginTime)
</pre>

== Checkpointing ==
Es la acción de guardar el estado de un proceso en ejecución en un archivo de imagen de punto de control. Este proceso se puede reiniciar más tarde desde el archivo del punto de control, continuando la ejecución desde donde se detuvo, en la misma computadora o en una diferente.

=== ¿Por qué utilizarlo? ===
* Permite ejecuciones de tarea largas que superen el tiempo de ejecución permitido en el cluster (30 días)
* Estar preparados ante fallas del sistema que nos puedan hacer perder resultados de nuestras simulaciones

=== Utilización ===
Lo primero que debemos hacer en nuestro script es cargar el módulo de Mana:
<pre>
ml mana/3.0.0
</pre>
Este módulo provee 3 ejecutables que necesitaremos:

* '''mana_coordinator:''' Coordina los checkpoints entre los distintos procesos
* '''mana_launch:''' Inicia un proceso con checkpoint
* '''mana_restart:''' Reinicia la ejecución desde una imagen del checkpoint

Necesitaremos 2 scripts para trabajar con checkpoints: Inicio y reinicio

=== Script de inicio (inicio.sh) ===
<pre>
#!/bin/bash
##---------------SLURM Parameters - NLHPC ----------------
#SBATCH -J Testcheckpoint
#SBATCH -p general
#SBATCH -n 44
#SBATCH --ntasks-per-node=44
#SBATCH --mem-per-cpu=4363
#SBATCH --mail-user=test@nlhpc.cl
#SBATCH --mail-type=ALL
#SBATCH -o Testcheckpoint_%j.out
#SBATCH -e Testcheckpoint_%j.err

# ----------------Modules----------------------------
ml mana/3.0.0
# ----------------Command--------------------------
#Checkpointing cada 1 hora
mana_cooridinator -i3600
#Ejecutamos nuestra tarea con checkpointing
srun mana_launch ./ejecutable
</pre>

=== Script de reinicio (reinicio.sh) ===
<pre>
#!/bin/bash
##---------------SLURM Parameters - NLHPC ----------------
#SBATCH -J Testcheckpoint
#SBATCH -p general
#SBATCH -n 44
#SBATCH --ntasks-per-node=44
#SBATCH --mem-per-cpu=4363
#SBATCH --mail-user=test@nlhpc.cl
#SBATCH --mail-type=ALL
#SBATCH -o Testcheckpoint_%j.out
#SBATCH -e Testcheckpoint_%j.err

# ----------------Modules----------------------------
ml mana/3.0.0
# ----------------Command--------------------------
#Checkpointing cada 1 hora
mana_cooridinator -i3600
#Reiniciar nuestra tarea desde los archivos de checkpoint
srun mana_restart
</pre>

Para correr estos scripts se puede hacer utilizando la funcionalidad de dependencias de SLURM:
<pre>
[test@leftraru2 test]$ sbatch inicio.sh
Submitted batch job 23574685
[test@leftraru2 test]$ sbatch --dependency=afterok:23574685 reinicio.sh
</pre>

== Trabajos ==
=== Trabajos paralelos ===
Muchos de los trabajos que se ejecutan en un clúster de producción implicarán más de un procesador (CPU, núcleo). Dichos trabajos paralelos deben solicitar la cantidad de recursos necesarios a través de opciones adicionales. Los más comunes son:

Para diferentes tipos de trabajos paralelos, se especificarán diferentes opciones. Los trabajos paralelos más comunes son trabajos de MPI (memoria distribuida), trabajos de subprocesos múltiples (memoria compartida) y los llamados híbridos que son una combinación de los dos. Analicemos por separado con un n ejemplo para cada uno.

=== Ejecución de programas con MPI ===
MPI (interfaz de paso de mensajes) es la API de comunicación estándar para trabajos paralelos de memoria distribuida capaz de implementarse en un clúster. Para programar dicho trabajo, es necesario especificar la cantidad de nodos del clúster que se utilizarán y la cantidad de procesos (tareas) que se ejecutarán en cada nodo.

El siguiente es un ejemplo de ejecución de un programa compilado con Open MPI:

#!/bin/bash
#SBATCH -J example_mpi
#SBATCH -p general
#SBATCH -n 264
#SBATCH --ntasks-per-node=44
#SBATCH --output=example_%j.out
#SBATCH --error=example_%j.err
#SBATCH --mail-user=user@example.com
#SBATCH --mail-type=ALL

srun ./mpi_test
A continuacion se explica línea por líneael script.

Como empieza un shell script en Linux:
<pre>
#!/bin/bash
</pre>

Nombre del Job:
<pre>
#SBATCH -J example_mpi
</pre>

Nombre la particion donde se desea ejecutar el trabajo:
<pre>
#SBATCH -p general
</pre>

Número de tareas. Debe de ser un número múltiplo del número de CPUs máximo que tenga un node de la partición donde se lanza:
<pre>
#SBATCH -n 264
</pre>

Con esto se fuerza a que se lancen 44 tareas MPI en cada uno de los nodos, ocupando de este modo nodos completos. En este caso 6 nodos completos:
<pre>
#SBATCH --ntasks-per-node=44
</pre>

Log de salida:
<pre>
#SBATCH -o example_%j.out
</pre>

Log de error:
<pre>
#SBATCH -e example_%j.err
</pre>

Correo para notificaciones:
<pre>
#SBATCH --mail-user=user@example.com
</pre>

Envía correo en todos los casos:
<pre>
#SBATCH --mail-type=ALL
</pre>

Programa para ejecutar:
<pre>
srun ./mpi_test
</pre>

'''Nota''': no se carga específicamente el módulo "mpi" ya que se carga siempre por defecto.

Para enviarlo al clúster debe ejecutar el comando: ''sbatch script.sh''. El ejemplo anterior ejecutará una tarea OpenMPI con 264 procesos reservando 264 cores para ello.

=== Trabajos multiproceso OpenMP ===
Los trabajos paralelos diseñados para ejecutarse en un sistema multi-core (shared-memory) suelen ser "multi-threaded". La programación de un job de este tipo requiere especificar el número de núcleos que se utilizan para acomodar los subprocesos.

OpenMP es el conjunto común de variables de compilación para facilitar el desarrollo de programas multi-threaded. Un script típico de SLURM para un programa de este tipo se ve así:
<pre>
#!/bin/bash
#SBATCH -J OMPtest
#SBATCH -p general
#SBATCH -n 1
#SBATCH -c 44
#SBATCH --ntasks-per-node=44
#SBATCH --mem-per-cpu=1024
#SBATCH -o example_%j.out
#SBATCH -e example_%j.err
#SBATCH --mail-user=user@example.com
#SBATCH --mail-type=ALL

OMP_NUM_THREADS=$SLURM_CPUS_PER_TASK time ./omp-program
</pre>

Como debe comenzar un script en Linux:
<pre>
#!/bin/bash
</pre>

Nombre del Job:
<pre>
#SBATCH -J OMPtest
</pre>

Nombre la particion donde desea ejecutar el Job:
<pre>
#SBATCH -p general
</pre>

Número de trabajos:
<pre>
#SBATCH -n 1
</pre>

Número de tareas:
<pre>
#SBATCH -c 44
</pre>

Con esto se fuerza a que se agrupen las 44 tareas en un nodo (en OpenMP no hay comunicación entre nodos, por lo que todas las tareas deben estar en el mismo nodo o no funcionaría):
<pre>
#SBATCH --ntasks-per-node=44
</pre>

Memoria por core (MBytes):
<pre>
#SBATCH --mem-per-cpu=1024
</pre>

Log de salida:
<pre>
#SBATCH -o example_%j.out
</pre>

Log de error:
<pre>
#SBATCH -e example_%j.err
</pre>

Correo para notificaciones:
<pre>
#SBATCH --mail-user=user@example.com
</pre>

Enviar correo en todos los casos:
<pre>
#SBATCH --mail-type=ALL
</pre>

Programa para ejecutar:
<pre>
OMP_NUM_THREADS=$SLURM_CPUS_PER_TASK time ./omp-program
</pre>

Cuando se utiliza un programa OpenMP, el número de subprocesos (y, por lo tanto, el número requerido de núcleos) se especifica a través de la variable de entorno OMP_NUM_THREADS que, por lo tanto, aparece en el script frente a la llamada al programa. Lo estamos configurando en la variable interna SLURM_CPUS_PER_TASK que se establece a través de la opción "-c" (a 44 en nuestro ejemplo, que sería el número total de cores de un nodo de la partición "general").

La opción "-n" se mantiene en 1 para indicar un único trabajo principal que tiene 44 tareas. Para asegurarnos que todas las tareas se ejecutan en el mismo nodo, se añade la opción "--ntasks-per-node" con el máximo número de cores que tiene un nodo de la partición donde se está lanzando el trabajo.

=== Ejecución de tareas en GPUs ===
<pre>
#!/bin/bash
#SBATCH -J ejemplo_gpus
#SBATCH -p v100
#SBATCH -n 1
#SBATCH -o ejemplo_%j.out
#SBATCH -e ejemplo_%j.err
#SBATCH --mail-user=correo@gmail.com
#SBATCH --mail-type=ALL
#SBATCH --mem-per-cpu=4300
#SBATCH --gres=gpu:1

./programa
</pre>

Inicio de un bash script en Linux:
<pre>
#!/bin/bash
</pre>

Nombre del trabajo:
<pre>
#SBATCH -J ejemplo_gpus
</pre>

Nombre la partición donde se ejecuta el trabajo:
<pre>
#SBATCH --partition=v100
</pre>

Número de tareas:
<pre>
#SBATCH -n 1
</pre>

Log de salida:
<pre>
#SBATCH -o ejemplo_%j.out
</pre>

Log de error:
<pre>
#SBATCH -e ejemplo_%j.err
</pre>

Correo para notificaciones:
<pre>
#SBATCH --mail-user=user@example.com
</pre>

Enviar correo en todos los casos:
<pre>
#SBATCH --mail-type=ALL
</pre>

Memoria por CPU (MB):
<pre>
#SBATCH --mem-per-cpu=4365
</pre>

Cantidad utilizada de GPUs. El parámetro gpu:1 indica la cantidad de tarjetas a utilizar (cada nodo tiene 2 GPUs):
<pre>
#SBATCH --gres=gpu:1
</pre>

Programa para ejecutar:
<pre>
./programa
</pre>

=== Job Arrays ===
Cuando se ejecutan cientos o miles de simulaciones que utilizan la misma cantidad de recursos, puede ser una ventaja ejecutar estas simulaciones como un "job array". Los job array le permiten enviar miles de dichos trabajos (llamados "job steps") con un solo script. A cada simulación se le asignará un valor único para la variable de entorno SLURM_ARRAY_TASK_ID. Puede usar esta variable para leer parámetros para pasos individuales de una línea dada de un archivo.

=== Caso de uso de un Script Job Array (Gaussian) ===
Tenemos usuarios que actualmente envían varias simulaciones al clúster que son similares en cuanto al uso de recursos, pero, la diferencia es que solo cambia la entrada que le entregan al programa. Para esta situación, recomendamos hacer uso de un script Job Array.

En este ejemplo crearemos un script job array para el software Gaussian, el cual, realizará 63 simulaciones, cada una de estas utilizará 8 cores y podrá alcanzar un uso máximo de 8 Gb de memoria ram. Para este caso utilizaremos la partición slims donde cada nodo tiene 46 Gb de memoria ram y 20 cores.

Script:
<pre>
#!/bin/bash
# ----------------SLURM Parameters----------------
#SBATCH -J prueba
#SBATCH -p slims
#SBATCH -n 1
#SBATCH -c 8
#SBATCH --mem-per-cpu=1000
#SBATCH --mail-user=prueba@nlhpc.cl
#SBATCH --mail-type=ALL
#SBATCH --array=1-63
#SBATCH -o prueba_%A_%a.out
#SBATCH -e prueba_%A_%a.err
#-----------------Toolchain---------------------------
ml purge
ml intel/2019b
# ----------------Módulos-----------------------------
ml g16/B.01
# ----------------Comandos--------------------------
file=$(ls Child_10_*.com | sed -n ${SLURM_ARRAY_TASK_ID}p)
srun g16 $file
</pre>

'''
Descripción de comandos utilizados en script:'''

Inicio de un bash script en Linux:
<pre>
#!/bin/bash
</pre>

Nombre de la simulación:
<pre>
#SBATCH -J prueba
</pre>

Nombre la partición donde se ejecuta la simulación:
<pre>
#SBATCH -p slims
</pre>

Número de tareas (1 tarea va a ejecutar 63 simulaciones):
<pre>
#SBATCH -n 1
</pre>

Core’s por tareas (cada tarea utilizará un máximo 8 cores):
<pre>
#SBATCH -c 8
</pre>

Memoria ram por cpu (cada tarea utilizará un máximo 8 Gb de ram):
<pre>
#SBATCH –mem-per-cpu=1000
</pre>

Correo para activar el envío de notificaciones:
<pre>
#SBATCH --mail-user=prueba@nlhpc.cl
</pre>

Permitir envío de notificaciones:
<pre>
#SBATCH --mail-type=ALL
</pre>

Se generan 63 simulaciones diferentes:
<pre>
#SBATCH --array=1-63
</pre>

Log de salida: (ejemplo: prueba_18455017_1.out)

* %A corresponde al Job ID de nuestra tarea que le asignará Slurm → 18455017.
* %a corresponde a la simulación X de nuestra tarea que le asignará Slurm → 1.
<pre>
#SBATCH -o prueba_%A_%a.out
</pre>

Log de errores: (ejemplo: prueba_18455017_1.err)

* %A corresponde al Job ID de nuestra tarea que le asignará Slurm → 18455017.
* %a corresponde a la simulación X de nuestra tarea que le asignará Slurm → 1.

<pre>
#SBATCH -e prueba_%A_%a.err
Toolchain: en este apartado, limpiaremos nuestro entorno de software no deseados y luego escogemos la herramienta informática con la cual está compilado el software Gaussian (nosotros utilizamos el compilador Intel/2019b).

#-----------------Toolchain---------------------------
ml purge
ml intel/2019b
Módulos: cargamos el software Gaussian versión 16/B.0.

# ----------------Módulos-----------------------------
ml g16/B.01
Comandos: aquí definimos los comandos a ejecutar.

# ----------------Comandos--------------------------
file=$(ls Child_10_*.com | sed -n ${SLURM_ARRAY_TASK_ID}p)
srun g16 $file
</pre>
file= variable que va a listar los archivos de entrada que comiencen por Child_10_ y terminen en .com

[[Archivo:Child.png|no]]

sed -n ${SLURM_ARRAY_TASK_ID}p) ← Sed imprimirá las líneas de cada archivo de entrada y la variable $SLURM_ARRAY_TASK_ID asumirá estas entradas como matriz de simulación en nuestro job array, en este ejemplo tenemos 63 archivos de entrada.

Para más detalles sobre los archivos stdin, stdout y stderr de una simulación % A será reemplazado por el valor de SLURM_ARRAY_JOB_ID que es el Job ID de nuestra tarea y %a será reemplazado por el valor de SLURM_ARRAY_TASK_ID que corresponde a la simulación X de nuestra tarea.

Srun g16 $file: ejecutará el comando gaussian g16 interpretando la variable $file en los nodos de cómputo asignados.

Enviar el script:
<pre>
[prueba@leftraru1 ~]$ sbatch prueba.sh
</pre>

=== Ejecución de una tarea que ocupa mucha RAM por CPU ===
Debemos tener en cuenta que la RAM que SLURM reserva por defecto son 1000 MB. Un típico error de cancelación de tarea por falta de memoria es el siguiente:
<pre>
/tmp/slurmd/job136839939/slurm_script: line 15: 23547 Killed ./programa.sh
slurmstepd: error: Detected 1 oom-kill event(s) in step 136839939.batch cgroup. Some of your processes
may have been killed by the cgroup out-of-memory handler.
</pre>

Si su tarea ocupa más de la memoria por defecto, puede utilizar el siguiente parámetro:
<pre>
#SBATCH --mem-per-cpu=2300 #Máxima RAM por CPU
</pre>
Esto hará que SLURM reserve más RAM por CPU para sus tareas.

Tenga en cuenta que nuestros nodos tienen 46 GB de memoria RAM (Partición slims), 187 GB (Partición general) y 765 GB (Partición largemem) por nodo. [https://wiki.nlhpc.cl/Hardware_Disponible Más información].

Otra forma de reservar memoria es utilizando el siguiente parámetro:

<pre>
#SBATCH --mem=2300
</pre>
En este caso SLURM realizará una reserva de memoria de 2300 MB pero por la totalidad del trabajo.

Los parámetros anteriores al igual que el número de CPUs que se van a usar, hay que afinarlos lo mejor posible. Para ello lo que se puede hacer es hacer pruebas en los nodos logins, sin lanzar en las colas, y así estudiar el uso de RAM y CPU por parte de sus procesos.

=== Ejecución de una tarea con Dependencias ===
Las dependencias de trabajos se utilizan para aplazar el inicio de un trabajo hasta que se satisfagan las dependencias especificadas. Se especifican con la opción --dependency en el siguiente formato:
<pre>
sbatch --dependency=<type:job_id[:job_id][,type:job_id[:job_id]]> ...
</pre>
Los tipos de dependencias son las siguientes:

* '''after''':jobid[:jobid...] - el trabajo puede empezar después de que los trabajos especificados comiencen
* '''afterany''':jobid[:jobid...] - el trabajo puede empezar después de que los trabajos especificados terminen
* '''afternotok''':jobid[:jobid...] - el trabajo puede empezar después que los trabajos especificados terminan fallidamente
* '''afterok''':jobid[:jobid...] - el trabajo puede empezar después que los trabajos especificados terminan exitósamente

La manera más simple de usar una dependencia del tipo afterok:
<pre>
[prueba@leftraru1 ~]$ sbatch job1.sh
Submitted batch job 21363626
[prueba@leftraru1 ~]$ sbatch --dependency=afterok:21363626 job2.sh
</pre>

Ahora cuando job1.sh termine correctamente, el job2.sh entrará en ejecución. Si job1.sh termina fallidamente, job2.sh no entrará en ejecución nunca pero sí quedará en cola (debe cancelarse manualmente el trabajo).

== Prioridad de tarea ==
Cómo ver la prioridad del trabajo. Los factores que determinan la prioridad del trabajo, incluyendo la fórmula y pesos.

=== Factores que determinan prioridad de tarea ===
<table class="wikitable" style="width: 60%;">
<tr>
<td><b>Comando SLURM</b></td>
<td><b>Descripción</b>
</td></tr>
<tr>
<td>Edad</td>
<td>la cantidad de tiempo que el trabajo ha estado esperando en la cola.
</td></tr>
<tr>
<td>Tamaño de la tarea</td>
<td>número de nodos solicitados por el trabajo.
</td></tr>
<tr>
<td>Partición</td>
<td>prioridad para una partición determinada.
</td></tr>
<tr>
<td>Prioridad Baja</td>
<td>Mientras más tareas se ejecuten en el cluster, menor será la prioridad.
</td></tr>
<tr>
<td>Prioridad Alta</td>
<td>Mientras menos tareas se ejecuten en el clúster, más alta es la prioridad.
</td></tr></table>

== Prioridad de tarea ==
Cómo ver la prioridad del trabajo. Los factores que determinan la prioridad del trabajo, incluyendo la fórmula y pesos.

=== Factores que determinan prioridad de tarea ===
* Edad - la cantidad de tiempo que el trabajo ha estado esperando en la cola
* Tamaño Oficio - número de nodos solicitados por el trabajo
* Partición - prioridad para una partición determinada
* Contribución de prioridades basada en los recursos informáticos utilizados por los miembros de un grupo de investigación en los últimos 30 días - Fairshare.
* Mientras más tareas se ejecuten en el cluster, menor será la prioridad.
* Mientras menos tareas se ejecuten en el clúster, más alta es la prioridad.
Fórmula Prioridad de tarea
<pre>
Job_priority =
(PriorityWeightAge) * (age_factor) +
(PriorityWeightFairshare) * (fair-share_factor) +
(PriorityWeightJobSize) * (job_size_factor) +
(PriorityWeightPartition) * (partition_factor) +
(PriorityWeightQOS) * (QOS_factor)
</pre>

== Visualización de sus Tareas ==
Si Ud. necesita visualizar información acerca de sus tareas de forma interactiva, puede utilizar el comando smap:

smap -i 3

[[Archivo:Smap.png|no|700px]]

De esta forma, tendrá una actualización cada 3 segundos de sus tareas en ejecución incluyendo los nodos en los cuales se encuentran ejecutándose.

== Bibliografía ==
[http://slurm.schedmd.com/documentation.html Manual Oficial de Slurm]

[https://slurm.schedmd.com/scrontab.html Documentación scrontab]

SISTEMA GESTOR DE RECURSOS

2024-04-29T22:00:21Z

Jmorales: /* Estado de nodos */

== SLURM Workload Manager ==
Es un sistema de programación de trabajos y gestión de clústeres de código abierto, tolerante a fallas y altamente escalable para clústeres Linux grandes y pequeños.

Como administrador de carga de trabajo de clúster, Slurm tiene tres funciones clave. Primero, asigna acceso exclusivo y / o no exclusivo a los recursos (nodos de cómputo) a los usuarios durante un período de tiempo para que puedan realizar el trabajo. En segundo lugar, proporciona un marco para iniciar, ejecutar y monitorear el trabajo (normalmente un trabajo paralelo) en el conjunto de nodos asignados. Finalmente, arbitra la contención de recursos mediante la gestión de una cola de trabajo pendiente.

SLURM es el gestor de colas instalado en muchos de los súper computadores del [https://www.top500.org/ TOP500], y también en el clúster del NLHPC. Si Ud. quiere lanzar tareas dentro de Leftaru, debe hacerlo a través de Slurm.

== Conceptos clave ==
SLURM gestiona trabajos de usuario que tienen las siguientes características clave:

* Conjunto de recursos solicitados:
** Número de recursos informáticos: nodos (incluidas todas sus CPUs y núcleos) o CPUs (incluidos todos sus núcleos) o solo núcleos
** Cantidad de memoria: por nodo o por CPU (lógica)
** Tiempo necesario para que las tareas del usuario completen su trabajo
* Una partición de nodo solicitada (cola de trabajos)
* Un nivel de calidad de servicio (QoS) solicitado que otorga a los usuarios accesos específicos
* Una cuenta solicitada con recursos limitados

De manera predeterminada, los usuarios envían trabajos a una partición particular (marcada como tal para todos los usuarios) y bajo una cuenta particular (preestablecida por usuario).

== Particiones SLURM ==

<table class="wikitable" style="width: 60%;">
<tr>
<td><b>Nombre Particion</b></td>
<td><b>Nodos</b></td>
<td><b>CPUs</b></td>
<td><b>RAM</b></td>
<td><b>Descripción</b>
</td></tr>
<tr>
<td>main</td>
<td>27</td>
<td>256</td>
<td>768GB</td>
<td>
</td></tr>
<tr>
<td>general</td>
<td>48</td>
<td>44</td>
<td>187GB</td>
<td>
</td></tr>
<tr>
<td>largemem</td>
<td>9</td>
<td>44</td>
<td>765GB</td>
<td>
</td></tr>
<tr>
<td>v100</td>
<td>2</td>
<td>44</td>
<td>187GB</td>
<td>4 GPUs Nvidia Tesla V100.
</td></tr>
<tr>
<td>mi100</td>
<td>1</td>
<td>128</td>
<td>502GB</td>
<td>2 GPUs AMD Instinct MI100.
</td></tr>
<tr>
<td>debug</td>
<td>4</td>
<td>20</td>
<td>59GB</td>
<td>Destinados a pruebas de máximo 30 minutos.
</td></tr></table>

== Introducción a los comandos slurm ==
<table class="wikitable" style="width: 60%;">
<td><b>Comando SLURM</b></td>
<td><b>Descripción</b>
</td></tr>
<tr>
<td>srun</td>
<td>ejecutar un comando en nodos de cómputo asignados.
</td></tr>
<tr>
<td>sbatch</td>
<td>presentar un script de trabajo
</td></tr>
<tr>
<td>squeue</td>
<td>Mostrar estado de los trabajos en la cola.
</td></tr>
<tr>
<td>scancel</td>
<td>eliminar un trabajo.
</td></tr>
<tr>
<td>sinfo</td>
<td>Muestra el estado de los nodos de cómputo.
</td></tr></table>
Estos son los comandos básicos utilizados para realizar la mayoría de las operaciones básicas con SLURM.

=== Estado de nodos ===
Para consultar el uso de nuestra infraestructura y qué particiones están más libres, le recomendamos el comando sinfo:

<pre># sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
all up infinite 16 mix cn[001,005-006,010,034-035,037,041,045,050,057,108,121],sn[012,016,037]
all up infinite 95 alloc cn[011-033,038-044,046-049,071-120],cnf[001-004],sn[001-011,038-041,043-044]
all up infinite 33 idle fn[001-009],gn[001-002],sn[018-035,045-048]
main* up infinite 20 alloc mn[001-011,014-022]
main* up infinite 7 idle [012-013,023-027]
debug up infinite 4 idle leftraru[1-2]
general up infinite 4 mix sn[012,016,037,042]
general up infinite 22 alloc sn[001-011,013-015,017,036,038-041,043-044]
general up infinite 22 idle sn[018-035,045-048]
largemem up infinite 9 idle fn[001-009]
v100 up infinite 2 idle gn[001-002]
mi100 up infinite 1 idle gna001
</pre>

Fijándose en el texto resaltado de la salida del comando sinfo, se puede comprobar que en la partición main hay 20 nodos que están completamente ocupados (estado alloc), 7 nodos que están libres (idle); por otro lado, en la partición general hay 22 nodos completamente ocupados, 4 parcialmente ocupados y 22 libres. Dado este escenario, está claro que debería de lanzar sus ejecuciones en los nodos de la partición general, por las razones anteriormente expuestas.

Para lanzar en la partición general, debe tener en cuenta que tiene que indicar en su script que se use dicha partición en vez de, probablemente, main. Por supuesto, en esta partición cambian las características técnicas, se pasan a tener 44 cores por nodo (en vez de 256 en main) y una capacidad RAM de 187GB (en vez de 768GB en main). Puede ver más información de las particiones en este link(agregar link), donde podrá revisar que con la inclusión de Guacolda hemos añadido nodos con hasta 765GB de memoria RAM y nodos con GPUs Nvidia Tesla V100 y AMD Instinct MI100 .

Para ver los nodos disponibles y poder determinar en que partición lanzar los trabajos se recomienda utilizar el siguiente comando.

<pre>[prueba@leftraru1 ~]$ sinfo -o "%10P %6D %10t %10m %c" -t idle| egrep "PARTITION|main|general|largemem|v100"
PARTITION NODES STATE MEMORY CPUS
main* 27 idle 768000 256
general 2 idle 187000 44
largemem 7 idle 765000 44
v100 1 idle 187000 44
mi100 1 idle 515047 128
</pre>

El comando anterior muestra que main tiene 27 nodos libres, en este caso es recomendado lanzar en en main para evitar que el trabajo quede en cola por falta de recursos en otros nodos.

Otro Ejemplo, se muestra sólo una partición específica

<pre>[prueba@leftraru1 ~]$ sinfo -p main
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
main* up infinite 15 mix mn[001-008,014-020]
main* up infinite 12 idle mn[009-013,021-027]
</pre>

=== Comprobación del estado de tareas ===
squeue - Muestra el estatus de los trabajos

<pre>squeue # tus trabajos
squeue -u <username> # trabajos por usuario <username>
</pre>

squeue: Comprobar estados de los trabajos

<div style="" class="mw-highlight mw-content-ltr" dir="ltr">
<pre>
JOBID PARTITION NAME USER ST TIME NODES NODELIST(REASON)
13951858_1 general test1 test1 R 1-18:35:14 2 cn[009-010]
13951857_2 general test2 test1 R 1-18:36:11 2 cn[099-100]
13956453 gpu test3 test3 R 1-03:42:08 1 cn039
13956449 largemem test4 test4 R 1-05:42:08 1 cn044
</pre>

Puede utilizar squeue para saber el estado de una o varias de sus tareas

<pre>
$ squeue -o "%.15i %.6P %.8j %.20S %.11M %.11L %.20V %.10Q %.4C %.2D %.6m" -S -t,-Q
JOBID PARTIT NAME START_TIME TIME TIME_LEFT SUBMIT_TIME PRIORITY CPUS NO MIN_ME
10837561 general TEST1 2018-06-18T18:51:01 19:00:31 2-04:59:29 2018-06-18T18:51:01 119972 1 1 1000M
10838562 general TEST2 2018-06-19T11:30:47 2:20:45 2-21:39:15 2018-06-19T11:30:46 119946 1 1 1000M
</pre>

para mas opciones puede revisar con el comando [https://slurm.schedmd.com/squeue.html man squeue] las opciones restantes.

=== Códigos de ESTADO de los trabajos ===

Los trabajos suelen pasar por varios estados durante su ejecución. Los estados típicos son PENDIENTE, EN EJECUCIÓN, SUSPENDIDO, FINALIZANDO y TERMINADO. A continuación se explica cada estado.

'''BF''' BOOT_FAIL
Trabajo finalizado debido a un fallo de arranque, normalmente debido a un fallo de hardware (por ejemplo, no se puede arrancar el nodo o bloque y el trabajo no se puede volver a poner en cola).

'''CA''' CANCELADO
El trabajo ha sido cancelado explícitamente por el usuario o el administrador del sistema. El trabajo puede haberse iniciado o no.

'''CD''' TERMINADO
El trabajo ha terminado todos los procesos en todos los nodos con un código de salida de cero.

'''CF''' CONFIGURANDO
Al trabajo se le han asignado recursos, pero están esperando a que estén listos para su uso (por ejemplo, arrancando).

'''CG''' COMPLETANDO
El trabajo está en proceso de finalización. Algunos procesos en algunos nodos pueden estar aún activos.

'''DL''' FECHA LÍMITE
El trabajo ha finalizado en la fecha límite.

'''F''' FALLÓ
Trabajo finalizado con un código de salida distinto de cero u otra condición de fallo.

'''NF''' NODO_FAIL
Trabajo finalizado debido al fallo de uno o más nodos asignados.

'''OOM''' OUT_OF_MEMORY
El trabajo ha experimentado un error de memoria insuficiente.

'''PD''' PENDIENTE
El trabajo está pendiente de asignación de recursos.

'''PR''' PREEMPTED
El trabajo ha finalizado debido a una espera.

'''R''' EN MARCHA
El trabajo tiene actualmente una asignación.

'''RD''' RESV_DEL_HOLD
El trabajo se está reteniendo después de que se eliminara la reserva solicitada.

'''RF''' REQUEUE_FED
El trabajo está siendo solicitado por una federación.

'''RH''' REQUEUE_HOLD
Se está volviendo a poner en cola un trabajo retenido.

'''RQ''' REQUEUED
Se está poniendo en cola un trabajo que se está completando.

'''RS''' CAMBIO DE TAMAÑO
El trabajo está a punto de cambiar de tamaño.

'''RV''' REVOCADO
El trabajo se ha retirado del clúster debido a que otro clúster ha iniciado el trabajo.

'''SI''' SEÑALANDO
El trabajo está siendo señalizado.

'''SE''' SPECIAL_EXIT
El trabajo se ha puesto en cola en un estado especial. Este estado puede ser establecido por los usuarios, normalmente en EpilogSlurmctld, si el trabajo ha terminado con un valor de salida particular.

'''SO''' STAGE_OUT
El trabajo está preparando los archivos.

'''ST''' PARADO
El trabajo tiene una asignación, pero la ejecución se ha detenido con la señal SIGSTOP. Los CPUS han sido retenidos por este trabajo.

'''S''' SUSPENDIDO
El trabajo tiene una asignación, pero se ha suspendido la ejecución y se han liberado CPUs para otros trabajos.

'''TO''' TIMEOUT
El trabajo ha finalizado al alcanzar su límite de tiempo.

=== Cancelar un trabajo ===
Con scancel se puede cancelar un trabajo en ejecución
<pre>scancel <jobID> # Matar proceso <jobID>. (puede obtener el ID del job con "squeue")
scancel -u <username> # Matar proceso por usuario <username>.
</pre>
<pre>[prueba@leftraru1 ~]$ squeue -u prueba
JOBID PARTITION NAME USER ST TIME NODES NODELIST(REASON)
45594 slims TEST prueba R 0:59 20 cn[001-020]
</pre>
<pre>[prueba@leftraru1 ~]$ scancel 45594
[prueba@leftraru1 ~]$ squeue -u prueba
JOBID PARTITION NAME USER ST TIME NODES NODELIST(REASON)
[prueba@leftraru1 ~]$
</pre>

=== Ver estado de trabajos ===
Para revisar el detalle de las opciones de un trabajo: scontrol show job

<pre>
$ scontrol show job 10837561
JobId=10837561 JobName=TEST1
UserId=usuario(1000) GroupId=group(1000) MCS_label=N/A
Priority=1100 Nice=0 Account=account QOS=120
JobState=RUNNING Reason=None Dependency=(null)
Requeue=0 Restarts=0 BatchFlag=1 Reboot=0 ExitCode=0:0
DerivedExitCode=0:0
RunTime=19:03:08 TimeLimit=3-00:00:00 TimeMin=N/A
SubmitTime=2018-06-18T18:51:01 EligibleTime=2018-06-18T18:51:01
StartTime=2018-06-18T18:51:01 EndTime=2018-06-21T18:51:01 Deadline=N/A
PreemptTime=None SuspendTime=None SecsPreSuspend=0
Partition=slims AllocNode:Sid=leftraru2:5471
ReqNodeList=(null) ExcNodeList=(null)
NodeList=cn021
BatchHost=cn021
NumNodes=1 NumCPUs=1 NumTasks=1 CPUs/Task=1 ReqB:S:C:T=0:0:*:*
TRES=cpu=1,mem=1000M,node=1
Socks/Node=* NtasksPerN:B:S:C=1:0:*:* CoreSpec=*
Nodes=cn021 CPU_IDs=1 Mem=1000 GRES_IDX=
MinCPUsNode=1 MinMemoryCPU=1000M MinTmpDiskNode=0
Features=(null) DelayBoot=00:00:00
Gres=(null) Reservation=(null)
OverSubscribe=OK Contiguous=0 Licenses=matlab Network=(null)
Command=/home/usuario/script.sh
WorkDir=/home/usuario/
StdErr=/home/usuario/10837561_%x.err
StdIn=/dev/null
StdOut=/home/usuario/10837561_%x.out
Power=
BatchScript=
</pre>

Para ver el script asociado a un trabajo: scontrol write batch_script <job_id> -

<pre>
$ scontrol write batch_script 10837561 -
#!/bin/bash
#SBATCH -J nombre_del_trabajo
#SBATCH -p slims
#SBATCH -n 1
#SBATCH --ntasks-per-node=1
#SBATCH --mail-user=usaurio@correo.cl
#SBATCH --mail-type=ALL
#SBATCH -o nombre_del_trabajo%j_%x.out
#SBATCH -e nombre_del_trabajo%j_%x.err
#SBATCH --license=matlab

ml MATLAB/2017a

matlab -nodisplay -nosplash -nodesktop < programa.m
</pre>

== Ejecutando trabajos ==
Actualmente contamos con 2 metodos de enviar trabajos bajo SLURM: '''sbatch''' and '''srun'''. A veces puede ser ventajoso ejecutar un solo comando en el clúster como prueba o realizar rápidamente una operación con recursos adicionales. 'srun' permite a los usuarios hacer esto, y comparte las mismas variables que 'sbatch' . STDOUT y STDERR para un trabajo 'srun' serán redirigidos a la pantalla del usuario. Ctrl-C cancelará un trabajo srun. '''sbatch''' enviará un script de trabajo para que lo ejecute el clúster. Los scripts de trabajo bajo SLURM son simplemente scripts de shell (* .sh) con un conjunto de solicitudes de recursos en la parte superior del script.

Uso básico de srun:

<pre>
srun <algúnComando>
</pre>

Ejemplo de salida (ejecutando el comando "hostname" para saber en que nodo se está ejecutando):
<pre> $ srun hostname
cn003
</pre>

Para enviar un script de trabajo a SLURM:
<pre>sbatch nombreScript.sh</pre>

Example output:
<pre>$ sbatch test-job.sh
Submitted batch job 1169</pre>

=== Variables Slurm ===
Las variables en esta sección son obligatorias, y SLURM las determina para determinar dónde y cuándo se ejecutarán sus trabajos. Si no asigna un valor para estos, el planificador asignará a sus trabajos el valor predeterminado. Si no solicita específicamente recursos para un trabajo, se le asignará un conjunto de recursos predeterminados. Para obtener una lista de todas las variables disponibles, consulte la documentación de SLURM en http://slurm.schedmd.com/sbatch.html. Las variables de este artículo estaban cubiertas porque eran las más relevantes para los casos de uso típicos.

<table class="wikitable" style="width: 100%;">
<tr>
<td><b>Comando SLURM</b></td>
<td><b>Descripción</b>
</td></tr>
<tr>
<td>--mem-per-cpu=<megabytes></td>
<td>Memoria requerida para el trabajo por CPU (en MegaBytes). El valor predeterminado es 1024 MB.
</td></tr>
<tr>
<td>-p <partition>, --partition=<partition></td>
<td>Enviar un trabajo a una partición específica.
</td></tr>
<tr>
<td>-n, --ntasks=<cantidad de tareas></td>
<td>Número de tareas que serán asignadas para el trabajo.
</td></tr>
<tr>
<td>-c <cpus></td>
<td>Esta es la cantidad de CPU que necesita su trabajo. Tenga en cuenta que SLURM es relativamente generoso con las CPU, y el valor especificado aquí es el número "mínimo" de CPU que se asignará a su trabajo. Si hay CPU adicionales disponibles en un nodo más allá de lo solicitado, su trabajo recibirá esas CPU hasta que otros trabajos las necesiten. El valor predeterminado es 1 CPU. Intentar usar más CPU de las que se le asignaron dará como resultado que sus procesos adicionales se turnen en la misma CPU (ralentizando su trabajo).
</td></tr>
<tr>
<td>-J <name>, --jobname=<name></td>
<td>Especifica un nombre a tu trabajo.
</td></tr>
<tr>
<td>--mail-type=BEGIN,END,FAIL,ALL<b> and </b>--mail-user=<emailAddress></td>
<td>Enviar por correo electrónico cuando su trabajo comienza / termina / falla. Puede especificar varios valores para esto (separados por comas) si es necesario.
</td></tr>
<tr>
<td>-o <STDOUT_log>, --output=<STDOUT_log></td>
<td>Redirija la salida a los archivos de registro que especifique. Por defecto, ambos, STDOUT and STDERR son enviados a este archivo. Puedes especificar %j como parte del nombre de archivo de registro para indicar la ID del trabajo (como ejemplo, "#SBATCH -o ouptut_%j.o" redirigiría la salida a "output_123456.o").
</td></tr>
<tr>
<td>-e <STDERR_log>, --error=<STDERR_log></td>
<td>Redireccionar STDERR a un archivo separado. Funciona exactamente igual que "-o".
</td></tr>
<tr>
<td>-t <days-hours:minutes:seconds></td>
<td>Walltime para tu trabajo. La duración del Walltime es el tiempo que espera que su trabajo se ejecute.
</td></tr>
<tr>
<td>-a, --array=<índices></td>
<td>Envía una lista (arreglo) de trabajos identicos. Solo aplica para sbatch.
</td></tr></table>

Los scripts de trabajo especifican los recursos solicitados y otras consideraciones especiales con comentarios especiales "#SBATCH" en la parte superior de un script de trabajo. Aunque muchas de estas opciones son opcionales, las varibles que se ocupan de solicitudes de recursos (CPU, memoria y tiempo) son obligatorias. Todas las variables deben agregarse a sus scripts de la siguiente manera:

<pre>#SBATCH <variable></pre>
Para especificar un nombre al job, por ejemplo, debe agregar lo siguiente a su secuencia de comandos:

<pre>#SBATCH --job-name=nombreDeTrabajo</pre>

===Enviar un script===
<pre>
#!/bin/bash
#SBATCH -J example
#SBATCH -p general
#SBATCH -n 1
#SBATCH --output=example_%j.out
#SBATCH --error=example_%j.err
#SBATCH --mail-user=user@example.com
#SBATCH --mail-type=ALL
</pre>

Como debe comenzar un script en Linux:
<pre>
#!/bin/bash
</pre>

Nombre del trabajo:
<pre>
#SBATCH -J example
</pre>

Nombre la partición donde desea ejecutar el Job:
<pre>
#SBATCH -p general
</pre>

Número de tareas:
<pre>
#SBATCH -n 1
</pre>

Log de salida:
<pre>
#SBATCH -o example_%j.out
</pre>

Log de error:
<pre>
#SBATCH -e example_%j.err
</pre>

Correo para notificaciones:
<pre>
#SBATCH --mail-user=user@example.com
</pre>

Enviar correo en todos casos (verificar opciones arriba):
<pre>
#SBATCH --mail-type=ALL
</pre>

=== Programar tarea (uso de scrontab) ===
'''scrontab''' es una implementación del clásico planificador de tareas de linux '''crontab''' donde se guarda un listado de comandos a ejecutar en un tiempo determinado por el usuario.

Para acceder a scrontab utilice el siguiente comando:
<pre>
[prueba@leftraru1 ~]$ scrontab -e
</pre>

Esto le permitirá editar su archivo scrontab, asignando recursos como también el momento en que desea ejecutar su tarea. La estructura base a utilizar es la siguiente:
<pre>
#SCRON -J mi_tarea
#SCRON -p slims
#SCRON -n 1
#SCRON -c 1
#SCRON --mem-per-cpu=2300
#SCRON --mail-user=foo@bar.com
#SCRON --mail-type=ALL
#SCRON -o mi_tarea_%j.out
#SCRON -e mi_tarea_%j.err
# Example of job definition:
# .---------------- minute (0 - 59)
# | .------------- hour (0 - 23)
# | | .---------- day of month (1 - 31)
# | | | .------- month (1 - 12) OR jan,feb,mar,apr ...
# | | | | .---- day of week (0 - 6) (Sunday=0 or 7) OR sun,mon,tue,wed,thu,fri,sat
# | | | | |
# * * * * * command to be executed
</pre>

* '''minute''' - Corresponde al minuto en que se va a ejecutar el script, valor de 0 a 59.
* '''hour''' - Hora de ejecución, formato 24 horas, valor de 0 a 23, donde 0 son las 12:00 AM.
* '''day of month''' - Día del mes, la tarea se puede ejecutar cada x día, valor de 1 a 31.
* '''month''' - La tarea se puede ejecutar cada x mes, valor de 1 a 12.
* '''day of week''' - Día de la semana, valor de 0 a 6, donde 0 es Domingo.
* '''command to be executed''' - Script a ejecutar por el usuario.

Ejemplo envío de trabajo slurm:

Para la asignación de recursos, utilizaremos la directriz '''#SCRON''', que utiliza los mismos parámetros usados por '''#SBATCH'''.

Luego de asignar los recursos debemos especificar el tiempo, en este caso la tarea será ejecutada todos los días cada 20 minutos, luego debemos indicar el script enviado por el usuario y guardamos los cambios en el archivo.

<pre>
*/20 * * * * /home/prueba/ejemplo/script.sh
</pre>

Es importante destacar que el script a lanzar '''/home/prueba/ejemplo/script.sh''' debe tener permisos de ejecución.

Para revisar el listado de tareas existentes en nuestro scrontab, ejecutamos el comando:
<pre>
[prueba@leftraru1 ~]$ scrontab -l
*/20 * * * * /home/prueba/ejemplo/script.sh
</pre>

Para borrar el contenido de nuestro scrontab:
<pre>
[prueba@leftraru1 ~]$ scrontab -r
</pre>

'''Información a considerar:'''

* Generar archivos de salida correctamente
** Para que el archivo error y out de tu script se generen en el directorio solicitado, ejemplo, /home/prueba/ejemplo/ en tu script debe estar presente el comando cd “/home/prueba/ejemplo”, esto hará que scrontab se posicione dentro del directorio de salida.
* Es distinto el tiempo de programar el envío de una tarea (scrontab) a que una tarea inicie en el clúster (running), ya que esto dependerá de los recursos libres que existan en ese momento en el clúster.
* Para revisar las tareas programadas debe ejecutar en cualquier nodo login el comando '''scrontab -l''' o revisar con el comando '''squeue''':

<pre>
[prueba@leftraru1 ~]$ squeue
24293471 slims /home/eg prueba PD 0:00 1 (BeginTime)
</pre>

== Checkpointing ==
Es la acción de guardar el estado de un proceso en ejecución en un archivo de imagen de punto de control. Este proceso se puede reiniciar más tarde desde el archivo del punto de control, continuando la ejecución desde donde se detuvo, en la misma computadora o en una diferente.

=== ¿Por qué utilizarlo? ===
* Permite ejecuciones de tarea largas que superen el tiempo de ejecución permitido en el cluster (30 días)
* Estar preparados ante fallas del sistema que nos puedan hacer perder resultados de nuestras simulaciones

=== Utilización ===
Lo primero que debemos hacer en nuestro script es cargar el módulo de Mana:
<pre>
ml mana/3.0.0
</pre>
Este módulo provee 3 ejecutables que necesitaremos:

* '''mana_coordinator:''' Coordina los checkpoints entre los distintos procesos
* '''mana_launch:''' Inicia un proceso con checkpoint
* '''mana_restart:''' Reinicia la ejecución desde una imagen del checkpoint

Necesitaremos 2 scripts para trabajar con checkpoints: Inicio y reinicio

=== Script de inicio (inicio.sh) ===
<pre>
#!/bin/bash
##---------------SLURM Parameters - NLHPC ----------------
#SBATCH -J Testcheckpoint
#SBATCH -p general
#SBATCH -n 44
#SBATCH --ntasks-per-node=44
#SBATCH --mem-per-cpu=4363
#SBATCH --mail-user=test@nlhpc.cl
#SBATCH --mail-type=ALL
#SBATCH -o Testcheckpoint_%j.out
#SBATCH -e Testcheckpoint_%j.err

# ----------------Modules----------------------------
ml mana/3.0.0
# ----------------Command--------------------------
#Checkpointing cada 1 hora
mana_cooridinator -i3600
#Ejecutamos nuestra tarea con checkpointing
srun mana_launch ./ejecutable
</pre>

=== Script de reinicio (reinicio.sh) ===
<pre>
#!/bin/bash
##---------------SLURM Parameters - NLHPC ----------------
#SBATCH -J Testcheckpoint
#SBATCH -p general
#SBATCH -n 44
#SBATCH --ntasks-per-node=44
#SBATCH --mem-per-cpu=4363
#SBATCH --mail-user=test@nlhpc.cl
#SBATCH --mail-type=ALL
#SBATCH -o Testcheckpoint_%j.out
#SBATCH -e Testcheckpoint_%j.err

# ----------------Modules----------------------------
ml mana/3.0.0
# ----------------Command--------------------------
#Checkpointing cada 1 hora
mana_cooridinator -i3600
#Reiniciar nuestra tarea desde los archivos de checkpoint
srun mana_restart
</pre>

Para correr estos scripts se puede hacer utilizando la funcionalidad de dependencias de SLURM:
<pre>
[test@leftraru2 test]$ sbatch inicio.sh
Submitted batch job 23574685
[test@leftraru2 test]$ sbatch --dependency=afterok:23574685 reinicio.sh
</pre>

== Trabajos ==
=== Trabajos paralelos ===
Muchos de los trabajos que se ejecutan en un clúster de producción implicarán más de un procesador (CPU, núcleo). Dichos trabajos paralelos deben solicitar la cantidad de recursos necesarios a través de opciones adicionales. Los más comunes son:

Para diferentes tipos de trabajos paralelos, se especificarán diferentes opciones. Los trabajos paralelos más comunes son trabajos de MPI (memoria distribuida), trabajos de subprocesos múltiples (memoria compartida) y los llamados híbridos que son una combinación de los dos. Analicemos por separado con un n ejemplo para cada uno.

=== Ejecución de programas con MPI ===
MPI (interfaz de paso de mensajes) es la API de comunicación estándar para trabajos paralelos de memoria distribuida capaz de implementarse en un clúster. Para programar dicho trabajo, es necesario especificar la cantidad de nodos del clúster que se utilizarán y la cantidad de procesos (tareas) que se ejecutarán en cada nodo.

El siguiente es un ejemplo de ejecución de un programa compilado con Open MPI:

#!/bin/bash
#SBATCH -J example_mpi
#SBATCH -p general
#SBATCH -n 264
#SBATCH --ntasks-per-node=44
#SBATCH --output=example_%j.out
#SBATCH --error=example_%j.err
#SBATCH --mail-user=user@example.com
#SBATCH --mail-type=ALL

srun ./mpi_test
A continuacion se explica línea por líneael script.

Como empieza un shell script en Linux:
<pre>
#!/bin/bash
</pre>

Nombre del Job:
<pre>
#SBATCH -J example_mpi
</pre>

Nombre la particion donde se desea ejecutar el trabajo:
<pre>
#SBATCH -p general
</pre>

Número de tareas. Debe de ser un número múltiplo del número de CPUs máximo que tenga un node de la partición donde se lanza:
<pre>
#SBATCH -n 264
</pre>

Con esto se fuerza a que se lancen 44 tareas MPI en cada uno de los nodos, ocupando de este modo nodos completos. En este caso 6 nodos completos:
<pre>
#SBATCH --ntasks-per-node=44
</pre>

Log de salida:
<pre>
#SBATCH -o example_%j.out
</pre>

Log de error:
<pre>
#SBATCH -e example_%j.err
</pre>

Correo para notificaciones:
<pre>
#SBATCH --mail-user=user@example.com
</pre>

Envía correo en todos los casos:
<pre>
#SBATCH --mail-type=ALL
</pre>

Programa para ejecutar:
<pre>
srun ./mpi_test
</pre>

'''Nota''': no se carga específicamente el módulo "mpi" ya que se carga siempre por defecto.

Para enviarlo al clúster debe ejecutar el comando: ''sbatch script.sh''. El ejemplo anterior ejecutará una tarea OpenMPI con 264 procesos reservando 264 cores para ello.

=== Trabajos multiproceso OpenMP ===
Los trabajos paralelos diseñados para ejecutarse en un sistema multi-core (shared-memory) suelen ser "multi-threaded". La programación de un job de este tipo requiere especificar el número de núcleos que se utilizan para acomodar los subprocesos.

OpenMP es el conjunto común de variables de compilación para facilitar el desarrollo de programas multi-threaded. Un script típico de SLURM para un programa de este tipo se ve así:
<pre>
#!/bin/bash
#SBATCH -J OMPtest
#SBATCH -p general
#SBATCH -n 1
#SBATCH -c 44
#SBATCH --ntasks-per-node=44
#SBATCH --mem-per-cpu=1024
#SBATCH -o example_%j.out
#SBATCH -e example_%j.err
#SBATCH --mail-user=user@example.com
#SBATCH --mail-type=ALL

OMP_NUM_THREADS=$SLURM_CPUS_PER_TASK time ./omp-program
</pre>

Como debe comenzar un script en Linux:
<pre>
#!/bin/bash
</pre>

Nombre del Job:
<pre>
#SBATCH -J OMPtest
</pre>

Nombre la particion donde desea ejecutar el Job:
<pre>
#SBATCH -p general
</pre>

Número de trabajos:
<pre>
#SBATCH -n 1
</pre>

Número de tareas:
<pre>
#SBATCH -c 44
</pre>

Con esto se fuerza a que se agrupen las 44 tareas en un nodo (en OpenMP no hay comunicación entre nodos, por lo que todas las tareas deben estar en el mismo nodo o no funcionaría):
<pre>
#SBATCH --ntasks-per-node=44
</pre>

Memoria por core (MBytes):
<pre>
#SBATCH --mem-per-cpu=1024
</pre>

Log de salida:
<pre>
#SBATCH -o example_%j.out
</pre>

Log de error:
<pre>
#SBATCH -e example_%j.err
</pre>

Correo para notificaciones:
<pre>
#SBATCH --mail-user=user@example.com
</pre>

Enviar correo en todos los casos:
<pre>
#SBATCH --mail-type=ALL
</pre>

Programa para ejecutar:
<pre>
OMP_NUM_THREADS=$SLURM_CPUS_PER_TASK time ./omp-program
</pre>

Cuando se utiliza un programa OpenMP, el número de subprocesos (y, por lo tanto, el número requerido de núcleos) se especifica a través de la variable de entorno OMP_NUM_THREADS que, por lo tanto, aparece en el script frente a la llamada al programa. Lo estamos configurando en la variable interna SLURM_CPUS_PER_TASK que se establece a través de la opción "-c" (a 44 en nuestro ejemplo, que sería el número total de cores de un nodo de la partición "general").

La opción "-n" se mantiene en 1 para indicar un único trabajo principal que tiene 44 tareas. Para asegurarnos que todas las tareas se ejecutan en el mismo nodo, se añade la opción "--ntasks-per-node" con el máximo número de cores que tiene un nodo de la partición donde se está lanzando el trabajo.

=== Ejecución de tareas en GPUs ===
<pre>
#!/bin/bash
#SBATCH -J ejemplo_gpus
#SBATCH -p v100
#SBATCH -n 1
#SBATCH -o ejemplo_%j.out
#SBATCH -e ejemplo_%j.err
#SBATCH --mail-user=correo@gmail.com
#SBATCH --mail-type=ALL
#SBATCH --mem-per-cpu=4300
#SBATCH --gres=gpu:1

./programa
</pre>

Inicio de un bash script en Linux:
<pre>
#!/bin/bash
</pre>

Nombre del trabajo:
<pre>
#SBATCH -J ejemplo_gpus
</pre>

Nombre la partición donde se ejecuta el trabajo:
<pre>
#SBATCH --partition=v100
</pre>

Número de tareas:
<pre>
#SBATCH -n 1
</pre>

Log de salida:
<pre>
#SBATCH -o ejemplo_%j.out
</pre>

Log de error:
<pre>
#SBATCH -e ejemplo_%j.err
</pre>

Correo para notificaciones:
<pre>
#SBATCH --mail-user=user@example.com
</pre>

Enviar correo en todos los casos:
<pre>
#SBATCH --mail-type=ALL
</pre>

Memoria por CPU (MB):
<pre>
#SBATCH --mem-per-cpu=4365
</pre>

Cantidad utilizada de GPUs. El parámetro gpu:1 indica la cantidad de tarjetas a utilizar (cada nodo tiene 2 GPUs):
<pre>
#SBATCH --gres=gpu:1
</pre>

Programa para ejecutar:
<pre>
./programa
</pre>

=== Job Arrays ===
Cuando se ejecutan cientos o miles de simulaciones que utilizan la misma cantidad de recursos, puede ser una ventaja ejecutar estas simulaciones como un "job array". Los job array le permiten enviar miles de dichos trabajos (llamados "job steps") con un solo script. A cada simulación se le asignará un valor único para la variable de entorno SLURM_ARRAY_TASK_ID. Puede usar esta variable para leer parámetros para pasos individuales de una línea dada de un archivo.

=== Caso de uso de un Script Job Array (Gaussian) ===
Tenemos usuarios que actualmente envían varias simulaciones al clúster que son similares en cuanto al uso de recursos, pero, la diferencia es que solo cambia la entrada que le entregan al programa. Para esta situación, recomendamos hacer uso de un script Job Array.

En este ejemplo crearemos un script job array para el software Gaussian, el cual, realizará 63 simulaciones, cada una de estas utilizará 8 cores y podrá alcanzar un uso máximo de 8 Gb de memoria ram. Para este caso utilizaremos la partición slims donde cada nodo tiene 46 Gb de memoria ram y 20 cores.

Script:
<pre>
#!/bin/bash
# ----------------SLURM Parameters----------------
#SBATCH -J prueba
#SBATCH -p slims
#SBATCH -n 1
#SBATCH -c 8
#SBATCH --mem-per-cpu=1000
#SBATCH --mail-user=prueba@nlhpc.cl
#SBATCH --mail-type=ALL
#SBATCH --array=1-63
#SBATCH -o prueba_%A_%a.out
#SBATCH -e prueba_%A_%a.err
#-----------------Toolchain---------------------------
ml purge
ml intel/2019b
# ----------------Módulos-----------------------------
ml g16/B.01
# ----------------Comandos--------------------------
file=$(ls Child_10_*.com | sed -n ${SLURM_ARRAY_TASK_ID}p)
srun g16 $file
</pre>

'''
Descripción de comandos utilizados en script:'''

Inicio de un bash script en Linux:
<pre>
#!/bin/bash
</pre>

Nombre de la simulación:
<pre>
#SBATCH -J prueba
</pre>

Nombre la partición donde se ejecuta la simulación:
<pre>
#SBATCH -p slims
</pre>

Número de tareas (1 tarea va a ejecutar 63 simulaciones):
<pre>
#SBATCH -n 1
</pre>

Core’s por tareas (cada tarea utilizará un máximo 8 cores):
<pre>
#SBATCH -c 8
</pre>

Memoria ram por cpu (cada tarea utilizará un máximo 8 Gb de ram):
<pre>
#SBATCH –mem-per-cpu=1000
</pre>

Correo para activar el envío de notificaciones:
<pre>
#SBATCH --mail-user=prueba@nlhpc.cl
</pre>

Permitir envío de notificaciones:
<pre>
#SBATCH --mail-type=ALL
</pre>

Se generan 63 simulaciones diferentes:
<pre>
#SBATCH --array=1-63
</pre>

Log de salida: (ejemplo: prueba_18455017_1.out)

* %A corresponde al Job ID de nuestra tarea que le asignará Slurm → 18455017.
* %a corresponde a la simulación X de nuestra tarea que le asignará Slurm → 1.
<pre>
#SBATCH -o prueba_%A_%a.out
</pre>

Log de errores: (ejemplo: prueba_18455017_1.err)

* %A corresponde al Job ID de nuestra tarea que le asignará Slurm → 18455017.
* %a corresponde a la simulación X de nuestra tarea que le asignará Slurm → 1.

<pre>
#SBATCH -e prueba_%A_%a.err
Toolchain: en este apartado, limpiaremos nuestro entorno de software no deseados y luego escogemos la herramienta informática con la cual está compilado el software Gaussian (nosotros utilizamos el compilador Intel/2019b).

#-----------------Toolchain---------------------------
ml purge
ml intel/2019b
Módulos: cargamos el software Gaussian versión 16/B.0.

# ----------------Módulos-----------------------------
ml g16/B.01
Comandos: aquí definimos los comandos a ejecutar.

# ----------------Comandos--------------------------
file=$(ls Child_10_*.com | sed -n ${SLURM_ARRAY_TASK_ID}p)
srun g16 $file
</pre>
file= variable que va a listar los archivos de entrada que comiencen por Child_10_ y terminen en .com

[[Archivo:Child.png|no]]

sed -n ${SLURM_ARRAY_TASK_ID}p) ← Sed imprimirá las líneas de cada archivo de entrada y la variable $SLURM_ARRAY_TASK_ID asumirá estas entradas como matriz de simulación en nuestro job array, en este ejemplo tenemos 63 archivos de entrada.

Para más detalles sobre los archivos stdin, stdout y stderr de una simulación % A será reemplazado por el valor de SLURM_ARRAY_JOB_ID que es el Job ID de nuestra tarea y %a será reemplazado por el valor de SLURM_ARRAY_TASK_ID que corresponde a la simulación X de nuestra tarea.

Srun g16 $file: ejecutará el comando gaussian g16 interpretando la variable $file en los nodos de cómputo asignados.

Enviar el script:
<pre>
[prueba@leftraru1 ~]$ sbatch prueba.sh
</pre>

=== Ejecución de una tarea que ocupa mucha RAM por CPU ===
Debemos tener en cuenta que la RAM que SLURM reserva por defecto son 1000 MB. Un típico error de cancelación de tarea por falta de memoria es el siguiente:
<pre>
/tmp/slurmd/job136839939/slurm_script: line 15: 23547 Killed ./programa.sh
slurmstepd: error: Detected 1 oom-kill event(s) in step 136839939.batch cgroup. Some of your processes
may have been killed by the cgroup out-of-memory handler.
</pre>

Si su tarea ocupa más de la memoria por defecto, puede utilizar el siguiente parámetro:
<pre>
#SBATCH --mem-per-cpu=2300 #Máxima RAM por CPU
</pre>
Esto hará que SLURM reserve más RAM por CPU para sus tareas.

Tenga en cuenta que nuestros nodos tienen 46 GB de memoria RAM (Partición slims), 187 GB (Partición general) y 765 GB (Partición largemem) por nodo. [https://wiki.nlhpc.cl/Hardware_Disponible Más información].

Otra forma de reservar memoria es utilizando el siguiente parámetro:

<pre>
#SBATCH --mem=2300
</pre>
En este caso SLURM realizará una reserva de memoria de 2300 MB pero por la totalidad del trabajo.

Los parámetros anteriores al igual que el número de CPUs que se van a usar, hay que afinarlos lo mejor posible. Para ello lo que se puede hacer es hacer pruebas en los nodos logins, sin lanzar en las colas, y así estudiar el uso de RAM y CPU por parte de sus procesos.

=== Ejecución de una tarea con Dependencias ===
Las dependencias de trabajos se utilizan para aplazar el inicio de un trabajo hasta que se satisfagan las dependencias especificadas. Se especifican con la opción --dependency en el siguiente formato:
<pre>
sbatch --dependency=<type:job_id[:job_id][,type:job_id[:job_id]]> ...
</pre>
Los tipos de dependencias son las siguientes:

* '''after''':jobid[:jobid...] - el trabajo puede empezar después de que los trabajos especificados comiencen
* '''afterany''':jobid[:jobid...] - el trabajo puede empezar después de que los trabajos especificados terminen
* '''afternotok''':jobid[:jobid...] - el trabajo puede empezar después que los trabajos especificados terminan fallidamente
* '''afterok''':jobid[:jobid...] - el trabajo puede empezar después que los trabajos especificados terminan exitósamente

La manera más simple de usar una dependencia del tipo afterok:
<pre>
[prueba@leftraru1 ~]$ sbatch job1.sh
Submitted batch job 21363626
[prueba@leftraru1 ~]$ sbatch --dependency=afterok:21363626 job2.sh
</pre>

Ahora cuando job1.sh termine correctamente, el job2.sh entrará en ejecución. Si job1.sh termina fallidamente, job2.sh no entrará en ejecución nunca pero sí quedará en cola (debe cancelarse manualmente el trabajo).

== Prioridad de tarea ==
Cómo ver la prioridad del trabajo. Los factores que determinan la prioridad del trabajo, incluyendo la fórmula y pesos.

=== Factores que determinan prioridad de tarea ===
<table class="wikitable" style="width: 60%;">
<tr>
<td><b>Comando SLURM</b></td>
<td><b>Descripción</b>
</td></tr>
<tr>
<td>Edad</td>
<td>la cantidad de tiempo que el trabajo ha estado esperando en la cola.
</td></tr>
<tr>
<td>Tamaño de la tarea</td>
<td>número de nodos solicitados por el trabajo.
</td></tr>
<tr>
<td>Partición</td>
<td>prioridad para una partición determinada.
</td></tr>
<tr>
<td>Prioridad Baja</td>
<td>Mientras más tareas se ejecuten en el cluster, menor será la prioridad.
</td></tr>
<tr>
<td>Prioridad Alta</td>
<td>Mientras menos tareas se ejecuten en el clúster, más alta es la prioridad.
</td></tr></table>

== Prioridad de tarea ==
Cómo ver la prioridad del trabajo. Los factores que determinan la prioridad del trabajo, incluyendo la fórmula y pesos.

=== Factores que determinan prioridad de tarea ===
* Edad - la cantidad de tiempo que el trabajo ha estado esperando en la cola
* Tamaño Oficio - número de nodos solicitados por el trabajo
* Partición - prioridad para una partición determinada
* Contribución de prioridades basada en los recursos informáticos utilizados por los miembros de un grupo de investigación en los últimos 30 días - Fairshare.
* Mientras más tareas se ejecuten en el cluster, menor será la prioridad.
* Mientras menos tareas se ejecuten en el clúster, más alta es la prioridad.
Fórmula Prioridad de tarea
<pre>
Job_priority =
(PriorityWeightAge) * (age_factor) +
(PriorityWeightFairshare) * (fair-share_factor) +
(PriorityWeightJobSize) * (job_size_factor) +
(PriorityWeightPartition) * (partition_factor) +
(PriorityWeightQOS) * (QOS_factor)
</pre>

== Visualización de sus Tareas ==
Si Ud. necesita visualizar información acerca de sus tareas de forma interactiva, puede utilizar el comando smap:

smap -i 3

[[Archivo:Smap.png|no|700px]]

De esta forma, tendrá una actualización cada 3 segundos de sus tareas en ejecución incluyendo los nodos en los cuales se encuentran ejecutándose.

== Bibliografía ==
[http://slurm.schedmd.com/documentation.html Manual Oficial de Slurm]

[https://slurm.schedmd.com/scrontab.html Documentación scrontab]

SISTEMA GESTOR DE RECURSOS

2024-04-29T21:59:39Z

Jmorales: /* Estado de nodos */

== SLURM Workload Manager ==
Es un sistema de programación de trabajos y gestión de clústeres de código abierto, tolerante a fallas y altamente escalable para clústeres Linux grandes y pequeños.

Como administrador de carga de trabajo de clúster, Slurm tiene tres funciones clave. Primero, asigna acceso exclusivo y / o no exclusivo a los recursos (nodos de cómputo) a los usuarios durante un período de tiempo para que puedan realizar el trabajo. En segundo lugar, proporciona un marco para iniciar, ejecutar y monitorear el trabajo (normalmente un trabajo paralelo) en el conjunto de nodos asignados. Finalmente, arbitra la contención de recursos mediante la gestión de una cola de trabajo pendiente.

SLURM es el gestor de colas instalado en muchos de los súper computadores del [https://www.top500.org/ TOP500], y también en el clúster del NLHPC. Si Ud. quiere lanzar tareas dentro de Leftaru, debe hacerlo a través de Slurm.

== Conceptos clave ==
SLURM gestiona trabajos de usuario que tienen las siguientes características clave:

* Conjunto de recursos solicitados:
** Número de recursos informáticos: nodos (incluidas todas sus CPUs y núcleos) o CPUs (incluidos todos sus núcleos) o solo núcleos
** Cantidad de memoria: por nodo o por CPU (lógica)
** Tiempo necesario para que las tareas del usuario completen su trabajo
* Una partición de nodo solicitada (cola de trabajos)
* Un nivel de calidad de servicio (QoS) solicitado que otorga a los usuarios accesos específicos
* Una cuenta solicitada con recursos limitados

De manera predeterminada, los usuarios envían trabajos a una partición particular (marcada como tal para todos los usuarios) y bajo una cuenta particular (preestablecida por usuario).

== Particiones SLURM ==

<table class="wikitable" style="width: 60%;">
<tr>
<td><b>Nombre Particion</b></td>
<td><b>Nodos</b></td>
<td><b>CPUs</b></td>
<td><b>RAM</b></td>
<td><b>Descripción</b>
</td></tr>
<tr>
<td>main</td>
<td>27</td>
<td>256</td>
<td>768GB</td>
<td>
</td></tr>
<tr>
<td>general</td>
<td>48</td>
<td>44</td>
<td>187GB</td>
<td>
</td></tr>
<tr>
<td>largemem</td>
<td>9</td>
<td>44</td>
<td>765GB</td>
<td>
</td></tr>
<tr>
<td>v100</td>
<td>2</td>
<td>44</td>
<td>187GB</td>
<td>4 GPUs Nvidia Tesla V100.
</td></tr>
<tr>
<td>mi100</td>
<td>1</td>
<td>128</td>
<td>502GB</td>
<td>2 GPUs AMD Instinct MI100.
</td></tr>
<tr>
<td>debug</td>
<td>4</td>
<td>20</td>
<td>59GB</td>
<td>Destinados a pruebas de máximo 30 minutos.
</td></tr></table>

== Introducción a los comandos slurm ==
<table class="wikitable" style="width: 60%;">
<td><b>Comando SLURM</b></td>
<td><b>Descripción</b>
</td></tr>
<tr>
<td>srun</td>
<td>ejecutar un comando en nodos de cómputo asignados.
</td></tr>
<tr>
<td>sbatch</td>
<td>presentar un script de trabajo
</td></tr>
<tr>
<td>squeue</td>
<td>Mostrar estado de los trabajos en la cola.
</td></tr>
<tr>
<td>scancel</td>
<td>eliminar un trabajo.
</td></tr>
<tr>
<td>sinfo</td>
<td>Muestra el estado de los nodos de cómputo.
</td></tr></table>
Estos son los comandos básicos utilizados para realizar la mayoría de las operaciones básicas con SLURM.

=== Estado de nodos ===
Para consultar el uso de nuestra infraestructura y qué particiones están más libres, le recomendamos el comando sinfo:

<pre># sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
all up infinite 16 mix cn[001,005-006,010,034-035,037,041,045,050,057,108,121],sn[012,016,037]
all up infinite 95 alloc cn[011-033,038-044,046-049,071-120],cnf[001-004],sn[001-011,038-041,043-044]
all up infinite 33 idle fn[001-009],gn[001-002],sn[018-035,045-048]
main* up infinite 20 alloc mn[001-011,014-022]
main* up infinite 7 idle [012-013,023-027]
debug up infinite 4 idle leftraru[1-2]
general up infinite 4 mix sn[012,016,037,042]
general up infinite 22 alloc sn[001-011,013-015,017,036,038-041,043-044]
general up infinite 22 idle sn[018-035,045-048]
largemem up infinite 9 idle fn[001-009]
v100 up infinite 2 idle gn[001-002]
mi100 up infinite 1 idle gna001
</pre>

Fijándose en el texto resaltado de la salida del comando sinfo, se puede comprobar que en la partición main hay 20 nodos que están completamente ocupados (estado alloc), 7 nodos que están libres (idle); por otro lado, en la partición general hay 22 nodos completamente ocupados, 4 parcialmente ocupados y 22 libres. Dado este escenario, está claro que debería de lanzar sus ejecuciones en los nodos de la partición general, por las razones anteriormente expuestas.

Para lanzar en la partición general, debe tener en cuenta que tiene que indicar en su script que se use dicha partición en vez de, probablemente, main. Por supuesto, en esta partición cambian las características técnicas, se pasan a tener 44 cores por nodo (en vez de 256 en main) y una capacidad RAM de 187GB (en vez de 768GB en main). Puede ver más información de las particiones en este link(agregar link), donde podrá revisar que con la inclusión de Guacolda hemos añadido nodos con hasta 765GB de memoria RAM y nodos con GPUs Nvidia Tesla V100 y AMD Instinct MI100 .

Para ver los nodos disponibles y poder determinar en que partición lanzar los trabajos se recomienda utilizar el siguiente comando.

<pre>[prueba@leftraru1 ~]$ sinfo -o "%10P %6D %10t %10m %c" -t idle| egrep "PARTITION|slims|general|largemem|v100"
PARTITION NODES STATE MEMORY CPUS
main* 27 idle 768000 256
general 2 idle 187000 44
largemem 7 idle 765000 44
v100 1 idle 187000 44
mi100 1 idle 515047 128
</pre>

El comando anterior muestra que main tiene 27 nodos libres, en este caso es recomendado lanzar en en main para evitar que el trabajo quede en cola por falta de recursos en otros nodos.

Otro Ejemplo, se muestra sólo una partición específica

<pre>[prueba@leftraru1 ~]$ sinfo -p main
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
main* up infinite 15 mix mn[001-008,014-020]
main* up infinite 12 idle mn[009-013,021-027]
</pre>

=== Comprobación del estado de tareas ===
squeue - Muestra el estatus de los trabajos

<pre>squeue # tus trabajos
squeue -u <username> # trabajos por usuario <username>
</pre>

squeue: Comprobar estados de los trabajos

<div style="" class="mw-highlight mw-content-ltr" dir="ltr">
<pre>
JOBID PARTITION NAME USER ST TIME NODES NODELIST(REASON)
13951858_1 general test1 test1 R 1-18:35:14 2 cn[009-010]
13951857_2 general test2 test1 R 1-18:36:11 2 cn[099-100]
13956453 gpu test3 test3 R 1-03:42:08 1 cn039
13956449 largemem test4 test4 R 1-05:42:08 1 cn044
</pre>

Puede utilizar squeue para saber el estado de una o varias de sus tareas

<pre>
$ squeue -o "%.15i %.6P %.8j %.20S %.11M %.11L %.20V %.10Q %.4C %.2D %.6m" -S -t,-Q
JOBID PARTIT NAME START_TIME TIME TIME_LEFT SUBMIT_TIME PRIORITY CPUS NO MIN_ME
10837561 general TEST1 2018-06-18T18:51:01 19:00:31 2-04:59:29 2018-06-18T18:51:01 119972 1 1 1000M
10838562 general TEST2 2018-06-19T11:30:47 2:20:45 2-21:39:15 2018-06-19T11:30:46 119946 1 1 1000M
</pre>

para mas opciones puede revisar con el comando [https://slurm.schedmd.com/squeue.html man squeue] las opciones restantes.

=== Códigos de ESTADO de los trabajos ===

Los trabajos suelen pasar por varios estados durante su ejecución. Los estados típicos son PENDIENTE, EN EJECUCIÓN, SUSPENDIDO, FINALIZANDO y TERMINADO. A continuación se explica cada estado.

'''BF''' BOOT_FAIL
Trabajo finalizado debido a un fallo de arranque, normalmente debido a un fallo de hardware (por ejemplo, no se puede arrancar el nodo o bloque y el trabajo no se puede volver a poner en cola).

'''CA''' CANCELADO
El trabajo ha sido cancelado explícitamente por el usuario o el administrador del sistema. El trabajo puede haberse iniciado o no.

'''CD''' TERMINADO
El trabajo ha terminado todos los procesos en todos los nodos con un código de salida de cero.

'''CF''' CONFIGURANDO
Al trabajo se le han asignado recursos, pero están esperando a que estén listos para su uso (por ejemplo, arrancando).

'''CG''' COMPLETANDO
El trabajo está en proceso de finalización. Algunos procesos en algunos nodos pueden estar aún activos.

'''DL''' FECHA LÍMITE
El trabajo ha finalizado en la fecha límite.

'''F''' FALLÓ
Trabajo finalizado con un código de salida distinto de cero u otra condición de fallo.

'''NF''' NODO_FAIL
Trabajo finalizado debido al fallo de uno o más nodos asignados.

'''OOM''' OUT_OF_MEMORY
El trabajo ha experimentado un error de memoria insuficiente.

'''PD''' PENDIENTE
El trabajo está pendiente de asignación de recursos.

'''PR''' PREEMPTED
El trabajo ha finalizado debido a una espera.

'''R''' EN MARCHA
El trabajo tiene actualmente una asignación.

'''RD''' RESV_DEL_HOLD
El trabajo se está reteniendo después de que se eliminara la reserva solicitada.

'''RF''' REQUEUE_FED
El trabajo está siendo solicitado por una federación.

'''RH''' REQUEUE_HOLD
Se está volviendo a poner en cola un trabajo retenido.

'''RQ''' REQUEUED
Se está poniendo en cola un trabajo que se está completando.

'''RS''' CAMBIO DE TAMAÑO
El trabajo está a punto de cambiar de tamaño.

'''RV''' REVOCADO
El trabajo se ha retirado del clúster debido a que otro clúster ha iniciado el trabajo.

'''SI''' SEÑALANDO
El trabajo está siendo señalizado.

'''SE''' SPECIAL_EXIT
El trabajo se ha puesto en cola en un estado especial. Este estado puede ser establecido por los usuarios, normalmente en EpilogSlurmctld, si el trabajo ha terminado con un valor de salida particular.

'''SO''' STAGE_OUT
El trabajo está preparando los archivos.

'''ST''' PARADO
El trabajo tiene una asignación, pero la ejecución se ha detenido con la señal SIGSTOP. Los CPUS han sido retenidos por este trabajo.

'''S''' SUSPENDIDO
El trabajo tiene una asignación, pero se ha suspendido la ejecución y se han liberado CPUs para otros trabajos.

'''TO''' TIMEOUT
El trabajo ha finalizado al alcanzar su límite de tiempo.

=== Cancelar un trabajo ===
Con scancel se puede cancelar un trabajo en ejecución
<pre>scancel <jobID> # Matar proceso <jobID>. (puede obtener el ID del job con "squeue")
scancel -u <username> # Matar proceso por usuario <username>.
</pre>
<pre>[prueba@leftraru1 ~]$ squeue -u prueba
JOBID PARTITION NAME USER ST TIME NODES NODELIST(REASON)
45594 slims TEST prueba R 0:59 20 cn[001-020]
</pre>
<pre>[prueba@leftraru1 ~]$ scancel 45594
[prueba@leftraru1 ~]$ squeue -u prueba
JOBID PARTITION NAME USER ST TIME NODES NODELIST(REASON)
[prueba@leftraru1 ~]$
</pre>

=== Ver estado de trabajos ===
Para revisar el detalle de las opciones de un trabajo: scontrol show job

<pre>
$ scontrol show job 10837561
JobId=10837561 JobName=TEST1
UserId=usuario(1000) GroupId=group(1000) MCS_label=N/A
Priority=1100 Nice=0 Account=account QOS=120
JobState=RUNNING Reason=None Dependency=(null)
Requeue=0 Restarts=0 BatchFlag=1 Reboot=0 ExitCode=0:0
DerivedExitCode=0:0
RunTime=19:03:08 TimeLimit=3-00:00:00 TimeMin=N/A
SubmitTime=2018-06-18T18:51:01 EligibleTime=2018-06-18T18:51:01
StartTime=2018-06-18T18:51:01 EndTime=2018-06-21T18:51:01 Deadline=N/A
PreemptTime=None SuspendTime=None SecsPreSuspend=0
Partition=slims AllocNode:Sid=leftraru2:5471
ReqNodeList=(null) ExcNodeList=(null)
NodeList=cn021
BatchHost=cn021
NumNodes=1 NumCPUs=1 NumTasks=1 CPUs/Task=1 ReqB:S:C:T=0:0:*:*
TRES=cpu=1,mem=1000M,node=1
Socks/Node=* NtasksPerN:B:S:C=1:0:*:* CoreSpec=*
Nodes=cn021 CPU_IDs=1 Mem=1000 GRES_IDX=
MinCPUsNode=1 MinMemoryCPU=1000M MinTmpDiskNode=0
Features=(null) DelayBoot=00:00:00
Gres=(null) Reservation=(null)
OverSubscribe=OK Contiguous=0 Licenses=matlab Network=(null)
Command=/home/usuario/script.sh
WorkDir=/home/usuario/
StdErr=/home/usuario/10837561_%x.err
StdIn=/dev/null
StdOut=/home/usuario/10837561_%x.out
Power=
BatchScript=
</pre>

Para ver el script asociado a un trabajo: scontrol write batch_script <job_id> -

<pre>
$ scontrol write batch_script 10837561 -
#!/bin/bash
#SBATCH -J nombre_del_trabajo
#SBATCH -p slims
#SBATCH -n 1
#SBATCH --ntasks-per-node=1
#SBATCH --mail-user=usaurio@correo.cl
#SBATCH --mail-type=ALL
#SBATCH -o nombre_del_trabajo%j_%x.out
#SBATCH -e nombre_del_trabajo%j_%x.err
#SBATCH --license=matlab

ml MATLAB/2017a

matlab -nodisplay -nosplash -nodesktop < programa.m
</pre>

== Ejecutando trabajos ==
Actualmente contamos con 2 metodos de enviar trabajos bajo SLURM: '''sbatch''' and '''srun'''. A veces puede ser ventajoso ejecutar un solo comando en el clúster como prueba o realizar rápidamente una operación con recursos adicionales. 'srun' permite a los usuarios hacer esto, y comparte las mismas variables que 'sbatch' . STDOUT y STDERR para un trabajo 'srun' serán redirigidos a la pantalla del usuario. Ctrl-C cancelará un trabajo srun. '''sbatch''' enviará un script de trabajo para que lo ejecute el clúster. Los scripts de trabajo bajo SLURM son simplemente scripts de shell (* .sh) con un conjunto de solicitudes de recursos en la parte superior del script.

Uso básico de srun:

<pre>
srun <algúnComando>
</pre>

Ejemplo de salida (ejecutando el comando "hostname" para saber en que nodo se está ejecutando):
<pre> $ srun hostname
cn003
</pre>

Para enviar un script de trabajo a SLURM:
<pre>sbatch nombreScript.sh</pre>

Example output:
<pre>$ sbatch test-job.sh
Submitted batch job 1169</pre>

=== Variables Slurm ===
Las variables en esta sección son obligatorias, y SLURM las determina para determinar dónde y cuándo se ejecutarán sus trabajos. Si no asigna un valor para estos, el planificador asignará a sus trabajos el valor predeterminado. Si no solicita específicamente recursos para un trabajo, se le asignará un conjunto de recursos predeterminados. Para obtener una lista de todas las variables disponibles, consulte la documentación de SLURM en http://slurm.schedmd.com/sbatch.html. Las variables de este artículo estaban cubiertas porque eran las más relevantes para los casos de uso típicos.

<table class="wikitable" style="width: 100%;">
<tr>
<td><b>Comando SLURM</b></td>
<td><b>Descripción</b>
</td></tr>
<tr>
<td>--mem-per-cpu=<megabytes></td>
<td>Memoria requerida para el trabajo por CPU (en MegaBytes). El valor predeterminado es 1024 MB.
</td></tr>
<tr>
<td>-p <partition>, --partition=<partition></td>
<td>Enviar un trabajo a una partición específica.
</td></tr>
<tr>
<td>-n, --ntasks=<cantidad de tareas></td>
<td>Número de tareas que serán asignadas para el trabajo.
</td></tr>
<tr>
<td>-c <cpus></td>
<td>Esta es la cantidad de CPU que necesita su trabajo. Tenga en cuenta que SLURM es relativamente generoso con las CPU, y el valor especificado aquí es el número "mínimo" de CPU que se asignará a su trabajo. Si hay CPU adicionales disponibles en un nodo más allá de lo solicitado, su trabajo recibirá esas CPU hasta que otros trabajos las necesiten. El valor predeterminado es 1 CPU. Intentar usar más CPU de las que se le asignaron dará como resultado que sus procesos adicionales se turnen en la misma CPU (ralentizando su trabajo).
</td></tr>
<tr>
<td>-J <name>, --jobname=<name></td>
<td>Especifica un nombre a tu trabajo.
</td></tr>
<tr>
<td>--mail-type=BEGIN,END,FAIL,ALL<b> and </b>--mail-user=<emailAddress></td>
<td>Enviar por correo electrónico cuando su trabajo comienza / termina / falla. Puede especificar varios valores para esto (separados por comas) si es necesario.
</td></tr>
<tr>
<td>-o <STDOUT_log>, --output=<STDOUT_log></td>
<td>Redirija la salida a los archivos de registro que especifique. Por defecto, ambos, STDOUT and STDERR son enviados a este archivo. Puedes especificar %j como parte del nombre de archivo de registro para indicar la ID del trabajo (como ejemplo, "#SBATCH -o ouptut_%j.o" redirigiría la salida a "output_123456.o").
</td></tr>
<tr>
<td>-e <STDERR_log>, --error=<STDERR_log></td>
<td>Redireccionar STDERR a un archivo separado. Funciona exactamente igual que "-o".
</td></tr>
<tr>
<td>-t <days-hours:minutes:seconds></td>
<td>Walltime para tu trabajo. La duración del Walltime es el tiempo que espera que su trabajo se ejecute.
</td></tr>
<tr>
<td>-a, --array=<índices></td>
<td>Envía una lista (arreglo) de trabajos identicos. Solo aplica para sbatch.
</td></tr></table>

Los scripts de trabajo especifican los recursos solicitados y otras consideraciones especiales con comentarios especiales "#SBATCH" en la parte superior de un script de trabajo. Aunque muchas de estas opciones son opcionales, las varibles que se ocupan de solicitudes de recursos (CPU, memoria y tiempo) son obligatorias. Todas las variables deben agregarse a sus scripts de la siguiente manera:

<pre>#SBATCH <variable></pre>
Para especificar un nombre al job, por ejemplo, debe agregar lo siguiente a su secuencia de comandos:

<pre>#SBATCH --job-name=nombreDeTrabajo</pre>

===Enviar un script===
<pre>
#!/bin/bash
#SBATCH -J example
#SBATCH -p general
#SBATCH -n 1
#SBATCH --output=example_%j.out
#SBATCH --error=example_%j.err
#SBATCH --mail-user=user@example.com
#SBATCH --mail-type=ALL
</pre>

Como debe comenzar un script en Linux:
<pre>
#!/bin/bash
</pre>

Nombre del trabajo:
<pre>
#SBATCH -J example
</pre>

Nombre la partición donde desea ejecutar el Job:
<pre>
#SBATCH -p general
</pre>

Número de tareas:
<pre>
#SBATCH -n 1
</pre>

Log de salida:
<pre>
#SBATCH -o example_%j.out
</pre>

Log de error:
<pre>
#SBATCH -e example_%j.err
</pre>

Correo para notificaciones:
<pre>
#SBATCH --mail-user=user@example.com
</pre>

Enviar correo en todos casos (verificar opciones arriba):
<pre>
#SBATCH --mail-type=ALL
</pre>

=== Programar tarea (uso de scrontab) ===
'''scrontab''' es una implementación del clásico planificador de tareas de linux '''crontab''' donde se guarda un listado de comandos a ejecutar en un tiempo determinado por el usuario.

Para acceder a scrontab utilice el siguiente comando:
<pre>
[prueba@leftraru1 ~]$ scrontab -e
</pre>

Esto le permitirá editar su archivo scrontab, asignando recursos como también el momento en que desea ejecutar su tarea. La estructura base a utilizar es la siguiente:
<pre>
#SCRON -J mi_tarea
#SCRON -p slims
#SCRON -n 1
#SCRON -c 1
#SCRON --mem-per-cpu=2300
#SCRON --mail-user=foo@bar.com
#SCRON --mail-type=ALL
#SCRON -o mi_tarea_%j.out
#SCRON -e mi_tarea_%j.err
# Example of job definition:
# .---------------- minute (0 - 59)
# | .------------- hour (0 - 23)
# | | .---------- day of month (1 - 31)
# | | | .------- month (1 - 12) OR jan,feb,mar,apr ...
# | | | | .---- day of week (0 - 6) (Sunday=0 or 7) OR sun,mon,tue,wed,thu,fri,sat
# | | | | |
# * * * * * command to be executed
</pre>

* '''minute''' - Corresponde al minuto en que se va a ejecutar el script, valor de 0 a 59.
* '''hour''' - Hora de ejecución, formato 24 horas, valor de 0 a 23, donde 0 son las 12:00 AM.
* '''day of month''' - Día del mes, la tarea se puede ejecutar cada x día, valor de 1 a 31.
* '''month''' - La tarea se puede ejecutar cada x mes, valor de 1 a 12.
* '''day of week''' - Día de la semana, valor de 0 a 6, donde 0 es Domingo.
* '''command to be executed''' - Script a ejecutar por el usuario.

Ejemplo envío de trabajo slurm:

Para la asignación de recursos, utilizaremos la directriz '''#SCRON''', que utiliza los mismos parámetros usados por '''#SBATCH'''.

Luego de asignar los recursos debemos especificar el tiempo, en este caso la tarea será ejecutada todos los días cada 20 minutos, luego debemos indicar el script enviado por el usuario y guardamos los cambios en el archivo.

<pre>
*/20 * * * * /home/prueba/ejemplo/script.sh
</pre>

Es importante destacar que el script a lanzar '''/home/prueba/ejemplo/script.sh''' debe tener permisos de ejecución.

Para revisar el listado de tareas existentes en nuestro scrontab, ejecutamos el comando:
<pre>
[prueba@leftraru1 ~]$ scrontab -l
*/20 * * * * /home/prueba/ejemplo/script.sh
</pre>

Para borrar el contenido de nuestro scrontab:
<pre>
[prueba@leftraru1 ~]$ scrontab -r
</pre>

'''Información a considerar:'''

* Generar archivos de salida correctamente
** Para que el archivo error y out de tu script se generen en el directorio solicitado, ejemplo, /home/prueba/ejemplo/ en tu script debe estar presente el comando cd “/home/prueba/ejemplo”, esto hará que scrontab se posicione dentro del directorio de salida.
* Es distinto el tiempo de programar el envío de una tarea (scrontab) a que una tarea inicie en el clúster (running), ya que esto dependerá de los recursos libres que existan en ese momento en el clúster.
* Para revisar las tareas programadas debe ejecutar en cualquier nodo login el comando '''scrontab -l''' o revisar con el comando '''squeue''':

<pre>
[prueba@leftraru1 ~]$ squeue
24293471 slims /home/eg prueba PD 0:00 1 (BeginTime)
</pre>

== Checkpointing ==
Es la acción de guardar el estado de un proceso en ejecución en un archivo de imagen de punto de control. Este proceso se puede reiniciar más tarde desde el archivo del punto de control, continuando la ejecución desde donde se detuvo, en la misma computadora o en una diferente.

=== ¿Por qué utilizarlo? ===
* Permite ejecuciones de tarea largas que superen el tiempo de ejecución permitido en el cluster (30 días)
* Estar preparados ante fallas del sistema que nos puedan hacer perder resultados de nuestras simulaciones

=== Utilización ===
Lo primero que debemos hacer en nuestro script es cargar el módulo de Mana:
<pre>
ml mana/3.0.0
</pre>
Este módulo provee 3 ejecutables que necesitaremos:

* '''mana_coordinator:''' Coordina los checkpoints entre los distintos procesos
* '''mana_launch:''' Inicia un proceso con checkpoint
* '''mana_restart:''' Reinicia la ejecución desde una imagen del checkpoint

Necesitaremos 2 scripts para trabajar con checkpoints: Inicio y reinicio

=== Script de inicio (inicio.sh) ===
<pre>
#!/bin/bash
##---------------SLURM Parameters - NLHPC ----------------
#SBATCH -J Testcheckpoint
#SBATCH -p general
#SBATCH -n 44
#SBATCH --ntasks-per-node=44
#SBATCH --mem-per-cpu=4363
#SBATCH --mail-user=test@nlhpc.cl
#SBATCH --mail-type=ALL
#SBATCH -o Testcheckpoint_%j.out
#SBATCH -e Testcheckpoint_%j.err

# ----------------Modules----------------------------
ml mana/3.0.0
# ----------------Command--------------------------
#Checkpointing cada 1 hora
mana_cooridinator -i3600
#Ejecutamos nuestra tarea con checkpointing
srun mana_launch ./ejecutable
</pre>

=== Script de reinicio (reinicio.sh) ===
<pre>
#!/bin/bash
##---------------SLURM Parameters - NLHPC ----------------
#SBATCH -J Testcheckpoint
#SBATCH -p general
#SBATCH -n 44
#SBATCH --ntasks-per-node=44
#SBATCH --mem-per-cpu=4363
#SBATCH --mail-user=test@nlhpc.cl
#SBATCH --mail-type=ALL
#SBATCH -o Testcheckpoint_%j.out
#SBATCH -e Testcheckpoint_%j.err

# ----------------Modules----------------------------
ml mana/3.0.0
# ----------------Command--------------------------
#Checkpointing cada 1 hora
mana_cooridinator -i3600
#Reiniciar nuestra tarea desde los archivos de checkpoint
srun mana_restart
</pre>

Para correr estos scripts se puede hacer utilizando la funcionalidad de dependencias de SLURM:
<pre>
[test@leftraru2 test]$ sbatch inicio.sh
Submitted batch job 23574685
[test@leftraru2 test]$ sbatch --dependency=afterok:23574685 reinicio.sh
</pre>

== Trabajos ==
=== Trabajos paralelos ===
Muchos de los trabajos que se ejecutan en un clúster de producción implicarán más de un procesador (CPU, núcleo). Dichos trabajos paralelos deben solicitar la cantidad de recursos necesarios a través de opciones adicionales. Los más comunes son:

Para diferentes tipos de trabajos paralelos, se especificarán diferentes opciones. Los trabajos paralelos más comunes son trabajos de MPI (memoria distribuida), trabajos de subprocesos múltiples (memoria compartida) y los llamados híbridos que son una combinación de los dos. Analicemos por separado con un n ejemplo para cada uno.

=== Ejecución de programas con MPI ===
MPI (interfaz de paso de mensajes) es la API de comunicación estándar para trabajos paralelos de memoria distribuida capaz de implementarse en un clúster. Para programar dicho trabajo, es necesario especificar la cantidad de nodos del clúster que se utilizarán y la cantidad de procesos (tareas) que se ejecutarán en cada nodo.

El siguiente es un ejemplo de ejecución de un programa compilado con Open MPI:

#!/bin/bash
#SBATCH -J example_mpi
#SBATCH -p general
#SBATCH -n 264
#SBATCH --ntasks-per-node=44
#SBATCH --output=example_%j.out
#SBATCH --error=example_%j.err
#SBATCH --mail-user=user@example.com
#SBATCH --mail-type=ALL

srun ./mpi_test
A continuacion se explica línea por líneael script.

Como empieza un shell script en Linux:
<pre>
#!/bin/bash
</pre>

Nombre del Job:
<pre>
#SBATCH -J example_mpi
</pre>

Nombre la particion donde se desea ejecutar el trabajo:
<pre>
#SBATCH -p general
</pre>

Número de tareas. Debe de ser un número múltiplo del número de CPUs máximo que tenga un node de la partición donde se lanza:
<pre>
#SBATCH -n 264
</pre>

Con esto se fuerza a que se lancen 44 tareas MPI en cada uno de los nodos, ocupando de este modo nodos completos. En este caso 6 nodos completos:
<pre>
#SBATCH --ntasks-per-node=44
</pre>

Log de salida:
<pre>
#SBATCH -o example_%j.out
</pre>

Log de error:
<pre>
#SBATCH -e example_%j.err
</pre>

Correo para notificaciones:
<pre>
#SBATCH --mail-user=user@example.com
</pre>

Envía correo en todos los casos:
<pre>
#SBATCH --mail-type=ALL
</pre>

Programa para ejecutar:
<pre>
srun ./mpi_test
</pre>

'''Nota''': no se carga específicamente el módulo "mpi" ya que se carga siempre por defecto.

Para enviarlo al clúster debe ejecutar el comando: ''sbatch script.sh''. El ejemplo anterior ejecutará una tarea OpenMPI con 264 procesos reservando 264 cores para ello.

=== Trabajos multiproceso OpenMP ===
Los trabajos paralelos diseñados para ejecutarse en un sistema multi-core (shared-memory) suelen ser "multi-threaded". La programación de un job de este tipo requiere especificar el número de núcleos que se utilizan para acomodar los subprocesos.

OpenMP es el conjunto común de variables de compilación para facilitar el desarrollo de programas multi-threaded. Un script típico de SLURM para un programa de este tipo se ve así:
<pre>
#!/bin/bash
#SBATCH -J OMPtest
#SBATCH -p general
#SBATCH -n 1
#SBATCH -c 44
#SBATCH --ntasks-per-node=44
#SBATCH --mem-per-cpu=1024
#SBATCH -o example_%j.out
#SBATCH -e example_%j.err
#SBATCH --mail-user=user@example.com
#SBATCH --mail-type=ALL

OMP_NUM_THREADS=$SLURM_CPUS_PER_TASK time ./omp-program
</pre>

Como debe comenzar un script en Linux:
<pre>
#!/bin/bash
</pre>

Nombre del Job:
<pre>
#SBATCH -J OMPtest
</pre>

Nombre la particion donde desea ejecutar el Job:
<pre>
#SBATCH -p general
</pre>

Número de trabajos:
<pre>
#SBATCH -n 1
</pre>

Número de tareas:
<pre>
#SBATCH -c 44
</pre>

Con esto se fuerza a que se agrupen las 44 tareas en un nodo (en OpenMP no hay comunicación entre nodos, por lo que todas las tareas deben estar en el mismo nodo o no funcionaría):
<pre>
#SBATCH --ntasks-per-node=44
</pre>

Memoria por core (MBytes):
<pre>
#SBATCH --mem-per-cpu=1024
</pre>

Log de salida:
<pre>
#SBATCH -o example_%j.out
</pre>

Log de error:
<pre>
#SBATCH -e example_%j.err
</pre>

Correo para notificaciones:
<pre>
#SBATCH --mail-user=user@example.com
</pre>

Enviar correo en todos los casos:
<pre>
#SBATCH --mail-type=ALL
</pre>

Programa para ejecutar:
<pre>
OMP_NUM_THREADS=$SLURM_CPUS_PER_TASK time ./omp-program
</pre>

Cuando se utiliza un programa OpenMP, el número de subprocesos (y, por lo tanto, el número requerido de núcleos) se especifica a través de la variable de entorno OMP_NUM_THREADS que, por lo tanto, aparece en el script frente a la llamada al programa. Lo estamos configurando en la variable interna SLURM_CPUS_PER_TASK que se establece a través de la opción "-c" (a 44 en nuestro ejemplo, que sería el número total de cores de un nodo de la partición "general").

La opción "-n" se mantiene en 1 para indicar un único trabajo principal que tiene 44 tareas. Para asegurarnos que todas las tareas se ejecutan en el mismo nodo, se añade la opción "--ntasks-per-node" con el máximo número de cores que tiene un nodo de la partición donde se está lanzando el trabajo.

=== Ejecución de tareas en GPUs ===
<pre>
#!/bin/bash
#SBATCH -J ejemplo_gpus
#SBATCH -p v100
#SBATCH -n 1
#SBATCH -o ejemplo_%j.out
#SBATCH -e ejemplo_%j.err
#SBATCH --mail-user=correo@gmail.com
#SBATCH --mail-type=ALL
#SBATCH --mem-per-cpu=4300
#SBATCH --gres=gpu:1

./programa
</pre>

Inicio de un bash script en Linux:
<pre>
#!/bin/bash
</pre>

Nombre del trabajo:
<pre>
#SBATCH -J ejemplo_gpus
</pre>

Nombre la partición donde se ejecuta el trabajo:
<pre>
#SBATCH --partition=v100
</pre>

Número de tareas:
<pre>
#SBATCH -n 1
</pre>

Log de salida:
<pre>
#SBATCH -o ejemplo_%j.out
</pre>

Log de error:
<pre>
#SBATCH -e ejemplo_%j.err
</pre>

Correo para notificaciones:
<pre>
#SBATCH --mail-user=user@example.com
</pre>

Enviar correo en todos los casos:
<pre>
#SBATCH --mail-type=ALL
</pre>

Memoria por CPU (MB):
<pre>
#SBATCH --mem-per-cpu=4365
</pre>

Cantidad utilizada de GPUs. El parámetro gpu:1 indica la cantidad de tarjetas a utilizar (cada nodo tiene 2 GPUs):
<pre>
#SBATCH --gres=gpu:1
</pre>

Programa para ejecutar:
<pre>
./programa
</pre>

=== Job Arrays ===
Cuando se ejecutan cientos o miles de simulaciones que utilizan la misma cantidad de recursos, puede ser una ventaja ejecutar estas simulaciones como un "job array". Los job array le permiten enviar miles de dichos trabajos (llamados "job steps") con un solo script. A cada simulación se le asignará un valor único para la variable de entorno SLURM_ARRAY_TASK_ID. Puede usar esta variable para leer parámetros para pasos individuales de una línea dada de un archivo.

=== Caso de uso de un Script Job Array (Gaussian) ===
Tenemos usuarios que actualmente envían varias simulaciones al clúster que son similares en cuanto al uso de recursos, pero, la diferencia es que solo cambia la entrada que le entregan al programa. Para esta situación, recomendamos hacer uso de un script Job Array.

En este ejemplo crearemos un script job array para el software Gaussian, el cual, realizará 63 simulaciones, cada una de estas utilizará 8 cores y podrá alcanzar un uso máximo de 8 Gb de memoria ram. Para este caso utilizaremos la partición slims donde cada nodo tiene 46 Gb de memoria ram y 20 cores.

Script:
<pre>
#!/bin/bash
# ----------------SLURM Parameters----------------
#SBATCH -J prueba
#SBATCH -p slims
#SBATCH -n 1
#SBATCH -c 8
#SBATCH --mem-per-cpu=1000
#SBATCH --mail-user=prueba@nlhpc.cl
#SBATCH --mail-type=ALL
#SBATCH --array=1-63
#SBATCH -o prueba_%A_%a.out
#SBATCH -e prueba_%A_%a.err
#-----------------Toolchain---------------------------
ml purge
ml intel/2019b
# ----------------Módulos-----------------------------
ml g16/B.01
# ----------------Comandos--------------------------
file=$(ls Child_10_*.com | sed -n ${SLURM_ARRAY_TASK_ID}p)
srun g16 $file
</pre>

'''
Descripción de comandos utilizados en script:'''

Inicio de un bash script en Linux:
<pre>
#!/bin/bash
</pre>

Nombre de la simulación:
<pre>
#SBATCH -J prueba
</pre>

Nombre la partición donde se ejecuta la simulación:
<pre>
#SBATCH -p slims
</pre>

Número de tareas (1 tarea va a ejecutar 63 simulaciones):
<pre>
#SBATCH -n 1
</pre>

Core’s por tareas (cada tarea utilizará un máximo 8 cores):
<pre>
#SBATCH -c 8
</pre>

Memoria ram por cpu (cada tarea utilizará un máximo 8 Gb de ram):
<pre>
#SBATCH –mem-per-cpu=1000
</pre>

Correo para activar el envío de notificaciones:
<pre>
#SBATCH --mail-user=prueba@nlhpc.cl
</pre>

Permitir envío de notificaciones:
<pre>
#SBATCH --mail-type=ALL
</pre>

Se generan 63 simulaciones diferentes:
<pre>
#SBATCH --array=1-63
</pre>

Log de salida: (ejemplo: prueba_18455017_1.out)

* %A corresponde al Job ID de nuestra tarea que le asignará Slurm → 18455017.
* %a corresponde a la simulación X de nuestra tarea que le asignará Slurm → 1.
<pre>
#SBATCH -o prueba_%A_%a.out
</pre>

Log de errores: (ejemplo: prueba_18455017_1.err)

* %A corresponde al Job ID de nuestra tarea que le asignará Slurm → 18455017.
* %a corresponde a la simulación X de nuestra tarea que le asignará Slurm → 1.

<pre>
#SBATCH -e prueba_%A_%a.err
Toolchain: en este apartado, limpiaremos nuestro entorno de software no deseados y luego escogemos la herramienta informática con la cual está compilado el software Gaussian (nosotros utilizamos el compilador Intel/2019b).

#-----------------Toolchain---------------------------
ml purge
ml intel/2019b
Módulos: cargamos el software Gaussian versión 16/B.0.

# ----------------Módulos-----------------------------
ml g16/B.01
Comandos: aquí definimos los comandos a ejecutar.

# ----------------Comandos--------------------------
file=$(ls Child_10_*.com | sed -n ${SLURM_ARRAY_TASK_ID}p)
srun g16 $file
</pre>
file= variable que va a listar los archivos de entrada que comiencen por Child_10_ y terminen en .com

[[Archivo:Child.png|no]]

sed -n ${SLURM_ARRAY_TASK_ID}p) ← Sed imprimirá las líneas de cada archivo de entrada y la variable $SLURM_ARRAY_TASK_ID asumirá estas entradas como matriz de simulación en nuestro job array, en este ejemplo tenemos 63 archivos de entrada.

Para más detalles sobre los archivos stdin, stdout y stderr de una simulación % A será reemplazado por el valor de SLURM_ARRAY_JOB_ID que es el Job ID de nuestra tarea y %a será reemplazado por el valor de SLURM_ARRAY_TASK_ID que corresponde a la simulación X de nuestra tarea.

Srun g16 $file: ejecutará el comando gaussian g16 interpretando la variable $file en los nodos de cómputo asignados.

Enviar el script:
<pre>
[prueba@leftraru1 ~]$ sbatch prueba.sh
</pre>

=== Ejecución de una tarea que ocupa mucha RAM por CPU ===
Debemos tener en cuenta que la RAM que SLURM reserva por defecto son 1000 MB. Un típico error de cancelación de tarea por falta de memoria es el siguiente:
<pre>
/tmp/slurmd/job136839939/slurm_script: line 15: 23547 Killed ./programa.sh
slurmstepd: error: Detected 1 oom-kill event(s) in step 136839939.batch cgroup. Some of your processes
may have been killed by the cgroup out-of-memory handler.
</pre>

Si su tarea ocupa más de la memoria por defecto, puede utilizar el siguiente parámetro:
<pre>
#SBATCH --mem-per-cpu=2300 #Máxima RAM por CPU
</pre>
Esto hará que SLURM reserve más RAM por CPU para sus tareas.

Tenga en cuenta que nuestros nodos tienen 46 GB de memoria RAM (Partición slims), 187 GB (Partición general) y 765 GB (Partición largemem) por nodo. [https://wiki.nlhpc.cl/Hardware_Disponible Más información].

Otra forma de reservar memoria es utilizando el siguiente parámetro:

<pre>
#SBATCH --mem=2300
</pre>
En este caso SLURM realizará una reserva de memoria de 2300 MB pero por la totalidad del trabajo.

Los parámetros anteriores al igual que el número de CPUs que se van a usar, hay que afinarlos lo mejor posible. Para ello lo que se puede hacer es hacer pruebas en los nodos logins, sin lanzar en las colas, y así estudiar el uso de RAM y CPU por parte de sus procesos.

=== Ejecución de una tarea con Dependencias ===
Las dependencias de trabajos se utilizan para aplazar el inicio de un trabajo hasta que se satisfagan las dependencias especificadas. Se especifican con la opción --dependency en el siguiente formato:
<pre>
sbatch --dependency=<type:job_id[:job_id][,type:job_id[:job_id]]> ...
</pre>
Los tipos de dependencias son las siguientes:

* '''after''':jobid[:jobid...] - el trabajo puede empezar después de que los trabajos especificados comiencen
* '''afterany''':jobid[:jobid...] - el trabajo puede empezar después de que los trabajos especificados terminen
* '''afternotok''':jobid[:jobid...] - el trabajo puede empezar después que los trabajos especificados terminan fallidamente
* '''afterok''':jobid[:jobid...] - el trabajo puede empezar después que los trabajos especificados terminan exitósamente

La manera más simple de usar una dependencia del tipo afterok:
<pre>
[prueba@leftraru1 ~]$ sbatch job1.sh
Submitted batch job 21363626
[prueba@leftraru1 ~]$ sbatch --dependency=afterok:21363626 job2.sh
</pre>

Ahora cuando job1.sh termine correctamente, el job2.sh entrará en ejecución. Si job1.sh termina fallidamente, job2.sh no entrará en ejecución nunca pero sí quedará en cola (debe cancelarse manualmente el trabajo).

== Prioridad de tarea ==
Cómo ver la prioridad del trabajo. Los factores que determinan la prioridad del trabajo, incluyendo la fórmula y pesos.

=== Factores que determinan prioridad de tarea ===
<table class="wikitable" style="width: 60%;">
<tr>
<td><b>Comando SLURM</b></td>
<td><b>Descripción</b>
</td></tr>
<tr>
<td>Edad</td>
<td>la cantidad de tiempo que el trabajo ha estado esperando en la cola.
</td></tr>
<tr>
<td>Tamaño de la tarea</td>
<td>número de nodos solicitados por el trabajo.
</td></tr>
<tr>
<td>Partición</td>
<td>prioridad para una partición determinada.
</td></tr>
<tr>
<td>Prioridad Baja</td>
<td>Mientras más tareas se ejecuten en el cluster, menor será la prioridad.
</td></tr>
<tr>
<td>Prioridad Alta</td>
<td>Mientras menos tareas se ejecuten en el clúster, más alta es la prioridad.
</td></tr></table>

== Prioridad de tarea ==
Cómo ver la prioridad del trabajo. Los factores que determinan la prioridad del trabajo, incluyendo la fórmula y pesos.

=== Factores que determinan prioridad de tarea ===
* Edad - la cantidad de tiempo que el trabajo ha estado esperando en la cola
* Tamaño Oficio - número de nodos solicitados por el trabajo
* Partición - prioridad para una partición determinada
* Contribución de prioridades basada en los recursos informáticos utilizados por los miembros de un grupo de investigación en los últimos 30 días - Fairshare.
* Mientras más tareas se ejecuten en el cluster, menor será la prioridad.
* Mientras menos tareas se ejecuten en el clúster, más alta es la prioridad.
Fórmula Prioridad de tarea
<pre>
Job_priority =
(PriorityWeightAge) * (age_factor) +
(PriorityWeightFairshare) * (fair-share_factor) +
(PriorityWeightJobSize) * (job_size_factor) +
(PriorityWeightPartition) * (partition_factor) +
(PriorityWeightQOS) * (QOS_factor)
</pre>

== Visualización de sus Tareas ==
Si Ud. necesita visualizar información acerca de sus tareas de forma interactiva, puede utilizar el comando smap:

smap -i 3

[[Archivo:Smap.png|no|700px]]

De esta forma, tendrá una actualización cada 3 segundos de sus tareas en ejecución incluyendo los nodos en los cuales se encuentran ejecutándose.

== Bibliografía ==
[http://slurm.schedmd.com/documentation.html Manual Oficial de Slurm]

[https://slurm.schedmd.com/scrontab.html Documentación scrontab]

SISTEMA GESTOR DE RECURSOS

2024-04-29T21:51:57Z

Jmorales: /* Particiones SLURM */

== SLURM Workload Manager ==
Es un sistema de programación de trabajos y gestión de clústeres de código abierto, tolerante a fallas y altamente escalable para clústeres Linux grandes y pequeños.

Como administrador de carga de trabajo de clúster, Slurm tiene tres funciones clave. Primero, asigna acceso exclusivo y / o no exclusivo a los recursos (nodos de cómputo) a los usuarios durante un período de tiempo para que puedan realizar el trabajo. En segundo lugar, proporciona un marco para iniciar, ejecutar y monitorear el trabajo (normalmente un trabajo paralelo) en el conjunto de nodos asignados. Finalmente, arbitra la contención de recursos mediante la gestión de una cola de trabajo pendiente.

SLURM es el gestor de colas instalado en muchos de los súper computadores del [https://www.top500.org/ TOP500], y también en el clúster del NLHPC. Si Ud. quiere lanzar tareas dentro de Leftaru, debe hacerlo a través de Slurm.

== Conceptos clave ==
SLURM gestiona trabajos de usuario que tienen las siguientes características clave:

* Conjunto de recursos solicitados:
** Número de recursos informáticos: nodos (incluidas todas sus CPUs y núcleos) o CPUs (incluidos todos sus núcleos) o solo núcleos
** Cantidad de memoria: por nodo o por CPU (lógica)
** Tiempo necesario para que las tareas del usuario completen su trabajo
* Una partición de nodo solicitada (cola de trabajos)
* Un nivel de calidad de servicio (QoS) solicitado que otorga a los usuarios accesos específicos
* Una cuenta solicitada con recursos limitados

De manera predeterminada, los usuarios envían trabajos a una partición particular (marcada como tal para todos los usuarios) y bajo una cuenta particular (preestablecida por usuario).

== Particiones SLURM ==

<table class="wikitable" style="width: 60%;">
<tr>
<td><b>Nombre Particion</b></td>
<td><b>Nodos</b></td>
<td><b>CPUs</b></td>
<td><b>RAM</b></td>
<td><b>Descripción</b>
</td></tr>
<tr>
<td>main</td>
<td>27</td>
<td>256</td>
<td>768GB</td>
<td>
</td></tr>
<tr>
<td>general</td>
<td>48</td>
<td>44</td>
<td>187GB</td>
<td>
</td></tr>
<tr>
<td>largemem</td>
<td>9</td>
<td>44</td>
<td>765GB</td>
<td>
</td></tr>
<tr>
<td>v100</td>
<td>2</td>
<td>44</td>
<td>187GB</td>
<td>4 GPUs Nvidia Tesla V100.
</td></tr>
<tr>
<td>mi100</td>
<td>1</td>
<td>128</td>
<td>502GB</td>
<td>2 GPUs AMD Instinct MI100.
</td></tr>
<tr>
<td>debug</td>
<td>4</td>
<td>20</td>
<td>59GB</td>
<td>Destinados a pruebas de máximo 30 minutos.
</td></tr></table>

== Introducción a los comandos slurm ==
<table class="wikitable" style="width: 60%;">
<td><b>Comando SLURM</b></td>
<td><b>Descripción</b>
</td></tr>
<tr>
<td>srun</td>
<td>ejecutar un comando en nodos de cómputo asignados.
</td></tr>
<tr>
<td>sbatch</td>
<td>presentar un script de trabajo
</td></tr>
<tr>
<td>squeue</td>
<td>Mostrar estado de los trabajos en la cola.
</td></tr>
<tr>
<td>scancel</td>
<td>eliminar un trabajo.
</td></tr>
<tr>
<td>sinfo</td>
<td>Muestra el estado de los nodos de cómputo.
</td></tr></table>
Estos son los comandos básicos utilizados para realizar la mayoría de las operaciones básicas con SLURM.

=== Estado de nodos ===
Para consultar el uso de nuestra infraestructura y qué particiones están más libres, le recomendamos el comando sinfo:

<pre># sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
all up infinite 16 mix cn[001,005-006,010,034-035,037,041,045,050,057,108,121],sn[012,016,037]
all up infinite 95 alloc cn[011-033,038-044,046-049,071-120],cnf[001-004],sn[001-011,038-041,043-044]
all up infinite 33 idle fn[001-009],gn[001-002],sn[018-035,045-048]
slims* up infinite 18 mix cn[001,003,005-006,010,034-035,043,045,050,057,070,079,085,095,098,108,121]
slims* up infinite 75 alloc cn[007-009,011-033,038-040,051-056,058-069,071-078,086-094,122-128],cnf[001-004]
debug up infinite 4 idle leftraru[1-2]
general up infinite 4 mix sn[012,016,037,042]
general up infinite 22 alloc sn[001-011,013-015,017,036,038-041,043-044]
general up infinite 22 idle sn[018-035,045-048]
largemem up infinite 9 idle fn[001-009]
v100 up infinite 2 idle gn[001-002]
mi100 up infinite 1 idle gna001
</pre>

Fijándose en el texto resaltado de la salida del comando sinfo, se puede comprobar que en la partición slims hay 112 nodos que están completamente ocupados (estado alloc), 20 nodos que están parcialmente ocupados (mix) y ninguno libre (idle); por otro lado, en la partición general hay 22 nodos completamente ocupados, 4 parcialmente ocupados y 22 libres. Dado este escenario, está claro que debería de lanzar sus ejecuciones en los nodos de la partición general, por las razones anteriormente expuestas.

Para lanzar en la partición general, debe tener en cuenta que tiene que indicar en su script que se use dicha partición en vez de, probablemente, slims. Por supuesto, en esta partición cambian las características técnicas, se pasan a tener 44 cores por nodo (en vez de 20 en slims) y una capacidad RAM de 187GB (en vez de 46GB en slims). Puede ver más información de las particiones en este link(agregar link), donde podrá revisar que con la inclusión de Guacolda hemos añadido nodos con hasta 765GB de memoria RAM y nodos con GPUs Nvidia Tesla V100 y AMD Instinct MI100 .

Para ver los nodos disponibles y poder determinar en que partición lanzar los trabajos se recomienda utilizar el siguiente comando.

<pre>[prueba@leftraru1 ~]$ sinfo -o "%10P %6D %10t %10m %c" -t idle| egrep "PARTITION|slims|general|largemem|v100"
PARTITION NODES STATE MEMORY CPUS
slims* 32 idle 46000 20
general 2 idle 187000 44
largemem 7 idle 765000 44
v100 1 idle 187000 44
mi100 1 idle 515047 128
</pre>

El comando anterior muestra que slims tiene 32 nodos libres, en este caso es recomendado lanzar en en slims para evitar que el trabajo quede en cola por falta de recursos en otros nodos.

Otro Ejemplo, se muestra sólo una partición específica

<pre>[prueba@leftraru1 ~]$ sinfo -p slims
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
slims* up infinite 24 mix cn[015,033,036-038,041-050,053-054,075-080,104]
slims* up infinite 76 alloc cn[001-009,019-032,039-040,051-090,093-094,097-099],cnf[001-004]
slims* up infinite 32 idle cn[010-014,016-018,034-035,056-058,073-074,091-100,120-122,125-127]
</pre>

=== Comprobación del estado de tareas ===
squeue - Muestra el estatus de los trabajos

<pre>squeue # tus trabajos
squeue -u <username> # trabajos por usuario <username>
</pre>

squeue: Comprobar estados de los trabajos

<div style="" class="mw-highlight mw-content-ltr" dir="ltr">
<pre>
JOBID PARTITION NAME USER ST TIME NODES NODELIST(REASON)
13951858_1 general test1 test1 R 1-18:35:14 2 cn[009-010]
13951857_2 general test2 test1 R 1-18:36:11 2 cn[099-100]
13956453 gpu test3 test3 R 1-03:42:08 1 cn039
13956449 largemem test4 test4 R 1-05:42:08 1 cn044
</pre>

Puede utilizar squeue para saber el estado de una o varias de sus tareas

<pre>
$ squeue -o "%.15i %.6P %.8j %.20S %.11M %.11L %.20V %.10Q %.4C %.2D %.6m" -S -t,-Q
JOBID PARTIT NAME START_TIME TIME TIME_LEFT SUBMIT_TIME PRIORITY CPUS NO MIN_ME
10837561 general TEST1 2018-06-18T18:51:01 19:00:31 2-04:59:29 2018-06-18T18:51:01 119972 1 1 1000M
10838562 general TEST2 2018-06-19T11:30:47 2:20:45 2-21:39:15 2018-06-19T11:30:46 119946 1 1 1000M
</pre>

para mas opciones puede revisar con el comando [https://slurm.schedmd.com/squeue.html man squeue] las opciones restantes.

=== Códigos de ESTADO de los trabajos ===

Los trabajos suelen pasar por varios estados durante su ejecución. Los estados típicos son PENDIENTE, EN EJECUCIÓN, SUSPENDIDO, FINALIZANDO y TERMINADO. A continuación se explica cada estado.

'''BF''' BOOT_FAIL
Trabajo finalizado debido a un fallo de arranque, normalmente debido a un fallo de hardware (por ejemplo, no se puede arrancar el nodo o bloque y el trabajo no se puede volver a poner en cola).

'''CA''' CANCELADO
El trabajo ha sido cancelado explícitamente por el usuario o el administrador del sistema. El trabajo puede haberse iniciado o no.

'''CD''' TERMINADO
El trabajo ha terminado todos los procesos en todos los nodos con un código de salida de cero.

'''CF''' CONFIGURANDO
Al trabajo se le han asignado recursos, pero están esperando a que estén listos para su uso (por ejemplo, arrancando).

'''CG''' COMPLETANDO
El trabajo está en proceso de finalización. Algunos procesos en algunos nodos pueden estar aún activos.

'''DL''' FECHA LÍMITE
El trabajo ha finalizado en la fecha límite.

'''F''' FALLÓ
Trabajo finalizado con un código de salida distinto de cero u otra condición de fallo.

'''NF''' NODO_FAIL
Trabajo finalizado debido al fallo de uno o más nodos asignados.

'''OOM''' OUT_OF_MEMORY
El trabajo ha experimentado un error de memoria insuficiente.

'''PD''' PENDIENTE
El trabajo está pendiente de asignación de recursos.

'''PR''' PREEMPTED
El trabajo ha finalizado debido a una espera.

'''R''' EN MARCHA
El trabajo tiene actualmente una asignación.

'''RD''' RESV_DEL_HOLD
El trabajo se está reteniendo después de que se eliminara la reserva solicitada.

'''RF''' REQUEUE_FED
El trabajo está siendo solicitado por una federación.

'''RH''' REQUEUE_HOLD
Se está volviendo a poner en cola un trabajo retenido.

'''RQ''' REQUEUED
Se está poniendo en cola un trabajo que se está completando.

'''RS''' CAMBIO DE TAMAÑO
El trabajo está a punto de cambiar de tamaño.

'''RV''' REVOCADO
El trabajo se ha retirado del clúster debido a que otro clúster ha iniciado el trabajo.

'''SI''' SEÑALANDO
El trabajo está siendo señalizado.

'''SE''' SPECIAL_EXIT
El trabajo se ha puesto en cola en un estado especial. Este estado puede ser establecido por los usuarios, normalmente en EpilogSlurmctld, si el trabajo ha terminado con un valor de salida particular.

'''SO''' STAGE_OUT
El trabajo está preparando los archivos.

'''ST''' PARADO
El trabajo tiene una asignación, pero la ejecución se ha detenido con la señal SIGSTOP. Los CPUS han sido retenidos por este trabajo.

'''S''' SUSPENDIDO
El trabajo tiene una asignación, pero se ha suspendido la ejecución y se han liberado CPUs para otros trabajos.

'''TO''' TIMEOUT
El trabajo ha finalizado al alcanzar su límite de tiempo.

=== Cancelar un trabajo ===
Con scancel se puede cancelar un trabajo en ejecución
<pre>scancel <jobID> # Matar proceso <jobID>. (puede obtener el ID del job con "squeue")
scancel -u <username> # Matar proceso por usuario <username>.
</pre>
<pre>[prueba@leftraru1 ~]$ squeue -u prueba
JOBID PARTITION NAME USER ST TIME NODES NODELIST(REASON)
45594 slims TEST prueba R 0:59 20 cn[001-020]
</pre>
<pre>[prueba@leftraru1 ~]$ scancel 45594
[prueba@leftraru1 ~]$ squeue -u prueba
JOBID PARTITION NAME USER ST TIME NODES NODELIST(REASON)
[prueba@leftraru1 ~]$
</pre>

=== Ver estado de trabajos ===
Para revisar el detalle de las opciones de un trabajo: scontrol show job

<pre>
$ scontrol show job 10837561
JobId=10837561 JobName=TEST1
UserId=usuario(1000) GroupId=group(1000) MCS_label=N/A
Priority=1100 Nice=0 Account=account QOS=120
JobState=RUNNING Reason=None Dependency=(null)
Requeue=0 Restarts=0 BatchFlag=1 Reboot=0 ExitCode=0:0
DerivedExitCode=0:0
RunTime=19:03:08 TimeLimit=3-00:00:00 TimeMin=N/A
SubmitTime=2018-06-18T18:51:01 EligibleTime=2018-06-18T18:51:01
StartTime=2018-06-18T18:51:01 EndTime=2018-06-21T18:51:01 Deadline=N/A
PreemptTime=None SuspendTime=None SecsPreSuspend=0
Partition=slims AllocNode:Sid=leftraru2:5471
ReqNodeList=(null) ExcNodeList=(null)
NodeList=cn021
BatchHost=cn021
NumNodes=1 NumCPUs=1 NumTasks=1 CPUs/Task=1 ReqB:S:C:T=0:0:*:*
TRES=cpu=1,mem=1000M,node=1
Socks/Node=* NtasksPerN:B:S:C=1:0:*:* CoreSpec=*
Nodes=cn021 CPU_IDs=1 Mem=1000 GRES_IDX=
MinCPUsNode=1 MinMemoryCPU=1000M MinTmpDiskNode=0
Features=(null) DelayBoot=00:00:00
Gres=(null) Reservation=(null)
OverSubscribe=OK Contiguous=0 Licenses=matlab Network=(null)
Command=/home/usuario/script.sh
WorkDir=/home/usuario/
StdErr=/home/usuario/10837561_%x.err
StdIn=/dev/null
StdOut=/home/usuario/10837561_%x.out
Power=
BatchScript=
</pre>

Para ver el script asociado a un trabajo: scontrol write batch_script <job_id> -

<pre>
$ scontrol write batch_script 10837561 -
#!/bin/bash
#SBATCH -J nombre_del_trabajo
#SBATCH -p slims
#SBATCH -n 1
#SBATCH --ntasks-per-node=1
#SBATCH --mail-user=usaurio@correo.cl
#SBATCH --mail-type=ALL
#SBATCH -o nombre_del_trabajo%j_%x.out
#SBATCH -e nombre_del_trabajo%j_%x.err
#SBATCH --license=matlab

ml MATLAB/2017a

matlab -nodisplay -nosplash -nodesktop < programa.m
</pre>

== Ejecutando trabajos ==
Actualmente contamos con 2 metodos de enviar trabajos bajo SLURM: '''sbatch''' and '''srun'''. A veces puede ser ventajoso ejecutar un solo comando en el clúster como prueba o realizar rápidamente una operación con recursos adicionales. 'srun' permite a los usuarios hacer esto, y comparte las mismas variables que 'sbatch' . STDOUT y STDERR para un trabajo 'srun' serán redirigidos a la pantalla del usuario. Ctrl-C cancelará un trabajo srun. '''sbatch''' enviará un script de trabajo para que lo ejecute el clúster. Los scripts de trabajo bajo SLURM son simplemente scripts de shell (* .sh) con un conjunto de solicitudes de recursos en la parte superior del script.

Uso básico de srun:

<pre>
srun <algúnComando>
</pre>

Ejemplo de salida (ejecutando el comando "hostname" para saber en que nodo se está ejecutando):
<pre> $ srun hostname
cn003
</pre>

Para enviar un script de trabajo a SLURM:
<pre>sbatch nombreScript.sh</pre>

Example output:
<pre>$ sbatch test-job.sh
Submitted batch job 1169</pre>

=== Variables Slurm ===
Las variables en esta sección son obligatorias, y SLURM las determina para determinar dónde y cuándo se ejecutarán sus trabajos. Si no asigna un valor para estos, el planificador asignará a sus trabajos el valor predeterminado. Si no solicita específicamente recursos para un trabajo, se le asignará un conjunto de recursos predeterminados. Para obtener una lista de todas las variables disponibles, consulte la documentación de SLURM en http://slurm.schedmd.com/sbatch.html. Las variables de este artículo estaban cubiertas porque eran las más relevantes para los casos de uso típicos.

<table class="wikitable" style="width: 100%;">
<tr>
<td><b>Comando SLURM</b></td>
<td><b>Descripción</b>
</td></tr>
<tr>
<td>--mem-per-cpu=<megabytes></td>
<td>Memoria requerida para el trabajo por CPU (en MegaBytes). El valor predeterminado es 1024 MB.
</td></tr>
<tr>
<td>-p <partition>, --partition=<partition></td>
<td>Enviar un trabajo a una partición específica.
</td></tr>
<tr>
<td>-n, --ntasks=<cantidad de tareas></td>
<td>Número de tareas que serán asignadas para el trabajo.
</td></tr>
<tr>
<td>-c <cpus></td>
<td>Esta es la cantidad de CPU que necesita su trabajo. Tenga en cuenta que SLURM es relativamente generoso con las CPU, y el valor especificado aquí es el número "mínimo" de CPU que se asignará a su trabajo. Si hay CPU adicionales disponibles en un nodo más allá de lo solicitado, su trabajo recibirá esas CPU hasta que otros trabajos las necesiten. El valor predeterminado es 1 CPU. Intentar usar más CPU de las que se le asignaron dará como resultado que sus procesos adicionales se turnen en la misma CPU (ralentizando su trabajo).
</td></tr>
<tr>
<td>-J <name>, --jobname=<name></td>
<td>Especifica un nombre a tu trabajo.
</td></tr>
<tr>
<td>--mail-type=BEGIN,END,FAIL,ALL<b> and </b>--mail-user=<emailAddress></td>
<td>Enviar por correo electrónico cuando su trabajo comienza / termina / falla. Puede especificar varios valores para esto (separados por comas) si es necesario.
</td></tr>
<tr>
<td>-o <STDOUT_log>, --output=<STDOUT_log></td>
<td>Redirija la salida a los archivos de registro que especifique. Por defecto, ambos, STDOUT and STDERR son enviados a este archivo. Puedes especificar %j como parte del nombre de archivo de registro para indicar la ID del trabajo (como ejemplo, "#SBATCH -o ouptut_%j.o" redirigiría la salida a "output_123456.o").
</td></tr>
<tr>
<td>-e <STDERR_log>, --error=<STDERR_log></td>
<td>Redireccionar STDERR a un archivo separado. Funciona exactamente igual que "-o".
</td></tr>
<tr>
<td>-t <days-hours:minutes:seconds></td>
<td>Walltime para tu trabajo. La duración del Walltime es el tiempo que espera que su trabajo se ejecute.
</td></tr>
<tr>
<td>-a, --array=<índices></td>
<td>Envía una lista (arreglo) de trabajos identicos. Solo aplica para sbatch.
</td></tr></table>

Los scripts de trabajo especifican los recursos solicitados y otras consideraciones especiales con comentarios especiales "#SBATCH" en la parte superior de un script de trabajo. Aunque muchas de estas opciones son opcionales, las varibles que se ocupan de solicitudes de recursos (CPU, memoria y tiempo) son obligatorias. Todas las variables deben agregarse a sus scripts de la siguiente manera:

<pre>#SBATCH <variable></pre>
Para especificar un nombre al job, por ejemplo, debe agregar lo siguiente a su secuencia de comandos:

<pre>#SBATCH --job-name=nombreDeTrabajo</pre>

===Enviar un script===
<pre>
#!/bin/bash
#SBATCH -J example
#SBATCH -p general
#SBATCH -n 1
#SBATCH --output=example_%j.out
#SBATCH --error=example_%j.err
#SBATCH --mail-user=user@example.com
#SBATCH --mail-type=ALL
</pre>

Como debe comenzar un script en Linux:
<pre>
#!/bin/bash
</pre>

Nombre del trabajo:
<pre>
#SBATCH -J example
</pre>

Nombre la partición donde desea ejecutar el Job:
<pre>
#SBATCH -p general
</pre>

Número de tareas:
<pre>
#SBATCH -n 1
</pre>

Log de salida:
<pre>
#SBATCH -o example_%j.out
</pre>

Log de error:
<pre>
#SBATCH -e example_%j.err
</pre>

Correo para notificaciones:
<pre>
#SBATCH --mail-user=user@example.com
</pre>

Enviar correo en todos casos (verificar opciones arriba):
<pre>
#SBATCH --mail-type=ALL
</pre>

=== Programar tarea (uso de scrontab) ===
'''scrontab''' es una implementación del clásico planificador de tareas de linux '''crontab''' donde se guarda un listado de comandos a ejecutar en un tiempo determinado por el usuario.

Para acceder a scrontab utilice el siguiente comando:
<pre>
[prueba@leftraru1 ~]$ scrontab -e
</pre>

Esto le permitirá editar su archivo scrontab, asignando recursos como también el momento en que desea ejecutar su tarea. La estructura base a utilizar es la siguiente:
<pre>
#SCRON -J mi_tarea
#SCRON -p slims
#SCRON -n 1
#SCRON -c 1
#SCRON --mem-per-cpu=2300
#SCRON --mail-user=foo@bar.com
#SCRON --mail-type=ALL
#SCRON -o mi_tarea_%j.out
#SCRON -e mi_tarea_%j.err
# Example of job definition:
# .---------------- minute (0 - 59)
# | .------------- hour (0 - 23)
# | | .---------- day of month (1 - 31)
# | | | .------- month (1 - 12) OR jan,feb,mar,apr ...
# | | | | .---- day of week (0 - 6) (Sunday=0 or 7) OR sun,mon,tue,wed,thu,fri,sat
# | | | | |
# * * * * * command to be executed
</pre>

* '''minute''' - Corresponde al minuto en que se va a ejecutar el script, valor de 0 a 59.
* '''hour''' - Hora de ejecución, formato 24 horas, valor de 0 a 23, donde 0 son las 12:00 AM.
* '''day of month''' - Día del mes, la tarea se puede ejecutar cada x día, valor de 1 a 31.
* '''month''' - La tarea se puede ejecutar cada x mes, valor de 1 a 12.
* '''day of week''' - Día de la semana, valor de 0 a 6, donde 0 es Domingo.
* '''command to be executed''' - Script a ejecutar por el usuario.

Ejemplo envío de trabajo slurm:

Para la asignación de recursos, utilizaremos la directriz '''#SCRON''', que utiliza los mismos parámetros usados por '''#SBATCH'''.

Luego de asignar los recursos debemos especificar el tiempo, en este caso la tarea será ejecutada todos los días cada 20 minutos, luego debemos indicar el script enviado por el usuario y guardamos los cambios en el archivo.

<pre>
*/20 * * * * /home/prueba/ejemplo/script.sh
</pre>

Es importante destacar que el script a lanzar '''/home/prueba/ejemplo/script.sh''' debe tener permisos de ejecución.

Para revisar el listado de tareas existentes en nuestro scrontab, ejecutamos el comando:
<pre>
[prueba@leftraru1 ~]$ scrontab -l
*/20 * * * * /home/prueba/ejemplo/script.sh
</pre>

Para borrar el contenido de nuestro scrontab:
<pre>
[prueba@leftraru1 ~]$ scrontab -r
</pre>

'''Información a considerar:'''

* Generar archivos de salida correctamente
** Para que el archivo error y out de tu script se generen en el directorio solicitado, ejemplo, /home/prueba/ejemplo/ en tu script debe estar presente el comando cd “/home/prueba/ejemplo”, esto hará que scrontab se posicione dentro del directorio de salida.
* Es distinto el tiempo de programar el envío de una tarea (scrontab) a que una tarea inicie en el clúster (running), ya que esto dependerá de los recursos libres que existan en ese momento en el clúster.
* Para revisar las tareas programadas debe ejecutar en cualquier nodo login el comando '''scrontab -l''' o revisar con el comando '''squeue''':

<pre>
[prueba@leftraru1 ~]$ squeue
24293471 slims /home/eg prueba PD 0:00 1 (BeginTime)
</pre>

== Checkpointing ==
Es la acción de guardar el estado de un proceso en ejecución en un archivo de imagen de punto de control. Este proceso se puede reiniciar más tarde desde el archivo del punto de control, continuando la ejecución desde donde se detuvo, en la misma computadora o en una diferente.

=== ¿Por qué utilizarlo? ===
* Permite ejecuciones de tarea largas que superen el tiempo de ejecución permitido en el cluster (30 días)
* Estar preparados ante fallas del sistema que nos puedan hacer perder resultados de nuestras simulaciones

=== Utilización ===
Lo primero que debemos hacer en nuestro script es cargar el módulo de Mana:
<pre>
ml mana/3.0.0
</pre>
Este módulo provee 3 ejecutables que necesitaremos:

* '''mana_coordinator:''' Coordina los checkpoints entre los distintos procesos
* '''mana_launch:''' Inicia un proceso con checkpoint
* '''mana_restart:''' Reinicia la ejecución desde una imagen del checkpoint

Necesitaremos 2 scripts para trabajar con checkpoints: Inicio y reinicio

=== Script de inicio (inicio.sh) ===
<pre>
#!/bin/bash
##---------------SLURM Parameters - NLHPC ----------------
#SBATCH -J Testcheckpoint
#SBATCH -p general
#SBATCH -n 44
#SBATCH --ntasks-per-node=44
#SBATCH --mem-per-cpu=4363
#SBATCH --mail-user=test@nlhpc.cl
#SBATCH --mail-type=ALL
#SBATCH -o Testcheckpoint_%j.out
#SBATCH -e Testcheckpoint_%j.err

# ----------------Modules----------------------------
ml mana/3.0.0
# ----------------Command--------------------------
#Checkpointing cada 1 hora
mana_cooridinator -i3600
#Ejecutamos nuestra tarea con checkpointing
srun mana_launch ./ejecutable
</pre>

=== Script de reinicio (reinicio.sh) ===
<pre>
#!/bin/bash
##---------------SLURM Parameters - NLHPC ----------------
#SBATCH -J Testcheckpoint
#SBATCH -p general
#SBATCH -n 44
#SBATCH --ntasks-per-node=44
#SBATCH --mem-per-cpu=4363
#SBATCH --mail-user=test@nlhpc.cl
#SBATCH --mail-type=ALL
#SBATCH -o Testcheckpoint_%j.out
#SBATCH -e Testcheckpoint_%j.err

# ----------------Modules----------------------------
ml mana/3.0.0
# ----------------Command--------------------------
#Checkpointing cada 1 hora
mana_cooridinator -i3600
#Reiniciar nuestra tarea desde los archivos de checkpoint
srun mana_restart
</pre>

Para correr estos scripts se puede hacer utilizando la funcionalidad de dependencias de SLURM:
<pre>
[test@leftraru2 test]$ sbatch inicio.sh
Submitted batch job 23574685
[test@leftraru2 test]$ sbatch --dependency=afterok:23574685 reinicio.sh
</pre>

== Trabajos ==
=== Trabajos paralelos ===
Muchos de los trabajos que se ejecutan en un clúster de producción implicarán más de un procesador (CPU, núcleo). Dichos trabajos paralelos deben solicitar la cantidad de recursos necesarios a través de opciones adicionales. Los más comunes son:

Para diferentes tipos de trabajos paralelos, se especificarán diferentes opciones. Los trabajos paralelos más comunes son trabajos de MPI (memoria distribuida), trabajos de subprocesos múltiples (memoria compartida) y los llamados híbridos que son una combinación de los dos. Analicemos por separado con un n ejemplo para cada uno.

=== Ejecución de programas con MPI ===
MPI (interfaz de paso de mensajes) es la API de comunicación estándar para trabajos paralelos de memoria distribuida capaz de implementarse en un clúster. Para programar dicho trabajo, es necesario especificar la cantidad de nodos del clúster que se utilizarán y la cantidad de procesos (tareas) que se ejecutarán en cada nodo.

El siguiente es un ejemplo de ejecución de un programa compilado con Open MPI:

#!/bin/bash
#SBATCH -J example_mpi
#SBATCH -p general
#SBATCH -n 264
#SBATCH --ntasks-per-node=44
#SBATCH --output=example_%j.out
#SBATCH --error=example_%j.err
#SBATCH --mail-user=user@example.com
#SBATCH --mail-type=ALL

srun ./mpi_test
A continuacion se explica línea por líneael script.

Como empieza un shell script en Linux:
<pre>
#!/bin/bash
</pre>

Nombre del Job:
<pre>
#SBATCH -J example_mpi
</pre>

Nombre la particion donde se desea ejecutar el trabajo:
<pre>
#SBATCH -p general
</pre>

Número de tareas. Debe de ser un número múltiplo del número de CPUs máximo que tenga un node de la partición donde se lanza:
<pre>
#SBATCH -n 264
</pre>

Con esto se fuerza a que se lancen 44 tareas MPI en cada uno de los nodos, ocupando de este modo nodos completos. En este caso 6 nodos completos:
<pre>
#SBATCH --ntasks-per-node=44
</pre>

Log de salida:
<pre>
#SBATCH -o example_%j.out
</pre>

Log de error:
<pre>
#SBATCH -e example_%j.err
</pre>

Correo para notificaciones:
<pre>
#SBATCH --mail-user=user@example.com
</pre>

Envía correo en todos los casos:
<pre>
#SBATCH --mail-type=ALL
</pre>

Programa para ejecutar:
<pre>
srun ./mpi_test
</pre>

'''Nota''': no se carga específicamente el módulo "mpi" ya que se carga siempre por defecto.

Para enviarlo al clúster debe ejecutar el comando: ''sbatch script.sh''. El ejemplo anterior ejecutará una tarea OpenMPI con 264 procesos reservando 264 cores para ello.

=== Trabajos multiproceso OpenMP ===
Los trabajos paralelos diseñados para ejecutarse en un sistema multi-core (shared-memory) suelen ser "multi-threaded". La programación de un job de este tipo requiere especificar el número de núcleos que se utilizan para acomodar los subprocesos.

OpenMP es el conjunto común de variables de compilación para facilitar el desarrollo de programas multi-threaded. Un script típico de SLURM para un programa de este tipo se ve así:
<pre>
#!/bin/bash
#SBATCH -J OMPtest
#SBATCH -p general
#SBATCH -n 1
#SBATCH -c 44
#SBATCH --ntasks-per-node=44
#SBATCH --mem-per-cpu=1024
#SBATCH -o example_%j.out
#SBATCH -e example_%j.err
#SBATCH --mail-user=user@example.com
#SBATCH --mail-type=ALL

OMP_NUM_THREADS=$SLURM_CPUS_PER_TASK time ./omp-program
</pre>

Como debe comenzar un script en Linux:
<pre>
#!/bin/bash
</pre>

Nombre del Job:
<pre>
#SBATCH -J OMPtest
</pre>

Nombre la particion donde desea ejecutar el Job:
<pre>
#SBATCH -p general
</pre>

Número de trabajos:
<pre>
#SBATCH -n 1
</pre>

Número de tareas:
<pre>
#SBATCH -c 44
</pre>

Con esto se fuerza a que se agrupen las 44 tareas en un nodo (en OpenMP no hay comunicación entre nodos, por lo que todas las tareas deben estar en el mismo nodo o no funcionaría):
<pre>
#SBATCH --ntasks-per-node=44
</pre>

Memoria por core (MBytes):
<pre>
#SBATCH --mem-per-cpu=1024
</pre>

Log de salida:
<pre>
#SBATCH -o example_%j.out
</pre>

Log de error:
<pre>
#SBATCH -e example_%j.err
</pre>

Correo para notificaciones:
<pre>
#SBATCH --mail-user=user@example.com
</pre>

Enviar correo en todos los casos:
<pre>
#SBATCH --mail-type=ALL
</pre>

Programa para ejecutar:
<pre>
OMP_NUM_THREADS=$SLURM_CPUS_PER_TASK time ./omp-program
</pre>

Cuando se utiliza un programa OpenMP, el número de subprocesos (y, por lo tanto, el número requerido de núcleos) se especifica a través de la variable de entorno OMP_NUM_THREADS que, por lo tanto, aparece en el script frente a la llamada al programa. Lo estamos configurando en la variable interna SLURM_CPUS_PER_TASK que se establece a través de la opción "-c" (a 44 en nuestro ejemplo, que sería el número total de cores de un nodo de la partición "general").

La opción "-n" se mantiene en 1 para indicar un único trabajo principal que tiene 44 tareas. Para asegurarnos que todas las tareas se ejecutan en el mismo nodo, se añade la opción "--ntasks-per-node" con el máximo número de cores que tiene un nodo de la partición donde se está lanzando el trabajo.

=== Ejecución de tareas en GPUs ===
<pre>
#!/bin/bash
#SBATCH -J ejemplo_gpus
#SBATCH -p v100
#SBATCH -n 1
#SBATCH -o ejemplo_%j.out
#SBATCH -e ejemplo_%j.err
#SBATCH --mail-user=correo@gmail.com
#SBATCH --mail-type=ALL
#SBATCH --mem-per-cpu=4300
#SBATCH --gres=gpu:1

./programa
</pre>

Inicio de un bash script en Linux:
<pre>
#!/bin/bash
</pre>

Nombre del trabajo:
<pre>
#SBATCH -J ejemplo_gpus
</pre>

Nombre la partición donde se ejecuta el trabajo:
<pre>
#SBATCH --partition=v100
</pre>

Número de tareas:
<pre>
#SBATCH -n 1
</pre>

Log de salida:
<pre>
#SBATCH -o ejemplo_%j.out
</pre>

Log de error:
<pre>
#SBATCH -e ejemplo_%j.err
</pre>

Correo para notificaciones:
<pre>
#SBATCH --mail-user=user@example.com
</pre>

Enviar correo en todos los casos:
<pre>
#SBATCH --mail-type=ALL
</pre>

Memoria por CPU (MB):
<pre>
#SBATCH --mem-per-cpu=4365
</pre>

Cantidad utilizada de GPUs. El parámetro gpu:1 indica la cantidad de tarjetas a utilizar (cada nodo tiene 2 GPUs):
<pre>
#SBATCH --gres=gpu:1
</pre>

Programa para ejecutar:
<pre>
./programa
</pre>

=== Job Arrays ===
Cuando se ejecutan cientos o miles de simulaciones que utilizan la misma cantidad de recursos, puede ser una ventaja ejecutar estas simulaciones como un "job array". Los job array le permiten enviar miles de dichos trabajos (llamados "job steps") con un solo script. A cada simulación se le asignará un valor único para la variable de entorno SLURM_ARRAY_TASK_ID. Puede usar esta variable para leer parámetros para pasos individuales de una línea dada de un archivo.

=== Caso de uso de un Script Job Array (Gaussian) ===
Tenemos usuarios que actualmente envían varias simulaciones al clúster que son similares en cuanto al uso de recursos, pero, la diferencia es que solo cambia la entrada que le entregan al programa. Para esta situación, recomendamos hacer uso de un script Job Array.

En este ejemplo crearemos un script job array para el software Gaussian, el cual, realizará 63 simulaciones, cada una de estas utilizará 8 cores y podrá alcanzar un uso máximo de 8 Gb de memoria ram. Para este caso utilizaremos la partición slims donde cada nodo tiene 46 Gb de memoria ram y 20 cores.

Script:
<pre>
#!/bin/bash
# ----------------SLURM Parameters----------------
#SBATCH -J prueba
#SBATCH -p slims
#SBATCH -n 1
#SBATCH -c 8
#SBATCH --mem-per-cpu=1000
#SBATCH --mail-user=prueba@nlhpc.cl
#SBATCH --mail-type=ALL
#SBATCH --array=1-63
#SBATCH -o prueba_%A_%a.out
#SBATCH -e prueba_%A_%a.err
#-----------------Toolchain---------------------------
ml purge
ml intel/2019b
# ----------------Módulos-----------------------------
ml g16/B.01
# ----------------Comandos--------------------------
file=$(ls Child_10_*.com | sed -n ${SLURM_ARRAY_TASK_ID}p)
srun g16 $file
</pre>

'''
Descripción de comandos utilizados en script:'''

Inicio de un bash script en Linux:
<pre>
#!/bin/bash
</pre>

Nombre de la simulación:
<pre>
#SBATCH -J prueba
</pre>

Nombre la partición donde se ejecuta la simulación:
<pre>
#SBATCH -p slims
</pre>

Número de tareas (1 tarea va a ejecutar 63 simulaciones):
<pre>
#SBATCH -n 1
</pre>

Core’s por tareas (cada tarea utilizará un máximo 8 cores):
<pre>
#SBATCH -c 8
</pre>

Memoria ram por cpu (cada tarea utilizará un máximo 8 Gb de ram):
<pre>
#SBATCH –mem-per-cpu=1000
</pre>

Correo para activar el envío de notificaciones:
<pre>
#SBATCH --mail-user=prueba@nlhpc.cl
</pre>

Permitir envío de notificaciones:
<pre>
#SBATCH --mail-type=ALL
</pre>

Se generan 63 simulaciones diferentes:
<pre>
#SBATCH --array=1-63
</pre>

Log de salida: (ejemplo: prueba_18455017_1.out)

* %A corresponde al Job ID de nuestra tarea que le asignará Slurm → 18455017.
* %a corresponde a la simulación X de nuestra tarea que le asignará Slurm → 1.
<pre>
#SBATCH -o prueba_%A_%a.out
</pre>

Log de errores: (ejemplo: prueba_18455017_1.err)

* %A corresponde al Job ID de nuestra tarea que le asignará Slurm → 18455017.
* %a corresponde a la simulación X de nuestra tarea que le asignará Slurm → 1.

<pre>
#SBATCH -e prueba_%A_%a.err
Toolchain: en este apartado, limpiaremos nuestro entorno de software no deseados y luego escogemos la herramienta informática con la cual está compilado el software Gaussian (nosotros utilizamos el compilador Intel/2019b).

#-----------------Toolchain---------------------------
ml purge
ml intel/2019b
Módulos: cargamos el software Gaussian versión 16/B.0.

# ----------------Módulos-----------------------------
ml g16/B.01
Comandos: aquí definimos los comandos a ejecutar.

# ----------------Comandos--------------------------
file=$(ls Child_10_*.com | sed -n ${SLURM_ARRAY_TASK_ID}p)
srun g16 $file
</pre>
file= variable que va a listar los archivos de entrada que comiencen por Child_10_ y terminen en .com

[[Archivo:Child.png|no]]

sed -n ${SLURM_ARRAY_TASK_ID}p) ← Sed imprimirá las líneas de cada archivo de entrada y la variable $SLURM_ARRAY_TASK_ID asumirá estas entradas como matriz de simulación en nuestro job array, en este ejemplo tenemos 63 archivos de entrada.

Para más detalles sobre los archivos stdin, stdout y stderr de una simulación % A será reemplazado por el valor de SLURM_ARRAY_JOB_ID que es el Job ID de nuestra tarea y %a será reemplazado por el valor de SLURM_ARRAY_TASK_ID que corresponde a la simulación X de nuestra tarea.

Srun g16 $file: ejecutará el comando gaussian g16 interpretando la variable $file en los nodos de cómputo asignados.

Enviar el script:
<pre>
[prueba@leftraru1 ~]$ sbatch prueba.sh
</pre>

=== Ejecución de una tarea que ocupa mucha RAM por CPU ===
Debemos tener en cuenta que la RAM que SLURM reserva por defecto son 1000 MB. Un típico error de cancelación de tarea por falta de memoria es el siguiente:
<pre>
/tmp/slurmd/job136839939/slurm_script: line 15: 23547 Killed ./programa.sh
slurmstepd: error: Detected 1 oom-kill event(s) in step 136839939.batch cgroup. Some of your processes
may have been killed by the cgroup out-of-memory handler.
</pre>

Si su tarea ocupa más de la memoria por defecto, puede utilizar el siguiente parámetro:
<pre>
#SBATCH --mem-per-cpu=2300 #Máxima RAM por CPU
</pre>
Esto hará que SLURM reserve más RAM por CPU para sus tareas.

Tenga en cuenta que nuestros nodos tienen 46 GB de memoria RAM (Partición slims), 187 GB (Partición general) y 765 GB (Partición largemem) por nodo. [https://wiki.nlhpc.cl/Hardware_Disponible Más información].

Otra forma de reservar memoria es utilizando el siguiente parámetro:

<pre>
#SBATCH --mem=2300
</pre>
En este caso SLURM realizará una reserva de memoria de 2300 MB pero por la totalidad del trabajo.

Los parámetros anteriores al igual que el número de CPUs que se van a usar, hay que afinarlos lo mejor posible. Para ello lo que se puede hacer es hacer pruebas en los nodos logins, sin lanzar en las colas, y así estudiar el uso de RAM y CPU por parte de sus procesos.

=== Ejecución de una tarea con Dependencias ===
Las dependencias de trabajos se utilizan para aplazar el inicio de un trabajo hasta que se satisfagan las dependencias especificadas. Se especifican con la opción --dependency en el siguiente formato:
<pre>
sbatch --dependency=<type:job_id[:job_id][,type:job_id[:job_id]]> ...
</pre>
Los tipos de dependencias son las siguientes:

* '''after''':jobid[:jobid...] - el trabajo puede empezar después de que los trabajos especificados comiencen
* '''afterany''':jobid[:jobid...] - el trabajo puede empezar después de que los trabajos especificados terminen
* '''afternotok''':jobid[:jobid...] - el trabajo puede empezar después que los trabajos especificados terminan fallidamente
* '''afterok''':jobid[:jobid...] - el trabajo puede empezar después que los trabajos especificados terminan exitósamente

La manera más simple de usar una dependencia del tipo afterok:
<pre>
[prueba@leftraru1 ~]$ sbatch job1.sh
Submitted batch job 21363626
[prueba@leftraru1 ~]$ sbatch --dependency=afterok:21363626 job2.sh
</pre>

Ahora cuando job1.sh termine correctamente, el job2.sh entrará en ejecución. Si job1.sh termina fallidamente, job2.sh no entrará en ejecución nunca pero sí quedará en cola (debe cancelarse manualmente el trabajo).

== Prioridad de tarea ==
Cómo ver la prioridad del trabajo. Los factores que determinan la prioridad del trabajo, incluyendo la fórmula y pesos.

=== Factores que determinan prioridad de tarea ===
<table class="wikitable" style="width: 60%;">
<tr>
<td><b>Comando SLURM</b></td>
<td><b>Descripción</b>
</td></tr>
<tr>
<td>Edad</td>
<td>la cantidad de tiempo que el trabajo ha estado esperando en la cola.
</td></tr>
<tr>
<td>Tamaño de la tarea</td>
<td>número de nodos solicitados por el trabajo.
</td></tr>
<tr>
<td>Partición</td>
<td>prioridad para una partición determinada.
</td></tr>
<tr>
<td>Prioridad Baja</td>
<td>Mientras más tareas se ejecuten en el cluster, menor será la prioridad.
</td></tr>
<tr>
<td>Prioridad Alta</td>
<td>Mientras menos tareas se ejecuten en el clúster, más alta es la prioridad.
</td></tr></table>

== Prioridad de tarea ==
Cómo ver la prioridad del trabajo. Los factores que determinan la prioridad del trabajo, incluyendo la fórmula y pesos.

=== Factores que determinan prioridad de tarea ===
* Edad - la cantidad de tiempo que el trabajo ha estado esperando en la cola
* Tamaño Oficio - número de nodos solicitados por el trabajo
* Partición - prioridad para una partición determinada
* Contribución de prioridades basada en los recursos informáticos utilizados por los miembros de un grupo de investigación en los últimos 30 días - Fairshare.
* Mientras más tareas se ejecuten en el cluster, menor será la prioridad.
* Mientras menos tareas se ejecuten en el clúster, más alta es la prioridad.
Fórmula Prioridad de tarea
<pre>
Job_priority =
(PriorityWeightAge) * (age_factor) +
(PriorityWeightFairshare) * (fair-share_factor) +
(PriorityWeightJobSize) * (job_size_factor) +
(PriorityWeightPartition) * (partition_factor) +
(PriorityWeightQOS) * (QOS_factor)
</pre>

== Visualización de sus Tareas ==
Si Ud. necesita visualizar información acerca de sus tareas de forma interactiva, puede utilizar el comando smap:

smap -i 3

[[Archivo:Smap.png|no|700px]]

De esta forma, tendrá una actualización cada 3 segundos de sus tareas en ejecución incluyendo los nodos en los cuales se encuentran ejecutándose.

== Bibliografía ==
[http://slurm.schedmd.com/documentation.html Manual Oficial de Slurm]

[https://slurm.schedmd.com/scrontab.html Documentación scrontab]

Como abrir un ticket

2024-04-29T21:48:02Z

Jmorales: /* Asunto o Subject */

== Introducción ==
La intención del siguiente documento es la de indicar algunas buenas prácticas al momento de solicitar al equipo del NLHPC soporte con distintas situaciones que pueda enfrentar, con la intención de que se otorgue la información necesaria de su requerimiento para lograr una atención adecuada por parte de nuestro equipo de trabajo.

== A modo de resumen ==

Siempre considere lo siguiente a la hora de solicitar soporte:

* Indique un ''asunto'' o ''subject'' específico y claro
* Datos importantes a considerar en su mensaje
** Solicitud clara
*** Explicación de qué desea lograr
*** Mención de qué pasos ha seguido para obtener su resultado actual
** Sobre la ejecución de tareas
*** Indicar Job ID
*** Indicar script utilizado
*** Rutas de archivos de entradas y scripts
** Sobre la instalación de software
*** Indicar URL de página oficial
*** Versión requerida
*** Otorgar Licencia de ser requerida
* Tickets cerrados
** No contestar mensajes cerrados, a menos que su requerimiento no haya sido resuelto
** Abrir tickets nuevos, en vez de reabrir tickets antiguos

Si necesita soporte por temas distintos, agradecemos nos envíe correos independientes para poder hacer un seguimiento adecuado a cada una de sus solicitudes. Esto también nos permitirá asignar distintas tareas entre el personal de nuestro equipo.

== Qué es un ticket ==
''Un ticket es un correo que se envía a soporte@nlhpc.cl el que será atendido por nuestro personal.''

Un ticket es la representación de un requerimiento enviado por el usuario mediante un correo electrónico a una casilla de correo específica.

El ticket es recibido en un sistema que permite organizar por tipo de requerimiento, nivel de urgencia y eventual asignación al equipo de trabajo adecuado.

Mediante el sistema de gestión de tickets, se responderá a su requerimiento y nos pondremos en contacto con el solicitante.

A efectos prácticos, el usuario verá una respuesta de correo en su casilla, y si tiene comentarios u observaciones sobre el servicio otorgado, bastará que responda dicho correo.

=== Otras vías de comunicación ===

En el caso que se reciban requerimientos por medios no convencionales o informales, solicitaremos al usuario que debe enviar un mensaje a soporte@nlhpc.cl con su requerimiento para continuar con el procedimiento formal de creación de ticket, lo que permite la gestión correcta de los distintos requerimientos que recibimos.

== Qué información debe tener un ticket ==

=== Asunto o Subject ===
''Ser claro y específico en el requerimiento le permitirá tener una respuesta más precisa a su requerimiento.''

Cuando un usuario realiza una solicitud para obtener asistencia, debe considerar que a mayor cantidad de información útil que otorgue, más acertada y pronta será la respuesta que recibirá.

La primera información que se lee es el ''asunto'' o ''subject'' del correo electrónico, por lo que recomendamos que utilice un descriptor que englobe su solicitud.

Algunos buenos ejemplos de un buen ''asunto'':

* Problema de falta de memoria en Job ID 2504311
* Ejecución de tarea en partición GENERAL con entorno virtual de Python
* Cómo copiar archivos desde mi computadora al cluster
* Solicitud de instalación de software FOOBAR versión 1.2.3

Algunos malos ejemplos:

* Ayuda
* Error
* ''Asunto dejado vacío por el propio usuario''

=== Solicitud de instalación de software ===

''¿Ya ha buscado ejecutando <code>ml avail</code>?''

''Actualmente contamos con una gran cantidad de software disponible en el clúster.''

En el caso de requerir la instalación de un nuevo software, indicar:

* Nombre del software
* Versión o versiones requeridas
* URL oficial para la obtención del código fuente o página oficial
* Si se requiere licencia, el usuario debe otorgar la licencia para su uso

=== Solicitud de verificación de tarea ===

''Recuerde visitar nuestro [https://wiki.nlhpc.cl/Generador%20Scripts Generador de Scripts] como también nuestra [https://wiki.nlhpc.cl Wiki] para conocer cómo editar scripts y ejecutarlos de manera exitosa.''

Las tareas que los usuarios lanzan pueden presentar distintas situaciones, como subutilización de recursos, fallas de ejecución, problemas de módulos, asignaciones incorrectas y otras situaciones.

En el caso de requerir soporte con alguna tarea o información sobre cómo ejecutar tareas en el cluster, recomendamos indicar:

* Nombre del usuario que ejecuta la tarea
* Nombre del script que utiliza
* Ruta de la ubicación del script
* Software utilizado
* Si ha ejecutado ya su tarea
** Job ID de la tarea ejecutada si aplica
** Archivos de salida/error obtenidos si ha ejecutado su tarea
** Resultado obtenido
** Pasos seguidos para obtener el resultado actual
** Resultado esperado

=== Problemas de acceso al clúster ===

''Tenemos un vídeo tutorial de acceso vía SSH en nuestro [https://www.youtube.com/watch?v=TSUQpsttRio canal de youtube].''

Cuando ocurren problemas de acceso, lo principal es poder identificar:

* Usuario que se quiere conectar
* Software utilizado para conectarse
* IPv4 desde la cual se está conectado (puede consultarlo [https://miip.cl/ aquí])
* Error obtenido

Con lo anterior podremos descartar problemas de comunicación, credenciales y validez de la cuenta.

=== Otros requerimientos ===

Si tiene algún otro tipo de requerimiento, siempre considere indicar:

* Usuario utilizado
* Pasos seguidos para obtener el resultado actual
* Resultado esperado
* Aplicaciones usadas y versiones de las mismas
* Otros datos que considere útiles que puedan ayudar a dar una mejor respuesta

== Cierre de tickets ==

''Agradecemos no responda los tickets que indiquen que se han cerrado. En vez de eso, recuerde siempre enviar un nuevo correo.''

Una vez que se ha otorgado una respuesta que satisfaga el requerimiento del usuario, solicitaremos no contestar los correos enviados.

De esta manera, el ticket será cerrado.

Si es necesario, el usuario puede volver a enviar '''un nuevo correo''' lo que creará una nueva solicitud.

Esto último permitirá gestionar de mejor manera los requerimientos que se atienden, verificar las tareas en las que se invierte tiempo en nuestros usuarios, como también verificar los distintos temas que se abordan.

En el caso de que un requerimiento sea similar a uno anterior, también es una buena práctica enviar '''un nuevo correo''' para crear un nuevo ticket.

Si responde un ticket antiguo, esto nos impedirá gestionar de mejor manera las tareas como también el reporte de las mismas.

== Otras fuentes de ayuda ==

Disponemos, además de una [https://wiki.nlhpc.cl Wiki] en donde podrá leer información importante sobre características del clúster y su uso.

También realizamos cursos básicos, avanzados y específicos, los cuales se pueden ver en nuestra página de [https://www.nlhpc.cl/eventos eventos].

Y nuestro canal de [https://www.youtube.com/@nlhpc_chile YouTube] donde podrá ver cursos anteriores y tutoriales que nuestro equipo prepara con el fin de entregar las herramientas adecuadas para el uso del Cluster Guacolda-Leftraru Epu.

Uso de conda

2024-04-29T21:45:03Z

Jmorales: /* Uso de entornos conda con scripts Sbatch */

= Introducción =

Si necesita utilizar entornos virtuales de Conda, el siguiente procedimiento muestra los pasos básicos para crear su primer entorno virtual.

Debe recordar que al ser entornos virtuales, estos estarán almacenados bajo su directorio <code>$HOME</code> y las instalaciones de software bajo este entorno deben ser administradas por el propio usuario.

= Módulos para Conda =

Actualmente en el cluster contamos con distintos módulos que pueden ser utilizados para la creación de entornos virtuales de '''Conda'''.

Anaconda2/5.3.0
Anaconda3/5.1.0
Anaconda3/5.3.0
Anaconda3/2020.02
Miniconda2/4.7.10
Miniconda3/4.5.12

Para nuestro ejemplo utilizaremos <code>Miniconda3/4.5.12</code>, pero puede utilizar el módulo que se adapte a sus necesidades.

= Carga de módulo y activación inicial de Conda =

El siguiente paso debe realizarse una única vez, posterior a esto, el usuario deberá crear, activar y administrar sus propios entornos virtuales.

== Carga de módulo ==

Cargaremos el módulo <code>Miniconda3/4.5.12</code>.

Recuerde que si omite la versión del módulo a cargar, se utilizará el que esté por defecto.

ml purge
ml intel
ml Miniconda3

== Activación de Conda ==

Activaremos el uso de conda con el comando:

conda init bash

Este comando editará su archivo <code>~/.bashrc</code> con un contenido similar a:

# >>> conda initialize >>>
# !! Contents within this block are managed by 'conda init' !!
__conda_setup="$('/home/lmod/software/Core/Miniconda3/4.5.12/bin/conda' 'shell.bash' 'hook' 2> /dev/null)"
if [ $? -eq 0 ]; then
eval "$__conda_setup"
else
if [ -f "/home/lmod/software/Core/Miniconda3/4.5.12/etc/profile.d/conda.sh" ]; then
. "/home/lmod/software/Core/Miniconda3/4.5.12/etc/profile.d/conda.sh"
else
export PATH="/home/lmod/software/Core/Miniconda3/4.5.12/bin:$PATH"
fi
fi
unset __conda_setup
# <<< conda initialize <<<

''Si elimina estas líneas, deberá cargar el módulo y activar conda nuevamente.''

En este punto, es necesario puede salir de su sesión y volver a acceder, o ejecutar el siguiente comando para activar volver a cargar su archivo <code>~/.bashrc</code>:

source ~/.bashrc

Y ya tendrá disponible el comando <code>conda</code> disponible en su sesión.

= Creación de entorno virtual =

Los siguientes pasos permitirán crear un entorno virtual bajo su cuenta personal.

== Creando nuestro entorno virtual ==

Crearemos nuestro entorno virtual con el comando:

conda create -n mi_primer_entorno

Una vez que este entorno se haya creado, lo podremos activar con:

conda activate mi_primer_entorno

''Fíjese que el prompt de su cuenta indicará el nombre del entorno virtual que esté activo. En una primera instancia verá un cambio de '''base''' por '''mi_primer_entorno''' ''

== Creando un entorno virtual con Python 3.9.5 ==

En el caso de querer crear un entorno virtual y en el mismo paso instalar Python en una versión específica, puede usar el comando:

conda create -n mi_entorno_con_python python=3.9.5

Este comando creará el entorno <code>mi_entorno_con_python</code> e instalará la versión '''3.9.5''' de '''Python'''.

Eventualmente, y luego que su entorno haya sido creado, podrá activar este nuevo entorno y verificar la ubicación del comando <code>python</code>

conda activate mi_entorno_con_python
which python

= Instalación de software adicional =

Cuando requiera instalar nuevo software, bastará que active su entorno virtual y use el comando <code>conda</code> para la instalación de software.

Por ejemplo, si queremos instalar '''Tensorflow''' en nuestro entorno <code>mi_primer_entorno</code>, podemos ejecutar:

conda activate mi_primer_entorno
conda install Tensorflow

=== Un ejemplo práctico e instalación de <code>numpy</code> ===

Veamos un ejemplo real: Muchos de nuestros usuarios que utilizan '''Python''' requieren el uso de '''NumPy'''.

Para la instalación bajo nuestro entorno que ya tiene Python instalado, ejecutaremos

conda activate mi_entorno_con_python
conda install numpy

Veremos un mensaje similar a:

Collecting package metadata (current_repodata.json): done
Solving environment: done
## Package Plan ##
environment location: /home/dbowman/.conda/envs/my_env
added / updated specs:
- numpy
The following packages will be installed:
ca-certificates 2023.5.7-hbcca054_0 --> 2023.7.22-hbcca054_0
certifi 2023.5.7-pyhd8ed1ab_0 --> 2023.7.22-pyhd8ed1ab_0
numpy 1.24.3-py311h64a7726_0 --> 1.25.1-py311h64a7726_0
openssl 3.1.0-hd590300_3 --> 3.1.1-hd590300_1
...
Proceed ([y]/n)?

Si aceptamos las dependencias se realizará la instalación y veremos un mensaje de finalización exitoso similar a:

Preparing transaction: done
Verifying transaction: done
Executing transaction: done

= Uso de entornos conda con scripts Sbatch =

Ya hemos creado nuestros entornos virtuales, como también hemos instalado el software que vamos a necesitar.

Ahora necesitamos ejecutar nuestras simulaciones en los nodos de cómputo, y para esto debemos indicar en nuestro script SBatch las siguientes instrucciones luego de haber realizado una reserva de recursos:

eval "$(conda shell.bash hook)"
conda activate mi_primer_entorno

De esa manera será posible crear un script que se verá similar a:

#!/bin/bash
#SBATCH -J conda_test
#SBATCH -p main
#SBATCH -n 1
#SBATCH -c 1
#SBATCH --mem-per-cpu=2300
#SBATCH --mail-user=foo@example.com
#SBATCH --mail-type=ALL
#SBATCH -o conda_test_%j.out
eval "$(conda shell.bash hook)"
conda activate mi_primer_entorno
... mis comandos...

= Eliminación de Conda y entornos virtuales =

== Eliminación de Entornos ==

Puede listar sus entornos virtuales con el comando:

conda env list

Y en el caso de querer eliminar un entorno virtual puede ejecutar indicando el nombre de entorno:

conda-env remove -n mi_primer_entorno

También puede eliminar '''todos los entornos''' borrando la carpeta contenedora:

rm -rf ~/.conda

== Eliminación de Conda y del entorno ==

Para eliminar el uso de Conda de nuestro archivo debemos editar nuestro archivo <code>~/.bashrc</code> y '''eliminar''' el contenido similar a:

# >>> conda initialize >>>
# !! Contents within this block are managed by 'conda init' !!
__conda_setup="$('/home/lmod/software/Miniconda3/4.9.2/bin/conda' 'shell.bash' 'hook' 2> /dev/null)"
if [ $? -eq 0 ]; then
eval "$__conda_setup"
else
if [ -f "/home/lmod/software/Miniconda3/4.9.2/etc/profile.d/conda.sh" ]; then
. "/home/lmod/software/Miniconda3/4.9.2/etc/profile.d/conda.sh"
else
export PATH="/home/lmod/software/Miniconda3/4.9.2/bin:$PATH"
fi
fi
unset __conda_setup
# <<< conda initialize <<<

Se debe guardar los cambios y salir de la sesión.

La próxima vez que se acceda a nuestra cuenta, ya no estará disponible para su uso.

Si se requiere volver a utilizar Conda, será necesario inicializar nuevamente nuestro entorno.

= Buenas prácticas =

En los ejemplos vistos, tenemos dos entornos virtuales: <code>mi_primer_entorno</code> y <code>mi_entorno_con_python</code>.

Pero estos nombres no nos dicen mucho.

Debe recordar que cada entorno virtual puede contener distintas colecciones de software, por lo que es una buena práctica que el nombre del entorno virtual sea descriptivo para su uso.

De esta manera, se mostrará las dependencias necesarias y deberá aceptar la instalación.

Si desea instalar y aceptar todas las dependencias de manera automática puede ejecutar:

conda install -y Tensorflow

También es necesario mencionar que debe cuidar al cargar otros módulos, ya que pueden generar conflictos con versiones de software disponibles en el cluster en comparación a los que un entorno virtual les pueda ofrecer.

Por ejemplo, si cargamos un módulo de Python y verificamos la ubicación del interprete de Python veremos lo siguiente:

[dbowman@leftraru1 ~]$ ml Python
[dbowman@leftraru1 ~]$ which python
/home/lmod/software/Python/3.9.5-intel-2019b/bin/python
[dbowman@leftraru1 ~]$ conda activate mi_entorno_con_python
[dbowman@leftraru1 ~]$ which python
~/.conda/envs/mi_entorno_con_python/bin/python
[dbowman@leftraru1 ~]$ ml Python
[dbowman@leftraru1 ~]$ which python
/home/lmod/software/Python/3.9.5-intel-2019b/bin/python

En el ejemplo anterior vemos que se carga el módulo de Python <code>Python/3.9.5</code> y el interprete corresponde a <code> /home/lmod/software/Python/3.9.5-intel-2019b/bin/python</code>.

Posterior a eso se activa el entorno virtual <code>mi_entorno_con_python</code> y el interprete corresponde a <code>~/.conda/envs/mi_entorno_con_python/bin/python</code>.

Nuevamente cargamos el módulo de Python <code>Python/3.9.5</code> y el interprete corresponde a <code> /home/lmod/software/Python/3.9.5-intel-2019b/bin/python</code>. Y aunque nuestro entorno sigue activo, al momento de utilizar el comando <code>python</code> puede que estemos utilizando otro.

= Más información =

Le invitamos a visitar https://anaconda.org/ donde encontrará más información como software disponible para instalar.

También lo invitamos a escribirnos a soporte@nlhpc.cl si necesita soporte.

= Enlaces de interés =

* Uso de [https://wiki.nlhpc.cl/Jupyter_bajo_Conda Jupyter] bajo conda
* Como solicitar soporte creando un [https://wiki.nlhpc.cl/Como_abrir_un_ticket ticket]
* Uso del gestor de tareas [https://wiki.nlhpc.cl/SISTEMA_GESTOR_DE_RECURSOS SLURM]

Uso de SWAN

2024-04-29T21:44:39Z

Jmorales: /* Ejecución de SWAN en nodo de cómputo con 20 CPU asignadas */

== Introducción ==

En la presente wiki se indican algunas recomendaciones para el uso de SWAN en la infraestructura del NLHPC.

Algunas consideraciones que cada usuario debe tener en consideración son los nombres de archivo de entrada y salida que cada uno debe tener.

== Cargando SWAN ==

Para la carga de SWAN, ejecutaremos lo siguiente:\

ml purge
ml intel
ml SWAN/41.31-omp

Una vez se tengan estos módulos cargados, se tendrá acceso al ejecutable

swan.exe

== Archivos necesarios y preparación inicial ==

El usuario debe proveer los siguientes archivos:

* Archivo de entrada, usualmente llamado '''input.swn'''
* Otros archivos de entradas indicados en el archivo '''input.swn'''

La aplicación '''swan.exe''' buscará un archivo llamado '''INPUT''' por lo que será necesario renombrar nuestro archivo de entrada ejecutando:

cp input.swn INPUT

=== Ejemplo de archivo de entrada ===

$*************************HEADING************************
$ SWAN Canal
PROJ 'example' '01'
SET NAUTICAL
NUMERIC ACCUR 0.02 0.02 0.02 98. STAT 20 0.01
$********************MODEL INPUT*************************
MODE STAT TWOD
COORDINATES CART
CGRID REG 555380 4936200 0 20860 21630 298 309 CIRCLE 90 0.125 1
INPGRID BOTTOM 555380 4936200 0 298 309 70 70
READINP BOTTOM 1 'extra_input_file.dep' 3 0 FREE
WIND 2 320
$BOUND SEG IJ 298 308 0 308 0 308 0 0 0 0 298 0 UNIF PAR 2.7 14 230
$*********************CALCULATION************************
BREAKING CONSTANT 1.0 0.78
QUAD
WCAP
$TRIad
GEN3 KOMen
DIFFRAC 0
$*********************MODEL OUTPUT************************
$NGRid 'example' 244000 6340900 0 21450 13100 429 262
POINTS 'point_example' 571235.51 4945437.89
BLOCK 'COMPGRID' NOHEAD 'output_file.mat' LAY 3 XP YP DEPTH HSIG TPS DIR PDIR TM01 WIND GENERAT RTP
TABLE 'point_example' HEAD 'output_file.tab' XP YP DEPTH HSIG TPS DIR PDIR TM01 TMM10
SPECout 'point_example' 'output_file.spc'
$*******************CALCULATIONS**************************
COMP STAT
STOP

El archivo consta de las siguientes secciones:

* Cabezera
* Entrada del modelo
** Aquí se indica el archivo adicional de ejemplo llamado '''extra_input_file.dep'''
* Sección de cálculos a realizar
* Salida del modelo
*** Aquí se generan los archivos de salida '''output_file.mat''', '''output_file.tab''' y '''output_file.spc'''
* Sección de estadísticas finales

Recuerde que estas secciones pueden variar según el uso que cada usuario pueda utilizar.

== Ejecución de SWAN en nodo de cómputo con 20 CPU asignadas ==

''Antes de continuar, recuerde que el archivo de entrada a utilizar debe llamarse '''INPUT'''.''

Para la ejecución de SWAN editaremos el script '''run_swan.job''' con el siguiente contenido:

#!/bin/bash
#SBATCH -J swan_job
#SBATCH -p main
#SBATCH -n 20
#SBATCH -c 1
#SBATCH --ntasks-per-node=20
#SBATCH --mem-per-cpu=2300
#SBATCH --mail-user=foo@example.com
#SBATCH --mail-type=ALL
#SBATCH -o swan_job_%j.out
#SBATCH -e swan_job_%j.err
ml purge
ml intel
ml SWAN/41.31-omp
srun swan.exe

Y lo ejecutaremos con:

sbatch run_swan.job

Este script generará los siguientes archivos de salida:

* swan_job_%j.out: archivo de salida con información de la tarea SLURM
* swan_job_%j.err: archivo de errores y alertas con información de la tarea SLURM
* PRINT: archivo de salida de la simulación de SWAN
* Errfile: archivo de error de la simulación de SWAN
* norm_end: archivo de finalización de la simulación de SWAN
* otros archivos de salida indicados en el archivo de entrada utilizado (ver archivo '''INPUT''')

En el caso de que vuelva a lanzar esta simulación en la misma ubicación, los archivos '''PRINT''', '''Errfile''' y otros archivos de salida usados por SWAN serán sobrescritos, por lo que se recomienda tomar medidas para evitar la pérdida de datos.

== Enlaces de interés ==

* Página oficial de SWAN [https://swanmodel.sourceforge.io/ aquí]
* Manual de usuario de SWAN [https://swanmodel.sourceforge.io/online_doc/swanuse/swanuse.html aquí]

Para generar scripts y asignar recursos le recomendamos utilizar nuestro [https://wiki.nlhpc.cl/Generador_Scripts Generador de Scripts].

QuantumESPRESSO

2024-04-29T21:43:51Z

Jmorales: /* Modulos */

== ¿Qué es? ==
Quantum ESPRESSO es un software opensource para simulaciones químicas.

== Modulos ==
Se encuentra disponible en general:
=== [https://wiki.nlhpc.cl/Lmod Lmod] ===
* QuantumESPRESSO/5.1.2-stress_hub_fix
* QuantumESPRESSO/5.1.2
* QuantumESPRESSO/5.4.0-hybrid
* QuantumESPRESSO/6.0
* QuantumESPRESSO/6.1
* QuantumESPRESSO/6.2.1

== Ejemplo de Lanzador ==
Ejemplo de SBATCH para enviar al cluster en la partición '''general''':
<pre>
#!/bin/bash
#SBATCH -J ejemplo
#SBATCH -p general
#SBATCH -n 88
#SBATCH --ntasks-per-node=44
#SBATCH --mem-per-cpu=4363
#SBATCH --mail-user=usuario@correo.cl
#SBATCH --mail-type=ALL
#SBATCH --o ejemplo_%j.out
#SBATCH --e ejemplo_%j.err

module purge
module load Lmod/6.5
source $LMOD_PROFILE
ml intel/2017a QuantumESPRESSO/6.2.1

srun pw.x < inp > out
</pre>

== Referencias ==
[https://www.quantum-espresso.org/ Quantum ESPRESSO]

Cancelación de Tareas

2024-04-29T21:43:15Z

Jmorales: /* Por uso de Memoria */

== Por uso de CPU ==
Procederemos a cancelar la tarea en el caso de que la mitad del total de cores reservados muestre un porcentaje de uso menor o igual a un '''30%''' en un lapso de '''4 horas'''.

== Por uso de Memoria ==
En el caso de que la memoria reservada por core en los nodos main sea mayor a '''1000MB''', se activa el proceso de verificación del uso de memoria RAM para su tarea para garantizar al menos '''70%''' de uso correcto de todo el recurso reservado. Esta condición será revisada desde el inicio de la tarea y si no alcanza el mencionado límite, la tarea será cancelada de forma automática.

Cabe destacar que si su tarea necesita reservar '''2300MB''' por core, usted debe hacer uso de la memoria RAM asignada por cada CPU.

Por lo anterior, el siguiente ejemplo muestra el uso de 1 proceso con 1 CPU con 2300M de RAM asignada.
<pre>
#SBATCH -p main
#SBATCH -n 1
#SBATCH -c 1
#SBATCH --mem-per-cpu=2300
</pre>

Puede visitar nuestro [https://wiki.nlhpc.cl/Generador_Scripts Generador de Scripts]

== Ejemplo ==
En el siguiente caso se hace una reserva de 11 cores y 48G de memoria:

[[Archivo:Cpu_subutilizacion.png|no]]

Se puede observar que el uso efectivo es de solo 1 core a la vez.

[[Archivo:Memoria subutilizacion.png|no]]

Además, SLURM asignó por core al menos (48000/11) 4300M de memoria, cuando el uso de la tarea solo fue de 5M (los valores del gráfico se presentan en bytes).

== Referencias ==
* [https://slurm.schedmd.com/sbatch.html man sbatch]
* [https://wiki.nlhpc.cl/Monitoreo Monitoreo De Tareas]

Jupyter bajo Conda

2024-04-29T21:42:37Z

Jmorales: /* Lanzando tareas de Jupyter en los nodos de cómputo */

= Introducción =

El siguiente procedimiento le permitirá instalar Jupyter Notebook en un entorno Conda, para eventualmente acceder desde su computadora local y utilizarlo.

Recomendamos la lectura de la página de la Wiki sobre Conda en el siguiente [https://wiki.nlhpc.cl/Uso_de_conda enlace] donde aprenderá a utilizar los módulos necesarios, crear entornos virtuales e instalar software.

= Creación de entorno virtual de Conda e instalación de Jupyter =

Crearemos un entorno virtual y posterior a eso instalaremos Jupyter de la siguiente manera:

[dbowman@leftraru1 ~]$ conda create -n mi_entorno_con_jupyter
Collecting package metadata (current_repodata.json): done
Solving environment: done
## Package Plan ##
environment location: /home/eosorio/.conda/envs/mi_entorno_con_jupyter
Proceed ([y]/n)?
Preparing transaction: done
Verifying transaction: done
Executing transaction: done

Luego activaremos nuestro entorno virtual con:

[dbowman@leftraru1 ~]$ conda activate mi_entorno_con_jupyter

E instalaremos jupyter ejecutando:

[dbowman@leftraru1 ~]$ conda install -y jupyter

Si todo resulta de manera exitosa veremos un resultado similar a:

Downloading and Extracting Packages
jsonpointer-2.0 | 9 KB | ######################################### | 100%
jedi-0.19.0 | 825 KB | ######################################### | 100%
webcolors-1.13 | 18 KB | ######################################### | 100%
isoduration-20.11.0 | 17 KB | ######################################### | 100%
jupyterlab_server-2. | 59 KB | ######################################### | 100%
async-lru-2.0.4 | 15 KB | ######################################### | 100%
uri-template-1.3.0 | 23 KB | ######################################### | 100%
ipywidgets-8.1.0 | 111 KB | ######################################### | 100%
fqdn-1.5.1 | 14 KB | ######################################### | 100%
arrow-1.2.3 | 92 KB | ######################################### | 100%
sip-6.7.11 | 569 KB | ######################################### | 100%
openssl-3.1.2 | 2.5 MB | ######################################### | 100%
jsonschema-with-form | 7 KB | ######################################### | 100%
jupyter_events-0.7.0 | 21 KB | ######################################### | 100%
notebook-7.0.1 | 3.1 MB | ######################################### | 100%
Preparing transaction: done
Verifying transaction: done
Executing transaction: done

= Ejecución de Jupyter =

A continuación deberemos realizar dos pasos:

# Identificar el nodo en el que nos encontramos
# Ejecutar jupyter

== Identificación de nodo en el que nos encontremos ==

Para identificar el nodo en el que nos encontremos ejecutaremos:

[dbowman@leftraru1 ~]$ hostname
leftraru2

La respuesta será uno de los nodos de acceso correspondientes a leftraru1, 2, 3 o 4.

En nuestro ejemplo obtuvimos <code>leftraru2</code>, dato que utilizaremos prontamente.

== Ejecutar Jupyter ==

En este paso ejecutaremos Jupyter indicando un puerto específico para posteriormente poder conectarnos desde nuestra computadora local.

El comando a utilizar es:

[dbowman@leftraru1 ~]$ jupyter-notebook --no-browser --port 2346

Obtendremos mucha información, pero nos deberemos fijar en la información similar a:

[C 2023-08-02 17:09:07.819 ServerApp]
To access the server, open this file in a browser:
file:///home/dbowman/.local/share/jupyter/runtime/jpserver-60187-open.html
Or copy and paste one of these URLs:
http://localhost:2346/tree?token=918029e46e54957ac797882f1
http://127.0.0.1:2346/tree?token=918029e46e54957ac797882f1

Deberemos tener en cuenta la información <code>http://localhost:2346/tree?token=918029e46e54957ac797882f1</code> para nuestros próximos pasos.

= Accediendo a Jupyter desde nuestra computadora local =

Los siguientes pasos son realizados en una terminal '''desde''' nuestra computadora local.

Los datos que necesitaremos son:

* Nombre de host en donde ejecutamos los pasos anteriores
* URL de acceso al ejecutar Jupyter en el cluster

Estos datos fueron obtenidos desde la sección anterior, lo que nos permitirá:

# Crear un túnel de acceso
# Acceder a Jupyter

== Creación de túnel de acceso ==

En pasos previos obtuvimos que el nombre de host <code>leftraru2</code>, con lo que podremos ejecutar desde nuestra computadora local un túnel SSH de la siguiente manera:

[david@HAL ~]$ ssh -NL 2346:localhost:2346 -l dbowman leftraru2.nlhpc.cl

Se le solicitará su contraseña del cluster y si la autenticación es exitosa, se creará un túnel desde nuestra computadora al cluster bajo nuestro usuario y el host donde hemos estado trabajando.

En el caso de haber obtenido otro nombre de host, por ejemplo <code>leftraru4</code>, deberemos indicar dicho nombre de host en el comando ejecutado.

== Accediendo a Jupyter ==

Una vez que hemos lanzado el túnel, deberemos acceder mediante nuestro navegador preferido a la URL obtenida previamente.

En nuestro caso bastará abrir: '''<code>http://localhost:2346/tree?token=918029e46e54957ac797882f1</code>'''

Y ya podrá acceder a utilizar Jupyter desde su navegador.

= Lanzando tareas de Jupyter en los nodos de cómputo =

Debemos tener en consideración que el uso de Jupyter suele realizarse mayormente de manera interactiva, lo que requerirá los cuatro pasos anteriores que hemos realizado:

# Identificación de host en el cluster
# Ejecutar Jupyter y tomar nota de URL de acceso
# Crear túnel SSH desde nuestra computadora al cluster
# Acceder a Jupyter

También es importante notar que estamos usando un entorno virtual, por lo que para ejecutar deberemos considerar lo siguiente:

* Reservar recursos
* Activar entorno de conda utilizado
* Lanzar tarea a los nodos de cómputo
** Esta tarea se ejecutará pero no podrá ser utilizada de manera interactiva

Entonces, si queremos lanzar nuestro archivo <code>HolaJupyter.ipynb</code> creado en nuestro '''notebook''', podremos crear un script similar a:

#!/bin/bash
#---------------Script SBATCH - NLHPC ----------------
#SBATCH -J jupyter-desde-sbatch
#SBATCH -p main
#SBATCH -n 1
#SBATCH -c 1
#SBATCH --mem-per-cpu=2300
#SBATCH --mail-user=dbowman@hal.com
#SBATCH --mail-type=ALL
#SBATCH -o jupyter-desde-sbatch_%j.out
source /home/dbowman/.bashrc
eval "$(/home/lmod/software/Core/Miniconda3/4.5.12/bin/conda shell.bash hook)"
conda activate mi_entorno_con_jupyter
jupyter nbconvert --to notebook --execute HolaJupyter.ipynb --output=jupyter-output.ipynb

Esto nos entregará información en el archivo de salida de la tarea <code>jupyter-desde-sbatch_234234.out</code> similar a:
[NbConvertApp] Converting notebook HolaJupyter.ipynb to notebook
0.00s - Debugger warning: It seems that frozen modules are being used, which may
0.00s - make the debugger miss breakpoints. Please pass -Xfrozen_modules=off
0.00s - to python to disable frozen modules.
0.00s - Note: Debugging will proceed. Set PYDEVD_DISABLE_FILE_VALIDATION=1 to disable this validation.
0.00s - Debugger warning: It seems that frozen modules are being used, which may
0.00s - make the debugger miss breakpoints. Please pass -Xfrozen_modules=off
0.00s - to python to disable frozen modules.
0.00s - Note: Debugging will proceed. Set PYDEVD_DISABLE_FILE_VALIDATION=1 to disable this validation.
[NbConvertApp] Writing 1187 bytes to jupyter-output.ipynb

Y el archivo de salida llamado <code>jupyter-output.ipynb</code> tendrá un contenido similar a:

{
"cells": [
{
"cell_type": "code",
"execution_count": 1,
"id": "7832632e-7aeb-48d5-97f5-4aed8644fb0b",
"metadata": {
"execution": {
"iopub.execute_input": "2023-08-02T22:06:21.689494Z",
"iopub.status.busy": "2023-08-02T22:06:21.689137Z",
"iopub.status.idle": "2023-08-02T22:06:21.701830Z",
"shell.execute_reply": "2023-08-02T22:06:21.700906Z"
}
},
"outputs": [
{
"name": "stdout",
"output_type": "stream",
"text": [
"Hola Jupyter!\n"
]
}
],
"source": [
"print(\"Hola Jupyter!\")"
]
},
...
}

= Conclusión =

El uso de Jupyter puede resultar de gran ayuda, y en conjunto con la potencia de los nodos de cómputo se transforma en una herramienta útil y flexible.

Se tiene una curva de aprendizaje inicial poco sencilla al requerir de varios pasos, pero una vez dominado, podrá repetir sus pasos una y otra vez según sus requerimientos.

= Más información =

Puede leer sobre Conda en el siguiente [https://wiki.nlhpc.cl/Uso_de_conda enlace].

Puede leer sobre Jupyter en la página web oficial en el siguiente [https://docs.jupyter.org/en/latest/ enlace].

Ejemplo WRF

2024-04-29T21:41:43Z

Jmorales: /* Realizar un Script de ejecución de WRF, de tal manera que se pueda enviar esta tarea al gestor SLURM para su procesamiento */

== Ejecución de WRF mediante el uso de módulos==
Este documento tiene por objetivo guiar a los usuario del [https://www.nlhpc.cl/ Laboratorio Nacional de Supercomputación NLHPC] en en el proceso de ejecución de una simulación del modelo '''WRF''' mediante la cargar los módulos disponibles en nuestro [https://wiki.nlhpc.cl/Lmod Gestor de Módulos LMOD].

Los pasos necesarios para realizar una simulación son los siguientes:

== Realizar la carga de módulos correspondiente a la versión de WRF/WPS deseada por el usuario ==
En este paso, el usuario podrá buscar mediante el [https://wiki.nlhpc.cl/Lmod Gestor de Módulos LMOD] las versiones de '''WRF''' y '''WPS''' disponibles, considerando que para una correcta ejecución de una simulación las versiones de WRF y WPS deben ser lo mas parecidas posibles.

Para realizar la búsqueda de módulos, el usuario deberá ejecutar los comandos <code>ml spider WRF</code> y <code>ml spider WPS</code>. Lo que mostrará la siguiente información

<pre>
(base) [usuario@leftraru1 run]$ ml spider WRF

-------------------------------------------------------------------------------------------------------------------
WRF:
-------------------------------------------------------------------------------------------------------------------
Description:
The Weather Research and Forecasting (WRF) Model is a next-generation mesoscale numerical weather prediction system designed to serve both operational
forecasting and atmospheric research needs.

Versions:
WRF/3.7.1-dm+sm-polar
WRF/3.7.1-dm+sm
WRF/3.9.1-dm+sm+chem
WRF/3.9.1-dm+sm-polar
WRF/3.9.1-dmpar+chem
WRF/4.0.3-dm+sm
WRF/4.1-dm+sm
WRF/4.1.2-dm+sm+oasis
WRF/4.1.2-dm+sm
WRF/4.1.3-dmpar
WRF/4.1.5-dm+sm
WRF/4.1.5-dmpar
WRF/4.2.1-dmpar+xios+oasis
WRF/4.2.2-dm+sm+chem
WRF/4.2.2-dm+sm
WRF/4.2.2-dmpar+chem
WRF/4.3-dmpar
WRF/4.3.1-dmpar+da
WRF/4.3.2-dm+sm+chem
WRF/4.3.2-dm+sm
WRF/4.3.2-dmpar+chem
WRF/4.3.2-dmpar
WRF/4.3.3-dmpar
WRF/4.4-dm+sm+chem+kpp
WRF/4.4-dm+sm+chem
WRF/4.4-dmpar+chem
WRF/4.4-dmpar
Other possible modules matches:
CALWRF WRFDA WRFPLUS

-------------------------------------------------------------------------------------------------------------------
To find other possible module matches execute:

$ module -r spider '.*WRF.*'

-------------------------------------------------------------------------------------------------------------------
For detailed information about a specific "WRF" module (including how to load the modules) use the module's full name.
For example:

$ module spider WRF/4.3.3-dmpar
-------------------------------------------------------------------------------------------------------------------
</pre>

Mismo procedimiento para el caso de '''WPS'''

<pre>
(base) [usuario@leftraru1 run]$ ml spider WPS

-------------------------------------------------------------------------------------------------------------------
WPS:
-------------------------------------------------------------------------------------------------------------------
Description:
WRF Preprocessing System (WPS) for WRF. The Weather Research and Forecasting (WRF) Model is a next-generation mesoscale numerical weather prediction system
designed to serve both operational forecasting and atmospheric research needs.

Versions:
WPS/3.7.1-dmpar
WPS/4.0.3-dmpar
WPS/4.1-dmpar
WPS/4.2-dmpar
WPS/4.3.1-dmpar

-------------------------------------------------------------------------------------------------------------------
For detailed information about a specific "WPS" module (including how to load the modules) use the module's full name.
For example:

$ module spider WPS/4.3.1-dmpar
-------------------------------------------------------------------------------------------------------------------

</pre>

Ahora bien, una vez elegidos los módulos indicados, se procede a su carga en el sistema

<pre>
ml WRF/4.1.3-dmpar
ml WPS/4.2-dmpar
</pre>

== Crear un directorio de trabajo para alojar la versión de WRF/WPS cargados previamente. ==

<pre>
cd ~
mkdir TEST_WRF
cp -rv /home/lmod/software/WRF/4.1.3-intel-2019b-dmpar/WRF-4.1.3 ~/TEST_WRF
cp -rv /home/lmod/software/WPS/4.2-intel-2019b-dmpar/WPS-4.2 ~/TEST_WRF
</pre>

== Descargar y descomprimir el archivo WPS_GEOG ==
<pre>
cd ~/TEST_WRF/WPS-4.2
wget https://www2.mmm.ucar.edu/wrf/src/wps_files/geog_high_res_mandatory.tar.gz
tar -xvzf geog_high_res_mandatory.tar.gz
</pre>

== Editar el archivo namelist.wps, de manera que pueda linkear apropiadamente los datos de geografía ==

<pre>
&share
wrf_core = 'ARW',
max_dom = 1,
start_date = '2021-01-30_12:00:00','2021-01-30_12:00:00',
end_date = '2021-01-30_18:00:00','2021-01-30_21:00:00',
interval_seconds = 10800
/

&geogrid
parent_id = 1, 1,
parent_grid_ratio = 1, 3,
i_parent_start = 1, 53,
j_parent_start = 1, 25,
e_we = 150, 220,
e_sn = 130, 214,
geog_data_res = 'default','default',
dx = 27000,
dy = 27000,
map_proj = 'lambert',
ref_lat = -33.00,
ref_lon = -80.00,
truelat1 = -32.0,
truelat2 = -34.0,
stand_lon = -71.0,
geog_data_path = './WPS_GEOG/'
/

&ungrib
out_format = 'WPS',
prefix = 'FILE',
/

&metgrid
fg_name = 'FILE'
/
</pre>

O bien puede descargarlo directamente para continuar con el ejercicio:

<pre>
wget https://raw.githubusercontent.com/nlhpc-training/Tutorial-WRF/main/namelist.wps
</pre>

En este ejemplo se ha descargado la data geog mandatoria, pero existe data opcional en caso de ser necesaria.

'''WPS_GEOG''' se descargó en <code>/home/nombre_usuario/TEST_WRF/WPS-4.2</code> pero cada usuario puede descargarla donde desee. Y como se puede apreciar, la ruta <code>geog_data_path</code> es la que debe apuntar a esta carpeta.

== Enlazar simbólicamente la Vtable a utilizar, el cual debe quedar en la ruta donde está el preprocesador WPS ==

<pre>
cd ~/TEST_WRF/WPS-4.2
ln -s ungrib/Variable_Tables/Vtable.GFS Vtable
</pre>

== Ejecutar el comando geogrid.exe, el cual nos permitirá generar nuestro dominio. ==

<pre>
srun geogrid.exe
</pre>

== Descargar datos de CI y CB para realizar el preproceso de datos ==

En este caso, clonaremos desde el [https://github.com/nlhpc-training git NLHPC] los datos de prueba, los cuales nos permitirán ejecutar los procesos de '''ungrib.exe''' y '''metgrid.exe''' respectivamente. En este proceso, copiaremos los datos y desde la carpeta de '''WPS''' realizaremos el proceso de linkeo a dichos datos mediante el <code>script link_grib.csh</code>. Finalmente ejecutaremos <code>ungrib.exe</code> y <code>metgrid.exe</code>

<pre>
cd ~/TEST_WRF/
mkdir CI_CB
cd CI_CB
wget https://github.com/nlhpc-training/Tutorial-WRF/raw/main/fnl_20210130_12_00.grib2
wget https://github.com/nlhpc-training/Tutorial-WRF/raw/main/fnl_20210130_18_00.grib2
cd ~/TEST_WRF/WPS-4.2/
./link_grib.csh ~/TEST_WRF/CI_CB/fnl*
srun ungrib.exe
srun metgrid.exe
</pre>

En este ejemplo se ha ejecutado interactivamente el preproceso de datos ya que el dominio y la data han sido pensados para un ejercicio de poca duración.
Ahora bien, en el caso de que el usuario deba preprocesar información de largo aliento, se recomienda crear un script y lanzarlo mediante sbatch. (Para mayor información, véase apartado de [https://wiki.nlhpc.cl/SISTEMA_GESTOR_DE_RECURSOS#Ejecutando_trabajos ejecución de trabajos])

== Crear el archivo de configuración namelist.input según lo requerido ==

Para este caso, ingresamos a la carpeta '''run''' de '''WRF''' y editaremos el archivo <code>namelist.input</code>

<pre>
cd ~/TEST_WRF/WRF-4.1.3/run/
vi namelist.input
</pre>

De manera tal que quede como el siguiente.

<pre>
&time_control
run_days = 0,
run_hours = 6,
run_minutes = 0,
run_seconds = 0,
start_year = 2021, 2021,
start_month = 01, 01,
start_day = 30, 29,
start_hour = 12, 00,
end_year = 2021, 2021,
end_month = 01, 02,
end_day = 30, 01,
end_hour = 18, 00,
interval_seconds = 10800
input_from_file = .true.,.true.,
history_interval = 60, 60,
frames_per_outfile = 1, 1,
restart = .false.,
restart_interval = 7200,
io_form_history = 2
io_form_restart = 2
io_form_input = 2
io_form_boundary = 2
/

&domains
time_step = 60,
time_step_fract_num = 0,
time_step_fract_den = 1,
max_dom = 1,
e_we = 150, 220,
e_sn = 130, 214,
e_vert = 45, 45,
dzstretch_s = 1.1
p_top_requested = 5000,
num_metgrid_levels = 34,
num_metgrid_soil_levels = 4,
dx = 27000,
dy = 27000,
grid_id = 1, 2,
parent_id = 0, 1,
i_parent_start = 1, 53,
j_parent_start = 1, 25,
parent_grid_ratio = 1, 3,
parent_time_step_ratio = 1, 3,
feedback = 1,
smooth_option = 0
/

&physics
physics_suite = 'CONUS'
mp_physics = -1, -1,
cu_physics = -1, -1,
ra_lw_physics = -1, -1,
ra_sw_physics = -1, -1,
bl_pbl_physics = -1, -1,
sf_sfclay_physics = -1, -1,
sf_surface_physics = -1, -1,
radt = 15, 15,
bldt = 0, 0,
cudt = 0, 0,
icloud = 1,
num_land_cat = 21,
sf_urban_physics = 0, 0,
fractional_seaice = 1,
/

&fdda
/

&dynamics
hybrid_opt = 2,
w_damping = 0,
diff_opt = 2, 2,
km_opt = 4, 4,
diff_6th_opt = 0, 0,
diff_6th_factor = 0.12, 0.12,
base_temp = 290.
damp_opt = 3,
zdamp = 5000., 5000.,
dampcoef = 0.2, 0.2,
khdif = 0, 0,
kvdif = 0, 0,
non_hydrostatic = .true., .true.,
moist_adv_opt = 1, 1,
/ scalar_adv_opt = 1, 1,
/ gwd_opt = 1, 0,
/

&bdy_control
spec_bdy_width = 5,
specified = .true.
/

&grib2
/

&diags
diag_nwp2 = 1
/

&namelist_quilt
nio_tasks_per_group = 0,
nio_groups = 1,
/
</pre>

O bien, puede descargarlo directamente para continuar con el ejercicio:

<pre>
wget https://raw.githubusercontent.com/nlhpc-training/Tutorial-WRF/main/namelist.input
</pre>

== Ejecución de real.exe ==

En este punto, debemos linkear los datos '''''met_em''''' resultantes del proceso <code>metgrid.exe</code> y posteriormente ejecutar el comando <code>real.exe</code>.

<pre>
cd ~/TEST_WRF/WRF-4.1.3/run/
ln -s ~/TEST_WRF/WPS-4.2/met_em.d01.2021-01-30_1* .
srun real.exe
</pre>

== Realizar un Script de ejecución de WRF, de tal manera que se pueda enviar esta tarea al gestor SLURM para su procesamiento ==

Creamos el archivo <code>lanza-wrf-sh</code> y lo editamos de la siguiente manera.

<pre>
#!/bin/bash
#---------------Script SBATCH - NLHPC ----------------
#SBATCH -J TestJob_wrf
#SBATCH -p main
#SBATCH -n 20
#SBATCH --ntasks-per-node=20
#SBATCH -c 1
#SBATCH --mem-per-cpu=2300
#SBATCH --mail-user=usuario@nlhpc.cl
#SBATCH --mail-type=ALL
#SBATCH -o asd_%j.out
#SBATCH -e asd_%j.err

#-----------------Toolchain---------------------------
ml purge
ml intel/2019b
# ----------------Modulos----------------------------
ml WPS/4.2-dmpar WRF/4.1.3-dmpar
# ----------------Comando--------------------------
cd ~/TEST_WRF/WRF-4.1.3/run/
time wrf.exe
</pre>

O bien, podemos descargarlo para continuar con el ejercicio.

<pre>
wget https://raw.githubusercontent.com/nlhpc-training/Tutorial-WRF/main/lanza-wrf.sh
</pre>

Finalmente ejecutamos este script mediante el comando sbatch

<pre>
sbatch lanza-wrf.sh
</pre>

== Enlaces de interés ==
University Corporation for Atmospheric Research UCAR: https://www.mmm.ucar.edu/<br>
National Oceanic and Atmospheric Administrarion NOAA: https://esrl.noaa.gov/gsd/wrfportal/<br>
NOAA (Tutoriales WRF): https://esrl.noaa.gov/gsd/wrfportal/html-tutorial.html<br>
NCEP Central Operations (Descarga de datos): https://www.nco.ncep.noaa.gov/pmb/products/gfs/<br>

Como abrir un ticket

2024-04-29T21:36:08Z

Jmorales: /* Otras fuentes de ayuda */

== Introducción ==
La intención del siguiente documento es la de indicar algunas buenas prácticas al momento de solicitar al equipo del NLHPC soporte con distintas situaciones que pueda enfrentar, con la intención de que se otorgue la información necesaria de su requerimiento para lograr una atención adecuada por parte de nuestro equipo de trabajo.

== A modo de resumen ==

Siempre considere lo siguiente a la hora de solicitar soporte:

* Indique un ''asunto'' o ''subject'' específico y claro
* Datos importantes a considerar en su mensaje
** Solicitud clara
*** Explicación de qué desea lograr
*** Mención de qué pasos ha seguido para obtener su resultado actual
** Sobre la ejecución de tareas
*** Indicar Job ID
*** Indicar script utilizado
*** Rutas de archivos de entradas y scripts
** Sobre la instalación de software
*** Indicar URL de página oficial
*** Versión requerida
*** Otorgar Licencia de ser requerida
* Tickets cerrados
** No contestar mensajes cerrados, a menos que su requerimiento no haya sido resuelto
** Abrir tickets nuevos, en vez de reabrir tickets antiguos

Si necesita soporte por temas distintos, agradecemos nos envíe correos independientes para poder hacer un seguimiento adecuado a cada una de sus solicitudes. Esto también nos permitirá asignar distintas tareas entre el personal de nuestro equipo.

== Qué es un ticket ==
''Un ticket es un correo que se envía a soporte@nlhpc.cl el que será atendido por nuestro personal.''

Un ticket es la representación de un requerimiento enviado por el usuario mediante un correo electrónico a una casilla de correo específica.

El ticket es recibido en un sistema que permite organizar por tipo de requerimiento, nivel de urgencia y eventual asignación al equipo de trabajo adecuado.

Mediante el sistema de gestión de tickets, se responderá a su requerimiento y nos pondremos en contacto con el solicitante.

A efectos prácticos, el usuario verá una respuesta de correo en su casilla, y si tiene comentarios u observaciones sobre el servicio otorgado, bastará que responda dicho correo.

=== Otras vías de comunicación ===

En el caso que se reciban requerimientos por medios no convencionales o informales, solicitaremos al usuario que debe enviar un mensaje a soporte@nlhpc.cl con su requerimiento para continuar con el procedimiento formal de creación de ticket, lo que permite la gestión correcta de los distintos requerimientos que recibimos.

== Qué información debe tener un ticket ==

=== Asunto o Subject ===
''Ser claro y específico en el requerimiento le permitirá tener una respuesta más precisa a su requerimiento.''

Cuando un usuario realiza una solicitud para obtener asistencia, debe considerar que a mayor cantidad de información útil que otorgue, más acertada y pronta será la respuesta que recibirá.

La primera información que se lee es el ''asunto'' o ''subject'' del correo electrónico, por lo que recomendamos que utilice un descriptor que englobe su solicitud.

Algunos buenos ejemplos de un buen ''asunto'':

* Problema de falta de memoria en Job ID 2504311
* Ejecución de tarea en partición SLIMS con entorno virtual de Python
* Cómo copiar archivos desde mi computadora al cluster
* Solicitud de instalación de software FOOBAR versión 1.2.3

Algunos malos ejemplos:

* Ayuda
* Error
* ''Asunto dejado vacío por el propio usuario''

=== Solicitud de instalación de software ===

''¿Ya ha buscado ejecutando <code>ml avail</code>?''

''Actualmente contamos con una gran cantidad de software disponible en el clúster.''

En el caso de requerir la instalación de un nuevo software, indicar:

* Nombre del software
* Versión o versiones requeridas
* URL oficial para la obtención del código fuente o página oficial
* Si se requiere licencia, el usuario debe otorgar la licencia para su uso

=== Solicitud de verificación de tarea ===

''Recuerde visitar nuestro [https://wiki.nlhpc.cl/Generador%20Scripts Generador de Scripts] como también nuestra [https://wiki.nlhpc.cl Wiki] para conocer cómo editar scripts y ejecutarlos de manera exitosa.''

Las tareas que los usuarios lanzan pueden presentar distintas situaciones, como subutilización de recursos, fallas de ejecución, problemas de módulos, asignaciones incorrectas y otras situaciones.

En el caso de requerir soporte con alguna tarea o información sobre cómo ejecutar tareas en el cluster, recomendamos indicar:

* Nombre del usuario que ejecuta la tarea
* Nombre del script que utiliza
* Ruta de la ubicación del script
* Software utilizado
* Si ha ejecutado ya su tarea
** Job ID de la tarea ejecutada si aplica
** Archivos de salida/error obtenidos si ha ejecutado su tarea
** Resultado obtenido
** Pasos seguidos para obtener el resultado actual
** Resultado esperado

=== Problemas de acceso al clúster ===

''Tenemos un vídeo tutorial de acceso vía SSH en nuestro [https://www.youtube.com/watch?v=TSUQpsttRio canal de youtube].''

Cuando ocurren problemas de acceso, lo principal es poder identificar:

* Usuario que se quiere conectar
* Software utilizado para conectarse
* IPv4 desde la cual se está conectado (puede consultarlo [https://miip.cl/ aquí])
* Error obtenido

Con lo anterior podremos descartar problemas de comunicación, credenciales y validez de la cuenta.

=== Otros requerimientos ===

Si tiene algún otro tipo de requerimiento, siempre considere indicar:

* Usuario utilizado
* Pasos seguidos para obtener el resultado actual
* Resultado esperado
* Aplicaciones usadas y versiones de las mismas
* Otros datos que considere útiles que puedan ayudar a dar una mejor respuesta

== Cierre de tickets ==

''Agradecemos no responda los tickets que indiquen que se han cerrado. En vez de eso, recuerde siempre enviar un nuevo correo.''

Una vez que se ha otorgado una respuesta que satisfaga el requerimiento del usuario, solicitaremos no contestar los correos enviados.

De esta manera, el ticket será cerrado.

Si es necesario, el usuario puede volver a enviar '''un nuevo correo''' lo que creará una nueva solicitud.

Esto último permitirá gestionar de mejor manera los requerimientos que se atienden, verificar las tareas en las que se invierte tiempo en nuestros usuarios, como también verificar los distintos temas que se abordan.

En el caso de que un requerimiento sea similar a uno anterior, también es una buena práctica enviar '''un nuevo correo''' para crear un nuevo ticket.

Si responde un ticket antiguo, esto nos impedirá gestionar de mejor manera las tareas como también el reporte de las mismas.

== Otras fuentes de ayuda ==

Disponemos, además de una [https://wiki.nlhpc.cl Wiki] en donde podrá leer información importante sobre características del clúster y su uso.

También realizamos cursos básicos, avanzados y específicos, los cuales se pueden ver en nuestra página de [https://www.nlhpc.cl/eventos eventos].

Y nuestro canal de [https://www.youtube.com/@nlhpc_chile YouTube] donde podrá ver cursos anteriores y tutoriales que nuestro equipo prepara con el fin de entregar las herramientas adecuadas para el uso del Cluster Guacolda-Leftraru Epu.

Tutorial de acceso a Leftraru via SSH

2024-04-29T19:15:18Z

Jmorales: /* Nodos Login */

== Accediendo desde un equipo Linux o Mac OSX ==
Para realizar una conexión desde un sistema GNU/Linux o MacOSX, use el comando SSH (ejemplo con usuario "prueba") e indicar el uso del puerto '''4603'''.

Por ejemplo, el usuario Dave Bowman (nombre de usuario ''dbowman'') accede al clúster ejecutando:
<pre>
$ ssh -p 4603 dbowman@leftraru.nlhpc.cl
dbowman@leftraru.nlhpc.cl password:

[...]

dbowman@leftraru2:~$
</pre>

=== Guardar información de la sesión ===

Es posible almacenar los datos de conexión bajo el archivo '''~/.ssh/config''', lo que nos otorgará un poco más de flexibilidad a la hora de conectarnos.

Por ejemplo, el usuario Dave Bowman edita el archivo mencionado con:

<pre>
vi ~/.ssh/config
</pre>

y agrega la siguiente información:

<pre>
Host leftraru
Hostname leftraru.nlhpc.cl
User dbwoman
Port 4603
UpdateHostKeys no
</pre>

El parámetro '''Host''' indica el valor '''leftraru''' como nombre de conexión. Este valor podrá ser utilizado directamente con el comando '''ssh'''.

El valor '''Hostname''' indica la dirección a la cual nos queremos conectar (puedes indicar una IP si así lo deseas).

Los parámetros '''User''' y '''Port''' ya los hemos visto.

Y por último el parámetro '''UpdateHostKeys''' indica si deberá aceptar o no los cambios de llaves en el servidor. Por seguridad se recomienda el valor '''no'''.

Una vez que se edito esta información, nuestro usuario podrá acceder al clúster con tan solo escribir el comando:

<pre>ssh leftraru</pre>

==== Es posible tener una gran cantidad de entradas en nuestro archivo .ssh/config ====

Un ejemplo del archivo de configuración con más cantidad de entradas sería similar a:

<pre>
Host leftraru
Hostname leftraru.nlhpc.cl
User dbwoman
Port 4603
UpdateHostKeys no

Host l1
Hostname leftraru1.nlhpc.cl
User dbwoman
Port 4603
UpdateHostKeys no

Host l2
Hostname leftraru2.nlhpc.cl
User dbwoman
Port 4603
UpdateHostKeys no

Host HAL
Hostname 127.0.0.1
User dbwoman
Port 9000
UpdateHostKeys no
...
</pre>

Con dicha configuración, el usuario podría acceder usando uno de los siguientes comandos:

<pre>
ssh l1
ssh l2
</pre>

== Accediendo desde un equipo Windows ==
Para conectar desde sistemas Windows, se recomienda usar Putty como cliente SSH.

Como vemos en el ejemplo se indican los campos:

* Hostname: dbowman@leftraru.nlhpc.cl
* Puerto: 4603

[[Archivo:Putty-dbowman-hostname.png|no]]

Y se realiza la conexión haciendo ''click'' en el botón inferior ''Open''.

Si la conexión es exitosa podremos ingresar el usuario y contraseña.

En este ejemplo, es el usuario Dave Bowman (dbowman) quien intenta conectarse al clúster.

[[Archivo:Putty-dbowman-user-ssh.png|no]]

Recuerda que al momento de ingresar tu contraseña, esta no será desplegada en pantalla.

=== Guardar nuestra sesión ===

Una vez que se ingresa los valores de '''Hostname''' y '''Puerto''', es posible almacenar dicha información indicando un nombre en el campo '''Saved Sessions''' y presionando el botón '''Save''.

La próxima vez que necesitemos acceder al cluster, bastará hacer doble ''click'' sobre la sesión que necesitemos abrir.

Por ejemplo en este caso es posible ver que las siguientes sesiones están almacenadas:

<gallery>
Archivo:Putty-saved-sessions.png
</gallery>

* Default
* L1
* L2
* Leftraru

== Acceso utilizando llaves (Recomendado) ==
La autenticación con clave pública es un método de seguridad alternativo a las contraseñas, mucho más difícil de hackear y, por lo tanto, más seguro. Este método de autenticación es recomendable usarlo para acceder a servidores.

La clave SSH consiste en la generación de un par de claves que proporcionan dos largas cadenas de caracteres, una pública y una privada. La clave pública se instala en cualquier servidor y luego se desbloquea mediante la conexión con un cliente SSH que hace uso de la clave privada. Si las dos claves coinciden, el servidor SSH permite el acceso sin necesidad de utilizar una contraseña. No obstante, para añadir una capa de seguridad adicional, siempre podemos aumentar la protección de la clave privada usando una contraseña.

Entonces nuestro usuario Dave Bowman creará una llave en su computadora personal para copiarla en el clúster siguiendo los pasos que se indican a continuación:

<pre>
[dave@HAL ~]$ ssh-keygen
</pre>

Tras ejecutar el comando obtendremos la siguiente respuesta:

<pre>
Generating public/private ed25519 key pair.
</pre>

Una vez ejecutada la instrucción para generar las claves, se nos pedirá que indiquemos la ruta en la que queremos almacenar la clave:

<pre>
Enter file in which to save the key (/home/dave/.ssh/id_rsa):
</pre>

Tras indicar la ruta en la que se almacenará la clave, lo siguiente que tendremos que hacer es indicar una contraseña (puede dejar vacío para acceso directo):

<pre>
Enter passphrase (empty for no passphrase):
</pre>

Finalmente debemos copiar nuestra llave pública al cluster:

<pre>
[dave@HAL ~] ssh-copy-id -p 4603 dbowman@leftraru.nlhpc.cl
Number of key(s) added: 1

Now try logging into the machine, with: "ssh -p '4603' 'dbowman@leftraru.nlhpc.cl'"
and check to make sure that only the key(s) you wanted were added.
</pre>

Ahora ya podremos conectarnos directamente con nuestras llaves:

<pre>
[dave@HAL ~] ssh -p 4603 dbowman@leftraru.nlhpc.cl
</pre>

== Cambiar contraseña ==
Para cambiar la contraseña de usuario, es necesario que esta cumpla con ciertos requisitos como por ejemplo:

* El mínimo de caracteres son 10.
* Debe ser alfanumérica.
* Tener 3 caracteres especiales (al menos 1 mayúscula – 1 minúscula y 1 número).

Para ejecutar esta acción, utilice el siguiente comando:
<pre>
[dbowman@leftraru1 ~]$ passwd

Changing password for user dbowman.
(current) LDAP Password: <- Ingrese su contraseña actual.

New password: ********* <- Ingrese su nueva contraseña.

Retype new password: Reingrese su nueva contraseña.

passwd: all authentication tokens updated successfully.
</pre>

Confirmación de cambio de clave exitoso, le recomendamos cerrar su sesión e ingresar nuevamente a nuestro sistema ingresando su nueva contraseña.

== Conexión a nodos actualmente utilizados ==
Algunas veces, por distintas circunstancias, sería deseable tener la posibilidad de ingresar al nodo donde se estén ejecutando nuestras tareas con tal de verificar su estado, comprobar ciertos valores, etc.

Pensado en la comodidad de los usuarios, se ha implementado un módulo del gestor que colas SLURM que permite esta funcionalidad. Por tanto, el login será permitido en todas aquellas máquinas donde actualmente exista un trabajo nuestro.

Por ejemplo; nuestra tarea de prueba 'tarea_test.sh' ha sido enviada a la cola y ha ingresado con el ID '3469576'. Slurm reservó el nodo 'cn053' para llevar a cabo la ejecución, por tanto el usuario tiene permitido el ingreso mediante ssh al nodo:

<pre>
leftraru$ sbatch tarea_test.sh
leftraru$ squeue

JOBID PARTITION NAME USER ST TIME NODES NODELIST(REASON)
3469576 general Prueba test R 1:57 1 sn007

leftraru$ ssh sn007
Last login: today 2016 from leftraru.nlhpc.cl
sn007$
</pre>

Tenga en cuenta que aún se mantiene la restricción de ingreso para el resto de los nodos:
<pre>
leftraru$ ssh sn001
Access denied: user test (uid=000) has no active jobs on this node.
leftraru$
</pre>

== Nodos Login ==
Aunque disponemos de 4 nodos para el acceso al clúster por parte de los usuarios, en general, hay que usar el nombre:

* leftraru.nlhpc.cl

A la hora de conectarse por SSH al clúster. Al acceder a esa dirección se consigue que los usuarios queden conectados aleatoriamente a los nodos login.

Pero si resultara necesario, se puede acceder a un nodo login específicamente usando su nombre a la hora de realizar la conexión SSH:

* leftraru1.nlhpc.cl
* leftraru2.nlhpc.cl

== Notas ==
Debido a que Leftraru balancea la carga de los nodos Login se debe evitar el uso de screen, ya que no se garantiza el acceso al mismo nodo que tenía la sesión screen abierta una vez que el usuario cierra su sesión.

Un usuario sólo podrá acceder por ssh a los nodos logins. En el caso de querer acceder a un nodo de cómputo, el usuario deberá tener al menos una tarea SLURM en ejecución en el nodo al cual necesite acceder, y deberá considerar que si dicha tarea finaliza, su sesión será cerrada del nodo.

'''Si falla muchas veces el intento de login por SSH o genera muchas conexiones, su IP podría ser bloqueada. Contacte por correo electrónico con Soporte indicando información relevante (más información [[Como_abrir_un_ticket#Problemas_de_acceso_al_clúster|aquí]]) si presenta problemas de conexión: ''' '''[mailto:soporte@nlhpc.cl soporte@nlhpc.cl]'''

SISTEMA GESTOR DE RECURSOS

2024-04-29T19:14:32Z

Jmorales: /* Estado de nodos */

== SLURM Workload Manager ==
Es un sistema de programación de trabajos y gestión de clústeres de código abierto, tolerante a fallas y altamente escalable para clústeres Linux grandes y pequeños.

Como administrador de carga de trabajo de clúster, Slurm tiene tres funciones clave. Primero, asigna acceso exclusivo y / o no exclusivo a los recursos (nodos de cómputo) a los usuarios durante un período de tiempo para que puedan realizar el trabajo. En segundo lugar, proporciona un marco para iniciar, ejecutar y monitorear el trabajo (normalmente un trabajo paralelo) en el conjunto de nodos asignados. Finalmente, arbitra la contención de recursos mediante la gestión de una cola de trabajo pendiente.

SLURM es el gestor de colas instalado en muchos de los súper computadores del [https://www.top500.org/ TOP500], y también en el clúster del NLHPC. Si Ud. quiere lanzar tareas dentro de Leftaru, debe hacerlo a través de Slurm.

== Conceptos clave ==
SLURM gestiona trabajos de usuario que tienen las siguientes características clave:

* Conjunto de recursos solicitados:
** Número de recursos informáticos: nodos (incluidas todas sus CPUs y núcleos) o CPUs (incluidos todos sus núcleos) o solo núcleos
** Cantidad de memoria: por nodo o por CPU (lógica)
** Tiempo necesario para que las tareas del usuario completen su trabajo
* Una partición de nodo solicitada (cola de trabajos)
* Un nivel de calidad de servicio (QoS) solicitado que otorga a los usuarios accesos específicos
* Una cuenta solicitada con recursos limitados

De manera predeterminada, los usuarios envían trabajos a una partición particular (marcada como tal para todos los usuarios) y bajo una cuenta particular (preestablecida por usuario).

== Particiones SLURM ==

<table class="wikitable" style="width: 60%;">
<tr>
<td><b>Nombre Particion</b></td>
<td><b>Nodos</b></td>
<td><b>CPUs</b></td>
<td><b>RAM</b></td>
<td><b>Descripción</b>
</td></tr>
<tr>
<td>general</td>
<td>48</td>
<td>44</td>
<td>187GB</td>
<td>
</td></tr>
<tr>
<td>largemem</td>
<td>9</td>
<td>44</td>
<td>765GB</td>
<td>
</td></tr>
<tr>
<td>v100</td>
<td>2</td>
<td>44</td>
<td>187GB</td>
<td>4 GPUs Nvidia Tesla V100.
</td></tr>
<tr>
<td>mi100</td>
<td>1</td>
<td>128</td>
<td>502GB</td>
<td>2 GPUs AMD Instinct MI100.
</td></tr>
<tr>
<td>slims</td>
<td>132</td>
<td>20</td>
<td>46GB</td>
<td>
</td></tr>
<tr>
<td>debug</td>
<td>4</td>
<td>20</td>
<td>59GB</td>
<td>Destinados a pruebas de máximo 30 minutos.
</td></tr></table>

== Introducción a los comandos slurm ==
<table class="wikitable" style="width: 60%;">
<td><b>Comando SLURM</b></td>
<td><b>Descripción</b>
</td></tr>
<tr>
<td>srun</td>
<td>ejecutar un comando en nodos de cómputo asignados.
</td></tr>
<tr>
<td>sbatch</td>
<td>presentar un script de trabajo
</td></tr>
<tr>
<td>squeue</td>
<td>Mostrar estado de los trabajos en la cola.
</td></tr>
<tr>
<td>scancel</td>
<td>eliminar un trabajo.
</td></tr>
<tr>
<td>sinfo</td>
<td>Muestra el estado de los nodos de cómputo.
</td></tr></table>
Estos son los comandos básicos utilizados para realizar la mayoría de las operaciones básicas con SLURM.

=== Estado de nodos ===
Para consultar el uso de nuestra infraestructura y qué particiones están más libres, le recomendamos el comando sinfo:

<pre># sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
all up infinite 16 mix cn[001,005-006,010,034-035,037,041,045,050,057,108,121],sn[012,016,037]
all up infinite 95 alloc cn[011-033,038-044,046-049,071-120],cnf[001-004],sn[001-011,038-041,043-044]
all up infinite 33 idle fn[001-009],gn[001-002],sn[018-035,045-048]
slims* up infinite 18 mix cn[001,003,005-006,010,034-035,043,045,050,057,070,079,085,095,098,108,121]
slims* up infinite 75 alloc cn[007-009,011-033,038-040,051-056,058-069,071-078,086-094,122-128],cnf[001-004]
debug up infinite 4 idle leftraru[1-2]
general up infinite 4 mix sn[012,016,037,042]
general up infinite 22 alloc sn[001-011,013-015,017,036,038-041,043-044]
general up infinite 22 idle sn[018-035,045-048]
largemem up infinite 9 idle fn[001-009]
v100 up infinite 2 idle gn[001-002]
mi100 up infinite 1 idle gna001
</pre>

Fijándose en el texto resaltado de la salida del comando sinfo, se puede comprobar que en la partición slims hay 112 nodos que están completamente ocupados (estado alloc), 20 nodos que están parcialmente ocupados (mix) y ninguno libre (idle); por otro lado, en la partición general hay 22 nodos completamente ocupados, 4 parcialmente ocupados y 22 libres. Dado este escenario, está claro que debería de lanzar sus ejecuciones en los nodos de la partición general, por las razones anteriormente expuestas.

Para lanzar en la partición general, debe tener en cuenta que tiene que indicar en su script que se use dicha partición en vez de, probablemente, slims. Por supuesto, en esta partición cambian las características técnicas, se pasan a tener 44 cores por nodo (en vez de 20 en slims) y una capacidad RAM de 187GB (en vez de 46GB en slims). Puede ver más información de las particiones en este link(agregar link), donde podrá revisar que con la inclusión de Guacolda hemos añadido nodos con hasta 765GB de memoria RAM y nodos con GPUs Nvidia Tesla V100 y AMD Instinct MI100 .

Para ver los nodos disponibles y poder determinar en que partición lanzar los trabajos se recomienda utilizar el siguiente comando.

<pre>[prueba@leftraru1 ~]$ sinfo -o "%10P %6D %10t %10m %c" -t idle| egrep "PARTITION|slims|general|largemem|v100"
PARTITION NODES STATE MEMORY CPUS
slims* 32 idle 46000 20
general 2 idle 187000 44
largemem 7 idle 765000 44
v100 1 idle 187000 44
mi100 1 idle 515047 128
</pre>

El comando anterior muestra que slims tiene 32 nodos libres, en este caso es recomendado lanzar en en slims para evitar que el trabajo quede en cola por falta de recursos en otros nodos.

Otro Ejemplo, se muestra sólo una partición específica

<pre>[prueba@leftraru1 ~]$ sinfo -p slims
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
slims* up infinite 24 mix cn[015,033,036-038,041-050,053-054,075-080,104]
slims* up infinite 76 alloc cn[001-009,019-032,039-040,051-090,093-094,097-099],cnf[001-004]
slims* up infinite 32 idle cn[010-014,016-018,034-035,056-058,073-074,091-100,120-122,125-127]
</pre>

=== Comprobación del estado de tareas ===
squeue - Muestra el estatus de los trabajos

<pre>squeue # tus trabajos
squeue -u <username> # trabajos por usuario <username>
</pre>

squeue: Comprobar estados de los trabajos

<div style="" class="mw-highlight mw-content-ltr" dir="ltr">
<pre>
JOBID PARTITION NAME USER ST TIME NODES NODELIST(REASON)
13951858_1 general test1 test1 R 1-18:35:14 2 cn[009-010]
13951857_2 general test2 test1 R 1-18:36:11 2 cn[099-100]
13956453 gpu test3 test3 R 1-03:42:08 1 cn039
13956449 largemem test4 test4 R 1-05:42:08 1 cn044
</pre>

Puede utilizar squeue para saber el estado de una o varias de sus tareas

<pre>
$ squeue -o "%.15i %.6P %.8j %.20S %.11M %.11L %.20V %.10Q %.4C %.2D %.6m" -S -t,-Q
JOBID PARTIT NAME START_TIME TIME TIME_LEFT SUBMIT_TIME PRIORITY CPUS NO MIN_ME
10837561 general TEST1 2018-06-18T18:51:01 19:00:31 2-04:59:29 2018-06-18T18:51:01 119972 1 1 1000M
10838562 general TEST2 2018-06-19T11:30:47 2:20:45 2-21:39:15 2018-06-19T11:30:46 119946 1 1 1000M
</pre>

para mas opciones puede revisar con el comando [https://slurm.schedmd.com/squeue.html man squeue] las opciones restantes.

=== Códigos de ESTADO de los trabajos ===

Los trabajos suelen pasar por varios estados durante su ejecución. Los estados típicos son PENDIENTE, EN EJECUCIÓN, SUSPENDIDO, FINALIZANDO y TERMINADO. A continuación se explica cada estado.

'''BF''' BOOT_FAIL
Trabajo finalizado debido a un fallo de arranque, normalmente debido a un fallo de hardware (por ejemplo, no se puede arrancar el nodo o bloque y el trabajo no se puede volver a poner en cola).

'''CA''' CANCELADO
El trabajo ha sido cancelado explícitamente por el usuario o el administrador del sistema. El trabajo puede haberse iniciado o no.

'''CD''' TERMINADO
El trabajo ha terminado todos los procesos en todos los nodos con un código de salida de cero.

'''CF''' CONFIGURANDO
Al trabajo se le han asignado recursos, pero están esperando a que estén listos para su uso (por ejemplo, arrancando).

'''CG''' COMPLETANDO
El trabajo está en proceso de finalización. Algunos procesos en algunos nodos pueden estar aún activos.

'''DL''' FECHA LÍMITE
El trabajo ha finalizado en la fecha límite.

'''F''' FALLÓ
Trabajo finalizado con un código de salida distinto de cero u otra condición de fallo.

'''NF''' NODO_FAIL
Trabajo finalizado debido al fallo de uno o más nodos asignados.

'''OOM''' OUT_OF_MEMORY
El trabajo ha experimentado un error de memoria insuficiente.

'''PD''' PENDIENTE
El trabajo está pendiente de asignación de recursos.

'''PR''' PREEMPTED
El trabajo ha finalizado debido a una espera.

'''R''' EN MARCHA
El trabajo tiene actualmente una asignación.

'''RD''' RESV_DEL_HOLD
El trabajo se está reteniendo después de que se eliminara la reserva solicitada.

'''RF''' REQUEUE_FED
El trabajo está siendo solicitado por una federación.

'''RH''' REQUEUE_HOLD
Se está volviendo a poner en cola un trabajo retenido.

'''RQ''' REQUEUED
Se está poniendo en cola un trabajo que se está completando.

'''RS''' CAMBIO DE TAMAÑO
El trabajo está a punto de cambiar de tamaño.

'''RV''' REVOCADO
El trabajo se ha retirado del clúster debido a que otro clúster ha iniciado el trabajo.

'''SI''' SEÑALANDO
El trabajo está siendo señalizado.

'''SE''' SPECIAL_EXIT
El trabajo se ha puesto en cola en un estado especial. Este estado puede ser establecido por los usuarios, normalmente en EpilogSlurmctld, si el trabajo ha terminado con un valor de salida particular.

'''SO''' STAGE_OUT
El trabajo está preparando los archivos.

'''ST''' PARADO
El trabajo tiene una asignación, pero la ejecución se ha detenido con la señal SIGSTOP. Los CPUS han sido retenidos por este trabajo.

'''S''' SUSPENDIDO
El trabajo tiene una asignación, pero se ha suspendido la ejecución y se han liberado CPUs para otros trabajos.

'''TO''' TIMEOUT
El trabajo ha finalizado al alcanzar su límite de tiempo.

=== Cancelar un trabajo ===
Con scancel se puede cancelar un trabajo en ejecución
<pre>scancel <jobID> # Matar proceso <jobID>. (puede obtener el ID del job con "squeue")
scancel -u <username> # Matar proceso por usuario <username>.
</pre>
<pre>[prueba@leftraru1 ~]$ squeue -u prueba
JOBID PARTITION NAME USER ST TIME NODES NODELIST(REASON)
45594 slims TEST prueba R 0:59 20 cn[001-020]
</pre>
<pre>[prueba@leftraru1 ~]$ scancel 45594
[prueba@leftraru1 ~]$ squeue -u prueba
JOBID PARTITION NAME USER ST TIME NODES NODELIST(REASON)
[prueba@leftraru1 ~]$
</pre>

=== Ver estado de trabajos ===
Para revisar el detalle de las opciones de un trabajo: scontrol show job

<pre>
$ scontrol show job 10837561
JobId=10837561 JobName=TEST1
UserId=usuario(1000) GroupId=group(1000) MCS_label=N/A
Priority=1100 Nice=0 Account=account QOS=120
JobState=RUNNING Reason=None Dependency=(null)
Requeue=0 Restarts=0 BatchFlag=1 Reboot=0 ExitCode=0:0
DerivedExitCode=0:0
RunTime=19:03:08 TimeLimit=3-00:00:00 TimeMin=N/A
SubmitTime=2018-06-18T18:51:01 EligibleTime=2018-06-18T18:51:01
StartTime=2018-06-18T18:51:01 EndTime=2018-06-21T18:51:01 Deadline=N/A
PreemptTime=None SuspendTime=None SecsPreSuspend=0
Partition=slims AllocNode:Sid=leftraru2:5471
ReqNodeList=(null) ExcNodeList=(null)
NodeList=cn021
BatchHost=cn021
NumNodes=1 NumCPUs=1 NumTasks=1 CPUs/Task=1 ReqB:S:C:T=0:0:*:*
TRES=cpu=1,mem=1000M,node=1
Socks/Node=* NtasksPerN:B:S:C=1:0:*:* CoreSpec=*
Nodes=cn021 CPU_IDs=1 Mem=1000 GRES_IDX=
MinCPUsNode=1 MinMemoryCPU=1000M MinTmpDiskNode=0
Features=(null) DelayBoot=00:00:00
Gres=(null) Reservation=(null)
OverSubscribe=OK Contiguous=0 Licenses=matlab Network=(null)
Command=/home/usuario/script.sh
WorkDir=/home/usuario/
StdErr=/home/usuario/10837561_%x.err
StdIn=/dev/null
StdOut=/home/usuario/10837561_%x.out
Power=
BatchScript=
</pre>

Para ver el script asociado a un trabajo: scontrol write batch_script <job_id> -

<pre>
$ scontrol write batch_script 10837561 -
#!/bin/bash
#SBATCH -J nombre_del_trabajo
#SBATCH -p slims
#SBATCH -n 1
#SBATCH --ntasks-per-node=1
#SBATCH --mail-user=usaurio@correo.cl
#SBATCH --mail-type=ALL
#SBATCH -o nombre_del_trabajo%j_%x.out
#SBATCH -e nombre_del_trabajo%j_%x.err
#SBATCH --license=matlab

ml MATLAB/2017a

matlab -nodisplay -nosplash -nodesktop < programa.m
</pre>

== Ejecutando trabajos ==
Actualmente contamos con 2 metodos de enviar trabajos bajo SLURM: '''sbatch''' and '''srun'''. A veces puede ser ventajoso ejecutar un solo comando en el clúster como prueba o realizar rápidamente una operación con recursos adicionales. 'srun' permite a los usuarios hacer esto, y comparte las mismas variables que 'sbatch' . STDOUT y STDERR para un trabajo 'srun' serán redirigidos a la pantalla del usuario. Ctrl-C cancelará un trabajo srun. '''sbatch''' enviará un script de trabajo para que lo ejecute el clúster. Los scripts de trabajo bajo SLURM son simplemente scripts de shell (* .sh) con un conjunto de solicitudes de recursos en la parte superior del script.

Uso básico de srun:

<pre>
srun <algúnComando>
</pre>

Ejemplo de salida (ejecutando el comando "hostname" para saber en que nodo se está ejecutando):
<pre> $ srun hostname
cn003
</pre>

Para enviar un script de trabajo a SLURM:
<pre>sbatch nombreScript.sh</pre>

Example output:
<pre>$ sbatch test-job.sh
Submitted batch job 1169</pre>

=== Variables Slurm ===
Las variables en esta sección son obligatorias, y SLURM las determina para determinar dónde y cuándo se ejecutarán sus trabajos. Si no asigna un valor para estos, el planificador asignará a sus trabajos el valor predeterminado. Si no solicita específicamente recursos para un trabajo, se le asignará un conjunto de recursos predeterminados. Para obtener una lista de todas las variables disponibles, consulte la documentación de SLURM en http://slurm.schedmd.com/sbatch.html. Las variables de este artículo estaban cubiertas porque eran las más relevantes para los casos de uso típicos.

<table class="wikitable" style="width: 100%;">
<tr>
<td><b>Comando SLURM</b></td>
<td><b>Descripción</b>
</td></tr>
<tr>
<td>--mem-per-cpu=<megabytes></td>
<td>Memoria requerida para el trabajo por CPU (en MegaBytes). El valor predeterminado es 1024 MB.
</td></tr>
<tr>
<td>-p <partition>, --partition=<partition></td>
<td>Enviar un trabajo a una partición específica.
</td></tr>
<tr>
<td>-n, --ntasks=<cantidad de tareas></td>
<td>Número de tareas que serán asignadas para el trabajo.
</td></tr>
<tr>
<td>-c <cpus></td>
<td>Esta es la cantidad de CPU que necesita su trabajo. Tenga en cuenta que SLURM es relativamente generoso con las CPU, y el valor especificado aquí es el número "mínimo" de CPU que se asignará a su trabajo. Si hay CPU adicionales disponibles en un nodo más allá de lo solicitado, su trabajo recibirá esas CPU hasta que otros trabajos las necesiten. El valor predeterminado es 1 CPU. Intentar usar más CPU de las que se le asignaron dará como resultado que sus procesos adicionales se turnen en la misma CPU (ralentizando su trabajo).
</td></tr>
<tr>
<td>-J <name>, --jobname=<name></td>
<td>Especifica un nombre a tu trabajo.
</td></tr>
<tr>
<td>--mail-type=BEGIN,END,FAIL,ALL<b> and </b>--mail-user=<emailAddress></td>
<td>Enviar por correo electrónico cuando su trabajo comienza / termina / falla. Puede especificar varios valores para esto (separados por comas) si es necesario.
</td></tr>
<tr>
<td>-o <STDOUT_log>, --output=<STDOUT_log></td>
<td>Redirija la salida a los archivos de registro que especifique. Por defecto, ambos, STDOUT and STDERR son enviados a este archivo. Puedes especificar %j como parte del nombre de archivo de registro para indicar la ID del trabajo (como ejemplo, "#SBATCH -o ouptut_%j.o" redirigiría la salida a "output_123456.o").
</td></tr>
<tr>
<td>-e <STDERR_log>, --error=<STDERR_log></td>
<td>Redireccionar STDERR a un archivo separado. Funciona exactamente igual que "-o".
</td></tr>
<tr>
<td>-t <days-hours:minutes:seconds></td>
<td>Walltime para tu trabajo. La duración del Walltime es el tiempo que espera que su trabajo se ejecute.
</td></tr>
<tr>
<td>-a, --array=<índices></td>
<td>Envía una lista (arreglo) de trabajos identicos. Solo aplica para sbatch.
</td></tr></table>

Los scripts de trabajo especifican los recursos solicitados y otras consideraciones especiales con comentarios especiales "#SBATCH" en la parte superior de un script de trabajo. Aunque muchas de estas opciones son opcionales, las varibles que se ocupan de solicitudes de recursos (CPU, memoria y tiempo) son obligatorias. Todas las variables deben agregarse a sus scripts de la siguiente manera:

<pre>#SBATCH <variable></pre>
Para especificar un nombre al job, por ejemplo, debe agregar lo siguiente a su secuencia de comandos:

<pre>#SBATCH --job-name=nombreDeTrabajo</pre>

===Enviar un script===
<pre>
#!/bin/bash
#SBATCH -J example
#SBATCH -p general
#SBATCH -n 1
#SBATCH --output=example_%j.out
#SBATCH --error=example_%j.err
#SBATCH --mail-user=user@example.com
#SBATCH --mail-type=ALL
</pre>

Como debe comenzar un script en Linux:
<pre>
#!/bin/bash
</pre>

Nombre del trabajo:
<pre>
#SBATCH -J example
</pre>

Nombre la partición donde desea ejecutar el Job:
<pre>
#SBATCH -p general
</pre>

Número de tareas:
<pre>
#SBATCH -n 1
</pre>

Log de salida:
<pre>
#SBATCH -o example_%j.out
</pre>

Log de error:
<pre>
#SBATCH -e example_%j.err
</pre>

Correo para notificaciones:
<pre>
#SBATCH --mail-user=user@example.com
</pre>

Enviar correo en todos casos (verificar opciones arriba):
<pre>
#SBATCH --mail-type=ALL
</pre>

=== Programar tarea (uso de scrontab) ===
'''scrontab''' es una implementación del clásico planificador de tareas de linux '''crontab''' donde se guarda un listado de comandos a ejecutar en un tiempo determinado por el usuario.

Para acceder a scrontab utilice el siguiente comando:
<pre>
[prueba@leftraru1 ~]$ scrontab -e
</pre>

Esto le permitirá editar su archivo scrontab, asignando recursos como también el momento en que desea ejecutar su tarea. La estructura base a utilizar es la siguiente:
<pre>
#SCRON -J mi_tarea
#SCRON -p slims
#SCRON -n 1
#SCRON -c 1
#SCRON --mem-per-cpu=2300
#SCRON --mail-user=foo@bar.com
#SCRON --mail-type=ALL
#SCRON -o mi_tarea_%j.out
#SCRON -e mi_tarea_%j.err
# Example of job definition:
# .---------------- minute (0 - 59)
# | .------------- hour (0 - 23)
# | | .---------- day of month (1 - 31)
# | | | .------- month (1 - 12) OR jan,feb,mar,apr ...
# | | | | .---- day of week (0 - 6) (Sunday=0 or 7) OR sun,mon,tue,wed,thu,fri,sat
# | | | | |
# * * * * * command to be executed
</pre>

* '''minute''' - Corresponde al minuto en que se va a ejecutar el script, valor de 0 a 59.
* '''hour''' - Hora de ejecución, formato 24 horas, valor de 0 a 23, donde 0 son las 12:00 AM.
* '''day of month''' - Día del mes, la tarea se puede ejecutar cada x día, valor de 1 a 31.
* '''month''' - La tarea se puede ejecutar cada x mes, valor de 1 a 12.
* '''day of week''' - Día de la semana, valor de 0 a 6, donde 0 es Domingo.
* '''command to be executed''' - Script a ejecutar por el usuario.

Ejemplo envío de trabajo slurm:

Para la asignación de recursos, utilizaremos la directriz '''#SCRON''', que utiliza los mismos parámetros usados por '''#SBATCH'''.

Luego de asignar los recursos debemos especificar el tiempo, en este caso la tarea será ejecutada todos los días cada 20 minutos, luego debemos indicar el script enviado por el usuario y guardamos los cambios en el archivo.

<pre>
*/20 * * * * /home/prueba/ejemplo/script.sh
</pre>

Es importante destacar que el script a lanzar '''/home/prueba/ejemplo/script.sh''' debe tener permisos de ejecución.

Para revisar el listado de tareas existentes en nuestro scrontab, ejecutamos el comando:
<pre>
[prueba@leftraru1 ~]$ scrontab -l
*/20 * * * * /home/prueba/ejemplo/script.sh
</pre>

Para borrar el contenido de nuestro scrontab:
<pre>
[prueba@leftraru1 ~]$ scrontab -r
</pre>

'''Información a considerar:'''

* Generar archivos de salida correctamente
** Para que el archivo error y out de tu script se generen en el directorio solicitado, ejemplo, /home/prueba/ejemplo/ en tu script debe estar presente el comando cd “/home/prueba/ejemplo”, esto hará que scrontab se posicione dentro del directorio de salida.
* Es distinto el tiempo de programar el envío de una tarea (scrontab) a que una tarea inicie en el clúster (running), ya que esto dependerá de los recursos libres que existan en ese momento en el clúster.
* Para revisar las tareas programadas debe ejecutar en cualquier nodo login el comando '''scrontab -l''' o revisar con el comando '''squeue''':

<pre>
[prueba@leftraru1 ~]$ squeue
24293471 slims /home/eg prueba PD 0:00 1 (BeginTime)
</pre>

== Checkpointing ==
Es la acción de guardar el estado de un proceso en ejecución en un archivo de imagen de punto de control. Este proceso se puede reiniciar más tarde desde el archivo del punto de control, continuando la ejecución desde donde se detuvo, en la misma computadora o en una diferente.

=== ¿Por qué utilizarlo? ===
* Permite ejecuciones de tarea largas que superen el tiempo de ejecución permitido en el cluster (30 días)
* Estar preparados ante fallas del sistema que nos puedan hacer perder resultados de nuestras simulaciones

=== Utilización ===
Lo primero que debemos hacer en nuestro script es cargar el módulo de Mana:
<pre>
ml mana/3.0.0
</pre>
Este módulo provee 3 ejecutables que necesitaremos:

* '''mana_coordinator:''' Coordina los checkpoints entre los distintos procesos
* '''mana_launch:''' Inicia un proceso con checkpoint
* '''mana_restart:''' Reinicia la ejecución desde una imagen del checkpoint

Necesitaremos 2 scripts para trabajar con checkpoints: Inicio y reinicio

=== Script de inicio (inicio.sh) ===
<pre>
#!/bin/bash
##---------------SLURM Parameters - NLHPC ----------------
#SBATCH -J Testcheckpoint
#SBATCH -p general
#SBATCH -n 44
#SBATCH --ntasks-per-node=44
#SBATCH --mem-per-cpu=4363
#SBATCH --mail-user=test@nlhpc.cl
#SBATCH --mail-type=ALL
#SBATCH -o Testcheckpoint_%j.out
#SBATCH -e Testcheckpoint_%j.err

# ----------------Modules----------------------------
ml mana/3.0.0
# ----------------Command--------------------------
#Checkpointing cada 1 hora
mana_cooridinator -i3600
#Ejecutamos nuestra tarea con checkpointing
srun mana_launch ./ejecutable
</pre>

=== Script de reinicio (reinicio.sh) ===
<pre>
#!/bin/bash
##---------------SLURM Parameters - NLHPC ----------------
#SBATCH -J Testcheckpoint
#SBATCH -p general
#SBATCH -n 44
#SBATCH --ntasks-per-node=44
#SBATCH --mem-per-cpu=4363
#SBATCH --mail-user=test@nlhpc.cl
#SBATCH --mail-type=ALL
#SBATCH -o Testcheckpoint_%j.out
#SBATCH -e Testcheckpoint_%j.err

# ----------------Modules----------------------------
ml mana/3.0.0
# ----------------Command--------------------------
#Checkpointing cada 1 hora
mana_cooridinator -i3600
#Reiniciar nuestra tarea desde los archivos de checkpoint
srun mana_restart
</pre>

Para correr estos scripts se puede hacer utilizando la funcionalidad de dependencias de SLURM:
<pre>
[test@leftraru2 test]$ sbatch inicio.sh
Submitted batch job 23574685
[test@leftraru2 test]$ sbatch --dependency=afterok:23574685 reinicio.sh
</pre>

== Trabajos ==
=== Trabajos paralelos ===
Muchos de los trabajos que se ejecutan en un clúster de producción implicarán más de un procesador (CPU, núcleo). Dichos trabajos paralelos deben solicitar la cantidad de recursos necesarios a través de opciones adicionales. Los más comunes son:

Para diferentes tipos de trabajos paralelos, se especificarán diferentes opciones. Los trabajos paralelos más comunes son trabajos de MPI (memoria distribuida), trabajos de subprocesos múltiples (memoria compartida) y los llamados híbridos que son una combinación de los dos. Analicemos por separado con un n ejemplo para cada uno.

=== Ejecución de programas con MPI ===
MPI (interfaz de paso de mensajes) es la API de comunicación estándar para trabajos paralelos de memoria distribuida capaz de implementarse en un clúster. Para programar dicho trabajo, es necesario especificar la cantidad de nodos del clúster que se utilizarán y la cantidad de procesos (tareas) que se ejecutarán en cada nodo.

El siguiente es un ejemplo de ejecución de un programa compilado con Open MPI:

#!/bin/bash
#SBATCH -J example_mpi
#SBATCH -p general
#SBATCH -n 264
#SBATCH --ntasks-per-node=44
#SBATCH --output=example_%j.out
#SBATCH --error=example_%j.err
#SBATCH --mail-user=user@example.com
#SBATCH --mail-type=ALL

srun ./mpi_test
A continuacion se explica línea por líneael script.

Como empieza un shell script en Linux:
<pre>
#!/bin/bash
</pre>

Nombre del Job:
<pre>
#SBATCH -J example_mpi
</pre>

Nombre la particion donde se desea ejecutar el trabajo:
<pre>
#SBATCH -p general
</pre>

Número de tareas. Debe de ser un número múltiplo del número de CPUs máximo que tenga un node de la partición donde se lanza:
<pre>
#SBATCH -n 264
</pre>

Con esto se fuerza a que se lancen 44 tareas MPI en cada uno de los nodos, ocupando de este modo nodos completos. En este caso 6 nodos completos:
<pre>
#SBATCH --ntasks-per-node=44
</pre>

Log de salida:
<pre>
#SBATCH -o example_%j.out
</pre>

Log de error:
<pre>
#SBATCH -e example_%j.err
</pre>

Correo para notificaciones:
<pre>
#SBATCH --mail-user=user@example.com
</pre>

Envía correo en todos los casos:
<pre>
#SBATCH --mail-type=ALL
</pre>

Programa para ejecutar:
<pre>
srun ./mpi_test
</pre>

'''Nota''': no se carga específicamente el módulo "mpi" ya que se carga siempre por defecto.

Para enviarlo al clúster debe ejecutar el comando: ''sbatch script.sh''. El ejemplo anterior ejecutará una tarea OpenMPI con 264 procesos reservando 264 cores para ello.

=== Trabajos multiproceso OpenMP ===
Los trabajos paralelos diseñados para ejecutarse en un sistema multi-core (shared-memory) suelen ser "multi-threaded". La programación de un job de este tipo requiere especificar el número de núcleos que se utilizan para acomodar los subprocesos.

OpenMP es el conjunto común de variables de compilación para facilitar el desarrollo de programas multi-threaded. Un script típico de SLURM para un programa de este tipo se ve así:
<pre>
#!/bin/bash
#SBATCH -J OMPtest
#SBATCH -p general
#SBATCH -n 1
#SBATCH -c 44
#SBATCH --ntasks-per-node=44
#SBATCH --mem-per-cpu=1024
#SBATCH -o example_%j.out
#SBATCH -e example_%j.err
#SBATCH --mail-user=user@example.com
#SBATCH --mail-type=ALL

OMP_NUM_THREADS=$SLURM_CPUS_PER_TASK time ./omp-program
</pre>

Como debe comenzar un script en Linux:
<pre>
#!/bin/bash
</pre>

Nombre del Job:
<pre>
#SBATCH -J OMPtest
</pre>

Nombre la particion donde desea ejecutar el Job:
<pre>
#SBATCH -p general
</pre>

Número de trabajos:
<pre>
#SBATCH -n 1
</pre>

Número de tareas:
<pre>
#SBATCH -c 44
</pre>

Con esto se fuerza a que se agrupen las 44 tareas en un nodo (en OpenMP no hay comunicación entre nodos, por lo que todas las tareas deben estar en el mismo nodo o no funcionaría):
<pre>
#SBATCH --ntasks-per-node=44
</pre>

Memoria por core (MBytes):
<pre>
#SBATCH --mem-per-cpu=1024
</pre>

Log de salida:
<pre>
#SBATCH -o example_%j.out
</pre>

Log de error:
<pre>
#SBATCH -e example_%j.err
</pre>

Correo para notificaciones:
<pre>
#SBATCH --mail-user=user@example.com
</pre>

Enviar correo en todos los casos:
<pre>
#SBATCH --mail-type=ALL
</pre>

Programa para ejecutar:
<pre>
OMP_NUM_THREADS=$SLURM_CPUS_PER_TASK time ./omp-program
</pre>

Cuando se utiliza un programa OpenMP, el número de subprocesos (y, por lo tanto, el número requerido de núcleos) se especifica a través de la variable de entorno OMP_NUM_THREADS que, por lo tanto, aparece en el script frente a la llamada al programa. Lo estamos configurando en la variable interna SLURM_CPUS_PER_TASK que se establece a través de la opción "-c" (a 44 en nuestro ejemplo, que sería el número total de cores de un nodo de la partición "general").

La opción "-n" se mantiene en 1 para indicar un único trabajo principal que tiene 44 tareas. Para asegurarnos que todas las tareas se ejecutan en el mismo nodo, se añade la opción "--ntasks-per-node" con el máximo número de cores que tiene un nodo de la partición donde se está lanzando el trabajo.

=== Ejecución de tareas en GPUs ===
<pre>
#!/bin/bash
#SBATCH -J ejemplo_gpus
#SBATCH -p v100
#SBATCH -n 1
#SBATCH -o ejemplo_%j.out
#SBATCH -e ejemplo_%j.err
#SBATCH --mail-user=correo@gmail.com
#SBATCH --mail-type=ALL
#SBATCH --mem-per-cpu=4300
#SBATCH --gres=gpu:1

./programa
</pre>

Inicio de un bash script en Linux:
<pre>
#!/bin/bash
</pre>

Nombre del trabajo:
<pre>
#SBATCH -J ejemplo_gpus
</pre>

Nombre la partición donde se ejecuta el trabajo:
<pre>
#SBATCH --partition=v100
</pre>

Número de tareas:
<pre>
#SBATCH -n 1
</pre>

Log de salida:
<pre>
#SBATCH -o ejemplo_%j.out
</pre>

Log de error:
<pre>
#SBATCH -e ejemplo_%j.err
</pre>

Correo para notificaciones:
<pre>
#SBATCH --mail-user=user@example.com
</pre>

Enviar correo en todos los casos:
<pre>
#SBATCH --mail-type=ALL
</pre>

Memoria por CPU (MB):
<pre>
#SBATCH --mem-per-cpu=4365
</pre>

Cantidad utilizada de GPUs. El parámetro gpu:1 indica la cantidad de tarjetas a utilizar (cada nodo tiene 2 GPUs):
<pre>
#SBATCH --gres=gpu:1
</pre>

Programa para ejecutar:
<pre>
./programa
</pre>

=== Job Arrays ===
Cuando se ejecutan cientos o miles de simulaciones que utilizan la misma cantidad de recursos, puede ser una ventaja ejecutar estas simulaciones como un "job array". Los job array le permiten enviar miles de dichos trabajos (llamados "job steps") con un solo script. A cada simulación se le asignará un valor único para la variable de entorno SLURM_ARRAY_TASK_ID. Puede usar esta variable para leer parámetros para pasos individuales de una línea dada de un archivo.

=== Caso de uso de un Script Job Array (Gaussian) ===
Tenemos usuarios que actualmente envían varias simulaciones al clúster que son similares en cuanto al uso de recursos, pero, la diferencia es que solo cambia la entrada que le entregan al programa. Para esta situación, recomendamos hacer uso de un script Job Array.

En este ejemplo crearemos un script job array para el software Gaussian, el cual, realizará 63 simulaciones, cada una de estas utilizará 8 cores y podrá alcanzar un uso máximo de 8 Gb de memoria ram. Para este caso utilizaremos la partición slims donde cada nodo tiene 46 Gb de memoria ram y 20 cores.

Script:
<pre>
#!/bin/bash
# ----------------SLURM Parameters----------------
#SBATCH -J prueba
#SBATCH -p slims
#SBATCH -n 1
#SBATCH -c 8
#SBATCH --mem-per-cpu=1000
#SBATCH --mail-user=prueba@nlhpc.cl
#SBATCH --mail-type=ALL
#SBATCH --array=1-63
#SBATCH -o prueba_%A_%a.out
#SBATCH -e prueba_%A_%a.err
#-----------------Toolchain---------------------------
ml purge
ml intel/2019b
# ----------------Módulos-----------------------------
ml g16/B.01
# ----------------Comandos--------------------------
file=$(ls Child_10_*.com | sed -n ${SLURM_ARRAY_TASK_ID}p)
srun g16 $file
</pre>

'''
Descripción de comandos utilizados en script:'''

Inicio de un bash script en Linux:
<pre>
#!/bin/bash
</pre>

Nombre de la simulación:
<pre>
#SBATCH -J prueba
</pre>

Nombre la partición donde se ejecuta la simulación:
<pre>
#SBATCH -p slims
</pre>

Número de tareas (1 tarea va a ejecutar 63 simulaciones):
<pre>
#SBATCH -n 1
</pre>

Core’s por tareas (cada tarea utilizará un máximo 8 cores):
<pre>
#SBATCH -c 8
</pre>

Memoria ram por cpu (cada tarea utilizará un máximo 8 Gb de ram):
<pre>
#SBATCH –mem-per-cpu=1000
</pre>

Correo para activar el envío de notificaciones:
<pre>
#SBATCH --mail-user=prueba@nlhpc.cl
</pre>

Permitir envío de notificaciones:
<pre>
#SBATCH --mail-type=ALL
</pre>

Se generan 63 simulaciones diferentes:
<pre>
#SBATCH --array=1-63
</pre>

Log de salida: (ejemplo: prueba_18455017_1.out)

* %A corresponde al Job ID de nuestra tarea que le asignará Slurm → 18455017.
* %a corresponde a la simulación X de nuestra tarea que le asignará Slurm → 1.
<pre>
#SBATCH -o prueba_%A_%a.out
</pre>

Log de errores: (ejemplo: prueba_18455017_1.err)

* %A corresponde al Job ID de nuestra tarea que le asignará Slurm → 18455017.
* %a corresponde a la simulación X de nuestra tarea que le asignará Slurm → 1.

<pre>
#SBATCH -e prueba_%A_%a.err
Toolchain: en este apartado, limpiaremos nuestro entorno de software no deseados y luego escogemos la herramienta informática con la cual está compilado el software Gaussian (nosotros utilizamos el compilador Intel/2019b).

#-----------------Toolchain---------------------------
ml purge
ml intel/2019b
Módulos: cargamos el software Gaussian versión 16/B.0.

# ----------------Módulos-----------------------------
ml g16/B.01
Comandos: aquí definimos los comandos a ejecutar.

# ----------------Comandos--------------------------
file=$(ls Child_10_*.com | sed -n ${SLURM_ARRAY_TASK_ID}p)
srun g16 $file
</pre>
file= variable que va a listar los archivos de entrada que comiencen por Child_10_ y terminen en .com

[[Archivo:Child.png|no]]

sed -n ${SLURM_ARRAY_TASK_ID}p) ← Sed imprimirá las líneas de cada archivo de entrada y la variable $SLURM_ARRAY_TASK_ID asumirá estas entradas como matriz de simulación en nuestro job array, en este ejemplo tenemos 63 archivos de entrada.

Para más detalles sobre los archivos stdin, stdout y stderr de una simulación % A será reemplazado por el valor de SLURM_ARRAY_JOB_ID que es el Job ID de nuestra tarea y %a será reemplazado por el valor de SLURM_ARRAY_TASK_ID que corresponde a la simulación X de nuestra tarea.

Srun g16 $file: ejecutará el comando gaussian g16 interpretando la variable $file en los nodos de cómputo asignados.

Enviar el script:
<pre>
[prueba@leftraru1 ~]$ sbatch prueba.sh
</pre>

=== Ejecución de una tarea que ocupa mucha RAM por CPU ===
Debemos tener en cuenta que la RAM que SLURM reserva por defecto son 1000 MB. Un típico error de cancelación de tarea por falta de memoria es el siguiente:
<pre>
/tmp/slurmd/job136839939/slurm_script: line 15: 23547 Killed ./programa.sh
slurmstepd: error: Detected 1 oom-kill event(s) in step 136839939.batch cgroup. Some of your processes
may have been killed by the cgroup out-of-memory handler.
</pre>

Si su tarea ocupa más de la memoria por defecto, puede utilizar el siguiente parámetro:
<pre>
#SBATCH --mem-per-cpu=2300 #Máxima RAM por CPU
</pre>
Esto hará que SLURM reserve más RAM por CPU para sus tareas.

Tenga en cuenta que nuestros nodos tienen 46 GB de memoria RAM (Partición slims), 187 GB (Partición general) y 765 GB (Partición largemem) por nodo. [https://wiki.nlhpc.cl/Hardware_Disponible Más información].

Otra forma de reservar memoria es utilizando el siguiente parámetro:

<pre>
#SBATCH --mem=2300
</pre>
En este caso SLURM realizará una reserva de memoria de 2300 MB pero por la totalidad del trabajo.

Los parámetros anteriores al igual que el número de CPUs que se van a usar, hay que afinarlos lo mejor posible. Para ello lo que se puede hacer es hacer pruebas en los nodos logins, sin lanzar en las colas, y así estudiar el uso de RAM y CPU por parte de sus procesos.

=== Ejecución de una tarea con Dependencias ===
Las dependencias de trabajos se utilizan para aplazar el inicio de un trabajo hasta que se satisfagan las dependencias especificadas. Se especifican con la opción --dependency en el siguiente formato:
<pre>
sbatch --dependency=<type:job_id[:job_id][,type:job_id[:job_id]]> ...
</pre>
Los tipos de dependencias son las siguientes:

* '''after''':jobid[:jobid...] - el trabajo puede empezar después de que los trabajos especificados comiencen
* '''afterany''':jobid[:jobid...] - el trabajo puede empezar después de que los trabajos especificados terminen
* '''afternotok''':jobid[:jobid...] - el trabajo puede empezar después que los trabajos especificados terminan fallidamente
* '''afterok''':jobid[:jobid...] - el trabajo puede empezar después que los trabajos especificados terminan exitósamente

La manera más simple de usar una dependencia del tipo afterok:
<pre>
[prueba@leftraru1 ~]$ sbatch job1.sh
Submitted batch job 21363626
[prueba@leftraru1 ~]$ sbatch --dependency=afterok:21363626 job2.sh
</pre>

Ahora cuando job1.sh termine correctamente, el job2.sh entrará en ejecución. Si job1.sh termina fallidamente, job2.sh no entrará en ejecución nunca pero sí quedará en cola (debe cancelarse manualmente el trabajo).

== Prioridad de tarea ==
Cómo ver la prioridad del trabajo. Los factores que determinan la prioridad del trabajo, incluyendo la fórmula y pesos.

=== Factores que determinan prioridad de tarea ===
<table class="wikitable" style="width: 60%;">
<tr>
<td><b>Comando SLURM</b></td>
<td><b>Descripción</b>
</td></tr>
<tr>
<td>Edad</td>
<td>la cantidad de tiempo que el trabajo ha estado esperando en la cola.
</td></tr>
<tr>
<td>Tamaño de la tarea</td>
<td>número de nodos solicitados por el trabajo.
</td></tr>
<tr>
<td>Partición</td>
<td>prioridad para una partición determinada.
</td></tr>
<tr>
<td>Prioridad Baja</td>
<td>Mientras más tareas se ejecuten en el cluster, menor será la prioridad.
</td></tr>
<tr>
<td>Prioridad Alta</td>
<td>Mientras menos tareas se ejecuten en el clúster, más alta es la prioridad.
</td></tr></table>

== Prioridad de tarea ==
Cómo ver la prioridad del trabajo. Los factores que determinan la prioridad del trabajo, incluyendo la fórmula y pesos.

=== Factores que determinan prioridad de tarea ===
* Edad - la cantidad de tiempo que el trabajo ha estado esperando en la cola
* Tamaño Oficio - número de nodos solicitados por el trabajo
* Partición - prioridad para una partición determinada
* Contribución de prioridades basada en los recursos informáticos utilizados por los miembros de un grupo de investigación en los últimos 30 días - Fairshare.
* Mientras más tareas se ejecuten en el cluster, menor será la prioridad.
* Mientras menos tareas se ejecuten en el clúster, más alta es la prioridad.
Fórmula Prioridad de tarea
<pre>
Job_priority =
(PriorityWeightAge) * (age_factor) +
(PriorityWeightFairshare) * (fair-share_factor) +
(PriorityWeightJobSize) * (job_size_factor) +
(PriorityWeightPartition) * (partition_factor) +
(PriorityWeightQOS) * (QOS_factor)
</pre>

== Visualización de sus Tareas ==
Si Ud. necesita visualizar información acerca de sus tareas de forma interactiva, puede utilizar el comando smap:

smap -i 3

[[Archivo:Smap.png|no|700px]]

De esta forma, tendrá una actualización cada 3 segundos de sus tareas en ejecución incluyendo los nodos en los cuales se encuentran ejecutándose.

== Bibliografía ==
[http://slurm.schedmd.com/documentation.html Manual Oficial de Slurm]

[https://slurm.schedmd.com/scrontab.html Documentación scrontab]

SISTEMA GESTOR DE RECURSOS

2024-04-29T19:13:43Z

Jmorales: /* Script de reinicio (reinicio.sh) */

== SLURM Workload Manager ==
Es un sistema de programación de trabajos y gestión de clústeres de código abierto, tolerante a fallas y altamente escalable para clústeres Linux grandes y pequeños.

Como administrador de carga de trabajo de clúster, Slurm tiene tres funciones clave. Primero, asigna acceso exclusivo y / o no exclusivo a los recursos (nodos de cómputo) a los usuarios durante un período de tiempo para que puedan realizar el trabajo. En segundo lugar, proporciona un marco para iniciar, ejecutar y monitorear el trabajo (normalmente un trabajo paralelo) en el conjunto de nodos asignados. Finalmente, arbitra la contención de recursos mediante la gestión de una cola de trabajo pendiente.

SLURM es el gestor de colas instalado en muchos de los súper computadores del [https://www.top500.org/ TOP500], y también en el clúster del NLHPC. Si Ud. quiere lanzar tareas dentro de Leftaru, debe hacerlo a través de Slurm.

== Conceptos clave ==
SLURM gestiona trabajos de usuario que tienen las siguientes características clave:

* Conjunto de recursos solicitados:
** Número de recursos informáticos: nodos (incluidas todas sus CPUs y núcleos) o CPUs (incluidos todos sus núcleos) o solo núcleos
** Cantidad de memoria: por nodo o por CPU (lógica)
** Tiempo necesario para que las tareas del usuario completen su trabajo
* Una partición de nodo solicitada (cola de trabajos)
* Un nivel de calidad de servicio (QoS) solicitado que otorga a los usuarios accesos específicos
* Una cuenta solicitada con recursos limitados

De manera predeterminada, los usuarios envían trabajos a una partición particular (marcada como tal para todos los usuarios) y bajo una cuenta particular (preestablecida por usuario).

== Particiones SLURM ==

<table class="wikitable" style="width: 60%;">
<tr>
<td><b>Nombre Particion</b></td>
<td><b>Nodos</b></td>
<td><b>CPUs</b></td>
<td><b>RAM</b></td>
<td><b>Descripción</b>
</td></tr>
<tr>
<td>general</td>
<td>48</td>
<td>44</td>
<td>187GB</td>
<td>
</td></tr>
<tr>
<td>largemem</td>
<td>9</td>
<td>44</td>
<td>765GB</td>
<td>
</td></tr>
<tr>
<td>v100</td>
<td>2</td>
<td>44</td>
<td>187GB</td>
<td>4 GPUs Nvidia Tesla V100.
</td></tr>
<tr>
<td>mi100</td>
<td>1</td>
<td>128</td>
<td>502GB</td>
<td>2 GPUs AMD Instinct MI100.
</td></tr>
<tr>
<td>slims</td>
<td>132</td>
<td>20</td>
<td>46GB</td>
<td>
</td></tr>
<tr>
<td>debug</td>
<td>4</td>
<td>20</td>
<td>59GB</td>
<td>Destinados a pruebas de máximo 30 minutos.
</td></tr></table>

== Introducción a los comandos slurm ==
<table class="wikitable" style="width: 60%;">
<td><b>Comando SLURM</b></td>
<td><b>Descripción</b>
</td></tr>
<tr>
<td>srun</td>
<td>ejecutar un comando en nodos de cómputo asignados.
</td></tr>
<tr>
<td>sbatch</td>
<td>presentar un script de trabajo
</td></tr>
<tr>
<td>squeue</td>
<td>Mostrar estado de los trabajos en la cola.
</td></tr>
<tr>
<td>scancel</td>
<td>eliminar un trabajo.
</td></tr>
<tr>
<td>sinfo</td>
<td>Muestra el estado de los nodos de cómputo.
</td></tr></table>
Estos son los comandos básicos utilizados para realizar la mayoría de las operaciones básicas con SLURM.

=== Estado de nodos ===
Para consultar el uso de nuestra infraestructura y qué particiones están más libres, le recomendamos el comando sinfo:

<pre># sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
all up infinite 16 mix cn[001,005-006,010,034-035,037,041,045,050,057,108,121],sn[012,016,037]
all up infinite 95 alloc cn[011-033,038-044,046-049,071-120],cnf[001-004],sn[001-011,038-041,043-044]
all up infinite 33 idle fn[001-009],gn[001-002],sn[018-035,045-048]
slims* up infinite 18 mix cn[001,003,005-006,010,034-035,043,045,050,057,070,079,085,095,098,108,121]
slims* up infinite 75 alloc cn[007-009,011-033,038-040,051-056,058-069,071-078,086-094,122-128],cnf[001-004]
debug up infinite 4 idle leftraru[1-4]
general up infinite 4 mix sn[012,016,037,042]
general up infinite 22 alloc sn[001-011,013-015,017,036,038-041,043-044]
general up infinite 22 idle sn[018-035,045-048]
largemem up infinite 9 idle fn[001-009]
v100 up infinite 2 idle gn[001-002]
mi100 up infinite 1 idle gna001
</pre>

Fijándose en el texto resaltado de la salida del comando sinfo, se puede comprobar que en la partición slims hay 112 nodos que están completamente ocupados (estado alloc), 20 nodos que están parcialmente ocupados (mix) y ninguno libre (idle); por otro lado, en la partición general hay 22 nodos completamente ocupados, 4 parcialmente ocupados y 22 libres. Dado este escenario, está claro que debería de lanzar sus ejecuciones en los nodos de la partición general, por las razones anteriormente expuestas.

Para lanzar en la partición general, debe tener en cuenta que tiene que indicar en su script que se use dicha partición en vez de, probablemente, slims. Por supuesto, en esta partición cambian las características técnicas, se pasan a tener 44 cores por nodo (en vez de 20 en slims) y una capacidad RAM de 187GB (en vez de 46GB en slims). Puede ver más información de las particiones en este link(agregar link), donde podrá revisar que con la inclusión de Guacolda hemos añadido nodos con hasta 765GB de memoria RAM y nodos con GPUs Nvidia Tesla V100 y AMD Instinct MI100 .

Para ver los nodos disponibles y poder determinar en que partición lanzar los trabajos se recomienda utilizar el siguiente comando.

<pre>[prueba@leftraru1 ~]$ sinfo -o "%10P %6D %10t %10m %c" -t idle| egrep "PARTITION|slims|general|largemem|v100"
PARTITION NODES STATE MEMORY CPUS
slims* 32 idle 46000 20
general 2 idle 187000 44
largemem 7 idle 765000 44
v100 1 idle 187000 44
mi100 1 idle 515047 128
</pre>

El comando anterior muestra que slims tiene 32 nodos libres, en este caso es recomendado lanzar en en slims para evitar que el trabajo quede en cola por falta de recursos en otros nodos.

Otro Ejemplo, se muestra sólo una partición específica

<pre>[prueba@leftraru1 ~]$ sinfo -p slims
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
slims* up infinite 24 mix cn[015,033,036-038,041-050,053-054,075-080,104]
slims* up infinite 76 alloc cn[001-009,019-032,039-040,051-090,093-094,097-099],cnf[001-004]
slims* up infinite 32 idle cn[010-014,016-018,034-035,056-058,073-074,091-100,120-122,125-127]
</pre>

=== Comprobación del estado de tareas ===
squeue - Muestra el estatus de los trabajos

<pre>squeue # tus trabajos
squeue -u <username> # trabajos por usuario <username>
</pre>

squeue: Comprobar estados de los trabajos

<div style="" class="mw-highlight mw-content-ltr" dir="ltr">
<pre>
JOBID PARTITION NAME USER ST TIME NODES NODELIST(REASON)
13951858_1 general test1 test1 R 1-18:35:14 2 cn[009-010]
13951857_2 general test2 test1 R 1-18:36:11 2 cn[099-100]
13956453 gpu test3 test3 R 1-03:42:08 1 cn039
13956449 largemem test4 test4 R 1-05:42:08 1 cn044
</pre>

Puede utilizar squeue para saber el estado de una o varias de sus tareas

<pre>
$ squeue -o "%.15i %.6P %.8j %.20S %.11M %.11L %.20V %.10Q %.4C %.2D %.6m" -S -t,-Q
JOBID PARTIT NAME START_TIME TIME TIME_LEFT SUBMIT_TIME PRIORITY CPUS NO MIN_ME
10837561 general TEST1 2018-06-18T18:51:01 19:00:31 2-04:59:29 2018-06-18T18:51:01 119972 1 1 1000M
10838562 general TEST2 2018-06-19T11:30:47 2:20:45 2-21:39:15 2018-06-19T11:30:46 119946 1 1 1000M
</pre>

para mas opciones puede revisar con el comando [https://slurm.schedmd.com/squeue.html man squeue] las opciones restantes.

=== Códigos de ESTADO de los trabajos ===

Los trabajos suelen pasar por varios estados durante su ejecución. Los estados típicos son PENDIENTE, EN EJECUCIÓN, SUSPENDIDO, FINALIZANDO y TERMINADO. A continuación se explica cada estado.

'''BF''' BOOT_FAIL
Trabajo finalizado debido a un fallo de arranque, normalmente debido a un fallo de hardware (por ejemplo, no se puede arrancar el nodo o bloque y el trabajo no se puede volver a poner en cola).

'''CA''' CANCELADO
El trabajo ha sido cancelado explícitamente por el usuario o el administrador del sistema. El trabajo puede haberse iniciado o no.

'''CD''' TERMINADO
El trabajo ha terminado todos los procesos en todos los nodos con un código de salida de cero.

'''CF''' CONFIGURANDO
Al trabajo se le han asignado recursos, pero están esperando a que estén listos para su uso (por ejemplo, arrancando).

'''CG''' COMPLETANDO
El trabajo está en proceso de finalización. Algunos procesos en algunos nodos pueden estar aún activos.

'''DL''' FECHA LÍMITE
El trabajo ha finalizado en la fecha límite.

'''F''' FALLÓ
Trabajo finalizado con un código de salida distinto de cero u otra condición de fallo.

'''NF''' NODO_FAIL
Trabajo finalizado debido al fallo de uno o más nodos asignados.

'''OOM''' OUT_OF_MEMORY
El trabajo ha experimentado un error de memoria insuficiente.

'''PD''' PENDIENTE
El trabajo está pendiente de asignación de recursos.

'''PR''' PREEMPTED
El trabajo ha finalizado debido a una espera.

'''R''' EN MARCHA
El trabajo tiene actualmente una asignación.

'''RD''' RESV_DEL_HOLD
El trabajo se está reteniendo después de que se eliminara la reserva solicitada.

'''RF''' REQUEUE_FED
El trabajo está siendo solicitado por una federación.

'''RH''' REQUEUE_HOLD
Se está volviendo a poner en cola un trabajo retenido.

'''RQ''' REQUEUED
Se está poniendo en cola un trabajo que se está completando.

'''RS''' CAMBIO DE TAMAÑO
El trabajo está a punto de cambiar de tamaño.

'''RV''' REVOCADO
El trabajo se ha retirado del clúster debido a que otro clúster ha iniciado el trabajo.

'''SI''' SEÑALANDO
El trabajo está siendo señalizado.

'''SE''' SPECIAL_EXIT
El trabajo se ha puesto en cola en un estado especial. Este estado puede ser establecido por los usuarios, normalmente en EpilogSlurmctld, si el trabajo ha terminado con un valor de salida particular.

'''SO''' STAGE_OUT
El trabajo está preparando los archivos.

'''ST''' PARADO
El trabajo tiene una asignación, pero la ejecución se ha detenido con la señal SIGSTOP. Los CPUS han sido retenidos por este trabajo.

'''S''' SUSPENDIDO
El trabajo tiene una asignación, pero se ha suspendido la ejecución y se han liberado CPUs para otros trabajos.

'''TO''' TIMEOUT
El trabajo ha finalizado al alcanzar su límite de tiempo.

=== Cancelar un trabajo ===
Con scancel se puede cancelar un trabajo en ejecución
<pre>scancel <jobID> # Matar proceso <jobID>. (puede obtener el ID del job con "squeue")
scancel -u <username> # Matar proceso por usuario <username>.
</pre>
<pre>[prueba@leftraru1 ~]$ squeue -u prueba
JOBID PARTITION NAME USER ST TIME NODES NODELIST(REASON)
45594 slims TEST prueba R 0:59 20 cn[001-020]
</pre>
<pre>[prueba@leftraru1 ~]$ scancel 45594
[prueba@leftraru1 ~]$ squeue -u prueba
JOBID PARTITION NAME USER ST TIME NODES NODELIST(REASON)
[prueba@leftraru1 ~]$
</pre>

=== Ver estado de trabajos ===
Para revisar el detalle de las opciones de un trabajo: scontrol show job

<pre>
$ scontrol show job 10837561
JobId=10837561 JobName=TEST1
UserId=usuario(1000) GroupId=group(1000) MCS_label=N/A
Priority=1100 Nice=0 Account=account QOS=120
JobState=RUNNING Reason=None Dependency=(null)
Requeue=0 Restarts=0 BatchFlag=1 Reboot=0 ExitCode=0:0
DerivedExitCode=0:0
RunTime=19:03:08 TimeLimit=3-00:00:00 TimeMin=N/A
SubmitTime=2018-06-18T18:51:01 EligibleTime=2018-06-18T18:51:01
StartTime=2018-06-18T18:51:01 EndTime=2018-06-21T18:51:01 Deadline=N/A
PreemptTime=None SuspendTime=None SecsPreSuspend=0
Partition=slims AllocNode:Sid=leftraru2:5471
ReqNodeList=(null) ExcNodeList=(null)
NodeList=cn021
BatchHost=cn021
NumNodes=1 NumCPUs=1 NumTasks=1 CPUs/Task=1 ReqB:S:C:T=0:0:*:*
TRES=cpu=1,mem=1000M,node=1
Socks/Node=* NtasksPerN:B:S:C=1:0:*:* CoreSpec=*
Nodes=cn021 CPU_IDs=1 Mem=1000 GRES_IDX=
MinCPUsNode=1 MinMemoryCPU=1000M MinTmpDiskNode=0
Features=(null) DelayBoot=00:00:00
Gres=(null) Reservation=(null)
OverSubscribe=OK Contiguous=0 Licenses=matlab Network=(null)
Command=/home/usuario/script.sh
WorkDir=/home/usuario/
StdErr=/home/usuario/10837561_%x.err
StdIn=/dev/null
StdOut=/home/usuario/10837561_%x.out
Power=
BatchScript=
</pre>

Para ver el script asociado a un trabajo: scontrol write batch_script <job_id> -

<pre>
$ scontrol write batch_script 10837561 -
#!/bin/bash
#SBATCH -J nombre_del_trabajo
#SBATCH -p slims
#SBATCH -n 1
#SBATCH --ntasks-per-node=1
#SBATCH --mail-user=usaurio@correo.cl
#SBATCH --mail-type=ALL
#SBATCH -o nombre_del_trabajo%j_%x.out
#SBATCH -e nombre_del_trabajo%j_%x.err
#SBATCH --license=matlab

ml MATLAB/2017a

matlab -nodisplay -nosplash -nodesktop < programa.m
</pre>

== Ejecutando trabajos ==
Actualmente contamos con 2 metodos de enviar trabajos bajo SLURM: '''sbatch''' and '''srun'''. A veces puede ser ventajoso ejecutar un solo comando en el clúster como prueba o realizar rápidamente una operación con recursos adicionales. 'srun' permite a los usuarios hacer esto, y comparte las mismas variables que 'sbatch' . STDOUT y STDERR para un trabajo 'srun' serán redirigidos a la pantalla del usuario. Ctrl-C cancelará un trabajo srun. '''sbatch''' enviará un script de trabajo para que lo ejecute el clúster. Los scripts de trabajo bajo SLURM son simplemente scripts de shell (* .sh) con un conjunto de solicitudes de recursos en la parte superior del script.

Uso básico de srun:

<pre>
srun <algúnComando>
</pre>

Ejemplo de salida (ejecutando el comando "hostname" para saber en que nodo se está ejecutando):
<pre> $ srun hostname
cn003
</pre>

Para enviar un script de trabajo a SLURM:
<pre>sbatch nombreScript.sh</pre>

Example output:
<pre>$ sbatch test-job.sh
Submitted batch job 1169</pre>

=== Variables Slurm ===
Las variables en esta sección son obligatorias, y SLURM las determina para determinar dónde y cuándo se ejecutarán sus trabajos. Si no asigna un valor para estos, el planificador asignará a sus trabajos el valor predeterminado. Si no solicita específicamente recursos para un trabajo, se le asignará un conjunto de recursos predeterminados. Para obtener una lista de todas las variables disponibles, consulte la documentación de SLURM en http://slurm.schedmd.com/sbatch.html. Las variables de este artículo estaban cubiertas porque eran las más relevantes para los casos de uso típicos.

<table class="wikitable" style="width: 100%;">
<tr>
<td><b>Comando SLURM</b></td>
<td><b>Descripción</b>
</td></tr>
<tr>
<td>--mem-per-cpu=<megabytes></td>
<td>Memoria requerida para el trabajo por CPU (en MegaBytes). El valor predeterminado es 1024 MB.
</td></tr>
<tr>
<td>-p <partition>, --partition=<partition></td>
<td>Enviar un trabajo a una partición específica.
</td></tr>
<tr>
<td>-n, --ntasks=<cantidad de tareas></td>
<td>Número de tareas que serán asignadas para el trabajo.
</td></tr>
<tr>
<td>-c <cpus></td>
<td>Esta es la cantidad de CPU que necesita su trabajo. Tenga en cuenta que SLURM es relativamente generoso con las CPU, y el valor especificado aquí es el número "mínimo" de CPU que se asignará a su trabajo. Si hay CPU adicionales disponibles en un nodo más allá de lo solicitado, su trabajo recibirá esas CPU hasta que otros trabajos las necesiten. El valor predeterminado es 1 CPU. Intentar usar más CPU de las que se le asignaron dará como resultado que sus procesos adicionales se turnen en la misma CPU (ralentizando su trabajo).
</td></tr>
<tr>
<td>-J <name>, --jobname=<name></td>
<td>Especifica un nombre a tu trabajo.
</td></tr>
<tr>
<td>--mail-type=BEGIN,END,FAIL,ALL<b> and </b>--mail-user=<emailAddress></td>
<td>Enviar por correo electrónico cuando su trabajo comienza / termina / falla. Puede especificar varios valores para esto (separados por comas) si es necesario.
</td></tr>
<tr>
<td>-o <STDOUT_log>, --output=<STDOUT_log></td>
<td>Redirija la salida a los archivos de registro que especifique. Por defecto, ambos, STDOUT and STDERR son enviados a este archivo. Puedes especificar %j como parte del nombre de archivo de registro para indicar la ID del trabajo (como ejemplo, "#SBATCH -o ouptut_%j.o" redirigiría la salida a "output_123456.o").
</td></tr>
<tr>
<td>-e <STDERR_log>, --error=<STDERR_log></td>
<td>Redireccionar STDERR a un archivo separado. Funciona exactamente igual que "-o".
</td></tr>
<tr>
<td>-t <days-hours:minutes:seconds></td>
<td>Walltime para tu trabajo. La duración del Walltime es el tiempo que espera que su trabajo se ejecute.
</td></tr>
<tr>
<td>-a, --array=<índices></td>
<td>Envía una lista (arreglo) de trabajos identicos. Solo aplica para sbatch.
</td></tr></table>

Los scripts de trabajo especifican los recursos solicitados y otras consideraciones especiales con comentarios especiales "#SBATCH" en la parte superior de un script de trabajo. Aunque muchas de estas opciones son opcionales, las varibles que se ocupan de solicitudes de recursos (CPU, memoria y tiempo) son obligatorias. Todas las variables deben agregarse a sus scripts de la siguiente manera:

<pre>#SBATCH <variable></pre>
Para especificar un nombre al job, por ejemplo, debe agregar lo siguiente a su secuencia de comandos:

<pre>#SBATCH --job-name=nombreDeTrabajo</pre>

===Enviar un script===
<pre>
#!/bin/bash
#SBATCH -J example
#SBATCH -p general
#SBATCH -n 1
#SBATCH --output=example_%j.out
#SBATCH --error=example_%j.err
#SBATCH --mail-user=user@example.com
#SBATCH --mail-type=ALL
</pre>

Como debe comenzar un script en Linux:
<pre>
#!/bin/bash
</pre>

Nombre del trabajo:
<pre>
#SBATCH -J example
</pre>

Nombre la partición donde desea ejecutar el Job:
<pre>
#SBATCH -p general
</pre>

Número de tareas:
<pre>
#SBATCH -n 1
</pre>

Log de salida:
<pre>
#SBATCH -o example_%j.out
</pre>

Log de error:
<pre>
#SBATCH -e example_%j.err
</pre>

Correo para notificaciones:
<pre>
#SBATCH --mail-user=user@example.com
</pre>

Enviar correo en todos casos (verificar opciones arriba):
<pre>
#SBATCH --mail-type=ALL
</pre>

=== Programar tarea (uso de scrontab) ===
'''scrontab''' es una implementación del clásico planificador de tareas de linux '''crontab''' donde se guarda un listado de comandos a ejecutar en un tiempo determinado por el usuario.

Para acceder a scrontab utilice el siguiente comando:
<pre>
[prueba@leftraru1 ~]$ scrontab -e
</pre>

Esto le permitirá editar su archivo scrontab, asignando recursos como también el momento en que desea ejecutar su tarea. La estructura base a utilizar es la siguiente:
<pre>
#SCRON -J mi_tarea
#SCRON -p slims
#SCRON -n 1
#SCRON -c 1
#SCRON --mem-per-cpu=2300
#SCRON --mail-user=foo@bar.com
#SCRON --mail-type=ALL
#SCRON -o mi_tarea_%j.out
#SCRON -e mi_tarea_%j.err
# Example of job definition:
# .---------------- minute (0 - 59)
# | .------------- hour (0 - 23)
# | | .---------- day of month (1 - 31)
# | | | .------- month (1 - 12) OR jan,feb,mar,apr ...
# | | | | .---- day of week (0 - 6) (Sunday=0 or 7) OR sun,mon,tue,wed,thu,fri,sat
# | | | | |
# * * * * * command to be executed
</pre>

* '''minute''' - Corresponde al minuto en que se va a ejecutar el script, valor de 0 a 59.
* '''hour''' - Hora de ejecución, formato 24 horas, valor de 0 a 23, donde 0 son las 12:00 AM.
* '''day of month''' - Día del mes, la tarea se puede ejecutar cada x día, valor de 1 a 31.
* '''month''' - La tarea se puede ejecutar cada x mes, valor de 1 a 12.
* '''day of week''' - Día de la semana, valor de 0 a 6, donde 0 es Domingo.
* '''command to be executed''' - Script a ejecutar por el usuario.

Ejemplo envío de trabajo slurm:

Para la asignación de recursos, utilizaremos la directriz '''#SCRON''', que utiliza los mismos parámetros usados por '''#SBATCH'''.

Luego de asignar los recursos debemos especificar el tiempo, en este caso la tarea será ejecutada todos los días cada 20 minutos, luego debemos indicar el script enviado por el usuario y guardamos los cambios en el archivo.

<pre>
*/20 * * * * /home/prueba/ejemplo/script.sh
</pre>

Es importante destacar que el script a lanzar '''/home/prueba/ejemplo/script.sh''' debe tener permisos de ejecución.

Para revisar el listado de tareas existentes en nuestro scrontab, ejecutamos el comando:
<pre>
[prueba@leftraru1 ~]$ scrontab -l
*/20 * * * * /home/prueba/ejemplo/script.sh
</pre>

Para borrar el contenido de nuestro scrontab:
<pre>
[prueba@leftraru1 ~]$ scrontab -r
</pre>

'''Información a considerar:'''

* Generar archivos de salida correctamente
** Para que el archivo error y out de tu script se generen en el directorio solicitado, ejemplo, /home/prueba/ejemplo/ en tu script debe estar presente el comando cd “/home/prueba/ejemplo”, esto hará que scrontab se posicione dentro del directorio de salida.
* Es distinto el tiempo de programar el envío de una tarea (scrontab) a que una tarea inicie en el clúster (running), ya que esto dependerá de los recursos libres que existan en ese momento en el clúster.
* Para revisar las tareas programadas debe ejecutar en cualquier nodo login el comando '''scrontab -l''' o revisar con el comando '''squeue''':

<pre>
[prueba@leftraru1 ~]$ squeue
24293471 slims /home/eg prueba PD 0:00 1 (BeginTime)
</pre>

== Checkpointing ==
Es la acción de guardar el estado de un proceso en ejecución en un archivo de imagen de punto de control. Este proceso se puede reiniciar más tarde desde el archivo del punto de control, continuando la ejecución desde donde se detuvo, en la misma computadora o en una diferente.

=== ¿Por qué utilizarlo? ===
* Permite ejecuciones de tarea largas que superen el tiempo de ejecución permitido en el cluster (30 días)
* Estar preparados ante fallas del sistema que nos puedan hacer perder resultados de nuestras simulaciones

=== Utilización ===
Lo primero que debemos hacer en nuestro script es cargar el módulo de Mana:
<pre>
ml mana/3.0.0
</pre>
Este módulo provee 3 ejecutables que necesitaremos:

* '''mana_coordinator:''' Coordina los checkpoints entre los distintos procesos
* '''mana_launch:''' Inicia un proceso con checkpoint
* '''mana_restart:''' Reinicia la ejecución desde una imagen del checkpoint

Necesitaremos 2 scripts para trabajar con checkpoints: Inicio y reinicio

=== Script de inicio (inicio.sh) ===
<pre>
#!/bin/bash
##---------------SLURM Parameters - NLHPC ----------------
#SBATCH -J Testcheckpoint
#SBATCH -p general
#SBATCH -n 44
#SBATCH --ntasks-per-node=44
#SBATCH --mem-per-cpu=4363
#SBATCH --mail-user=test@nlhpc.cl
#SBATCH --mail-type=ALL
#SBATCH -o Testcheckpoint_%j.out
#SBATCH -e Testcheckpoint_%j.err

# ----------------Modules----------------------------
ml mana/3.0.0
# ----------------Command--------------------------
#Checkpointing cada 1 hora
mana_cooridinator -i3600
#Ejecutamos nuestra tarea con checkpointing
srun mana_launch ./ejecutable
</pre>

=== Script de reinicio (reinicio.sh) ===
<pre>
#!/bin/bash
##---------------SLURM Parameters - NLHPC ----------------
#SBATCH -J Testcheckpoint
#SBATCH -p general
#SBATCH -n 44
#SBATCH --ntasks-per-node=44
#SBATCH --mem-per-cpu=4363
#SBATCH --mail-user=test@nlhpc.cl
#SBATCH --mail-type=ALL
#SBATCH -o Testcheckpoint_%j.out
#SBATCH -e Testcheckpoint_%j.err

# ----------------Modules----------------------------
ml mana/3.0.0
# ----------------Command--------------------------
#Checkpointing cada 1 hora
mana_cooridinator -i3600
#Reiniciar nuestra tarea desde los archivos de checkpoint
srun mana_restart
</pre>

Para correr estos scripts se puede hacer utilizando la funcionalidad de dependencias de SLURM:
<pre>
[test@leftraru2 test]$ sbatch inicio.sh
Submitted batch job 23574685
[test@leftraru2 test]$ sbatch --dependency=afterok:23574685 reinicio.sh
</pre>

== Trabajos ==
=== Trabajos paralelos ===
Muchos de los trabajos que se ejecutan en un clúster de producción implicarán más de un procesador (CPU, núcleo). Dichos trabajos paralelos deben solicitar la cantidad de recursos necesarios a través de opciones adicionales. Los más comunes son:

Para diferentes tipos de trabajos paralelos, se especificarán diferentes opciones. Los trabajos paralelos más comunes son trabajos de MPI (memoria distribuida), trabajos de subprocesos múltiples (memoria compartida) y los llamados híbridos que son una combinación de los dos. Analicemos por separado con un n ejemplo para cada uno.

=== Ejecución de programas con MPI ===
MPI (interfaz de paso de mensajes) es la API de comunicación estándar para trabajos paralelos de memoria distribuida capaz de implementarse en un clúster. Para programar dicho trabajo, es necesario especificar la cantidad de nodos del clúster que se utilizarán y la cantidad de procesos (tareas) que se ejecutarán en cada nodo.

El siguiente es un ejemplo de ejecución de un programa compilado con Open MPI:

#!/bin/bash
#SBATCH -J example_mpi
#SBATCH -p general
#SBATCH -n 264
#SBATCH --ntasks-per-node=44
#SBATCH --output=example_%j.out
#SBATCH --error=example_%j.err
#SBATCH --mail-user=user@example.com
#SBATCH --mail-type=ALL

srun ./mpi_test
A continuacion se explica línea por líneael script.

Como empieza un shell script en Linux:
<pre>
#!/bin/bash
</pre>

Nombre del Job:
<pre>
#SBATCH -J example_mpi
</pre>

Nombre la particion donde se desea ejecutar el trabajo:
<pre>
#SBATCH -p general
</pre>

Número de tareas. Debe de ser un número múltiplo del número de CPUs máximo que tenga un node de la partición donde se lanza:
<pre>
#SBATCH -n 264
</pre>

Con esto se fuerza a que se lancen 44 tareas MPI en cada uno de los nodos, ocupando de este modo nodos completos. En este caso 6 nodos completos:
<pre>
#SBATCH --ntasks-per-node=44
</pre>

Log de salida:
<pre>
#SBATCH -o example_%j.out
</pre>

Log de error:
<pre>
#SBATCH -e example_%j.err
</pre>

Correo para notificaciones:
<pre>
#SBATCH --mail-user=user@example.com
</pre>

Envía correo en todos los casos:
<pre>
#SBATCH --mail-type=ALL
</pre>

Programa para ejecutar:
<pre>
srun ./mpi_test
</pre>

'''Nota''': no se carga específicamente el módulo "mpi" ya que se carga siempre por defecto.

Para enviarlo al clúster debe ejecutar el comando: ''sbatch script.sh''. El ejemplo anterior ejecutará una tarea OpenMPI con 264 procesos reservando 264 cores para ello.

=== Trabajos multiproceso OpenMP ===
Los trabajos paralelos diseñados para ejecutarse en un sistema multi-core (shared-memory) suelen ser "multi-threaded". La programación de un job de este tipo requiere especificar el número de núcleos que se utilizan para acomodar los subprocesos.

OpenMP es el conjunto común de variables de compilación para facilitar el desarrollo de programas multi-threaded. Un script típico de SLURM para un programa de este tipo se ve así:
<pre>
#!/bin/bash
#SBATCH -J OMPtest
#SBATCH -p general
#SBATCH -n 1
#SBATCH -c 44
#SBATCH --ntasks-per-node=44
#SBATCH --mem-per-cpu=1024
#SBATCH -o example_%j.out
#SBATCH -e example_%j.err
#SBATCH --mail-user=user@example.com
#SBATCH --mail-type=ALL

OMP_NUM_THREADS=$SLURM_CPUS_PER_TASK time ./omp-program
</pre>

Como debe comenzar un script en Linux:
<pre>
#!/bin/bash
</pre>

Nombre del Job:
<pre>
#SBATCH -J OMPtest
</pre>

Nombre la particion donde desea ejecutar el Job:
<pre>
#SBATCH -p general
</pre>

Número de trabajos:
<pre>
#SBATCH -n 1
</pre>

Número de tareas:
<pre>
#SBATCH -c 44
</pre>

Con esto se fuerza a que se agrupen las 44 tareas en un nodo (en OpenMP no hay comunicación entre nodos, por lo que todas las tareas deben estar en el mismo nodo o no funcionaría):
<pre>
#SBATCH --ntasks-per-node=44
</pre>

Memoria por core (MBytes):
<pre>
#SBATCH --mem-per-cpu=1024
</pre>

Log de salida:
<pre>
#SBATCH -o example_%j.out
</pre>

Log de error:
<pre>
#SBATCH -e example_%j.err
</pre>

Correo para notificaciones:
<pre>
#SBATCH --mail-user=user@example.com
</pre>

Enviar correo en todos los casos:
<pre>
#SBATCH --mail-type=ALL
</pre>

Programa para ejecutar:
<pre>
OMP_NUM_THREADS=$SLURM_CPUS_PER_TASK time ./omp-program
</pre>

Cuando se utiliza un programa OpenMP, el número de subprocesos (y, por lo tanto, el número requerido de núcleos) se especifica a través de la variable de entorno OMP_NUM_THREADS que, por lo tanto, aparece en el script frente a la llamada al programa. Lo estamos configurando en la variable interna SLURM_CPUS_PER_TASK que se establece a través de la opción "-c" (a 44 en nuestro ejemplo, que sería el número total de cores de un nodo de la partición "general").

La opción "-n" se mantiene en 1 para indicar un único trabajo principal que tiene 44 tareas. Para asegurarnos que todas las tareas se ejecutan en el mismo nodo, se añade la opción "--ntasks-per-node" con el máximo número de cores que tiene un nodo de la partición donde se está lanzando el trabajo.

=== Ejecución de tareas en GPUs ===
<pre>
#!/bin/bash
#SBATCH -J ejemplo_gpus
#SBATCH -p v100
#SBATCH -n 1
#SBATCH -o ejemplo_%j.out
#SBATCH -e ejemplo_%j.err
#SBATCH --mail-user=correo@gmail.com
#SBATCH --mail-type=ALL
#SBATCH --mem-per-cpu=4300
#SBATCH --gres=gpu:1

./programa
</pre>

Inicio de un bash script en Linux:
<pre>
#!/bin/bash
</pre>

Nombre del trabajo:
<pre>
#SBATCH -J ejemplo_gpus
</pre>

Nombre la partición donde se ejecuta el trabajo:
<pre>
#SBATCH --partition=v100
</pre>

Número de tareas:
<pre>
#SBATCH -n 1
</pre>

Log de salida:
<pre>
#SBATCH -o ejemplo_%j.out
</pre>

Log de error:
<pre>
#SBATCH -e ejemplo_%j.err
</pre>

Correo para notificaciones:
<pre>
#SBATCH --mail-user=user@example.com
</pre>

Enviar correo en todos los casos:
<pre>
#SBATCH --mail-type=ALL
</pre>

Memoria por CPU (MB):
<pre>
#SBATCH --mem-per-cpu=4365
</pre>

Cantidad utilizada de GPUs. El parámetro gpu:1 indica la cantidad de tarjetas a utilizar (cada nodo tiene 2 GPUs):
<pre>
#SBATCH --gres=gpu:1
</pre>

Programa para ejecutar:
<pre>
./programa
</pre>

=== Job Arrays ===
Cuando se ejecutan cientos o miles de simulaciones que utilizan la misma cantidad de recursos, puede ser una ventaja ejecutar estas simulaciones como un "job array". Los job array le permiten enviar miles de dichos trabajos (llamados "job steps") con un solo script. A cada simulación se le asignará un valor único para la variable de entorno SLURM_ARRAY_TASK_ID. Puede usar esta variable para leer parámetros para pasos individuales de una línea dada de un archivo.

=== Caso de uso de un Script Job Array (Gaussian) ===
Tenemos usuarios que actualmente envían varias simulaciones al clúster que son similares en cuanto al uso de recursos, pero, la diferencia es que solo cambia la entrada que le entregan al programa. Para esta situación, recomendamos hacer uso de un script Job Array.

En este ejemplo crearemos un script job array para el software Gaussian, el cual, realizará 63 simulaciones, cada una de estas utilizará 8 cores y podrá alcanzar un uso máximo de 8 Gb de memoria ram. Para este caso utilizaremos la partición slims donde cada nodo tiene 46 Gb de memoria ram y 20 cores.

Script:
<pre>
#!/bin/bash
# ----------------SLURM Parameters----------------
#SBATCH -J prueba
#SBATCH -p slims
#SBATCH -n 1
#SBATCH -c 8
#SBATCH --mem-per-cpu=1000
#SBATCH --mail-user=prueba@nlhpc.cl
#SBATCH --mail-type=ALL
#SBATCH --array=1-63
#SBATCH -o prueba_%A_%a.out
#SBATCH -e prueba_%A_%a.err
#-----------------Toolchain---------------------------
ml purge
ml intel/2019b
# ----------------Módulos-----------------------------
ml g16/B.01
# ----------------Comandos--------------------------
file=$(ls Child_10_*.com | sed -n ${SLURM_ARRAY_TASK_ID}p)
srun g16 $file
</pre>

'''
Descripción de comandos utilizados en script:'''

Inicio de un bash script en Linux:
<pre>
#!/bin/bash
</pre>

Nombre de la simulación:
<pre>
#SBATCH -J prueba
</pre>

Nombre la partición donde se ejecuta la simulación:
<pre>
#SBATCH -p slims
</pre>

Número de tareas (1 tarea va a ejecutar 63 simulaciones):
<pre>
#SBATCH -n 1
</pre>

Core’s por tareas (cada tarea utilizará un máximo 8 cores):
<pre>
#SBATCH -c 8
</pre>

Memoria ram por cpu (cada tarea utilizará un máximo 8 Gb de ram):
<pre>
#SBATCH –mem-per-cpu=1000
</pre>

Correo para activar el envío de notificaciones:
<pre>
#SBATCH --mail-user=prueba@nlhpc.cl
</pre>

Permitir envío de notificaciones:
<pre>
#SBATCH --mail-type=ALL
</pre>

Se generan 63 simulaciones diferentes:
<pre>
#SBATCH --array=1-63
</pre>

Log de salida: (ejemplo: prueba_18455017_1.out)

* %A corresponde al Job ID de nuestra tarea que le asignará Slurm → 18455017.
* %a corresponde a la simulación X de nuestra tarea que le asignará Slurm → 1.
<pre>
#SBATCH -o prueba_%A_%a.out
</pre>

Log de errores: (ejemplo: prueba_18455017_1.err)

* %A corresponde al Job ID de nuestra tarea que le asignará Slurm → 18455017.
* %a corresponde a la simulación X de nuestra tarea que le asignará Slurm → 1.

<pre>
#SBATCH -e prueba_%A_%a.err
Toolchain: en este apartado, limpiaremos nuestro entorno de software no deseados y luego escogemos la herramienta informática con la cual está compilado el software Gaussian (nosotros utilizamos el compilador Intel/2019b).

#-----------------Toolchain---------------------------
ml purge
ml intel/2019b
Módulos: cargamos el software Gaussian versión 16/B.0.

# ----------------Módulos-----------------------------
ml g16/B.01
Comandos: aquí definimos los comandos a ejecutar.

# ----------------Comandos--------------------------
file=$(ls Child_10_*.com | sed -n ${SLURM_ARRAY_TASK_ID}p)
srun g16 $file
</pre>
file= variable que va a listar los archivos de entrada que comiencen por Child_10_ y terminen en .com

[[Archivo:Child.png|no]]

sed -n ${SLURM_ARRAY_TASK_ID}p) ← Sed imprimirá las líneas de cada archivo de entrada y la variable $SLURM_ARRAY_TASK_ID asumirá estas entradas como matriz de simulación en nuestro job array, en este ejemplo tenemos 63 archivos de entrada.

Para más detalles sobre los archivos stdin, stdout y stderr de una simulación % A será reemplazado por el valor de SLURM_ARRAY_JOB_ID que es el Job ID de nuestra tarea y %a será reemplazado por el valor de SLURM_ARRAY_TASK_ID que corresponde a la simulación X de nuestra tarea.

Srun g16 $file: ejecutará el comando gaussian g16 interpretando la variable $file en los nodos de cómputo asignados.

Enviar el script:
<pre>
[prueba@leftraru1 ~]$ sbatch prueba.sh
</pre>

=== Ejecución de una tarea que ocupa mucha RAM por CPU ===
Debemos tener en cuenta que la RAM que SLURM reserva por defecto son 1000 MB. Un típico error de cancelación de tarea por falta de memoria es el siguiente:
<pre>
/tmp/slurmd/job136839939/slurm_script: line 15: 23547 Killed ./programa.sh
slurmstepd: error: Detected 1 oom-kill event(s) in step 136839939.batch cgroup. Some of your processes
may have been killed by the cgroup out-of-memory handler.
</pre>

Si su tarea ocupa más de la memoria por defecto, puede utilizar el siguiente parámetro:
<pre>
#SBATCH --mem-per-cpu=2300 #Máxima RAM por CPU
</pre>
Esto hará que SLURM reserve más RAM por CPU para sus tareas.

Tenga en cuenta que nuestros nodos tienen 46 GB de memoria RAM (Partición slims), 187 GB (Partición general) y 765 GB (Partición largemem) por nodo. [https://wiki.nlhpc.cl/Hardware_Disponible Más información].

Otra forma de reservar memoria es utilizando el siguiente parámetro:

<pre>
#SBATCH --mem=2300
</pre>
En este caso SLURM realizará una reserva de memoria de 2300 MB pero por la totalidad del trabajo.

Los parámetros anteriores al igual que el número de CPUs que se van a usar, hay que afinarlos lo mejor posible. Para ello lo que se puede hacer es hacer pruebas en los nodos logins, sin lanzar en las colas, y así estudiar el uso de RAM y CPU por parte de sus procesos.

=== Ejecución de una tarea con Dependencias ===
Las dependencias de trabajos se utilizan para aplazar el inicio de un trabajo hasta que se satisfagan las dependencias especificadas. Se especifican con la opción --dependency en el siguiente formato:
<pre>
sbatch --dependency=<type:job_id[:job_id][,type:job_id[:job_id]]> ...
</pre>
Los tipos de dependencias son las siguientes:

* '''after''':jobid[:jobid...] - el trabajo puede empezar después de que los trabajos especificados comiencen
* '''afterany''':jobid[:jobid...] - el trabajo puede empezar después de que los trabajos especificados terminen
* '''afternotok''':jobid[:jobid...] - el trabajo puede empezar después que los trabajos especificados terminan fallidamente
* '''afterok''':jobid[:jobid...] - el trabajo puede empezar después que los trabajos especificados terminan exitósamente

La manera más simple de usar una dependencia del tipo afterok:
<pre>
[prueba@leftraru1 ~]$ sbatch job1.sh
Submitted batch job 21363626
[prueba@leftraru1 ~]$ sbatch --dependency=afterok:21363626 job2.sh
</pre>

Ahora cuando job1.sh termine correctamente, el job2.sh entrará en ejecución. Si job1.sh termina fallidamente, job2.sh no entrará en ejecución nunca pero sí quedará en cola (debe cancelarse manualmente el trabajo).

== Prioridad de tarea ==
Cómo ver la prioridad del trabajo. Los factores que determinan la prioridad del trabajo, incluyendo la fórmula y pesos.

=== Factores que determinan prioridad de tarea ===
<table class="wikitable" style="width: 60%;">
<tr>
<td><b>Comando SLURM</b></td>
<td><b>Descripción</b>
</td></tr>
<tr>
<td>Edad</td>
<td>la cantidad de tiempo que el trabajo ha estado esperando en la cola.
</td></tr>
<tr>
<td>Tamaño de la tarea</td>
<td>número de nodos solicitados por el trabajo.
</td></tr>
<tr>
<td>Partición</td>
<td>prioridad para una partición determinada.
</td></tr>
<tr>
<td>Prioridad Baja</td>
<td>Mientras más tareas se ejecuten en el cluster, menor será la prioridad.
</td></tr>
<tr>
<td>Prioridad Alta</td>
<td>Mientras menos tareas se ejecuten en el clúster, más alta es la prioridad.
</td></tr></table>

== Prioridad de tarea ==
Cómo ver la prioridad del trabajo. Los factores que determinan la prioridad del trabajo, incluyendo la fórmula y pesos.

=== Factores que determinan prioridad de tarea ===
* Edad - la cantidad de tiempo que el trabajo ha estado esperando en la cola
* Tamaño Oficio - número de nodos solicitados por el trabajo
* Partición - prioridad para una partición determinada
* Contribución de prioridades basada en los recursos informáticos utilizados por los miembros de un grupo de investigación en los últimos 30 días - Fairshare.
* Mientras más tareas se ejecuten en el cluster, menor será la prioridad.
* Mientras menos tareas se ejecuten en el clúster, más alta es la prioridad.
Fórmula Prioridad de tarea
<pre>
Job_priority =
(PriorityWeightAge) * (age_factor) +
(PriorityWeightFairshare) * (fair-share_factor) +
(PriorityWeightJobSize) * (job_size_factor) +
(PriorityWeightPartition) * (partition_factor) +
(PriorityWeightQOS) * (QOS_factor)
</pre>

== Visualización de sus Tareas ==
Si Ud. necesita visualizar información acerca de sus tareas de forma interactiva, puede utilizar el comando smap:

smap -i 3

[[Archivo:Smap.png|no|700px]]

De esta forma, tendrá una actualización cada 3 segundos de sus tareas en ejecución incluyendo los nodos en los cuales se encuentran ejecutándose.

== Bibliografía ==
[http://slurm.schedmd.com/documentation.html Manual Oficial de Slurm]

[https://slurm.schedmd.com/scrontab.html Documentación scrontab]

Hardware Disponible

2024-04-26T20:28:45Z

Jmorales:

El NLHPC cuenta actualmente con los siguientes recursos computacionales, distribuidos en varias particiones [https://wiki.nlhpc.cl/SISTEMA_GESTOR_DE_RECURSOS SLURM]:

<table border="0" style="background:#ffffff" align="top" class="sortable wikitable">
<caption align="center" style="background:DarkSlateBlue; color:white"><big><b>Partición general</b></big>
</caption>
<tr>
<th width="60 px" style="background:Lavender; color:Black">Nodo
</th>
<th width="80 px" style="background:Lavender; color:Black">Modelo
</th>
<th width="80 px" style="background:Lavender; color:Black">Cantidad
</th>
<th width="100 px" style="background:Lavender; color:Black">Procesador
</th>
<th width="120 px" style="background:Lavender; color:Black">RAM
</th>
<th width="140 px" style="background:Lavender; color:Black">Infiniband
</th></tr>
<tr>
<td>sn[001-048]</td>
<td>Dell PowerEdge C6420</td>
<td>48</td>
<td>2 x Intel Xeon Gold 6152 CPU @ 2.10GHz, 22 cores C./U.</td>
<td>187 GB</td>
<td>Infiniband FDR
</td></tr>
</table>

<table border="0" style="background:#ffffff" align="top" class="sortable wikitable">
<caption align="center" style="background:DarkSlateBlue; color:white"><big><b>Partición largemem</b></big>
</caption>
<tr>
<th width="60 px" style="background:Lavender; color:Black">Nodo
</th>
<th width="80 px" style="background:Lavender; color:Black">Modelo
</th>
<th width="80 px" style="background:Lavender; color:Black">Cantidad
</th>
<th width="100 px" style="background:Lavender; color:Black">Procesador
</th>
<th width="120 px" style="background:Lavender; color:Black">RAM
</th>
<th width="140 px" style="background:Lavender; color:Black">Infiniband
</th></tr>
<tr>
<td>fn[001-009]</td>
<td>Dell PowerEdge R640</td>
<td>9</td>
<td>2 x Intel Xeon Gold 6152 CPU @ 2.10GHz, 22 cores C./U.</td>
<td>765 GB</td>
<td>Infiniband FDR
</td></tr>
</table>

<table border="0" style="background:#ffffff" align="top" class="sortable wikitable">
<caption align="center" style="background:DarkSlateBlue; color:white"><big><b>Partición v100</b></big>
</caption>
<tr>
<th width="60 px" style="background:Lavender; color:Black">Nodo
</th>
<th width="80 px" style="background:Lavender; color:Black">Modelo
</th>
<th width="80 px" style="background:Lavender; color:Black">Cantidad
</th>
<th width="100 px" style="background:Lavender; color:Black">Procesador
</th>
<th width="160 px" style="background:Lavender; color:Black">GPU
</th>
<th width="120 px" style="background:Lavender; color:Black">RAM
</th>
<th width="140 px" style="background:Lavender; color:Black">Infiniband
</th></tr>
<tr>
<td>gn[001-002]</td>
<td>Dell PowerEdge R740</td>
<td>2</td>
<td>2 x Intel Xeon Gold 6152 CPU @ 2.10GHz, 22 cores C./U.</td>
<td>2x NVIDIA Tesla V100 C/U.</td>
<td>187 GB</td>
<td>Infiniband FDR
</td></tr>
</table>

<table border="0" style="background:#ffffff" align="top" class="sortable wikitable">
<caption align="center" style="background:DarkSlateBlue; color:white"><big><b>Partición mi100</b></big>
</caption>
<tr>
<th width="60 px" style="background:Lavender; color:Black">Nodo
</th>
<th width="80 px" style="background:Lavender; color:Black">Modelo
</th>
<th width="80 px" style="background:Lavender; color:Black">Cantidad
</th>
<th width="100 px" style="background:Lavender; color:Black">Procesador
</th>
<th width="160 px" style="background:Lavender; color:Black">GPU
</th>
<th width="120 px" style="background:Lavender; color:Black">RAM
</th>
<th width="140 px" style="background:Lavender; color:Black">Infiniband
</th></tr>
<tr>
<td>gn003</td>
<td>Dell PowerEdge R7525</td>
<td>1</td>
<td>2 x AMD EPYC 7713 64-Core Processor CPU @ 2.0GHz, 64 cores C./U.</td>
<td>2x Instinct MI100 C/U.</td>
<td>502 GB</td>
<td>Infiniband FDR
</td></tr>
</table>

<table border="0" style="background:#ffffff" align="top" class="sortable wikitable">
<caption align="center" style="background:DarkSlateBlue; color:white"><big><b>Partición MI210</b></big>
</caption>
<tr>
<th width="60 px" style="background:Lavender; color:Black">Nodo
</th>
<th width="80 px" style="background:Lavender; color:Black">Modelo
</th>
<th width="80 px" style="background:Lavender; color:Black">Cantidad
</th>
<th width="100 px" style="background:Lavender; color:Black">Procesador
</th>
<th width="120 px" style="background:Lavender; color:Black">RAM
</th>
<th width="140 px" style="background:Lavender; color:Black">Infiniband
</th></tr>
<tr>
<td>gn00[4-5]</td>
<td>Lenovo ThinkSystem SR675 V3</td>
<td>2</td>
<td>2 x AMD EPYC 9224 @ 2.5GHz, 24 cores c/u.</td>
<td>1.457 GB</td>
<td>Infiniband NDR
</td></tr>
</table>

<table border="0" style="background:#ffffff" align="top" class="sortable wikitable">
<caption align="center" style="background:DarkSlateBlue; color:white"><big><b>Partición main</b></big>
</caption>
<tr>
<th width="60 px" style="background:Lavender; color:Black">Nodo
</th>
<th width="80 px" style="background:Lavender; color:Black">Modelo
</th>
<th width="80 px" style="background:Lavender; color:Black">Cantidad
</th>
<th width="100 px" style="background:Lavender; color:Black">Procesador
</th>
<th width="120 px" style="background:Lavender; color:Black">RAM
</th>
<th width="140 px" style="background:Lavender; color:Black">Infiniband
</th></tr>
<tr>
<td>mn00[1-27]</td>
<td>Lenovo ThinkSystem SR645 V3</td>
<td>27</td>
<td>2 x AMD EPYC 9754 @ 2,25GHz, 128 cores c/u.</td>
<td>768 GB</td>
<td>Infiniband NDR
</td></tr>
</table>

La partición debug es para uso exclusivo de pruebas que duren hasta 30 minutos. Cualquier trabajo que supere ese tiempo es cancelado automáticamente.

<table border="0" style="background:#ffffff" align="top" class="sortable wikitable">
<caption align="center" style="background:DarkSlateBlue; color:white"><big><b>Partición debug</b></big>
</caption>
<tr>
<th width="60 px" style="background:Lavender; color:Black">Nodo
</th>
<th width="80 px" style="background:Lavender; color:Black">Modelo
</th>
<th width="80 px" style="background:Lavender; color:Black">Cantidad
</th>
<th width="100 px" style="background:Lavender; color:Black">Procesador
</th>
<th width="120 px" style="background:Lavender; color:Black">RAM
</th>
<th width="140 px" style="background:Lavender; color:Black">Infiniband
</th></tr>
<tr>
<td>leftraru[1-2]</td>
<td>Lenovo ThinkSystem SR645 V3</td>
<td>2</td>
<td>2 x AMD EPYC 9224 @ 2,5GHz, 24 cores c/u.</td>
<td>768 GB</td>
<td>Infiniband NDR
</td></tr>
</table>

La capacidad total de Guacolda-Leftraru Epu al día de hoy es de 9.956 CPU cores, 95.232 GPU cores y 479 TFlops.

Para más información respecto a la utilización del sistema gestor de colas y uso de recursos vea el siguiente enlace: [https://wiki.nlhpc.cl/SISTEMA_GESTOR_DE_RECURSOS SLURM]

Hardware Disponible

2024-04-26T20:26:51Z

Jmorales:

El NLHPC cuenta actualmente con los siguientes recursos computacionales, distribuidos en varias particiones [https://wiki.nlhpc.cl/SISTEMA_GESTOR_DE_RECURSOS SLURM]:

<table border="0" style="background:#ffffff" align="top" class="sortable wikitable">
<caption align="center" style="background:DarkSlateBlue; color:white"><big><b>Partición general</b></big>
</caption>
<tr>
<th width="60 px" style="background:Lavender; color:Black">Nodo
</th>
<th width="80 px" style="background:Lavender; color:Black">Modelo
</th>
<th width="80 px" style="background:Lavender; color:Black">Cantidad
</th>
<th width="100 px" style="background:Lavender; color:Black">Procesador
</th>
<th width="120 px" style="background:Lavender; color:Black">RAM
</th>
<th width="140 px" style="background:Lavender; color:Black">Infiniband
</th></tr>
<tr>
<td>sn[001-048]</td>
<td>Dell PowerEdge C6420</td>
<td>48</td>
<td>2 x Intel Xeon Gold 6152 CPU @ 2.10GHz, 22 cores C./U.</td>
<td>187 GB</td>
<td>Infiniband FDR
</td></tr>
</table>

<table border="0" style="background:#ffffff" align="top" class="sortable wikitable">
<caption align="center" style="background:DarkSlateBlue; color:white"><big><b>Partición largemem</b></big>
</caption>
<tr>
<th width="60 px" style="background:Lavender; color:Black">Nodo
</th>
<th width="80 px" style="background:Lavender; color:Black">Modelo
</th>
<th width="80 px" style="background:Lavender; color:Black">Cantidad
</th>
<th width="100 px" style="background:Lavender; color:Black">Procesador
</th>
<th width="120 px" style="background:Lavender; color:Black">RAM
</th>
<th width="140 px" style="background:Lavender; color:Black">Infiniband
</th></tr>
<tr>
<td>fn[001-009]</td>
<td>Dell PowerEdge R640</td>
<td>9</td>
<td>2 x Intel Xeon Gold 6152 CPU @ 2.10GHz, 22 cores C./U.</td>
<td>765 GB</td>
<td>Infiniband FDR
</td></tr>
</table>

<table border="0" style="background:#ffffff" align="top" class="sortable wikitable">
<caption align="center" style="background:DarkSlateBlue; color:white"><big><b>Partición v100</b></big>
</caption>
<tr>
<th width="60 px" style="background:Lavender; color:Black">Nodo
</th>
<th width="80 px" style="background:Lavender; color:Black">Modelo
</th>
<th width="80 px" style="background:Lavender; color:Black">Cantidad
</th>
<th width="100 px" style="background:Lavender; color:Black">Procesador
</th>
<th width="160 px" style="background:Lavender; color:Black">GPU
</th>
<th width="120 px" style="background:Lavender; color:Black">RAM
</th>
<th width="140 px" style="background:Lavender; color:Black">Infiniband
</th></tr>
<tr>
<td>gn[001-002]</td>
<td>Dell PowerEdge R740</td>
<td>2</td>
<td>2 x Intel Xeon Gold 6152 CPU @ 2.10GHz, 22 cores C./U.</td>
<td>2x NVIDIA Tesla V100 C/U.</td>
<td>187 GB</td>
<td>Infiniband FDR
</td></tr>
</table>

<table border="0" style="background:#ffffff" align="top" class="sortable wikitable">
<caption align="center" style="background:DarkSlateBlue; color:white"><big><b>Partición mi100</b></big>
</caption>
<tr>
<th width="60 px" style="background:Lavender; color:Black">Nodo
</th>
<th width="80 px" style="background:Lavender; color:Black">Modelo
</th>
<th width="80 px" style="background:Lavender; color:Black">Cantidad
</th>
<th width="100 px" style="background:Lavender; color:Black">Procesador
</th>
<th width="160 px" style="background:Lavender; color:Black">GPU
</th>
<th width="120 px" style="background:Lavender; color:Black">RAM
</th>
<th width="140 px" style="background:Lavender; color:Black">Infiniband
</th></tr>
<tr>
<td>gn003</td>
<td>Dell PowerEdge R7525</td>
<td>1</td>
<td>2 x AMD EPYC 7713 64-Core Processor CPU @ 2.0GHz, 64 cores C./U.</td>
<td>2x Instinct MI100 C/U.</td>
<td>502 GB</td>
<td>Infiniband FDR
</td></tr>
</table>

<table border="0" style="background:#ffffff" align="top" class="sortable wikitable">
<caption align="center" style="background:DarkSlateBlue; color:white"><big><b>Partición MI210</b></big>
</caption>
<tr>
<th width="60 px" style="background:Lavender; color:Black">Nodo
</th>
<th width="80 px" style="background:Lavender; color:Black">Modelo
</th>
<th width="80 px" style="background:Lavender; color:Black">Cantidad
</th>
<th width="100 px" style="background:Lavender; color:Black">Procesador
</th>
<th width="120 px" style="background:Lavender; color:Black">RAM
</th>
<th width="140 px" style="background:Lavender; color:Black">Infiniband
</th></tr>
<tr>
<td>gn00[4-5]</td>
<td>Lenovo ThinkSystem SR675 V3</td>
<td>2</td>
<td>2 x AMD EPYC 9224 @ 2.5GHz, 24 cores c/u.</td>
<td>1457 GB</td>
<td>Infiniband NDR
</td></tr>
</table>

<table border="0" style="background:#ffffff" align="top" class="sortable wikitable">
<caption align="center" style="background:DarkSlateBlue; color:white"><big><b>Partición main</b></big>
</caption>
<tr>
<th width="60 px" style="background:Lavender; color:Black">Nodo
</th>
<th width="80 px" style="background:Lavender; color:Black">Modelo
</th>
<th width="80 px" style="background:Lavender; color:Black">Cantidad
</th>
<th width="100 px" style="background:Lavender; color:Black">Procesador
</th>
<th width="120 px" style="background:Lavender; color:Black">RAM
</th>
<th width="140 px" style="background:Lavender; color:Black">Infiniband
</th></tr>
<tr>
<td>mn00[1-27]</td>
<td>Lenovo ThinkSystem SR645 V3</td>
<td>27</td>
<td>2 x AMD EPYC 9754 @ 2,25GHz, 128 cores c/u.</td>
<td>768 GB</td>
<td>Infiniband NDR
</td></tr>
</table>

La partición debug es para uso exclusivo de pruebas que duren hasta 30 minutos. Cualquier trabajo que supere ese tiempo es cancelado automáticamente.

<table border="0" style="background:#ffffff" align="top" class="sortable wikitable">
<caption align="center" style="background:DarkSlateBlue; color:white"><big><b>Partición debug</b></big>
</caption>
<tr>
<th width="60 px" style="background:Lavender; color:Black">Nodo
</th>
<th width="80 px" style="background:Lavender; color:Black">Modelo
</th>
<th width="80 px" style="background:Lavender; color:Black">Cantidad
</th>
<th width="100 px" style="background:Lavender; color:Black">Procesador
</th>
<th width="120 px" style="background:Lavender; color:Black">RAM
</th>
<th width="140 px" style="background:Lavender; color:Black">Infiniband
</th></tr>
<tr>
<td>leftraru[1-2]</td>
<td>Lenovo ThinkSystem SR645 V3</td>
<td>2</td>
<td>2 x AMD EPYC 9224 @ 2,5GHz, 24 cores c/u.</td>
<td>768 GB</td>
<td>Infiniband NDR
</td></tr>
</table>

La capacidad total de Guacolda-Leftraru Epu al día de hoy es de 9956 cores y 430 TFlops.

Para más información respecto a la utilización del sistema gestor de colas y uso de recursos vea el siguiente enlace: [https://wiki.nlhpc.cl/SISTEMA_GESTOR_DE_RECURSOS SLURM]

Hardware Disponible

2024-04-26T15:40:55Z

Jmorales:

El NLHPC cuenta actualmente con los siguientes recursos computacionales, distribuidos en varias particiones [https://wiki.nlhpc.cl/SISTEMA_GESTOR_DE_RECURSOS SLURM]:

<table border="0" style="background:#ffffff" align="top" class="sortable wikitable">
<caption align="center" style="background:DarkSlateBlue; color:white"><big><b>Partición general</b></big>
</caption>
<tr>
<th width="60 px" style="background:Lavender; color:Black">Nodo
</th>
<th width="80 px" style="background:Lavender; color:Black">Modelo
</th>
<th width="80 px" style="background:Lavender; color:Black">Cantidad
</th>
<th width="100 px" style="background:Lavender; color:Black">Procesador
</th>
<th width="120 px" style="background:Lavender; color:Black">RAM
</th>
<th width="140 px" style="background:Lavender; color:Black">Infiniband
</th></tr>
<tr>
<td>sn[001-048]</td>
<td>Dell PowerEdge C6420</td>
<td>48</td>
<td>2 x Intel Xeon Gold 6152 CPU @ 2.10GHz, 22 cores C./U.</td>
<td>187 GB</td>
<td>Infiniband FDR
</td></tr>
</table>

<table border="0" style="background:#ffffff" align="top" class="sortable wikitable">
<caption align="center" style="background:DarkSlateBlue; color:white"><big><b>Partición largemem</b></big>
</caption>
<tr>
<th width="60 px" style="background:Lavender; color:Black">Nodo
</th>
<th width="80 px" style="background:Lavender; color:Black">Modelo
</th>
<th width="80 px" style="background:Lavender; color:Black">Cantidad
</th>
<th width="100 px" style="background:Lavender; color:Black">Procesador
</th>
<th width="120 px" style="background:Lavender; color:Black">RAM
</th>
<th width="140 px" style="background:Lavender; color:Black">Infiniband
</th></tr>
<tr>
<td>fn[001-009]</td>
<td>Dell PowerEdge R640</td>
<td>9</td>
<td>2 x Intel Xeon Gold 6152 CPU @ 2.10GHz, 22 cores C./U.</td>
<td>765 GB</td>
<td>Infiniband FDR
</td></tr>
</table>

<table border="0" style="background:#ffffff" align="top" class="sortable wikitable">
<caption align="center" style="background:DarkSlateBlue; color:white"><big><b>Partición v100</b></big>
</caption>
<tr>
<th width="60 px" style="background:Lavender; color:Black">Nodo
</th>
<th width="80 px" style="background:Lavender; color:Black">Modelo
</th>
<th width="80 px" style="background:Lavender; color:Black">Cantidad
</th>
<th width="100 px" style="background:Lavender; color:Black">Procesador
</th>
<th width="160 px" style="background:Lavender; color:Black">GPU
</th>
<th width="120 px" style="background:Lavender; color:Black">RAM
</th>
<th width="140 px" style="background:Lavender; color:Black">Infiniband
</th></tr>
<tr>
<td>gn[001-002]</td>
<td>Dell PowerEdge R740</td>
<td>2</td>
<td>2 x Intel Xeon Gold 6152 CPU @ 2.10GHz, 22 cores C./U.</td>
<td>2x NVIDIA Tesla V100 C/U.</td>
<td>187 GB</td>
<td>Infiniband FDR
</td></tr>
</table>

<table border="0" style="background:#ffffff" align="top" class="sortable wikitable">
<caption align="center" style="background:DarkSlateBlue; color:white"><big><b>Partición mi100</b></big>
</caption>
<tr>
<th width="60 px" style="background:Lavender; color:Black">Nodo
</th>
<th width="80 px" style="background:Lavender; color:Black">Modelo
</th>
<th width="80 px" style="background:Lavender; color:Black">Cantidad
</th>
<th width="100 px" style="background:Lavender; color:Black">Procesador
</th>
<th width="160 px" style="background:Lavender; color:Black">GPU
</th>
<th width="120 px" style="background:Lavender; color:Black">RAM
</th>
<th width="140 px" style="background:Lavender; color:Black">Infiniband
</th></tr>
<tr>
<td>gn003</td>
<td>Dell PowerEdge R7525</td>
<td>1</td>
<td>2 x AMD EPYC 7713 64-Core Processor CPU @ 2.0GHz, 64 cores C./U.</td>
<td>2x Instinct MI100 C/U.</td>
<td>502 GB</td>
<td>Infiniband FDR
</td></tr>
</table>

<table border="0" style="background:#ffffff" align="top" class="sortable wikitable">
<caption align="center" style="background:DarkSlateBlue; color:white"><big><b>Partición MI210</b></big>
</caption>
<tr>
<th width="60 px" style="background:Lavender; color:Black">Nodo
</th>
<th width="80 px" style="background:Lavender; color:Black">Modelo
</th>
<th width="80 px" style="background:Lavender; color:Black">Cantidad
</th>
<th width="100 px" style="background:Lavender; color:Black">Procesador
</th>
<th width="120 px" style="background:Lavender; color:Black">RAM
</th>
<th width="140 px" style="background:Lavender; color:Black">Infiniband
</th></tr>
<tr>
<td>gn00[4-5]</td>
<td>Lenovo ThinkSystem SR675 V3</td>
<td>2</td>
<td>2 x AMD EPYC 9224 @ 2.5GHz, 24 cores c/u.</td>
<td>768 GB</td>
<td>Infiniband NDR
</td></tr>
</table>

<table border="0" style="background:#ffffff" align="top" class="sortable wikitable">
<caption align="center" style="background:DarkSlateBlue; color:white"><big><b>Partición main</b></big>
</caption>
<tr>
<th width="60 px" style="background:Lavender; color:Black">Nodo
</th>
<th width="80 px" style="background:Lavender; color:Black">Modelo
</th>
<th width="80 px" style="background:Lavender; color:Black">Cantidad
</th>
<th width="100 px" style="background:Lavender; color:Black">Procesador
</th>
<th width="120 px" style="background:Lavender; color:Black">RAM
</th>
<th width="140 px" style="background:Lavender; color:Black">Infiniband
</th></tr>
<tr>
<td>mn00[1-27]</td>
<td>Lenovo ThinkSystem SR645 V3</td>
<td>27</td>
<td>2 x AMD EPYC 9754 @ 2,25GHz, 128 cores c/u.</td>
<td>768 GB</td>
<td>Infiniband NDR
</td></tr>
</table>

La partición debug es para uso exclusivo de pruebas que duren hasta 30 minutos. Cualquier trabajo que supere ese tiempo es cancelado automáticamente.

<table border="0" style="background:#ffffff" align="top" class="sortable wikitable">
<caption align="center" style="background:DarkSlateBlue; color:white"><big><b>Partición debug</b></big>
</caption>
<tr>
<th width="60 px" style="background:Lavender; color:Black">Nodo
</th>
<th width="80 px" style="background:Lavender; color:Black">Modelo
</th>
<th width="80 px" style="background:Lavender; color:Black">Cantidad
</th>
<th width="100 px" style="background:Lavender; color:Black">Procesador
</th>
<th width="120 px" style="background:Lavender; color:Black">RAM
</th>
<th width="140 px" style="background:Lavender; color:Black">Infiniband
</th></tr>
<tr>
<td>leftraru[1-2]</td>
<td>Lenovo ThinkSystem SR645 V3</td>
<td>2</td>
<td>2 x AMD EPYC 9224 @ 2,5GHz, 24 cores c/u.</td>
<td>768 GB</td>
<td>Infiniband NDR
</td></tr>
</table>

La capacidad total de Guacolda-Leftraru Epu al día de hoy es de 9956 cores y 430 TFlops.

Para más información respecto a la utilización del sistema gestor de colas y uso de recursos vea el siguiente enlace: [https://wiki.nlhpc.cl/SISTEMA_GESTOR_DE_RECURSOS SLURM]

Descripción General del Sistema

2024-04-22T18:21:45Z

Jmorales: /* Infraestructura Leftraru Epu */

== National Laboratory for High Performance Computing ==
El NLHPC en Chile está dirigido a la instalación en Chile de una capacidad computacional que pueda satisfacer la demanda científica nacional de computación de alto rendimiento (HPC), ofreciendo servicios de alta calidad y promoviendo su uso en las problemáticas de Investigación tanto básica como también aplicada, con énfasis en aplicaciones industriales. En años recientes, el desarrollo de las ciencias aplicadas y la industria ha sido dirigido por el uso sofisticado de las tecnologías de la información y las comunicaciones (ICT), proceso en el cual HPC ha jugado un rol fundamental.

Nuestros servicios están diseñados para ofrecer soporte al ciclo de vida completo de la investigación e innovación basada en HPC.

== Misión del NLHPC ==
La consolidación de una facilidad a nivel nacional de HPC al ofrecer servicios de alta calidad y training avanzado para así responder a la alta demanda de computación científica, desarrollando lazos entre grupos de investigación, la industria y el sector público.

== Visión del NLHPC ==
Visionamos al NLHPC como un centro altamente competitivo con una gama de servicios para la investigación en computación de alto rendimiento de calidad de clase mundial.

== Objetivo General ==
El NLHPC servirá como socio IT clave para los proyectos de investigación basados en HPC a gran escala.

=== Objetivos específicos ===
Desarrollar y dar soporte a recursos computacionales y de redes eficaces y confiables permitiendo a investigadores nacionales tener acceso a capacidad HPC para así resolver intensos problemas científicos de computación y data. Estimular y participar en la creación de una red nacional de alta velocidad para la transmisión de data de investigación Usar y explorar arquitecturas y técnicas innovadoras para acelerar la computación científica. Gatillar nuevas iniciativas industriales en HPC. Ayudar a educar a las próximas generaciones de científicos e ingenieros en HPC. Incrementar la conciencia social sobre el rol de HPC en la sociedad contemporánea y el desarrollo tecnológico.

== Infraestructura Guacolda-Leftraru Epu ==
=== Infraestructura Leftraru Epu===
* 280 TFlops total de rendimiento (sin coprocesadores)
* 7.360 cores total de cómputo
* 24.320 GB total de memoria RAM
* 27 nodos main
** 2 x AMD EPYC 9754 @ 2.25GHz, 128 cores c/u
** 768 GB de RAM c/u
* 2 nodos master
** 2 x AMD EPYC 9224 @ 2.5GHz Processor, 24 cores c/u
** 384 GB de RAM c/u
* 2 nodos gpu MI210
** 2 x AMD EPYC 9224 @ 2.5GHz Processor, 24 cores c/u
** 1536 GB de RAM c/u
** 6 tarjetas AMD Instinct MI210 c/u
* 1 nodo gpu MI100
** 2 x AMD EPYC 7713 @ 2.0GHz, 64 cores c/u
** 502 GB de RAM c/u
** 2 tarjetas AMD Instinct MI100 c/u.
* Infiniband NDR 400 Gbps
* Red servicio 1 Gpbs
* Red XClarity Controller para administración de hardware
* Racks enfriados por agua
* Enfriamiento in-row respaldo
* UPS 120 KVA autonomia: 30 mins

=== Infraestructura Guacolda ===

* 196 TFlops total de rendimiento (sin coprocesadores)
* 2.596 cores total de cómputo
* 16.235 GB total de memoria RAM
* 48 nodos General
** 2 x Intel(R) Xeon(R) Gold 6152 CPU @ 2.10GHz. 22 cores c/u
** 187 GB de RAM c/u
* 9 nodos largemem
** 2 x Intel(R) Xeon(R) Gold 6152 CPU @ 2.10GHz. 22 cores c/u
** 765 GB de RAM c/u
* 2 nodos v100
** 2 x Intel(R) Xeon(R) Gold 6152 CPU @ 2.10GHz. 22 cores c/u
** 187 GB de RAM c/u
** 2 x NVIDIA Tesla V100 c/u
* Infiniband FDR 56 Gbps
* Racks enfriados por agua
* Enfriamiento in-row respaldo
* UPS 120 KVA autonomia: 30 mins

=== Almacenamiento Cluster ===
* Almacenamiento paralelo de clase mundial
* Alto rendimiento en operaciones IO
* Tolerante a fallas (alta disponibilidad)
* Interconexión infiniband
* Capacidades Big Data

Características en Guacolda-Leftraru Epu

* 4 PB de almacenamiento IBM Elastic Storage System (IBM ESS 3200)
* Almacenamiento metadata separado
* 2 controladoras SFA en H.A

Hardware Disponible

2024-04-22T18:20:46Z

Jmorales:

El NLHPC cuenta actualmente con los siguientes recursos computacionales, distribuidos en varias particiones [https://wiki.nlhpc.cl/SISTEMA_GESTOR_DE_RECURSOS SLURM]:

<table border="0" style="background:#ffffff" align="top" class="sortable wikitable">
<caption align="center" style="background:DarkSlateBlue; color:white"><big><b>Partición general</b></big>
</caption>
<tr>
<th width="60 px" style="background:Lavender; color:Black">Nodo
</th>
<th width="80 px" style="background:Lavender; color:Black">Modelo
</th>
<th width="80 px" style="background:Lavender; color:Black">Cantidad
</th>
<th width="100 px" style="background:Lavender; color:Black">Procesador
</th>
<th width="120 px" style="background:Lavender; color:Black">RAM
</th>
<th width="140 px" style="background:Lavender; color:Black">Infiniband
</th></tr>
<tr>
<td>sn[001-048]</td>
<td>Dell PowerEdge C6420</td>
<td>48</td>
<td>2 x Intel Xeon Gold 6152 CPU @ 2.10GHz, 22 cores C./U.</td>
<td>187 GB</td>
<td>Infiniband FDR
</td></tr>
</table>

<table border="0" style="background:#ffffff" align="top" class="sortable wikitable">
<caption align="center" style="background:DarkSlateBlue; color:white"><big><b>Partición largemem</b></big>
</caption>
<tr>
<th width="60 px" style="background:Lavender; color:Black">Nodo
</th>
<th width="80 px" style="background:Lavender; color:Black">Modelo
</th>
<th width="80 px" style="background:Lavender; color:Black">Cantidad
</th>
<th width="100 px" style="background:Lavender; color:Black">Procesador
</th>
<th width="120 px" style="background:Lavender; color:Black">RAM
</th>
<th width="140 px" style="background:Lavender; color:Black">Infiniband
</th></tr>
<tr>
<td>fn[001-009]</td>
<td>Dell PowerEdge R640</td>
<td>9</td>
<td>2 x Intel Xeon Gold 6152 CPU @ 2.10GHz, 22 cores C./U.</td>
<td>765 GB</td>
<td>Infiniband FDR
</td></tr>
</table>

<table border="0" style="background:#ffffff" align="top" class="sortable wikitable">
<caption align="center" style="background:DarkSlateBlue; color:white"><big><b>Partición v100</b></big>
</caption>
<tr>
<th width="60 px" style="background:Lavender; color:Black">Nodo
</th>
<th width="80 px" style="background:Lavender; color:Black">Modelo
</th>
<th width="80 px" style="background:Lavender; color:Black">Cantidad
</th>
<th width="100 px" style="background:Lavender; color:Black">Procesador
</th>
<th width="160 px" style="background:Lavender; color:Black">GPU
</th>
<th width="120 px" style="background:Lavender; color:Black">RAM
</th>
<th width="140 px" style="background:Lavender; color:Black">Infiniband
</th></tr>
<tr>
<td>gn[001-002]</td>
<td>Dell PowerEdge R740</td>
<td>2</td>
<td>2 x Intel Xeon Gold 6152 CPU @ 2.10GHz, 22 cores C./U.</td>
<td>2x NVIDIA Tesla V100 C/U.</td>
<td>187 GB</td>
<td>Infiniband FDR
</td></tr>
</table>

<table border="0" style="background:#ffffff" align="top" class="sortable wikitable">
<caption align="center" style="background:DarkSlateBlue; color:white"><big><b>Partición mi100</b></big>
</caption>
<tr>
<th width="60 px" style="background:Lavender; color:Black">Nodo
</th>
<th width="80 px" style="background:Lavender; color:Black">Modelo
</th>
<th width="80 px" style="background:Lavender; color:Black">Cantidad
</th>
<th width="100 px" style="background:Lavender; color:Black">Procesador
</th>
<th width="160 px" style="background:Lavender; color:Black">GPU
</th>
<th width="120 px" style="background:Lavender; color:Black">RAM
</th>
<th width="140 px" style="background:Lavender; color:Black">Infiniband
</th></tr>
<tr>
<td>gn003</td>
<td>Dell PowerEdge R7525</td>
<td>1</td>
<td>2 x AMD EPYC 7713 64-Core Processor CPU @ 2.0GHz, 64 cores C./U.</td>
<td>2x Instinct MI100 C/U.</td>
<td>502 GB</td>
<td>Infiniband FDR
</td></tr>
</table>

<table border="0" style="background:#ffffff" align="top" class="sortable wikitable">
<caption align="center" style="background:DarkSlateBlue; color:white"><big><b>Partición MI210</b></big>
</caption>
<tr>
<th width="60 px" style="background:Lavender; color:Black">Nodo
</th>
<th width="80 px" style="background:Lavender; color:Black">Modelo
</th>
<th width="80 px" style="background:Lavender; color:Black">Cantidad
</th>
<th width="100 px" style="background:Lavender; color:Black">Procesador
</th>
<th width="120 px" style="background:Lavender; color:Black">RAM
</th>
<th width="140 px" style="background:Lavender; color:Black">Infiniband
</th></tr>
<tr>
<td>gn00[4-5]</td>
<td>Lenovo ThinkSystem SR675 V3</td>
<td>2</td>
<td>2 x AMD EPYC 9224 @ 2.5GHz, 24 cores c/u.</td>
<td>768 GB</td>
<td>Infiniband NDR
</td></tr>
</table>

<table border="0" style="background:#ffffff" align="top" class="sortable wikitable">
<caption align="center" style="background:DarkSlateBlue; color:white"><big><b>Partición main</b></big>
</caption>
<tr>
<th width="60 px" style="background:Lavender; color:Black">Nodo
</th>
<th width="80 px" style="background:Lavender; color:Black">Modelo
</th>
<th width="80 px" style="background:Lavender; color:Black">Cantidad
</th>
<th width="100 px" style="background:Lavender; color:Black">Procesador
</th>
<th width="120 px" style="background:Lavender; color:Black">RAM
</th>
<th width="140 px" style="background:Lavender; color:Black">Infiniband
</th></tr>
<tr>
<td>mn00[1-29]</td>
<td>Lenovo ThinkSystem SR645 V3</td>
<td>29</td>
<td>2 x AMD EPYC 9754 @ 2,25GHz, 128 cores c/u.</td>
<td>768 GB</td>
<td>Infiniband NDR
</td></tr>
</table>

La partición debug es para uso exclusivo de pruebas que duren hasta 30 minutos. Cualquier trabajo que supere ese tiempo es cancelado automáticamente.

<table border="0" style="background:#ffffff" align="top" class="sortable wikitable">
<caption align="center" style="background:DarkSlateBlue; color:white"><big><b>Partición debug</b></big>
</caption>
<tr>
<th width="60 px" style="background:Lavender; color:Black">Nodo
</th>
<th width="80 px" style="background:Lavender; color:Black">Modelo
</th>
<th width="80 px" style="background:Lavender; color:Black">Cantidad
</th>
<th width="100 px" style="background:Lavender; color:Black">Procesador
</th>
<th width="120 px" style="background:Lavender; color:Black">RAM
</th>
<th width="140 px" style="background:Lavender; color:Black">Infiniband
</th></tr>
<tr>
<td>leftraru[1-2]</td>
<td>Lenovo ThinkSystem SR645 V3</td>
<td>2</td>
<td>2 x AMD EPYC 9224 @ 2,5GHz, 24 cores c/u.</td>
<td>768 GB</td>
<td>Infiniband NDR
</td></tr>
</table>

La capacidad total de Guacolda-Leftraru Epu al día de hoy es de 9956 cores y 430 TFlops.

Para más información respecto a la utilización del sistema gestor de colas y uso de recursos vea el siguiente enlace: [https://wiki.nlhpc.cl/SISTEMA_GESTOR_DE_RECURSOS SLURM]

Glosario

2024-04-19T16:39:30Z

Jmorales: /* C */

== Introducción ==
El presente documento contiene un listado de términos y palabras que son utilizadas en el ámbito de las presentaciones y cursos que dicta el NLHPC, como también en la wiki y en nuestros distintos sitios.

Al poder entregar una definición transversal a las instancias mencionadas y a las relacionadas con el quehacer del NLHPC podremos comprender de mejor manera lo que deseamos expresar.

== Glosario ==
=== A ===
* '''Acceso SSH''': Referencia al uso mediante protocolo de seguridad SSH. Usualmente utilizado en terminales, como en aplicaciones como Putty.

=== B ===
* '''Bash/Shell''': Intérprete de comandos que permite la interacción interactiva con el usuario. Desde este intérprete de comandos es posible ejecutar comandos, programas y ejecutar simulaciones en el Gestor de Tareas del Cluster.
* '''Batch/Batch script/Script''': Archivo de texto con un conjunto de instrucciones. A diferencia de un código fuente, estas instrucciones son ejecutadas por el sistema operativo o un programa interprete como por ejemplo Python.

=== C ===
* '''Cache:''' Una caché es un componente de hardware o software que guarda datos para que las solicitudes futuras de esos datos se puedan atender con mayor rapidez.
* '''Cambio de Contexto:''' Consiste en la ejecución de una rutina perteneciente al núcleo del sistema operativo multitarea de una computadora, cuyo propósito es parar la ejecución de un hilo o proceso para dar paso a la ejecución de otro distinto.
* '''Cluster:''' Conjunto de computadores y servidores interconectados que se ven como una sola máquina. En nuestro caso tenemos los clusters Guacolda y Leftraru Epu.
* '''Código Fuente/Source code:''' Conjunto de archivos de texto que contienen las instrucciones computacionales que una vez que son compiladas generan un archivo de tipo binario que será el programa a ejecutar.
* '''Cola/Cola de Trabajo/Queue:''' Listado de trabajos asociados a un usuario y/o partición que se encuentran en distintos estados. La cola se organiza por orden de llegada.
* '''Compilador:''' En informática, un compilador es un tipo de traductor que transforma un programa entero de un lenguaje de programación (llamado código fuente) a otro.
* '''Core/CPU:''' Unidad de procesamiento, circuito electrónico que ejecuta las instrucciones de un programa.

=== E ===
* '''Estado de Nodo:''' Referido a la situación en particular de un nodo. Un nodo puede encontrarse Disponible(IDLE), No Disponible(Down), Ocupado(Allocated), Ocupado Parcial(MIX).
* '''Estado de Tarea:''' Referido a la situación en particular de una tarea enviada al Gestor de Tareas. Una tarea puede encontrarse en Pendiende(Pending), En Ejecución(Running), Finalizada(Completed), Cancelada(Cancelled), entre otros.

=== G ===
* '''Gestor/Gestor Slurm/Slurm:''' Organizador de recursos computacionales, particiones y colas de trabajo. Permite la organización y correcta asignación de recursos necesarios para que los usuarios puedan ejecutar sus simulaciones.

* '''Gandalf:''' Es un istar (‘mago’), uno de los espíritus maia enviados a la Tierra Media durante la Tercera Edad del Sol para ayudar a sus habitantes en la lucha contra el «señor oscuro» Sauron. Allí adoptó el aspecto de un anciano de barba larga y de color blanca grisácea, vestido con una gran capa gris, un sombrero puntiagudo de color azul y un gran cayado.

=== H ===
* '''Hardware:''' En informática se refiere a las partes físicas, tangibles, de un sistema informático; sus componentes eléctricos, electrónicos, electromecánicos y mecánicos.
* '''Hilo/Thread:''' Un hilo dentro de un procesador es la forma en que cada uno de los núcleos del CPU recibirá y procesará la información. Cada core puede atender un hilo a la vez.
* '''HPC:''' La computación de alto rendimiento (High performance Computing o HPC en inglés) es la agregación de potencia de cálculo para resolver problemas complejos en ciencia, ingeniería o gestión.

=== I ===
* '''Identificador de Tarea/Job ID:''' Número único e irrepetible asignado a una tarea. Permite la identificación de una Tarea enviada al Gestor Slurm.
* '''IP:''' Una dirección IP es un número que identifica de forma única a una interfaz en red de cualquier dispositivo conectado a ella que utilice el protocolo IP (Internet Protocol), que corresponde al nivel de red del modelo TCP/IP.

=== L ===
* '''Login/Inicio de Sesión:''' Dícese de la acción de ingresar su nombre de usuario y clave personal para acceder a una instancia computacional, como una terminal o a un servicio que requiera validación.

=== M ===
* '''Memoria Compartida/Shared Memory:''' En informática, la memoria compartida es aquel tipo de memoria que puede ser accedida por múltiples programas, ya sea para comunicarse entre ellos o para evitar copias redundantes.
* '''MPI:''' (interfaz de paso de mensajes) es la API de comunicación estándar para trabajos paralelos de memoria distribuida capaz de implementarse en un clúster. Las tareas se pueden ejecutar en múltiples nodos.
* '''Multi Core:''' Un procesador multinúcleo es aquel que combina dos o más microprocesadores independientes en un solo paquete, a menudo un solo circuito integrado.
* '''Multi Hilo/Multi-Threaded:''' Las unidades centrales de procesamiento con capacidad para multihilo (multithreading en inglés) tienen soporte en hardware para ejecutar eficientemente múltiples hilos de ejecución.

=== N ===
* '''Nodo:''' Unidad de hardware perteneciente a un cluster. Esta unidad tiene CPU y memoria RAM.

=== O ===
* '''OpenMP:''' Es una interfaz de programación de aplicaciones (API) para la programación multiproceso de memoria compartida en múltiples plataformas. Las tareas se ejecutan en un único nodo.

=== P ===
* '''Partición:''' En el ámbito del NLHPC, una partición es un conjunto de recursos físicos que incluye memoria RAM, procesadores y almacenamiento para la ejecución de tareas.

=== R ===
* '''RAM:''' La memoria de acceso aleatorio (Random Access Memory, RAM) se utiliza como memoria de trabajo de computadoras y otros dispositivos para el sistema operativo.

=== S ===
* '''Socket:''' Cantidad de procesadores que tiene un nodo. Un procesador puede tener n cores
* '''Software:''' Se conoce como software al soporte lógico de un sistema informático, que comprende el conjunto de los componentes lógicos necesarios que hacen posible la realización de tareas específicas.
* '''SSH:''' (Secure SHell) es el nombre de un protocolo y del programa que lo implementa cuya principal función es el acceso remoto a un servidor por medio de un canal seguro en el que toda la información está cifrada.

=== T ===
* '''Tarea/Job:''' Dícese del script enviado al Gestor de Tareas que indica los recursos computacionales solicitados para la ejecución de una simulación y/o programa. La tarea pasa a la Cola de Trabajo en espera de recursos para su ejecución.

== ¿Y ahora qué? ==
Con la aclaración de estos puntos, esperamos que su participación en próximos eventos del NLHPC como la lectura de la Wiki le resulte clarificadora para el uso del Cluster Guacolda-Leftraru Epu y que logre lanzar las simulaciones para obtener los resultados para sus investigaciones.

También lo invitamos a enviarnos sus comentarios o recomendaciones de nuevas palabras a agregar a este glosario al correo '''[mailto:soporte@nlhpc.cl soporte@nlhpc.cl.]'''

Glosario

2024-04-19T16:38:49Z

Jmorales: /* ¿Y ahora qué? */

== Introducción ==
El presente documento contiene un listado de términos y palabras que son utilizadas en el ámbito de las presentaciones y cursos que dicta el NLHPC, como también en la wiki y en nuestros distintos sitios.

Al poder entregar una definición transversal a las instancias mencionadas y a las relacionadas con el quehacer del NLHPC podremos comprender de mejor manera lo que deseamos expresar.

== Glosario ==
=== A ===
* '''Acceso SSH''': Referencia al uso mediante protocolo de seguridad SSH. Usualmente utilizado en terminales, como en aplicaciones como Putty.

=== B ===
* '''Bash/Shell''': Intérprete de comandos que permite la interacción interactiva con el usuario. Desde este intérprete de comandos es posible ejecutar comandos, programas y ejecutar simulaciones en el Gestor de Tareas del Cluster.
* '''Batch/Batch script/Script''': Archivo de texto con un conjunto de instrucciones. A diferencia de un código fuente, estas instrucciones son ejecutadas por el sistema operativo o un programa interprete como por ejemplo Python.

=== C ===
* '''Cache:''' Una caché es un componente de hardware o software que guarda datos para que las solicitudes futuras de esos datos se puedan atender con mayor rapidez.
* '''Cambio de Contexto:''' Consiste en la ejecución de una rutina perteneciente al núcleo del sistema operativo multitarea de una computadora, cuyo propósito es parar la ejecución de un hilo o proceso para dar paso a la ejecución de otro distinto.
* '''Cluster:''' Conjunto de computadores y servidores interconectados que se ven como una sola máquina. En nuestro caso tenemos los clusters Leftraru y Guacolda.
* '''Código Fuente/Source code:''' Conjunto de archivos de texto que contienen las instrucciones computacionales que una vez que son compiladas generan un archivo de tipo binario que será el programa a ejecutar.
* '''Cola/Cola de Trabajo/Queue:''' Listado de trabajos asociados a un usuario y/o partición que se encuentran en distintos estados. La cola se organiza por orden de llegada.
* '''Compilador:''' En informática, un compilador es un tipo de traductor que transforma un programa entero de un lenguaje de programación (llamado código fuente) a otro.
* '''Core/CPU:''' Unidad de procesamiento, circuito electrónico que ejecuta las instrucciones de un programa.

=== E ===
* '''Estado de Nodo:''' Referido a la situación en particular de un nodo. Un nodo puede encontrarse Disponible(IDLE), No Disponible(Down), Ocupado(Allocated), Ocupado Parcial(MIX).
* '''Estado de Tarea:''' Referido a la situación en particular de una tarea enviada al Gestor de Tareas. Una tarea puede encontrarse en Pendiende(Pending), En Ejecución(Running), Finalizada(Completed), Cancelada(Cancelled), entre otros.

=== G ===
* '''Gestor/Gestor Slurm/Slurm:''' Organizador de recursos computacionales, particiones y colas de trabajo. Permite la organización y correcta asignación de recursos necesarios para que los usuarios puedan ejecutar sus simulaciones.

* '''Gandalf:''' Es un istar (‘mago’), uno de los espíritus maia enviados a la Tierra Media durante la Tercera Edad del Sol para ayudar a sus habitantes en la lucha contra el «señor oscuro» Sauron. Allí adoptó el aspecto de un anciano de barba larga y de color blanca grisácea, vestido con una gran capa gris, un sombrero puntiagudo de color azul y un gran cayado.

=== H ===
* '''Hardware:''' En informática se refiere a las partes físicas, tangibles, de un sistema informático; sus componentes eléctricos, electrónicos, electromecánicos y mecánicos.
* '''Hilo/Thread:''' Un hilo dentro de un procesador es la forma en que cada uno de los núcleos del CPU recibirá y procesará la información. Cada core puede atender un hilo a la vez.
* '''HPC:''' La computación de alto rendimiento (High performance Computing o HPC en inglés) es la agregación de potencia de cálculo para resolver problemas complejos en ciencia, ingeniería o gestión.

=== I ===
* '''Identificador de Tarea/Job ID:''' Número único e irrepetible asignado a una tarea. Permite la identificación de una Tarea enviada al Gestor Slurm.
* '''IP:''' Una dirección IP es un número que identifica de forma única a una interfaz en red de cualquier dispositivo conectado a ella que utilice el protocolo IP (Internet Protocol), que corresponde al nivel de red del modelo TCP/IP.

=== L ===
* '''Login/Inicio de Sesión:''' Dícese de la acción de ingresar su nombre de usuario y clave personal para acceder a una instancia computacional, como una terminal o a un servicio que requiera validación.

=== M ===
* '''Memoria Compartida/Shared Memory:''' En informática, la memoria compartida es aquel tipo de memoria que puede ser accedida por múltiples programas, ya sea para comunicarse entre ellos o para evitar copias redundantes.
* '''MPI:''' (interfaz de paso de mensajes) es la API de comunicación estándar para trabajos paralelos de memoria distribuida capaz de implementarse en un clúster. Las tareas se pueden ejecutar en múltiples nodos.
* '''Multi Core:''' Un procesador multinúcleo es aquel que combina dos o más microprocesadores independientes en un solo paquete, a menudo un solo circuito integrado.
* '''Multi Hilo/Multi-Threaded:''' Las unidades centrales de procesamiento con capacidad para multihilo (multithreading en inglés) tienen soporte en hardware para ejecutar eficientemente múltiples hilos de ejecución.

=== N ===
* '''Nodo:''' Unidad de hardware perteneciente a un cluster. Esta unidad tiene CPU y memoria RAM.

=== O ===
* '''OpenMP:''' Es una interfaz de programación de aplicaciones (API) para la programación multiproceso de memoria compartida en múltiples plataformas. Las tareas se ejecutan en un único nodo.

=== P ===
* '''Partición:''' En el ámbito del NLHPC, una partición es un conjunto de recursos físicos que incluye memoria RAM, procesadores y almacenamiento para la ejecución de tareas.

=== R ===
* '''RAM:''' La memoria de acceso aleatorio (Random Access Memory, RAM) se utiliza como memoria de trabajo de computadoras y otros dispositivos para el sistema operativo.

=== S ===
* '''Socket:''' Cantidad de procesadores que tiene un nodo. Un procesador puede tener n cores
* '''Software:''' Se conoce como software al soporte lógico de un sistema informático, que comprende el conjunto de los componentes lógicos necesarios que hacen posible la realización de tareas específicas.
* '''SSH:''' (Secure SHell) es el nombre de un protocolo y del programa que lo implementa cuya principal función es el acceso remoto a un servidor por medio de un canal seguro en el que toda la información está cifrada.

=== T ===
* '''Tarea/Job:''' Dícese del script enviado al Gestor de Tareas que indica los recursos computacionales solicitados para la ejecución de una simulación y/o programa. La tarea pasa a la Cola de Trabajo en espera de recursos para su ejecución.

== ¿Y ahora qué? ==
Con la aclaración de estos puntos, esperamos que su participación en próximos eventos del NLHPC como la lectura de la Wiki le resulte clarificadora para el uso del Cluster Guacolda-Leftraru Epu y que logre lanzar las simulaciones para obtener los resultados para sus investigaciones.

También lo invitamos a enviarnos sus comentarios o recomendaciones de nuevas palabras a agregar a este glosario al correo '''[mailto:soporte@nlhpc.cl soporte@nlhpc.cl.]'''

MATLAB

2024-04-19T16:37:54Z

Jmorales: /* Modulos */

== ¿Qué es? ==

MATLAB (abreviatura de MATrix LABoratory, "laboratorio de matrices") es una herramienta de software matemático que ofrece un entorno de desarrollo integrado (IDE) con un lenguaje de programación propio (lenguaje M).

== Modulos ==
Se encuentra disponible con el nombre '''Matlab/2017''' y el runtime esta agregado como '''MCR/R2017a''' en todas las particiones de Guacolda-Leftraru Epu.

== Ejemplo SBATCH para [https://wiki.nlhpc.cl/SISTEMA_GESTOR_DE_RECURSOS#SLURM_Workload_Manager SLURM] ==
<pre>
#!/bin/bash
#SBATCH -J nombretarea
#SBATCH -p general
#SBATCH -n 1
#SBATCH --ntasks-per-node=1
#SBATCH --mem-per-cpu=4363
#SBATCH --mail-user=usuario@correo.cl
#SBATCH --mail-type=ALL
#SBATCH -o %j_%x.out
#SBATCH -e %j_%x.err
#SBATCH --license=matlab #agregar si se va a ocupar MATLAB

ml intel/2019b
ml Matlab/2017

matlab -nodisplay -nosplash -nodesktop < ejemplo.m
</pre>
(Sin paralelización)

== Licencias ==
Existen 50 licencias disponibles para el uso de MATLAB proporcionadas por el [http://www.cmm.uchile.cl/ CMM], pero es posible evitar esta restricción de licencias creando una [https://wiki.nlhpc.cl/MATLAB_Compilaci%C3%B3n compilación standalone] con el Toolbox Compiler. El gestor de recursos cancelara las tareas que no indiquen las licencias en el script SBATCH, todo esto para favorecer el uso entre los distintos usuarios.

== Toolbox ==
Tenemos disponibles los siguientes toolbox con su respectiva cantidad de licencias.

<p> </p>

<table align="center" border="1" cellpadding="1" cellspacing="1" style="height:519px; width:500px">
<tr>
<th scope="col">Nombre</th>
<th scope="col">Cantidad</th>
<th scope="col">Licencia Slurm</th>
</tr>
<tr>
<td>SIMULINK</td>
<td style="text-align:center">2</td>
<td>matlab-simulink</td>
</tr>
<tr>
<td>Bioinformatics</td>
<td style="text-align:center">1</td>
<td>matlab-bioinformatics</td>
</tr>
<tr>
<td>Control</td>
<td style="text-align:center">20</td>
<td>matlab-control</td>
</tr>
<tr>
<td>Curve_Fitting</td>
<td style="text-align:center">2</td>
<td>matlab-curve_fitting</td>
</tr>
<tr>
<td>Database</td>
<td style="text-align:center">1</td>
<td>matlab-database</td>
</tr>
<tr>
<td>Econometrics</td>
<td style="text-align:center">2</td>
<td>matlab-econometrics</td>
</tr>
<tr>
<td>Financial</td>
<td style="text-align:center">2</td>
<td>matlab-financial</td>
</tr>
<tr>
<td>GADS</td>
<td style="text-align:center">1</td>
<td>matlab-gads</td>
</tr>
<tr>
<td>Image</td>
<td style="text-align:center">2</td>
<td>matlab-image</td>
</tr>
<tr>
<td>MATLAB_Coder</td>
<td style="text-align:center">1</td>
<td>matlab-matlab_code</td>
</tr>
<tr>
<td>Compiler</td>
<td style="text-align:center">1</td>
<td>matlab-compiler</td>
</tr>
<tr>
<td>Optimization</td>
<td style="text-align:center">5</td>
<td>matlab-optimization</td>
</tr>
<tr>
<td>[https://wiki.nlhpc.cl/MATLAB_Distrib_Computing Distrib_Computing]</td>
<td style="text-align:center">2</td>
<td>matlab-distrib_computing</td>
</tr>
<tr>
<td>PDE</td>
<td style="text-align:center">20</td>
<td>matlab-pde</td>
</tr>
<tr>
<td>Signal</td>
<td style="text-align:center">2</td>
<td>matlab-signal</td>
</tr>
<tr>
<td>SimBiology</td>
<td style="text-align:center">2</td>
<td>matlab-simbiology</td>
</tr>
<tr>
<td>Statistics</td>
<td style="text-align:center">5</td>
<td>matlab-statistics</td>
</tr>
<tr>
<td>Identification</td>
<td style="text-align:center"> 2   </td>
<td> matlab-identification</td>
</tr>
<tr>
<td>Wavelet</td>
<td style="text-align:center">1</td>
<td>matlab-wavelet</td>
</tr>
</table>

<p><br />
<br />
 </p>

<p> </p>

== Referencias ==

* [https://la.mathworks.com/help/matlab/language-fundamentals.html Language Fundamentals]
* [http://www.cas.mcmaster.ca/~cs4te3/tutorials/matlab_toolbox_quickref.pdf MATLAB Toolbox Quickref]
* [http://walkingrandomly.com/?p=5343 Checkpointing MATLAB Programs]

Información para nuevos usuarios

2024-04-19T16:37:06Z

Jmorales:

Esta es la wiki de usuarios de Guacolda-Leftraru Epu, el clúster HPC del NLHPC. Aquí encontrará información útil para:

* Ingresar al clúster: [https://wiki.nlhpc.cl/Tutorial_de_acceso_a_Leftraru_via_SSH Tutorial acceso SSH]
* Descripción del hardware: [https://wiki.nlhpc.cl/Hardware_Disponible Recursos Computacionales NLHPC]
* Lanzar tareas en el gestor de colas Slurm: [https://wiki.nlhpc.cl/SISTEMA_GESTOR_DE_RECURSOS Sistema Gestor de Recursos]
* Solicitar soporte mediante ticket: [https://wiki.nlhpc.cl/Como_abrir_un_ticket Cómo abrir un ticket]
* Preguntas frecuentes: [https://wiki.nlhpc.cl/FAQs FAQs]

Software Leftraru

2024-04-19T16:36:28Z

Jmorales:

El software instalado en Guacolda-Leftraru Epu se encuentra dividido en dos sistemas de aplicaciones distintos,

* [https://wiki.nlhpc.cl/Lmod Lmod]
* [https://wiki.nlhpc.cl/Environment_Modules Environment Modules]

Este software corresponde a las aplicaciones instaladas por el Equipo de Soporte solicitadas al email [mailto:soporte@nlhpc.cl soporte@nlhpc.cl]

Sumario

2024-04-19T16:36:02Z

Jmorales: /* Software instalado en el Clúster */

== Información para nuevos usuarios ==
Esta es la wiki para nuestra comunidad de usuarios del NLHPC. Aquí encontrará información útil para:

* Ingresar al clúster
* Descripción del hardware
* Lanzar tareas en el gestor de recursos '''Slurm'''
* Preguntas Frecuentes
* Para más información puede visitar [https://wiki.nlhpc.cl/Informaci%C3%B3n_para_nuevos_usuarios Aquí]

== Recursos computacionales del Clúster ==
Nuestro clúster cuenta actualmente con 7 particiones: general, largemem, V100, mi100, mi210, main y debug.

Las caracterísiticas de estas particiones pueden encontrarse en [https://wiki.nlhpc.cl/Hardware_Disponible Recursos Computacionales NLHPC]

== Creación de cuentas ==
El proceso de creación de cuentas es relativamente fácil. Para poder crear una cuenta debe seguir las instrucciones del siguiente [http://www.nlhpc.cl/es/servicios enlace] y luego postular a una cuenta rellenando información en un formulario online.

== Software instalado en el Clúster ==
Guacolda-Leftraru Epu cuenta con una amplia gama de software.

Para saber el software que está instalado en nuestro clúster, vaya al siguiente link: [https://wiki.nlhpc.cl/Lmod Lmod]

Tenga en cuenta que el NLHPC no entrega licencias de software, por lo que es responsabilidad de cada usuario o grupo de usuarios el adquirir estas licencias.

== Accediendo al Clúster ==
Nuestro clúster utiliza Linux como sistema operativo el que permite el acceso a nuestros usuarios mediante el protocolo [https://es.wikipedia.org/wiki/Secure_Shell SSH] para conectase remotamente. Puede conectarse a su cuenta accediendo a la siguiente dirección:

leftraru.nlhpc.cl

Puede encontrar mayor información en [https://wiki.nlhpc.cl/Tutorial_de_acceso_a_Leftraru_via_SSH Tutorial de acceso a Leftraru via SSH]. Para facilitar la copia de archivos hacia y desde el clúster, vea el [https://wiki.nlhpc.cl/Tutorial_de_acceso_a_archivos Tutorial de acceso a archivos]

== MFA o autenticación multifactor ==
MFA o autenticación multifactor agrega una capa de protección al proceso de inicio de sesión. En el caso del NLHPC, se ha decidido integrar MFA adicionalmente al uso de contraseñas y llaves. El proceso de creación de MFA se ejecutará automáticamente cuando inicie sesión y es necesario que tenga a la mano su celular con la aplicación Google Authenticator o Authy instalada. Cuando inicie sesión, se mostrará un código qr que deberá escanear en alguna de estas aplicaciones. También se mostrarán un “secret key” que le permitirá recuperar el acceso en el caso de extravío de su celular. La próxima vez que inicie sesión en su cuenta se pedirá tanto la contraseña de acceso como el código generado por la aplicación multifactor.

== Slurm, sistema de gestión de recursos ==
En el NLHPC utilizamos [https://slurm.schedmd.com/ Slurm] como gestor de recursos. Slurm provee de un framework para encolar trabajos, asignación de nodos de cómputo, reserva de tiempo de CPU, ejecución y gestión de trabajos dentro de clúster. Nuestros nodos de cómputo se encuentran agrupados en particiones, dentro de las cuales los usuarios pueden ejecutar sus trabajos dependiendo de sus necesidades.

Para ver más información acerca de cómo trabajar con Slurm en el clúster, por favor visite el tutorial de [https://wiki.nlhpc.cl/SISTEMA_GESTOR_DE_RECURSOS ejecución de tareas dentro de Leftaru.]

== Lustre, sistema de archivos distribuido ==
[https://es.wikipedia.org/wiki/Lustre_%28sistema_de_archivos%29 Lustre] es un conocido [https://es.wikipedia.org/wiki/Sistema_de_archivos_distribuido sistema de archivos distribuido] de alta disponibilidad que permite usar una red de computadores para construir un espacio de almacenamiento amplio, escalable y mantenible en el que se pueden definir cuotas de utilización por usuario.

Lustre es open source, pero debido a su envergadura y dificultad para constituirlo, se ha optado por contratar una solución privada (a la empresa [http://www.ddn.com/ DDN]) que incluye tanto infraestructura como configuraciones optimizadas de tal manera de contar con una opción de almacenamiento acorde a las necesidades del NLHPC.

'''Limitaciones y excepciones de Lustre:''' A pesar de tener muchas características sobresalientes, y en pos de aumentar el rendimiento de la lectura y escritura de archivos, Lustre no permite bloquear un archivo ([https://en.wikipedia.org/wiki/File_locking file locking] en inglés). Esto implica que muchos de los motores de bases de datos más conocidos (MySQL, Postgres, etc.) e incluso algunas aplicaciones que hacen uso de esta característica no funcionen o se caigan en su ejecución. Se recomienda realizar esa parte del trabajo en la partición /mnt/flock/usuario.

== Tutoriales ==
[https://wiki.nlhpc.cl/Tutorial_de_acceso_a_Leftraru_via_SSH Tutorial de acceso a Leftraru via SSH]

[https://wiki.nlhpc.cl/SISTEMA_GESTOR_DE_RECURSOS Ejecución de tareas dentro de Leftaru]

Presentación uso del clúster del NLHPC

[https://wiki.nlhpc.cl/Escalamiento Escalamiento de Aplicaciones]

[https://wiki.nlhpc.cl/Monitoreo_De_Tareas Monitoreo De Tareas]

[https://wiki.nlhpc.cl/Categor%C3%ADa:Software Documentación de temas relacionados con el software del clúster]

Información para nuevos usuarios

2024-04-19T16:34:55Z

Jmorales:

Esta es la wiki de usuarios de Leftraru Epu, el clúster HPC del NLHPC. Aquí encontrará información útil para:

* Ingresar al clúster: [https://wiki.nlhpc.cl/Tutorial_de_acceso_a_Leftraru_via_SSH Tutorial acceso SSH]
* Descripción del hardware: [https://wiki.nlhpc.cl/Hardware_Disponible Recursos Computacionales NLHPC]
* Lanzar tareas en el gestor de colas Slurm: [https://wiki.nlhpc.cl/SISTEMA_GESTOR_DE_RECURSOS Sistema Gestor de Recursos]
* Solicitar soporte mediante ticket: [https://wiki.nlhpc.cl/Como_abrir_un_ticket Cómo abrir un ticket]
* Preguntas frecuentes: [https://wiki.nlhpc.cl/FAQs FAQs]

Software Leftraru

2024-04-19T16:34:14Z

Jmorales:

El software instalado en Leftraru Epu se encuentra dividido en dos sistemas de aplicaciones distintos,

* [https://wiki.nlhpc.cl/Lmod Lmod]
* [https://wiki.nlhpc.cl/Environment_Modules Environment Modules]

Este software corresponde a las aplicaciones instaladas por el Equipo de Soporte solicitadas al email [mailto:soporte@nlhpc.cl soporte@nlhpc.cl]

Hardware Disponible

2024-04-19T16:33:16Z

Jmorales:

El NLHPC cuenta actualmente con los siguientes recursos computacionales, distribuidos en varias particiones [https://wiki.nlhpc.cl/SISTEMA_GESTOR_DE_RECURSOS SLURM]:

<table border="0" style="background:#ffffff" align="top" class="sortable wikitable">
<caption align="center" style="background:DarkSlateBlue; color:white"><big><b>Partición general</b></big>
</caption>
<tr>
<th width="60 px" style="background:Lavender; color:Black">Nodo
</th>
<th width="80 px" style="background:Lavender; color:Black">Modelo
</th>
<th width="80 px" style="background:Lavender; color:Black">Cantidad
</th>
<th width="100 px" style="background:Lavender; color:Black">Procesador
</th>
<th width="120 px" style="background:Lavender; color:Black">RAM
</th>
<th width="140 px" style="background:Lavender; color:Black">Infiniband
</th></tr>
<tr>
<td>sn[001-048]</td>
<td>Dell PowerEdge C6420</td>
<td>48</td>
<td>2 x Intel Xeon Gold 6152 CPU @ 2.10GHz, 22 cores C./U.</td>
<td>187 GB</td>
<td>Infiniband FDR
</td></tr>
</table>

<table border="0" style="background:#ffffff" align="top" class="sortable wikitable">
<caption align="center" style="background:DarkSlateBlue; color:white"><big><b>Partición largemem</b></big>
</caption>
<tr>
<th width="60 px" style="background:Lavender; color:Black">Nodo
</th>
<th width="80 px" style="background:Lavender; color:Black">Modelo
</th>
<th width="80 px" style="background:Lavender; color:Black">Cantidad
</th>
<th width="100 px" style="background:Lavender; color:Black">Procesador
</th>
<th width="120 px" style="background:Lavender; color:Black">RAM
</th>
<th width="140 px" style="background:Lavender; color:Black">Infiniband
</th></tr>
<tr>
<td>fn[001-009]</td>
<td>Dell PowerEdge R640</td>
<td>9</td>
<td>2 x Intel Xeon Gold 6152 CPU @ 2.10GHz, 22 cores C./U.</td>
<td>765 GB</td>
<td>Infiniband FDR
</td></tr>
</table>

<table border="0" style="background:#ffffff" align="top" class="sortable wikitable">
<caption align="center" style="background:DarkSlateBlue; color:white"><big><b>Partición v100</b></big>
</caption>
<tr>
<th width="60 px" style="background:Lavender; color:Black">Nodo
</th>
<th width="80 px" style="background:Lavender; color:Black">Modelo
</th>
<th width="80 px" style="background:Lavender; color:Black">Cantidad
</th>
<th width="100 px" style="background:Lavender; color:Black">Procesador
</th>
<th width="160 px" style="background:Lavender; color:Black">GPU
</th>
<th width="120 px" style="background:Lavender; color:Black">RAM
</th>
<th width="140 px" style="background:Lavender; color:Black">Infiniband
</th></tr>
<tr>
<td>gn[001-002]</td>
<td>Dell PowerEdge R740</td>
<td>2</td>
<td>2 x Intel Xeon Gold 6152 CPU @ 2.10GHz, 22 cores C./U.</td>
<td>2x NVIDIA Tesla V100 C/U.</td>
<td>187 GB</td>
<td>Infiniband FDR
</td></tr>
</table>

<table border="0" style="background:#ffffff" align="top" class="sortable wikitable">
<caption align="center" style="background:DarkSlateBlue; color:white"><big><b>Partición mi100</b></big>
</caption>
<tr>
<th width="60 px" style="background:Lavender; color:Black">Nodo
</th>
<th width="80 px" style="background:Lavender; color:Black">Modelo
</th>
<th width="80 px" style="background:Lavender; color:Black">Cantidad
</th>
<th width="100 px" style="background:Lavender; color:Black">Procesador
</th>
<th width="160 px" style="background:Lavender; color:Black">GPU
</th>
<th width="120 px" style="background:Lavender; color:Black">RAM
</th>
<th width="140 px" style="background:Lavender; color:Black">Infiniband
</th></tr>
<tr>
<td>gn003</td>
<td>Dell PowerEdge R7525</td>
<td>1</td>
<td>2 x AMD EPYC 7713 64-Core Processor CPU @ 2.0GHz, 64 cores C./U.</td>
<td>2x Instinct MI100 C/U.</td>
<td>502 GB</td>
<td>Infiniband FDR
</td></tr>
</table>

<table border="0" style="background:#ffffff" align="top" class="sortable wikitable">
<caption align="center" style="background:DarkSlateBlue; color:white"><big><b>Partición MI210</b></big>
</caption>
<tr>
<th width="60 px" style="background:Lavender; color:Black">Nodo
</th>
<th width="80 px" style="background:Lavender; color:Black">Modelo
</th>
<th width="80 px" style="background:Lavender; color:Black">Cantidad
</th>
<th width="100 px" style="background:Lavender; color:Black">Procesador
</th>
<th width="120 px" style="background:Lavender; color:Black">RAM
</th>
<th width="140 px" style="background:Lavender; color:Black">Infiniband
</th></tr>
<tr>
<td>gn00[4-5]</td>
<td>Lenovo ThinkSystem SR675 V3</td>
<td>2</td>
<td>2 x AMD EPYC 9224 @ 2.5GHz, 24 cores c/u.</td>
<td>768 GB</td>
<td>Infiniband HDR
</td></tr>
</table>

<table border="0" style="background:#ffffff" align="top" class="sortable wikitable">
<caption align="center" style="background:DarkSlateBlue; color:white"><big><b>Partición main</b></big>
</caption>
<tr>
<th width="60 px" style="background:Lavender; color:Black">Nodo
</th>
<th width="80 px" style="background:Lavender; color:Black">Modelo
</th>
<th width="80 px" style="background:Lavender; color:Black">Cantidad
</th>
<th width="100 px" style="background:Lavender; color:Black">Procesador
</th>
<th width="120 px" style="background:Lavender; color:Black">RAM
</th>
<th width="140 px" style="background:Lavender; color:Black">Infiniband
</th></tr>
<tr>
<td>mn00[1-29]</td>
<td>Lenovo ThinkSystem SR645 V3</td>
<td>29</td>
<td>2 x AMD EPYC 9754 @ 2,25GHz, 128 cores c/u.</td>
<td>768 GB</td>
<td>Infiniband HDR
</td></tr>
</table>

La partición debug es para uso exclusivo de pruebas que duren hasta 30 minutos. Cualquier trabajo que supere ese tiempo es cancelado automáticamente.

<table border="0" style="background:#ffffff" align="top" class="sortable wikitable">
<caption align="center" style="background:DarkSlateBlue; color:white"><big><b>Partición debug</b></big>
</caption>
<tr>
<th width="60 px" style="background:Lavender; color:Black">Nodo
</th>
<th width="80 px" style="background:Lavender; color:Black">Modelo
</th>
<th width="80 px" style="background:Lavender; color:Black">Cantidad
</th>
<th width="100 px" style="background:Lavender; color:Black">Procesador
</th>
<th width="120 px" style="background:Lavender; color:Black">RAM
</th>
<th width="140 px" style="background:Lavender; color:Black">Infiniband
</th></tr>
<tr>
<td>leftraru[1-2]</td>
<td>Lenovo ThinkSystem SR645 V3</td>
<td>2</td>
<td>2 x AMD EPYC 9224 @ 2,5GHz, 24 cores c/u.</td>
<td>768 GB</td>
<td>Infiniband HDR
</td></tr>
</table>

La capacidad total de Guacolda-Leftraru Epu al día de hoy es de 9956 cores y 430 TFlops.

Para más información respecto a la utilización del sistema gestor de colas y uso de recursos vea el siguiente enlace: [https://wiki.nlhpc.cl/SISTEMA_GESTOR_DE_RECURSOS SLURM]

Descripción General del Sistema

2024-04-19T16:31:43Z

Jmorales: /* Infraestructura Leftraru Epu */

== National Laboratory for High Performance Computing ==
El NLHPC en Chile está dirigido a la instalación en Chile de una capacidad computacional que pueda satisfacer la demanda científica nacional de computación de alto rendimiento (HPC), ofreciendo servicios de alta calidad y promoviendo su uso en las problemáticas de Investigación tanto básica como también aplicada, con énfasis en aplicaciones industriales. En años recientes, el desarrollo de las ciencias aplicadas y la industria ha sido dirigido por el uso sofisticado de las tecnologías de la información y las comunicaciones (ICT), proceso en el cual HPC ha jugado un rol fundamental.

Nuestros servicios están diseñados para ofrecer soporte al ciclo de vida completo de la investigación e innovación basada en HPC.

== Misión del NLHPC ==
La consolidación de una facilidad a nivel nacional de HPC al ofrecer servicios de alta calidad y training avanzado para así responder a la alta demanda de computación científica, desarrollando lazos entre grupos de investigación, la industria y el sector público.

== Visión del NLHPC ==
Visionamos al NLHPC como un centro altamente competitivo con una gama de servicios para la investigación en computación de alto rendimiento de calidad de clase mundial.

== Objetivo General ==
El NLHPC servirá como socio IT clave para los proyectos de investigación basados en HPC a gran escala.

=== Objetivos específicos ===
Desarrollar y dar soporte a recursos computacionales y de redes eficaces y confiables permitiendo a investigadores nacionales tener acceso a capacidad HPC para así resolver intensos problemas científicos de computación y data. Estimular y participar en la creación de una red nacional de alta velocidad para la transmisión de data de investigación Usar y explorar arquitecturas y técnicas innovadoras para acelerar la computación científica. Gatillar nuevas iniciativas industriales en HPC. Ayudar a educar a las próximas generaciones de científicos e ingenieros en HPC. Incrementar la conciencia social sobre el rol de HPC en la sociedad contemporánea y el desarrollo tecnológico.

== Infraestructura Guacolda-Leftraru Epu ==
=== Infraestructura Leftraru Epu===
* 280 TFlops total de rendimiento (sin coprocesadores)
* 7.360 cores total de cómputo
* 24.320 GB total de memoria RAM
* 27 nodos main
** 2 x AMD EPYC 9754 @ 2.25GHz, 128 cores c/u
** 768 GB de RAM c/u
* 2 nodos master
** 2 x AMD EPYC 9224 @ 2.5GHz Processor, 24 cores c/u
** 384 GB de RAM c/u
* 2 nodos gpu MI210
** 2 x AMD EPYC 9224 @ 2.5GHz Processor, 24 cores c/u
** 1536 GB de RAM c/u
** 6 tarjetas AMD Instinct MI210 c/u
* 1 nodo gpu MI100
** 2 x AMD EPYC 7713 @ 2.0GHz, 64 cores c/u
** 502 GB de RAM c/u
** 2 tarjetas AMD Instinct MI100 c/u.
* Infiniband HDR 100 Gbps
* Red servicio 1 Gpbs
* Red XClarity Controller para administración de hardware
* Racks enfriados por agua
* Enfriamiento in-row respaldo
* UPS 120 KVA autonomia: 30 mins

=== Infraestructura Guacolda ===

* 196 TFlops total de rendimiento (sin coprocesadores)
* 2.596 cores total de cómputo
* 16.235 GB total de memoria RAM
* 48 nodos General
** 2 x Intel(R) Xeon(R) Gold 6152 CPU @ 2.10GHz. 22 cores c/u
** 187 GB de RAM c/u
* 9 nodos largemem
** 2 x Intel(R) Xeon(R) Gold 6152 CPU @ 2.10GHz. 22 cores c/u
** 765 GB de RAM c/u
* 2 nodos v100
** 2 x Intel(R) Xeon(R) Gold 6152 CPU @ 2.10GHz. 22 cores c/u
** 187 GB de RAM c/u
** 2 x NVIDIA Tesla V100 c/u
* Infiniband FDR 56 Gbps
* Racks enfriados por agua
* Enfriamiento in-row respaldo
* UPS 120 KVA autonomia: 30 mins

=== Almacenamiento Cluster ===
* Almacenamiento paralelo de clase mundial
* Alto rendimiento en operaciones IO
* Tolerante a fallas (alta disponibilidad)
* Interconexión infiniband
* Capacidades Big Data

Características en Guacolda-Leftraru Epu

* 4 PB de almacenamiento IBM Elastic Storage System (IBM ESS 3200)
* Almacenamiento metadata separado
* 2 controladoras SFA en H.A

Descripción General del Sistema

2024-04-19T16:31:31Z

Jmorales: /* Infraestructura Guacolda */

== National Laboratory for High Performance Computing ==
El NLHPC en Chile está dirigido a la instalación en Chile de una capacidad computacional que pueda satisfacer la demanda científica nacional de computación de alto rendimiento (HPC), ofreciendo servicios de alta calidad y promoviendo su uso en las problemáticas de Investigación tanto básica como también aplicada, con énfasis en aplicaciones industriales. En años recientes, el desarrollo de las ciencias aplicadas y la industria ha sido dirigido por el uso sofisticado de las tecnologías de la información y las comunicaciones (ICT), proceso en el cual HPC ha jugado un rol fundamental.

Nuestros servicios están diseñados para ofrecer soporte al ciclo de vida completo de la investigación e innovación basada en HPC.

== Misión del NLHPC ==
La consolidación de una facilidad a nivel nacional de HPC al ofrecer servicios de alta calidad y training avanzado para así responder a la alta demanda de computación científica, desarrollando lazos entre grupos de investigación, la industria y el sector público.

== Visión del NLHPC ==
Visionamos al NLHPC como un centro altamente competitivo con una gama de servicios para la investigación en computación de alto rendimiento de calidad de clase mundial.

== Objetivo General ==
El NLHPC servirá como socio IT clave para los proyectos de investigación basados en HPC a gran escala.

=== Objetivos específicos ===
Desarrollar y dar soporte a recursos computacionales y de redes eficaces y confiables permitiendo a investigadores nacionales tener acceso a capacidad HPC para así resolver intensos problemas científicos de computación y data. Estimular y participar en la creación de una red nacional de alta velocidad para la transmisión de data de investigación Usar y explorar arquitecturas y técnicas innovadoras para acelerar la computación científica. Gatillar nuevas iniciativas industriales en HPC. Ayudar a educar a las próximas generaciones de científicos e ingenieros en HPC. Incrementar la conciencia social sobre el rol de HPC en la sociedad contemporánea y el desarrollo tecnológico.

== Infraestructura Guacolda-Leftraru Epu ==
=== Infraestructura Leftraru Epu===
* 280 TFlops total de rendimiento (sin coprocesadores)
* 7.360 cores total de cómputo
* 24.320 GB total de memoria RAM
* 27 nodos main
** 2 x AMD EPYC 9754 @ 2.25GHz, 128 cores c/u
** 768 GB de RAM c/u
* 2 nodos master
** 2 x AMD EPYC 9224 @ 2.5GHz Processor, 24 cores c/u
** 384 GB de RAM c/u
* 2 nodos gpu MI210
** 2 x AMD EPYC 9224 @ 2.5GHz Processor, 24 cores c/u
** 1536 GB de RAM c/u
** 6 tarjetas AMD Instinct MI210 c/u
* 1 nodo gpu MI100
** 2 x AMD EPYC 7713 @ 2.0GHz, 64 cores c/u
** 502 GB de RAM c/u
** 2 tarjetas AMD Instinct MI100 c/u.
* Infiniband HDR 100 Gbps
* Red servicio 1 Gpbs
* Red XClarity Controller para administración de hardware
* Racks enfriados por agua
* Enfriamiento in-row respaldo

=== Infraestructura Guacolda ===

* 196 TFlops total de rendimiento (sin coprocesadores)
* 2.596 cores total de cómputo
* 16.235 GB total de memoria RAM
* 48 nodos General
** 2 x Intel(R) Xeon(R) Gold 6152 CPU @ 2.10GHz. 22 cores c/u
** 187 GB de RAM c/u
* 9 nodos largemem
** 2 x Intel(R) Xeon(R) Gold 6152 CPU @ 2.10GHz. 22 cores c/u
** 765 GB de RAM c/u
* 2 nodos v100
** 2 x Intel(R) Xeon(R) Gold 6152 CPU @ 2.10GHz. 22 cores c/u
** 187 GB de RAM c/u
** 2 x NVIDIA Tesla V100 c/u
* Infiniband FDR 56 Gbps
* Racks enfriados por agua
* Enfriamiento in-row respaldo
* UPS 120 KVA autonomia: 30 mins

=== Almacenamiento Cluster ===
* Almacenamiento paralelo de clase mundial
* Alto rendimiento en operaciones IO
* Tolerante a fallas (alta disponibilidad)
* Interconexión infiniband
* Capacidades Big Data

Características en Guacolda-Leftraru Epu

* 4 PB de almacenamiento IBM Elastic Storage System (IBM ESS 3200)
* Almacenamiento metadata separado
* 2 controladoras SFA en H.A

Descripción General del Sistema

2024-04-19T16:29:51Z

Jmorales: /* Infraestructura Leftraru Epu */

== National Laboratory for High Performance Computing ==
El NLHPC en Chile está dirigido a la instalación en Chile de una capacidad computacional que pueda satisfacer la demanda científica nacional de computación de alto rendimiento (HPC), ofreciendo servicios de alta calidad y promoviendo su uso en las problemáticas de Investigación tanto básica como también aplicada, con énfasis en aplicaciones industriales. En años recientes, el desarrollo de las ciencias aplicadas y la industria ha sido dirigido por el uso sofisticado de las tecnologías de la información y las comunicaciones (ICT), proceso en el cual HPC ha jugado un rol fundamental.

Nuestros servicios están diseñados para ofrecer soporte al ciclo de vida completo de la investigación e innovación basada en HPC.

== Misión del NLHPC ==
La consolidación de una facilidad a nivel nacional de HPC al ofrecer servicios de alta calidad y training avanzado para así responder a la alta demanda de computación científica, desarrollando lazos entre grupos de investigación, la industria y el sector público.

== Visión del NLHPC ==
Visionamos al NLHPC como un centro altamente competitivo con una gama de servicios para la investigación en computación de alto rendimiento de calidad de clase mundial.

== Objetivo General ==
El NLHPC servirá como socio IT clave para los proyectos de investigación basados en HPC a gran escala.

=== Objetivos específicos ===
Desarrollar y dar soporte a recursos computacionales y de redes eficaces y confiables permitiendo a investigadores nacionales tener acceso a capacidad HPC para así resolver intensos problemas científicos de computación y data. Estimular y participar en la creación de una red nacional de alta velocidad para la transmisión de data de investigación Usar y explorar arquitecturas y técnicas innovadoras para acelerar la computación científica. Gatillar nuevas iniciativas industriales en HPC. Ayudar a educar a las próximas generaciones de científicos e ingenieros en HPC. Incrementar la conciencia social sobre el rol de HPC en la sociedad contemporánea y el desarrollo tecnológico.

== Infraestructura Guacolda-Leftraru Epu ==
=== Infraestructura Leftraru Epu===
* 280 TFlops total de rendimiento (sin coprocesadores)
* 7.360 cores total de cómputo
* 24.320 GB total de memoria RAM
* 27 nodos main
** 2 x AMD EPYC 9754 @ 2.25GHz, 128 cores c/u
** 768 GB de RAM c/u
* 2 nodos master
** 2 x AMD EPYC 9224 @ 2.5GHz Processor, 24 cores c/u
** 384 GB de RAM c/u
* 2 nodos gpu MI210
** 2 x AMD EPYC 9224 @ 2.5GHz Processor, 24 cores c/u
** 1536 GB de RAM c/u
** 6 tarjetas AMD Instinct MI210 c/u
* 1 nodo gpu MI100
** 2 x AMD EPYC 7713 @ 2.0GHz, 64 cores c/u
** 502 GB de RAM c/u
** 2 tarjetas AMD Instinct MI100 c/u.
* Infiniband HDR 100 Gbps
* Red servicio 1 Gpbs
* Red XClarity Controller para administración de hardware
* Racks enfriados por agua
* Enfriamiento in-row respaldo

=== Infraestructura Guacolda ===

* 150 TFlops total de rendimiento (sin coprocesadores)
* 2.596 cores total de cómputo
* 16.235 GB total de memoria RAM
* 48 nodos
** 2 x Intel(R) Xeon(R) Gold 6152 CPU @ 2.10GHz. 22 cores c/u 187 GB de RAM
* 9 nodos
** 2 x Intel(R) Xeon(R) Gold 6152 CPU @ 2.10GHz. 22 cores c/u 765 GB de RAM
* 2 nodos
** 2 x Intel(R) Xeon(R) Gold 6152 CPU @ 2.10GHz. 22 cores c/u 187 GB de RAM
** 2x NVIDIA Tesla V100 c/u
* Infiniband FDR 56 Gbps
* Racks enfriados por agua
* Enfriamiento in-row respaldo
* UPS 120 KVA autonomia: 30 mins

=== Almacenamiento Cluster ===
* Almacenamiento paralelo de clase mundial
* Alto rendimiento en operaciones IO
* Tolerante a fallas (alta disponibilidad)
* Interconexión infiniband
* Capacidades Big Data

Características en Guacolda-Leftraru Epu

* 4 PB de almacenamiento IBM Elastic Storage System (IBM ESS 3200)
* Almacenamiento metadata separado
* 2 controladoras SFA en H.A

Descripción General del Sistema

2024-04-18T19:06:13Z

Jmorales: /* Infraestructura Guacolda */

== National Laboratory for High Performance Computing ==
El NLHPC en Chile está dirigido a la instalación en Chile de una capacidad computacional que pueda satisfacer la demanda científica nacional de computación de alto rendimiento (HPC), ofreciendo servicios de alta calidad y promoviendo su uso en las problemáticas de Investigación tanto básica como también aplicada, con énfasis en aplicaciones industriales. En años recientes, el desarrollo de las ciencias aplicadas y la industria ha sido dirigido por el uso sofisticado de las tecnologías de la información y las comunicaciones (ICT), proceso en el cual HPC ha jugado un rol fundamental.

Nuestros servicios están diseñados para ofrecer soporte al ciclo de vida completo de la investigación e innovación basada en HPC.

== Misión del NLHPC ==
La consolidación de una facilidad a nivel nacional de HPC al ofrecer servicios de alta calidad y training avanzado para así responder a la alta demanda de computación científica, desarrollando lazos entre grupos de investigación, la industria y el sector público.

== Visión del NLHPC ==
Visionamos al NLHPC como un centro altamente competitivo con una gama de servicios para la investigación en computación de alto rendimiento de calidad de clase mundial.

== Objetivo General ==
El NLHPC servirá como socio IT clave para los proyectos de investigación basados en HPC a gran escala.

=== Objetivos específicos ===
Desarrollar y dar soporte a recursos computacionales y de redes eficaces y confiables permitiendo a investigadores nacionales tener acceso a capacidad HPC para así resolver intensos problemas científicos de computación y data. Estimular y participar en la creación de una red nacional de alta velocidad para la transmisión de data de investigación Usar y explorar arquitecturas y técnicas innovadoras para acelerar la computación científica. Gatillar nuevas iniciativas industriales en HPC. Ayudar a educar a las próximas generaciones de científicos e ingenieros en HPC. Incrementar la conciencia social sobre el rol de HPC en la sociedad contemporánea y el desarrollo tecnológico.

== Infraestructura Guacolda-Leftraru Epu ==
=== Infraestructura Leftraru Epu===
* 280 TFlops total de rendimiento (sin coprocesadores)
* 7.360 cores total de cómputo
* 24.320 GB total de memoria RAM
* 27 nodos main
** 2 x AMD EPYC 9754 @ 2.25GHz, 128 cores c/u 768 GB de RAM
* 2 nodos master
** 2 x AMD EPYC 9224 @ 2.5GHz Processor, 24 cores c/u 384 GB de RAM
* 2 nodos gpu MI210
** 2 x AMD EPYC 9224 @ 2.5GHz Processor, 24 cores c/u 1536 GB de RAM
** 6 tarjetas AMD Instinct MI210
* 1 nodo gpu MI100
** 2 x AMD EPYC 7713 @ 2.0GHz, 64 cores c/u, 502 GB de RAM, 2 tarjetas AMD Instinct MI100 c/u.
* Infiniband HDR 100 Gbps
* Red servicio 1 Gpbs
* Red XClarity Controller para administración de hardware
* Racks enfriados por agua
* Enfriamiento in-row respaldo
* UPS 120 KVA autonomia: 30 mins

=== Infraestructura Guacolda ===

* 150 TFlops total de rendimiento (sin coprocesadores)
* 2.596 cores total de cómputo
* 16.235 GB total de memoria RAM
* 48 nodos
** 2 x Intel(R) Xeon(R) Gold 6152 CPU @ 2.10GHz. 22 cores c/u 187 GB de RAM
* 9 nodos
** 2 x Intel(R) Xeon(R) Gold 6152 CPU @ 2.10GHz. 22 cores c/u 765 GB de RAM
* 2 nodos
** 2 x Intel(R) Xeon(R) Gold 6152 CPU @ 2.10GHz. 22 cores c/u 187 GB de RAM
** 2x NVIDIA Tesla V100 c/u
* Infiniband FDR 56 Gbps
* Racks enfriados por agua
* Enfriamiento in-row respaldo
* UPS 120 KVA autonomia: 30 mins

=== Almacenamiento Cluster ===
* Almacenamiento paralelo de clase mundial
* Alto rendimiento en operaciones IO
* Tolerante a fallas (alta disponibilidad)
* Interconexión infiniband
* Capacidades Big Data

Características en Guacolda-Leftraru Epu

* 4 PB de almacenamiento IBM Elastic Storage System (IBM ESS 3200)
* Almacenamiento metadata separado
* 2 controladoras SFA en H.A

Descripción General del Sistema

2024-04-18T19:05:05Z

Jmorales: /* Infraestructura Leftraru Epu */

== National Laboratory for High Performance Computing ==
El NLHPC en Chile está dirigido a la instalación en Chile de una capacidad computacional que pueda satisfacer la demanda científica nacional de computación de alto rendimiento (HPC), ofreciendo servicios de alta calidad y promoviendo su uso en las problemáticas de Investigación tanto básica como también aplicada, con énfasis en aplicaciones industriales. En años recientes, el desarrollo de las ciencias aplicadas y la industria ha sido dirigido por el uso sofisticado de las tecnologías de la información y las comunicaciones (ICT), proceso en el cual HPC ha jugado un rol fundamental.

Nuestros servicios están diseñados para ofrecer soporte al ciclo de vida completo de la investigación e innovación basada en HPC.

== Misión del NLHPC ==
La consolidación de una facilidad a nivel nacional de HPC al ofrecer servicios de alta calidad y training avanzado para así responder a la alta demanda de computación científica, desarrollando lazos entre grupos de investigación, la industria y el sector público.

== Visión del NLHPC ==
Visionamos al NLHPC como un centro altamente competitivo con una gama de servicios para la investigación en computación de alto rendimiento de calidad de clase mundial.

== Objetivo General ==
El NLHPC servirá como socio IT clave para los proyectos de investigación basados en HPC a gran escala.

=== Objetivos específicos ===
Desarrollar y dar soporte a recursos computacionales y de redes eficaces y confiables permitiendo a investigadores nacionales tener acceso a capacidad HPC para así resolver intensos problemas científicos de computación y data. Estimular y participar en la creación de una red nacional de alta velocidad para la transmisión de data de investigación Usar y explorar arquitecturas y técnicas innovadoras para acelerar la computación científica. Gatillar nuevas iniciativas industriales en HPC. Ayudar a educar a las próximas generaciones de científicos e ingenieros en HPC. Incrementar la conciencia social sobre el rol de HPC en la sociedad contemporánea y el desarrollo tecnológico.

== Infraestructura Guacolda-Leftraru Epu ==
=== Infraestructura Leftraru Epu===
* 280 TFlops total de rendimiento (sin coprocesadores)
* 7.360 cores total de cómputo
* 24.320 GB total de memoria RAM
* 27 nodos main
** 2 x AMD EPYC 9754 @ 2.25GHz, 128 cores c/u 768 GB de RAM
* 2 nodos master
** 2 x AMD EPYC 9224 @ 2.5GHz Processor, 24 cores c/u 384 GB de RAM
* 2 nodos gpu MI210
** 2 x AMD EPYC 9224 @ 2.5GHz Processor, 24 cores c/u 1536 GB de RAM
** 6 tarjetas AMD Instinct MI210
* 1 nodo gpu MI100
** 2 x AMD EPYC 7713 @ 2.0GHz, 64 cores c/u, 502 GB de RAM, 2 tarjetas AMD Instinct MI100 c/u.
* Infiniband HDR 100 Gbps
* Red servicio 1 Gpbs
* Red XClarity Controller para administración de hardware
* Racks enfriados por agua
* Enfriamiento in-row respaldo
* UPS 120 KVA autonomia: 30 mins

=== Infraestructura Guacolda ===

* 150 TFlops total de rendimiento (sin coprocesadores)
* 2.596 cores total de cómputo
* 16.235 GB total de memoria RAM
* 48 nodos, 2 x Intel(R) Xeon(R) Gold 6152 CPU @ 2.10GHz. 22 cores c/u 187 GB de RAM
* 9 nodos, 2 x Intel(R) Xeon(R) Gold 6152 CPU @ 2.10GHz. 22 cores c/u 765 GB de RAM
* 2 nodos, 2 x Intel(R) Xeon(R) Gold 6152 CPU @ 2.10GHz. 22 cores c/u 187 GB de RAM y 2x NVIDIA Tesla V100 c/u
* Infiniband FDR 56 Gbps
* Racks enfriados por agua
* Enfriamiento in-row respaldo
* UPS 120 KVA autonomia: 30 mins

=== Almacenamiento Cluster ===
* Almacenamiento paralelo de clase mundial
* Alto rendimiento en operaciones IO
* Tolerante a fallas (alta disponibilidad)
* Interconexión infiniband
* Capacidades Big Data

Características en Guacolda-Leftraru Epu

* 4 PB de almacenamiento IBM Elastic Storage System (IBM ESS 3200)
* Almacenamiento metadata separado
* 2 controladoras SFA en H.A

Descripción General del Sistema

2024-04-18T19:03:43Z

Jmorales: /* Infraestructura Leftraru Epu */

== National Laboratory for High Performance Computing ==
El NLHPC en Chile está dirigido a la instalación en Chile de una capacidad computacional que pueda satisfacer la demanda científica nacional de computación de alto rendimiento (HPC), ofreciendo servicios de alta calidad y promoviendo su uso en las problemáticas de Investigación tanto básica como también aplicada, con énfasis en aplicaciones industriales. En años recientes, el desarrollo de las ciencias aplicadas y la industria ha sido dirigido por el uso sofisticado de las tecnologías de la información y las comunicaciones (ICT), proceso en el cual HPC ha jugado un rol fundamental.

Nuestros servicios están diseñados para ofrecer soporte al ciclo de vida completo de la investigación e innovación basada en HPC.

== Misión del NLHPC ==
La consolidación de una facilidad a nivel nacional de HPC al ofrecer servicios de alta calidad y training avanzado para así responder a la alta demanda de computación científica, desarrollando lazos entre grupos de investigación, la industria y el sector público.

== Visión del NLHPC ==
Visionamos al NLHPC como un centro altamente competitivo con una gama de servicios para la investigación en computación de alto rendimiento de calidad de clase mundial.

== Objetivo General ==
El NLHPC servirá como socio IT clave para los proyectos de investigación basados en HPC a gran escala.

=== Objetivos específicos ===
Desarrollar y dar soporte a recursos computacionales y de redes eficaces y confiables permitiendo a investigadores nacionales tener acceso a capacidad HPC para así resolver intensos problemas científicos de computación y data. Estimular y participar en la creación de una red nacional de alta velocidad para la transmisión de data de investigación Usar y explorar arquitecturas y técnicas innovadoras para acelerar la computación científica. Gatillar nuevas iniciativas industriales en HPC. Ayudar a educar a las próximas generaciones de científicos e ingenieros en HPC. Incrementar la conciencia social sobre el rol de HPC en la sociedad contemporánea y el desarrollo tecnológico.

== Infraestructura Guacolda-Leftraru Epu ==
=== Infraestructura Leftraru Epu===
* 280 TFlops total de rendimiento (sin coprocesadores)
* 7.360 cores total de cómputo
* 24.320 GB total de memoria RAM
* 27 nodos main
** 2 x AMD EPYC 9754 @ 2.25GHz, 128 cores c/u 768 GB de RAM
* 2 nodos master
** 2 x AMD EPYC 9224 @ 2.5GHz Processor, 24 cores c/u 384 GB de RAM
* 2 nodos gpu MI210
** 2 x AMD EPYC 9224 @ 2.5GHz Processor, 24 cores c/u 1536 GB de RAM,
* 6 tarjetas AMD Instinct MI210
* 1 nodo gpu MI100
** 2 x AMD EPYC 7713 @ 2.0GHz, 64 cores c/u, 502 GB de RAM, 2 tarjetas AMD Instinct MI100 c/u.
* Infiniband HDR 100 Gbps
* Red servicio 1 Gpbs
* Red XClarity Controller para administración de hardware
* Racks enfriados por agua
* Enfriamiento in-row respaldo
* UPS 120 KVA autonomia: 30 mins

=== Infraestructura Guacolda ===

* 150 TFlops total de rendimiento (sin coprocesadores)
* 2.596 cores total de cómputo
* 16.235 GB total de memoria RAM
* 48 nodos, 2 x Intel(R) Xeon(R) Gold 6152 CPU @ 2.10GHz. 22 cores c/u 187 GB de RAM
* 9 nodos, 2 x Intel(R) Xeon(R) Gold 6152 CPU @ 2.10GHz. 22 cores c/u 765 GB de RAM
* 2 nodos, 2 x Intel(R) Xeon(R) Gold 6152 CPU @ 2.10GHz. 22 cores c/u 187 GB de RAM y 2x NVIDIA Tesla V100 c/u
* Infiniband FDR 56 Gbps
* Racks enfriados por agua
* Enfriamiento in-row respaldo
* UPS 120 KVA autonomia: 30 mins

=== Almacenamiento Cluster ===
* Almacenamiento paralelo de clase mundial
* Alto rendimiento en operaciones IO
* Tolerante a fallas (alta disponibilidad)
* Interconexión infiniband
* Capacidades Big Data

Características en Guacolda-Leftraru Epu

* 4 PB de almacenamiento IBM Elastic Storage System (IBM ESS 3200)
* Almacenamiento metadata separado
* 2 controladoras SFA en H.A

Descripción General del Sistema

2024-04-18T19:02:44Z

Jmorales: /* Infraestructura Leftraru Epu */

== National Laboratory for High Performance Computing ==
El NLHPC en Chile está dirigido a la instalación en Chile de una capacidad computacional que pueda satisfacer la demanda científica nacional de computación de alto rendimiento (HPC), ofreciendo servicios de alta calidad y promoviendo su uso en las problemáticas de Investigación tanto básica como también aplicada, con énfasis en aplicaciones industriales. En años recientes, el desarrollo de las ciencias aplicadas y la industria ha sido dirigido por el uso sofisticado de las tecnologías de la información y las comunicaciones (ICT), proceso en el cual HPC ha jugado un rol fundamental.

Nuestros servicios están diseñados para ofrecer soporte al ciclo de vida completo de la investigación e innovación basada en HPC.

== Misión del NLHPC ==
La consolidación de una facilidad a nivel nacional de HPC al ofrecer servicios de alta calidad y training avanzado para así responder a la alta demanda de computación científica, desarrollando lazos entre grupos de investigación, la industria y el sector público.

== Visión del NLHPC ==
Visionamos al NLHPC como un centro altamente competitivo con una gama de servicios para la investigación en computación de alto rendimiento de calidad de clase mundial.

== Objetivo General ==
El NLHPC servirá como socio IT clave para los proyectos de investigación basados en HPC a gran escala.

=== Objetivos específicos ===
Desarrollar y dar soporte a recursos computacionales y de redes eficaces y confiables permitiendo a investigadores nacionales tener acceso a capacidad HPC para así resolver intensos problemas científicos de computación y data. Estimular y participar en la creación de una red nacional de alta velocidad para la transmisión de data de investigación Usar y explorar arquitecturas y técnicas innovadoras para acelerar la computación científica. Gatillar nuevas iniciativas industriales en HPC. Ayudar a educar a las próximas generaciones de científicos e ingenieros en HPC. Incrementar la conciencia social sobre el rol de HPC en la sociedad contemporánea y el desarrollo tecnológico.

== Infraestructura Guacolda-Leftraru Epu ==
=== Infraestructura Leftraru Epu===
* 280 TFlops total de rendimiento (sin coprocesadores)
* 7.360 cores total de cómputo
* 24.320 GB total de memoria RAM
* 27 nodos main,
** 2 x AMD EPYC 9754 @ 2.25GHz, 128 cores c/u 768 GB de RAM
* 2 nodos master, 2 x AMD EPYC 9224 @ 2.5GHz Processor, 24 cores c/u 384 GB de RAM
* 2 nodos gpu MI210, 2 x AMD EPYC 9224 @ 2.5GHz Processor, 24 cores c/u 1536 GB de RAM, * 6 tarjetas AMD Instinct MI210
*1 nodo gpu MI100, 2 x AMD EPYC 7713 @ 2.0GHz, 64 cores c/u, 502 GB de RAM, 2 tarjetas AMD Instinct MI100 c/u.
* Infiniband HDR 100 Gbps
* Red servicio 1 Gpbs
* Red XClarity Controller para administración de hardware
* Racks enfriados por agua
* Enfriamiento in-row respaldo
* UPS 120 KVA autonomia: 30 mins

=== Infraestructura Guacolda ===

* 150 TFlops total de rendimiento (sin coprocesadores)
* 2.596 cores total de cómputo
* 16.235 GB total de memoria RAM
* 48 nodos, 2 x Intel(R) Xeon(R) Gold 6152 CPU @ 2.10GHz. 22 cores c/u 187 GB de RAM
* 9 nodos, 2 x Intel(R) Xeon(R) Gold 6152 CPU @ 2.10GHz. 22 cores c/u 765 GB de RAM
* 2 nodos, 2 x Intel(R) Xeon(R) Gold 6152 CPU @ 2.10GHz. 22 cores c/u 187 GB de RAM y 2x NVIDIA Tesla V100 c/u
* Infiniband FDR 56 Gbps
* Racks enfriados por agua
* Enfriamiento in-row respaldo
* UPS 120 KVA autonomia: 30 mins

=== Almacenamiento Cluster ===
* Almacenamiento paralelo de clase mundial
* Alto rendimiento en operaciones IO
* Tolerante a fallas (alta disponibilidad)
* Interconexión infiniband
* Capacidades Big Data

Características en Guacolda-Leftraru Epu

* 4 PB de almacenamiento IBM Elastic Storage System (IBM ESS 3200)
* Almacenamiento metadata separado
* 2 controladoras SFA en H.A

Descripción General del Sistema

2024-04-18T19:01:23Z

Jmorales: /* Infraestructura Guacolda */

== National Laboratory for High Performance Computing ==
El NLHPC en Chile está dirigido a la instalación en Chile de una capacidad computacional que pueda satisfacer la demanda científica nacional de computación de alto rendimiento (HPC), ofreciendo servicios de alta calidad y promoviendo su uso en las problemáticas de Investigación tanto básica como también aplicada, con énfasis en aplicaciones industriales. En años recientes, el desarrollo de las ciencias aplicadas y la industria ha sido dirigido por el uso sofisticado de las tecnologías de la información y las comunicaciones (ICT), proceso en el cual HPC ha jugado un rol fundamental.

Nuestros servicios están diseñados para ofrecer soporte al ciclo de vida completo de la investigación e innovación basada en HPC.

== Misión del NLHPC ==
La consolidación de una facilidad a nivel nacional de HPC al ofrecer servicios de alta calidad y training avanzado para así responder a la alta demanda de computación científica, desarrollando lazos entre grupos de investigación, la industria y el sector público.

== Visión del NLHPC ==
Visionamos al NLHPC como un centro altamente competitivo con una gama de servicios para la investigación en computación de alto rendimiento de calidad de clase mundial.

== Objetivo General ==
El NLHPC servirá como socio IT clave para los proyectos de investigación basados en HPC a gran escala.

=== Objetivos específicos ===
Desarrollar y dar soporte a recursos computacionales y de redes eficaces y confiables permitiendo a investigadores nacionales tener acceso a capacidad HPC para así resolver intensos problemas científicos de computación y data. Estimular y participar en la creación de una red nacional de alta velocidad para la transmisión de data de investigación Usar y explorar arquitecturas y técnicas innovadoras para acelerar la computación científica. Gatillar nuevas iniciativas industriales en HPC. Ayudar a educar a las próximas generaciones de científicos e ingenieros en HPC. Incrementar la conciencia social sobre el rol de HPC en la sociedad contemporánea y el desarrollo tecnológico.

== Infraestructura Guacolda-Leftraru Epu ==
=== Infraestructura Leftraru Epu===
* 280 TFlops total de rendimiento (sin coprocesadores)
* 7.360 cores total de cómputo
* 24.320 GB total de memoria RAM
* 27 nodos main, 2 x AMD EPYC 9754 @ 2.25GHz, 128 cores c/u 768 GB de RAM
* 2 nodos master, 2 x AMD EPYC 9224 @ 2.5GHz Processor, 24 cores c/u 384 GB de RAM
* 2 nodos gpu MI210, 2 x AMD EPYC 9224 @ 2.5GHz Processor, 24 cores c/u 1536 GB de RAM, * 6 tarjetas AMD Instinct MI210
*1 nodo gpu MI100, 2 x AMD EPYC 7713 @ 2.0GHz, 64 cores c/u, 502 GB de RAM, 2 tarjetas AMD Instinct MI100 c/u.
* Infiniband HDR 100 Gbps
* Red servicio 1 Gpbs
* Red XClarity Controller para administración de hardware
* Racks enfriados por agua
* Enfriamiento in-row respaldo
* UPS 120 KVA autonomia: 30 mins

=== Infraestructura Guacolda ===

* 150 TFlops total de rendimiento (sin coprocesadores)
* 2.596 cores total de cómputo
* 16.235 GB total de memoria RAM
* 48 nodos, 2 x Intel(R) Xeon(R) Gold 6152 CPU @ 2.10GHz. 22 cores c/u 187 GB de RAM
* 9 nodos, 2 x Intel(R) Xeon(R) Gold 6152 CPU @ 2.10GHz. 22 cores c/u 765 GB de RAM
* 2 nodos, 2 x Intel(R) Xeon(R) Gold 6152 CPU @ 2.10GHz. 22 cores c/u 187 GB de RAM y 2x NVIDIA Tesla V100 c/u
* Infiniband FDR 56 Gbps
* Racks enfriados por agua
* Enfriamiento in-row respaldo
* UPS 120 KVA autonomia: 30 mins

=== Almacenamiento Cluster ===
* Almacenamiento paralelo de clase mundial
* Alto rendimiento en operaciones IO
* Tolerante a fallas (alta disponibilidad)
* Interconexión infiniband
* Capacidades Big Data

Características en Guacolda-Leftraru Epu

* 4 PB de almacenamiento IBM Elastic Storage System (IBM ESS 3200)
* Almacenamiento metadata separado
* 2 controladoras SFA en H.A

Descripción General del Sistema

2024-04-18T18:59:55Z

Jmorales: /* Infraestructura Leftraru Epu */

== National Laboratory for High Performance Computing ==
El NLHPC en Chile está dirigido a la instalación en Chile de una capacidad computacional que pueda satisfacer la demanda científica nacional de computación de alto rendimiento (HPC), ofreciendo servicios de alta calidad y promoviendo su uso en las problemáticas de Investigación tanto básica como también aplicada, con énfasis en aplicaciones industriales. En años recientes, el desarrollo de las ciencias aplicadas y la industria ha sido dirigido por el uso sofisticado de las tecnologías de la información y las comunicaciones (ICT), proceso en el cual HPC ha jugado un rol fundamental.

Nuestros servicios están diseñados para ofrecer soporte al ciclo de vida completo de la investigación e innovación basada en HPC.

== Misión del NLHPC ==
La consolidación de una facilidad a nivel nacional de HPC al ofrecer servicios de alta calidad y training avanzado para así responder a la alta demanda de computación científica, desarrollando lazos entre grupos de investigación, la industria y el sector público.

== Visión del NLHPC ==
Visionamos al NLHPC como un centro altamente competitivo con una gama de servicios para la investigación en computación de alto rendimiento de calidad de clase mundial.

== Objetivo General ==
El NLHPC servirá como socio IT clave para los proyectos de investigación basados en HPC a gran escala.

=== Objetivos específicos ===
Desarrollar y dar soporte a recursos computacionales y de redes eficaces y confiables permitiendo a investigadores nacionales tener acceso a capacidad HPC para así resolver intensos problemas científicos de computación y data. Estimular y participar en la creación de una red nacional de alta velocidad para la transmisión de data de investigación Usar y explorar arquitecturas y técnicas innovadoras para acelerar la computación científica. Gatillar nuevas iniciativas industriales en HPC. Ayudar a educar a las próximas generaciones de científicos e ingenieros en HPC. Incrementar la conciencia social sobre el rol de HPC en la sociedad contemporánea y el desarrollo tecnológico.

== Infraestructura Guacolda-Leftraru Epu ==
=== Infraestructura Leftraru Epu===
* 280 TFlops total de rendimiento (sin coprocesadores)
* 7.360 cores total de cómputo
* 24.320 GB total de memoria RAM
* 27 nodos main, 2 x AMD EPYC 9754 @ 2.25GHz, 128 cores c/u 768 GB de RAM
* 2 nodos master, 2 x AMD EPYC 9224 @ 2.5GHz Processor, 24 cores c/u 384 GB de RAM
* 2 nodos gpu MI210, 2 x AMD EPYC 9224 @ 2.5GHz Processor, 24 cores c/u 1536 GB de RAM, * 6 tarjetas AMD Instinct MI210
*1 nodo gpu MI100, 2 x AMD EPYC 7713 @ 2.0GHz, 64 cores c/u, 502 GB de RAM, 2 tarjetas AMD Instinct MI100 c/u.
* Infiniband HDR 100 Gbps
* Red servicio 1 Gpbs
* Red XClarity Controller para administración de hardware
* Racks enfriados por agua
* Enfriamiento in-row respaldo
* UPS 120 KVA autonomia: 30 mins

=== Infraestructura Guacolda ===
* 150 TFlops sin coprocesadores
* 48 nodos, 2 x Intel(R) Xeon(R) Gold 6152 CPU @ 2.10GHz. 22 cores c/u 187 GB de RAM
* 9 nodos, 2 x Intel(R) Xeon(R) Gold 6152 CPU @ 2.10GHz. 22 cores c/u 765 GB de RAM
* 2 nodos, 2 x Intel(R) Xeon(R) Gold 6152 CPU @ 2.10GHz. 22 cores c/u 187 GB de RAM y 2x NVIDIA Tesla V100 c/u
* Nueva generación de procesadores Intel Xeon Skylake (SP)
* Intel Advanced Vector Extensions 512 (Intel AVX-512)
* Ganancia en el rendimiento en aplicaciones de deep learning de hasta 113x (respecto a los procesadores de Leftraru Epu)

=== Almacenamiento Cluster ===
* Almacenamiento paralelo de clase mundial
* Alto rendimiento en operaciones IO
* Tolerante a fallas (alta disponibilidad)
* Interconexión infiniband
* Capacidades Big Data

Características en Guacolda-Leftraru Epu

* 4 PB de almacenamiento IBM Elastic Storage System (IBM ESS 3200)
* Almacenamiento metadata separado
* 2 controladoras SFA en H.A

Descripción General del Sistema

2024-04-18T18:55:26Z

Jmorales: /* Almacenamiento Cluster */

== National Laboratory for High Performance Computing ==
El NLHPC en Chile está dirigido a la instalación en Chile de una capacidad computacional que pueda satisfacer la demanda científica nacional de computación de alto rendimiento (HPC), ofreciendo servicios de alta calidad y promoviendo su uso en las problemáticas de Investigación tanto básica como también aplicada, con énfasis en aplicaciones industriales. En años recientes, el desarrollo de las ciencias aplicadas y la industria ha sido dirigido por el uso sofisticado de las tecnologías de la información y las comunicaciones (ICT), proceso en el cual HPC ha jugado un rol fundamental.

Nuestros servicios están diseñados para ofrecer soporte al ciclo de vida completo de la investigación e innovación basada en HPC.

== Misión del NLHPC ==
La consolidación de una facilidad a nivel nacional de HPC al ofrecer servicios de alta calidad y training avanzado para así responder a la alta demanda de computación científica, desarrollando lazos entre grupos de investigación, la industria y el sector público.

== Visión del NLHPC ==
Visionamos al NLHPC como un centro altamente competitivo con una gama de servicios para la investigación en computación de alto rendimiento de calidad de clase mundial.

== Objetivo General ==
El NLHPC servirá como socio IT clave para los proyectos de investigación basados en HPC a gran escala.

=== Objetivos específicos ===
Desarrollar y dar soporte a recursos computacionales y de redes eficaces y confiables permitiendo a investigadores nacionales tener acceso a capacidad HPC para así resolver intensos problemas científicos de computación y data. Estimular y participar en la creación de una red nacional de alta velocidad para la transmisión de data de investigación Usar y explorar arquitecturas y técnicas innovadoras para acelerar la computación científica. Gatillar nuevas iniciativas industriales en HPC. Ayudar a educar a las próximas generaciones de científicos e ingenieros en HPC. Incrementar la conciencia social sobre el rol de HPC en la sociedad contemporánea y el desarrollo tecnológico.

== Infraestructura Guacolda-Leftraru Epu ==
=== Infraestructura Leftraru Epu===
* 44 TFlops
* 2640 cores
* 132 nodos slims
* 12 Xeon Phi
* Infiniband FDR 56 Gbps
* Red servicio 1 Gpbs
* Red iLO para administracion de hardware
* Racks enfriados por agua
* Enfriamiento in-row respaldo
* UPS 120 KVA autonomia: 30 mins

=== Infraestructura Guacolda ===
* 150 TFlops sin coprocesadores
* 48 nodos, 2 x Intel(R) Xeon(R) Gold 6152 CPU @ 2.10GHz. 22 cores c/u 187 GB de RAM
* 9 nodos, 2 x Intel(R) Xeon(R) Gold 6152 CPU @ 2.10GHz. 22 cores c/u 765 GB de RAM
* 2 nodos, 2 x Intel(R) Xeon(R) Gold 6152 CPU @ 2.10GHz. 22 cores c/u 187 GB de RAM y 2x NVIDIA Tesla V100 c/u
* Nueva generación de procesadores Intel Xeon Skylake (SP)
* Intel Advanced Vector Extensions 512 (Intel AVX-512)
* Ganancia en el rendimiento en aplicaciones de deep learning de hasta 113x (respecto a los procesadores de Leftraru Epu)

=== Almacenamiento Cluster ===
* Almacenamiento paralelo de clase mundial
* Alto rendimiento en operaciones IO
* Tolerante a fallas (alta disponibilidad)
* Interconexión infiniband
* Capacidades Big Data

Características en Guacolda-Leftraru Epu

* 4 PB de almacenamiento IBM Elastic Storage System (IBM ESS 3200)
* Almacenamiento metadata separado
* 2 controladoras SFA en H.A

Descripción General del Sistema

2024-04-18T18:54:59Z

Jmorales: /* Infraestructura Guacolda */

== National Laboratory for High Performance Computing ==
El NLHPC en Chile está dirigido a la instalación en Chile de una capacidad computacional que pueda satisfacer la demanda científica nacional de computación de alto rendimiento (HPC), ofreciendo servicios de alta calidad y promoviendo su uso en las problemáticas de Investigación tanto básica como también aplicada, con énfasis en aplicaciones industriales. En años recientes, el desarrollo de las ciencias aplicadas y la industria ha sido dirigido por el uso sofisticado de las tecnologías de la información y las comunicaciones (ICT), proceso en el cual HPC ha jugado un rol fundamental.

Nuestros servicios están diseñados para ofrecer soporte al ciclo de vida completo de la investigación e innovación basada en HPC.

== Misión del NLHPC ==
La consolidación de una facilidad a nivel nacional de HPC al ofrecer servicios de alta calidad y training avanzado para así responder a la alta demanda de computación científica, desarrollando lazos entre grupos de investigación, la industria y el sector público.

== Visión del NLHPC ==
Visionamos al NLHPC como un centro altamente competitivo con una gama de servicios para la investigación en computación de alto rendimiento de calidad de clase mundial.

== Objetivo General ==
El NLHPC servirá como socio IT clave para los proyectos de investigación basados en HPC a gran escala.

=== Objetivos específicos ===
Desarrollar y dar soporte a recursos computacionales y de redes eficaces y confiables permitiendo a investigadores nacionales tener acceso a capacidad HPC para así resolver intensos problemas científicos de computación y data. Estimular y participar en la creación de una red nacional de alta velocidad para la transmisión de data de investigación Usar y explorar arquitecturas y técnicas innovadoras para acelerar la computación científica. Gatillar nuevas iniciativas industriales en HPC. Ayudar a educar a las próximas generaciones de científicos e ingenieros en HPC. Incrementar la conciencia social sobre el rol de HPC en la sociedad contemporánea y el desarrollo tecnológico.

== Infraestructura Guacolda-Leftraru Epu ==
=== Infraestructura Leftraru Epu===
* 44 TFlops
* 2640 cores
* 132 nodos slims
* 12 Xeon Phi
* Infiniband FDR 56 Gbps
* Red servicio 1 Gpbs
* Red iLO para administracion de hardware
* Racks enfriados por agua
* Enfriamiento in-row respaldo
* UPS 120 KVA autonomia: 30 mins

=== Infraestructura Guacolda ===
* 150 TFlops sin coprocesadores
* 48 nodos, 2 x Intel(R) Xeon(R) Gold 6152 CPU @ 2.10GHz. 22 cores c/u 187 GB de RAM
* 9 nodos, 2 x Intel(R) Xeon(R) Gold 6152 CPU @ 2.10GHz. 22 cores c/u 765 GB de RAM
* 2 nodos, 2 x Intel(R) Xeon(R) Gold 6152 CPU @ 2.10GHz. 22 cores c/u 187 GB de RAM y 2x NVIDIA Tesla V100 c/u
* Nueva generación de procesadores Intel Xeon Skylake (SP)
* Intel Advanced Vector Extensions 512 (Intel AVX-512)
* Ganancia en el rendimiento en aplicaciones de deep learning de hasta 113x (respecto a los procesadores de Leftraru Epu)

=== Almacenamiento Cluster ===
* Almacenamiento paralelo de clase mundial
* Alto rendimiento en operaciones IO
* Tolerante a fallas (alta disponibilidad)
* Interconexión infiniband
* Capacidades Big Data

Características en Guacolda-Leftraru

* 4 PB de almacenamiento IBM Elastic Storage System (IBM ESS 3200)
* Almacenamiento metadata separado
* 2 controladoras SFA en H.A

Descripción General del Sistema

2024-04-18T18:54:22Z

Jmorales: /* Infraestructura Leftraru */

== National Laboratory for High Performance Computing ==
El NLHPC en Chile está dirigido a la instalación en Chile de una capacidad computacional que pueda satisfacer la demanda científica nacional de computación de alto rendimiento (HPC), ofreciendo servicios de alta calidad y promoviendo su uso en las problemáticas de Investigación tanto básica como también aplicada, con énfasis en aplicaciones industriales. En años recientes, el desarrollo de las ciencias aplicadas y la industria ha sido dirigido por el uso sofisticado de las tecnologías de la información y las comunicaciones (ICT), proceso en el cual HPC ha jugado un rol fundamental.

Nuestros servicios están diseñados para ofrecer soporte al ciclo de vida completo de la investigación e innovación basada en HPC.

== Misión del NLHPC ==
La consolidación de una facilidad a nivel nacional de HPC al ofrecer servicios de alta calidad y training avanzado para así responder a la alta demanda de computación científica, desarrollando lazos entre grupos de investigación, la industria y el sector público.

== Visión del NLHPC ==
Visionamos al NLHPC como un centro altamente competitivo con una gama de servicios para la investigación en computación de alto rendimiento de calidad de clase mundial.

== Objetivo General ==
El NLHPC servirá como socio IT clave para los proyectos de investigación basados en HPC a gran escala.

=== Objetivos específicos ===
Desarrollar y dar soporte a recursos computacionales y de redes eficaces y confiables permitiendo a investigadores nacionales tener acceso a capacidad HPC para así resolver intensos problemas científicos de computación y data. Estimular y participar en la creación de una red nacional de alta velocidad para la transmisión de data de investigación Usar y explorar arquitecturas y técnicas innovadoras para acelerar la computación científica. Gatillar nuevas iniciativas industriales en HPC. Ayudar a educar a las próximas generaciones de científicos e ingenieros en HPC. Incrementar la conciencia social sobre el rol de HPC en la sociedad contemporánea y el desarrollo tecnológico.

== Infraestructura Guacolda-Leftraru Epu ==
=== Infraestructura Leftraru Epu===
* 44 TFlops
* 2640 cores
* 132 nodos slims
* 12 Xeon Phi
* Infiniband FDR 56 Gbps
* Red servicio 1 Gpbs
* Red iLO para administracion de hardware
* Racks enfriados por agua
* Enfriamiento in-row respaldo
* UPS 120 KVA autonomia: 30 mins

=== Infraestructura Guacolda ===
* 150 TFlops sin coprocesadores
* 48 nodos, 2 x Intel(R) Xeon(R) Gold 6152 CPU @ 2.10GHz. 22 cores c/u 187 GB de RAM
* 9 nodos, 2 x Intel(R) Xeon(R) Gold 6152 CPU @ 2.10GHz. 22 cores c/u 765 GB de RAM
* 2 nodos, 2 x Intel(R) Xeon(R) Gold 6152 CPU @ 2.10GHz. 22 cores c/u 187 GB de RAM y 2x NVIDIA Tesla V100 c/u
* Nueva generación de procesadores Intel Xeon Skylake (SP)
* Intel Advanced Vector Extensions 512 (Intel AVX-512)
* Ganancia en el rendimiento en aplicaciones de deep learning de hasta 113x (respecto a los procesadores de Leftraru)
=== Almacenamiento Cluster ===
* Almacenamiento paralelo de clase mundial
* Alto rendimiento en operaciones IO
* Tolerante a fallas (alta disponibilidad)
* Interconexión infiniband
* Capacidades Big Data

Características en Guacolda-Leftraru

* 4 PB de almacenamiento IBM Elastic Storage System (IBM ESS 3200)
* Almacenamiento metadata separado
* 2 controladoras SFA en H.A

Descripción General del Sistema

2024-04-18T18:54:00Z

Jmorales: /* Infraestructura Guacolda-Leftraru */

== National Laboratory for High Performance Computing ==
El NLHPC en Chile está dirigido a la instalación en Chile de una capacidad computacional que pueda satisfacer la demanda científica nacional de computación de alto rendimiento (HPC), ofreciendo servicios de alta calidad y promoviendo su uso en las problemáticas de Investigación tanto básica como también aplicada, con énfasis en aplicaciones industriales. En años recientes, el desarrollo de las ciencias aplicadas y la industria ha sido dirigido por el uso sofisticado de las tecnologías de la información y las comunicaciones (ICT), proceso en el cual HPC ha jugado un rol fundamental.

Nuestros servicios están diseñados para ofrecer soporte al ciclo de vida completo de la investigación e innovación basada en HPC.

== Misión del NLHPC ==
La consolidación de una facilidad a nivel nacional de HPC al ofrecer servicios de alta calidad y training avanzado para así responder a la alta demanda de computación científica, desarrollando lazos entre grupos de investigación, la industria y el sector público.

== Visión del NLHPC ==
Visionamos al NLHPC como un centro altamente competitivo con una gama de servicios para la investigación en computación de alto rendimiento de calidad de clase mundial.

== Objetivo General ==
El NLHPC servirá como socio IT clave para los proyectos de investigación basados en HPC a gran escala.

=== Objetivos específicos ===
Desarrollar y dar soporte a recursos computacionales y de redes eficaces y confiables permitiendo a investigadores nacionales tener acceso a capacidad HPC para así resolver intensos problemas científicos de computación y data. Estimular y participar en la creación de una red nacional de alta velocidad para la transmisión de data de investigación Usar y explorar arquitecturas y técnicas innovadoras para acelerar la computación científica. Gatillar nuevas iniciativas industriales en HPC. Ayudar a educar a las próximas generaciones de científicos e ingenieros en HPC. Incrementar la conciencia social sobre el rol de HPC en la sociedad contemporánea y el desarrollo tecnológico.

== Infraestructura Guacolda-Leftraru Epu ==
=== Infraestructura Leftraru ===
* 44 TFlops
* 2640 cores
* 132 nodos slims
* 12 Xeon Phi
* Infiniband FDR 56 Gbps
* Red servicio 1 Gpbs
* Red iLO para administracion de hardware
* Racks enfriados por agua
* Enfriamiento in-row respaldo
* UPS 120 KVA autonomia: 30 mins
=== Infraestructura Guacolda ===
* 150 TFlops sin coprocesadores
* 48 nodos, 2 x Intel(R) Xeon(R) Gold 6152 CPU @ 2.10GHz. 22 cores c/u 187 GB de RAM
* 9 nodos, 2 x Intel(R) Xeon(R) Gold 6152 CPU @ 2.10GHz. 22 cores c/u 765 GB de RAM
* 2 nodos, 2 x Intel(R) Xeon(R) Gold 6152 CPU @ 2.10GHz. 22 cores c/u 187 GB de RAM y 2x NVIDIA Tesla V100 c/u
* Nueva generación de procesadores Intel Xeon Skylake (SP)
* Intel Advanced Vector Extensions 512 (Intel AVX-512)
* Ganancia en el rendimiento en aplicaciones de deep learning de hasta 113x (respecto a los procesadores de Leftraru)
=== Almacenamiento Cluster ===
* Almacenamiento paralelo de clase mundial
* Alto rendimiento en operaciones IO
* Tolerante a fallas (alta disponibilidad)
* Interconexión infiniband
* Capacidades Big Data

Características en Guacolda-Leftraru

* 4 PB de almacenamiento IBM Elastic Storage System (IBM ESS 3200)
* Almacenamiento metadata separado
* 2 controladoras SFA en H.A