• Noviembre 2023:
  Mediante fondos administrados por la UNL correspondientes a porcentaje de gastos indirectos que recibe el instituto por los Servicios Altamente Especializados a Terceros (SAT) que prestan sus miembros, la memoria RAM del clúster Pirayu fue aumentada en una capacidad de 7.5 TB de RAM para tener así un total de 15 TB de RAM.
• Septiembre 2022:
  Se potencia el clúster Pirayú, luego de obtener en 2017, el Préstamo BID AR/L 3497 Programa de Modernización de Equipamiento PME 2015-0036 con Mario Storti como Investigador Responsable, la suma de $16,910,000 pudo ser ejecutada y convertida en cómputo para atender las necesidades del CIMEC-CONICET y de toda la comunidad de Ciencia y Técnica del país.
  El nuevo equipamiento consta de 44 nodos con:
  - 2 x Intel Xeon Gold 6226R, arquitectura Skylake, 6 canales de memoria.
  - 64 GiB RAM DDR4-2666 MT/s.
  - Infiniband FDR-56.
  También gracias al PICT-E 2018-0271 de Mario Storti (CIMEC) – Paola Quaino (IQAL), se compraron 11 nodos más de marca AMD, con las siguientes características:
  - 2 x AMD EPYC 7401, architectura Zen1 (Naples), 8 canales de memoria.
  - 64 GiB DDR4-2666 MT/s, 128 GiB DDR4-2666 MT/s.
  - 1 GigE.
  Gracias a las nuevas adquisiciones, la potencia del clúster Pirayú se ha elevado alcanzando los 85 TFLops de capacidad de cómputo.
• Noviembre 2017:
  Gracias a los fondos de un PICT 2014 (Dra. Paola Quaino - PRELINE) se compraron 2 nodos de cómputo de 24 cores y 128 GB de RAM.
• Junio 2017:
  Mediante fondos de PICT-E 2014-0191 (Dr. Jorge D'Elia - CIMEC) la capacidad de cálculo fue aumentada a 27 TFlops gracias a 5 nuevos nodos de 24 cores, con una erogación de AR$ 800 mil.
• Diciembre 2016:
  El cluster entró en funcionamiento con 31 equipos (1 servidor, 1 NAS, 25 nodos de cálculo, 5 nodos con GPU y 1 nodo con Xeon Phi), brindando una capacidad inicial de 22 TFlops.
• Septiembre 2015:
  De este proyecto surge Pirayú, que es el nombre original dado por los pueblos originarios a una de las criaturas característica de la fauna litoraleña argentina: el dorado (Salminus brasiliensis). Este pez de gran musculatura es conocido por su velocidad y potencia, algo que sirvió de inspiración a los integrantes del consorcio para elegir un nombre para la que sería la supercomputadora más potente (hasta el momento) de la región.
• Diciembre 2014:
  17 proyectos de innovación productiva y equipamiento de alta complejidad fueron seleccionados en la primera convocatoria a financiamiento de propuestas de la Agencia Santafesina de Ciencia, Tecnología e Innovación ( ASACTEI).
  Uno de los proyectos seleccionados es la adquisición y puesta en funcionamiento de un Clúster de Cálculo para Aplicaciones de Computación de Alto Rendimiento, y tiene como institución beneficiaria a un consorcio conformado por nueve institutos de doble dependencia CONICET-UNL (CIMEC, IAL, ICIVET, IFIS, IMAL, INCAPE, INTEC, PRELINE y SINC). El financiamiento total del proyecto fue de U$D 420 mil.

Guía de usuario

• Actualmente el cluster Pirayu cuenta con el administrador de trabajos SLURM para administrar sus recursos. El usuario solicita un número de cores para una aplicación, y el sistema los asigna apenas tenga disponibilidad de recursos
• Para enviar trabajos a Pirayu mediante SLURM, se pueden usar dos comandos: sbatch y srun. Se recomienda el uso del primer comando, ya que permite una mejor configuración a pesar de tener que usar un archivo de configuración.
• La sintaxis del comando sbatch es la siguiente:
  sbatch [opciones] script
  Las opciones pueden especificarse en la consola, en un archivo de configuración o en variables de entorno.
• En el caso de usar un script de configuración, se deben definir algunas variables: Si se especifican dentro del script, Slurm lee las líneas que comienzan con #SBATCH e ignora el resto, y permite agregar comentarios después de las opciones. Por ejemplo "trabajo.sh" contiene:
  
  #!/bin/bash
#SBATCH --job-name=prueba4 # nombre para identificar el trabajo. Por defecto es el nombre del script
#SBATCH --ntasks=10 # cantidad de cores pedidos
# la linea siguiente es ignorada por Slurm porque empieza con ##
##SBATCH --ntasks-per-node=1 # cantidad de cores por nodo, para que distribuya entre varios nodos
#SBATCH --output=myjob.output # la salida y error estandar van a este archivo. Si no es especifca es slurm-%j.out (donde %j es el Job ID)
#SBATCH --error=myjob.error # si se especifica, la salida de error va por separado a este archivo

# aqui comienzan los comandos
mpirun /u/alquien/programa/programa_mpi
  
  El script pide 10 cores de un mismo nodo. Para un mejor rendimiento, se recomienda para la mayoría de las aplicaciones establecer --ntasks-per-node=N, con N igual a la cantidad de tareas si es menor a 20 ó 24 (el trabajo entra en un nodo), o usar N=20 (ó N=24, según el tipo de nodo elegido) cuando la cantidad de tareas excede ese valor. El tiempo máximo permitido para un trabajo son 15 días, si no se especifica se asignan por defecto 4 días. Cumplido el plazo, el trabajo será cancelado con un error de TIMEOUT. Para trabajos cortos (pocas horas/días) se recomienda indicar el tiempo porque puede permitir al planificador de Slurm insertarlo en un hueco de recursos.
  Para lanzarlo (no es necesario que el script tenga permiso de ejecución):
  sbatch trabajo.sh
  y devuelve un texto similar a
  Submitted batch job 101
  Luego con squeue -l se puede ver el estado:
  

  JOBID	PARTITION	NAME	USER	STATE	TIME	TIME_LIMI	NODES	NODELIST(REASON)
  101	work	prueba4	alguien	PENDING	0:00	UNLIMITED	1	(Resources)
  100	work	mpi-slur	alguien	RUNNING	0:44	UNLIMITED	5	compute-0-[2-7]

  
  El trabajo prueba4 ha quedado en espera (PENDING) hasta que haya nodos suficientes/adecuados (Resources) para que se ejecute.
  El mismo script "trabajo.sh" se puede enviar con otras opciones (tienen precedencia sobre las variables SBATCH):
  
  sbatch --ntasks=4 --constraint=RAM16 --job-name=parte2 trabajo.sh
  De este modo no es necesario crea o modificar un script por cada trabajo.


• Opciones útiles:
  
  • --job-name=prueba4 # nombre para identificar el trabajo. Por defecto es el nombre del script
  • --ntasks=N # solicita N cores, por defecto se asignan consecutivamente dentro de un nodo. Si N excede la cantidad de cores continúa en otro nodo.
  • --cpus-per-task=C # por cada tarea solicita C cores, utilizando en total C*N cores. Es útil para código híbrido MPI+OpenMP: lanza N procesos MPI reservando C cores para cada una.
  • --ntasks-per-node=TPN # asigna a lo sumo TPN tareas por nodo hasta completar las ntasks, sin ocupar el resto de cores del nodo. Por ejemplo, si N=20 y TPN=10 se ocuparán 10 cores en 2 nodos.
  • --nodes=P # solicita P nodos completos. Tener en cuenta lanzar la cantidad adecuada de procesos para que el nodo no quede subtulizado.
  • --mem-per-cpu=M # asigna M megabytes de memoria por cada ntask. Si no se especifica, por defecto es 6440 MB (aprox 6.3 GB). Tener en cuenta que la tarea será cancelada si excede la cantidad solicitada.
  • --output=trabajo-%j.salida.txt # redirige la salida del script al archivo especificado.
  • --error=trabajo-%j.error.txt # redirige la salida de error del script al archivo especificado.
  • --mail-user=alguien@mail.com.ar --mail-type=end # envía un correo cuando el trabajo finaliza correctamente o por algún error.
  • --no-requeue # no permite que el trabajo vuelva a ejecutarse luego de un problema en los nodos u otra interrupción. Es útil si el código/aplicación utilizado no tiene capacidad de continuar desde el último estado guardado.
  • Se pueden encadenar trabajos independientes para que se ejecuten siguiendo un orden: sbatch --dependency=afterany:110 segunda_parte.sh
    Las opciones posibles para --dependency son:
    • afterany:job_id[:job_id...]
      Este trabajo comienza cuando la ejecución del trabajo con id job_id haya finalizado.
      
    • afternotok:job_id[:job_id...]
      Este trabajo comienza su ejecución luego de que el trabajo especificado en job_id haya finalizado con algún estado de error (código de sálida distinto de cero, fallo de nodo, timeout, etc.)
      
    • afterok:job_id[:job_id...]
      Este trabajo comienza su ejecución luego de que el trabajo especificado en job_id haya finalizado correctamente.
      
    
    
  Como se menciona en la descripción de los equipos, este cluster posee dos tipos de CPU en los nodos: de 20 cores (2 x Xeon E5-2650 v3 @ 2.30GHz de 10 cores cada uno) y de 24 cores (2 x Xeon E5-2650 v4 @ 2.20GHz de 12 cores cada uno). Si bien los rendimientos son similares, para ciertas aplicaciones puede convenir uno u otro (por ejemplo para aplicaciones que no pueden usar más de un nodo) o garantizar que sean todos iguales. Principalmente se debe tener cuenta si se hacen pruebas de rendimiento. Para seleccionar uno u otro se utiliza --constraint=v3-20cores o --constraint=v4-24cores


• Recursos especiales: El cluster tiene 5 nodos con una placa GPU Nvidia Tesla K40 cada uno (accesible a través de CUDA), y un nodo con una placa Intel Xeon Phi. Estas placas obtienen mayores rendimientos que las CPU de los nodos para algunos algoritmos/programas, y se pueden usar de forma individual o en conjunto con las CPU de los nodos. Slurm los denomina GRES y permite solicitarlos para obtener uso exclusivo de los mismos durante un trabajo. La cantida de cada GRES es por nodo, no en total para el trabjo. Para ello es necesario especficar los recursos a usar, incluyendo los cores.
  • --gres=gpu --ntasks=N # usar nodos dentro de la partición "gpu" y la placa GPU por cada nodo pedido. Asigna además N cores por nodo pedido, máximo 2 cores.
  • --gres=mic # usar nodo dentro de la partición "gpu" y la placa Xeon Phi. Asigna además un core en el nodo. Al disponer sólo de una placa no se puede solicitar más de un nodo.


• Comandos útiles:
  • squeue -l # lista los trabajos en ejecución y espera
  • sinfo # muestra estado de los nodos
  • scancel JOB_ID # cancela un trabajo
  • slurm j JOB_ID # muestra detalles de un trabajo


• Importante: Los comandos (sbatch, squeue) y opciones (--ntasks, --job-name) son sensibles a mayúsculas.