Curso rápido de introducción a Picasso

Autores:

Rafael Larrosa Jiménez (Administrador de Sistemas, SCBI)
David Castaño Bandín (Administrador de Sistemas, SCBI)
Manuel Guerrero Claro (Administrador de Sistemas, SCBI)

Para cualquier duda, contactar con soporte@scbi.uma.es. Puede verse más información sobre el uso de Picasso en el manual de usuario.

La grabación del curso corresponde a la versión de 2024, por lo que algunos datos difieren de este texto, que es el que está al día.

Descargar el vídeo (MP4, 78 minutos, 206,7 MB).

1. Introducción

En España hay una serie de infraestructuras públicas denominadas ICTS (Infraestructuras Científico-Técnicas Singulares). Su objetivo es proveer a los investigadores españoles de medios competitivos para llevar a cabo investigaciones de vanguardia.

Mapa de las ICTS de España

Un ejemplo muy conocido de este tipo de infraestructuras son los telescopios y observatorios astronómicos de Canarias. En el ámbito andaluz están la Reserva Biológica de Doñana, el Observatorio Astronómico de Calar Alto o la que nos ocupa en este curso, la Red Española de Supercomputación (RES), a través del nodo Picasso.

Mapa de los nodos de la RES

La RES está formada por una serie de «nodos», es decir, de centros de supercomputación repartidos por toda España. El SCBI, con su supercomputador Picasso y sus más de 37.000 núcleos de CPU, aparece como el segundo nodo más potente de la RES en la gráfica de capacidad de la red, solo por detrás de MareNostrum 5, en el BSC (Barcelona Supercomputing Center).

Capacidad de cálculo de los nodos de la RES, en TFlop/s

El SCBI también participa en la computación cuántica a través del proyecto Quantum Spain.

Proyecto Quantum Spain y sus nodos en España

2. Acceso

El acceso a Picasso se realiza con el protocolo SSH en línea de comandos:

ssh -X <user>@picasso.scbi.uma.es

Donde <user> debe sustituirse por el usuario correspondiente. Este comando se puede ejecutar en:

un terminal de Linux;
un terminal de macOS;
un PowerShell en Windows.

Otra opción es usar un programa dedicado a las conexiones SSH con servidores, como MobaXterm o similares. MobaXterm es una buena opción para principiantes que no estén acostumbrados a manejar un terminal, porque incluye un explorador de ficheros (columna de la izquierda) que facilita moverse entre carpetas y mover archivos entre Picasso y el ordenador local.

MobaXterm conectado por SSH, con el explorador de ficheros a la izquierda

3. Movimiento de ficheros

Para copiar ficheros entre Picasso y el ordenador local hay dos opciones:

usar comandos como rsync o scp en un terminal;
usar programas externos para abrir un explorador de archivos en Picasso (MobaXterm, Dolphin en Linux…).

3.1. Los comandos scp y rsync

Lo primero que hay que tener en cuenta es que tanto los comandos para copiar del ordenador local a Picasso como los de Picasso al ordenador local se ejecutan en el ordenador local. Ambos sirven para mover archivos entre un ordenador local y un servidor, siendo rsync el más potente y versátil. Se recomienda usar rsync con ficheros grandes o con grandes cantidades de archivos, porque es capaz de reanudar la copia si se interrumpe.

Del ordenador local a Picasso

Lo primero es abrir un terminal o un PowerShell en la carpeta que contenga los ficheros y directorios que se quieren copiar. Después, basta con ejecutar uno de los siguientes comandos:

scp -r <file> <user>@picasso.scbi.uma.es:<destination>
rsync -CazvHu <file> <user>@picasso.scbi.uma.es:<destination>

donde:

<file> debe sustituirse por el nombre del archivo o carpeta que se quiere copiar;
<user> debe sustituirse por el usuario de Picasso;
<destination> debe sustituirse por la ruta de la carpeta de destino en Picasso, que puede obtenerse con el comando pwd en Picasso.

De Picasso al ordenador local

Lo primero es abrir un terminal o un PowerShell en la carpeta donde se quieren copiar los archivos de Picasso. Después, basta con ejecutar uno de los siguientes comandos:

scp -r <user>@picasso.scbi.uma.es:<file> .
rsync -CazvHu <user>@picasso.scbi.uma.es:<file> .

donde:

<file> debe sustituirse por el nombre del archivo o carpeta que se quiere copiar;
<user> debe sustituirse por el usuario de Picasso;
el . del final del comando es la ruta de destino y significa «aquí». ¡Es importante ponerlo!

3.2. Mover ficheros con MobaXterm

Como ya se ha comentado, en la columna de la izquierda de MobaXterm se pueden mover ficheros entre Picasso y el ordenador local (véase la figura de la sección 2). Basta con arrastrar los ficheros o usar las opciones de subir y descargar del menú superior.

3.3. Otras alternativas

Hay una gran variedad de programas que permiten montar un servidor por SFTP. Por ejemplo, en las distribuciones de Linux el propio explorador de archivos suele ofrecer esta opción.

En Ubuntu basta con abrir el explorador de archivos, ir a Otras ubicaciones (Other Locations) y escribir abajo del todo, donde pone Conectar al servidor (Connect to Server), la dirección:

sftp://USER@picasso.scbi.uma.es

Donde USER debe sustituirse por el usuario correspondiente.

Conexión SFTP a Picasso desde el explorador de archivos de Ubuntu

En otros exploradores de archivos, como Dolphin (el que trae por defecto openSUSE con el escritorio KDE), basta con escribir la dirección anterior en la barra de la ruta.

Conexión SFTP a Picasso desde Dolphin

4. Recursos hardware

Picasso consta de diferentes tipos de nodos: unos con más RAM, otros con más núcleos, unos con procesador Intel, otros con AMD y algunos con GPU. La tabla recoge la RAM disponible para el usuario en cada familia, que es algo menor que la RAM física del nodo.

Familia	Nodos	Núcleos por nodo	RAM útil por nodo	GPU por nodo
sd (Intel Xeon 6230R)	123	52	182 GB	—
sr (AMD EPYC 7H12)	154	128	439 GB	—
bc (AMD EPYC 9754)	29	256	683 GB	—
bl (AMD EPYC 7H12)	24	128	1.855 GB	—
exa (NVIDIA DGX A100)	4	128	878 GB	8 × A100 de 40 GB
blk (NVIDIA DGX B200)	2	128	3.418 GB	8 × B200 de 180 GB

Los nodos, núcleos y RAM salen de sinfo (5 de octubre de 2026). La memoria de las A100 se ha comprobado en Picasso, y la de las B200 es la de la especificación de NVIDIA.

Desde el punto de vista del usuario, no hay que preocuparse por el tipo de nodo. Como se verá en la sección 8, el usuario solo tiene que pedir al sistema la RAM, el número de núcleos, el tiempo de ejecución y poco más, y es el sistema el que se encarga de asignarle los recursos. Lo único que hay que tener en cuenta es que los nodos con más RAM o más núcleos son escasos en comparación con el resto, así que si se piden más de 439 GB de RAM o más de 128 núcleos por nodo, los trabajos tardarán más en entrar en ejecución.

Solo 6 nodos tienen GPU. En la sección 10 se explica cómo usarlos.

5. Sistema de ficheros / cuota

Picasso tiene dos sistemas de ficheros compartidos (el HOME y el FSCRATCH), aparte de un sistema de ficheros local en cada nodo (LOCALSCRATCH). Cada usuario tiene una cuota de ficheros y espacio en HOME y otra en FSCRATCH.

5.1. Sistemas de ficheros compartidos

En ellos se trabaja la inmensa mayor parte del tiempo:

HOME (almacenamiento permanente). Aquí se deben guardar los datos importantes, los scripts de desarrollo propio, los resultados finales y otros ficheros importantes. Para volver a tu HOME puedes usar cualquiera de los siguientes comandos:
```
cd
cd ~
cd $HOME
```
FSCRATCH (almacenamiento temporal). Es un almacenamiento de alta velocidad desde el que se deberían lanzar tus trabajos. Es temporal, es decir, tiene una política de borrado automático de los archivos antiguos (más de 2 meses). Por ello es importante copiar los resultados importantes al HOME una vez terminado el trabajo. Para acceder a él se puede usar el comando:
```
cd $FSCRATCH
```
Se pueden copiar carpetas de HOME a FSCRATCH con un comando como:
```
cp -r $HOME/path/to/your/folder/in/home $FSCRATCH/path/to/target/folder
```
o de FSCRATCH a HOME con:
```
cp -r $FSCRATCH/path/to/your/folder/in/fscratch $HOME/path/to/target/folder
```

5.2. Cuota

La cuota de cada usuario se puede consultar con el comando:

quota

Cuando se ha sobrepasado alguna de las cuotas, aparece un mensaje de aviso al entrar en Picasso. Este mensaje se puede volver a ver con el comando quota.

Salida del comando quota con la cuota de número de ficheros del HOME superada

Como se ve en la imagen, hay una cuota de espacio (en GB o TB) y otra de número de ficheros. Además, hay dos tipos de cuotas:

Quota (cuota soft). Una vez superada alguna de las cuotas soft, se concede un periodo de gracia de 7 días para volver a la situación normal. Pasados esos 7 días con la cuota superada, se bloquea la escritura.
Limit (cuota hard). La cuota hard no se puede superar. Cuando se alcanza, se bloquea la escritura.

6. Software

En Picasso hay preinstalada una gran variedad de software. La lista puede consultarse en la web del centro o con el comando module avail:

module avail python          # módulos cuyo nombre empieza por «python»
module avail -C torch        # módulos cuyo nombre contiene «torch»

Para cargar un software se usa el comando:

module load software/version

Para ver los módulos cargados:

module list

Para descargar un módulo:

module unload software/version

Para descargar todos los módulos:

module purge

7. Nociones de paralelismo

Uno de los grandes potenciales de un superordenador es la capacidad de ejecutar procesos con un paralelismo masivo (cientos o miles de ejecuciones en paralelo). Por eso merece la pena hablar un poco sobre ciertas nociones de paralelismo en los programas. Cuando hablamos del paralelismo de un programa, hablamos de su capacidad de ejecutar ciertas partes de forma simultánea en vez de secuencial.

Hay un principio famoso, conocido como ley de Amdahl, que nos dice la aceleración que conseguiremos en un proceso al aumentar el número de núcleos, dependiendo de lo grande que sea la parte paralela del programa. Un programa puede tener partes que se tienen que ejecutar sí o sí de forma secuencial y partes que se pueden paralelizar.

Ley de Amdahl: aceleración frente al número de procesadores para porciones paralelas del 50, 75, 90 y 95 %

Figura: Daniels220, Wikimedia Commons, licencia CC BY-SA 3.0.

Esta ley nos hace ver que las partes secuenciales de un programa son las que, al final, dictan el máximo incremento de velocidad que se puede conseguir mediante el paralelismo.

Por ejemplo, la línea azul representa un programa cuyo 50 % es paralelizable. En la gráfica vemos que con 16 núcleos prácticamente se ha alcanzado el máximo incremento de velocidad, y que a partir de ahí aumentar el número de núcleos es inútil. Vemos también que el incremento máximo de velocidad en este caso es de 2, es decir, el programa tarda la mitad. Esto se debe a que, mediante el paralelismo, ese 50 % paralelo del programa se hace rápidamente, mientras que el 50 % secuencial sigue tardando lo mismo.

Veamos otro ejemplo, el procesamiento de un fichero que tarda 100 minutos sin paralelismo. De estos 100 minutos, un 10 % es secuencial y un 90 % puede paralelizarse.

Tiempo de ejecución del ejemplo con 1 núcleo (100 min) y con 2 núcleos (55 min)

Vemos que al duplicar el número de núcleos el tiempo pasa de 100 a 55 minutos, y no se reduce a la mitad. Con n núcleos, el programa tarda 10 + 90/n minutos:

Núcleos	Tiempo
1	100 min
2	55 min
4	32,5 min
10	19 min
Infinitos	10 min

Si todo fuera paralelo, con 10 núcleos tardaría 10 minutos. Sin embargo, como hay 10 minutos secuenciales, sabemos que este programa va a tardar como mínimo 10 minutos, por muchos núcleos que se usen.

Siguiendo con este ejemplo (el procesamiento de un fichero donde el 10 % del trabajo es secuencial y el 90 % paralelo), surgen las siguientes preguntas:

¿Cuántos núcleos es lo óptimo para procesar 10 ficheros de este tipo?
¿Es lo óptimo usar todos los núcleos para cada trabajo?

Dos formas de procesar 10 ficheros con 10 núcleos: uno tras otro, paralelizando cada análisis (190 min), o los 10 a la vez con un núcleo cada uno (100 min)

En las gráficas anteriores vemos dos formas de plantear el cálculo, ambas con 10 núcleos, pero una tarda casi el doble que la otra:

La primera opción ejecuta los 10 análisis uno detrás de otro, paralelizando cada análisis.
La segunda opción ejecuta los 10 análisis en paralelo, sin paralelizar cada uno de ellos.

En este caso particular es más eficiente la segunda opción, porque tiene todos los núcleos al máximo de uso todo el tiempo. En la primera, como el análisis tiene una parte secuencial, en cada análisis habrá un tiempo en el que 9 de los 10 núcleos no hacen nada.

8. Sistema de colas

8.1. Archivo de envío (simple)

Para acceder a todos los recursos de Picasso hay que usar el sistema de colas. Cuando se entra en Picasso, se accede a uno de los nodos del superordenador. Al resto de nodos no se puede acceder directamente, sino que se envían los trabajos al sistema de colas. Para ello, se escribe un «archivo de envío» donde se especifican los recursos necesarios, se cargan los módulos necesarios y se ejecuta el programa.

Veamos un ejemplo simple de archivo de envío:

#!/usr/bin/env bash
#SBATCH -J esto_es_un_ejemplo
#SBATCH --ntasks=1
#SBATCH --cpus-per-task=2
#SBATCH --mem=2gb
#SBATCH --time=10:00:00
#SBATCH --constraint=cal

# Set output and error files
#SBATCH --error=ejemplo_simple.%J.err
#SBATCH --output=ejemplo_simple.%J.out

module load software/version

hostname

time ./mi_programa -t $SLURM_CPUS_PER_TASK argumentos

El %J en el nombre de los archivos de salida se sustituye por el identificador del trabajo, de forma que los ficheros de salida no se pisan unos a otros.
El -t se debe a que a algunos programas hay que indicarles con un argumento el número de CPU (núcleos) que deben usar, a veces con -t numero_de_nucleos. En el sistema de colas Slurm, el valor de #SBATCH --cpus-per-task se guarda en la variable $SLURM_CPUS_PER_TASK, de forma que podemos usarla para decirle al programa que use todos los núcleos reservados.
--constraint=cal lo tienen las cuatro familias de nodos de CPU, así que no elige arquitectura. Para pedir nodos Intel o AMD se usa --constraint=intel o --constraint=amd.
Si el programa usa MPI para paralelizar, se piden tantas tareas como procesos con #SBATCH --ntasks=N y se ejecuta con mpirun -np $SLURM_NTASKS ejecutable_del_programa.

Puede generarse una plantilla de archivo de envío (con comentarios explicativos) con el comando:

gen_sbatch_file script_de_envio.sh 1 2gb 2:00:00 'ls -al'

Así se genera un archivo script_de_envio.sh que pide:

1 núcleo;
2 GB de RAM;
2 horas de tiempo de ejecución;
y ejecuta el comando ls -al.

La idea es editar esta plantilla, poniendo los recursos adecuados, cargando los módulos necesarios y escribiendo la orden de ejecución pertinente.

8.2. Envío al sistema de colas

Una vez escrito el archivo, hay que enviarlo al sistema de colas con el comando:

sbatch script_de_envio.sh

La cola puede verse con el comando:

squeue

Un trabajo puede cancelarse con el comando:

scancel job_id

Donde job_id se sustituye por el identificador del trabajo, que se obtiene con el comando squeue.

9. Array jobs

Los array jobs son una forma de mandar varios trabajos simultáneos variando un parámetro. Es decir, se envía un único script_de_envio.sh y se ejecutan varios trabajos en el sistema de colas, cada uno con un valor distinto del parámetro. Veamos un ejemplo de archivo de envío de un array job:

#!/usr/bin/env bash
#SBATCH -J esto_es_un_ejemplo_con_arrays
#SBATCH --ntasks=1
#SBATCH --cpus-per-task=2
#SBATCH --mem=2gb
#SBATCH --time=10:00:00
#SBATCH --constraint=cal

# Set output and error files
#SBATCH --error=ejemplo_array.%A-%a.err
#SBATCH --output=ejemplo_array.%A-%a.out

#SBATCH --array=1-10

module load software/version

hostname
echo a procesar el ${SLURM_ARRAY_TASK_ID}
time ./mi_programa -t $SLURM_CPUS_PER_TASK argumentos_${SLURM_ARRAY_TASK_ID}

Vemos que ha habido 3 cambios:

Se ha añadido la línea #SBATCH --array=1-10, que es la que hace que se ejecute un array job variando un parámetro (en este caso, de 1 a 10). También se puede hacer variar el parámetro entre los valores de una lista. El parámetro puede usarse después para hacer una serie de operaciones matemáticas y pasarle al programa un valor concreto. Por ejemplo, para hacer simulaciones variando la temperatura entre 273 K y 373 K de 5 en 5 grados, se puede usar un array job con #SBATCH --array=0-20 y calcular la temperatura como T = 273 + 5*${SLURM_ARRAY_TASK_ID}.
Se ha añadido ${SLURM_ARRAY_TASK_ID} al nombre de un supuesto archivo de argumentos del programa. Esto solo sirve para ver que el valor que se hace variar se guarda en la variable ${SLURM_ARRAY_TASK_ID} y puede usarse, por ejemplo, para leer un archivo distinto en cada ejecución del array job o para hacer operaciones aritméticas con él (como en el ejemplo anterior).
Se ha cambiado %J por %A-%a, para que los archivos .out y .err de cada trabajo del array job tengan un nombre diferente, que contiene el valor del parámetro que se hace variar (el %a).

10. Usando GPUs

Veamos ahora cómo pedir GPU en el sistema de colas de Picasso:

#!/usr/bin/env bash
#SBATCH --job-name=ejemplo1_gpu
#SBATCH --time=02:00:00
#SBATCH --mem=100G
#SBATCH --ntasks=1
#SBATCH --cpus-per-task=16
#SBATCH --gres=gpu:1
#SBATCH --constraint=a100

# Set output and error files
#SBATCH --error=ejemplo.%J.err
#SBATCH --output=ejemplo.%J.out

module load software/version

hostname
time ./mi_programa -t $SLURM_CPUS_PER_TASK argumentos

Los cambios significativos respecto al primer ejemplo son los siguientes:

Se ha añadido la línea que indica el número de GPU solicitadas, #SBATCH --gres=gpu:1. Un trabajo dirigido a los nodos de GPU que no pide ninguna se rechaza al enviarlo.
Se ha cambiado la constraint a #SBATCH --constraint=a100, que elige los nodos con GPU A100 (antes era cal, los nodos de cálculo). Para pedir una B200 se usa --constraint=b200.
16 núcleos y 100 GB de RAM por GPU es un reparto proporcionado, porque cada nodo exa tiene 128 núcleos, 878 GB de RAM y 8 GPU. Ajusta --time a lo que necesite el trabajo, con margen, porque cuanto menos se pide, antes suele entrar en ejecución.

Las B200 también pueden pedirse indicando el tipo dentro de --gres, sin constraint. El tipo va en mayúsculas, porque gpu:b200:1 se rechaza:

#SBATCH --gres=gpu:B200:1

Si el trabajo cabe en los 40 GB de memoria de una A100, conviene pedir A100, porque hay 32 frente a 16 B200.