Cuenta Lancad Nodo Uami

Nodo UAM.
Contraseña.
La primera actividad a realizar cuando se conecta un nuevo usuario al cluster yoltla,
es asignar una contraseña a su cuenta.
Las políticas establecidas en el cluster para asignación de contraseñas son:
Debe estar formada por al menos 8 caracteres (sin espacios).

Debe contener un carácter minúscula (a-z)
Debe contener un carácter mayuscula (A-Z)
Debe contener un carácter numérico (0-9)
Debe contener un carácter especial (! " # $ % & ' ( ) * + , - . / @)
Al realizarse la primera conexión y después de establecer su nueva contraseña, la

conexión se cerrara. Al volver a conectarse utilizar la nueva contraseña.
Esta primera conexión debe realizarse al nodo de acceso yoltla0. La
sincronización de contraseñas entre ambos nodos de acceso tomara un
par de horas.
Acceso al sistema.
El acceso a los recursos de cómputo del nodo UAM del LANCAD es por medio de 2
servidores que en lo posterior llamaremos nodos de acceso.
El nombre de estos 2 nodos de acceso así como su dirección IP son los siguientes:
yoltla0 148.206.50.61
yoltla1 148.206.50.62
En estos 2 nodos se podrá editar y compilar aplicaciones, pero para ejecutar estas
aplicaciones es necesario crear un archivo de guión o “script” y formarlo en una de
las diferentes colas o particiones para que sea despachado en los nodos de
ejecución.
SSH GNU/Linux OS X
Para conectarse a los nodos de acceso del nodo UAM del LANCAD se requiere de un
shell seguro (secure shell / SSH), en el caso del sistema operativo GNU/Linux o Mac
OS es suficiente con abrir una terminal y ejecutar el comando
ssh -l <nombre de usuario> <dirección IP del nodo de acceso>

*opción -l (letra ele minúscula)
NODO UAM LANCAD

LABORATORIO DE SUPERCÓMPUTO Y VISUALIZACIÓN EN PARALELO
Av. San Rafael Atlixco No. 186, Col. Vicentina, C.P. 09340, Tel. (55)5804-4987, Iztapalapa, Ciudad de México.
otra forma de realizar la conexión es utilizando la notación usuario@maquina
ssh <nombre usuario>@<dirección IP del nodo de acceso>
SSH Windows
Para conectarse a los nodos de acceso del nodo UAM del LANCAD se requiere de un
shell seguro (secure shell / SSH), para el sistema operativo Windows existen varias
alternativas comerciales y libres de clientes SSH.
Los siguientes 2 clientes son gratuitos y sabemos funcionan bien para conexiones
hacia los nodos de acceso desde sistema operativo Windows
PuTTY
Página del proyecto PuTTY_Portable
Enlace de descarga PuTTYPortable_0.68_English.paf.exe
SmarTTY
Página del proyecto SmarTTY
Enlace de descarga PortableSmartty-2.2.zip
*Las versiones portables de software en Windows no requieren instalación y pueden

ser ejecutadas directamente.
Recursos de cómputo.
El acceso a los nodos de cómputo o ejecución que proporciona el nodo UAM del
LANCAD es por medio del administrador de recursos SLURM.
La versión instalada en el cluster es 16.05.4, la documentación puede consultarse
en https://slurm.schedmd.com/documentation.html
Existen 25 particiones para solicitar recursos en el cluster, el nombre de cada una

de estas particiones hace referencia a los recursos máximos que se pueden
solicitar, por ejemplo la partición q1d-80p tiene como tiempo de ejecución máxima
1 día utilizando hasta 80 cores.
Nombre de la Tiempo Formato simplificado y Número de cores Tipo de

partición máximo extenso SLURM máximo nodo
q1h-20p 1 hora 0-1 | 1:00:00 20 1x nc
q1d-20p 1 día 1-0 | 1-00:00:00 20 1x nc
NODO UAM LANCAD
q4d-20p 4 días 4-0 | 4-00:00:00 20 1x nc
q7d-20p 7 días 7-0 | 7-00:00:00 20 1x nc
q1h-40p 1 hora 0-1 | 1:00:00 40 2x nc
q1d-40p 1 día 1-0 | 1-00:00:00 40 2x nc
q4d-40p 4 días 4-0 | 4-00:00:00 40 2x nc
q1h-80p 1 hora 0-1 | 1:00:00 80 4x nc
q12h-80p 12 horas 0-12 | 12:00:00 80 4x nc
q1d-80p 1 día 1-0 | 1-00:00:00 80 4x nc
q1h-160p 1 hora 0-1 | 1:00:00 160 8x nc
q12h-160p 12 horas 0-12 | 12:00:00 160 8x nc
q1d-160p 1 día 1-0 | 1-00:00:00 160 8x nc
q1h-320p 1 hora 0-1 | 1:00:00 320 16x nc
q12h-320p 12 horas 0-12 | 12:00:00 320 16x nc
q1d-320p 1 día 1-0 | 1-00:00:00 320 16x nc
q1d-640p 1 día 1-0 | 1-00:00:00 640 32x nc
tt2d-80p 2 días 2-0 | 2-00:00:00 80 4x tt
tt1d-160p 1 día 1-0 | 1-00:00:00 160 8x tt
tt12h-320p 12 horas 0-12 | 12:00:00 320 16x tt
tt2d-64p 2 días 2-0 | 2-00:00:00 64p 2x tt
tt1d-128p 1 día 1-0 | 1-00:00:00 128 4x tt
tt1d-256p 1 día 1-0 | 1-00:00:00 256 8x tt
tt1d-512p 1 días 1-0 | 1-00:00:00 512 16x tt
gpus 7 días 7-0 | 7-00:00:00 2 / 4 / 8 GPU nc
Tabla 1. Particiones en el cluster yoltla
Tipo de nodo Número de cores Memoria RAM

Cómputo GPU - nc 20 64 GB
Cómputo CPU - nc 20 64 GB
Cómputo CPU - tt 20 128 GB
Cómputo CPU - tt 32 256 GB
Tabla 2. Nodos de cómputo en el cluster yoltla
NODO UAM LANCAD

Solicitud de recursos y envío de trabajos
El acceso a los recursos de cómputo del cluster yoltla es mediante la creación de
un script con directivas para SLURM y los comandos necesarios para ejecutar el
programa de interés.
Imagen 1. Diagrama configuración y funcionamiento cluster yolta
Las principales directivas para SLURM son:
NODO UAM LANCAD

Directiva Uso
#SBATCH –-job-name=TRABAJO-10 OPCIONAL
Establece el nombre del trabajo,

útil en el uso del comando squeue.
Si no se establece nombre al
trabajo, el nombre por default
será el nombre del script.
#SBATCH -–error=error-%j.err OPCIONAL
Almacenar los mensajes escritos al

flujo “error estandar” en el
archivo especificado.
Por ejemplo error-%j.err indica

que se debe crear el archivo
error-<id del trabajo>.err para
guardar los mensajes del flujo
“error estandar”.
#SBATCH -–output=salida-%j.out OPCIONAL
Almacenar los mensajes escritos al

flujo “salida estandar” en el
archivo especificado.
Por ejemplo salida-%j.out indica

que se debe crear el archivo
error-<id del trabajo>.out para
guardar los mensajes del flujo
“salida estandar”.
#SBATCH --partition=tt1d-160p OBLIGATORIO
Nombre de la partición donde se

formará el trabajo para ser
despachado.
Si no se establece una partición

el sistema aceptará el trabajo
para formarlo en la partición
default q1, la cual esta limitada
a 1 hora de ejecución.
#SBATCH --time=0-12 OBLIGATORIO
Establece el tiempo máximo de uso

de los nodos de cómputo, el
NODO UAM LANCAD

trabajo puede terminar de
ejecutarse en menos tiempo (caso
deseado) o no terminar en el
tiempo solicitado, en este último
caso el programa es notificado
mediante una señal SIGTERM seguida
por la señal SIGKILL.
En caso de omitir esta directiva,

el tiempo máximo se establecerá
según la partición. En general se
recomienda establece el tiempo, si
es menor que el máximo permitido
por la partición, ya que permitirá
al algoritmo “backfill”
seleccionar el trabajo para su
ejecución antes que otros trabajos
que le preceden.
Los formatos validos para esta

directiva son:
• minutos
◦ #SBATCH --time=35
• minutos:segundos
◦ #SBATCH --time=35:20
• horas:minutos:segundos
◦ #SBATCH --time=1:35:20
• días-horas
◦ #SBATCH –-time=1-0
◦ #SBATCH -–time=0-1
• días-horas:minutos
◦ #SBATCH --time=4-1:35
• días-horas:minutos:segundos
◦ #SBATCH --time=4-1:35:20
#SBATCH --ntasks-per-node=20 OBLIGATORIO
#SBATCH --tasks-per-node=20
Estas dos directivas son
equivalentes y establecen la
cantidad tareas a ejecutar en los
nodos asignados. Cada una de las
tareas será despachada por un core
diferente.
En el entorno de SLURM una tarea

NODO UAM LANCAD
es una copia del programa que se
ejecutará en el nodo o nodos
asignados. Ver ejemplos.
#SBATCH --nodes=8 OBLIGATORIO
Cantidad de nodos de cómputo a

utilizar para la ejecución del
trabajo.
Es necesario indicar el número de

nodos dependiendo de la partición
solicitada ya que de lo contrario
el trabajo será rechazado.
--cpus-per-task=20 OBLIGATORIO
Establece la cantidad de cores que

utilizará una tarea en cada uno de
los nodos asignados. Esta
directiva es útil para ejecuciones
de programas de memoria compartida
“OPENMP” ya que solamente se
ejecuta una copia (tarea) del
programa y posteriormente se crean
hilos necesarios para atender las
partes paralelas.
La cantidad de hilos que se

crearán durante la ejecución de un
programa de memoria compartida
“OPENMP” es controlada en el
archivo de entrada de la tarea o
por medio de la variable de
ambiente OMP_NUM_THREADS (Ver
ejemplos)
Entorno de programación / compilación

Se encuentran instalados compiladores para los lenguajes C, C++ y Fortran
• GCC (gcc, g++, gfortran)
• Intel parallel studio XE (icc, icpc, ifort)
Las variables de entorno que permiten el acceso a los compiladores así como al
software ya compilado son modificadas dinámicamente por medio de la
herramienta environment modules (http://modules.sourceforge.net/). La
configuración de esta herramienta se basa en archivos de módulos (modulefiles) los
NODO UAM LANCAD
caules establecen o alteran variables del shell tales como PATH, LD_LIBRARY_PATH,
etc.
Para listar los archivos de módulos o “módulos” configurados en el cluster ejecutar

el comando:
module avail
Por ejemplo para hacer uso de los compiladores y herramientas de intel 2016
ejecutar el comando:
module load compilers/intel/2016/u3/tools-16.3.210
Para hacer uso del software nwchem 6.6 ejecutar:
module load intel/15.6.232/impi/5.0.3.49/nwchem/6.6
Para conocer las modificaciones o nuevas variables de entorno realizados al cargar

un archivo de módulos, utilizar la opción show:
module show intel/15.6.232/impi/5.0.3.49/nwchem/6.6
*Nota. Cada archivo de modulo correspondiente a una aplicación pre-compilada

define la variable YOLTLA_EXAMPLE que hace referencia a un archivo con un
ejemplo base para la creación de un trabajo para SLURM. Para consultar dicho
archivo basta con ejecutar cat $YOLTLA_EXAMPLE después de cargar el modulo.
NODO UAM LANCAD

Ejemplos.
En el contexto de SLURM una tarea debe entenderse como un proceso. Por ejemplo
la ejecución de un programa MPI se lleva a cabo ejecutando múltiples procesos
(copias del mismo programa) en uno o varios nodos de cómputo. Cada una de estas
tareas utiliza un solo “core” de procesamiento.
Por otro lado un programa de memoria compartida (OpenMP o multi-hilo) está

compuesto por una tarea que utiliza varios “cores” en un solo nodo de cómputo.
SLURM da el nombre de trabajo “job” a los recursos de cómputo (nodos con sus
correspondientes cores) asignados a un usuario por un determinado periodo de
tiempo.
Ejemplo 1. Trabajo con 20 tareas seriales

#!/bin/bash
#
### Partición q1h-20p ###
#SBATCH –-partition=q1h-20p
#
### Nombre del trabajo ###
#SBATCH --job-name=programax20
#
### El trabajo requiere de 1 nodo, donde se ejecutarán 20 tareas ###
### Por default por cada nodo solicitado SLURM asume que se ###
### ejecutará una tarea. ###
### LA DIRECTIVA #SBATCH –-nodes=1 NO RESERVA NODOS COMPLETOS ###
### ES NECESARIO INDICAR EXPLÍCITAMENTE LA CANTIDAD DE TAREAS ###
### QUE SE EJECUTARÁN EN LOS NODOS SOLICITADOS ###
#SBATCH --nodes=1
#SBATCH –-ntasks-per-node=20
#
### Se solicitan 30 minutos para este trabajo ###
#SBATCH --time=30:00
#
### A continuación todos los comandos necesarios para ejecutar las ###
### 20 tareas ###
# Cargamos el modulo correspondiente al programa que ejecutaremos

module load <modulefiles/app>
NODO UAM LANCAD

# Indicamos al shell bash que a partir de esta línea, imprima en error
# estándar “STDERR” cada comando antes de ser ejecutado.
# Útil para fines de diagnostico
set -x
# SLURM comienza la ejecución del trabajo en el mismo directorio donde

# se invoco el comando sbatch. El siguiente comando es opcional
cd $SLURM_SUBMIT_DIR
# Ejecutamos cada una de las 20 tareas (en segundo plano)

# en este caso con archivos de entrada diferentes
programa input1 &
programa input2 &
…
…
programa input20 &
# De antemano no sabemos el orden en que terminarán cada una de

# las 20 tareas que fueron lanzadas en segundo plano.
# Nos auxiliaremos del comando interno de bash “wait” para detener
# la ejecución del script (trabajo) hasta que todos los procesos
# lanzados en segundo plano hayan finalizado.
#
# Sin esta instrucción el script terminara y SLURM dará por
# finalizado el trabajo y terminando por medio de señales “kill”
# cualquier tarea asociada al trabajo, en este caso los procesos
# lanzados en segundo plano.
wait
Ejemplo 2. Trabajo con 1 tarea utilizando 20 cores (OpenMP)

#!/bin/bash
#
### Partición q1h-20p ###
#SBATCH –-partition=q1h-20p
#
#SBATCH --job-name=programa_OMP
#
### La salida estándar “STDOUT” de la tarea será redirigida al ###
### archivo programa_OMP.o%j. %j será remplazado por el ###
### identificador asignado al trabajo. ###
#SBATCH -–output=programa_OMP.o%j
NODO UAM LANCAD

#
### El error estándar “STDERR” de la tarea será redirigida al ###
### archivo programa_OMP.e%j. %j será remplazado por el ###
#SBATCH -–error=programa_OMP.e%j
#
### El trabajo requiere de 1 nodo, donde se ejecutará 1 tarea. ###
### Por cada nodo solicitado SLURM asume que se ejecutará una ##
### tarea, por lo que la directiva #SBATCH –-ntasks-per-node=1 ##
### en este caso puede omitirse.
#SBATCH --nodes=1
#
### Indicamos a SLURM que esta tarea ocupara 20 cores. ###
### NO ESTABLECER ESTA OPCIÓN TENDRÁ COMO RESULTADO QUE LOS HILOS ##
### CREADOS POR EL PROGRAMA SEAN RESTRINGIDOS A UN SOLO CORE EN ##
### EN EL NODO DE CÓMPUTO, AFECTANDO CON ESTO DRÁSTICAMENTE EL ###
### RENDIMIENTO ###
#SBATCH --cpus-per-task=20
#
### Se solicitan 30 minutos para este trabajo ###
#SBATCH --time=30:00
#
### A continuación todos los comandos necesarios para ejecutar la ###
### tarea ###
# Cargamos el modulo correspondiente al programa que ejecutaremos.


# Útil para fines de diagnostico.
set -x

# Consultamos los cores que podemos utilizar así como el limite para
# el segmento de memoria de pila o “stack size”
grep Cpus_allowed_list: /proc/self/status
grep "Max stack size" /proc/self/limits
ulimit -s
NODO UAM LANCAD

# Ejecutamos la tarea en primer plano
programa input1
Ejemplo 3. Trabajo con 2 nodos 32 tareas por nodo (MPI)

#!/bin/bash
#
### Partición tt2d-64p ###
#SBATCH –-partition=tt2d-64p
#
#SBATCH --job-name=programa_MPI
#
### archivo programa_MPI.o%j. %j será remplazado por el ###
#SBATCH -–output=programa_MPI.o%j
#
### archivo programa_MPI.e%j. %j será remplazado por el ###
#SBATCH -–error=programa_MPI.e%j
#
### El trabajo requiere de 2 nodos, cada uno ejecutará 32 tareas. ###
#SBATCH --nodes=2
#
### Se solicitan 2 días para este trabajo ###
#SBATCH –time=2-0
#
### tarea ###


set -x

NODO UAM LANCAD
# A partir de este punto la ejecución de un programa paralelo MPI puede

# variar. Recomendamos consultar el archivo referenciado por la
# variable $YOLTLA_EXAMPLE después de cargar el modulo correspondiente
# al programa que se ejecutará.
# Por ejemplo:
# module load intel/15.2.164/impi/5.0.3.48/nwchem/6.6
# cat $YOLTLA_EXAMPLE
# Obtenemos la lista de nodos asignados en el archivo nodes.list

scontrol show hostname $SLURM_NODELIST > nodes.list
# Ejecutamos el programa nwchem por medio de mpiexec.hydra:

# 64 tareas (-np $SLURM_NTASKS)
# 32 tareas por nodo (-ppn $SLURM_NTASKS_PER_NODE)
MPI_COM=”mpiexec.hydra -bootstrap rsh -f ./hostlist.dat ”

$MPI_COM -ppn $SLURM_NTASKS_PER_NODE -np $SLURM_NTASKS nwchem input.nw
Ejemplo 4. Trabajo con 1 nodo utilizando GPUS

#!/bin/bash
#
### Partición gpus ###
#SBATCH –-partition=gpus
#
#SBATCH --job-name=programa_GPU
#
### archivo programa_GPU.o%j. %j se remplazará por el ###
#SBATCH -–output=programa_GPU.o%j
#
### archivo programa_GPU.e%j. %j se remplazará por el ###
#SBATCH -–error=programa_GPU.e%j
#
### El trabajo requiere de 1 nodo, dependiendo de la aplicación ###
### es la cantidad de tareas a ejecutar. En este caso asumiremos ###
### que 2 tareas cada una de ellas trabajando en una tarjeta GPU ###
#SBATCH --nodes=1
NODO UAM LANCAD
#
### El cluster yoltla cuenta con nodos GPU:
### 16 con 2 tarjetas. ###
### Para solicitar los recursos cómputo, que en este caso son ###
### las tarjetas GPU, debemos indicar a slurm la cantidad de ###
### tarjetas que requerimos para ejecutar nuestro programa. ###
### –-gres=gpu:2
### –-gres=gpu:4
### –-gres=gpu:8
###
### Con base en esta información se nos asignará el nodo con el ###
### número de tarjetas solicitas. En este ejemplo solicitaremos ###
### un nodo con 2 tarjetas.
#SBATCH –-gres=gpu:2
#
### Se solicitan 2 días para este trabajo ###
#SBATCH –time=2-0
#
### tarea ###


set -x

# Consultamos los cores que podemos utilizar así como el limite para
# el segmento de memoria de pila o “stack size”
grep Cpus_allowed_list: /proc/self/status
grep "Max stack size" /proc/self/limits
ulimit -s
echo $CUDA_VISIBLE_DEVICES
programa-GPU input
NODO UAM LANCAD

Envío y estado de los trabajos
sbatch trabajo.sh
Para enviar un trabajo a la partición indicada en el script utilizar el comando sbatch,
al enviar un trabajo este será identificado por un identificador numérico único “JOB
ID”. Este identificador nos servirá posteriormente para consultar el estado del
trabajo o cancelarlo.
scancel JOB-ID
Un trabajo puede ser cancelado si se encuentra en ejecución o en espera de
recursos (trabajo en cola). Solo el usuario propietario del trabajo puede cancelarlo.
squeue --long --user=$USER

La herramienta squeue reporta el estado de todos los trabajos en el cluster, para
solicitar solo el estado de nuestros trabajos, usar las opciones --long y --user.
Documentación adicional
SLURM es el proyecto de software para la administración de trabajos en sistema de
cómputo de alto rendimiento más popular debido a su facilidad de uso así como a
su extensa documentación.
quickstart https://slurm.schedmd.com/quickstart.html
sbtach https://slurm.schedmd.com/sbatch.html
scancel https://slurm.schedmd.com/scancel.html
squeue https://slurm.schedmd.com/squeue.html
sinfo https://slurm.schedmd.com/sinfo.html
salloc https://slurm.schedmd.com/salloc.html
NODO UAM LANCAD


Cuenta Lancad Nodo Uami

Cargado por

Información del documento

Título original

Derechos de autor

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Cuenta Lancad Nodo Uami

Título original:

Cargado por

Copyright:

Nodo UAM.

Las políticas establecidas en el cluster para asignación de contraseñas son:

Debe estar formada por al menos 8 caracteres (sin espacios).

Al realizarse la primera conexión y después de establecer su nueva contraseña, la

ssh -l <nombre de usuario> <dirección IP del nodo de acceso>

NODO UAM LANCAD

ssh <nombre usuario>@<dirección IP del nodo de acceso>

*Las versiones portables de software en Windows no requieren instalación y pueden

Existen 25 particiones para solicitar recursos en el cluster, el nombre de cada una

Nombre de la Tiempo Formato simplificado y Número de cores Tipo de

Tipo de nodo Número de cores Memoria RAM

NODO UAM LANCAD

Imagen 1. Diagrama configuración y funcionamiento cluster yolta

Las principales directivas para SLURM son:

NODO UAM LANCAD

Establece el nombre del trabajo,

Almacenar los mensajes escritos al

Por ejemplo error-%j.err indica

Almacenar los mensajes escritos al

Por ejemplo salida-%j.out indica

Nombre de la partición donde se

Si no se establece una partición

Establece el tiempo máximo de uso

NODO UAM LANCAD

En caso de omitir esta directiva,

Los formatos validos para esta

En el entorno de SLURM una tarea

Cantidad de nodos de cómputo a

Es necesario indicar el número de

Establece la cantidad de cores que

La cantidad de hilos que se

Entorno de programación / compilación

Para listar los archivos de módulos o “módulos” configurados en el cluster ejecutar

module load compilers/intel/2016/u3/tools-16.3.210

Para hacer uso del software nwchem 6.6 ejecutar:

module load intel/15.6.232/impi/5.0.3.49/nwchem/6.6

Para conocer las modificaciones o nuevas variables de entorno realizados al cargar

module show intel/15.6.232/impi/5.0.3.49/nwchem/6.6

*Nota. Cada archivo de modulo correspondiente a una aplicación pre-compilada

NODO UAM LANCAD

Por otro lado un programa de memoria compartida (OpenMP o multi-hilo) está

Ejemplo 1. Trabajo con 20 tareas seriales

# Cargamos el modulo correspondiente al programa que ejecutaremos

NODO UAM LANCAD

# SLURM comienza la ejecución del trabajo en el mismo directorio donde

# Ejecutamos cada una de las 20 tareas (en segundo plano)

# De antemano no sabemos el orden en que terminarán cada una de

Ejemplo 2. Trabajo con 1 tarea utilizando 20 cores (OpenMP)

NODO UAM LANCAD

# Cargamos el modulo correspondiente al programa que ejecutaremos.

# Indicamos al shell bash que a partir de esta línea, imprima en error

# SLURM comienza la ejecución del trabajo en el mismo directorio donde

NODO UAM LANCAD

Ejemplo 3. Trabajo con 2 nodos 32 tareas por nodo (MPI)

# Cargamos el modulo correspondiente al programa que ejecutaremos.

# Indicamos al shell bash que a partir de esta línea, imprima en error

# SLURM comienza la ejecución del trabajo en el mismo directorio donde

# A partir de este punto la ejecución de un programa paralelo MPI puede

# Obtenemos la lista de nodos asignados en el archivo nodes.list

# Ejecutamos el programa nwchem por medio de mpiexec.hydra:

MPI_COM=”mpiexec.hydra -bootstrap rsh -f ./hostlist.dat ”

Ejemplo 4. Trabajo con 1 nodo utilizando GPUS

# Cargamos el modulo correspondiente al programa que ejecutaremos.

# Indicamos al shell bash que a partir de esta línea, imprima en error

# SLURM comienza la ejecución del trabajo en el mismo directorio donde