Saltar a contenido

CESGA#

Vista general#

El CESGA (Centro de Supercomputación de Galicia) es un centro público de supercomputación. Da a tus solvers acceso a dos máquinas, cada una conectada a la plataforma como un provider propio:

Provider Máquina Qué es
CESGA FinisTerrae III ft3.cesga.es Supercomputador de propósito general: nodos CPU x86, nodos GPU NVIDIA A100 y T4, y nodos ARM (A64FX)
CESGA QMIO qmio.cesga.es El ordenador cuántico del CESGA. Acceso restringido

Las dos se gestionan con Slurm, así que tu solver no calcula nada por sí mismo: envía un job por lotes al clúster, espera a que termine y devuelve la salida. Eso significa también que las dos se manejan exactamente con el mismo código: cambiar de máquina es cuestión de qué provider usa tu solver, no de reescribir nada.

Nota

Esta es la página específica del provider. La API del cliente, las opciones del job y el formato de los resultados son iguales para todos los providers de HPC y están documentados en Cómo crear un solver de HPC: lee primero esa página y vuelve aquí para lo específico del CESGA.

Cómo funciona#

Los nodos de login del CESGA solo son accesibles desde redes autorizadas: las de los centros de investigación y universidades asociados. Desde cualquier otro sitio la conexión simplemente expira, así que la plataforma llega a ellos a través de la VPN del CESGA.

No tienes que ocuparte de nada de eso: cuando tu solver usa un provider del CESGA, la plataforma, antes de que se llame a tu run():

  1. Levanta la VPN hacia el CESGA.
  2. Inicia sesión en el clúster y prepara el acceso a Slurm.
  3. Inyecta las credenciales del clúster como variables de entorno, que el cliente de HPC lee por ti.

Tu run() → envía un script → cliente de HPC → Slurm a través de la VPN → el clúster lo ejecuta en un nodo de cómputo → la salida del job vuelve a tu run().

Solo se ejecuta en la plataforma

Los solvers que usan estos providers no se pueden ejecutar en local con python app.py. La VPN, las credenciales del clúster y el cliente de HPC solo existen dentro del entorno de ejecución de QCentroid. Puedes desarrollar la lógica del job en local si quieres, pero prueba el solver completo en la plataforma.

Crear un solver para el CESGA#

1. Habilita el provider#

Ve a la sección Providers, busca CESGA FinisTerrae III (o CESGA QMIO) y pulsa Enable.

  • Cuando se te pida, añade tu usuario y contraseña del CESGA.

Una sola cuenta para todo en el CESGA

Las mismas credenciales abren la VPN y el clúster: el CESGA emite una única cuenta. No son las de QCentroid; te las da el CESGA cuando te conceden el acceso. Introduce el usuario solo (miusuario), nunca la dirección de correo completa. Los introduces una vez, aquí; a partir de ese momento la plataforma los inyecta en tus solvers y nunca los escribes en tu código.

El acceso a QMIO se concede aparte

Poder llegar al CESGA no basta para QMIO: tu cuenta tiene además que estar habilitada para esa máquina. Si no lo está, la conexión llega al nodo de login y se rechaza. Pídele al CESGA que te la habilite antes de crear un solver de QMIO.

2. Registra tu solver#

Ve a My solvers → Add new solver, y después:

  1. Selecciona uno de los casos de uso existentes.
  2. Selecciona como proveedor de hardware el provider del CESGA que habilitaste.
  3. Elige el lenguaje de HPC (python_hpc) en el desplegable de lenguaje de programación. Esto es lo que le indica a la plataforma que construya tu solver con el cliente de HPC y la VPN.
  4. Completa el resto de la información y pulsa Add new solver.

3. Implementa tu solver#

Escribe tu qcentroid.py usando el cliente de HPC (mira el solver de ejemplo más abajo) y súbelo a un repositorio Git.

4. Conecta tu repositorio#

Ve a la sección Repositories, pulsa Connect a new repository, selecciona el solver que acabas de crear, rellena el resto de los detalles y pulsa Connect repository.

Ya tienes el solver registrado, conectado al clúster y listo para ejecutarse. Para lanzarlo, consulta Cómo ejecutar un job.

Trabajar con estos clústeres#

Indica siempre memoria y tiempo#

Es la regla con la que todo el mundo tropieza primero: un job que no indica a la vez su memoria y su límite de tiempo se rechaza en el momento del envío.

job_id = client.run_job(
    BATCH_SCRIPT,
    name="my-job",
    time_limit=10,           # minutos — obligatorio
    memory_per_node=4096,    # MB      — obligatorio
    environment="login",     # para que `module load` funcione
)

El provider configura una memoria por defecto, así que un solver que no pase nada envía igualmente un job válido. Aun así, fija los dos de forma explícita: son los dos valores que solo tú conoces.

No nombres ni partición ni QOS#

FinisTerrae III tiene particiones (short, medium, long, ondemand, …), pero no está pensado que elijas una: Slurm enruta el job automáticamente según los recursos que pida, y la propia guía del CESGA desaconseja fijar la QOS a mano. Nombrar cualquiera de las dos es una causa habitual de envíos rechazados, así que el provider las deja sin fijar a propósito.

La excepción es el tipo de nodo, que se selecciona con una restricción de Slurm en lugar de con una partición:

job_overrides={"constraints": "clk"}   # Intel Cascade Lake; "epyc" para AMD EPYC

Pedir una GPU#

Los nodos con GPU de FinisTerrae III se piden con gres, nombrando el modelo:

gres="gpu:a100:1",     # una A100
cpus_per_task=32,      # los cores escalan con las GPUs: 32 por GPU en los nodos estándar

Módulos del clúster#

El software se carga con module (Lmod). Hay algo específico del CESGA: solo la sección Core es visible hasta que cargas primero un módulo base, así que module load <algo> falla por sí solo hasta que haces:

module load cesga/2022     # o cesga/2020, o cesga/system
module load <el software que necesites>

Dos cosas más para que module funcione dentro de tu job:

  • Empieza el script con #!/bin/bash -l: la -l lo convierte en un shell de login.
  • Pasa environment="login" a run_job(), para que el entorno de login del clúster se propague al job.

Usa module spider <nombre> en el clúster para ver qué hay disponible: el catálogo cambia con el tiempo.

Solver de ejemplo#

Un qcentroid.py completo que ejecuta un job en FinisTerrae III:

qcentroid.py
import logging
from qcentroid_solver_runner.hpc import QCentroidHPCClient

logger = logging.getLogger("qcentroid-user-log")   # para que el progreso salga en el panel

# "-l" ejecuta un shell de login, que es lo que hace que `module` esté disponible.
# cesga/2022 es el módulo base que hace visible el resto del stack de software para Lmod.
BATCH_SCRIPT = """#!/bin/bash -l
module load cesga/2022

echo "Running on $(hostname)"
python3 -c 'print("Hello world from CESGA")'
"""


def run(input_data: dict, solver_params: dict, extra_arguments: dict) -> dict:
    logger.info("Enviando el job al CESGA...")

    with QCentroidHPCClient(logger=logger) as client:
        client.login()

        # Útil en una primera ejecución: registra las particiones que el clúster tiene de
        # verdad y bajo qué combinaciones puede enviar tu cuenta.
        logger.info("Particiones: %s", client.list_partitions())

        job_id = client.run_job(
            BATCH_SCRIPT,
            name="my-hpc-job",
            time_limit=10,           # minutos — obligatorio aquí
            memory_per_node=4096,    # MB      — obligatorio aquí
            environment="login",     # para que `module load` funcione
            # Sin partición ni QOS: Slurm elige ambas según los recursos pedidos.
        )
        logger.info("Job %s enviado", job_id)

        # Acota la espera: el clúster es compartido, así que las colas pueden ser largas.
        client.wait_for_completion(job_id, poll_interval=5, queue_timeout=3600, run_timeout=600)

        result = client.get_job_results(job_id)

    logger.info("Job %s terminado: %s (código de salida %s)", result.job_id, result.state, result.exit_code)

    return {
        "job_id": result.job_id,
        "state": result.state,
        "succeeded": result.succeeded,
        "stdout": result.stdout,
        "stderr": result.stderr,
    }

El mismo solver se ejecuta en QMIO apuntándolo al provider de QMIO: solo cambia el script por lotes, porque el stack de software cuántico tiene sus propios módulos. La referencia completa del cliente —todas las opciones de run_job(), los campos de JobResult y cómo publicar assets— está en Cómo crear un solver de HPC.

Cosas a tener en cuenta#

  • Los tiempos en cola pueden ser largos. Son infraestructuras nacionales compartidas, así que un job puede pasar un rato encolado antes de ejecutarse. wait_for_completion() registra el motivo de la cola en cada sondeo; acota la espera con queue_timeout / run_timeout si tu solver no debe esperar indefinidamente.
  • Un job fallido del clúster no es automáticamente un solver fallido. Tu run() devuelve con normalidad, reportando el estado. Lanza una excepción tú mismo si quieres marcar toda la ejecución como fallida.
  • Guarda la salida del job. Deja el stdout crudo, informes o gráficas en una carpeta additional_output para publicarlos como assets descargables.
  • El CESGA documenta sus propias máquinas. Los tipos de nodo, el catálogo de software, el almacenamiento y las cuotas están cubiertos por la guía de usuario de FinisTerrae III; esta página solo cubre cómo llegar al clúster desde un solver.

Qué sigue#

Cómo crear un solver de HPC

Ejecuta tu solver

Edita o actualiza este solver