Meeting Notes:
POSC Supplier Workshop Series: Schlumberger / GeoQuest

Welcome; Alan Doniger

Meeting Agenda Review; Najib Abusalbi

The GeoQuest Products: Vision and Future Direction; Larry Denver

Larry described the coverage of the GeoFrame integration platform and traced how the coverage has expanded through the versions of the product from GeoFrame 1.0 in '93 through the plans for GeoFrame 3.5 in '98. Larry described the industry's current difficulty in leveraging upstream data for use downstream in models. He talked about using a framework approach for leveraging more of the interpreted structural and stratigraphic data. He talked about the approach as "building models as we interpret."

Larry talked about plans for GeoFrame 4.0 in '99 which is expected to address production analysis, pre and post-simulation, drilling, and inter-well imaging. He described the OGCI product line for reservoir management and production surveillance (was Production Analyst and is now Oil Field Manager for Windows).

Discussion

• Cary Purdy (CP): How does the LogDB product fit with other products?
Larry Denver (LD): LogDB is an archival system. Data may be extracted from LogDB for use with petrophysics tools.
• CP: Is Enterprise a separate product?
LD: Enterprise is part of Finder now. It can be used, for example, to access data from both Finder data bases and third-party data bases.
• Ted Lumley (TL): Is your goal to reduce cycle time on a component basis or on a systemic basis?
LD: Historically, work in one domain is not leveraged throughout the life cycle. We are now doing things to improve cycle time across domains.
• CP: Can preferred interpretation elements be set?
LD: Yes, that can be done with a preferred collection.
• CP: Is there trace history tracking and seismic tracking?
LD: Yes and yes.
• Michael Ring (MR): How many GeoFrame installations are there worldwide?
Frank Marrone (FM): Prior to the release of GeoFrame 3.0, there are 600. With the inclusion of geophysical applications in GeoFrame 3.0, there will be four to five thousand.
• MR: What is meant by "improved integration with surface facilities?"
LD: It means putting constraints from the surface facility into the reservoir simulation process, i.e. coordinating with the facility piping network.
• MR: What is the impact of the Year 2000 problem on your products?
LD: We plan to confirm fixes for the Year 2000 problem during '98.
• Keith Tally (KT): Is Stratlog available alone or only with GeoFrame?
LD: When Stratlog is purchased, it is a part of GeoFrame.
• Van Bui-Tran (VBT): Do the products support geostatistics?
LD: Tools from Geko-Prakla are being added for attribute anomalies using Basian methods or neural networks. Our Geologic modeling (Property Modeling) and mapping products (Log Property Mapping) also support geostatistics.
• Harvey Ford (HF): Do the products run on Windows NT?
LD: Yes, some of our products are already based on NT. The testing load to deliver on NT and UNIX is very heavy, so we have prioritized the commercial products based on client feedback. NT, in general, is something we will deliver as clients request it.
• When will the GeoFrame Developer ToolKit (GFDK) be released?
LD: The toolkit is being shipped on the same schedule as GeoFrame 3.0. Key clients are receiving it now.
• Dortha Dougherty (DD): Are CGM and/or CGM*PIP used?
LD: Yes and yes.
• MR: Would you characterize the effort and time put into testing?
LD: That is difficult to do. There were eighty people involved testing GeoFrame 3.0 for a period of one year. There was a six to seven month pre-release period for selected clients. Integration testing is an enormous effort.
• Dan Schenck (DS): Would you discuss how the product supports plug-and-play?
LD: There are a number of possible scenarios. Some will develop applications on GeoFrame which would provide complete plug and play with other GeoFrame applications. Some users will merely want to access data from GeoFrame without even running GeoFrame.
• Tarek Ghazi (TG): Would you compare the performance of IESX and Charisma stand-alone versus in GeoFrame?
LD: The results indicate that some tasks are faster while others are slower depending on what is being done. Fundamentally, the start-up process is in some cases slower, but it is not necessarily noticeable afterwards.
• Tom Nash (TN): When will Finder be converted fully to Epicentre?
LD: There will be progress release by release over the next two to four years. I can't say specifically.
• Steve Jennis (SJ): How do you support third-party components?
LD: We work with individuals clients, e.g. Chevron. We recommend processes that should be used.
• Åge Haldorsen (ÅH): Will oil companies use more application licenses and, thereby, have higher costs with your new products where more applications are packaged with GeoFrame?
LD: This is not necessarily the case.
Frank Marrone (FM): The costs may decrease as there are more opportunities to share licenses. Also, the costs may decrease as redundant products are eliminated as a by-product of the integration.
Jay Hollingsworth (JH): As GeoFrame incorporates more applications, oil companies may be able to buy smaller components at lower unit cost.

The GeoFrame 3.0 Release: Deployment, Scope, OpenToolkit; Frank Marrone

Frank explained the content of the toolkit, its availability, terms, and conditions. He described the level of market interest in the toolkit as being strong with over 56 companies expressing interest and nearly 30 buying licenses already.

Discussion

• Kelly Crawford (KC): Is there project locking?
FM: This is mainly a problem with stand-alone applications without multi-user access. More capabilities will come in GeoFrame 3.5, e.g. data item level access authority.
• David Archer (DA): Can work done on another supplier's integration platform be shared with GeoFrame applications?
FM: I haven't looked at it that way. For example, Elf wants certain applications from CGG/Petrosystems to work with Charisma. We are not opposed to sharing in this way, if there is client interest and if there are no commercialization issues.
• Gongquan Chen (GC): Are the header files in C or C++?
Najib Abusalbi (NA): C
• DA: Does the use of the toolkit involve paying a royalty fee? Must a user have the GeoFrame run-time environment?
FM: Yes, the user must have a GeoFrame run-time environment.
• Jay Hollingsworth (JH): A user must acquire an Oracle run-time license as well. Correct?
FM: Yes.
• JH: Are any third-party applications developed with the toolkit released on GeoFrame 3.0?
FM: Not yet. In the future, the toolkit will be released ahead of the commercial release to enable third-party developers to prepare their updates for release in time with our commercial releases. In this first release, they were released simultaneously.

The GeoFrame Architecture: Data Model, Data Access, Inter-Application Communications, Data Exchange, Business Objects; Najib Abusalbi

Najib explained how Epicentre is mapped (projected) to both objects and physical tables and how meta-data is stored for reference in framework tables. He illustrated the user interface for object editors. Najib compared the GeoFrame data model to Epicentre in terms of common and extended entities, attributes, and relationships. He explained that extensions were used to support specific application needs and to address open issues with Epicentre. A proprietary projection and object mapping tool is used currently. Commercial tools are being evaluated.

Najib reviewed the topical coverage of the GeoFrame data model. He explained pilot projects using POSC's DAE specification and explained how Schlumberger's own Application Data Interface (ADI) is used in the current GeoFrame product. Najib concluded by reviewing the pilot architecture being used to support interoperability and business objects, which is based on the preliminary architecture defined by the POSC Interoperability work effort earlier this year.

Discussion

• LW: What is done to move to a new version of Epicentre?
NA: The objects are re-mapped.
• JH: Do the applications use direct SQL access to the physical tables?
NA: Applications access data through the objects. You could access data directly, but direct access is not recommended since the objects embed most of the usage rules.
• DA: Are the GeoFrame entities a proper subset of the Epicentre entities?
NA: No. About 20% of the 628 entities in GeoFrame are extensions. The additional attributes include many derived attributes (with stored procedures).
• JH: Why are some attribute names different between Epicentre and GeoFrame?
NA: Some differences are due to historical usage or conventions. Some differences are in areas where the corresponding Epicentre attribute has not been used. The historical differences will be eliminated as soon as we can.
• Steve Trythall (ST): What purpose is served by defining the mappings?
NA: People want to understand our process of data definition.
• Winston Gunther (WG): Are applications impacted by the differences in attribute names?
NA: No. Applications only see the attribute names from the objects -- not from the physical data model.
• JH: Are attribute format and length carried in the meta-data?
NA: Only to the extent that there are changes from Epicentre to support application requirements.
• JH: Are your extensions and modifications fed back to POSC?
NA: In cases such as increasing the precision of locations, yes. We have not shared the derived data definitions with POSC as yet.
• JH: Culture data is not well addressed in GeoFrame. This subject would benefit from joint work by suppliers, GeoShare, and POSC. Is that feasible?
NA: Bill Quinlivan is working on culture data. We don't mind sharing this work. We would start from Epicentre and we would submit the results to the GeoShare User Group.
• Dan Schenck (DS): Does the POSC DAE specification fit into the GeoFrame architecture?
NA: We have experience with DAE, but it is not currently used and we don't know if it will be used in the future.
• DA: Is your DAE work included as part of the GeoFrame toolkit?
NA: No. To do so would present a support issue for us.
LD: It is a matter of priority.
• DA: Are there any plans to support access to GeoFrame data stores from non-GeoFrame, POSC-based applications?
NA: Our approach would be to do so through business objects, i.e. using a higher-level toolkit.
• Doug Benson (DB): Which DAEF product did you use in your pilot projects?
NA: We used the POSC sample implementation. We also have the Prism Epicentre Access product. We will upgrade to the commercial (LightSIP project) product. We have to decide what to do for the future.
• DS: Do you have any issues with the preliminary architecture from the POSC interoperability work effort?
NA: Yes. We will address these issues in our response to the Request for Technology.
• William O'Brien (WOB): Would you comment on your experience using the DAE frames construct?
NA: We used frames in our pilot projects. The DAE frames interface is complex to use directly, because it is defined at a low level.
• WOB: How are complex data types stored in GeoFrame now?
NA: We interfaced to our existing bulk data storage using the POSC DAE Bulk Data Access Library (BDAL) specifications.

General Discussion

• ST: The use of terms POSC-compliant, POSC-based, POSC-like, etc. can be confusing. Would you comment on that?
NA: Compliance is not a binary switch. It is a process of balancing standardization with commercialization. It is important to have levels of compliance.
• Should POSC have some kind of compliance verification process?
NA: The client asks for evidence of compliance. This ranges from requests for formal mappings to simply saying so.
• DA: This is both good and bad. Compliance is a "directional statement," but there is still confusion. We must work on this subject fairly hard and fairly soon. We need objective measures to define the terms. Buyers are asking to see a demonstration of the capability to exchange data.
• LW: I believe that too much money is being put on the issue of compliance. There is a need for flexibility and less emphasis on technical compliance. We need more focus on functional compliance.
• VBT: What is your relationship with GOCAD?
LD: We are not members of the GOCAD Consortium.
• Bertrand du Castel (BdC): The market will decide which supplier is compliant. POSC should not spend a lot of resources on this issue. We are reaching a plateau, but it is based on the wrong technology. The future is moving away from process-oriented systems and moving towards model-based systems to refine a single earth model. We can't have two earth models for sharing data among real-time applications. The work of RESCUE, OMEGA, XOX, GOCAD, URGENT, etc. is relevant. If POSC is not the body to consolidate these ideas, then POSC is not fulfilling its role.
  DA: Nevertheless, we believe that it is necessary to try to clarify the POSC compliance issue.

Closing; Alan Doniger