SIMULACIÓN DE YACIMIENTOS DE PETRÓLEO Y SISTEMA DE CARACTERIZACIÓN Y MÉTODO
Antecedentes de la Invención Esta solicitud reivindica el beneficio e incorpora para referencia en su totalidad, la Solicitud de Patente Provisional de los E.U. No. 60/159,252, presentada el 13 de Octubre de 1999. La presente invención se refiexe a sistemas y métodos para la evaluación y diseño de yacimientos minerales y en particular a métodos y sistemas para proporcionar en un solo soporte lógico personalizado de computadora accesible de manera remota e interfaz para el movimiento eficiente de datos y salidas de procesamiento diferentes entre ellos y entre varias aplicaciones de software utilizadas para el análisis comparativo y la predicción respecto a las características a través del tiempo del retiro del fluido del yacimiento de petróleo (petróleo crudo, gas y agua) utilizando cualquiera o todos los datos sísmicos, de perfil de sondeo, de producción y otros datos geológicos, geofísicos y de ingeniería petrolera y análisis que puedan ser relevantes. En el sector de explotación y producción petrolera, se coloca una prioridad sobre el conocimiento y análisis exactos del beneficio respecto a las características y cambios a través del tiempo de los yacimientos de petróleo (por ejemplo, yacimientos de petróleo crudo y/o gas natural) ya que el petróleo, el gas y el agua se extraen a la superficie. Debido a que los yacimientos de petróleo se presentan bajo la tierra, con frecuencia bastante por debajo de la superficie de la Tierra (de una a varias millas) y debido a que los contenidos de un yacimiento de petróleo (por ejemplo, un campo de petróleo o gas) pueden dispersarse a través de una región espacial y geológicamente extensa y diversa de la región bajo tierra (el yacimiento) , la evaluación a través del tiempo de los yacimientos de petróleo es una tarea compleja y económicamente esencial. Los objetivos de evaluar los yacimientos son diversificar y comenzar con las etapas más iniciales de la actividad de explotación especulativa (en un punto en donde no necesariamente se conoce si una región geológica o estructura contiene petróleo accesible en cantidades comercialmente negociables) , a través del tiempo de vida de producción de un yacimiento identificado (cuando este puede ser importante, por ejemplo, para evaluar y/o variar los mejores sitios para colocar pozos para tapar el yacimiento o la proporción óptima a la cual puede retirarse petróleo de un yacimiento durante el bombeo en curso) . Debido a que las compañías en la industria petrolera invierten muy grandes cantidades de dinero en la exploración, desarrollo y explotación de yacimientos de petróleo conocidos o potenciales, es importante que la evaluación y valoración de las características del yacimiento se acompañen con el uso más eficiente y exacto de un amplio rango de datos respecto « al yacimiento. Para este fin, los geologistas, los geofísicos y los ingenieros petroleros han desarrollado numerosas metodologías para valorar los yacimientos de petróleo (en cuanto a tales parámetros co o reservas totales, ubicación del petróleo, caída de presión, invasión de agua, disolución de gas, etc.) . Estas metodologías han dependido de un amplio rango de aplicaciones de software, para lo cual se encuentran datos de entrada variables respecto al carácter geológico del yacimiento y cómo estos datos variables varían a través del tiempo de producción. Muchos de estos datos variables pueden valorarse más fácilmente mediante el análisis de los datos sísmicos -i.e., datos obtenidos mediante el análisis de las características de ondas sonoras que viajan a través y se reflejan desde las estructuras geológicas bajo tierra. Como es bien conocido, debido a que los sonidos viajan con diferentes velocidades a través de las diferentes substancias — e.g. , roca porosa rellena de líquido de diferentes densidades - los análisis sísmicos de ondas sonoras causadas que viajan a través del yacimiento de petróleo pueden utilizarse para caracterizar el yacimiento en términos de sus partes constituyentes heterogéneas; e.g., los diversos sólidos, líquidos, etc., regiones o componentes del yacimiento y sµs ubicaciones respectivas dentro del yacimiento pueden representarse a medida que cambian a través del tiempo. El término SeisRes puede utilizarse generalmente a través de la presente para referirse a datos y procesos para caracterizar yacimientos de petróleo (típicamente por medios sísmicos) , aunque debe entenderse que los datos físicos de entrada diferentes o en adición a los datos estrictamente sísmicos pueden y se utilizan en la evaluación, análisis y formación de las caracterizaciones de las regiones del subsuelo y los yacimientos de petróleo. La presente invención es particularmente útil, pero no se limita, a técnicas de caracterización que se enfocan en gran parte sobre los datos sísmicos; también puede manejarse y optimizarse la caracterización utilizando otros tipos de entradas de datos . La evaluación del yacimiento y su caracterización de manera genérica (incluyendo pero no limitándose a las que usan análisis de datos sísmicos, no sísmicos e híbridos) se referirán en la presente como SeisRes OF. Al sistema de soporte lógico personalizado y la interfaz los denominamos la estructura de operación, abreviada en lo sucesivo (OF) . Obviamente tales datos pueden ser de utilidad por ejemplo en confirmar y caracterizar la ubicación del mencionado petróleo líquido dentro del yacimiento, facilitando potencialmente así grandemente su cuantificación y extracción. Debido a que las operaciones de Exploración y Producción ("E&P") en la industria de energía son mundiales, rurales así como urbanas y altamente técnicas, empleando un diverso grupo de conjuntos de datos y aplicaciones de software científicos, comerciales y de ingeniería, las mejoras en la eficiencia de los procesos de evaluación de yacimientos son extremadamente complejas y difíciles. Aunque se han conocido diversas aplicaciones mandadas por computadora para el análisis de los yacimientos de petróleo, la evaluación, cuantificación y caracterización de un yacimiento dado casi siempre requerirá el análisis bajo más de una aplicación de computadora. Las principales aplicaciones de software (apps) tienen diferentes fuentes, proveedores, formatos, lenguajes y protocolos de datos. En muchos casos, la pluralidad de aplicaciones de computadora puede diseñarse para sistemas de operación diferentes, pueden aplicarse diferentes algoritmos de procesamiento o suposiciones analíticas y pueden utilizarse datos de entrada y/o suministrar datos de salida procesados en formatos (e.g. , formatos de entrada/salida de datos utilizando diferentes unidades de medición, puntos de referencia, estructuras de tiempo o terminología, conjuntos de variables) que no son consistentes con los formatos de datos respectivos utilizados por otra aplicación de análisis por computadora que se está aplicando al mismo yacimiento. Por lo tanto, aunque se han conocido aplicaciones de análisis por computadora útiles, el proceso de alimentar datos de entrada en bruto acerca de un yacimiento en las diferentes aplicaciones (que en algunos casos puede involucrar alimentar datos o resultados parcial o totalmente procesados desde una aplicación- hacia otra aplicación para su procesamiento adicional) y posteriormente del procesamiento eficiente mediante la pluralidad de aplicaciones obtener datos de salida preliminares o caracterizaciones del yacimiento de- petróleo (i.e., del estado, ubicación y cantidad volumétrica de las sustancias dentro del yacimiento, específicamente de los fluidos de petróleo) y finalmente de integrar datos de salida indicativos de tal caracterización a partir de la pluralidad de aplicaciones en tal forma de manera que los errores en las caracterizaciones e inconsistencias entre las caracterizaciones se minimicen y pueda formarse la más completa y exacta imagen de la OF, jamás realizada de manera simple . Nos referimos al proceso de proporcionar una caracterización integrada de datos de salida a partir de la pluralidad de aplicaciones analíticas como "optimización", de un proceso que involucra la reconciliación y/o minimización de errores entre las salidas de la aplicación (que pueden consistir de caracterizaciones parciales o aproximadamente completas del yacimiento) . En el pasado, cuando se obtenían datos relacionados a la caracterización inconsistente a partir de diferentes aplicaciones analíticas, las inconsistencias no siempre se resolvían fácilmente. Con frecuencia, la única resolución que podría lograrse era la selección de los expertos humanos entre las salidas inconsistentes o no armoniosas o mediante el ajuste de intensa labor de los tipos de datos incompatibles asociados con cada aplicación y alimentar tales datos ajustados hacia una etapa de procesamiento adicional . La técnica anterior no ha contenido un sistema y método satisfactorio para crear y administrar un proceso de circuito de producción automatizado para integrar muchas aplicaciones analíticas de computadora y su manejo, procesamiento y salida de datos en relación a un yacimiento en tal forma que: (a) el manejo de datos se automatice grandemente; (b) se integren o se "reinicien" diferentes aplicaciones analíticas en una interfaz de usuario común, lo cual puede hacerse disponible de manera remota; (c) las jerarquías del circuito de producción o procesamiento entre las aplicaciones pueda ajustarse fácilmente; (d) los datos de caracterización provenientes de las múltiples aplicaciones se optimicen sobre una base automatizada, para permitir el acceso a una OF de agregado exacto; y (e) la - -
historia no solo de los datos y de la OF, sino del circuito de producción analítico aplicada a lograr tal caracterización, se almacena y se hace disponible para su inmediata recuperación a fin de que los perfiles históricos, no solo de las características aproximadas del yacimiento, sino de los supuestos utilizados para alcanzar tal aproximación, se encuentran fácilmente disponibles y puedan actualizarse, re-ejecutarse y re-evaluarse utilizando diferentes supuestos o métricas analíticas. SUMARIO DE LA INVENCIÓN La invención descrita y reivindicada en la presente es un sistema y método para administrar y optimizar el manejo y análisis a través de un periodo de tiempo de los datos relativos a una caracterización del estado, ubicación y cantidad de fluidos dentro de un yacimiento de petróleo subterráneo. La invención descrita en la presente permite la integración completa de varias (potencialmente un gran número) de diferentes herramientas analíticas de computadora para realizar las tareas analíticas complementarias o de sobreposición en los datos del yacimiento o sub-conjuntos de datos (incluyendo en los datos que se originan como la salida intermedia de otra de la pluralidad de aplicaciones analíticas) . Adicionalmente, pueden minimizarse los conflictos (ya sea en los regímenes de formateado o manejo de datos, o en las conclusiones relacionadas a la caracterización) entre las diversas aplicaciones analíticas mediante un proceso iterativo para optimizar los datos y salidas asociadas con cada una de las diferentes aplicaciones . La presente invención proporciona una -estructura de operación en red ("OF") esas fuentes después integran las aplicaciones y conjuntos de datos científicos, comerciales y de diseño de múltiples proveedores. Nuestra OF administra las versiones y coordina la ejecución de múltiples aplicaciones. Maneja el tráfico de datos entre las aplicaciones; actualiza los modelos geoespacialmente alineados de la tierra y de los yacimientos y promueve los resultados a través de los ciclos de optimización. En una modalidad útil, el usuario del campo se interconecta con nuestra plataforma y otros miembros del grupo de haberes multidisciplinario a través de un "tablero de instrumentos" basado en la World Wide Web (Red Mundial) . Los Clientes tienen acceso a las versiones en tiempo real de múltiples proyectos que permiten el procesamiento las 24 horas los 7 días mediante grupos virtuales utilizando recursos distribuidos . La internet, y la elevada transmisión de datos en banda ancha, en general han hecho posible que inventemos una infraestructura de operación (a la que nos referimos como una estructura de soporte lógico personalizado) que permite, para la primera vez, conjuntos de datos de volumen muy grande a configurarse y transportarse eficientemente entre las diferentes aplicaciones de software geológicas, geofísicas y de diseño, la iteración a través de la cual se requiere determinar exactamente la ubicación a través del tiempo del petróleo y gas dentro del yacimiento con relación al agua circundante en la matriz de roca. Además, hemos inventado el software habilitado en la World Wide Web que rastrea el progreso del circuito de producción a través de la historia de computación alrededor del ciclo, incluyendo el mantenimiento de versiones de los diversos datos y resultados . "Mantenimiento de versiones" en este contexto se refiere a las técnicas de software para mantener el rastreo, dar cuenta y/o registrar los cambios a través del tiempo en el estado de un conjunto o conjuntos de parámetros, datos y salidas de análisis de datos de manera que los cambios en el conjunto o conjuntos (o sub-conjuntos de los mismos) puedan trazarse longitudinalmente a través del tiempo, reconstruirse y representarse para propósitos analíticos y de archivo a través del tiempo. Debe hacerse la provisión específica para rastrear los estados instantáneos de los conjuntos y subconjuntos de datos a intervalos predeterminados (o mediante el uso de marcadores de evento que correspondan a etapas de marcas de tierra significativas dentro de un circuito de producción) debido a que de otro modo los datos manipulados y procesados en la computadora, que pueden actualizarse continuamente, no pueden ser susceptibles de análisis de la historia de datos o seguimiento "patológico" o reconstrucción de errores, los cambios de datos cruciales o las fallas en el circuito de producción o en las líneas de tiempo, o las causas y resultados de inexactitudes en los_ supuestos o modelos aplicados a través de las aplicaciones relacionadas a la caracterización particular. BREVE DESCRIPCIÓN DE LAS FIGURAS La Figura 1 proporciona un resumen del proceso de las cuatro dimensiones (4D) , i.e. del ciclo de procesamiento dependiente del tiempo para la integración de las aplicaciones analíticas que manejan los datos relacionados al yacimiento, y para la optimización de los resultados de caracterización a partir de los mismos. La Figura 2 proporciona una estructura de arquitectura del sistema ilustrativo para ilustrar las capas de entrada/salida, el procesamiento, y la optimización de los datos relacionados a la OF. DESCRPCION DETALLADA DE LA INVECION De lo que se perdió la técnica anterior fue la
Estructura de Operación (OF) computacional, o soporte lógico personalizado, que permitiría la comunicación completa y rápida entre la variedad de aplicaciones de software que se requieren para la administración del yacimiento. No solo debe simularse el bloque de yacimiento a partir de una perspectiva de flujo de fluido, sino los cambios en el drenaje deben alimentarse en un programa de modelado tridimensional (3D) , sísmico elástico que pueda simular los cambios en amplitud sísmica de manera suficientemente exacta para compararse de manera real a las diferencias de datos de campo sísmico variables en tiempo real (tetradimensional o 4D) . Un optimizador debe entonces reconciliar las diferencias entre los cambios en el lapso de tiempo en los datos a partir de las fuentes separadas, sísmicas y de otra manera. Es decir, las diferencias en el lapso de tiempo entre los modelos y datos sísmicos observados y computados y de flujo de fluido, deben computarse y volverse a computar hasta que converjan en la mejor vista de los cambios reales que ocurren en el yacimiento de petróleo y gas a través del tiempo. La técnica de una modalidad altamente útil de nuestra invención se ilustra en la Figura 1 y consiste de las etapas marcadas como sigue en las cuales las marcas en las letras corresponden a la etapa con la letra respectiva en la Figura : A. El circuito de producción sísmico en 4D para la inversión no lineal de dos volúmenes sísmicos en 3D adquiridos en diferentes momentos durante la historia de producción de un campo, y su conversión tiempo-profundidad, normalización y diferenciación (como se entenderá más completamente a la luz de la exposición de las patentes de E.U. No. 5,798,982 y
,586,082, que se incorporan en la presente en su totalidad mediante la referencia) se utilizan para computar las diferencias sísmicas a través del tiempo; La preparación del perfil de sondeo y la conversión profundidad-tiempo utilizando una aplicación de software tal como SigmaView de Landmark Graphics
Corporation; La OF en 4D de los dos volúmenes sísmicos utilizando la aplicación de software geoestadística co-kriging tal como EarthGM de Western Geophysical
Corporation; Exportar al MultiMesher de IBM para construir el
Earth Model (Modelo de la Tierra) ; E. La simulación del flujo de fluido en Eclipse de
Schlumberger, VIP de Landmark Graphics, o cualquier otro simulador comparable; F. Una fase de modelado sísmico elástico en 3D para generar cubos sísmicos sintéticos en 4D; Exportación del sísmico modelado para una aplicación de software de modelado sísmico tal como
Omega de Western Geophysical para migración;
H. Diferenciación de los datos sísmicos observados versus él modelo en 4D y el análisis de la diferencia de las diferencias utilizando el software de diferencia sísmica observada en 4D (e.g. la de RAÍ) ; I. La optimización que identifica los cambios en las propiedades físicas de los yacimientos para comparar de manera más cercana el retiro de fluido, los cambios de presión y las diferencias sísmicas; J. El ciclo "Ir a" de regreso a E, anterior. La computación y caracterización nunca se completan durante la vida del yacimiento debido a que continuamente llegan nuevos datos hacia la estructura de operación a partir del monitoreo del campo de petróleo o gas por si mismo, y debido a que la extracción del yacimiento es un proceso dinámico que cambia continuamente las características del yacimiento, algunas veces en forma no completamente predecible. Así se proporciona la primera estructura de operación computacional del soporte lógico personalizado, extensible que permite versiones de datos y la interpretación del circuito de producción entre las diversas aplicaciones del proveedor de software comercialmente disponibles necesarias para completar el ciclo a partir de la interpretación geológica y geofísica para la implementación de diseño requerida para la producción moderna de petróleo y gas. ARQUITECTURA DEL SISTEMA EJEMPLIFICATIVO El diseño e implementación de la presente invención como se practica en una modalidad consiste del código de sistema C++OF, y de los programas de instrucción, reiniciadores e implementación de los programas de instrucción. Sin embargo, no -es necesario describir todos esos elementos en extremo detalle, ya que será suficiente una descripción de la arquitectura del sistema para el entendimiento de la construcción de los principales componentes y su interrelación con el sistema. La arquitectura de la Infraestructura de Operación OF que contiene los siguientes componentes o módulos principales, descritos a continuación en conjunto con la tarea del circuito de producción se señalan: 1. Controlar y rastrear toda la actividad dentro de la OF utilizando nuestro Active Notebook en base a la web. Puede revisarse rápida y fácilmente una evaluación retrospectiva (distribución posterior) de las ejecuciones previas debido a que en nuestra versión todo entra y sale en cada aplicación utilizando el Active Notebook. Todas las transacciones se sincronizan, incluyendo los ciclos de computadora utilizados a través del WAN, de modo que el registro es rápido y fácil. Proporcionar un modelo de datos de proveedor neutro con nuestro Data Repository PIÓ (Repositorio de Datos de PIÓ) de entrada/salida, de persistente objetivo para nuestra OF, que se coloca en 0la parte superior de los sistemas de administración de datos que existen en diversos usuarios. Implementamos nuestro PIÓ Data Repository utilizando TCP/IP rápido y confiable, objetos distribuidos, y lo protocolos de bajo nivel similares a XDR. CORBA (o sistemas de siguiente generación similares a SOAP) que todavía no soportan la persistencia natural, pero nosotros podemos manejar PIÓ con ellos. Proporcionar acceso a las aplicaciones del
proveedor, no solo las base de datos del proveedor, utilizando los Reiniciadores automatizados. Por ejemplo, permitimos al usuario seleccionar entre Eclipse (de Schlumberger) y VIP (de la División de Gráficos de Landmark de Halliburton) dentro de
nuestra superestructura OF, solo al hacer click en los diferentes programas en la OF de Microsoft Windows de su PC de escritorio. Tenemos cuidado de la conectividad, intercalación, tráfico de datos y mantenimiento de versiones. Utilizamos el producto
"Swig" para crear las interfaces para los Reiniciadores de los programas de instrucción. 4. Proporcionar un Event Handling Mechanism (Mecanismo de Manejo de Evento) para hacer la ejecución de aplicaciones de manera asincrona. Analizamos el circuito de producción entre varias aplicaciones de manera simultánea y las distribuimos en la red cliente/servidor, conjuntándolas como completas en lugar de tener que esperar a que finalice una antes de que otra inicie. 10 5. Proporcionar un conjunto rico de Container Foundation Classes (Clases de Fundamento del Contenedor) reutilizables y extensibles para diseñar los datos de diseño, geológicos y geofísicos a fin de que puedan agregarse fácil y
rápidamente nuevas aplicaciones y tipos de datos al sistema de administración de OF. 6. Proporcionamos M ltiMesh (Red Múltiple) un sistema de intercalación de IBM que es topológico de manera que siempre que existan los requerimientos de
cuadriculado de una Aplicación nosotros lo suministramos rápidamente. 7. Proporcionamos un Optimization Tool Kit (Equipo de Herramientas de Optimización) a fin de que los parámetros clave puedan modificarse para converger
en una solución de último error durante la ejecución de una aplicación. El optimizador puede visualizarse a través de la web y los establecimientos de cambios al parámetro para una aplicación se propagan a otros que utilizan aquellos mismos establecimientos. 8. Proporcionamos el OF Data Viewer (Visualizador de Datos de OF) un sistema de visualización desarrollado por nosotros mediante VTK, una compañía subsidiaria de GE. El usuario puede diseñar la visualización del progreso de sus simulaciones de computadora a través de la Web y manipular las imágenes en tiempo real a medida que se computan. Para ilustrar adicionalmente las formas en que la arquitectura del sistema puede implementarse, a continuación se proporciona una descripción más detallada de una modalidad de la arquitectura del sistema en la cual las capas, etapas y componentes del sistema se numeran de acuerdo con las marcas de número correspondientes en el diagrama de arquitectura del sistema proporcionado en la Figura 2. 1.0 CAPA DE INTERFAZ DE USUARIO Utilizamos tecnologías de la web de fuente abierta que consiste del Zope Web Application Server (Servidor de
Aplicación Zope de la Web) y el uso de normas a base de DHTML y XML para la interoperabilidad, integración y presentación de haberes y lógica comerciales en la web. Una Capa de Interfaz de Usuario de la web utiliza un modelo de Web completa de servicio en base a aplicaciones (llamadas productos) para los usuarios en oposición sc las páginas individuales de la web. Zope utiliza una base q^ datos de objeto con un editor de objeto de la web que hace su tarea. Las mejores prácticas en la ejecución de computaciones de ciencia y diseño es mantener un cuaderno de notas con un registro de los experimentos y sus pruebas y erroxes (la versión moderna de los cuadernos de notas de los investigadores) . En la realización de una tarea complicada tal como el análisis y caracterización de yacimientos, el "cuaderno de notas" necesariamente tendrá la estructura para esto - desglosándose en secciones que describan las múltiples tareas involucradas en el flujo de trabajo y sub-investigaciones hechas a lo largo del camino de completar la tarea total. Para OF, implementamos tecnología modera en la web para hacer un cuaderno de notas en base a la computadora. El cuaderno de notas capturará las tareas (y todos sus atributos) de OF a medida que se realicen por el usuario. Este es un cuaderno de notas activo debido a que el inicio y monitoreo de las tareas de OF se hacen utilizando esta tecnología de la web. Los trabajos anteriores pueden reactivarse en la OF y renovar las investigaciones utilizando el cuaderno de notas. La interfaz de usuario en el amplio conjunto de tareas de OF es el cuaderno de notas. Es una característica particularmente útil de esta invención que puede utilizarse para establecer la interfaz del usuario con la OF a través de cualquier red de comunicaciones de datos^ distribuidos . Tal red bastante útil, puede incluir una red privada, una red privada virtual o una red pública tal como la Internet o la world wide web. Utilizando la internet, los usuarios del campo pueden tener instantáneamente, a solicitud, un acceso interactivo persistente a la funcionalidad de caracterización del yacimiento de la invención. Puede utilizarse una variedad de protocolos en red conocidos en relación con la interfaz del usuario. Por ejemplo, las técnicas para establecer el acceso remoto seguro encriptado a los servidores principales (a través de la internet o internets) están bien establecidos y pueden utilizarse fácilmente para establecer la conexión de datos para la interfaz del usuario. Circuito de Producción en Base a la Red Al combinar las capacidades de comunicación de la información en banda ancha de la internet con la automatización de los procesos comerciales estratégicos y las capacidades de integración del Motor del Circuito de Producción de OF, pueden realizarse mejoras significativas monitoreando y controlando la migración del petróleo y el gas a partir de los yacimientos del subsuelo. Esto permite una aceleración real del mejoramiento de la productividad dentro de las actividades relacionadas a la información y supera la manera para formas totalmente nuevas de trabajo en la industria de producción de petróleo. Estos monitoreos de tiempo real incluyen, trabajo móvil y empresas de producción virtual . Estas últimas se formarán pox la duración de un proyecto específico y se construirán sobre la solidez única de la ubicación física mundial del usuario. 1.1 Cuaderno de Notas Activo El Cuaderno de Notas Activo es un conjunto integrado o páginas web generadas mediante un servidor de aplicación en la web, Zope que monitorea y registra las tareas de OF a medida que se realizan por el usuario. Puede reactivarse en la OF el trabajo anterior y las investigaciones pueden renovarse utilizando el Cuaderno de Notas. Así, la industria tiene la capacidad de las tareas computacionales del modelo anterior relacionadas a la administración del yacimiento utilizando el Cuaderno de Notas Activo. Todos los parámetros y datos que fueron hacia un conjunto de interpretaciones entre las aplicaciones controladas por la OF pueden recomputarse, aún si han pasado años en el entretiempo del Cuaderno de Notas del Cliente. El cliente soporta la computación instrumentada a través del sistema de búsqueda de la web. El Cuaderno de Notas Activo se basa en utilizar VTK como un conector de tclet. El sistema de búsqueda tiene una interfaz para objetos de repositorio de OF directamente dentro de los ambientes de programa de instrucción del sistema de búsqueda. Esto incluye, pero no se limita a tcl, Javascript o JPython. El ambiente de programas de instrucción en el sistema de búsqueda tiene acceso al modelo de objeto del documento del sistema de búsqueda (DOM) . Tal acceso es Netscape' s Live Wire. El cliente "ligero" funciona en el modo confiado cuando ejecuta la visualización así como cuando se interconecta al repositorio y objetos de evento, ya que la OF se utilizará inicialmente en una situación intrared. El XML se utiliza para transportar datos estructurados entre el sistema de búsqueda y el servidor de OF. El sistema de búsqueda hace uso de visualizadores incorporados analicen XML para visualizar o analizar XML directamente en su programa de instrucción. Los visualizadores incorporados puede ser en base a programas de instrucción (i.e., tclet), en base a Java o pre-construirse como conectores. El cuaderno de notas del cliente soporta una interfaz para crear documentos y status . Utilizamos para esto la interfaz de creación de documentos Zope. 1.1.2. Servidor del Cuaderno de Notas El servidor rastrea el progreso del circuito de producción de un usuario y construye dinámicamente un nuevo contenido de red incluyendo programas de instrucción laterales de cliente en base a la iniciativa del usuario, objetos OF y metadatos acerca del estado del circuito de producción del experimento de OF. en progreso. Los cambios0en el estado del cliente se rastrean con formas de sumisión (http POST) , cookies y comunicación de conector directo con el servidor (por ejemplo, la capacidad para conectar tclet para hacer http POST) . El último almacén de datos persistentes es el almacén de metadatos OF (en Zope y el repositorio de datos de OF) - sin embargo, las cookies se utilizan para presentar datos persistentes a este almacén. Utilizamos Apache como - el servidor http. Ejecutamos el Zope en base a python bajo Apache como una forma de editar dinámicamente objetos para la red. La idea es utilizar objetos Zope para representar las tareas y documentos del circuito de producción de OF. Estos objetos representan la sumisión de tarea, el monitoreo, los resultados, la sinopsis y los documentos establecidos asociados que contienen formas de sumisión para los archivos de parámetros, por ejemplo. La preparación de los documentos OF ejecutará tareas de trabajo OF en el conjunto de recursos computacionales para el trabajo de OF. El Zope tiene un sistema de objeto persistente de manera que estos documentos se archivan con el estado del trabajo de OF a través de sus tareas de trabajo. Zope utiliza un lenguaje de programas de instrucción lateral del servidor denominado DTML. La funcionalidad principal de los programas de instrucción laterales del servidor es construir el programa de instrucción lateral del cliente y el contenidas de la web que comprende 1. una interfaz para las tareas OF despachadas desde el Servidor OF hacia los huéspedes de cómputo utilizando RSH; y .. 2. la generación de los programas de instrucción laterales del cliente que pueden generar la red del cauce de visualización (VTK) o una interfaz de usuario en el cliente no tan ligero por ejemplo. La comunicación necesaria entre los componentes del cuaderno de notas y el servidor de OF puede resumirse como sigue : • Applets/conectores ver el DOM (Document Objet Model
(Modelo Objeto del Documento)) • Applets/conectores ver cada uno • Server Side Scripting (Programas de Instrucción Laterales del Servidor) ver el DOM • Applets/conectores información posterior para el servidor • Programas de Instrucción Laterales del Cliente y objetos de Evento y Repositorio de Acceso a Applet/ Conectores utilizando directamente los servidores de Evento y Repositorio. Estos se comunican con metadatos Zope utilizando http POST e indirectamente con los programas de instrucción laterales del servidor. El diseño de interfaz de un buen usuario debe mantener cuestiones como organizar la suma del circuito de producción para los diversos experimentos de OF, el diseño de menús y widgets (objetos de Windows) de entrada de usuario, conectoxes, applets, etc. Los individuos enfocan las tareas complejas en diferentes formas y el sistema OF general necesita acomodar las variantes iniciativas del usuario en orden de trabajo; etc. así como desplegar mejores prácticas de circuitos de producción utilizadas en circunstancias similares en otra parte en la compañía del cliente. Para dirigir estos problemas implementamos dos características: 1. Se introduce un movimiento de "visualizadores": conectores, applets, etc., que tienen un cuidadoso pero simple diseño de interfaz que cubre la mayoría de las funciones que un usuario haría con el visualizador. El visualizador puede ser un visualizador sísmico con su interfaz intuitiva para visualizar datos sísmicos.
Las widgets de parámetro y menús con el visualizador tienen un diseño que considera los factores liumanos involucrados en los datos sísmicos de visualización del usuario. El visualizador también funciona como un elemento de control. Utilizamos conectores tclet como la base para los visualizadores . 2. Construimos un sistema de administración y diseminación -de documentos de red en el servidor del cuaderno de notas. Los gráficos Explorer- (como en Windows) como interfaces y/o flujo de datos se utilizan para dar al usuario una vista de alto nivel de los contenidos del cuaderno de notas con perforación así como etapas para ejecutarse en el circuito de producción. El servidor de aplicación en la red, Zope, se utiliza por si sistema de administración de documentos. 2.2. Equipo de Herramienta de Optimización El Equipo de Herramienta de Optimización se diseña para ser un conjunto de herramientas que pueden desplegarse en cualquier momento y cualquier lugar dentro de la OF para proporcionar servicios de estimación de parámetros. Se implementa como un componente acoplado libremente debido a que la necesidad de estimación de parámetros varía de app a app. El principio que subyace en esta selección de diseño es que permite la selección de opciones, incluyendo opciones híbridas que combinan algoritmos de diferentes categorías, para producir el procedimiento más apropiado. El objetivo técnico es implementar rápidamente sub-ciclos de optimización para facilitar el proceso de optimización- completo para la simulación del yacimiento sísmico. El optimizador consiste de tres componentes: programas solucionadores de optimización, reiniciadores de simulación en avance y convertidores de datos de simulación. El programa solucionador de simulación en avance y los convertidores de datos de simulación se desarrollan de manera separada para el caracterizador propio del yacimiento, el simulador del yacimiento, el caracterizador petrofísico propio y el simulador de diferencia finita en 3D. El Laboratorio de Optimización se implementa de acuerdo al circuito de producción ilustrado más adelante. Los reiniciadores se desarrollan para dirigir la ejecución uniforme de cada sub-problema individual. Los sub-problemas se ilustran con diferente color en el diagrama. Es claro que cada sub-problema involucra uno o más procesos de simulación en avance que generan los datos predichos a partir de los parámetros del modelo de optimización. Cada sub-problema también involucra resolver un problema de optimización. El componente de optimización consiste de varios algoritmos de optimización en la forma de programas ejecutables. Cada uno de estos reiniciadores de optimización ofrecen la siguiente funcionalidad: 0 1) Capaz de obtener una actualización del parámetro modelo, 2) Capaz de realizar la actualización interactiva así como actualizar automáticamente los parámetros modelo, y 3) Capaz de enviar y recibir solicitudes hacia y desde otros reiniciadores de aplicaciones incluyendo otros reiniciadores de optimización. Hemos construido tres algoritmos de optimización en el Laboratorio de Optimización de OF. Estos son un programa solucionador lineal generalizado (GLS) , un programa solucionador no lineal generalizado (el Programa Solucionador LevenBerg-Marquardt modificado LMDIF) y el programa solucionador del Algoritmo Genético restringido (GENOCOP III) . El GENOCOP III por sí mismo se considera con frecuencia una solución híbrida huerística para algunos problemas de optimización. Los reiniciadores GLS utilizan un formato I/O de datos definidos en conjunto con la graduación automática de las columnas de una matriz Jacobiana incluida con un reiniciador de mecanismo de control.
Reiniciador de Simulación del Flujo de Fluido Hemos creado un reiniciador TCL/TK que acciona el simulador de yacimiento Eclipse y VIP. Somos capaces de integrar libremente los reiniciadores Eclipse y VIP con el optimizador p ra realizar la producción de comparaciones históxicas . Reiniciadores que Modelan Propiedades Petrofísicas
Hemos escrito un conjunto de herramientas que implementan ecuaciones tanto teóricas como empíricas publicadas en la literatura para comparar impedancias computadas utilizando varios algoritmos Biot-Gassman con impedancias observadas. Identificamos 11 parámetros clave para producir la complejidad de la impedancia acústica invertida. Mediante la integración con el programa solucionador GL, somos capaces de optimizar estas constantes para modelar los cambios de impedancia de los resultados de la simulación del yacimiento. Visualización del Optimizador mientas se Computa Los eventos se envían durante los ciclos de optimización de manera que la visualización de las convergencias de los gradientes y las normas computadas como los parámetros se cambian en la simulación del yacimiento. 2.3 Visualizador de Datos OF El Visualizador de Datos en 3D de OF (SDV) se ha diseñado para 1) desplegar una variedad de tipos de datos de geociencia registrados én coordenadas del mundo real en una escena común sobre la Red, 2) utilizar métodos que convierten el estado de la técnica, 3) ejecutar todas las estaciones de trabajo populares, y 4) ser fácilmente extendible mediante otros desarrolladores. El prototipo despliega datos almacenados sísmicos (archivo, volumen de impedancia acústica migrada, etc.), superficies y perfiles de sondeo. Se integra en el Repositorio de Datos OF. El yacimiento se caracteriza por múltiples exámenes sísmicos secuenciales; volúmenes de atributos sísmicos; muchos perfiles de sondeo de diferentes tipos y vendimias; volúmenes de datos geoestadísticamente derivados en cuadrículas regulares y estratigráficas; volúmenes de saturación de fluido; mapas de flujo de fluido de tetradimensionales; interfaces de fluido, horizonte y superficies de falla y posiblemente otros tipos de datos. Siendo capaces de visualizar todos estos datos -espacialmente registrados con respecto uno a otro en el sistema local de coordenadas mundiales reales y convertirlos en una variedad de modos de manera que las interrelaciones puedan percibirse - es una gran ayuda y puede ser una necesidad para entender los yacimientos espacialmente complejos a través del tiempo. La OF utiliza el equipo de herramientas de visualización (vtk) . El Vtk es un artículo libre; su código fuente se encuentra disponible para cualquiera a través de la copia en la internet. Se proporciona una interfaz para gráficas en 3D que es fácil de utilizar en relación a OpenGL, u otras interfaces de bajo nivel. Se encuentra escrito en C++ y proporciona una API de C++ bien documentada. También proporciona la API para Java y los lenguajes de programas de instrucción populares Tcl/Tk y Python. Se ha desarrollado SDW hasta el punto de visualizar datos sísmicos almacenados (archivos, volúmenes migrados, volúmenes de atributo, etc.), perfiles de sondeo y un formato de archivo ASCII de gráficos por computadora conocidos como el formato BYU. Los datos sísmicos pueden convertirse de SEGY y los registros pueden convertirse a partir de uno de los formatos SigmaView. El código vtk y de todos los SDV es transportable a
Windows. Se ha hecho el desarrollo tanto en las estaciones de trabajo de SGI como en Sun sin problemas diferentes a algunas peculiaridades variables de formación de archivos y ambiente. Mucha gente utiliza vtk en NT o Linux en las PCs . Debido a que el código del más alto nivel se escribe en Tcl/Tk, puede invocarse a partir de un sistema de búsqueda en la web. El SDV se diseña como una estructura central y cauces específicos de datos. Un cauce es un concepto inherente en vtk. Todos los datos se procesan mediante un cauce que consiste de la conexión serial de un lector u objeto fuente para importar los datos en su forma nativa, varios filtros para convertirlos en forma gráfica, un trazador para generar las gráficas iniciales, un actor para asociar las transformaciones en 3D, colores, luces y otras propiedades gráficas con los datos y un interpretador para trazar todo. La estructura puede operar con cualquiera o más de los cauces, y los cauces pueden desarrollarse sin el acceso al código fuente de la estructura. La Principal Ventana de Visualizacidn El centro de atención en el SDV es una sola ventana de visualización encerrada en la ventana del nivel más alto de Tcl/Tk. Todos los objetos en 3D se despliegan aquí en coordenadas del mundo real . La ventana principal tiene una barra de menú típica a través de la parte superior. Los botones de Archivo, Edición y Vista se colocaron en la barra de menú mediante la estructura SDV. El botón BYU se colocó en la barra de menú mediante el cauce BYU. Ya que el GUI se escribe en el programa de instrucción tcl es fácil para los cauces agregarle objetos sin modificar el código de estructura. El Árbol de Objeto de Datos El segundo elemento principal de la estructura GUI es un árbol de objeto de datos gráficos. Esta ventana muestra los objetos que se cargan en el SDV. El SDV organiza los objetos de datos en una jerarquía de árbol. En el nivel más elevado se encuentra el único caso del SDV. El segundo en la jerarquía es un proyecto. Bajo el proyecto, los objetos de datos se agrupan por el tipo de datos . Se determina la estructura de árbol por debajo del nivel de tipo de datos mediante el cauce específico de datos. La jerarquía del perfil de sondeo y las vistas sísmicas son diferentes. La estructura derecha de esta ventana se encuentra disponible para desplegar información o las widgets de GUI asociadas con un solo componente seleccionado del árbol . Actualmente, la estructura solo imprime el nombre del objeto. Una variedad de datos con respecto a los diversos componentes puede asociarse con esta selección. VTK La estructura consiste de la ventana de visualización, de un árbol de objeto de datos gráficos y de las widgets de GUI comunes a todos los tipos de datos. Esta no se modifica por ninguno de los desarrolladores específicos de datos. De hecho, solo los archivos de encabezado C++, los archivos compartidos y el principal programa de instrucción tcl se necesitan para desarrollar nuevas característica. Se agrega un nuevo cause al agregar una o unas cuantas líneas al archivo . sdv_recurso, e informar al sistema operativo dónde encontrar el programa de instrucción tcl y los archivos que contienen el código del nuevo cause. Vtk se distribuye en forma de código fuente de manera que puede construirse en la mayoría de las computadoras comunes : en la mayoría de los Unix incluyendo Sun, SGI, HP y AIX, Linux y Windows NT. UtiJ-iza una implementación de hardware de OpenGL, si se encuentra disponible en la computadora principal (Unix o NT) o implementaciones de software de OpenGL, o un lenguaje de gráficos específicos de Windows. Tiene algunas instalaciones para múltiples causes gráficos tales como los que se encuentran en ambientes CAVE. Vtk se mantiene por Kitware, Inc. y se distribuye desde un servidos ftp en el Rensselaer Polytechnic Institute. Requiere un compilador C++ para "hacer" una versión ejecutable. Se proporcionan muchos ejemplos para permitir al usuario ver como los objetos en 3D pueden visualizarse e ilustrar cómo pueden utilizar las diversas clases. Vtk tiene APIs para Python y Java. Elegimos no utilizar Java ya que la versión de Java utiliza Java3D para su soporte de gráficos subyacente. Java3D casi no se ejecuta como OpenGL en la actualidad. Puede ser una opción en el futuro. Python es un lenguaje de programa de instrucción mucho mejor estructurado de lo que es Tcl/Tk pero es bastante menos ampliamente utilizado. Probablemente hemos evitado muchos errores al utilizar Tcl/Tk. La decisión de utilizar Tcl/Tk necesita revisarse periódicamente. Un cambio de Tcl/Tk a Python sería directo. Un cambio a Java probablemente produciría un registro completo de la porción Tcl de la estructura SDV: menos de diez páginas del código actual . 3.0 LA CAPA DE SERVICIOS DE DATOS El paquete de almacenamiento persistente de la OF (pió) es una pieza importante del software de OF debido a los datos geológicos, geofísicos y otros que deben ser persistentes en el .ciclo de OF . Esta persistencia requiere que los objetos de datos puedan restaurarse a su forma original en cualquier momento. La idea general pox detrás de nuestro diseño de persistencia para el repositorio de datos es serializar los objetos de OF utilizando XDR y después almacenar los objetos serializados en nuestro repositorio. Nuestro servidor administrador puede accesarse por clientes remotos a través de los controles del Cuaderno de Notas Activo basado en la web. Esta característica permite que un circuito de producción distribuido pase nombres de objetos o referencias entre las aplicaciones de software reiniciadas. 3.1 Almacén de Datos Persistentes El repositorio del objeto de datos OF funciona como una base de datos de objeto que almacena y recupera los objetos C++ . El almacén para el repositorio de datos de OF es el sistema de archivo unix. Un directorio unix es un repositorio físico. Un directorio de repositorio tiene que tener dos archivos de índice: uno llamado el archivo de índice de objeto y el otro llamado el índice de repositorio. En la implementación real del repositorio de objeto, el repositorio de objeto pió maneja otros dos administradores: el administrador de índice - de objeto y el administrador de índice de sub-repositorio . El administrador de índice de objeto es responsable de agregar, retirar, renombrar y recuperar el descriptor de objeto y asegurar que el archivo de índice sea consistente y persistente. El administrador de índice del repositorio es responsable de agregar, retirar y recuperar un objeto del índice del repositorio y asegurar que el archivo de índice del repositorio sea consistente y persistente. Para garantizar la consistencia y persistencia del repositorio de objetos, es necesario que el servidor centralizado mantenga el archivo de índice de objetos y el archivo de índice del repositorio. Otras cuestiones tales como la seguridad y el monitoreo de transacciones se manejan por el Cuaderno de Notas Activo. El servidor del cliente del repositorio de datos se implementa en la parte superior de la capa conectora del sistema. El protocolo TCP/IP se utiliza para la comunicación que es punto a punto la conexión garantizada para cada cliente. El servidor del cliente del repositorio de datos tiene dos clases de interfaces de alto nivel pioCliente y pioServidor. La clase de pioCliente es la clase de interfaz para todas las aplicaciones y la clase pioServidor es la clase de interfaz para pioRepositorioAdministrador, que implementa todas las funcionalidades del servidor pió. La comunicación entre el cliente y el servidor se implementa en la parte superior de la capa conectora del sistema. El protocolo de comunicación es TCP/IP. Los datos transferidos son la corriente de bits ya sea de tamaño fijo o tamaño variable. En el lado del cliente, crea un conector, une el conector a la dirección del servidor, entonces las llamadas se conectan para hacer una conexión punto a punto para el servidor. En el lado del servidor, crea un conector, une el conector a la dirección IP de la computadora principal, después escucha la conexión del cliente. A medida que un cliente solicita ingresarse, acepta las llamadas para crear un conector temporal para ese cliente particular. Los datos se recibirán a través del conector regresado desde la llamada de aceptación. Un cliente solicita un servicio al enviar un mensaje. Un mensaje de solicitud consiste de tres partes: la primera parte es el código de solicitud, la segunda parte es la información del cliente que incluye el nombre de usuario, nombre de la máquina, id del proceso, marca de tiempo, e id única del cliente, y la tercera parte son los parámetros relacionados a la solicitud. Una secuencia ejemplificativa de comunicación en el lado del cliente es: Enviar un mensaje de solicitud; o Recibir el reconocimiento si el servicio solicitado se servirá por el servidor; Enviar datos si es necesario (tal como agregar el objeto al repositorio) ; y Recibir el reconocimiento si se cumple la solicitud El mensaje de reconocimiento será un entero que dice al cliente si el servicio solicitado sucedió o falló, y si falló, qué causó la falla. Una secuencia ejemplificativa del lado del servidor es : Recibe una solicitud; Reconoce al cliente si el servicio solicitado está disponible; Recibe datos de un cliente si es necesario, tal como agregar método; Envía los datos al cliente tal como conseguir método; Envía el reconocimiento al cliente si se cumple el servicio solicitado.
-
El píoServidor utiliza el pioObjRepositorioAdministrador para hacer todo el trabajo solicitado por un cliente. El pioObjRepositorioAdministrador utiliza dos administradores de índice para manejar los directorios y archivos bajo un directorio Unix. El pioRepositorioIndiceAdministrador maneja los directorios, y el pioObj IndiceAdministrador maneja los archivos de objeto. El Repositorio de Datos OF tiene cuatro componentes de alto nivel: el Administrador de Repositorio, el Administrador Descriptor de Objeto, el Manejador de I/O de Persistencia y el Bobinador de XDR. El repositorio almacena los objetos con la asistencia del Administrador Descriptor de Objeto, que mantiene una tabla de objetos indexados con sus descripciones asociadas. El Manejador de i/O de persistencia es responsable de la construcción y modelado de objetos. Utiliza el Bobinador XDR para serializar objetos para los archivos en el formato XDR, que se almacena entonces en el repositorio. Obsérvese que el repositorio es un conjunto de archivos almacenados en NFS . Este concepto es análogo al repositorio de un código fuente que hace versiones del sistema tal como CVS o RCS . La diferencia es que almacenamos la máquina independiente de los archivos binarios (formato XDR) que representan las versiones en serie de los objetos. pioReposi orioAdministrador Un repositorio en proyecto es simplemente un directorio Unix. El Administrador de Repositorio agrega y retira objetos dentro/fuera del repositorio. Utiliza el Administrador Descriptor de Objeto para catalogar los objetos en el repositorio. Cada directorio de proyecto tiene un o archivo, el cual contiene una colección de objetos descriptores (pioObjDescriptor) . Estos descriptores de objeto tienen información acerca de todos los objetos almacenados en el repositorio. La clase de Administrador Descriptor de Objeto (pioObjDescriptorAdministrador) agrega, recupera y suprime cualquier descriptor de objeto del repositorio. En esta implementación, cada objeto es un solo archivo en formato ASCII o XDR. La función estática para crear un objeto de un tipo definido tiene que registrarse en una tabla de registro (String2PtrFuncMap) antes de que el objeto se almacene o recupere a partir del repositorio. Una sesión típica que utiliza el repositorio para agregar un objeto se demuestra en el siguiente extracto de código: pioObjDescriptorAdministrador Existe un descriptor de objeto (pioObjDescriptor) asociado con cada uno de los objetos almacenados en el repositorio. El Administrador Descriptor de Objeto El (pioObjDescriptorAdministrador) contiene un mapa único: typedef map<string, objDescriptor>string20bjDescriptorMap Que se refiere al nombre del objeto para su descriptor. Este administrador realiza esencialmente operaciones para agregar, retirar y registrar cambios en el repositorio. El Descriptor de Objeto contiene información ® relevante asociada con los objetos a almacenarse tal como el formato del archivo (ASCII o XDR) , el nombre, tipo, nombre del proyecto, número de id, propietario, tiempo de registro, descripción del objeto y secuencia de versión xdr. Manipulador de I/O de Persistencia Este componente puede estar entre lo más importante en este diseño. El Manipulador de I/O de Persistencia es responsable del registro, construcción, inicio y modelado apropiado de los objetos almacenados. El Manipulador es un marcador de campo para los tipos que se desean almacenar en el repositorio. El Manipulador utiliza XDR para seriar y escribir los objetos en el repositorio. Leer los objetos seriados a partir del repositorio es más complicado, debido a que el Administrador del Repositorio ro conoce el tipo de los objetos que se van a leer. El Administrador del Repositorio solo tiene una secuencia que contiene el nombre del objeto. Por lo tanto, utiliza el mapa de función de secuencia a indicador para localizar el método apropiado para construir el objeto y regresarlo como un indicador pioObjBase. Este indicador se distribuye entonces (limitado) mediante el usuario utilizando el método ObjCast que es esencialmente una verificación de modelado dinámico además de un registro de objeto en el repositorio. No es posible recuperar tipos de objeto desconocidos del repositorio y si el usuario trata de recuperar un tipo no registrado entonces se regresa un indicador invalido (nada) . Si el objeto no se encuentra registrado del todo se produce una excepción. Bobinador XDR La clase xdrBobinador reinicia las funciones de serialización XDR para los tipos incorporados fundamentales en C++. El XDR se creo por Sun Microsystems, Ine y se encuentra libremente disponible. Se encuentra normalmente incorporado en los sistemas libe de Unix para llamadas remotas de procedimiento. XDR proporciona una forma convencional para convertir entre tipos de datos incorporados y una representación de secuencia de bits externa. Estas rutinas de XDR se utilizan para ayudar a implementar un tipo de rutina de codificación/decodificación para cada tipo definido por el usuario. El manejo de XDR contiene un campo de operación que indica cual de las operaciones (ENCODE, DECODE o FREE) (CODIFICACIÓN, DECODIFICACION o LIBRE) va a realizarse. Reiniciadores El OF es un sistema computacional que involucra muchas aplicaciones de software provenientes de proveedores así como códigos de legados propios de Western Geophysical. El circuito de producción de OF puede involucrar muchos diferentes miembros del grupo de haberes que funcionan en muchas diferentes aplicaciones que pueden distribuirse en diferentes máquinas en diferentes países que se encuentran conectados a través de la red. Traficar y realizar versiones entre muchas aplicaciones en un circuito de producción de manera eficiente en formas uniformes y sincronizadas es lo que este reiniciador de componentes hace. Un reiniciador de OF es como una caja negra que contiene una aplicación dentro. Existen causes conectados a ambos lados de la caja, un lado es la entrada y el otro es la salida. Una caja puede conectarse a otra caja al conectar las salidas de una a la entrada de la otra, mientras los tipos de datos dentro y fuera de los causes sean los mismos. Cada cauce de la caja es un puerto que se identifica por el nombre. Existe solo un tipo de datos que se permite fluir a través del cauce y que se define por cada aplicación. Cada. caja reiniciadora tiene la siguiente funcionalidad. Primero puede ejecutar las aplicaciones tan pronto como las entradas requeridas por la aplicación se encuentran satisfechas. Segundo, envía eventos acerca del status de la ejecución hacia el servidor de evento. Tercero, verifica los tipos de datos para comparar los entrantes a través del cauce con aquellos necesarios para la aplicación específica. Si el tipo de datos entrantes desde el otro cauce son diferentes del tipo de datos requeridos, entonces el reiniciador invoca el programa de formateo apropiado para convertir los datos al tipo apropiado, si existe un programa de formateo en el registro para el tipo de conversión o o requerida. Cada reiniciador se implementa en C++ y después se compila y prueba por los sistemas unix funcionando en sistemas operativos Sun, SGI y Linux. Registro del Reiniciador Para reiniciar una nueva aplicación del proveedor, la aplicación debe registrarse. Este registro crea una especificación de aplicación que se encuentra en la forma de un objeto appSpec . Este objeto spec de aplicación se almacena en el repositorio de datos a fin de que en lo futuro, el reiniciador pueda obtener la información acerca de esta aplicación. Si la aplicación lee y escribe archivos, entonces la información acerca de estos archivos debe registrarse también. Este proceso se llama crear una especificación de archivo en la forma de un objeto fileSpec. Este objeto fileSpec también se almacenará en el repositorio de datos para que el reiniciador lo utilice para obtener información acerca de la clase de datos necesarios en el cauce . Descripción del srReiniciador La clase de srReiniciador se diseña para ser una caja de reiniciador automático. Existen dos tipos de puertos 1/0, el puerto de archivo y el puerto de parámetro. El puerto de archivo indica un archivo que se unirá al puerto. El puerto de parámetro significa que el puerto mantiene un valor de parámetro tal cómo una secuencia, entero, flotador, etc . La clase de srReiniciador proporciona mecanismos para crear una caja, agrega puertos de entrada y salida, establecer valores para el puerto, conectar los puertos de un reiniciador a otro, y ejecutar la aplicación. También proporciona el mecanismo de consulta para permitir al usuario preguntar a la caja para obtener información acerca de que está en proceso en el interior de la caja. 3.2 Eventos El software de OF (Estructura de Operación) es un sistema distribuido integrado que conecta de manera enteriza (o incluye) muchas aplicaciones y códigos del proveedor. Un trabajo típico de OF incluye muchos programas del proveedor que funcionan en cualquier tiempo particular. En aplicaciones de computadora tradicional, tal como el procesamiento en lote secuencial, el usuario de cada uno es responsable de monitorear el status de su trabajo. No existe normalmente comunicación entre los programas de aplicación individual. En nuestra OF, hemos construido un manejador de eventos para monitorear el progreso y status de cada uno de los procesos . Un evento de OF es una pieza de información generada desde la aplicación del cliente. Esta información se delega a las partes interesadas quienes están en espera de tal información. Por ejemplo, si uno quiere visualizar los resultados intermedios cuando funciona una simulación, entonces el simulador de OF puede enviar un evento hacia el visualízador. También el objeto de los datos puede suministrarse a otra aplicación. El Manejador de Evento mantiene en los libros toda la información vital para el usuario final y sincroniza las múltiples ejecuciones. La sincronización se logra a través del Servicio del Manejador de Evento al utilizar un sistema de mensaje centralizado que permite a todos los procesos de trabajo comunicarse entre si y reportar sus status y excepciones. El Manejador de Evento se implementa como un servidor centralizado que utiliza conectores para comunicarse con el cliente. El servidor administrador de eventos puede registrar los clientes como ya sea productores de eventos o consumidores de eventos . Nuestra implementación del servidor del cliente administrador de eventos utiliza un modelo de "interrogación secuencial" . Es decir, el cliente tiene que interrogar de manera secuencial al servidor para encontrar los datos en los cuales esta interesado. Los eventos producidos se almacenen en el servidor para que las partes interesadas extraigan los datos de la memoria. Este es el así llamado "modelo de interrogación secuencial". Además, los eventos pueden inducirse de regreso a los clientes quienes se encuentran escuchando, esto es el así llamado "modelo de promoción" . Excepciones del Evento (EE) Existen cinco (5) diferentes partes del componente EE. El cliente EE en las aplicaciones envía y recibe eventos. El servidor EE sirve a todos los clientes EE y administra los eventos . El administradora de eventos proporciona APIs al servidor de evento. El administrador productor proporciona APIs para el administrador de eventos para manejarse por los productores, y el administrador del consumidor proporciona APIs para el administrador de eventos para manejarse por los consumidores. Cliente del Evento El cliente del evento se designa para que las aplicaciones se comuniquen con el servidor de evento a través de la conexión TCP/IP. Este cliente proporciona todo las APIs necesarias para una aplicación para enviar y recibir eventos y hacer consultas. Un primer cliente tiene que registrarse por si mismo como un productor o consumidor. Para producir eventos, el cliente debe registrarse como productor, después de agregar los eventos al servidor se le otorgan. Para consumir eventos, el cliente debe registrarse como consumidor, después el cliente puede interrogar secuencialmente al servidor acerca de los eventos en que esta interesado. También el cliente puede decir al servidor de evento en que eventos esta interesado o a los productores que eventos espera. Entonces el servidor puede promover los eventos de regreso a los consumidores registrados. Servidor de Evento El Servidor de Evento es un proveedor de servicio que sirve a los clientes de evento. Ee responsable de registrar a los clientes, maneja eventos, responde las consultas del cliente, promueve eventos de regreso a clientes registrados, etc. El servidor depende del administrador de eventos para hacer todo el trabajo. El administrador de eventos después administra adicionalmente otros dos administradores, administradores productores y administradores consumidores. El administrador productor es responsable de la adición de eventos provenientes del cliente hacia la cola de eventos, y la recuperación de eventos para los consumidores. El administrador productor administra una lista de productores, y cada productor administrará entonces una cola de eventos y una cola de consumidores . Los eventos producidos por esto productores se forman en la cola de eventos que tiene un protocolo de prioridad de primero en entrar primero en salir (FIFO) . Todos los consumidores que están interesados en este productor se forman en la cola de consumidores. El administrador consumidor administra una lista de consumidores registrados en el servidor. Cada consumidor registrado administra entonces su propia cola de tipo de evento y cola de productores. La cola de tipo de evento almacena todos los tipos de evento en que este consumidor esta interesado, y la cola de productores almacena los productores interesados que son del interés de este consumidor. Existen dos versiones de servidor EE implementado: de un solo enlace y de múltiples enlaces. Este último se diseña para manejar múltiples clientes al mismo tiempo . 3.3 Clases de Fundamento (FC) OF es un ambiente fundamentalmente construido en bloques "Lego" llamados clases de fundamento. La API de cada una de estas clases se expone a los idiomas de los programas de instrucción tales como Tcl, Python, Pearl y Java que permiten la rápida construcción de prototipos de nuevas aplicaciones y herramientas. Por ejemplo ei desarrollo del cuaderno de notas activo se traza lentamente a partir de estos paquetes a través del lenguaje del programa de instrucción Tcl. Seguimos el diseño STL para la mayoría de los paquetes, que se dividen en contenedores y algoritmos/filtros . Paquete de utilidad (Utilidad de OF) El paquete útil proporciona un conjunto de clases C++ categorizadas en contenedores de datos, tal como ordenamientos, clases de algoritmos relacionados a los contenedores, y clases de utilidad para secuencias, sistemas e información de recursos, archivo unix y manipulación de o directorio, y comparación del modelo. Los contenedores de datos son ordenamientos de hasta seis dimensiones. Las matrices y las clases ele ordenamiento base son ordenamientos numéricos genéricos y se dividen a partir de ordenamientos genéricos. Las clases de ordenamientos numéricos han sobrecargado los operadores numéricos tales como +, -, *, /, += etc. La misma regla de diseño se aplica a la matriz en ambas 2D y 3D. Nuestras secuencias de clase son un subconjunto de la clase de secuencia estándar proporcionada por el lenguaje C++ . Sin embargo tenemos algunos métodos de manipulación de secuencia especiales ampliamente utilizados por todos los paquetes de OF. La clase de comparación de modelo hace la comparación de modelo. La Systemlnfo (Información del Sistema) de la clase permite la aplicación para obtener la información del sistema tal como tiempo, nombre de usuario, información del recurso del sistema etc. La Filelnfo
(Información de Archivo) de la clase permite las aplicaciones para conseguir información acerca de un archivo unix. La clase unixDirUtil se utiliza para generar las estructuras de árbol del nombre de archivo de un directorio unix. Las clases de algoritmo se relacionan a cada contenedor de datos.
Una regla de diseño para las clases útiles de OF es que separamos los contenedores de los algoritmos. Este diseño hace a las clases de contenedores más reutilizables en el o o futuro . Paquete SRFC (Clases de Fundamento SeisRes) El paquete SRFC contiene las clases de fundamento que implementan un conjunto de contenedores de datos para conjuntos de datos geológicos y geofísicos eepecíficoe. Típicamente los tipos de datos utilizados en todos los software geológicos y geofísicos son datos volumétricos (3D sísmicos, 3D de velocidad, etc.) datos de pozo incluyendo datos de cultivo del pozo, perforación de pozo (geometría de la trayectoria del pozo) perfiles de sondeo, picos de pozo, zonas, perfs, tablas de conversión tiempo-profundidad, tablas de velocidad, núcleos. Otros tipos de datos son el horizonte, falla, modelo de depósito y varias tablas utilizadas en el software de simulación de fluido. Ya que estos datos utilizan muchos diferentes paquetes con muy diferentes formatos, se desea un formato interno para cada uno de lo tipos de datos descritos en el sistema OF. Actualmente el paquete srfc proporciona contenedores para todos estos tipos de datos. Estos contenedores solo se utilizan para mantener los datos con ayuda del acceso (consigue métodos) y manipulación (establece métodos) para comunicarse con el objeto. No existen algoritmos implementados para estos contenedores. Los algoritmos se implementan en el filtro del paquete. Este diseño hará a estos contenedores extensibles y reutilizables en el futuro. o 3.4 Sistema MultiMesh (MúltiMallas) Muchos tipos de datos OF consisten de dos diferentes tipos de datos: la geometría y los atributos asociados. El registro correcto de los atributos con la geometría es una parte crítica del sistema ÓF. Este registro se implementa con ayuda de un modelo terrestre compartido
(CGC) y el sistema de múltiples mallas (mms) desarrollado por
Ulisses Mello de IBM. El sistema CGC crea y mantiene una representación topológica de un modelo terrestre que se utiliza como el modelo de referencia en cada uno de los proyectos de OF. El mms proporciona contenedores para todos los diferentes tipos de objetos y mallas de geometría necesarios para las aplicaciones tales como punto, polilínea, superficie, polígonos, tetraedro, cajas de unión y más. Para asociar el contenedor srfc con la geometría, se implementa un conjunto de clases de campo en este paquete. Estos campos se diseñan generalmente para conjuntos de datos estructurados y no estructurados 2D y 3D. Los campos estructurados en 2D se representan en horizontes y fallas, los campos no estructurados en 2D son horizontes triangulados y fallas.
-
Los campos estructurados en 3D incluyen campos regulares rectilíneos y curvilíneos. El campo no estructurado en 3D es una malla irregular. Este contenedor de campo es similar a los contenedores srfc. Ellos son objetos para almacenar la geometría y los atributos. Las APIs disponibles son o o conjuntos y solo consiguen métodos. Cada clase de campo tiene métodos para codificar y decodificar las corrientes de entrada y salida xdr sobrecargadas . La arquitectura de alto nivel de nuestra estructura modelada es un modelo de software de arquitectura estratificada en el cual cada capa tiene un distinto papel en la estructura. En la base de la estructura, utilizamos una representación topológica en base a la Radial Edge Data Structure - REDS - (Estructura de Datos de Borde Radial) que se utiliza para representar las topologías complejas sin diversidad. La REDS almacena explícitamente los dos usos
(lados) de una cara mediante dos regiones que comparten la misma cara. Cada uso de cara se une por uno o más usos de ciclos, que a su vez se componen de una secuencia alternativa de usos de borde y usos de vértice. La REDS es general y puede representar la topología si diversidad. Hacemos extensivo el uso de operadores topológicos de alto nivel para construir modelos terrestres debido a que las estructuras de datos topológicos son en general demasiado complejas para manipularse directamente. Los bordes de REDS pueden representar trayectorias de pozos, un conjunto de caras o una cubierta puede representar la superficie de una falla u horizontes sísmicos, y los conjuntos de regiones pueden representar las capas geológicas y las zonas de falla. El mallado y remallado asociado de estos objetos geológicos se o o basa en la conectividad e información de sub-división espacial almacenada en REDS . El Paquete Multimesh (MultiMallas) MMS Implementamos la REDS y sus operadores topológicos utilizando C++, y esta implementación es muy compacta, teniendo menos de 50 clases de C++. La REDS es el componente que almacena la representación topológica y geométrica de un modelo terrestre. El MMS es la capa que genera y administra mallas numéricas asociadas con las sub-regiones del modelo terrestre. Es importante notar que las mallas se tratan como atributos de las entidades geológicas tales como bloques, horizontes, capas y fallas. Por lo tanto, una malla no es el modelo, sino solo una posible realización de un modelo o una sub-región del modelo. Utilizando CGC y MMS, los operadores de la malla pueden proporcionar múltiples representaciones de malla con múltiples resoluciones de un modelo terrestre dado. Una aplicación particularmente importante de estos operadores se encuentra en el área de OF en donde es comúnmente necesario ascender en la escala de las cuadrículas geológicas hasta una resolución que pueda ejecutar la simulación de flujo en las computadoras disponibles. Las operaciones entre las cuadriculas de resolución gruesas y finas se facilitan grandemente en esta estructura. Modelo Terrestre Compartido (CGC) A fin de compartir la información geológica entre O S las diversas aplicaciones utilizadas en OF, se implemento un constructor de modelo terrestre compartido (CGC) . Un modelo terrestre se construye a partir de un conjunto de superficies poligonales que definen los límites de las estructuras geológicas. CGC tiene varios aperadores geométricos incorporados para facilitar la creación de representaciones en 3D apropiadas de las entidades geológicas tales como yacimientos dislocados. La interpretación sísmica estructural del yacimiento proporciona los elemento geométricos (conjunto de superficies poligonales) necesaxios para crear un modelo terrestre de yacimiento y su subdivisión espacial. La descripción geométrica y topológica de un modelo terrestre se obtiene de manera incrementada al agregar superficies poligonales secuencialmente al modelo. El modelo terrestre resultante contiene las divisiones de espacio (regiones de espacio) definidas por esas superficies. Las mallas pueden generarse para el modelo terrestre completo así como para cada región individual del modelo. Cada región puede tener múltiples mallas con diversas resoluciones asociadas con esta (abajo) . Estas mallas de región se tratan como atributos de la región del modelo de manera similar a otros atributos físicos tales como litslogía, densidad, y velocidad. En la actual implementación, una región mantiene una lista del nombre (Secuencia) de los objetos de malla asociados con o o esta. Estas mallas se almacenan en el repositorio de OF y puede consultarse fácilmente y recuperarse por el nombre. Estructura de Datos de Borde Radial Es importante comprender que esta estructura también nos permite manipular las representaciones voxel (mallas regulares) del modelo terrestre con gran flexibilidad. Por ejemplo, tratamos volúmenes sísmicos en 3D como atributos de cuadrícula regular del modelo terrestre. Debido a que el modelo terrestre tiene información explícita de la geometría de los objetos geológicos en el modelo, podemos seleccionar fácilmente, por ejemplo, sólo los voxeles sísmicos de un objeto de yacimiento particular. Sistema MultiMesh (MultiMalla) (MMS) Las MultiMallas necesarias como entrada para algunas de las aplicaciones de OF se generan automáticamente por el Sistema de MultiMallas. Este sistema se diseñó para integrar y transferir la información en mallas numéricas entre las aplicaciones que requieren distintas representaciones de malla. Las mallas son realizaciones separadas del modelo terrestre. Este es análogo al proceso de OF en el cual cada realización de yacimiento es solo una posible representación del yacimiento. Una malla particular
(regular, curvilínea o tetraédrica es solo una posible representación del modelo terrestre) . Las MultiMallas son capaces de generar mallas estructuradas (regulares y o o rectilíneas) y no estructuradas (tetraédricas) . Pueden manipularse todas las mallas necesarias para integrar las aplicaciones (Eclipse, FDM, EarthGM) . IBM ha contribuido a construir clases de yacimientos (SRFC) en la parte alta de algunas clases de MultiMallas, y el trabajo final se enfocará en la integración de MultiMallas con otras aplicaciones. El diseño de las clases de mallas en MMS se ha influenciado por el diseño de las clases de mallas VTK. Sin embargo, nuestras clases de campo son mucho más flexibles. Decidimos tener el diseño de malla cercano al de VTK debido a que hace más simple crear los objetos de malla VTK para la visualización. 3.5 Paquete de Entrada y Salida de Datos de OF de SRIO Las fuentes de los datos de OF son de muchos diferentes software de legado tal como las aplicaciones de interpretación tradicional (e.g., Landmark, GeoQuest) , software de procesamiento de datos sísmicos complejos (e.g., OMEGA), software de OF (e.g., EarthGM 3D) , software de simulación de fluido (e.g., VIP, ECLIPS) , software de - visualización y muchos otros. Estas aplicaciones toman diferentes formatos de datos como entrada y generan muchos formatos de datos diferentes como salida. El ciclo OF es un gran sistema de optimización que incorpora muchos conjuntos de datos para generar los mejores modelos de yacimiento. Es impractico y también imposible implementar elosoftware de OF que toma en cuenta todos los formatos de datos posibles . Construimos un software de OF que opera en el diseño de pozos y con frecuencia utiliza objetos de datos, pero otros tipos de datos deben convertirse a los tipos de datos internes. El archivo SRIO sirve para este propósito. ?l paquete SRIO consiste de un conjunto de clases que definen las APIs públicas para tedas las aplicaciones, y las clares derivadas para cada paquete de software de aplicación diferente. Cada clase tiene dos API: leer y escribir. Este método de lectura lee los datos del cliente y los convierte a objetos SRFC o MMS. El método de escritura convierte los objetos de SRFC o MMS al formato de los datos del cliente. 3.6 Paquete de Filtración de Datos del Filtro OF Los paquetes similares a SRFC no proporcionan ninguna APIs para manipular aquellos objetos de datos. Por ejemplo, los datos de perforaciones de pozo vienen usualmente con coordenadas (x, y) más la profundidad vertical y la profundidad medida, pero con frecuencia se utiliza un tiempo de recorrido de dos vías de la perforación de pozo cuando se compara con los datos sísmicos. Para, conseguir el tiempo de recorrido de dos vías, es necesario la tabla y el algoritmo de conversión tiempo-profundidad. Otro ejemplo son los datos representados para un horizonte, este proceso incluye dos diferentes objetos de datos: horizonte y datos o volumétricos. Se ha implementado un algoritmo de interpolación para obtener los datos para cada punto del horizonte. El paquete de filtro-proporciona un conjunto de clases para los datos específicos del filtro a partir de los objetos del contenedor de OF para satisfacer algorítmicamente los requerimientos anteriormente descritos. Aquellos de experiencia ordinaria en la técnica entenderán que aunque er. la anterior descripción de la invención se han establecido ciertas modalidades ilustrativas, la presente invención no se limita por las modalidades ejemplificativas establecidas en la presente. En particular, la cita de ciertas modalidades en relación con sistemas o redes particulares de operación de computadora o aplicaciones analíticas particulares no es limitativa, y es una ventaja específica de la presente invención, que pueden adaptarse fácilmente para usarse a través de una amplia variedad de sistemas, redes y configuraciones de lenguajes de computadora, por aquellos de experiencia ordinaria en la técnica, y que puedan implementarse para armonizar la operación de varias de las aplicaciones separadas relacionadas a la caracterización, incluyendo sistemas de legado así como aplicaciones analíticas y de caracterización de desarrollo futuro. De manera similar, la cita de las ventajas para utilizar la presente invención en conjunto con la entrada de datos de caracterización sísmica no limita la o o capacidad también implementa el sistema con datos no sísmicos de yacimiento. Así, las modalidades ilustrativas establecidas en la presente, no limitan el espíritu y alcance de la presente invención, que solo se limita por las siguientes reivindicaciones.