A pesar de que había dado por concluído este topic, creo conveniente retomarlo porque encontré una mejor forma de planificar los cálculos enviados desde la interfaz web.

Después de probar varios sistemas de colas, encontré que uno muy fácil de instalar y ampliar, con funcionamiento en Windows y Unix. Se llama Condor (http://www.cs.wisc.edu/condor/), un sistema para adminsitrar grids de workstations. Había oido hablar de él y sabía que existía, pero nunca lo había instalado y configurado,

La adaptación de mi código actual para utilizar Condor fue muy sencilla y rápida, y ahora mi sistema es mucho más robusto.

Durante las pruebas del algoritmo genético para la diagnosis espectroscópica, me encontré con dos problemas que no dependían de mi algoritmo, sino del entorno de ejecución.

El primero de ellos fue la conexión a Internet de mi casa. Mi conexión se cae cada dos por tres. Si ejecuto el algoritmo genético (es un programa en python) en la conexión ssh al supercomputador, el programa finaliza de forma incorrecta al interrumpirse la conexión. Para evitarlo utilicé el programa nohup. Este programa estándar de UNIX desliga un proceso de su terminal, de modo que aunque el shell o la conexión se corten, el proceso sigue ejecutándose. Esto solucionó el primer problema.

El segundo problema fue el autologout del shell bash. A pesar de ejecutar el programa con nohup, mi nohup ejecutaba un script bash que es el que realmente ejecutaba el algoritmo genético python:

$ nohup run.sh

El script bash run.sh es algo parecido a esto:

#!/bin/bash
NI=200
./clean.sh
python algoritmo.py parametros

La forma de solucionar el autologout fue mediante una variable de entorno llamada TMOUT. Si se pone a 0, el bash nunca hace autologout por falta de actividad de entrada/salida.

El script bash run.sh quedó de este modo:

#!/bin/bash
TMOUT=0
NI=200
./clean.sh
python algoritmo.py parametros

Esto solucionó mis problemas y ya tengo el algoritmo genético ejecutándose y diagnosticando en el Supercomputador de Canarias.

En este post describo un conjunto de herramientas que puede servir para programar un gestor automatizado de trabajos dependientes en el Super Computador de Canarias.

El Super Computador de Canarias es un sistema distribuido de computación adquirido por la Agencia Canaria de Investigación, Innovación y Sociedad de la Información hace un par de años. Se integra en la red española de super computación. Tiene 80 máquinas IBM con 2 procesadores de doble núcleo cada una. En total dispone de 332 procesadores de cómputo. Recientemente he descubierto, además, que un único usuario no puede utilizar más del 61% de los recursos…

Para realizar mis experimentos de diagnosis de plasmas de fusión, necesito ejecutar un algoritmo genético que lanza de 8 a 200 simulaciones del plasma en cada generación. Cada una de estas simulaciones, según el elemento químico y otros parámetros físicos, puede tardar hasta 6 horas, que es el tiempo que manejo con las simulaciones actuales. Es aquí donde el uso del Super Computador es ideal, ya que me permite calcular las 200 simulaciones en paralelo, y en lugar de desayunar durante 1200 horas, sólo lo hago durante 6.

El problema surge en que para que se ejecuten esas simulaciones, hay que enviarlas al cluster mediante las órdenes de envío de trabajos ‘mnsubmit’. Mi algoritmo genético ejecutado en la máquina Atlante de login se encarga de crear los scripts de trabajo para cada simulación y lanzarlos al cluster, y quedarse esperando a que los trabajos terminen. Este proceso, que en lenguaje natural es muy sencillo, requirió el uso de algunas herramientas interesantes, y que pongo a disposición de la comunidad. Están adaptadas de otras herramientas creadas por … bueno, no se por quién, pero lo adapté de aquí: http://www.cac.cornell.edu/wiki/index.php?title=Programmatically_Submitting_Jobs_and_Checking_Whether_They_are_Done. para otro sistema distribuido de cómputo, e incluyen algunos ejemplos.

Super Computador Python Utilities

El siguiente paso para completar la interfaz es hacer un job scheduler o instalar alguno de los que por ahí existe. La ventaja de la segunda opción es obvia: control de colas, usuarios, recursos eficiente. La desventaja es el tiempo que lleva manejar todo eso.

Programarlo nosotros mismos puede dar, en cualquier caso, resultados aceptables. Para programarlo he utilizado una librería de gestión de hilos muy simple, que puede encontrarse en http://chrisarndt.de/projects/threadpool. Es lo mejor y más simple que he encontrado y la utilizo también para mi algoritmo genético. Enhorabuena a Christopher Arndt, su programador. Me ha ahorrado muchas horas de trabajo.

Simple Job Scheduler

El proceso consiste ahora en ejecutar el server.py en la máquina que ejecuta el servidor web. Este servicio se quedará esperando a que un cliente (el client.py) le envíe trabajos para realizar.

El cliente se ejecutará en el punto donde se solicitaba al servidor web la ejecución del código de cálculo, ahora con los parámetros adecuados al software cliente. El software cliente encolará el trabajo en el server y devolverá el control al servidor web, que mostrará la pantalla de actualización del trabajo.

Ahora es cuestión de cada uno ponerlo lo más bonito posible. Y corregir fallos en mi código, que seguro que los hay.