UNIVERSIDAD SIMÓN BOLÍVAR

Ingeniería de la Computación

Aplicaciones de Exploración y Producción de Petróleo y Gas en

Plataformas Cluster Heterogéneas y Grid

por
Rodolfo Miguel Martínez Macedo

Proyecto de Grado
Presentado ante la Ilustre Universidad Simón Bolívar
como Requisito Parcial para Optar al Título de
Ingeniero en Computación

Sartenejas, Enero del 2008

 UNIVERSIDAD SIMÓN BOLÍVAR
DECANATO DE ESTUDIOS PROFESIONALES

COORDINACIÓN DE INGENIERÍA DE COMPUTACIÓN

ACTA FINAL DE PROYECTO DE GRADO

Aplicaciones de Exploración y Producción de Petróleo y Gas

en Plataformas Cluster Heterogéneas y Grid
Presentado por

Rodolfo Miguel Martínez Macedo

Este proyecto de grado ha sido aprobado en nombre de la Universidad Simón Bolívar por el siguiente jurado

examinador:

Prof. Yudith Cardinale (Tutor Académico)

Prof. Carlos Figueira (Co-tutor Académico)

Prof. Angela Di Serio

Jurado

Prof. Emely Arráiz

Jurado

Sartenejas, Enero de 2008

 Aplicaciones de Exploración y Producción de Petróleo y Gas
en Plataformas Cluster Heterogéneas y Grid
por
Rodolfo Miguel Martínez Macedo

Resumen

Este trabajo consistió en la instalación, adecuación y entonación de dos aplicaciones de exploración y pro-

ducción de petróleo y gas en plataformas cluster heterogéneo que se accede a través de mecanismos de grid.

Como parte de la adecuación se desarrollaron aplicaciones interactivas que facilitan la ejecución en plataformas

cluster heterogéneas a través de un grid computacional para aplicaciones del área de exploración y producción

de gas y petróleo.

Una de las aplicaciones desarrolladas es Trimodeler, la cual provee una interfaz para el modelado de capas

del subsuelo realizado con un comando del paquete Seismic Unix. Le permite al usuario especificar, en un eje de

coordenadas, los puntos que definen los límites entre subcapas de diferentes formas y/o densidades. El modelo

creado puede ser guardado en un archivo, pudiendo ser cargado y modificado posteriormente. También es

posible ejecutarlo como módulo integrado (plugin) de generación de datos para la aplicación JobDAG.

La otra aplicación es Eclipse-R. Ésta le permite al usuario especificar las diferentes opciones para los coman-

dos @eclipse y @mpieclipse del paquete Eclipse. Ambos comandos son utilizados en el proceso de simulación

de yacimientos, siendo el primero un programa de ejecución secuencial mientras que el segundo es de ejecu-

ción paralela. Se puede ejecutar como un aplicación convencional de escritorio o mediante un navegador web

a través de un portal de aplicaciones.

Tanto Trimodeler como Eclipse-R son herramientas simples que facilitan el envío de trabajos a un grid

computacional, así como también proveen mecanismos para recuperar los datos producidos de manera trans-

parente al usuario.

III
 Índice general

Resumen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II

1. Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.1. Motivación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2. Justificación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.3. Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.4. Presentación del Documento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2. Marco Teórico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Aplicaciones para la Exploración de Petróleo y Gas . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1.1. Seismic Unix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1.2. Eclipse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2. Plataformas de Ejecución de Aplicaciones de Alto Desempeño . . . . . . . . . . . . . . . . . . . . 8
2.2.1. Cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.2.2. Grid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.3. Secure Shell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.4. JobDAG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.5. Portales Grid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.5.1. Portlets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.5.2. GridSphere . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

3. Trimodeler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.1. Análisis de Requerimientos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.2. Selección de Plataformas de Desarrollo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.3. Diseño . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.4. Implantación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.4.1. Ejecución en cluster mediante SSH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.4.2. Ejecución en Grid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.4.3. Implantación del Plugin para JobDAG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.5. Pruebas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.5.1. Ejecución Local . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.5.2. Ejecución Cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.5.3. Ejecución Grid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.5.4. Plugin para JobDAG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.6. Observaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

IV
4. Eclipse-R . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.1. Análisis de Requerimientos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.2. Selección de Plataformas de Desarrollo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
4.3. Diseño . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
4.4. Implantación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
4.4.1. Implantación del Portlet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
4.5. Pruebas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
4.5.1. Aplicación de Escritorio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
4.5.2. Portal Web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
4.6. Observaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

5. Conclusiones y Recomendaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

Bibliografía . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

A. Qt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

B. Generación de claves SSH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

V
 Índice de figuras

2.1. Imagen resultante del proceso de ejecución de trimodel . . . . . . . . . . . . . . . . . . . . . . . . 7

3.1. Diagrama de clases para la aplicación Trimodel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

3.2. Especificación de las capas del subsuelo que se quiere analizar . . . . . . . . . . . . . . . . . . . . 18
3.3. Imagen resultante del procesamiento y generación de archivo PostScript . . . . . . . . . . . . . . 19
3.4. Cuadro de diálogo Ejecución Local de Trimodel. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.5. Cuadro de diálogo Ejecución en Cluster de Trimodel. . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.6. Cuadro de diálogo Recuperar Resultados de Cluster. . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.7. Ventana de confirmación de éxito recuperando los archivos desde el cluster. . . . . . . . . . . . . 21
3.8. Cuadro de diálogo Ejecutar en Grid de Trimodeler. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.9. Confirmación del correcto envío del trabajo al grid. . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.10. Cuadro de diálogo Resultados desde Grid de Trimodeler. . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.11. Ventana con la información del estado de un trabajo enviado al grid por Trimodeler . . . . . . . . 25
3.12. Ventana con la confirmación que un trabajo ha sido recuperado del grid exitosamente . . . . . . 26
3.13. Ventana de inicio en JobDAG. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.14. El archivo ejemplo4.txt cargado y listo para procesarse con JobDAG. . . . . . . . . . . . . . . . 27

4.1. Ventana principal de Eclipse-R. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

4.2. Diagrama de Clases de Eclipse-R. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
4.3. Captura de pantalla del portlet de Eclipse-R. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.4. Ventana que muestra la confirmación de un trabajo enviado exitosamente al grid. . . . . . . . . . 34
4.5. Ventana con la información del estado de un trabajo enviado anteriormente. . . . . . . . . . . . . 35
4.6. Ventana confirmando que se han recuperado los archivos generados en la ejecución en el grid. . 35
4.7. Confirmación de envío del trabajo mediante el Portal Web. . . . . . . . . . . . . . . . . . . . . . . 36

VI
 Capítulo 1

Introducción

1.1. Motivación

La creciente demanda de cómputo en aplicaciones en ambientes científicos, de investigación o industriales,

ha incrementado el interés en el área de computacion de alto rendimiento. La utilización de clusters provee

una opción de cómputo ampliamente usada en la actualidad. Los clusters permiten realizar cómputo de alto

rendimiento a costos muy inferiores a los que representan la utilización de supercomputadores. Es por esta

disminución de costos que la computación de alto rendimiento se ha enfocado en el uso de clusters.

Los clusters no satisfacen completamente los requerimientos de grandes proyectos; existe el problema real

y específico del compartimiento de recursos de forma coordinada y de la resolución de problemas de forma

dinámica dentro de un plano de múltiples organizaciones virtuales [22]. Para atacar este problema planteado

surgen los grid computacionales, interconectando recursos para el aprovechamiento del poder de cómputo

agregado así como la capacidad de almacenamiento de cada una de las partes involucradas en el grid.

En el ambiente industrial, la computación en grid ha ganado interés en los últimos años, en su mayoría

en los sectores energéticos y públicos[5], para la realización de simulaciones complejas y análisis de grandes

volúmenes de datos. PDVSA es en nuestro país uno de los principales usuarios potenciales de esta tecnología,

con el fin de aprovechar la capacidad de cómputo existente para las actividades de simulación, interpretación

y virtualización relacionadas con exploración y producción de gas y petróleo. Como parte del esfuerzo en

lograr este aprovechamiento, PDVSA ha instalado en la Universidad Simón Bolívar el Cluster Miranda, el cual

cuenta con 88 nodos y que servirá para la realización de pruebas de aplicaciones e investigación sobre clusters.

Derivado de las experiencias con el Cluster Miranda, PDVSA planea la posterior instalación de un cluster de

1
1.2. JUSTIFICACIÓN 2

mayores prestaciones. Además está planteado el proyecto de instalación del Grid PDVSA, lo que le permitirá

aprovechar sus recursos geográficamente dispersos.

1.2. Justificación

La ejecución de comandos en grids y clusters, comúnmente implican la elaboración de scripts y empleo de

un terminal de comandos o cónsola, lo cuál se presenta como una barrera difícil de superar para los usuarios

menos experimentados. Sin embargo, es posible desarrollar aplicaciones que provean a los usuarios de una

interfaz más intuitiva, amigable y sencilla.

Ante esta realidad, se eligieron dos aplicaciones utilizadas en la exploración de petróleo y gas, para instalar-

las en el Cluster Miranda y desarrollarles mejores interfaces de uso. Para cada una de ellas se decidió elaborar

una aplicación con interfaz gráfica de usuario.

1.3. Objetivos

Evaluar aplicaciones de código abierto y propietario: La industria petrolera invierte anualmente grandes

sumas de dinero en licencias de software para cómputo y análisis de datos relacionados a esta área. La cons-

tante necesidad de obtener información útil y los costos que ello genera, crearon la necesidad de comenzar

desarrollos de aplicaciones de código abierto, cuyo fin último sea la generación de conocimiento y una plata-

forma tecnológica propia de la empresa estatal. Sin embargo, actualmente no es posible efectuar la completa

migración hacia el software de código abierto debido a que existen aplicaciones propietarias muy establecidas

en la industria.

Instalación y entonación de aplicaciones petroleras en el Cluster Miranda: En la industria petrolera exis-

ten aplicaciones que demandan alto poder de cómputo para las cuales el Cluster Miranda se presenta como

una plataforma de ejecución capaz de producir datos en períodos de tiempo razonables. Es necesaria la instala-

ción de software que no soporta oficialmente al sistema operativo Debian bajo el cual opera el Cluster Miranda.

La correcta puesta en funcionamiento de las aplicaciones requeridas implica un proceso de configuración y

administración más allá de la instalación y opciones por defecto.

1.4. PRESENTACIÓN DEL DOCUMENTO 3

Desarrollar interfaces gráficas para su acceso vía Grid: La utilización de complejas plataformas de cómpu-

to se ha visto restringida por la ausencia de interfaces adecuadas que faciliten su utilización por parte de usua-

rios no especialistas en el área de computación. Se pueden desarrollar interfaces gráficas para el usuario que

sean más amigables y así evitar que los usuarios pasen por arduos procesos de aprendizaje.

El objetivo de este trabajo es elaborar mecanismos sencillos de ejecución en grid y cluster para dos aplica-

ciones comúnmente utilizadas en la industria petrolera, logrando simplificar el trabajo de los usuarios de estas

aplicaciones quienes suelen tener pocos conocimientos en elaboración de scripts e interacción con líneas de

comandos.

Buscando mejorar y optimizar la utilización de aplicaciones de producción de petróleo y gas se implementa-

ron dos aplicaciones. Trimodeler provee al usuario de una interfaz gráfica para el usuario que permite generar

los datos de entrada, enviar el comando y recibir los resultados para el comando trimodeler, el cual es parte del

paquete computacional Seismic Unix[19]. Puede ser utilizado como plugin de aplicación de JobDAG[1], que

es una aplicación que permite la ejecución diferida basada en grafos dirigidos acíclicos sobre plataformas de

cómputo paralelo de tipo cluster y grid. Eclipse-R provee al usuario de una interfaz para ejecutar y recibir los

datos del simulador de yacimientos Eclipse[3]. Se desarrolló una extensión de portal (portlet) que permite la

ejecución en grid mediante un portal web.

1.4. Presentación del Documento

En los siguientes capítulos se presentarán las bases para la comprensión de los desarrollos que involucran

este proyecto, así como también su utilización. En el capítulo 2 se presentarán las aplicaciones para las cuales se

han desarrollado interfaces de ejecución y se describirán las diferentes tecnologías que han motivado y hecho

posible el presente trabajo. En los capítulos 3 y 4 se presenta la implementación y descripción de Trimodeler y

Eclipse-R respectivamente. Finalmente se exponen algunas conclusiones y recomendaciones sobre el trabajo.

 Capítulo 2

Marco Teórico

2.1. Aplicaciones para la Exploración de Petróleo y Gas

2.1.1. Seismic Unix

El paquete Seismic Unix (SU) del Centro para Fenómenos Ondulatorios (CWP) de la Escuela de Minas de

Colorado es un conjunto de rutinas de cómputo científico que proveen al usuario de un ambiente para realizar

diversas tareas de índole geofísico, entre ellas tareas de modelado de propagación de ondas y de procesamiento

sísmico[19]. Típicamente, se construyen shell scripts que invocan los diversos comandos que provee SU y los

combina mediante la redirección de sus entradas y salidas. De esta manera es posible realizar tareas relaciona-

das a la simulación y modelado de procesos de exploración

Trimodel

El comando de SU llamado trimodel realiza una interpolación de superficies dadas unas coordenadas espe-

cíficas que describen las capas que conforman el suelo a explorar, por medio del método de Triangulación de

Delaunay Ajustada[13].

Los parámetros del comando son los siguientes:

xmin: Valor mínimo de la coordenada horizontal (eje x).

xmax: Valor máximo de la coordenada horizontal (eje x).

zmin: Valor mínimo de la coordenada vertical (eje z).

zmax: Valor máximo de la coordenada vertical (eje z).

4
2.1. APLICACIONES PARA LA EXPLORACIÓN DE PETRÓLEO Y GAS 5

xedge: Valores de las coordenas en el eje x de una interfaz.

zedge: Valores de las coordenas en el eje z de una interfaz.

sfill: x, z, x0, z0, s00, dsdx, dsdz para rellenar un área.

maxangle: Máximo ángulo (grados) entre segmentos de interfaces adyacentes.

Comúnmente, los usuarios de este comando crean un script que engloba la especificación de los parámetros

de entrada y la especificación de la superficie a evaluar.

A continuación se presenta un shell script a modo de ejemplo utilizando el comando.

#! /bin/sh
# Script de ejemplo de uso del comando trimodel de Seismic Unix

trimodel xmin=-1 zmin=0 xmax=5.0 zmax=2.0 \

1 xedge=-1,0,1,2,3,4,5 \
zedge=0,0,0,0,0,0,0 \
sedge=0,0,0,0,0,0,0 \
2 xedge=-1,0,0.5,1.0,1.5,2,2.5,3,4,5 \
zedge=1,1,1.1,1.3,1.1,1,1.1,1,1,1 \
sedge=0,0,0,0,0,0,0,0,0,0 \
3 xedge=-1,0,1,2,3,4,5 \
zedge=2,2,2,2,2,2,2 \
sedge=0,0,0,0,0,0,0 \
sfill=1,0.5,0,0,0.25,0,0 \
sfill=1,1.8,0,0,0.1,0,0 \
> modelo

spslot < modelo title="Modelo de ejemplo" \

label1="Profundiadad (km)" label2="Distancia (km)" \
> modelo.ps

exit 0

Los parámetros xmin, zmin, xmax y zmax son los valores máximos y mínimos que tendrán los ejes de

coordenadas tanto en la dirección horizontal (x) como en la vertical (z). Esto determinará el tamaño del modelo.

A continuación siguen las interfaces, las cuales representan los límites de las diferentes capas del subsuelo y
2.1. APLICACIONES PARA LA EXPLORACIÓN DE PETRÓLEO Y GAS 6

cada una es especificada con los parámetros xedge, zedge y sedge, siendo los dos primeros una lista con los

valores de la coordenada en los ejes respectivos. En este modelo, se especifican tres interfaces, la primera de

ellas definida por los puntos (-1,0), (0,0), (1,0), (2,0), (3,0), (4,0) y (5,0). El parámetro sedge es una lista con los

valores de sloth1 .

El hecho de tener que especificar de esta manera las capas de la superficie que se va a analizar implica

un proceso engorroso si se desean cambiar dichas especificaciones para repetir la simulación con parámetros

diferentes.

En este script se genera el archivo binario modelo, el cual posteriormente es graficado a un archivo PostScript

con el comando spsplot.

La figura 2.1 muestra la imagen resultante.

2.1.2. Eclipse

La simulación de yacimientos se encarga de predecir el comportamiento de los fluidos (típicamente petróleo,

agua y gas) a través de un medio poroso como lo es un yacimiento de hidrocarburos. Mediante aplicaciones

especializadas llamadas simuladores, los ingenieros de yacimientos son capaces de estimar cuan productivo

puede ser un yacimiento[18].

Uno de los simuladores más conocidos es ECLIPSE. Este simulador fue desarrollado por ECL (Exploration

Consultants Limited) aunque actualmente es manejado, comercializado y desarrollado por SIS (Geoquest), una

división de Schlumberger. Por más de 25 años este simulador ha sido el punto de referencia para otros sistemas

de simulación[3].

ECLIPSE100 es uno de los diferentes simuladores que contiene ECLIPSE. Puede ser ejecutado de forma se-

cuencial utilizando el comando @eclipse o de forma paralela con el comando @mpieclipse. Ambos comandos

trabajan sobre un archivo de entrada comunmente denominado DATASET, el cual es un archivo de texto que

contiene los datos sobre los yacimientos y otras variables de configuración. Típicamente, no es trivial su crea-

ción de manera que se utilizan otras herramientas contenidas en el paquete ECLIPSE, tales como Eclipse Office,

para su generación.

1 sloth = square slowness = 1/v2 = Inverso del cuadrado de la velocidad de propagación

2.1. APLICACIONES PARA LA EXPLORACIÓN DE PETRÓLEO Y GAS 7

Figura 2.1: Imagen resultante del proceso de ejecución de trimodel

2.2. PLATAFORMAS DE EJECUCIÓN DE APLICACIONES DE ALTO DESEMPEÑO 8

2.2. Plataformas de Ejecución de Aplicaciones de Alto Desempeño

2.2.1. Cluster

Un cluster de computadores es un grupo de múltiples computadores unidos mediante una red de alta ve-

locidad, de tal forma que el conjunto es visto como un único computador, más potente que los comunes de

escritorio. La construcción de los ordenadores del cluster es más fácil y económica debido a su flexibilidad:

pueden tener todos la misma configuración de equipamiento y sistema operativo (cluster homogéneo), dife-

rente rendimiento pero con arquitecturas y sistemas operativos similares (cluster semi-homogéneo), o tener

diferentes equipos y sistema operativo (cluster heterogéneo).

En la Universidad Simón Bolívar se encuentra instalado el Cluster Miranda, el cual cuenta con 88 nodos. Es

propiedad de PDVSA y la USB aportó su experticia y apoyo técnico para su instalación y mantenimiento.

2.2.2. Grid

La computación Grid es una tecnología que permite utilizar de forma coordinada todo tipo de recursos

(entre ellos cómputo, almacenamiento y aplicaciones específicas) que no están sujetos a un control centralizado.

En este sentido es una nueva forma de computación distribuida, en la cual los recursos pueden ser heterogéneos

(diferentes arquitecturas, supercomputadores, clusters...) y se encuentran conectados mediante redes de área

extensa (por ejemplo Internet)[6].

El término grid se refiere a una infraestructura que permite la integración y el uso colectivo de ordena-

dores de alto rendimiento, redes y bases de datos que son propiedad y están administrados por diferentes

instituciones. Puesto que la colaboración entre instituciones envuelve un intercambio de datos, o de tiempo

de computación, el propósito del grid es facilitar la integración de recursos computacionales. Universidades,

laboratorios de investigación o empresas, se asocian para formar un grid, para lo cual utilizan sistemas que

implementan este concepto[5]. En nuestro caso particular de investigación hemos empleado gLite[4].

El sistema donde se tiene instalado el conjunto de aplicaciones de usuario, típicamente comandos UNIX,

que permiten el envío y recepción de trabajos al grid se denomina User Interface.

2.3. SECURE SHELL 9

2.3. Secure Shell

SSH (Secure SHell) es un protocolo que sirve para acceder de manera segura a máquinas remotas a través

de una red insegura. Permite manejar por completo la computadora mediante un intérprete de comandos.

Además de la conexión a otras máquinas, SSH permite copiar datos de forma segura (tanto archivos como

simular sesiones FTP cifradas), gestionar claves RSA para no escribir claves al conectar a las máquinas y pasar

los datos de cualquier otra aplicación por un canal seguro mediante SSH[21].

2.4. JobDAG

JobDAG es una aplicación gráfica interactiva para el área de Exploración y Producción de Gas y Petróleo.

Esta aplicación permite la ejecución de filtros sobre objetos seleccionados de un área de trabajo, así como la

ejecución diferida basada en DAGs (Grafos Dirigidos Acíclicos) de tales filtros, sobre plataformas de cómputo

paralelo tipo Cluster y tipo Grid [1]. JobDAG puede ser fácilmente extendido mediante plugins.

2.5. Portales Grid

Para facilitar la adopción y utilización de Grids por parte de las distintas comunidades de usuarios, es nece-

sario presentar el Grid de una forma visual, atractiva e intuitiva. Una solución común a esta necesidad consiste

en la elaboración de portales web, a los que se puede acceder disponiendo simplemente de un navegador web,

para operar con el Grid. Este enfoque evita que los usuarios tengan que instalar y administrar aplicaciones en

sus estaciones de trabajo, y permite que puedan acceder al Grid desde cualquier lugar.

2.5.1. Portlets

Los portlets son componentes modulares de interfaz de usuario gestionadas y visualizadas en un portal web.

Los portlets producen fragmentos de HTML que se agregan en una página de un portal. La especificación Java

Portlet (JSR168) [11] permite la interoperabilidad de los portlets entre portales web diferentes. Esta especifica-

ción define un conjunto de API para interacción entre el contenedor portlet y el portlet que direcciona áreas de

personalización, presentación y seguridad[16].

2.5. PORTALES GRID 10

2.5.2. GridSphere

Gridsphere es una herramienta código abierto para crear portales web basados en portlets. Permite a los

desarrolladores generar y empaquetar rápidamente aplicaciones basadas en web portlets que pueden ser ejecu-

tadas y administradas con el contenedor de portlets Gridsphere[8].

 Capítulo 3

Trimodeler

Trimodeler es una aplicación desarrollada para facilitar tanto el trabajo con el comando trimodel de Seismic

Unix como el envío del trabajo de generación del modelo directamente a un cluster, mediante una conexión

SSH o haciendo uso de un grid.

Para su elaboración se siguió una metodología de Desarrollo en Cascada con Retroalimentación[12], debido

a que desde un principio los requerimientos fueron especificados rígidamente. Adicionalmente, se considera a

Trimodeler como un sistema de pequeña envergadura donde otra metodología con mayores controles no sería

justificada.

3.1. Análisis de Requerimientos

El comando de SU trimodel es empleado para el anális y modelado de capas del subsuelo. Los límites que

definen las capas del subsuelo se definen con segmentos de rectas definidos por puntos en un eje de coordena-

das. Se desea desarrollar una aplicación que facilite la introducción de los puntos en un eje de coordenadas así

como del resto de parámetros utilizados por el comando. Se desea generar los modelos localmente y en plata-

formas de cómputo de alto rendimiento. A continuación se presenta una lista con los requerimientos definidos

para el desarrollo de Trimodeler.

Generación del modelo de las capas del subsuelo y demás parámetros utilizados por el comando trimodel.

Integración como plugin con la aplicación JobDAG.

Ejecución del comando trimodel en una plataforma de Cluster Heterogéneo.

11
3.2. SELECCIÓN DE PLATAFORMAS DE DESARROLLO 12

Ejecución del comando trimodel accediendo al recurso de cómputo mediante un grid.

Recuperación de los resultados generados.

3.2. Selección de Plataformas de Desarrollo

Para desarrollar la aplicación se decidió utilizar una herramienta que facilitara el diseño de la interfaz grá-

fica, con el soporte de un lenguaje de programación poderoso. En ambientes gráficos Linux, los desarrollos de

interfaces gráficas suelen inclinarse por una de dos opciones: el empleo de las librerías GTK+[9] o las librerías

Qt[17]. GTK+ es utilizado típicamente para los entornos gráficos GNOME[7] y XFCE[23] mientras que Qt es la

librería utilizada por KDE. GTK+ está desarrollado en C, mientras que Qt ha sido creado en C++, sin embargo

ambas librerías pueden ser utilizadas indistintamente no sólo por programas escritos en C o C++, sino tam-

bién en Java, Ruby, Perl y Python entre otros. Finalmente, se optó por la opción Qt (Apéndice A) combinado

con el que es su lenguaje de programación por defecto, C++, principalmente por una mayor familiaridad y

experiencia previa con la herramienta y por el precedente del desarrollo de JobDAG, realizado en Qt.

3.3. Diseño

Para cumplir con la meta de facilitar el trabajo al usuario de Seismic Unix, específicamente de trimodel,

era necesario proveer una herramienta que permitiera especificar gráficamente los puntos que componen las

coordenadas en (x,z) de los modelos. Ésto evita tener que especificar manualmente los puntos que describen

las capas de la superficie que se quiere analizar, proceso poco intuitivo y que dificulta la reutilización de los

modelos para experimentos posteriores. La librería Qwt contiene componentes de interfaz gráfica de usuario y

clases utilitarias que son útiles para programas técnicos[14]. Entre otros componentes, provee una librería para

realizar gráficas en 2 dimensiones.

El diagrama de clases para la aplicación se expone en la figura 3.1. La clase central de la aplicación tiene

como nombre Trimodeler y hereda de QMainWindow, clase incluida desde la librería Qt con las funcionalidades

básicas que suelen proveer las ventanas principales de las aplicaciones. La clase QwtPlot es el objeto central

de Trimodeler, el cual provee un eje de coordenadas donde son graficadas las interfaces del modelo. Cada
3.3. DISEÑO 13

Figura 3.1: Diagrama de clases para la aplicación Trimodel

interfaz es representada con un objeto QwtPlotCurve. Una vez graficada cada interfaz, el usuario puede mo-

dificarla arrastrando con el ratón los puntos que la definen. Esta funcionalidad está implementada en la clase

CanvasPicker. El grupo de clases que heredan de QDialog son, como su nombre sugiere, cuadros de diálogo o

ventanas que muestra la aplicación para solicitarle más información al usuario cuando éste quiere hacer uso de

alguna funcionalidad específica de Trimodeler. También implementan ciertas funcionalidades específicas:

ExecLocal, ExecCluster y ExecGrid implementan la ejecución en ambiente local, cluster por SSH o me-

diante el grid respectivamente.La ejecución en un ambiente local no requiere una instalación de SU puesto

que Trimodeler provee los comandos necesarios. La ejecución en cluster requiere la correcta generación de

claves públicas y privadas, de manera que el usuario no deba introducir su password. La ejecución en

Grid funciona cuando se ejecuta desde un User Interface del grid al que queremos enviar el trabajo.

ResultadosCluster y ResultadosGrid implementan la recuperación de los resultados obtenidos previa-

mente. Así, el usuario obtiene los productos de la ejecución de forma sencilla, tal como fue su producción.
3.4. IMPLANTACIÓN 14

SfillsDialog permite al usuario cambiar los valores de la propiedad de los modelos denominada sfills.

Ésta propiedad en un conjunto de valores matemáticos utilizados para representar las densidades de las

capas del subsuelo.

NuevoPunto permite agregar un nuevo punto a una interfaz.

MaxAngleDialog permite cambiar el valor maxangle que es un parámetro utilizado en el modelo matemá-

tico empleado para realizar la simulacioń.

3.4. Implantación

El proceso de codificación fue iterativo; periódicamente hubo reuniones con potenciales usuarios de la he-

rramienta quienes aportaron sus experiencias con SU así como diversas sugerencias que fueron consideradas

y en buena medida dieron forma al estado actual del proyecto. También cabe destacar la importancia de la

retroalimentación experimentada para la detección de fallas y errores en la aplicación.

3.4.1. Ejecución en cluster mediante SSH

Para realizar la ejecución vía SSH se tiene como requerimiento que el usuario posea una cuenta en el cluster

y tenga generadas las claves SSH (apéndice B). Enviar a ejecutar mediante este mecanismo generará un direc-

torio en la cuenta del usuario en el cluster llamado .trimodeler_<Nombre del Modelo> siendo <Numbre del

Modelo> un identificador especificado por el usuario al momento de enviar la ejecución. En el directorio creado

se procederá a copiar los archivos de datos y scripts de ejecución, los cuales procederán a enviar el trabajo a la

cola de ejecución utilizando para ello el comando qsub. Para recuperar los resultados se emplea un mecanismo

similar utilizando las claves SSH y realizando una copia remota desde el directorio .trimodeler_<Nombre del

Modelo> de los resultados obtenidos en caso que ya hayan sido producidos.

3.4.2. Ejecución en Grid

La ejecución en Grid se basa en la ejecución del comando de gLite glite-wms-job-submit, el cual recibe

como parámetros de entrada el nombre de la organización virtual gridadmins y la ruta a un archivo JDL que

es generado por la aplicación. A continuación se describe el archivo que se genera:

3.4. IMPLANTACIÓN 15

Executable = "exec_trim.sh";
Arguments = "NombreDelModelo.txt";
StdOutput = "NombreDelModelo.out";
StdError = "NombreDelModelo.err"
OutputSandbox = {"NombreDelModelo","NombreDelModelo.ps","NombreDelModelo.err",
"NombreDelModelo.out"};
InputSandbox = {"/home/rodolfo/.trimodeler/NombreDelModelo/NombreDelModelo.txt",
"/home/rodolfo/.trimodeler/NombreDelModelo/exec_trim.sh"};

Executable es el archivo que se va a ejecutar y Arguments establece el argumento. En este caso el ejecutable

es un script el cual genera dinámicamente la aplicación y se encarga de poner el trabajo en la cola de ejecución

del cluster. Recibe como argumento el archivo de texto generado por Trimodeler que contiene las especifica-

ciones de las interfaces del subsuelo. StdOutput y StdError son los nombres de archivos en los que se copiará

las salidas estándar y de error del comando a ejecutar. OutputSandbox son los archivos generados al ejecutar

en el grid que se desea recuperar como resultados mientras que InputSandbox son los archivos locales que se

desean subir al grid por ser requerimientos para la ejecución como lo son en este caso el archivo de interfaces

generado por Trimodel y el script de ejecución.

Todo trabajo enviado a un grid recibe un identificador único denominado jobId. Al enviarse el comando a

ejecutar se recupera el jobId y se almacena en un archivo de texto que hace la función de registro de ejecuciones

en grid. El usuario cuando se dispone a recuperar o consultar el trabajo enviado al grid no necesita entonces

recordar el identificador ya que la aplicación muestra los identificadores con la fecha y hora de ejecución. Para

verificar el estado se utiliza el comando glite-wms-job-status. Para recuperar los archivos producidos en

una ejecución finalizada exitosamente se emplea el comando glite-wms-job-output. En ambos casos se le

proporciona como parámetro de entrada el jobId correspondiente.

3.4.3. Implantación del Plugin para JobDAG

La integración de Trimodeler con JobDAG permite agregarle a esta aplicación una funcionalidad extra. La

manera típica de trabajar con JobDAG es realizando un grafo cuyos nodos son archivos. A cada archivo se le

puede aplicar una función que producirá como salida a su vez otro archivo. Este esquema es particularmente

útil en Seismic Unix, ya que cada comando suele recibir por su entrada estándar un archivo como entrada y
3.5. PRUEBAS 16

produce otro archivo de salida que a su vez típicamente se le quiere aplicar otro comando para seguir proce-

sándolo.

Los plugins de archivos de entrada en JobDAG son archivos ejecutables que reciben como primer parámetro

de entrada una ruta a un directorio en el cual se debe producir un archivo con nombre temporales.archivo

el cual contiene en cada línea el nombre de cada archivo generado por la aplicación que está actuando como

plugin de entrada.

3.5. Pruebas

Se realizaron varias pruebas, algunas de ellas descritas a continuación. Trimodeler genera por el usuario

archivos de texto con las especificaciones de las capas del subsuelo y demás opciones del comando. Para

simplificar la descripción de los diversos casos, se trabajará siempre con el modelo generado en el archivo

ejemplo4.txt, mostrado a continuación:

3.5. PRUEBAS 17

################################################################################
# Archivo de parametros generado por Trimodeler
# mar enero 15 2008 02:03:41 pm
################################################################################

xmin=0
xmax=10000
zmin=0
zmax=5000
maxangle=5

xedge=0,10000
zedge=0,0
sedge=0,0

xedge=0,10000
zedge=1500,1500
sedge=0,0

xedge=0,1500,3100,4000,5000,6500,10000
zedge=1800,1800,1830,2000,2700,3500,5000
sedge=0,0,0,0,0,0,0

xedge=1500,5000,6800,10000
zedge=1800,1890,2700,3500
sedge=0,0,0,0

xedge=5000,6250,7500,10000
zedge=1890,1920,2700,3000
sedge=0,0,0,0

xedge=0,4000
zedge=2000,2000
sedge=0,0

xedge=0,5000
zedge=2700,2700
sedge=0,0

xedge=0,10000
zedge=5000,5000
sedge=0,0
3.5. PRUEBAS 18

Figura 3.2: Especificación de las capas del subsuelo que se quiere analizar

Para generar ejemplo4.txt, el usuario de Trimodeler utilizó el ratón de su computadora para graficar las

interfaces. La figura 3.2 muestra una captura de pantalla de la aplicación al generar al archivo ejemplo4.txt.

La visualización del producto generado en archivo PostScript se puede apreciar en la figura 3.3.

3.5.1. Ejecución Local

Para ejecutar localmente, se seleccionó desde el menú principal de la aplicación Ejecutar la opción Local. En

el cuadro de diálogo emergente se introdujo el nombre del archivo a producir y su ubicación. Para visualizar el

resultado, se habilitó la opción Generar archivo PostScript y se rellenaron los campos de título, etiquetas de los

ejes y tamaño de la imágen (figura 3.4). Se generó el archivo binario ejemplo4 con la representación del modelo

y el archivo PostScript mostrado en la figura 3.3.

3.5.2. Ejecución Cluster

Para enviar a ejecutar la aplicación al cluster a través de SSH es necesario como requisito previo tener las

claves SSH generadas previamente, proceso descrito en el apéndice B. El cuadro de diálogo mostrado en la
3.5. PRUEBAS 19

Figura 3.3: Imagen resultante del procesamiento y generación de archivo PostScript

Figura 3.4: Cuadro de diálogo Ejecución Local de Trimodel.

3.5. PRUEBAS 20

Figura 3.5: Cuadro de diálogo Ejecución en Cluster de Trimodel.

figura 3.5 se accede seleccionando Ejecutar desde el menú principal y luego Cluster y fue rellenado con los

datos correspondientes a la dirección IP o hostname a donde se quiere enviar el trabajo y el nombre de usuario

con el que se pretende ejecutar. Se debe especificar en el campo Nombre del modelo un nombre que identifique al

trabajo enviado, el cual deberá ser especificado cuando se deseen recuperar los resultados.

Para recuperar los resultados en cluster accedemos al cuadro de diálogo que se muestra al seleccionar Resul-

tados desde el menú principal la opción Desde el cluster... (figura resultcluster). Una vez realizada la transferencia

de los archivos, Trimodeler confirma que la operación se realizó exitosamente (figura 3.7).

3.5.3. Ejecución Grid

Trimodeler puede enviar a ejecutar a través de un grid. Para hacer ésto basta con seleccionar en el menú

principal de la aplicación el menú Ejecutar la opción Grid. Trimodeler mostrará el cuadro de diálogo Ejecutar en
3.5. PRUEBAS 21

Figura 3.6: Cuadro de diálogo Recuperar Resultados de Cluster.

Figura 3.7: Ventana de confirmación de éxito recuperando los archivos desde el cluster.
3.5. PRUEBAS 22

Grid (figura 3.8). Allí basta con introducir el nombre del modelo a generar y seleccionar si se desea generar el

archivo PostScript. Al presionar el botón Enviar comienza el proceso de envío. Al mismo tiempo, los comanodos

ejecutados imprimen en el cuadro de texto sus salidas estándar y de error estándar. En caso que ocurra algún

problema, la aplicación lo identifica y muestra el mensaje al usuario. En la figura 3.8 se observa un ejecución

exitosa. Al finalizar el proceso, Trimodeler notifica al usuario que el proceso se llevó a cabo correctamente (figura

3.9).

Para recuperar los resultados de los trabajos enviados al grid, se debe acceder mediante el menú Recuperar

resultados a la opción Desde grid.... Hacer esta selección presenta el cuadro de diálogo mostrado en la figura

3.10. Se puede observar el cuadro con los identificadores de los trabajos enviados al grid por la aplicación. El

botón Verificar consulta el estado del trabajo en el grid. La figura 3.11 muestra la consulta del estado del trabajo

enviado anteriormente. Para recuperar los datos generados, el usuario selecciona de la lista el identificador

que desee, o bien puede escribir uno que no aparezca en la lista. En la línea de texto etiquetada Guardar en:

escribe el nombre del directorio donde quiere guardar los archivos producidos por la ejecución. La figura 3.12

muestra la ventana confirmando que los archivos producidos en la ejecución por grid se han recuperado y están

disponibles en la ubicación que el usuario especificó.

3.5.4. Plugin para JobDAG

El plugin de Trimodeler para JobDAG tiene como objetivo extender esta aplicacion y proveer un medio de

generación de archivos de entrada. JobDAG implementa sus propios ambientes de ejecución. Por ello el plugin

Trimodeler no presenta opciones de ejecución ni de recuperación de resultados. Al ejecutar JobDAG se muestra

la ventana de selección del ambiente de ejecución y solicita un nombre para el grafo (figura 3.13. Para agregar

un plugin, se selecciona un ambiente de ejecución y activamos el botón Cambiar Preferencias. Al hacer ésto,

la aplicación mostrará la ventana Opciones de Administración en donde iremos a la pestaña Plugins de Entrada,

donde se introduce en una línea de texto la ruta al ejecutable de Trimodeler. Una vez guardada la configuración,

en la página principal de JobDAG se podrá acceder a Trimodeler seleccionando Archivo desde el menú principal

la opción Obtener archivo desde plugin y a continuación trimodeler. Una instancia de Trimodel se deberá iniciar y

al guardar los archivos generados se mostrará por defecto una ruta a un directorio que es donde JobDAG busca
3.5. PRUEBAS 23

Figura 3.8: Cuadro de diálogo Ejecutar en Grid de Trimodeler.

Figura 3.9: Confirmación del correcto envío del trabajo al grid.

3.6. OBSERVACIONES 24

Figura 3.10: Cuadro de diálogo Resultados desde Grid de Trimodeler.

los archivos de entrada para aplicarle algún comando. En la figura 3.14 se observa que el archivo ejemplo4.txt

ha sido cargado a JobDAG procedente de Trimodel y listo para que se le aplique algún comando.

3.6. Observaciones

Trimodeler es una aplicación que facilita la generación de modelos triangulares del subsuelo con el comando

trimodeler de SU y provee mecanismos para la ejecución del comando localmente sin necesidad de tener que

realizar una instalación del paquete SU.

Con Trimodeler, el usuario no tiene necesidad de enfrentarse a una línea de comandos ni debe escribir scripts

que pueden parecer sencillos a los ojos de expertos en el área de computación pero más complicado a los ojos

de un ingeniero en geofísica o petróleo, quienes son los que realmente realizan este tipo de simulaciones. El

mecanismo de especificar las capas del subsuelo con el ratón u otro dispositivo apuntador de manera gráfica,

viendo lo que se está diseñando en pantalla, es mucho más intuitivo y sencillo que escribir en una línea de

comandos o en un script las coordenadas en unos puntos en un eje cartesiano.

Para modelos especialmente grandes cuyo procesamiento pueda tardar un tiempo considerable, Trimodeler

ofrece mecanismos para enviar ejecutar el procesamiento pesado en un cluster mediante el protocolo SSH o
3.6. OBSERVACIONES 25

Figura 3.11: Ventana con la información del estado de un trabajo enviado al grid por Trimodeler
3.6. OBSERVACIONES 26

Figura 3.12: Ventana con la confirmación que un trabajo ha sido recuperado del grid exitosamente

Figura 3.13: Ventana de inicio en JobDAG.

3.6. OBSERVACIONES 27

Figura 3.14: El archivo ejemplo4.txt cargado y listo para procesarse con JobDAG.
3.6. OBSERVACIONES 28

utilizando un Grid. Trimodeler puede integrarse fácilmente con JobDAG de manera que le provee un mecanismo

de generación de archivos de entrada y delega a éste la forma de ejecución.

Cada una de las diferentes opciones presentadas ofrecen ventajas particulares que pueden ser aprovecha-

das según sea el caso del usuario. La opción de ejecución por medio de SSH ofrece ventajas en casos donde

no se tenga disponible un User Interface a un Grid, mientras que el plugin a JobDAG potencialmente puede

ser utilizado para enviar el trabajo a diferentes opciones, según sean implementados los diferentes plugins de

ejecución.
 Capítulo 4

Eclipse-R

Eclipse-R es una aplicación que le provee al usuario un entorno amigable para la ejecución del simulador de

yacimientos ECLIPSE100 a través de un Grid. Se puede ejecutar la versión paralela del simulador denominado

mpieclipse o la versión secuencial eclipse. Se tiene como requerimiento que la aplicación se ejecute en un

User Interface del grid al que se quiere acceder.

Se empleó un metodología de desarrollo en cascada con retroalimentación[12], por los mismos argumentos

presentes en el caso de Trimodeler

Eclipse-R presenta al usuario una sencilla interfaz gráfica (ver figura 4.1) dividida en 4 secciones principa-

les.En la parte superior de la ventana selecciona si el tipo de ejecución será secuencial o paralela. Más abajo

se seleccionan las opciones de ejecución básicas que son comunes para ambas opciones de ejecución. A con-

tinuación aparece un grupo de opciones sólo disponibles para la ejecución paralela y finalmente en la parte

inferior de la ventana principal se observa en un cuadro de texto el comando como va siendo generado según

las opciones arriba seleccionadas y el botón para enviar a ejecutar el comando.

4.1. Análisis de Requerimientos

Eclipse es una aplicación muy utilizada en la industria petrolera. Generalmente, su ejecución requiere alto

poder de cómputo y la ejecución de una simulación de tamaño considerable en una computadora convencio-

nal puede requerir días para terminar. Por ello es necesario su ejecución en plataformas de cómputo de alto

rendimiento y además se requiere una aplicación que realice el envío mediante Grid de manera sencilla para el

usuario.

29
4.1. ANÁLISIS DE REQUERIMIENTOS 30

Figura 4.1: Ventana principal de Eclipse-R.

4.2. SELECCIÓN DE PLATAFORMAS DE DESARROLLO 31

Figura 4.2: Diagrama de Clases de Eclipse-R.

Especificar las posibles opciones de ejecución del simulador ECLIPSE100 en sus versiones secuencial y

paralela.

Proveer las opciones de envío del trabajo a través de Grid.

4.2. Selección de Plataformas de Desarrollo

Para el desarrollo de la aplicación se utilizó, tal como se hizo en Trimodeler, el lenguaje C++ y la librería Qt,

por los mismos motivos justificados en la sección 3.2.

4.3. Diseño

En el momento de modelar el universo de la aplicación se hizo evidente que para resolver el problema sólo

era necesario tres clases. La clase EclipseLauncher provee la interfaz gráfica de usuario y la construcción del

comando junto con todos sus parámetros de ejecución posibles. La clase SendGrid provee el cuadro de diálogo

y la implementación del envío del trabajo al grid y la clase ReceiveGrid que provee el cuadro de diálogo y la

implementación de la recepción de los resultados. La figura 4.2 representa el diagrama de clases de la aplicación.
4.4. IMPLANTACIÓN 32

4.4. Implantación

La aplicación se desarrolló iterativamente, contando con el apoyo del Ingeniero Argenis Álvarez, especia-

lista de PDVSA en simulación de yacimientos y experimentado usuario de la herramienta ECLIPSE100 quien

aportó diversas recomendaciones que fueron tomadas en cuenta para el desarrollo de Eclipse-R.

Para ejecutar la aplicación mediante un grid se genera un archivo JDL como el siguiente:
Executable = "/ecl/macros/@eclipse";
Arguments = "SALT";
StdOutput = "eclipse-r.out";
StdError = "eclipse-r.err"
OutputSandbox = {"SALT.ECLEND","SALT.DBG","SALT.INSPEC","SALT.MSG","SALT.PRT",
"eclipse.err","eclipse.out"};
InputSandbox = {"/home/rodolfo/models/SALT.DATA"};

Executable es el comando a ejecutarse, en este caso se trata de eclipse por lo que se trata de la ejecución

secuencial, Arguments es el nombre del archivo de datos si la extensión .DAT. En OutputSandbox se especifican

los nombres de los archivos que el comando eclipse produce. En InputSandbox se especifica la ruta al archivo

de datos de eclipse.

Se utiliza el mismo esquema de archivo de registro con los JobID utilizado en Trimodeler. Se emplean los

comandos glite-wms-job-submit para enviar, glite-wms-job-status para verificar el estado y glite-wms-job-output

para recuperar los resultados.

4.4.1. Implantación del Portlet

Como alternativa a la aplicación de escritorio fue desarrollada una versión portal web, la cual se apoyó

en la herramienta realizada por Aixbel Martínez en su proyecto de grado titulado Portales Grid para la Ejecu-

ción y Administración de los Servicios del Grid/PDVSA-AIT[15], el cual es un contenedor de portlets basado en

Gridsphere.

Para realizar esta versión, fue necesario reimplementar la lógica de la aplicación en el lenguaje de progra-

mación Java, puesto que se requería generar una clase en dicho lenguaje para satisfacer los requerimientos y

estándares de desarrollo de portlets. La presentación se hace utilizando el lenguaje de marcado Java Server Pa-

ges, común en el desarrollo de sistemas web. En la figura 4.3 se observa una captura de pantalla con la página
4.4. IMPLANTACIÓN 33

Figura 4.3: Captura de pantalla del portlet de Eclipse-R.

web cargada en un navegador.

Un portal web por naturaleza debe ser fácilmente extensible. En el caso particular de eclipse-r bastó

con desarrollar la interfaz gráfica del usuario empleando Java Server Pages y dos clases Java. Una llamada

ViewApplication la cual recoge los datos introducidos en la interfaz por el usuario y ServiceEclipseImpl en

donde se implementa la generación del archivo JDL con los datos obtenidos.
4.5. PRUEBAS 34

Figura 4.4: Ventana que muestra la confirmación de un trabajo enviado exitosamente al grid.

4.5. Pruebas

4.5.1. Aplicación de Escritorio

Eclipse-R debe ejecutarse desde un User Interface del grid donde queremos enviar el trabajo. Desde la venta-

na principal de la aplicación, el trabajo puede enviarse mediante el botón Enviar ubicado en la esquina inferior

derecha. El usuario podrá observar como ocurre el proceso en la ventana que Enviar Trabajo que aparecerá cuan-

do comience el envío al grid. La figura 4.4 muestra un envío a grid exitoso. Eclipse-R provee la funcionalidad

de recuperar los datos producidos y revisar el estado de los trabajos enviados al grid, de idéntica forma como

lo hace Trimodeler. Al hacer click sobre el botón Recuperar, el usuario podrá observar en su pantalla el cuadro

de diálogo Resultados desde Grid, en donde se muestra una lista con los identificadores de los trabajos enviados

a ejecutar al grid por parte de la aplicación. Puede verificar el estado de un trabajo con el botón Verificar (figura

4.5) y puede recuperar los resultados de un trabajo ya finalizado mediante el botón Recuperar (figura 4.6).

4.5.2. Portal Web

La versión desarrollada para el portal web se ejecuta de manera similar. El usuario selecciona las diferen-

tes opciones para la simulación a efectuar y simplemente envía el trabajo mediante el botón Crear archivo de
4.5. PRUEBAS 35

Figura 4.5: Ventana con la información del estado de un trabajo enviado anteriormente.

Figura 4.6: Ventana confirmando que se han recuperado los archivos generados en la ejecución en el grid.
4.6. OBSERVACIONES 36

Figura 4.7: Confirmación de envío del trabajo mediante el Portal Web.

ejecución. La aplicación procederá a pasar la información del trabajo al portal y confirmará el éxito o fracaso

de la operación (figura 4.7). El propio portal ofrece al usuario las funcionalidades de recuperación de datos

generados y de verificación de estado de los trabajos enviados.

4.6. Observaciones

Eclipse-R provee un entorno de ejecución en grid para el simulador de yacimientos ECLIPSE100. Se desa-

rrolló una versión de aplicación de escritorio y un portal web. Aunque no se realizaron mediciones, se puede

pensar que el usuario debe tardar más en enviar y recibir trabajos mediante el portal grid que al utilizar la

aplicación de escritorio, debido a que la versión escritorio realiza el envío del trabajo directamente. El portlet

típicamente será accedido desde cualquier sistema con una conexión internet o intranet, de manera que la co-

municación es indirecta y se tienen que transferir archivos por la red. Se considera que la mayor desventaja de

la aplicación de escritorio es el requerimiento de una instalación apropiada de un User Interface, mientras que

el portlet no tiene esta limitación.

 Capítulo 5

Conclusiones y Recomendaciones

El análisis de datos con ayuda de herramientas computacionales en diversas áreas del conocimiento, y más

específicamente en la industria petrolera, se ha venido incrementando en forma exponencial en las últimas

décadas, lo cual justifica los dos grandes basamentos del planteamiento de este proyecto: simplificación de la

interacción de los usuarios con los comandos y utilización de plataformas de cómputación de alto rendimiento.

La utilización de complejas plataformas como Clusters de computadoras y Grids de cómputo y datos, se ha

visto restringida por la ausencia de interfaces adecuadas, que faciliten su utilización por parte de usuarios no

especialistas en el área de computación.

Trimodeler facilita la generación de modelos triangulares del subsuelo, utilizados ampliamente en el área de

la Geofísica para la exploración y búsqueda de petróleo y gas. El usuario ahora es capaz de diseñar los perfiles

de capas del subsuelo en un ambiente gráfico utilizando sólo el ratón de su computador. Adicionalmente,

ofrece la capacidad de generar el modelo desde la misma aplicación, con la opción de ejecutarse localmente sin

necesidad de una instalación completa de Seismic Unix, en un Cluster o en un Grid de cómputo. Trimodeler,

además, puede integrarse fácilmente al entorno de ejecución JobDAG, de manera que seguirá ofreciendo la

facilidad de generación del modelo y adicionalmente se aprovechan las características de JobDAG para realizar

procesamiento posterior de manera sencilla.

Eclipse-R ofrece en una sencilla ventana todas las opciones de ejecución de los comandos eclipse y mpieclipse

del simulador de yacimientos ECLIPSE100. Al igual que Trimodeler, una vez que el usuario ha seleccionado sus

preferencias, el envío del trabajo a un Grid computacional se encuentra a sólo unos cuantos clicks de su ratón.

Así mismo, la recepción de los resultados es igual de trivial. Tan solo introduciendo el ID del trabajo enviado,

se pueden obtener los resultados. Como no siempre se encuentra disponible un User Interface, se desarrolló un

37
Capítulo. 5. Conclusiones y Recomendaciones 38

portlet alojado en un Portal Web que se puede acceder desde cualquier sistema sin necesidad de otro software

más alla que un navegador.

Estas aplicaciones contribuyen a reducir la carga cognitiva a los profesionales de cualquier campo sobre

temas que no necesariamente debería dominar, conduciendo a una mayor concentración de esfuerzos en cada

sector del negocio respectivo, contribuyendo directamente en su eficiencia.

Ambas aplicaciones pueden ser utilizadas por profesionales del área de exporación y producción de pe-

tróleo, facilitándoles en buena medida su trabajo. Sin embargo, se puede afirmar que podrían ser mejoradas

en posteriores desarrollos. Trimodeler y Eclipse-R manejan los identificadores de los trabajos al grid de manera

rudimentaria, mediante archivos de texto. Es deseable una implementación de una pequeña base de datos o

mediante archivos XML que manejen los trabajos enviados, de manera que se pueda mantener información

acerca de la fecha y hora en la que se enviaron, su estado de ejecución, modelo o trabajo específico al que están

relacionados y otros atributos que puedan ser de interés para los usuarios. De igual forma, no se necesita guar-

dar un registro con todos los trabajos enviados por la aplicación, sino que es deseable una funcionalidad que

permita eliminar la información de algunos trabajos que no se deseen almacenar.

En el caso particular de Trimodel, se puede extender en sus funcionalidades a otros comandos de SU que

requieran la introducción de datos en forma de ejes de coordenadas, como es el caso del comando unif2. En ese

caso serÃa necesario implementar una validación de los modelos, debido a las restricciones particulares que

pueda tener cada método utilizado para realizar los modelados sísmicos. Es posible y deseable implementar

una funcionalidad de verificación de estado de trabajos enviados al cluster mediante SSH similar a la desarro-

llada para la ejecución en Grid.

Eclipse-R sólo trabaja con dos comandos de todo el paquete ECLIPSE. Fácilmente, con la experiencia obteni-

da en este desarrollo, se puede extender la aplicación al resto de comandos del simulador y crear una aplicación

completa que facilite la interacción con sus usuarios y permita el envío de trabajos a un grid de cómputo. Para

proveer portabilidad a las aplicaciones que requieren su ejecución en un User Interface se propone su instalación

en máquinas virtuales configuradas correctamente para proveer la funcionalidad de ejecución en Grid.

 Bibliografía

[1] Ortega S. Jimmy, Naranjo M. Sergio G. Aplicaciones Interactivas para Plataformas Cluster Heterogéneas. Tesis

de Grado, Universidad Simón Bolívar, Caracas 2007.

[2] Jasmin Blanchette, Mark Summerfield C++ GUI programming with Qt4. Prentice Hall, 2006.

[3] ECLIPSE Reservoir Engineering Software. http://www.slb.com/content/services/software/reseng/index.asp.

[4] EGEE >gLite. www.cern.ch/glite/.

[5] Vladimir Silva. Grid Computing for Developers. Thomson Delmar Learning, 2006.

[6] I. Foster, C. Kesselman, J. Nick, S. Tuecke. The Physiology of the Grid: An Open Grid Services Architecture for

Distributed Systems Integration. Computer, 35(6), 2002.

[7] GNOME: The Free Software Desktop Project. www.gnome.org.

[8] Gridsphere Portal Framework. www.gridsphere.org.

[9] The Gtk Project. www.gtk.org.

[10] Navarro Toro, Sinivaldo Iván. Integración de Clusters de Almacenamiento a Grid basados en gLite. Tesis de

Grado, Universidad Simón Bolívar, Caracas 2007.

[11] JSRs: Java Specification Requests JSR 168: Portlet Specification.

[12] Rick Bitter, Taqi Mohiuddin, Matt Nawrocki LabVIEW: Advanced Programming Techniques. CRC Press,

ISBN 0849333253, 2006.

[13] Lara, Jose Antonio. Modelado Sísmico con Seismic Unix. Tesis de Grado, Universidad Simón Bolívar, Cara-

cas 2007.

39
Capítulo. 5. Conclusiones y Recomendaciones 40

[14] Qwt User’s Guide: Qwt - Qt Widgets for Technical Applications. http://qwt.sourceforge.net

[15] Martinez Toledo, Aixbel Zhuelky Portales Grid para la ejecución y administración de los servicios del

Grid/PDVSA-AIT. Tesis de Grado, Universidad Simón Bolívar, Caracas 2008.

[16] Portlet. http://en.wikipedia.org/wiki/Portlet

[17] Qt - Trolltech. http://trolltech.com/products/qt/

[18] Reservoir Simulator. http://en.wikipedia.org/wiki/Reservoir_simulator

[19] Seismic Un*x. http://www.cwp.mines.edu/cwpcodes

[20] The SU User’s Manual. Version 1.0, Colorado School of Mines, Center for Wave Phenomena, 1994

[21] RFC 4251 - The Secure Shell (SSH) Protocol Architecture. http://tools.ietf.org/html/rfc4251

[22] F.W. Dyson, A.S. Eddington, and C.R. Davidson. The Anatomy of the Grid: Enabling Scalable Virtual

Organizations. In International J. Supercomputer Applications, 15(3).

[23] Xfce - Desktop Environment. http://www.xfce.org

 Apéndice A

Qt

Qt es un framework, ampliamente utilizado para el desarrollo de interfaces gráficas de usuario para aplica-

ciones. Qt es multiplataforma y está desarrollado en el lenguaje de programación C++.

Qt es distribuida bajo una licencia GPL que permite incorporar desarrollos con Qt en aplicaciones de

código abierto.

Se encuentra disponible para una gran número de plataformas: Linux, MacOs X, Solaris, HP-UX, UNIX

con X11. Además, existe también una versión para sistemas embebidos.

Es orientado a objetos, lo que puede facilitar el desarrollo de sistemas. El lenguaje para el que se encuentra

disponible por defecto es C++ aunque han aparecido adaptaciones a otros lenguajes como Python o Perl.

Es una librería que se basa en los conceptos de widgets (objetos), señales y eventos.

QT proporciona además otras funcionalidades:

• Librerías básicas de entrada y salida, manejor de red, XML

• Interfaces ocn bases de datos Oracle, MySQL, PostgreSQL.

• Internacionalización, Unicode.

Qt soporta diferentes compiladores, incluyendo el compilador GCC para C++ y el entorno de desarrollo

Visual Studio para desarrollos en Microsoft Windows.

Disponiendo de una correcta instalación de Qt4, los pasos para compilar proyectos desarrollados en esta

plataforma son:

41
Capítulo. A. Qt 42

1. Ubicarse en la línea de comandos en el directorio que contiene el código fuente de la aplicación.

2. Ejecutar el comando qmake –project. De esta forma se genera un archivo de extensión .pro que especifica

las características del proyecto y los archivos y librerías involucradas.

3. Ejecutar el comando qmake. Al realizar ésto, se genera un archivo Makefile.

4. Ejecutar el comando make para compilar el código fuente de la aplicación.

 Apéndice B

Generación de claves SSH

SSH es un protocolo que permite, entre otras funcionalidades, la ejecución de un terminal de comandos

en una máquina remota. En ocasiones se desea que la conexión pueda ejecutarse sin necesidad que el usuario

deba introducir su contraseña en. Podemos lograr ésto aprovechando la funcionalidad de SSH para manejar la

autenticación de los usuarios, utilizando el comando ssh-keygen.

Si se ejecuta el comando ssh-keygen -t rsa se producirán dos claves, una privada cuyo nombre por defec-

to es id_rsa y otra pública bajo el nombre id_rsa.pub del tipo RSA con una longitud de 2048 bits. Al generar

las claves se solicitará que se introduzca un frase de paso (passphrase) que al dejarla en blanco no solicitará

escribirla cada vez que se produzca la conexión. Una vez generadas las claves públicas y privadas en la má-

quina que va a solicitar las conexiones SSH, es necesario copiar el contenido de la clave pública al archivo

~/.ssh/authorized_keys en el sistema que se quiere acceder sin introducir contraseña. Se puede hacer con los

siguientes pasos:

1. scp id_rsa.pub usuario@maquina:, copia el archivo con la clave pública al directorio personal del usua-

rio en el sistema al que queremos acceder. El comando solicitará que se introduzca la contraseña de

usuario en maquina.

2. ssh usuario@maquina "cat ~/id_rsa.pub >> ~/.ssh/authorized_keys", concatena el contenido de la

clave pública en el archivo authorized_keys. Igual que en el paso anterior, será solicitada la contraseña

de usuario.

Una vez ejecutados estos comandos, los comandos scp (copia de archivos remotos) y ssh no solicitarán

contraseña para conectarse.

43