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 developers license is required to create new Ocean
modules.
If you run Petrel 2009.1 with an Ocean for Petrel Developers 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 Schlumbergers software. Furthermore, Petrel will configure itself to
go into Developers mode. This implies that the Petrel application shell and all hard-copies
will be watermarked. Any projects saved whilst in Developers 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 3
rd
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
isnt 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.
APIs 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 APIs
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 APIs, as illustrated in Figure 1.

Figure 1 Ocean API architecture

Ocean Core
Ocean Core
Infrastructure:
- Service locator
- Messaging interface
- Module lifecycle
- Data source manager
- Workspace
- Event transaction mgr.
- Licensing
Infrastructure:
- Service locator
- Module lifecycle
- Workspace
- Licensing
Ocean Services
Ocean Services
Application-independent
services:
- Domain object hosting
- Unit system / conversions
- Coordinate system /
conversions
- Abstract data types
- Geometry data types
services:
conversions
Ocean Petrel
Ocean Petrel
Product family:
Application shell
Domain objects
Data sources / bulk access
Processes
Windows
Toolbars
Events
Interaction
Product family:
Application shell
Domain objects
Processes
Windows
Toolbars
Events
Interaction
Application module
Application module
Deployed as plug -in or extension module
Deployed as plug-in or extension module
Public API Public API Public API
Ocean Core
Ocean Core
Infrastructure:
- Service locator
- Module lifecycle
- Workspace
- Licensing
Infrastructure:
- Service locator
- Module lifecycle
- Workspace
- Licensing
Ocean Core
Ocean Core
Infrastructure:
- Service locator
- Module lifecycle
- Workspace
- Licensing
Infrastructure:
- Service locator
- Module lifecycle
- Workspace
- Licensing
Ocean Services
Ocean Services
services:
conversions
services:
conversions
Ocean Services
Ocean Services
services:
conversions
services:
conversions
Ocean Petrel
Ocean Petrel
Product family:
Application shell
Domain objects
Processes
Windows
Toolbars
Events
Interaction
Product family:
Application shell
Domain objects
Processes
Windows
Toolbars
Events
Interaction
Ocean Petrel
Ocean for Petrel
Product family:
Application shell
Domain objects
Processes
Windows
Toolbars
Events
Interaction
Product family:
Application shell
Domain objects
Processes
Windows
Toolbars
Events
Interaction
Application module
Application module
Application module
Application module
Public API Public API Public API Public API Public API Public API Public API Public API Public 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 Librarys 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 base
1
SI units. Note in
particular that the base SI unit for seismic traveltime is seconds (not milliseconds) and for
permeability is m
2
(not Darcy or milli-Darcy; 1 Darcy = 0.9869233E-12m
2
).
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
changes
2
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 APIs 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, its 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 Petrels Process Diagram, or as
part of a Petrel Workflow as defined in Petrels Workflow Editor. The API essentially enables
custom processes to take seamlessly part in Petrels 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 UIs.
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 boreholes 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
boreholes 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
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 isnt
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 Petrels 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 doesnt 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
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 doesnt 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=119
402&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 doesnt 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 dont 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 doesnt 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 doesnt 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 doesnt 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 cant 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 Simulators 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 Petrels 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 simulators 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 Petrels
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 editors 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 algorithms 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

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Releasenotes 2009 1

Uploaded by

Copyright:

Available Formats

Ocean for Petrel 2009.

You might also like