releasenotes_2009_1

Ocean for Petrel 2009.1

Release Notes

For Geoscientists and Software Developers

Published by Schlumberger Information Solutions, 5599 San Felipe, Houston Texas 77056

ii

Copyright Notice Copyright © 2008-2009 Schlumberger. All rights reserved. No part of this manual may be reproduced, stored in a retrieval system, or translated in any form or by any means, electronic or mechanical, including photocopying and recording, without the prior written permission of Schlumberger Information Solutions, 5599 San Felipe, Suite 1700, Houston, TX 77056-2722. Disclaimer Use of this product is governed by the License Agreement. Schlumberger makes no warranties, express, implied, or statutory, with respect to the product described herein and disclaims without limitation any warranties of merchantability or fitness for a particular purpose. Schlumberger reserves the right to revise the information in this manual at any time without notice. Trademarks Petrel, Ocean and Ocean for Petrel are trademarks of Schlumberger. Microsoft® and Windows® are registered trademarks of Microsoft Corporation.

iii

Table of Contents

Table of Contents .................................................................................................................. 3

What is Ocean for Petrel? .................................................................................................... 1

Ocean for Petrel Distribution – CD ............................................................................... 1

Product Licenses .......................................................................................................... 2

Ocean for Petrel Documentation .................................................................................. 2

Operating Environment ................................................................................................. 2

Petrel 2009.1 ................................................................................................................. 3

Ocean API Stability ....................................................................................................... 3

Summary of Ocean elements ............................................................................................... 4

Ocean Architecture ....................................................................................................... 4

Ocean Core ................................................................................................................... 5

Ocean Services ............................................................................................................. 5

Ocean for Petrel ............................................................................................................ 7

New features in Ocean for Petrel 2009.1 ............................................................................ 9

Domain API ................................................................................................................... 9

UI and Look & Feel ..................................................................................................... 18

New features in Ocean for Petrel 2008.1 .......................................................................... 22

Domain API ................................................................................................................. 22

UI Infrastructure .......................................................................................................... 28

Installation and Un-installation .................................................................................... 30

Known Issues ...................................................................................................................... 31

Known behavioral differences between Ocean for Petrel 2009.1 and 2008.1 .............. 33

Tutorial: The EclipseFormatSimulator API ...................................................................... 37

Introduction ................................................................................................................. 37

Integrating a Simulator ................................................................................................ 38

Saving of projects and matching up of simulators ..................................................... 44

Example:Integrating FrontSim as a plug-in Simulator ................................................ 45

Adding Your own Custom Tabs .................................................................................. 47

Adding a Custom Editor .............................................................................................. 52

Tutorial: The Uncertainty API ............................................................................................ 53

Uncertainty API ........................................................................................................... 53

Background ................................................................................................................. 53

API design ................................................................................................................... 54

Client code samples.................................................................................................... 57

Contacting the Ocean Team............................................................................................... 61

1

What is Ocean for Petrel?

Ocean is an open, proprietary application development framework targeted for E&P software. Ocean provides a powerful software development environment through the extensive API footprint, through the .NET based architecture and the associated .NET tools. The Petrel application is implemented on the Ocean framework, and is bundled with Ocean and Ocean for Petrel. Ocean for Petrel enables access to the key Petrel domain data types, as well as user interface and interaction features. It also enables extensions of Petrel, allowing addition of new domain data types with renderers, new windows, and new algorithmic and interactive processes. Ocean for Petrel offers the opportunity to extend, interoperate with, and re-use many of the features of Petrel in custom workflows. This expedites delivery of technological innovation and significantly reduces the time-to-market. This document contains the release notes of Ocean for Petrel 2009.1. The features that are new with this release are listed in the section New features in Ocean for Petrel 2009.1, page 9. For completeness, we have also integrated the summary of the news in the previous version over the one before that in the section New features in Ocean for Petrel 2008.1, page 22. A summary of known issues in Ocean for Petrel 2009.1 can be found on page 31.

Ocean for Petrel Distribution – CD

All the elements necessary to develop Ocean for Petrel plug-ins are available on the Ocean for Petrel Distribution CD.

This consists mainly of:

• Petrel 2009.1 (32 and 64bits) and Ocean for Petrel 2009.1 API binaries,

• a Demo Data Set (Gullfaks for Petrel 2009.1),

• the Ocean for Petrel 2009.1 SDK documentation integrated with Visual Studio,

• the Ocean for Petrel Wizards (Visual Studio 2005 and Visual Studio 2008 Plug-in) ,

• Sample Code and Reference Applications showing patterns for how to use the API,

Please refer to the Installation Guidelines on the CD to get the details of the CD content and how to install the Ocean for Petrel development environment.


2

Product Licenses

Ocean is a licensed feature of Petrel. A developer’s license is required to create new Ocean modules.

If you run Petrel 2009.1 with an Ocean for Petrel Developer’s License, all licensable features of Petrel will be available. The license may be used for testing the interoperability of developed Ocean modules with Petrel. The enabled Petrel features may not be used for any other purpose, such as offer or perform commercial services and perform commercial or competitive analysis of Schlumberger’s software. Furthermore, Petrel will configure itself to go into Developer’s mode. This implies that the Petrel application shell and all hard-copies will be watermarked. Any projects saved whilst in Developer’s mode will be tagged. Such projects will continue to be watermarked even if you load these into a fully featured version of Petrel at a later point.

Ocean for Petrel Documentation

The Ocean for Petrel help files (.chm, .HxS and the .doxdb files) are generated from the source code at build time, and is the ultimate source of API documentation. Please refer to this for the definitive list of API features.

Operating Environment

Ocean for Petrel 2009.1 (3.2009.0.0) has been validated on Windows XP (XP 32 and XP 64 as a 32bits application), and Windows Vista 64 (as a 64 bits application). Ocean for Petrel 2009.1 is built on top of Ocean Core, version 3.2008.4.0, and on Ocean Services, version 3.2008.11.0.

The following 3rd party software is needed for developing Ocean for Petrel modules:

Windows XP SP2 (32 or 64 bits) or Windows Vista 64 operating system

Visual Studio 2005 or Visual Studio 2008 Standard/Professional

In addition OpenInventor (version 7.1.1) comes bundled with Ocean for petrel 2009.1. Note that the OpenInventor (3D graphics) toolkit is an integral part of the Ocean API. It is not separately licensed, but can only be used in the context of Ocean for Petrel. OpenInventor is provided by Mercury Computer Systems. If a stand-alone version of OpenInventor is required, you need to purchase a license directly from Mercury Computer systems. More information may be found at www.mc.com.


3

Unless a plug-in needs specific Infragistics control, the purchase of an Infragistics license isn’t needed anymore. The dependencies have been removed from the Ocean for Petrel API. A new PetrelSystem.ToolService can be used to access Petrel toolbars and menus. The Ocean for Petrel binaries were built with Visual Studio 2005, with Service Pack 1 installed as well as the hotfixes 932232 (vista), 932372, 940359, 936142, 934341, 930259, 938057, 939879

Petrel 2009.1

Please refer to Petrel 2009.1 documentation for information regarding the features shipped with Petrel 2009.1.

Ocean API Stability

We are committing to a minimum of 2 release compile-time compatibility in the Ocean API. This will enable applications to be easily migrated to subsequent, commercial versions of Ocean applications. There is however an exception to this commitment: In some cases we expect changes in the underlying API implementation, which may imply changes in the API. In these cases we have tagged the API with the keyword ‘SubjectToChange’ in the Ocean help files, which are available with the Ocean for Petrel SDK installer.

API’s that will be replaced and phased out in the future are marked as Deprecated, and your compiler will give you warnings if you continue to use these. However, the deprecated API’s are still supported and tested until they disappear.

Ocean for Petrel 2009.1 is built on top of Petrel 2009.1. It is not binary compatible with 2008.1, it means that plug-ins developed against Ocean for Petrel 2008.1 (or previous releases) need to be recompiled to work with Ocean for Petrel 2009.1. Due to serialization changes in the baseline it is not possible to open projects saved with Petrel 2009.1 with the commercial Petrel 2008.1 baseline.

4

Summary of Ocean elements

Whilst the definitive documentation for API features is available in the help files, bundled in the Ocean for Petrel 2009.1 SDK installer, this section gives an overview of the fundamental building blocks of Ocean.

Ocean Architecture

The Ocean architecture is illustrated in Figure 1. The foundation of the overall system is Ocean Core. Ocean Core provides the essential features that are used by components at a higher level in the architecture, e.g. module lifecycle management and data source management.

The next level in the architectural hierarchy is the Ocean Services, comprising features such as coordinate transformations and unit conversions. Ocean Services can only have dependencies to Ocean Core or to other Services.

The third level introduces the product family, which in this case is Ocean for Petrel. It provides access to Petrel data types, the Petrel UI and Petrel workflow management.

Ocean Applications may use all of these API’s, as illustrated in Figure 1.

Figure 1 Ocean API architecture

Ocean CoreOcean Core

Infrastructure:- Service locator- Messaging interface- Module lifecycle- Data source manager- Workspace- Event transaction mgr.- Licensing

Infrastructure:- Service locator

- Messaging interface

- Module lifecycle

- Data source manager

- Workspace - Event transaction mgr.

- Licensing

Ocean ServicesOcean Services

Application-independent services:- Domain object hosting- Unit system / conversions- Coordinate system / conversions

- Abstract data types- Geometry data types

Application-independent services:- Domain object hosting

- Unit system / conversions

- Coordinate system /

conversions

- Abstract data types - Geometry data types

Ocean PetrelOcean Petrel

Product family:Application shell

Domain objects

Data sources / bulk access Processes

Windows

Toolbars

Events Interaction

Product family: Application shell Domain objects

Data sources / bulk access Processes Windows

Toolbars

Events Interaction

Application moduleApplication module

Deployed as plug -in or extension moduleDeployed as plug-in or extension module

Public API Public API Public API





- Module lifecycle



- Licensing





- Module lifecycle



- Licensing







conversions








conversions


Ocean PetrelOcean Petrel


Domain objects


Windows

Toolbars

Events Interaction



Toolbars

Events Interaction

Ocean PetrelOcean for Petrel


Domain objects


Windows

Toolbars

Events Interaction



Toolbars

Events Interaction

Application moduleApplication module

Deployed as plug -in or extension moduleDeployed as plug-in or extension module Application moduleApplication module

Deployed as plug -in or extension moduleDeployed as plug-in or extension module

Public APIPublic APIPublic API Public APIPublic APIPublic API Public APIPublic APIPublic API


5

Ocean Core

The Ocean Core consists of a set of basic principles and strategies, interfaces and implementations, all designed to guide the development of all Ocean applications such that they are all aligned to the same basic mold.

The Ocean Core APIs exposed are:

• Module Lifecycle

• Service Locator

• Basic Logging

• Data Source Manager and Data Source

• Workspace

• Event Transactions

The Ocean Core uses some of the Microsoft Enterprise Library’s application blocks, namely Logging and Exception Handling. Logging is configurable.

Ocean Services

In this version of Ocean, six services are provided, namely Basics, Geometry, a Unit Service, Domain Object Hosting, Catalogs Service, and a Coordinate Service. The last service is not to be considered fully commercial at this point.

Basics

This service provides applications with basic types, representing concepts such as Extents, Indices and Index ranges, together with basic numerical algorithms.

Geometry

This service provides applications with fundamental definitions of geometry, e.g. basic types such as Angles, Points and Lines, Planes and Boxes.

Unit Service

The Unit Service consists of a catalog of unit measurements that is organized hierarchically. Unit measurements (e.g. “length”) are associated with units (e.g. “meters” or “feet”), also organized in a catalog. A third catalog keeps pairs of unit and unit measurements defining unit systems (e.g. “metric” or “imperial”). The unit conversion service provides converters between units


6

defined in the catalog to transform values.

In the Ocean domain API all data are delivered and received in base1 SI units. Note in particular that the base SI unit for seismic traveltime is seconds (not milliseconds) and for permeability is m2 (not Darcy or milli-Darcy; 1 Darcy = 0.9869233E-12m2).

With 2009.1, the Extensible Unit Service allows an application (or product family) to create its own unit catalogs that reference and extend the predefined catalogs in the Reference Unit Service.

Catalogs Service This service allows applications to look up log channels based on channel names or unit measurements.

Coordinates Service

This service provides you with the ability to create converters to transform data between coordinate systems.

The new Coordinates Service replaces the previous Coordinate System Services. It is still based on the Mentor coordinate conversion engine, but the API is abstracted so that different conversion engines may be mapped to the same API in the future.

The API of this service may change somewhat in coming releases of Ocean.

Domain Object Hosting

Ocean provides high-level data access to entities representing data, irrespective of the data source, called Domain Objects. The framework allows a developer to encapsulate application-specific validation or usage rules and hide location and complexities related to the data store.

Domain Objects typically act as intermediaries between a persistent data store and application code. They map from the data store representation to a format required (and desired) by applications. Their object model is often quite different from the model used by the underlying data store – they hide database implementation details and differences between database vendors from the application. Domain Objects do not require persistence – it is possible to have in-memory objects that contain business logic but do not save their state to a persistent data store.

Domain Object Hosting provides support for transaction management allowing the user to lock objects before they are modified, commit changes after modification, or rollback

1 Base SI unit are defined as the SI unit, which has a scaling factor of 1.0 and an offset of 0.0. A

homogeneous unit system promotes cross-computation. Example: a product of two base SI units values yields a value in a base SI unit of a new measurement.


7

changes2 if the modifications are abandoned.

Domain Object Hosting provides a notification event mechanism to which a module can subscribe. The object will then be notified when the object changes or is being changed. This means that domain object writers create new data types that follow the same usage pattern as the Petrel data exposed through the API.

Ocean for Petrel

Extending the Petrel User interface, the UI Infrastructure

The Petrel user interface (UI) uses MS Winforms. A set of API’s have been exposed so that it can be tailored to the needs of new applications. Ocean for Petrel provides convenience classes in order to display messages, status information, and progress information. It also allows for examining the Petrel project state, and change and manage the different UI elements exposed from Petrel.

The UI Infrastructure API provides interfaces to access the various elements of the Petrel Explorer. You can add new objects to the trees, or customize existing ones. All tree interfaces provide current selection and selection change events, so the module can access the state of a particular tree or be notified whenever a change is produced (i.e. new object is select/deselected).

The content of display windows in Petrel are synchronized with objects and elements selected in the Petrel Explorer. The window manager interface handles the display window area by reporting its current state, notifying windows state changes with events, and managing collections of windows.

Ocean for Petrel provides APIs for custom rendering of new domain objects in selected 2D windows and in the 3D Petrel window, and for creating new windows. Objects rendered with 2D graphics use .NET Graphic Library (GDI+), while 3D rendering is done with OpenInventor.

Interoperating with Petrel data types, the Domain API

The Ocean for Petrel Domain API exposes and offers a number of data types and services to manage Petrel data. These services include the ability to navigate the data, to programmatically discover relationships between data types, to enable additions of new extension objects to existing Petrel objects, as well as a data event model. For a full overview of the current capabilities, please refer to the API documentation. A brief description of the data types follows:

PillarGrid: This API gives access to the 3D Grid model of Petrel. Grid geometry, properties, faults, horizons, segments and zones are accessed through this main class.

Shapes: provides support classes to manipulate points, polylines, and surfaces. The

2 Roll-back is not supported for the current version of Ocean Services


8

PointSet and Surfaces classes also provide access to properties associated with the shape.

Well: Borehole is the main class in this API, and gives access to Logs, Trajectory, Completions and Markers, from which it is possible to identify the relationships to zones, horizons and faults.

Seismic: SeismicCollection and InterpretationCollection act as the containers for seismic surveys and faults and horizons interpreted on seismic data, respectively. The API supports 2D and 3D seismic data and 2D and 3D interpretation. Traces can be accessed either through an enumerator or randomly from a relative positional index. In addition, it’s possible to access sub-cubes of 3D data.

Simulation: provides interfaces to access reservoir simulation data in Petrel: Streamlines, Summary vectors, Observed (production) data, Fluid and saturation functions. SimulationRoot acts as the container for all domain objects in the simulation domain. ISimulationManager and EclipseFormatSimulator allow to integrate a custom simulator into Petrel. The external simulator must be compatible with the Eclipse simulators and perform input and output in an Eclipse format.

Petrel Processes and Workflows, the Workflow API

New processes may be created, and may be executed from Petrel’s Process Diagram, or as part of a Petrel Workflow as defined in Petrel’s Workflow Editor. The API essentially enables custom processes to take seamlessly part in Petrel’s workflows.

The process may have a UI auto-constructed by Ocean for Petrel from a set of arguments, but applications are also free to create their own custom UI’s.

New features in Ocean for Petrel 2009.1

9


Domain API

Reservoir Engineering – Plug-in Simulator

UI extensibility for simulator plug-ins Namespace: Slb.Ocean.Petrel.Simulation.SimulatorPageUIFactory, Slb.Ocean.Petrel.Simulation.SimulatorPageLogic

MySimPage : SimulatorPageLogic<TArgPack>

PageList.Add(new MySimPage())

MySimPageFact : SimulatorPageUIFactory<TArgPack>

CoreSystem.Services.AddService(typeof(TArgPack),

MySimPageFact.ServiceType,

new MySimPageFact())

For more detailed information, please consult section “Tutorial: The EclipseFormatSimulator API” on page 37.

Programmatically run a simulation case Namespace: Slb.Ocean.Petrel.Simulation. This feature allows to programmatically execute the same operations a Petrel user can trigger by clicking the Run button on the Define simulation case process dialog. How to use the API:

1. Define the class that will run simulation 2. Derive custom CaseRunnerMonitor class. (Optional. But necessary when user wants

to capture the finish events from Simulation process) 3. Get an instance of CaseRunner through PetrelSystem.SimulationManager, and run

the Simulation.

Simulation.CaseRunner.Export()

Simulation.CaseRunner.Run()

Simulation.CaseRunnerMonitor.RunAborted()

Simulation.CaseRunnerMonitor.RunCompleted()

New property to access exported sections of an Eclipse Deck The EclipseFormatSimulator provides a new property RequestedExportSections to

specify which sections of the Deck need to be exported when Petrel does the export.

Interface to use keywords of an Eclipse Deck Namespace: Slb.Ocean.Petrel.Simulation


10

The API allows accessing the individual sections of an Eclipse deck such as GRID, SCHEDULE etc. to add, insert or remove keywords from each section. It is possible to get an EclipseKeywordEditor from ISimulationManager by passing the relevent Simulation domain object. Then the KeywordDeckSections object allows access to a desired section. The API provides access to a Keywords IEnumerable and CreateKeyword() methods to create and edit keywords.

EclipseKeywordEditor

EclipseKeywordSection.CreateKeyword(…)

EclipseKeywordSection[i]

EclipseKeyword.Name – EclipseKeyword.FreeText

Access to segmentation borehole’s flow paths Namespace: Slb.Ocean.Petrel.DomainObject.Simulation.SimulationRoot The multi-segmented well model in Petrel and ECLIPSE divides the whole well bore into segments with different physical properties to allow ECLIPSE to accurately model the fluid physics throughout the well bore. The SegmentationSpec object represents the segmentation of a borehole’s flow paths. The API allows creating and accessing SegmentationSpec.

SimulationRoot.SegmentationSpecCollection

Simulation.SegmentationSpec.Spec

.SegmentLength

.UseFriction

Simulation case $variables ISimulationManager.GetCaseVariables(…)

Liners (completions type) Namespace: Slb.Ocean.Petrel.DomainObject.Well.Completion The type LinerString is added to the Completions API and can be created via Borehole.Completions.CreateLinerString. In previous versions liners had to be modeled as CasingString instances with the StartMD set greater than zero, and as such would show in the Petrel UI with the casing icon rather than the liner icon.


11

Uncertainty Workflow API Namespace: Slb.Ocean.Petrel.Uncertainty The Uncertainty API enables extensibility of the Petrel Uncertainty process. This is done by registering user-defined algorithms via PetrelSystem.UncertaintyManager. The benefit is that the algorithm may focus directly on the parameter tuning of the optimization loop, and can leave to Petrel the logistics and machinery of updating models, re-gridding, creating simulation decks and running the simulation. For more detailed information, please consult section “Tutorial: The Uncertainty API” on page 53. Distribution functions A distribution exposes an operation over an argument package containing all the distribution settings. Custom distribution functions

MyDistr : Distribution<TArgPack>.NextSample(…)

Sampler Provides parameter values to the Uncertainty process. This can be either random values (e.g. Monte-Carlo sampling) or following some sort of methodology (e.g. experimental design). Custom samplers

MySampler : Sampler<TArgPack>.Validate(…)

.CreateExecutor(…)

SamplerExecutor.SampleValues(k,output)

Proxy (Emulator) Computes an approximation to simulation output. Usually, an emulator is calibrated with a small number of actual simulations before it can provide approximated results (e.g. neural network). Custom simulator proxies

MyProxy : Proxy<TArgPack>.CreateExecutor(…) etc.

ProxyExecutor.Evaluate(input,output)

Optimizer Finds an optimal set of control parameters of a given objective. This usually involves evaluation of the simulator for a large number of input configurations

Custom optimizers MyOpt : Optimizer<TArgPack>.CreateExecutor(…) etc.

OptimizerExecutor.SampleValues(k,output)

OptimizerExecutor.ReportOptimums(…)


12

Data Analysis

Selection Filters Namespace: Slb.Ocean.Petrel.DomainObject.Analysis A LogicalFilter is defined by an association of logical operation on the result of other filters. A PropertyVersionFilter is defined by an association of regions in the property space [FirstProperty, SecondProperty], each region including or excluding a range of values (1D filters) or a set of points (2D filters).

The DataSelectionFilterRoot allows getting PropertyVersionFilter and LogicalFilter objects in the context of a Project.A DataSelectionFilterRegion is defining a set of values or points to be included by a PropertyVersionFilter object. SelectionFilterRegion can define a 2D or 1D region: a 2D region will be represented by a polygon, whereas a 1D region will be a value range with a lower and upper limit.

1D property (selection) filters DataSelectionFilterRoot.CreatePropertyDataFilter()

PropertyDataFilter1D.Add/Get/Set/RemoveRegion()

PropertyDataFilter1D.Property

PropertyDataFilter1D.IsIncluded(...)

myWindow.SetVisible(PropertyDataFilter1D/2D)

2D property (selection) filters – extras/special wrt. 1D DataSelectionFilterRoot.CreatePropertyDataFilter()

PropertyDataFilter2D.SecondProperty

Logical filters not=new LogicalDataFilterNot(f1);

and=new LogicalDataFilterAnd(f2,f3);

comb=new LogicalDataFilterOr(and,not);

DataSelectionFilterRoot

.CreateLogicalDataFilter(comb)

Variogram Domain Object Namespace: Slb.Ocean.Petrel.DomainObject.PillarGrid A variogram describes the natural variation in a property (surface property, model property, etc.) and is used as input to both discrete and continuous property modeling. The Ocean for Petrel API exposes the Petrel model variogram defined in the Property modelling -> Data Analysis process, from the Variograms tab. The PillarGrid.DataAnalysis is used to create and get PillarGrid.ModelVariogram and PillarGrid.DictionaryModelVariogram instances. In addition to a continuous property, a model variogram instance will have associations with a PillarGrid.Zone or with all zones. In addition to a dictionary property, a DictionaryModelVariogram instance will have associations with one or all PillarGrid.Zone and facies.

DataAnalysis.Create/Get…(…)

Grid.DataAnalysis.Create/Get…(…)

PillarGrid.ModelVariogram .Dip

.MajorRange

.Nugget

etc.

PillarGrid.DictionaryModelVariogram …


13

Correlation data (cross plot) Domain Object Namespace: Slb.Ocean.Petrel.DomainObject.Analysis Ocean for Petrel 2009.1 exposes the cross plot domain object, used in property modeling in Petrel. A crossplot domain object describes a bivariate distribution. The bivariate distribution values are contained in a collection of Point2 values.

CorrelationData2D[k].X/Y

Function Domain Object Namespace: Slb.Ocean.Petrel.DomainObject. Analysis Ocean for Petrel 2009.1 exposes the function domain object, used in property modeling in Petrel. This requirement relates to the function domain object, not the function window/renderer. A Function domain object describes a linear regression function. The data are contained in a collection of Point2 values.

Function[k].X/Y

LaunchDataAnalysisDialog Namespace: Slb.Ocean.Petrel.PetrelSystem.ProcessDiagram Programmatically launch the data analysis tool / dialog of Petrel

ProcessDiagram.ShowDataAnalysisProcess(…)


14

Seismic Performance

Improved bulk access speed Namespace: Slb.Ocean.Petrel.DomainObject.Seismic Performances of access to seismic data have been improved. Both ISubCube and ITrace access have been optimized and should now be limited by the disk access. No API change. On a default developer machine, initial measurements show the following performance improvements: ~28MB/s to 180MB/s for 32-bit data sample by sample access (fully cached) ~24MB/s to 120MB/s for 8-bit data sample by sample access (fully cached, slower due to byte to float conversion) ~60MB/s to 260MB/s for 32-bit data using the ToArray () (fully cached) ~60MB/s to 270MB/s for 8-bit data sample by sample access (fully cached) For large cubes, the machine yields a sustained throughput of 70MB/s or so from disk. (Note that these numbers are measured for a best-case scenario, where the cube is accessed in the most efficient way: access has been designed to minimize cache misses, looping through all samples in each 64x64x64 brick in the zgy file).

Regular Height Fields Surface Performance Improvement Namespace: DomainObject.Shapes A new method: SurfaceProperty.SetRecordValues(…)has been implemented to set

Surface properties in a bulk fashion. Performances using this method are much better than the random access.

Multi-Threading - Attribute computation Namespace: Slb.Ocean.Petrel.SeismicAttribute This requirement was already available in Ocean for Petrel 2008.1 with the new IAttributeVersion2 interface. It now supports multiple seismic cubes and additional testing has been provided for 2009.1. The interface IAttributeVersion2 inherits Iattribute, it influences performance, threading, API access and persistence. Performance:

• The generator's Calculate method is now called with subcubes tailored to what is required to fulfill the user interaction that caused the computation. For example visualization of a horizontal slice triggers thin subcubes to be passed for calculation. The original IAttribute always got called with sub cubes of one seismic trace.

• IAttributeVersion2 uses a more optimized code path to provide improvement in computation speed of around an order of magnitude for simple algorithms. With complex algorithm the performance improvement might not be as noticeable.

• IAttributeVersion2 implementations with large computational footprints run faster because they are called fewer times than before (with larger subcubes).

Threading and API access:

• IAttributeVersion2 computes in one of two thread modes: SingleWorkerThread or MultipleWorkerThreads.

• SingleWorkerThread means computation is carried out in one single thread which is not the main (UI) thread. Only a small cross-thread-safe subset of the Ocean for


15

Petrel API is available, only the ‘reading’ part of the Domain API can be used. Any code path which changes data up in the GUI (forms) technology will throw an exception as it is considered an illegal cross thread operation.

• MultipleWorkerThreads means the calculate method is called in parallel on several threads (possibly one to four). The generator implementation must use only thread safe (.Net) components in its implementation, and cannot use any Ocean resources (like domain objects).

Persistence

• IAttributeVersion2 can optionally be persisted (if it is serializable). This will in effect make it a singleton and just its identity will be persisted. Any state should be persisted with the argument package. Note that it is recommended to implement your own serialization logic rather than using .NET Serialization. The generator of a IAttributeVersion2 is *not* persisted. This was mandatory with the old version.

Multi-Threading - Generic seismic bulk access Namespace: Slb.Ocean.Petrel.DomainObject.Seismic The IAsyncSubCube GetAsyncSubCube(…) method provides random asynchronous

read and write access to the data. The implementation is not thread safe, but multiple sub cubes can be processed in parallel in separate threads. The GetAsyncSubCube can only be called in the main thread, but the returned handle can be used in any thread. Instances of ISubCube must not be used in the main thread when there are active IAsyncSubCube instances. In the main thread:

IAsyncSubCube subCubeIn = cubeIn.GetAsyncSubCube(...);

IAsyncSubCube subCubeOut = cubeOut.GetAsyncSubCube(...);

In a worker thread: foreach (Index3 index in subCubeOut)

{

subCubeOut[index] = subCubeIn[index];

}

subCubeIn.Dispose();

subCubeOut.Dispose();


16

Seismic Domain

Fault (Ant Tracking) patches

Namespace: Ocean.Petrel.DomainObject.Seismic.FaultPatchSet FaultPatchSet represents a set of fault surfaces, whose geometry is a set of indexed triangles, with properties attached to each fault. A fault patch is an individual Fault in a FaultPatchSet object. This fault is usually computed from seismic data and requires a seismic survey definition on creation, vertices are snapped to the nearest index position.

Fracture patches

Namespace: Ocean.Petrel.DomainObject.Shapes.FractureNetwork FractureNetwork represents a Petrel fracture network with properties. Individual fractures are represented by the FracturePatch object, and can be accessed through FractureNetwork.FracturePatches and FractureNetwork.PatchAtIndex. A FracturePatch is an individual Fracture in a FractureNetwork object. The fracture can be expressed as a triangulated surface, through IndexedTriangleMesh.

Multiple input seismic attributes Namespace: Slb.Ocean.Petrel.SeismicAttribute.IAttribute Ocean for Petrel now supports multiple seismic input cubes. The API is unchanged, but now the Slb.Ocean.Petrel.SeismicAttribute.IAttribute.NumInputs

can be greater than 1.

Data Management

Reference project tool awareness and Copy/Paste of Custom domain objects Namespace: Slb.Ocean.Petrel.Basics.ICopyable Slb.Ocean.Petrel.Basics.ISyncable The API allows custom domain objects or extensions to native domain objects to do the roundtrip between an opened Petrel project and a reference project using the Reference Project Tool and to participate in copy-paste actions in Petrel, including cascading copies.

• ICopyable to handle duplication

• IPropertyComparable to provide object-to-object comparisons of e.g. identity or version

• IObservableElementCollection,

IObservableElementCollectionFactory,

IObservableElementEnumerable,

IObservableElementEnumerableFactory to allow handling of children items in a custom domain object

• Custom Extensions can be managed using the IO.AttributeContainer

IO.ICustomAttributeService


17

SurfaceAsIExtensionSource Namespace: Slb.Ocean.Petrel.DomainObject.Shapes RegularHeightFieldSurface implements IExtensionSource, so it can be extended with custom extensions.

WellMarkersIIdentifiable Namespace: Slb.Ocean.Petrel.DomainObject.Well.Marker Well markers are now IIdentifiable enabling data management solutions.

Data Fidelity: Attributes of Petrel Domain Objects The API now provides access to native (WellKnown) attributes – attributes with ”special meaning”. Each attribute is identifiable and String, Boolean and DateTime properties are now supported.

Surfaces/horizons Surface.GetWellKnownProperty()

Surface.Properties

WellKnownSurfacePropertyTypes.Velocity etc.

SurfaceProperty.IsGeometryProperty

HorizonProperty2D/3D.IsGeometryProperty

Point sets PointSet.Create/GetWellKnown[Dictionary]Property()

WellKnownPointSetPropertyTypes.DipAzimuth etc.

PointProperty.IsGeometryProperty

Boreholes BoreholePropertyCollection

Borehole.PropertyAccess.Get/SetPropertyValue()

WellKnownBoreholePropertyTypes.SpudDate etc.

Point well data General: WellPointPropertyCollection

Well markers Marker.PropertyAccess.Get/SetPropertyValue()

WellKnownMarkerPropertyTypes.Interpreter etc.

Checkshots WellKnownBoreholePropertyTypes.TWTPicked etc.

CheckShot.GetPropertyAccess()

Point well logs PointWellLog.GetPropertyAccess()

WellKnownPointWellLogPropertyTypes.MD etc.


18

UI and Look & Feel

Interaction Events Extension Namespace: Slb.Ocean.Petrel.UI.WindowMode Provides extensions in the interaction events to cater for keyboard events.

WindowMode.OnKeyDown()

WindowMode.OnKeyUp()

Toolbars and Tools associated with a Process Namespace: Slb.Ocean.Petrel.Workflow.Process,

Slb.Ocean.Petrel.UI.Tools.WellKnownTools The new ToolbarsCore and ToolsCore properties are called by the framework whenever it needs to know respectively the list of PetrelToolbars and PetrelTools associated with a Process. An implementation of this method typically returns different PetrelToolbar or PetrelTool configurations based on e.g. the active IToggleWindow.

UI.WellknownWindowModes

Process.Tool[bar]sCore

Process Insensitive Namespace: Slb.Ocean.Petrel.Workflow.Process Enables Ocean for Petrel processes to be set as disabled (grayed out) if e.g. a license can not be obtained or if the required input data isn’t present.

Process.Enabled = true/false

Process.EnabledChanged/OnEnabledChanged() event

Custom windows tree extensions for Petrel windows Namespace: Slb.Ocean.Petrel.Basics.IExtensionsSource Native Petrel window interfaces (IWindow3D, IMapWindow, IWellSectionWindow, IIntersectionWindow, IFunctionWindow) now extend Slb.Ocean.Petrel.Basics.IExtensionsSource, giving them an Extensions property. Like other native domain objects, this allows Ocean for Petrel applications to add and remove custom domain objects as children of the trees in the Petrel tree hierarchy.

AutoLegendProgrammaticShowHide Namespace: Slb.Ocean.Petrel.UI.IWindow3D Support for programmatically showing/hiding Petrel’s AutoLegend

bool IWindow3D.ShowAutoLegend


19

Cursor tracking independent of IToggleWindow, with proper domain handling Namespace: Slb.Ocean.Petrel.UI.IWorldCursor The new World Cursor API allows applications to participate in cursor tracking without explicitly needing to implement a custom toggle window. It allows listeners of cursor tracking events to determine the originating domain of the vertical coordinate through the DomainZ property.

UI.IWorldCursor

UI.WorldCursorEventArgs.DomainZ

UI.WorldCursorEventArgs.Position …

Petrel Task Manager Namespace: Slb.Ocean.Petrel The PetrelLogger.NewAsyncProgress(..) allows displaying progress of separate-threaded processes in the Petrel task manager.

using (IProgress pr = PetrelLogger.NewAsyncProgress(

"test", ProgressType.Cancelable))

{

for (int i = 0; i < 100; i++)

{

pr.ProgressStatus = i;

}

}

Launching Dialogs and Controlling Visual Content Namespace: Slb.Ocean.Petrel.UI Programmatically launch settings dialogs

UI.DialogBuilder.Show/HideSettings(obj,...)

UI.DialogBuilder.ActivateSettingsTab(obj,...)

Namespace: Slb.Ocean.Petrel.IO It is now possible to programmatically launch an import or export dialog.

IFileFormatCollection.ShowExportDialog(fmt,path,...)

IFileFormatCollection.ShowImportDialog(fmt,path,...)

Select active explorer tree Namespace: Slb.Ocean.Petrel.PetrelProject Gets or sets the active tree in Petrel explorer. PetrelProject.ActiveTree = PetrelProject.Models


20

Expand/collapse branches in the explorer trees Namespace: Slb.Ocean.Petrel.PetrelProject Enable programmatic expansion of data tree nodes PetrelProject.TreeOperations.SetExpanded(obj,

TreeElementState.Expanded)

Workflow editor folders Namespace: Slb.Ocean.Petrel.Workflow.IWorkflowEditor Provides a mechanism to place a workstep under a given workstep folder (in the workflow editor). IWorkflowEditor.Add(wkstp,wkstpGroup)

Provides a mechanism to add new folders for worksteps in the workflow editor Processes.FindOrCreateWorkstepGroup("My new folder")

Infragistics dependencies have been removed Namespace: Slb.Ocean.Petrel.PetrelSystem, Slb.Ocean.Petrel.UI.Tools.IToolService Infragistics dependencies have been removed from the Ocean for Petrel API. A new PetrelSystem.ToolService can be used to

• Create new toolbars/access native Petrel toolbars

• Create new menus/access native Petrel menus

• Register context menu handlers

• Add tools to toolbars, menus

Template Hierarchy Namespace: Slb.Ocean.Petrel.UI.DictionaryColorTableEntry The Slb.Ocean.Petrel.UI.DictionaryColorTableEntry class now has a Parent property to support hierarchies.

Retrieving Measurement for its name NameSpace: Ocean.Petrel.PetrelUnitSystem a new method has been added to get the measurement from a measurement name: public static IUnitMeasurement GetUnitMeasurement(string unitMeasurementName)


21

Other Development

• A document describing Module Deployment Best Practices has been released recently and is available from the Ocean Portal: Developer Center > Best Practices > Module Deployment.

• The Ocean for Petrel 2009.1 SDK now installs even if a previous version (Ocean for Petrel 2008.1 SDK) is installed. It allows keeping the documentation of previous Ocean for Petrel SDK releases.

• 64bits support: The Ocean for Petrel 2009.1 SDK supports Petrel 2009.1 x32 on Windows XP32 and XP64, and Petrel 2009.1 x64 on Windows Vista 64

• Ocean for Petrel Wizards The wizards now install on top of Visual Studio 2005 and Visual Studio 2008. It is now possible to create projects targeting Petrel 2008 or Petrel 2009 (if installed on the computer). The installer wizard allows choosing the targeted version of Petrel: Petrel 2008, Petrel 2009 x32 or Petrel 2009 64 bits (providing warnings in case of incompatibilities).


22


Although this is the release notes for Ocean for Petrel 2009.1, we include the summary of changes between versions 2008.1 for completeness. Ocean for Petrel 2008.1 was released in March 2008.

Domain API

Second generation Seismic Attributes The seismic attribute service keeps the stability promise by introducing a new interface IAttributeVersion2 which gives access to the new features. There are 'no' changes to the original API and behavior. Old implementations work as before. The interface IAttributeVersion2 inherits IAttribute. In order to start using the new service you can implement this new interface. This influences performance, threading, API access and persistence. Performance:

• The generator's Calculate method is now called with subcubes tailored to what is required to fulfill the user interaction that caused the computation. For example visualization of a horizontal slice triggers thin subcubes to be passed for calculation. The original IAttribute always got called with sub cubes of one seismic trace.

• IAttributeVersion2 uses a more optimized code path to provide improvement in computation speed of around an order of magnitude for simple algorithms. With complex algorithm the performance improvement might not be as noticeable.

• IAttributeVersion2 implementations with large computational footprints run faster because they are called fewer times than before (with larger subcubes).

Threading and Ocean API access:

• IAttributeVersion2 computes in one of two thread modes: SingleWorkerThread or MultipleWorkerThreads.

• SingleWorkerThread means computation is carried out in one single thread which is not the main (UI) thread. Only a small cross-thread-safe subset of the Ocean API is available, only the ‘reading’ part of the Domain API can be used. Any code path which changes data up in the GUI (forms) technology will throw an exception as it is considered an illegal cross thread operation.

• MultipleWorkerThreads means the calculate method is called in parallel on several threads (possibly one to four). The generator implementation must use only thread safe (.Net) components in its implementation, and cannot use any Ocean resources (like domain objects).


23

Persistence

• IAttributeVersion2 can optionally be persisted (if it is serializable). This will in effect make it a singleton and just its identity will be persisted. Any state should be persisted with the argument package. Note that it is recommended to implement your own serialization logic rather than using .NET Serialization. The generator of a IAttributeVersion2 is *not* persisted. This was mandatory with the old version.

Note that IAttributeVersion2 doesn’t support multiple seismic cubes. The original (but slower) IAttribute will have to be used in that case.

Geometrical Property Modeling Namespace: Slb.Ocean.Petrel.PropertyModeling An extension mechanism allows to extend the geometrical modeling process with new algorithms, behaving just like native Petrel algorithms.

Creation of Seismic Line 2D collection Namespace: Slb.Ocean.Petrel.DomainObject.Seismic Create a seismic line 2d collection from scratch.

Seismic SubFolder Awareness Namespace: Slb.Ocean.Petrel.DomainObject.Seismic.SurveyCollection Petrel Geophysics introduces user-defined folders in the seismic folder to organize seismic surveys. Ocean for Petrel exposes these folders to enable navigation programmatically through the structure of the data tree to all seismic data items. Warning of potential behavioral change: If your module had code to programmatically parse all seismic volumes in a project file, this code may not parse to the complete set of volumes anymore. You will need to update it to also parse through any sub-folders.

Seismic Logs Namespace: Slb.Ocean.Petrel.DomainObject.Well.BoreholeSeismogram Enable access to Seismic logs.


24

Programmatic Seismic Load Namespace: Slb.Ocean.Petrel.IO.ISegyFormat,

Slb.Ocean.Petrel.IO.IZgyFormat It is now possible to programmatically trigger load of seismic data (ZGY and SEG-Y). Note that the API doesn’t support the SEG-Y complex parameters: it addresses the "double-click" cases only, i.e. cases where Petrel is capable of loading the cubes without tweaking parameters related to where to find stuff in the SEG-Y trace headers, etc. It is the responsibility of the Ocean for Petrel module to ensure that the input is in a format recognized by the default Petrel loader. If this cannot be accomplished, the end-user may also adjust the parameters in the settings dialog, under "SEG-Y Settings", after loading the volume.

Seismic Origin Refactoring Namespace: Slb.Ocean.Petrel.DomainObject.Seismic.SeismicCollection Petrel 2008.1 changes the way seismic survey and cube origins are defined: in order to improve interoperability and reduce user confusion, the change is to always put the survey/cube origin in the corner with lowest annotation values. Warning of potential behavioral change: If you have built assumptions on relation between the I,J indices of seismic volumes and world locations, you may experience a change in behavior. It is not recommended practice to assume world locations for I,J. These indices should be considered of transient nature. Please do only make world location assumptions based on the X,Y and annotation indices of seismic data. Currently, the origin is only changed for an existing cube at project upgrade to version 2008.1. RegularHeightFieldSurface Performance Improvement Namespace: DomainObject.Shapes New Samples property. This property can be used to read & write samples in a bulk fashion. Performances using this method are much better than the random access through the IRegularHeightField interface. Domain Transformation Namespace: Slb.Ocean.Petrel.DomainObject.DomainConversion Enables conversion of custom domain objects between domains.

Pillar Grid Geometry Updates Namespace: Slb.Ocean.Petrel.DomainObject.PillarGrid.Grid Support for Pillar grid has be extended to allow creation of new Horizon, Contact Set, Segments and Zones.


25

Eclipse Format Simulator Namespace: Slb.Ocean.Petrel.Simulation.EclipseFormatSimulator Plugin API for 3rd party ECLIPSE-compatible simulators

Steamline Folder Create Namespace: Slb.Ocean.Petrel.DomainObject.Simulation.Streamline Allows to create Streamline top-level folder in Petrel

Fluid Function and Saturation Function Domain Object Namespace: Slb.Ocean.Petrel.DomainObject.Simulation The BlackOil domain object has GasPhase, OilPhase, WaterPhase and a collection of InitialConditions. The FluidFunctionCollection domain object contains BlackOils but can also contain other FluidFunctionCollection instances (sub-folders). The Saturation Function domain object holds data regarding Relative Permeability curves and Capillary Pressure curves.

Hierarchical Fault Properties Namespace: Slb.Ocean.Petrel.DomainObject.PillarGrid

Grid.FaultPropertyVersionCollection represents a fault property subfolder (can be nested) under the Fault/FaultProperties folder of a PillarGrid.Grid.

Performance Improvement for Well Log Bulk data Namespace: Slb.Ocean.Petrel.DomainObject.Well Ocean for Petrel well log bulk data access performances have been optimized

Well Log Sample Index at MD Namespace: Slb.Ocean.Petrel.DomainObject.Well Provides an API to get the index at a given depth for CheckShot, DictionaryWellLog, MultitraceWellLog, PointWellLog and WellLog. Reverse direction is not needed as XxxLog[int index] returns a XxxLogSample.MD;


26

Trimesh Domain Object Namespace: Slb.Ocean.Petrel.DomainObject.Shapes.TriangleMesh

Slb.Ocean.Petrel.DomainObject.DomainObjectExtensionRoot The TriangleMesh domain object represents a 3D triangle mesh geometry in space. TriangleMesh are created from DomainObjectExtensionRoot. The DomainObjectExtensionRoot convenience class provides creation of and navigation to root type extension domain objects, as well as event notification about creation or deletion of such types. The API of this domain object may be changed or extended in future releases (marked as Subject to Change).

IDeletable Interface Custom domain objects can offer the IDeletable interface. IDeletable is a service located feature via IDeletableFactory. Petrel responds to a IDeletable.Deleted event by removing the Object from the Petrel tree, but the object is deleted by calling Delete(). IDeletable.Delete() is called by Petrel if the domain object is deleted from GUI. Domain objects offering this interface can be deleted by the end-user.

Serialization Service Namespace: Slb.Ocean.Petrel.Data SerializationService allows Serialization binders to be registered with the .NET formatter used by Ocean for Petrel internally to binary serialize and de-serialize custom data into and from a Petrel project. These serialization binders are in charge of de-serializing the data for one type by coercing it into an instance of another type, providing a mechanism to handle de-serialization of data binary serialized with a previous version of a custom domain object. Although tagging your classes [Serializable] allows easily saving data in a Petrel project, it becomes difficult to scale when planning more than one version of a plug-in or targeting more than one version of Petrel. It is therefore recommended to implement your own data source. Note that the SerializationService provides a workaround for an issue with the .NET BinaryFormatter preventing to de-serialize a custom domain object containing a generic collection of a serializable type: https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=119402&wa=wsignin1.0 For example an exception will be raised while reloading in 2008.1, from a project saved with Petrel 2007.2, a domain object tagged as [serializable] and containing a System.Collections.Generic.List<Droid> member.

To avoid this issue, a new class needs to be created in the plug-in: public class DroidListSerializationBinder :

System.Runtime.Serialization.SerializationBinder

{

public override Type BindToType( string assemblyName,

string typeName)

{

if (typeName.Equals(

"System.Collections.Generic.List`1[[


27

Slb.Ocean.Core.Droid, Slb.Ocean.Core,

Version=3.2007.2.0,

Culture=neutral,

PublicKeyToken=14ef4a483ef6a64b]]"))

return typeof(

System.Collections.Generic.List<Slb.Ocean.Core.Droid>);

return null;

}

}

Then an instance of this class needs to be registered with the serialization service during the integrate-step of the module: public class MyModule : IModule

{

public void Integrate()

{

PetrelSystem.ProjectSerializationService.AddSerializationBinder(

new DroidListSerializationBinder ());

}

...

}


28

UI Infrastructure

IIntersection3DRenderer Namespace: Slb.Ocean.Petrel.UI.IIntersection3DRenderer

Slb.Ocean.Petrel.UI. IIntersection3DPicking Enables the framework to render or draw a visual representation of a custom domain object with relation to an intersection plane in a 3D window.

Tree State Persistence for Custom Domain Objects Namespace: Slb.Ocean.Petrel.UI.ITreeOperations State of Custom Domain Object in data tree is now persisted.

Petrel Tree Switch Launching of an Ocean for Petrel module doesn’t cause the Petrel explorer tree to switch.

ColorTable Definition Namespace: Slb.Ocean.Petrel.UI.IColorTable Programmatic reading and writing of colors and opacity values is now available for color table definitions that use continuous templates (color tables for dictionary templates was supported in previous versions). For custom domain objects with a continuous color table, the ‘Colors’ tab in the Petrel Settings dialog now includes the opacity curve.

Remember that beginning in 2007.2, a custom domain object has a continuous color table, and consequently a ‘Colors’ tab in the Petrel Settings dialog, when it supports IPropertySettingsInfo or IDomainSettingsInfo. If a custom domain object supports IPropertySettingsInfo, then the color table is based on the IPropertySettingsInfo.CurrentTemplate property. If a custom domain object supports IDomainSettingsInfo and not IPropertySettingsInfo, then the color table is based on the IDomainSettingsInfo.CurrentDomain property.

Also new in 2008.1 is the support of private color tables for those custom domain objects that implement IIdentifiable.

DistinguishOpenVsClosedWindows Namespace: Slb.Ocean.Petrel.UI.IWindowManager Allows to Hide(),Show() or check if IsVisible() a specified IToggleWindow.


29

Borehole Style Attribute API The subject-to-change borehole style attribute (i.e. rendering attributes of boreholdes) API are cleaned up for consistency. A summary of the API changes are:

• IStyleFactory replaces IBoreholeStyleFactory. The IBoreholeStyleFactory API is deleted.

• The IBoreholeStyle.ValidLineWidths() method is replaced by the IBoreholeStyle.ValidLineWidths property. Details are:

o The valid values are now returned in an IEnumerable structure instead of an IList.

o The returned values themselves are now integers instead of Slb.Ocean.Petrel.UI.Style.LineWidth enumeration values.

o The Slb.Ocean.Petrel.UI.Style.LineWidth enumeration API is deleted.

• The IBoreholeStyle.ValidStyles() method is replaced by the IBoreholeStyle.ValidLineTypes property. Details are:

o The valid values are now returned in an IEnumerable structure instead of an IList.

o The returned values themselves are now Slb.Ocean.Petrel.UI.Style.LineType enumeration values instead of Slb.Ocean.Petrel.UI.Style.LineStyle enumeration values.

o The Slb.Ocean.Petrel.UI.Style.LineStyle enumeration API is deleted.

• The IBoreholeStyle API now inherits from the IStyle API. Details are: o The IBoreholeStyle.Borehole property is deleted and is replaced by the

IStyle.DomainObject property. o The IBoreholeStyle.Window property is deleted and is replaced by the

IStyle.Window property.

• The IBoreholeStyle.LineWidth property now gets and sets an integer value instead of a Slb.Ocean.Petrel.UI.Style.LineWidth enumeration value. The Slb.Ocean.Petrel.UI.Style.LineWidth enumeration API is deleted.

• The IBoreholeStyle.Style property is deleted and is replaced by the IBoreholeStyle.LineType property. Details are:

o The Slb.Ocean.Petrel.UI.Style.LineStyle enumeration is deleted and is replaced by the Slb.Ocean.Petrel.UI.Style.LineType enumeration.

o The new IBoreholeStyle.LineType property gets and sets Slb.Ocean.Petrel.UI.Style.LineType enumeration values.

The two validation methods are added IBoreholeStyle.IsValidLineType(LineType value), and IBoreholeStyle.IsValidLineWidth(int value).


30

Installation and Un-installation

To improve the Petrel awareness of plug-ins installed we have developed new Ocean for Petrel plug-in install and uninstall procedures. This is mainly to help the Petrel and plug-ins un-installation. When a plug-in is installed on top of Petrel it registers itself to inform Petrel it exists, then as Petrel knows which plug-ins are installed on top of itself it can, when it is uninstalled, selectively un-install (or not) these plug-ins. When Petrel is uninstalled it checks if plug-ins are installed and asks the user if and which plug-ins need to be un-installed. In case the user wants to uninstall plug-ins the Petrel uninstaller gets the list of registered plug-ins for Petrel and asks the user which registered plug-ins should be uninstalled. It then launches successively the uninstaller of all selected plug-ins (using the option to not check for dependencies). Petrel un-installation needs to be restarted manually then

31

Known Issues in Ocean for Petrel 2009.1

Visual Studio Express does not support any Visual Studio plug-ins. This means that the Ocean for Petrel Plug-in to Visual Studio (also referred to as the Ocean Wizard) will not work with Visual Studio Express.

When Windows Vista UAC (User Access Control) is turned on, the Ocean Wizards in Visual Studio don’t install properly if the installer is not run as Administrator. On Windows Vista, be sure to explicitly run the Ocean for Petrel SDK installer as administrator: right click the SDK installer and select “Run as Administrator”.

Wrongful entries in the Petrel.exe.config file may cause unsolicited behavior. In order to safeguard against this, please use the module registration utility RegisterModule.exe

when registering or un-registering modules in this configuration file. We strongly recommend any installers created by applications to also use this utility.

Also, please make sure that ‘your’ uninstaller handles the condition that Petrel has been uninstalled before ‘your’ module is uninstalled. Specifically this means that RegisterModule.exe and RegisterPlugin.exe are no longer available.

Due to conflicts of registration of RegisterPlugin.exe between Petrel 2008.1, Petrel 2009.1 and mixed 32 and 64 bits environment, Petrel 2009.1 doesn’t register this COM interface anymore: Do NOT use the COM interface of RegisterPlugin.exe. The COM interface will be deprecated in a further version. Please use the command line interface or the .NET interface to register and unregister your plug-ins and let Petrel know they exist. It allows them to be un-installed when Petrel is itself uninstalled.

Please note that Ocean Services delivers a new Coordinates Service. It comes with Mentor and ESRI engines implementations. However, in Petrel 2009.1 only the Mentor engine in available because there is no ESRI engine available for 64 bits.

The current design of the IAsyncSubCube interface doesn’t flush changes written to an async subcube until all async subcubes instances are disposed: working with subcubes covering large parts of a cube caches these large parts in a low layer of Petrel and are actually released only after all instances are disposed. This can potentially lead to out of memory problems. The workaround is to make sure that only a “reasonable” amount of subcubes are created and disposed at the same time.

32

Foreseen changes in Ocean for Petrel 2010.1

The organization of simulated 3D reservoir properties might change in 2010.1. Properties from simulations may move to the results tree, adopting the navigation pattern of the results tree. Ocean for Petrel API will be updated with new functions for navigating to these properties. Calculator features will also make it possible to copy these properties “back” to the models tree. Nevertheless, if your plug-in and workflow require access to simulated properties, some changes to either your plug-in or workflow will have to be implemented. Hence this early warning.

Known behavioral differences between Ocean for Petrel 2009.1 and 2008.1

33

Known behavioral differences between Ocean

for Petrel 2009.1 and 2008.1

• There are two Petrel 2009.1 installers, one for the 32bits version and one for the 64bits versions. Note that it is two different products: they have their own product code:

o Petrel 2009.1 x32 = {E74EFDC6-2423-4CBB-A107-7A6D1538D990} o Petrel 2009.1 x64 = {6FA7870D-3DEA-43D1-BD4C-E3F23DD8F799}

For info, Petrel 2008.1 x32 = {4959CDAB-1A21-4CB7-B753-6ABAD3FFB11C} Petrel product codes remain the same for patches, but change for major version.

• When Petrel 2009.1 installs (32 or 64bits) it creates the OCEAN2009HOME environment variable. Petrel 2009.1 32bits creates an additional OCEAN2009HOME_WIN32 environment variable, while Petrel 2009.1 64 bits creates the OCEAN2009HOME_x64 environment variable. These variables contain the root installation folder of Petrel. These variables are deleted when Petrel is uninstalled.

• As mentioned earlier, Petrel 2009.1 doesn’t register RegisterPlugin.exe COM interface anymore: Do NOT use the COM interface of RegisterPlugin.exe, but use the command line interface or the .NET interface to register and unregister your plug-ins. RegisterPlugin.exe is now installed in Petrel root folder. It can’t be used anymore to query which versions of Petrel are installed and where they are installed: please use the environment variables mentioned above for that purpose.

• Active interpretation is obsolete, and will be removed in next version of Petrel (2010). Horizon interpretation in the current Petrel release can be active at 2 levels, the horizon itself which spans multiple surveys, and the interpretation representing the interpretation for a specific survey. It is the active state of the survey specific interpretation which is obsolete/deprecated. Note that active interpretation being obsolete/deprecated applies to both 2d and 3d interpretations.

• A new assembly, Slb.Ocean.Petrel.Basics, has been introduced to contain classes and interfaces used in different assemblies. The DeletableInfo class, the IDeletable Interface and IDeletableFactory interfaces previously in Slb.Ocean.Petrel have been moved to this new assembly.

• In Ocean for Petrel 2009.1, when an unhandled exception raised from a plug-in is caught by the Ocean for Petrel framework, a message is shown in the Petrel message log window to inform the end users that something went wrong. All details are written in the OceanPetrel.log file. In Ocean for Petrel 2008.1, details were written in the log file, but the end users was never informed that something went wrong in one of his plug-in.

If an unhandled exception is raised by Petrel, .NET or Windows through a plug-in and not caught by the Ocean for Petrel framework, then Petrel crashes, generates a


34

dump file, and uses the Windows Error Reporting to send this dump file to a Microsoft server from where the Petrel support team can analyze it.

• INotifyingEnumerableFactory is made obsolete and is replaced by IElementCollectionFactory. Please use this new interface. Note that IElementCollection replaces INotifyingEnumerable.

• TrajectoryRecord and ExplicitTrajectoryRecord no longer accept Nan, Min, Max or Infinity values for Md, Azimuth and Inclination. The method GetLogInCells marked as subject to change in the MultitraceWellLog class has been removed. As a result the LogInCell class has been removed too. Please use instead the more sophisticated: Slb.Ocean.Petrel.DomainObject.PillarGrid.IPillarGridIntersectionService.

• The SetRecordValues methods on the {Dictionary}PointProperty and {Dictionary}SurfaceProperty (Slb.Ocean.Petrel.DomainObject.Shapes) have been changed to support data types other than double & int. The methods are now generic.

• The DropTarget class (Slb.Ocean.Petrel.UI) has been improved such that the requested type can be specified in the GetData() method. This is useful for the case that the Petrel object maps to multiple Ocean object types. E.g. if a Petrel continuous template is dropped, then until now you could only get the PropertyVersion for it as follow:

DropTarget t = ...; t.GetData(typeof(object)) as PropertyVersion

Now you can get both the ITemplate and the PropertyVersion: DropTarget t = ...; ITemplate templ = t.GetData(typeof(ITemplate)) as ITemplate;

PropertyVersion pv = t.GetData(typeof(PropertyVersion)) as PropertyVersion;

• The unitServiceSettingsType information is not needed anymore in the petrel.exe.config file. If you want to reuse your previous config file, you need to remove the line:

<add key="unitServiceSettingsType"

value="Slb.Ocean.Petrel.Internal.Units.UnitServiceSettingsImpl,

Slb.Ocean.Petrel.InternalM, Version=4.10.0.0, Culture=neutral,

PublicKeyToken=14ef4a483ef6a64b" />

• Petrel 2009.1 uses the new Extensible Unit Service to create and use its own unit catalog that extends the OSDD (Oilfield Services Data Dictionary) reference catalog with new custom units and measurements. In previous versions, the only one possible unit catalog – the OSDD reference catalog –was routinely located as follows:

// *Usually* incorrect way to locate the unit catalog

IUnitCatalog cat = CoreSystem.GetService<IUnitService>().GetCatalog("OSDD");

Or IUnitCatalog cat = CoreSystem.GetService<IUnitService>().GetCatalog(null);

Such code needs to be changed to ensure it accesses the content of the new extended Petrel catalog rather than the default OSDD Catalog. Petrel sets this new


35

catalog as the value of the CurrentCatalog property on its own implementation of the Unit Service Settings Service.

To work with the same Petrel unit catalog, plug-ins must locate the unit catalog

through the IUnitServiceSettings service as follows: // Correct way to locate the unit catalog

IUnitCatalog cat =

CoreSystem.GetService<IUnitServiceSettings>().CurrentCatalog;

• CheckShot and PointWellLog domain objects have a new property API replacing previous properties and methods that have been marked obsolete. Use CheckShot.GetPropertyAccess and PointWellLog.GetPropertyAccess to get or set the property values.

• The IColorTable now always supports value ranges as data values (see SMR 2330544). Previously, the IColorTable.ValueRange was always (-1, 1) when the color table had an automatic minimum and maximum. The plug-in then had to do a mapping between the data range and (-1, 1) before calling the IColorTable. Now, the IColorTable.ValueRange are always data values and the plug-in should no longer do this mapping before calling the IColorTable.

• The Slb.Ocean.Petrel.DomainObject.IExtensionsSource and

Slb.Ocean.Petrel.DomainObject.IExtensions interfaces have been marked

obsolete, and this functionality has moved to the Slb.Ocean.Basics namespace. This may cause some confusion when accessing the Extensions property of various domain objects (Borehole, Project, Grid, etc), because you must now explicitly cast

these objects to the new interface type in order to access their updated Extensions properties.

Overwriting the existing Extensions properties to return the new interface type would be a breaking change, so this means supporting both interfaces until the Obsolete period is over and we can go back to just having one (the

Slb.Ocean.Basics version). In the meantime, this casting is necessary to access the property on the new interface.

As an example, the following line would result in a compiler warning that the

Extensions property is obsolete: myBorehole.Extensions.Add(newObj);

For the time being, the correct usage would be:

((Slb.Ocean.Petrel.Basics.IExtensionsSource)myBorehole).Extensions.Add(newObj);

In the event that implementations do not move to Basics.IExtensionSource, they must explicitly implement the Extensions property with the new return type. For example:

// Excerpt of Slb.Ocean.Petrel.DomainObject.IExtensionsSource implementation

public Slb.Ocean.Petrel.DomainObject.IExtensions Extensions

{

get

{

// (Existing implementation)

}

}

public Slb.Ocean.Petrel.Basics.IExtensions

Slb.Ocean.Petrel.Basics.IExtensionsSource.Extensions

{

get


36

{

return Extensions as Slb.Ocean.Petrel.Basics.IExtensions;

}

}

// End of Excerpt

• Petrel will no longer use the concept of active object (boldface in the tree) for interpretation Therefore the PetrelSystem.ActiveObjectService.GetActiveObject() will stop returning any active object for the subject in question. The return value will be corresponding to no active object, i.e. return a null pointer.

• Note that a new Coordinates Service is available in Petrel 2009.and allows implementing multiple “engines” to manage Coordinate reference systems, Transforms and Conversion. The current CoordinateSystems service is not yet marked as Obsolete in Ocean for Petrel 2009, but will be in Ocean for Petrel 2010. It is recommended to start moving to the new Coordinates service.

Here is an example of how to use the new service: ReturnStatus status; ICoordinateService CoordService =

CoreSystem.GetService<ICoordinateService>(); ICoordinateReferenceSystem CoordinateSystemA;

ICoordinateReferenceSystem CoordinateSystemB;

status = CoordService.GetCoordinateReferenceSystem("MENTOR:UTM84-31N",

out CoordinateSystemA);

status = CoordService.GetCoordinateReferenceSystem("MENTOR:UTM84-32N",

out CoordinateSystemB);

ICoordinateOperation converter;

status = CoordService.CreateOperation(cs1, cs2, PrePostUnitConversions.None,

out converter);

Point3 wellHead = new Point3(xRef, yRef, zRef);

status = converter.Convert(ref wellHead);

And for distortion correction usage:

IProjectionDistortionCorrector corrector;

status = CoordService.CreateOperationCorrector(converter, corrector);

double scaleFactor;

Angle gridConvergence;

status = corrector.Convert(wellHead, ref scaleFactor, ref gridConvergence);

• In previous versions of Ocean for Petrel setting borehole trajectories was adding “gratuitously“ additional interpolated samples. With Ocean for Petrel 2009.1, the trajectory will contain only the points explicitly added. Rendering of these trajectories will be different in 2009.1 as they are not smoothed anymore by the added interpolated points.

37

Tutorial: The EclipseFormatSimulator API

Introduction

This document details how an Ocean client may integrate a plug-in simulator with Petrel. This is a detailed technical guide. The client will use the Slb.Ocean.Petrel.Simulation.EclipseFormatSimulator class. It is expected that an EclipseFormatSimulator will be able to accept input in an ECLIPSE format and to output results in an ECLIPSE format.

Petrel Simulation Overview In Petrel a simulation run is controlled by the ‘Define Simulation Case’ process. In the ‘Define Simulation Case’ dialog a Petrel user can create a Case and specify associated options. They can then run that Case which involves exporting an ‘ECLIPSE deck’ (writing the ECLIPSE input files to disk), running that simulator, writing the results to disk, and Petrel importing those results. The steps are:

1. User defines Case

2. ECLIPSE deck is exported

3. Simulator is run and uses this ECLIPSE deck as input

4. Simulator writes results

5. Petrel imports those results

For a Petrel project and a given Case, the ECLIPSE deck is exported to a directory on the hard disk of the PC. The name of this directory will be of the form: PetrelProjectDirectory\PetrelProjectName.sim\CASENAME_SIMULATORNAME The exported files in this directory will also be of the form CASENAME_SIMULATORNAME.ext Please note that in the directory and filenames that the Case name and the Simulator name are forced into uppercase. Results for the simulation run should also be written into the same directory.


38

An EclipseFormatSimulator simulation run overview For a plug-in simulator there are a number of extra steps involved in a simulation run:

1. User defines Case

2. ECLIPSE deck is exported

3. Plug-in simulator is given chance to modify or translate this deck for their own

purposes (PostExport() event).

4. Plug-in simulator PreRun() event occurs.

5. Plug-in simulator is run (SubmitCommand is executed).

6. Plug-in simulator run completes (the process from the SubmitCommand is

determined to have ended).

7. Plug-in Simulator’s PreImport() event is called prior to Petrel importing the results.

This allows the simulator to put the results in the correct format for Petrel.

8. Petrel imports those results.

Note that it is possible to set up a simulation run such that results are checked for ‘every n minutes’. In this scenario steps 7 and 8 above would happen multiple times before the simulation run has completed (step 6).

Integrating a Simulator

Integrating an EclipseFormatSimulator into Petrel consists of the following steps:

1. Derive a class from EclipseFormatSimulator

2. Implement the various methods and properties on EclipseFormatSimulator that relate

to your simulator.

3. Add your simulator into Petrel using the ISimulationManager.AddSimulator()

method.


39

Implementing an EclipseFormatSimulator The ‘Define Simulation Case’ dialog is shown below.

Note that clicking the ‘Run’ button both exports the ECLIPSE deck and runs the simulation. A view of participating classes is show below.


40

Abstract methods and properties When you derive a class from EclipseFormatSimulator you will need to implement the following methods and properties:

public override string Name

This is the name of the simulator that will be used in the display of the ‘Define Simulation Case’ dialog. Please note that this name is used as a unique identifier. Certain restrictions are placed on the valid characters for Name (as it will ultimately be used to form part of a directory name). Also, although no restrictions are places on mixing of case in the characters used, as the name is forced into uppercase when producing the output directory, only one of say SiMuLaToR, simulator or SIMULATOR would be allowed as a Name (the first entry being the one that would be accepted).

public override string SubmitCommand

Petrel expects to execute a command line style string to run the simulator. This string should be supplied here. Please note that Petrel also monitors the ‘life’ of the simulator by monitoring the Process Id of this process i.e. when the process associated with the submit command expires, the simulation run is assumed by Petrel to have finished. It is not necessary that the executable supplied in this SubmitCommand be the plug-in simulator itself. Rather it could be an executable that could say carry out some prerequisite tasks, run the simulator, and then perhaps carry out some tidy up. However the principle remains that Petrel will assume that the simulation run is complete when the process associated with this command has ended. You must fill in this Submit command, if you do not, then the process associated with it will end instantly and Petrel will assume the simulation run has finished, even though no work would have been carried out at that point.

public override string FetchCommand

The fetch command is a similar concept to the SubmitCommand. However, the FetchCommand only applies to simulation runs on remote machines. This is a command line style string that Petrel expects to execute to tell your simulator to fetch results from the remote machine and bring them back locally. The fetch command is not used nor required for local simulation runs as for such a run the simulator is expected to place its output directly into the sim folder of the project. If your simulation is running locally then this can be left as an empty string.

public override string KillCommand

The kill command is a similar concept to the SubmitCommand. However, the KillCommand only applies to simulation runs on remote machines.


41

This is a command line style string that Petrel expects to execute to tell your simulator to kill or end the remote simulation run. The kill command is not used nor required for local simulation runs as for such a run Petrel will directly terminate the running operating system process which was started by issuing the submit command. If your simulation is running locally then this can be left as an empty string.

public override bool SupportsDualPorosity

public override bool SupportsDualPermeability

public override bool SupportsStreamlines

These properties should return boolean values indicating if your plug-in simulator supports dual porosity, dual permeability or streamlines. These values control the options displayed by the Petrel ‘Define Simulation Case’ dialog.

Single porosity is the default where each cell has a permeability and models fluid movement through the cell. Dual porosity is for a fractured reservoir. As the fractures provide a path of choice for fluids, the dual porosity simulator will split each cell into two parts. Each part will have a different porosity, one for the rock matrix and one for the fractures. The fluid can migrate from the matrix cell to the fracture cell and only fracture cells can communicate between each other. Dual permeability is similar to dual porosity, but in dual permeability, fluid movement is allowed between matrix cells.

public override EclipseFormatSimulator.EclipseDeck ExportDeckAs

This property stipulates what kind of ECLIPSE deck that your simulator is expecting to use as input. The options are:

• Eclipse100 – an ECLIPSE 100 deck

• Eclipse300 – an ECLIPSE 300 deck

• FrontSim – a FrontSim deck The specified value will be used when exporting the ECLIPSE deck. ECLIPSE 100 is the traditional black oil simulator, simple fluid model, and three phases: water, oil, and gas. Decks built for ECLIPSE 100 are well known in the industry and the keywords used in the deck are recognized by many simulators. ECLIPSE 300 is the black oil or compositional simulator. It solves cubic equations of state throughout the reservoir and requires more keywords. FrontSim is a streamline simulator. It also uses equations of state from ECLIPSE 300.


42

The plug-in simulator selects one of the three possible deck formats. There is no feedback to the user that this has been selected, but it will affect Petrel’s output. public override EclipseFormatSimulator.GridFormats SupportedGridFormats

You should return the grid formats that your simulator supports. These are specified as bit flags and can thus be combined. The options are:

• GRIDECL

• GRID

• EGRID

• GSG

• RESCUE

• OPF

ECLIPSE formats EGRID or GRDECL are used for ECLIPSE runs. The limitation of these formats is that they can only handle vertical or straight pillars. EGRID is the binary version of the format. GRID is the corner point grid definition used in old ECLIPSE versions. It is kept in the list for simulators compatible with earlier ECLIPSE releases. GSG is the new format used to describe grids for ECLIPSE 100 and ECLIPSE 300. It is used for versions newer than ECLIPSE 2008.1. RESCUE is a widely accepted, vendor independent format standard for corner point grid description, published by POSC (Petrotechnical Open Standards Consortium). OPF is the Open Petrel Binary format, a private format that has been provided to the client to precisely describe the Petrel pillar grid. It is currently not supported and is kept as a legacy format. These values appear in the ‘Select grid export type’ drop down list in the ‘Advanced’ tab (under the ‘Advance grid’ sub tab).

Useful Events Your derived simulator class may override the following virtual methods. These methods will be called to indicate specific events in the simulation run.

public override void PostExport(Case theCase)

The PostExport() method is called on your derived simulator class when the ECLIPSE deck for theCase has been exported.


43

This is the opportune moment to carry out translation of the ECLIPSE deck (should you so desire) or to modify the deck. Please note that the ‘Define Simulation Case’ dialog provides an ‘Export’ button. If the user clicks this, then the deck is only exported and the simulation is not run at this point. In this scenario the PostExport() method would still be called.

public override void PreRun()

This method is called immediately before your simulator’s SubmitCommand is executed by Petrel. This provides an opportunity to prepare for the simulation run.

public override void PreImport(Case theCase)

This method is called prior to Petrel importing the results that were output by your simulator. This is the opportune moment to format the results in an ECLIPSE format such that Petrel can load them. Note that if a simulation run was defined to check for results ‘every n minutes’ then this method could be called multiple times before the simulation run completes.

Hiding of built in tabs You may control whether certain of the built in tabs on the ‘Define Simulation Case’ dialog are shown when your simulator is selected.

public override bool UsesDevelopmentStrategies

public override bool UsesResults

public override bool UsesFunctionTables

These properties control whether the ‘Strategies’, ‘Results’ and ‘Functions’ tabs are displayed when your simulator is selected. If the contents of these tabs have no relevance to your simulator then you should hide them. Please note that the validation functionality ‘behind’ these tabs will be turned off if those tabs are hidden. This means that it is still possible to export an ECLIPSE deck that contains warnings/errors that your simulator may not be able to use.

Controlling what parts of the ECLIPSE deck are exported You may select which parts of the ECLIPSE deck you wish to export. This may have some bearing if you have disabled tabs as in section 2.4 above. You may implement the RequestedExportSections property to do this.

public override EclipseFormatSimulator.ExportSections RequestedExportSections

You should return which sections of the deck you are interested in having exported into the ECLIPSE deck. These are specified as bit flags that you may combine.


44

The options are:

• EDIT

• PROPS

• REGIONS

• SOLUTION

• SUMMARY

• SCHEDULE

Note that the default is to export all sections.

Adding your simulator into Petrel To expose the new simulator class to Petrel, it has to be added via Petrel’s ISimulationManager service registered in the Ocean core. This can be done at any time, but only once per plug-in simulator class during the whole Petrel session, and not once per project session. It is therefore natural to add the plug-in simulator in the Module Integrate method when Petrel services are available. ISimulationManager SimService = PetrelSystem.SimulationManager;

SimService.AddSimulator(new MySimulator);

Saving of projects and matching up of simulators

Your definition for your plug-in simulator can only be added when Petrel is running. Should you run a simulation with your EclipseFormatSimulator and save this project then data relating to that simulation run will be saved. If you later open that project (in a different session of Petrel) then Petrel will not know about your EclipseFormatSimulator until its definition is added using the ISimulationManager service as described in 2.6. Thus you will be required to add that simulator each time Petrel runs. If we consider the scenario where you have added an EclipseFormatSimulator called ‘MySimulator’ , ran a simulation and saved the project. Then when Petrel is restarted the definition that you provide for ‘MySimulator’ should match those that you provided previously. Providing mismatched definitions may lead to unpredictable results. The onus is placed squarely on the client to do this correctly.


45

Example:Integrating FrontSim as a plug-in Simulator

The code shown below essentially allows the FrontSim simulator to be added to Petrel as a plug-in simulator. class PluginSim_FrontSIMClone : EclipseFormatSimulator

{

public override string Name

{

get

{

return "FrontSIMClone";

}

}

public override string SubmitCommand

{

get

{

return "eclrun.exe [-v %VERSION%] [-s %SERVER%] [-q %QUEUE%] [-d %DIRECTORY%]

[-m %HOSTFILE%] [-c %COMMS%] [--username %USERID%] [--passwd %PASSWORD%]

frontsim %DATAFILE%";

}

}

public override string FetchCommand

{

get

{

return "eclrun.exe [--passwd %PASSWORD%] check %DATAFILE%";

}

}

public override string KillCommand

{

get

{

return "eclrun.exe [--passwd %PASSWORD%] kill %DATAFILE%";

}

}

public override bool SupportsDualPorosity

{

get

{

return true;

}

}

public override bool SupportsDualPermeability

{

get

{

return false;

}

}


46

public override bool SupportsStreamlines

{

get

{

return true;

}

}

public override EclipseDeck ExportDeckAs

{

get

{

return EclipseFormatSimulator.EclipseDeck.FrontSim;

}

}

public override GridFormats SupportedGridFormats

{

get

{

GridFormats Format = EclipseFormatSimulator.GridFormats.GRDECL |

EclipseFormatSimulator.GridFormats.OPF;

return Format;

}

}

}


47

Adding Your own Custom Tabs

You may define extra tab pages that will appear on the ‘Define Simulation Case’ dialog. These are intended to be custom tab pages related to your plug-in simulator. In order to add an extra tab page you must define an Argument Package in a similar manner that is used for Worksteps. An argument package is essentially a property bag. The properties in your argument package should relate to the settings you wish to be displayed on your custom tab page. By using an argument package serialization of data will be handled for you by Ocean (assuming you mark your argument package as being [Serializable] or you make it implement IIdentifiable). Note that a warning will appear in the debug window if your argument package is not serializable – this will of course only happen during development time.

Setting tab title and icon The title of the additional tab and its icon are set by the client implementing the IPresentation interface on their SimulatorPageLogic derived class. The IPresentation::Text property will supply the title of the page and the IPresentation::Image property will supply the bitmap for the tab. Here the title has been set to ‘Extra tab 1’ and the SystemIcons.WinLogo icon supplied.

Using the IPresentation mechanism means that if the client does not implement IPresentation then defaults will be used. This will be the name of the class and the Ocean bubbles icon.


48

Providing the control The client will derive a class from SimulatorPageLogic<TArgPack> . This is an argument package. The client can choose to provide a Control that will be hosted on the page or if they do not provide one a default table will be created from this argument package (similar to workstep). An example of the default control is shown below:

To provide a custom control the client needs to provide a factory for creating their custom control by deriving from SimulatorPageUIFactory<TArgPack> .

The SimulatorPageUIFactory<TArgPack> class In order to provide a custom control for their tab page the client must implement a SimulatorPageUIFactory<TArgPack> class that corresponds to their TArgPack. The SimulatorPageUIFactory<TArgPack> class has the following methods:

protected abstract Control CreateUI(TArgPack argumentPackage);

Here the client will create and return their custom control.

The client of course must also implement the custom control that is returned by CreateUI.

Registering the SimulatorPageUIFactory<TArgPack> factory The factory that was defined in 5.3 must be associated with the corresponding argument package. This should be done in Module::Integrate() .

CoreSystem.Services.AddService( typeof(MyArgPack),

MySimulatorPageFactory.ServiceType,

new MySimulatorPageFactory ());

Here the factory MySimulatorPageFactory<MyArgPack> is being associated with MyArgPack. When your plug-in simulator is selected from the ‘Define Simulation Case’ dialog, the factory will be used to create the custom control for the tab page.


49

Validate

protected virtual bool Validate( out IEnumerable<string> warnings,

out IEnumerable<string> errors)

In the Validate() method the client will return a boolean value to indicate if their additional tab page can be validated. This obviously depends on what parameter values have been set on the additional tab control by the user. Validate() will be called when the associated simulator is first selected in the Define Simulation Case dialog, when any changes occur on the dialog (other that within the additional tab itself), when the apply or OK button is pressed, and when an export occurs (i.e. when export, check or run are pressed in the dialog). If true is returned then the normal icon will be displayed (Icon and text are provided by implementing IPresentation).

If false is returned the normal dialog warning triangle will be displayed.

The client can return warnings and error messages via the warnings and errors parameters.

If the client returns false, but does not supply a warning or error then a default warning will be generated. This will be of the form “SimulatorName – validation failed”.

Putting it all together – steps to add an additional tab Page. Define an argument package

[Serializable]

internal class MyArgPack : IDescribedArgumentsSource

{

…

public DescribedArgument[] DescribedArguments


50

{

get { … }

}

}

Derive a class from SimulatorPageLogic<MyArgPack>

internal class MySimulatorPage : SimulatorPageLogic< MyArgPack >, IPresentation

{

protected override MyArgPack CreateArgumentPackage()

{

…

}

protected override void CopyArgumentPackage(MyArgPack

fromArgumentPackage, MyArgPack toArgumentPackage)

{

…

}

protected override bool Validate(out IEnumerable<string> warnings,

out IEnumerable<string> errors)

{

…

}

IPresentation … // for Icon and tab page Title

}

An object of this derived class should be returned via the EclipseFormatSimulator.Pages

property.

public override IEnumerable<ISimulatorPageLogic> Pages

{

get

{

List< ISimulatorPageLogic > PageList = new List<

ISimulatorPageLogic >();

PageList.Add(new MySimulatorPage());

return PageList;

}

}

Define a factory to create the custom control:

public class MySimulatorPageFactory : SimulatorPageUIFactory<MyArgPack>

{

protected override Control CreateUI(MyArgPack argumentPackage)

{

return new MyUIControl(argumentPackage);

}

}

Associate that factory with creating the control for the corresponding argument package.

This is done in Module::Integrate() .

CoreSystem.Services.AddService( typeof(MyArgPack),

MySimulatorPageFactory.ServiceType,

new MySimulatorPageFactory ());


51

When the additional tab page is now created then the MySimulatorPageFactory.CreateUI()

will be called where you will return your Control.

Your MySimulatorPage::Validate() method will be called when validation is required.

An example of a custom tab page is shown below:


52

Adding a Custom Editor

If the Ocean client wishes (the Petrel user) to modify or supplement the exported ECLIPSE deck then they may specify an editor control that can be loaded. The editor will be launched by the button on the ‘Advanced’ tab.

protected override bool HasEditor

The client should return true to indicate that they are using an editor.

protected override string EditorName

The editor’s name will be displayed on the button.

protected override Control CreateEditorUI(Case theCase)

This method will be called when the user clicks on the button. The control you provide will be hosted in a dialog.

53

Tutorial: The Uncertainty API

Uncertainty API

The Uncertainty and Optimization process in Petrel is an extensible tool that allows the user to create and manipulate parameterized reservoir models. The Slb.Ocean.Petrel.Uncertainty namespace in Slb.Ocean.Petrel assembly exposes classes and methods that extend the Uncertainty and optimization process and allows for the development and deployment of custom algorithms within the context of this process. The key features of Uncertainty and optimization process in Petrel are:

• Cross-domain integration, from seismic to simulation.

• Specially designed for a wide functional spectrum, from uncertainty analysis to optimization, with a task oriented graphical user interface.

• Ability to update the workflow with variables by using the workflow editor directly from within the uncertainty & optimization process.

• Openness and the ability to plug-in external algorithms through the Ocean API. The fundamental task of the Uncertainty and Optimization process is to define a parameterized reservoir model and to automatically create realizations of the model by varying these parameters. Each realization represent a different scenario and evaluating several scenarios allows to estimate the variation in, assign probabilities to and analyze the risk associated with modelling outputs. During execution, the Uncertainty and optimization process runs an "uncertainty loop" in which model realizations are created. It is during the execution of this loop that calls to custom algorithms can be made. This enables user defined methods and algorithms to be executed as part of the uncertainty loop.

Background

Algorithms The Uncertainty API enables extensibility of the Petrel Uncertainty process. This is done by registering user-defined algorithms via PetrelSystem.UncertaintyManager. The Slb.Ocean.Petrel.Uncertainty namespace defines 4 bases classes of algorithms that can be used to extend the Uncertainty and Optimization process:

• Sampler Provides values for uncertain or unknown parameters. This can be either random values (Monte-Carlo sampling) or following some sort of methodology (experimental design).


54

• Optimizer The aim is to find optimal sets of control parameters for a given objective. Algorithms of this type propose control parameter configuration that are used to create a realization in the uncertainty loop. The process reports back the objective for this realizations to the algorithm, which can then be used provide improved control parameters.

• Proxy Mathematical method to compute approximate reservoir modelling results. Usually, an proxy is calibrated with a small number of realizations before it can provide approximated results. This allows to bypass time consuming reservoir simulations and enables running workflows that would otherwise take too much time to compute.

• PartnerSampler A sampler that is adapted to provide data used to calibrate a specific Proxy.

Distributions Each Uncertain Variable must have a distribution associated with it. It can be a built-in or an external distribution. Distributions define how variables should be sampled accordingly to their arguments. The distribution for a variable is considered part of the uncertain model of the reservoir. The Slb.Ocean.Petrel.Uncertainty namespace defines one base class for distributions that can be used to extend the Uncertainty and Optimization process:

• Distribution Definition for a probability distribution. Parameters in the reservoir model can be set to random variables that are drawn from a probability distribution.

Uncertainty Loop The Uncertainty process in Petrel provides framework upon which the Uncertainty API is built. This framework is mainly concerned with defining parameters and launching simulations. It also contains the uncertainty loop - an iteration, during which calls to external algorithms are performed.

API design

Public API overview An algorithm has 2 parts – the static part, which provides common infrastructure common for all algorithms, and the dynamic part – executor, which is created to run the process and performs actual algorithmic operations. The static part of the algorithm is stateless and operates as a factory. The dynamic part (the Executor) is created for each run. The Executor has an argument package to keep user settings for the algorithm, and all the runtime state information, required to run the algorithm,


55

suspend and resume it. The argument package is a user defined type and thus allows convenient strong compile time access and type checking.

Algorithm API Algorithm public API is exposed as a set of generic classes, where generic type parameter is the user-defined argument package type. To implement an algorithm user must perform following steps:

1. Implement an argument package for the algorithm, which must be either a

serializable class or inherit from IIdentifiable. This class should hold all the algorithm

settings and its state.

2. Inherit from the base generic class depending on the type of the algorithm he needs

to implement (Sampler<TArgPack>, PartnerSampler<TArgPack, TProxyArgPack>,

Proxy<TArgPack>, Optimizer<TArgPack>), where type parameter of the base class

is the user-defined argument package type for the given algorithm.

3. Implement algorithm specific Executor (SamplerExecutor (for both Sampler and

PartnerSampler), ProxyExecutor, OptimizerExecutor).

4. If custom user interface is required – create a class inheriting from

System.Windows.Forms.Control, and implement AlgortihmUIFactory<TArgPack>

where TArgPack – type of the algorithm’s argument package.

5. Register an instance of the algorithm using UncertaintyManager.

6. Register (if required) UI factory using service locator against the defined argument

package type.

Brief description of the public API implementation is depicted on next page.


56


57

Distribution API The namespace Slb.Ocean.Petrel.Uncertainty.Arguments contains definitions for commonly used probability distributions arguments. This makes it easy for multiple algorithms to use the same distributions. The distributions defined in this namespace are:

• Uniform distribution arguments

• Normal distribution arguments

• Triangular distribution arguments

• Log-normal distribution arguments

• Truncated versions of the above distribution arguments Many algorithms require bounded parameter ranges. The truncated distributions use the same probability densities as their non-truncated equivalents, but enforce strict bounds for the parameters.

To specify how uncertainty variable should be sampled, plug-ins may provide custom distributions. To implement an uncertainty distribution they must perform the following steps:

1. Implement distribution argument package, which describes input parameters of the

distribution for sampling. It must be either a serializable class or inherit from

IIdentifiable.

2. Inherit from Distribution<TArgPack> where TArgPack is type of the user-defined

argument package.

3. If argument package custom editor is required – implement an editor control (which

must be inherited from the System.Windows.Forms.Control) UI factory by inheriting

from DistributionUIFactory<TArgPack>.

4. Register an instance of the distribution via UncertaintyManager.

5. Register UI Factory if needed against the type of the argument package.

Client code samples

Here is the sample code required to implement a very simple distribution using the described API. [Serializable]

class MyDistributionArgs

{

private double min_;

private double max_;

[Description("Minimum", "Minimum value")]

public double Min

{

get { return min_; }

set { min_ = value; }

}

[Description("Maximum", "Maximum value")]

public double Max

{

get { return max_; }


58

set { max_ = value; }

}

internal void CopyFrom(MyDistributionArgs otherArgs)

{

min_ = otherArgs.min_;

max_ = otherArgs.max_;

}

}

class MyDistribution : Distribution<MyDistributionArgs>

{

private Random random_ = new Random();

protected override void CopyArgumentPackage(

MyDistributionArgs fromArgumentPackage,

MyDistributionArgs toArgumentPackage)

{

toArgumentPackage.CopyFrom(fromArgumentPackage);

}

protected override double NextSample(MyDistributionArgs argumentPackage)

{

return (argumentPackage.Max - argumentPackage.Min) *

random_.NextDouble() + argumentPackage.Min;

}

}

Here is the sample code required to implement a very simple sampler, supporting above distribution plus 2 built-in. [Serializable]

class MyArguments : DescribedArgumentsByReflection

{

// Fields

private double dblArg_;

private bool boolArg_;

[Description("Double", "Sample double value")]

public double DblArg

{

get { return dblArg_; }

set { dblArg_ = value; }

}

[Description("Boolean", "Sample boolean value")]

public bool BoolArg

{

get { return boolArg_; }

set { boolArg_ = value; }

}

internal void CopyFrom(MyArguments otherArgs)

{

dblArg_ = otherArgs.dblArg_;

boolArg_ = otherArgs.boolArg_;

}

}


59

class MySampler : Sampler<MyArguments>, IPresentation

{

protected override void CopyArgumentPackage( MyArguments fromArgumentPackage,

MyArguments toArgumentPackage )

{

toArgumentPackage.CopyFrom(fromArgumentPackage);

}

protected override Executor CreateExecutor( MyArguments argumentPackage,

RuntimeContext context,

bool resuming )

{

return new MyExecutor(argumentPackage, context);

}

protected override bool Validate( MyArguments argumentPackage,

RuntimeContext context)

{

foreach (Variable v in context.Variables)

{

// Support custom distribution

if (v.Arguments is MyDistributionArgs)

continue;

// Support well-known distributions

if (v.Arguments is NormalArgs)

continue;

if (v.Arguments is UniformArgs)

continue;

return false;

}

return true;

}

#region IPresentation Members

public Bitmap Image

{

get { return null; }

}

public event EventHandler PresentationChanged;

public string Text

{

get { return "My Sampler"; }

}

#endregion

}


60

class MyExecutor : SamplerExecutor

{

MyArguments argPack_;

RuntimeContext context_;

public MyExecutor(MyArguments argumentPackage, RuntimeContext context)

{

argPack_ = argumentPackage;

context_ = context;

}

protected override void SampleValues( int iteration,

NamedValuesCollection output)

{

foreach (Variable v in context_.Variables)

{

output[v.Name].Value = v.NextSample() +

(argPack_.BoolArg ? argPack_.DblArg : 0.0D);

}

}

}

61

Contacting the Ocean Team

Please refer to the following resources for Ocean information:

www.ocean.slb.com.

releasenotes_2009_1

Documents