Buenas prácticas#
Recopilación de recomendaciones para sacar el máximo partido a la plataforma, desarrollar solvers robustos y gestionar eficientemente los recursos de BIQAIN.
Desarrollo del solver#
Empieza desde la plantilla, no desde cero.
El repositorio ya contiene qcentroid.py, Launcher.ipynb y requirements.txt con la estructura correcta. Modifica estos archivos en lugar de crearlos de nuevo para evitar errores de firma o de nombre.
No modifiques la firma de run().
La plataforma llama exactamente a run(input_data, solver_params, extra_arguments). Cambiar el nombre de la función o el número de parámetros impedirá que el solver se ejecute.
Añade logs desde el primer momento. No esperes a que algo falle. Registra los valores de entrada, los pasos intermedios y los tiempos de ejecución desde el principio. En un entorno de experimentación, la visibilidad interna del solver vale más que unas líneas de código extra.
logger.info(f"input_data: {input_data}")
logger.info(f"Paso intermedio completado en {elapsed:.2f}s")
Los mensajes aparecen en la pestaña Execution logs de la página de detalle del job.
Mide el tiempo de ejecución. Incluye mediciones de tiempo en las partes críticas de tu algoritmo desde el principio. Te ayudará a detectar cuellos de botella y a estimar el coste antes de escalar a hardware más caro.
import time
start = time.time()
# proceso a medir
logger.info(f"Tiempo: {time.time() - start:.2f}s")
Deja escalar las excepciones bloqueantes.
Evita capturar excepciones de forma global (except Exception en el nivel raíz). Si una excepción se captura y no se relanza, la plataforma no puede detectar que el solver ha fallado y no mostrará la traza en la página de detalles del job. Usa try/except con alcance limitado para errores esperados y controlados.
Prueba en el IDE antes de subir a la plataforma.
Usa el Launcher.ipynb para ejecutar tu solver localmente con datos de prueba. Es mucho más rápido iterar en el IDE que lanzar jobs en la plataforma para cada cambio.
Gestión de dependencias#
Mantén el requirements.txt lo más abierto posible.
Incluye solo las librerías que tu código importa directamente y sin versiones fijas innecesarias:
ortools
numpy
Evita hacer pip freeze y copiar el resultado: ese archivo incluye cientos de dependencias transitivas con versiones fijas que pueden entrar en conflicto en el entorno de la plataforma.
No uses pip install como solución permanente.
Puedes instalar paquetes en el IDE para probar, pero esa instalación no persiste entre sesiones ni se aplica en la plataforma. Toda dependencia necesaria debe estar en requirements.txt.
Flujo de trabajo en la plataforma#
Ejecuta jobs con frecuencia, no solo al final. Lanza jobs cada vez que tengas una versión estable de tu algoritmo. Detectar problemas pronto es mucho más barato que hacerlo después de semanas de desarrollo.
Lanza el Build después de cada push. La plataforma no recoge los cambios del IDE directamente, solo del repositorio Git. Después de cada push, ve a Solvers > Repositories y lanza el proceso Build para que la plataforma use la versión más reciente.
Haz commit y push al servidor Git con regularidad. Tanto el LaunchPad como el servidor del cluster Fujitsu tienen un volumen persistente: tus archivos se conservan entre sesiones. Aun así, el repositorio Git es tu copia de seguridad fuera del entorno — commitea y haz push con frecuencia para no depender únicamente del volumen local.
Apaga el servidor del LaunchPad cuando no lo uses. Cuando termines de trabajar o no vayas a usar el LaunchPad durante un tiempo prolongado, apaga el servidor manualmente para liberar recursos. El LaunchPad incluye un mecanismo de apagado automático tras 1 hora de inactividad, pero apagarlo tú antes es la mejor práctica.
Revisa el historial de builds. Si un job falla de forma inesperada, comprueba primero el historial de builds del repositorio. Un build fallido (entrypoint no encontrado, error de dependencias) puede ser la causa de errores que parecen de ejecución.
Gestión de créditos y costes#
Empieza con simuladores y datasets pequeños. Antes de usar hardware cuántico real o recursos de mayor coste, valida tu solver con simuladores y datos reducidos. Esto te permitirá detectar errores rápidamente y tener una estimación realista del coste y el tiempo de ejecución antes de escalar a recursos más costosos.
Consulta el coste estimado del solver antes de lanzar. El coste estimado de cada ejecución se muestra en la página de detalle del solver. Revísalo antes de lanzar jobs intensivos.
Revisa el saldo de créditos antes de ejecuciones intensivas. Ve al menú de usuario > Credits para ver el saldo disponible. Si un job no tiene créditos suficientes asignados al usuario, la ejecución será rechazada.
Redistribuye créditos si es necesario. Cualquier miembro de la organización puede reasignar créditos desde menú de usuario > Credits. Si la bolsa total está agotada, contacta con la Oficina Técnica de BIQAIN.
Cluster Fujitsu (SLURM)#
Usa el nodo de login solo para gestión.
El nodo login.lantik.lab es para enviar trabajos, revisar resultados y editar ficheros. No ejecutes cálculos intensivos directamente en él — usa siempre sbatch para lanzar trabajos al cluster.
Verifica los saltos de línea en scripts .sh creados en Windows.
Los archivos editados en Windows pueden contener saltos de línea CRLF que causan errores en el cluster Linux. Conviértelos antes de enviarlos:
sed -i 's/\r//' mi_trabajo.sh
O cambia el formato en el IDE: barra inferior CRLF → LF antes de guardar.
Monitoriza tus trabajos con squeue.
Después de hacer sbatch, comprueba que el trabajo está en cola:
squeue -u tu_usuario
Si lleva mucho tiempo en estado PD (pending), el cluster puede estar saturado. Consulta sinfo para ver la disponibilidad de nodos.
Inicia el LaunchPad con un solver Fujitsu para activar la VPN.
La conexión VPN al cluster se activa automáticamente solo cuando abres el LaunchPad con un solver asociado al proveedor Fujitsu. Sin esta condición, login.lantik.lab no será accesible.
Los datos del cluster son persistentes, pero haz push igualmente.
Tu directorio home en el cluster (/home/tu_usuario/) tiene almacenamiento persistente: los scripts y resultados se conservan entre conexiones SSH. Aun así, guarda en el servidor Git el código relevante para tener trazabilidad y una copia fuera del cluster.
Soporte#
Si tienes dudas que no se resuelven con esta documentación, contacta con la Oficina Técnica de BIQAIN: