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.

Recientemente he tenido que crear una interfaz gráfica sencilla para ejecutar via web el código de cálculo de propiedades radiativas de mi grupo de investigación.

Comienzo así una serie de posts sobre las técnicas que he utilizado para hacerlo funcionar.

En este primer post hablaré de la necesidad de controlar fácilmente las entradas y salidas del programa siguiendo buenas técnicas de diseño.

El programa será ejecutado por el servidor web en una primera fase o por un gestor de trabajos (job queue manager o job scheduling) en una fase posterior, es necesario que se le puedan pasar las opciones de ejecución por línea de comandos, al estilo Unix. Hay muchas formas de hacer esto y depende del lenguaje de programación utilizado. Esto es necesario porque varias instancias del programa se ejecutarán simultáneamente en la máquina, de modo que si los nombres de los ficheros están incluidos en el código fuente los ficheros pueden estar bloqueados por otra instancia, o peor aún, se sobreescribirán los datos de otras ejecuciones.

Por ejemplo, si disponemos de un código en python para ejecutar el Flexible Atomic Code para el cálculo de datos atómicos, será necesario que nuestro código admita al menos unos cuantos argumentos: elemento químico, ion y fichero de salida, de modo que pueda ejecutarse así:

runFac -ion 2 -elemento C -outfile carbono2.dat

Hechas estas modificaciones, podemos pasar a la segunda parte del artículo…

Un nuevo subproyecto en el que me voy a embarcar es la separación del código de cálculo de datos atomicos de Abako.

Antiguamente los códigos sobre los que se construyó Abako estaban separados, pero fueron integrados para facilitar el cálculo de poblaciones iónicas. Ahora que algunos miembros del grupo estan interesados en modificar los potenciales – que se usan para la generación de los datos atómicos que Abako utiliza – pues se hace interesante separar la parte de los datos atómicos de Abako. No parece requerir grandes esfuerzos y ya estamos pensando en crear una aplicación web que permita ejecutar el New Atomic (que así­ se llamará el código) y obtener los resultados, incluso mostrando las funciones de onda de los electrones.

En cuanto este funcionando, haré un post con algunas gráficas.

La matriz de tasas contiene los coeficientes del sistema de ecuaciones que es necesario resolver para calcular las poblaciones iónicas en el plasma.

En este caso muestro la matriz de tasas generada por Abako en el caso del Oro entre los iones con 26 y 33 electrones. Me ha interesado ponerla porque es curiosamente bonita .

El cálculo consistí­a en hallar las poblaciones iónicas de los iones correspondientes a ese número de electrones. Ejecutando Abako bajo Ubuntu Linux en la máquina virtual tardó “solamente” 18 horas.