Mientras investigaba el javadoc, me surgió la idea de la documentación automática aplicada a Fortran. ya estaba inventado. Se llama grdoc y permite básicamente lo mismo que el javadoc.

Aplicar el esquema de documentación de grdoc al código fuente Fortran del proyecto será sin duda una fabulosa ayuda a la hora de mantener y portar el código.

La cadena de televisión Cuatro tiene una oferta de programación cuando menos interesante. He oido que están reponiendo series muy viejas (de esas que ya ni te acuerdas). Ayer mismo vi Juzgado de Guardia (risas).

Pues bueno, sobre el programa que da nombre al post, he de decir que lo he visto como tres o cuatro veces, y es moderadamente entretenido. Eso sí­, no hay que creerse nada de lo que dicen.

Tiene un aire a pseudociencia y a paranormalidad exacerbada que me hace dudar de la cordura humana. Me niego a creerme ninguna de las paranormalidades que dicen que ocurren. Es funesto es que intenten vendernos la moto, presentando los sucesos en plan periodí­stico y cientí­fico.

Por lo que me he enterado, el Cí­cuclo escéptico está recogiendo firmas para que lo quiten de emisión. No me parece mal. Podrí­an rellenar el espacio con cosas que ocurrieran de verdad. Además de entretenido serí­a educativo.

Discutiré en este post algunos aspectos importantes de las aplicaciones de gestión de proyectos que estoy empleando para gestionar el proceso de elaboración de mi proyecto de fin de carrera.

Por un lado tenemos openWorkbench, una aplicación tradicional muy similar al Microsoft Projects, contando con muchas de las funciones de éste, si no todas. Diagramas Gantt, multiples baselines, auto planificación, permite contabilizar las horas trabajadas en los proyectos, etc.

Por otro lado está dotProject, una aplicación en lí­nea programada en PHP que permite interacción entre varios usuarios, gestión de ficheros, un foro y un sistema de “tickets”. La gestión de tareas es sencilla (no abarca todas las opciones disponibles en openWorkbench): dibuja diagramas Gantt pero no permite dependencias complejas.

openWorkbench parece funcionar bien, hasta que pasa un cierto tiempo. Por alguna extraña razón los datos comienzan a corromperse misteriosamente. Pierdes trabajo, te frustras y acabas mandándolo a criar malvas. Prácticamente todo mi proceso de copias de seguridad existe para salvaguardar el estado de mi planificación openWorkbench. He tenido que rehacer la planificación al menos una vez desde cero, y recuperar versiones de los backups por lo menos 20 veces.

dotProject no me ha hecho ninguna faena aún. Es cierto que no puedo ver los diagramas de Gantt, pero es porque no tengo configurada las GD en el servidor. Además, en el dotProject se pueden compartir ficheros y documentos de forma integrada, almacenando toda la información formal del proyecto de forma centralizada y accesible a los miembros del mismo.

En conclusión, el openWorkbench tiene bugs que ocasionan pérdidas irreparables. Si pudiera elegir ahora retrospectivamente, no lo utilizarí­a. dotProject no tendrá tantas opciones, pero al menos no falla catastróficamente.

MPI Slaver ( o Esclavista MPI en español) ha sido mi propuesta de proyecto para el grupo OSCAR (Open Source Cluster Application Resourcers) y la Mars Space Flight Facility.

MPI Slaver es una librerí­a de utilidades de alto nivel que se construye sobre MPI y que permite una sencilla programación en modelo maestro – esclavo.

Las ventajas de usar MPI Slaver frente a MPI directamente surgen cuando se dispone de un cluster que utilice openMosix o Kerrighed y soporte la migración de procesos de forma transparente.

Para explicar como MPI Slaver aumenta el rendimiento en un cluster de alta disponibilidad acercándolo a un enfoque hí­brido entre HPT y HPC expondré parte de la descripción que utilicé para la descripción del proyecto.

A MPI process ‘A’ (the main worker) will ask the master for help to do a task, requesting ‘X’ helper workers to get aided in his task. The master will assign it a set with ‘X’ workers. When ‘A’ receive them, it split it task into ‘X’ parts and send one of them to each helper worker.

When a helper process ends, it send its results to the main worker and returns to a free worker state (notifying master).

At this moment, ‘A’ has finish it task and continues its execution.

The level of sub tasking of a task is only set by the application programmer.

Which that schema, and creating more MPI process than nodes in the cluster, openMosix or Kerrighed will take care of process migration, assigning processes to idle nodes. Maybe there will be more than one process by node, but it is not a problem: it is desirable because some of them could be waiting for work (and will be migrated when a task will be assigned to them) and will not consume CPU time.

A highly parallelizable software, but at coarse-grain level is the target for MPI Slaver. Using only openMosix or Kerrighed will lead to unused CPU power: it is a heterogeneus cluster, so when the high end processors will finish their tasks the processes on the low power computers will be migrated to them; therefore the computing power in the low power computers will be unused.

Using MPI in a classical way in this environment will not produce a better performance than a fork programming model. The key is to decrease the grain level and to increase the MPI processes number, but not using a SPMD classical approach, but a MPMD available by means of MPI Slaver.