La colección de compiladores GNU (GNU Compiler Collection, GCC) es accesible en el clúster a través de sus comandos y opciones habituales. Por defecto, los compiladores instalados en el sistema pertenecen a la versión 4.7.2 de GCC (versión por defecto del SO).¹⁾

ct$ module load gcc
ct$ gcc      -O exemplo.c   -o exemplo
ct$ g++      -O exemplo.cpp -o exemplo
ct$ gfortran -O exemplo.f   -o exemplo

Las opciones recomendadas son:

• -O Genera código optimizado para obtener un mayor rendimiento. Es equivalente a -O1. Alternativamente, se pueden utilizar las opciones -O0, -O2 o -O3. El número indica el nivel de optimización, siendo 0 el nivel sin ningún tipo de optimización y 3 el nivel con el que se obtiene un mayor rendimiento (la opción -O3 realiza algunas optimizaciones agresivas que pueden generar resultados imprecisos).
• -o <name> Establece el nombre del fichero ejecutable.

La colección de compiladores GCC permite la compilación de código OpenMP, indicándolo mediante la opción -fopenmp.

ct$ gcc      -O -fopenmp exemplo.c
ct$ g++      -O -fopenmp exemplo.cpp 
ct$ gfortran -O -fopenmp exemplo.f   

Para compilar código MPI es necesario cargar un módulo MPI (como, por ejemplo, el módulo openmpi), que proporcione los scripts de compilación de código MPI (mpicc, mpicxx, mpif77). Estos scripts hacen llamadas al compilador del lenguaje correspondiente.

ct$ module load openmpi
ct$ mpicc  -O exemplo.c
ct$ mpicxx -O exemplo.cpp 
ct$ mpif77 -O exemplo.f   

El comando modules permite gestionar, de manera eficaz y consistente, múltiples versiones de librerías y sofware para que el usuario utilice la versión adecuada en función de sus requerimientos. Su funcionamiento se basa en el encapsulamiento, dentro de un módulo, de las variables de entorno relacionadas con una versión de software determinada. De este modo, es el propio usuario quien gestiona la utilización de las diferentes versiones de software disponibles en el sistema.

La gestion, a nivel de usuario, de los módulos se realiza con el comando modules :

ct$ module avail
ct$ module list
ct$ module load module_name
ct$ module unload module_name
ct$ module purge

Las opciones son:

• avail Muestra todos los módulos disponibles en el sistema.
• list Muestra todos los módulos que están siendo utilizados en la sesión actual.
• load Activa el módulo module_name
• unload Desactiva el módulo module_name
• purge Desactiva todos los los módulos de la sesión actual.

El comando modules manipula las variables de entorno relacionadas con los path del sistema (PATH, LD_LIBRARY_PATH, etc.), por lo que se recomienda a los usuarios no modificar estas variables de modo arbitrario.

Se recomienda utilizar este comando de manera interactiva. Su uso dentro de .bashrc para cargar automáticamente módulos habituales no está recomendado, ya que todos los scripts que se ejecuten leen este fichero.

Se recomienda utilizar las versiones por defecto de los difentes módulos. En cualquier caso, el comando module avail porporciona una lista completa de todos los los módulos y versiones disponibles.

Por defecto, el entorno de ejecución del sistema Torque/PBS define algunas variables de entorno que pueden ser utilizadas dentro de los scripts (lista completa en el MAN de qsub):

• PBS_O_WORKDIR: contiene el path del directorio de trabajo ($PWD) desde donde se ha ejecutado el comando qsub. Es útil para establer un directorio de referencia durante la ejecución de los trabajos indicados.
• PBS_ARRAYID: contiene el índice del array correspondiente cuando el trabajo se lanza con la opción -t.
• PBS_JOBID: el job_id asignado al trabajo.
• PBS_JOBNAME: el nombre asignado por el usuario al trabajo.

Además cualquier variable exportada desde el script de lanzamiento del trabajo estará disponible en el entorno de ejecución.

El envío de trabajos se realiza a través de un comando cuyo argumento obligatorio es el nombre de un script de shell. El script tiene que disponer de permisos de ejecución.

ct$ chmod u+x script.sh

Dentro del script, el usuario debe indicar la acciones que se realizarán en los nodos, una vez que los recursos requeridos estén disponibles. Ejemplos de scripts contiene diferentes ejemplos relacionados con los módulos instalados en el clúster).

El script tiene básicamente tres elementos:

1. La definición del intérprete a usar, por defecto #!/bin/bash
2. Una serie de comentarios de BASH que comienzan por #PBS de modo que actúan como instrucciones para el gestor de colas.
3. Comandos de BASH que definen el trabajo a ejecutar.

Ejemplo simple de script:

#!/bin/bash
#PBS -l nodes=1:ppn=1,walltime=1:00:00
cd /path/to/job/
./executable

• -N Indica el nombre de referencia de nuestro trabajo en el sistema de colas. Por defecto sería el nombre del ejecutable.
  Ej: #PBS -N myjob
• -l Indica los recursos que se solicitan para la ejecución de nuestro trabajo, como el número de núcleos computacionales y el tiempo de ejecución. Los diferentes tipos de recursos se separan por comas.
  Ej: #PBS -l nodes=1:ppn=1,walltime=1:00:00
  • nodes=N:ppn=K: solicitamos N nodos computacionales, y K núcleos en cada nodo.²⁾
  • walltime=HH:MM:SS: solicitamos la exclusividad de los recursos durante un tiempo máximo de HH horas, MM minutos y SS segundos. El límite máximo de tiempo permitido es de 168 horas (1 semana).

• -e Indica el fichero en el que se redireccionará la salida estándar de error de nuestro ejecutable. Por defecto, la salida estándar de error se redirecciona a un fichero con extensión .eXXX (donde XXX representa el identificador PBS del trabajo).
  Ej: #PBS -e mySTD.err
• -o Indica el fichero en el que se redireccionará la salida estándar de nuestro ejecutable. Por defecto, la salida estándar se redirecciona a un fichero con extensión .oXXX (donde XXX representa el identificador PBS del trabajo).
  Ej: #PBS -o mySTD.out
• -m Indica el tipo de eventos que serán notificados por correo electrónico. Los argumentos posibles de esta opción son: b cuando el trabajo se emita a los nodos, a en caso de que se aborte la ejecución del trabajo inexperadamente y/o e cuando el trabajo termine su ejecución sin ningún incidente. Estos argumentos no son excluyentes y se pueden combinar.
  Ej: #PBS -m ae
• -M Indica la dirección de correo en la que se notificarán los eventos indicados con la opción -m.
  Ej: #PBS -M nombre.usuario@usc.es

• -t Crea un array de trabajos. Útil cuando se quieren enviar muchos trabajos que usan el mismo script y solo cambian los datos de entrada. Se definen uno o varios rangos de números separados por comas y/o guiones. Si solo se pone un único número, el rango será de 0 hasta dicho número.
  Ej:

...
#PBS -t 0-4
cat input.${PBS_ARRAYID} > output.${PBS_ARRAYID}
...

En este ejemplo los datos de entrada se encuentran en 5 ficheros llamados input.0, input.1,etc. Al usar este script generaremos 5 trabajos distintos cada uno con un valor del índice distinto. El de índice 0 leerá los datos de entrada del archivo input.0 y escribirá la salida en output.0, el de índice 1 usará input.1 y output.1, etc.

• -W Permite especificar atributos adicionales para el trabajo con el formato nombre=valor[,nombre=valor…]. La lista completa y su formato está en la página del MAN. El atributo más útil es depend=dependency_list que permite establecer dependencias entre trabajos.

Por ejemplo, para hacer que el trabajo 2 empiece cuando job1 haya terminado con éxito pondríamos esto en el script que lanza el job2 (hace falta saber el job_id del trabajo 1):

#PBS -Wdepend=afterok:<job1_id> 

A continuación se muestran varios ejemplos de scripts que muestran el conjunto básico de intrucciones para el envio de diferentes tipos de trabajos al gestor de colas.

#!/bin/bash
#PBS -l nodes=1:ppn=1,walltime=1:00:00
#PBS -N ejemplo
#PBS -o salida.out
#PBS -e salida.err
#PBS -m ae -M direccion_correo@usc.es
cd $PBS_O_WORKDIR
./executable

#!/bin/bash
#PBS -l nodes=1:ppn=4,walltime=1:00:00
#PBS -N ejemplo
cd $PBS_O_WORKDIR
(cd dir1; ./executable1) &
(cd dir2; ./executable2) &
(cd dir3; ./executable3) &
(cd dir4; ./executable4) &
wait

Java consume, por defecto, toda la memoria del sistema. En un sistema compartido por diferentes usuarios es necesario limitar la cantidad de memoria asignada a cada proceso, por lo que el tamaño del heap de Java en ctcomp2 está limitado al 25 del límite de memoria de la cola asignada al proceso y, cualquier caso, con un tamaño máximo de 8 GB.

Los usuarios pueden utilizar otros tamaños de heap en sus trabajos si modifican, antes de ejecutar JAVA, el valor de la opción -Xmx de JAVA a través de la variable _JAVA_OPTIONS. Por ejemplo, si queremos que el heap tenga 16 GB, el comando sería:

export _JAVA_OPTIONS=-Xmx16777216K

Al modificar el tamaño del heap el usuario debe asegurarse, bajo su responsabilidad, que el conjunto de procesos que se estén ejecutando concurrentemente en su trabajo no sobrepase el límite de memoria establecido en la correspondiente cola, ya que en ese caso el trabajo será cancelado automáticamente.

Los usuarios que ejecuten en sus trabajos una sola instancia de java (independientemente de los threads que ejecute) podrán aumentar el tamaño del heap, pero se recomienda que no sea un valor cercano al límite de memoria de la correspondiente cola.

#!/bin/bash
#PBS -l nodes=1:ppn=64,walltime=1:00:00
#PBS -N ej-java
cd $PBS_O_WORKDIR
module load jdk
export _JAVA_OPTIONS=-Xmx16777216K
java executable

#!/bin/bash
#PBS -l nodes=1:ppn=64,walltime=1:00:00
#PBS -N ej-openmp
cd $PBS_O_WORKDIR
export OMP_NUM_THREADS=64
./executable 

#!/bin/bash
#PBS -l nodes=8:ppn=64,walltime=1:00:00
#PBS -N ej-mpi
cd $PBS_O_WORKDIR
module load openmpi
mpirun -np 512 ./executable

No es posible realizar una sesión R interactiva, por lo que es necesario escribir previamente los comandos en un script.

#!/bin/bash
#PBS -l nodes=1:ppn=1,walltime=1:00:00
#PBS -N ej-R
cd $PBS_O_WORKDIR
module load R
R --no-save < test.R

No es posible realizar una sesión MATLAB interactiva, por lo que es necesario escribir previamente los comandos en un script. MATLAB emplea internamente, y de manera transparente al usuario, threads para paralelizar ciertas operaciones, por lo que se puede utilizar reservando varios núcleos computacionales dentro de un mismo nodo. Sin embargo, en las versiones instaladas no es posible controlar esta característica, por lo que MATLAB utiliza todos los recursos del nodo asignado, independientemente de los recursos solicitados. Para evitar posibles cancelaciones debido a un uso indebido de los recursos asignados, se recomienda a los usuarios utilizar el paralelismo implícito de MATLAB solo cuando se reserve en exclusividad un nodo del clúster. En cualquier otro caso, se recomienda solicitar únicamente un núcleo computacional y utilizar la opción -singleCompThread, que desactiva el paralelismo implícito de MATLAB para realizar una ejecución secuencial. En este ejemplo, el nombre del script es test.m.

#!/bin/bash
#PBS -l nodes=1:ppn=1,walltime=1:00:00
#PBS -N ej-MATLAB
cd $PBS_O_WORKDIR
module load matlab
matlab -r test -nodisplay -nojvm -singleCompThread
# -r:         indicar el fichero a ejecutar (sin .m)
# IMPORTANTE: incluir la orden quit al final del fichero
# -nodisplay: sin display X.
# -nosplash:  sin pantalla inicial (OPCIONAL)
# -nojvm:     sin entorno java (OPCIONAL)
# -singleCompThread: ejecuta MATLAB secuencialmente