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.

El siguiente paso consiste en crear la infraestructura web para mantener la aplicación.

Lo más fácil es utilizar xampplite en Windows; en Linux hay que instalar el apache y un lenguaje de script con el que te sientas cómodo. Yo recomiendo python o php, aunque en este tutorial me ceñiré a php.

Nuestro sistema necesitará entradas, que serán suministradas por un formulario html, y un wrapper que lea las opciones del formulario y se las mande al código. Esto es un método directo, por así decirlo, hasta que instalemos un gestor de ejecución.

El formulario puede llamarse index.php y el wrapper run.php. Ambos en el mismo directorio del servidor web, que puede ser htdocs/wui.

He puesto un ejemplo que desarrollé para mi propio código. Es en el wrapper run.php donde se hace importante lo dicho en el anterior post, donde hablé de la necesidad de permitir al código leer opciones desde la línea de comandos.

El comando php para ejecutar el código es system(), que ejecuta un programa en el servidor. Cuando el programa termina, el script php continua su ejecución.

Ejemplo php:

$input = $_GET['opcion1'];
$output = $_GET['opcion2'];

system("micodigo -input $input -output $output");

¿Cuál es el problema aquí? Si nuestro código es costoso en tiempo computacional, tardará más de 10 segundos en ejecutarse. Tener al usuario esperando que una web se cargue más de 5 segundos es como mínimo, arriesgado: puede aburrise, darle a volver en el navegador, cerrar la ventana, etc.

Lo que necesitamos ahora es el job scheduler, para mandar el trabajo a ejecutarse y mientras, mostrar al usuario una web de espera y decirle cómo puede acceder a sus resultados cuando el trabajo haya finalizado.

De esto hablaremos en el siguiente post…