Petrel Data Access.book - Ocean - Schlumberger

Ocean 

Ocean* application development framework 

Version 2007.1 

Volume 2 l Petrel* Data Access

Release Notes 

Copyright Notice 

Copyright © 2007 Schlumberger. All rights reserved. 

No part of this document may be reproduced, stored in an information retrieval system, or translated or retransmitted 

in any form or by any means, electronic or mechanical, including photocopying and recording, without 

the prior written permission of the copyright owner. 

* 

* Mark of Schlumberger 

Other company, product, and service names are the properties of their respective owners. 

ii 

© 2007 Schlumberger. All rights reserved.

iii 


Contents 

1 Accessing Domain Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1 

General Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 

Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 

Property Version . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 

Domain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 

Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 

Extensions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 

Data Access Patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 

Domain Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 

Common Patterns and Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 

Transactions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 

Data Source . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 

Domain Object Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 

Data Mining . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 

Data Queries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 

Input . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 

Models tree . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 

Results and Cases tree . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 

Data Creation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 

Creation rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 

Parent types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 

Creating new hierarchies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 

Expanding trees . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 

Creating properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 

Data Deletion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 

Settings Information Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 

General Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 

History . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 

Statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 

Active Object Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 

2 Borehole and Geology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .45 

Well Domain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 

Contents 

iv 


Volume 2: Petrel Data Access 

Borehole . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 

Well Log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 

Stratigraphy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 

3 Structural Domain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .71 

Shapes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72 

Surface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 

PointSet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76 

4 Seismic and the Geophysical Domain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .79 

Seismic Datasets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80 

Seismic Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80 

Seismic Datasets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82 

Seismic Interpretation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .108 

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .117 

5 Reservoir Modeling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .119 

The Static Reservoir Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .120 

Pillar Grid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .121 

Pillar Grid Domain Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .134 

3D Property . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .149 

Reservoir Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .163 

Simulation Result Classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .163 

Data Analysis and Simulation Cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .164 

Accessing Simulation Data by Time Series . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .165 

Result Filtering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .167 

Streamlines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .168 

Reading Streamline Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .169 

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .173 

6 Input and Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .175 

Extending Import/Export . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .176 

Open Petrel Binary Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .182 

RESCUE Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .183 

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .185 

v 

Ocean Developer’s Guide 


1 Accessing Domain Objects 

In This Chapter 

General Concepts .......................................................................................... 2 

Data Access Patterns ..................................................................................... 9 

Data Deletion...............................................................................................32 

Settings Information Access ..........................................................................33 

Active Object Access.....................................................................................40 

1: Accessing Domain Objects 1 



General Concepts 

Ocean exposes most of Petrel Data Model. The modeling concepts in the 

Ocean framework are founded on the design of a C# class library. Part of 

this library models the various Data Domains of Petrel. This chapter explains 

how to retrieve, modify, and create Petrel Data Domain objects, also known 

as native Petrel domain objects. 

The term 'domain object' is used in the Ocean API to mean a class of data. 

The data used in Exploration and Production can be varied. To organize 

such a varied amount of data, abstract classes are formed in a taxonomic 

hierarchy with the interface IDomainObject at the root. One domain object 

may represent a geological horizon, another domain object may be a 

completed interval in a Well, and yet another domain object may be a Seismic 

cube. 

Every domain object representing earth entities have related properties. The 

properties, although seen as domain objects themselves, are dependent 

instances that cannot exist without a related independent domain object. 

For example, a 3D property object in a model is meaningless without the 

pillar grid to which it is attached. The 3D property object does not contain 

any geometry information and needs the pillar grid to be placed in space. 

A domain object may participate in any number of binary relationships with 

other domain objects, and these relationships may be exclusive (composition) 

or shared (aggregation). For example, a borehole refers to a trajectory object 

that is really part of the borehole, and a borehole is contained in a 

BoreholeCollection, but it can exist outside that collection. 

A domain object is anything, concrete or abstract, that is uniquely identifiable 

or observable and being of interest during a period of time or at all times. A 

domain object represents some type of object that is of interest to the class 

of applications under consideration. It is described by a collection of 

characteristics. For example, a borehole is a domain object. In data modeling 

terminology, a domain object would be closely associated with an 'Entity.' 

A domain object cannot be constructed. Its model representation is either an 

interface or a sealed class. Domain objects are created usually by a Create 

method residing in the intended container class of the object. 

Properties 

Properties are used to describe physical characteristics of data model entities. 

Properties are modeled as domain objects themselves, but they are dependent 

of the entity domain object that they characterize. 

For example, a WellLog cannot be placed in 3D space without the Borehole 

it is attached to. Likewise a Property (3D property) is meaningless without 

the Grid (pillar grid) that contains it. 

2 Ocean Application Development Framework 2007.1 



As property objects contain values that bear meaning in a certain unit 

measurement context, they must define that context. A property always refers 

to a unit measurement and a presentation template. 

Property Version 

This introduces the concept of property version. A property version defines 

uniqueness for the entity it characterizes. For the API user, the property 

version specifies the unit measurement so that the API consumer may 

convert the values of the property to the proper unit. 

A property version reference is always needed when creating a property type 

object. 

The PropertyVersion class and the IUnitMeasurement and ITemplate 

interface are related as follows. 

IUnitMeasurement 

PropertyVersion 

ITemplate 

Fig. 1-1 

Property Version, Unit Measurement, and Template Classes 

Defining Property 

Versions 

Log Type Property 

Versions 

When creating a Property instance, one needs to specify the property 

version that the property object will use. Existing property versions are 

found in the IPropertyVersionService. This is accessed via the static 

class PetrelSystem with many other Petrel-related services. 

The IPropertyVersionService is accessed via the static property 

PetrelSystem.PropertyVersionService. 

PetrelSystem.PropertyVersionService has methods to retrieve, or 

create if needed, the PropertyVersion and ITemplate objects. 

This is done slightly differently for Log type properties than for other types. 

Property versions for logs are treated as a separate case because the data 

model allows only one log of a given property version in each individual 

borehole. This is exposed in the Petrel data tree in the global well log objects 

that the user can select. The global well log is referenced in the API with the 




interface ILogTemplate. Having an ILogTemplate instance is enough to 

determine the property version. 

using Slb.Ocean.Petrel; 

using Slb.Ocean.Petrel.UI; 

using Slb.Ocean.Petrel.DomainObject; 

ILogTemplate globalLog = ...; 

IPropertyVersionService pvs = 

PetrelSystem.PropertyVersionService; 

PropertyVersion pv = 

pvs.FindOrCreate(globalLog); 

However, the user may not have selected a global well log, so that 

ILogTemplate object may not be at hand. Yet the global well log may be 

retrieved by mnemonic: 


using Slb.Ocean. 




ILogTemplate globalLog = 

pvs.FindTemplateByMnemonics(“GR”); 


pvs.FindOrCreate(globalLog); 

An alternative is to define the property version from a given well log name 

and an ITemplate property template. This is similar to the property version 

definition for non-log properties, except that we supply a well log name, 

which will be used to create a new global well log. 

Instead of ITemplate, we can supply IUnitMeasurement. In that case, the 

first template found in the catalog that fits that unit measurement will be 

used (several templates are used for the same unit measurement, yet one 




would like to specify the property version as precisely as possible, so using 

IUnitMeasurement is not recommended). 



using Slb.Ocean.Petrel.UI: 

using Slb.Ocean.Units; 



// Use IUnitMeasurement to define 


IUnitServiceSettings uss; 

uss = 

CoreSystem.GetService( 

); 

IUnitMeasurement um; 

um = 

uss.CurrentCatalog.GetUnitMeasurement("Poros 

ity"); 

// Create PropertyVersion from 

UnitMeasurement, log name “NewPorosity” 


pvs.FindOrCreate("NewPorosity", um); 

// It is better to find a template for a 

precise definition of 

// PropertyVersion 

ITemplate temp1 = 

pvs.FindTemplate("Porosity"); 


pvs.FindOrCreate("NewPorosity", temp1); 

// Better yet, use statics to find template 

// to avoid typing mistakes on property names 

ITemplate temp = 

PetrelUnitSystem.TemplateGroupPetrophysical. 

Porosity; 


pvs.FindOrCreate("NewPorosity", temp); 

Non-Log Type Property 

Versions 

This is a simpler case; we find an ITemplate or settle for an 

IUnitMeasurement and get the PropertyVersion with the FindOrCreate 

method. 

We only have to specify where to look for property versions to reuse. This is 

done by giving a container object where other property versions have been 




instantiated. Property version containers are objects of type Borehole, 

BoreholeCollection, MarkerCollection, Surface, and PointSet. 




using Slb.Ocean.Units; 



// Use IUnitMeasurement to define 


IUnitServiceSettings uss; 

uss = CoreSystem.GetService( 

); 

IUnitMeasurement um; 

um = 

uss.CurrentCatalog.GetUnitMeasurement("Poros 

ity"); 

// Create PropertyVersion from a container 

and the UnitMeasurement 

Borehole bh = ...; 

PropertyVersion pv = pvs.FindOrCreate(bh, 

um); 

// Use a template for a precise definition of 


ITemplate temp = 

PetrelUnitSystem.TemplateGroupPetrophysical. 

Porosity; 

PropertyVersion pv = pvs.FindOrCreate(bh, 

temp); 

Dictionary Property 

Versions 

Dictionary property versions are similar to property versions but define 

presentation templates for enumerated property types such as facies codes. 

Similar methods are used from IDictionaryPropertyVersionService 

object referenced by PetrelSystem. We can also create log or non-log 

dictionary property versions. The code sample shows versioning on a non-log 

property. 






IDictionaryPropertyVersionService dpvs; 

dpvs = 

PetrelSystem.DictionaryPropertyVersionServic 

e; 

IDictionaryTemplate dtemp; 

dtemp = 

PetrelUnitSystem.TemplateGroupFacies.Fluvial 

Facies; 

DictionaryPropertyVersion dpv = 

dpvs.FindOrCreate(bh, dtemp); 



Domain 

A log is a possibly sparse collection of samples (property values) along the 

wellbore. The point in the well path where the sample has been measured can 

be expressed in different ways, in TVDSS (true vertical depth below sea 

level), TVD, MD (measured depth), TWT (two-way time), etc. Domain is a 

class that exposes the various domains via public static read-only properties. 

These static properties are used to switch index on the log. This is done by 

the Borehole.Transform method. 

public sealed class Domain 

{ 

public static Domain AZIMUTH; 

public static Domain CALENDAR_TIME; 

public static Domain ELEVATION_DEPTH; 

public static Domain ELEVATION_TIME; 

public static Domain INCLINATION; 

public static Domain INDEX; 

public static Domain MD; 

public static Domain MD_MSL; 

public static Domain OWT; 

public static Domain TST; 

public static Domain TVD; 

public static Domain TVD_KB; 

public static Domain TVT; 

public static Domain TWT; 

public static Domain X; 

public static Domain Y; 

} 

Project 

Project is a class that gets instantiated to describe the primary project open 

at run time. It contains global settings for the project like elevation time, 

depth references, and the default coordinate system. 

It also lets the Ocean Module create a new Collection (a folder in the 

Input data tree residing at the root) or a new ModelCollection (similar 

folder in the Models data tree). 

public sealed class Project 

{ 

public string Name { get; }; 

public ICoordSys CoordinateSystem { get; set; } 

public double ReferenceElevationDepth { get; }; 

public IEnumerable Collections { get; }; 

... 

public Collection CreateCollection (string name); 

public Collection CreateModelCollection (string name); 

} 

Extensions 

IExtensions is an interface to add or remove custom domain objects to or 

from native Petrel domain objects. Extensions can only contain objects that 

are custom domain objects, that is, those that are not native Petrel objects. 

Extensions cannot be used to modify the class relationships in the Petrel data 

model. 




When an object is added with the IExtensions.Add method, it will appear 

in the data tree under the IExtensionsSource type object that had the 

Extensions property to start with. Once inserted in the data tree, the 

custom domain object can be selected, displayed, and have a custom context 

menu. 

The IExtensions interface can also be used to find the objects inserted to 

extend the data model. 

The use of extensions is discussed in Volume 3, Chapter 12, "UI and 

Visualization" on page 707. 



Data Access Patterns 


This section describes the basic patterns of data access in Ocean Petrel, covering 

the relevant portions of Domain Object Hosting from the perspective of an 

application developer using the native Petrel domain objects. The native Petrel 

domain objects API is tailored to the individual domain object and discussed in 

detail in the following sections, beginning with Well Domain. See Volume 2, 

Chapter 6, "Accessing Domain Objects" on page 341. 

Domain Objects 

Domain Objects provide a high-level way to access your data. They are often 

called business objects because they represent concepts that are visible to the 

end-user. An important point with Domain Objects is that they are 

implemented as C# classes. The application code is type safe; object 

properties and types are known and checked by the compiler. 

Domain objects contain business logic. Typically, they 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 memory objects that contain 

business logic but are not able to save their state to a persistent data store. 

application 

Domain 

Object 

Domain 

Object 

database 

file 

persisten 

Domain 

Object 

in memory 

Fig. 1-2 

Domain Object 

Data in Petrel is accessed via hosted domain objects; they are hosted domain 

objects because their implementations utilize the Ocean Domain Object 

Hosting (DOH) patterns, interfaces, and classes. All native Petrel domain 

objects are hosted domain objects, as opposed to custom domain objects, 

which may or may not use the DOH hosting model. As a user of the native 

Petrel domain objects, the complexity of the DOH implementation is hidden 

from you. There are only a few general topics of which you should be aware, 

and they are as follows: 

• Common interfaces 




• Transactions 

• Data store 

• Events 

Since Petrel is a single-threaded application, all access to the native Petrel 

domain objects must take place on the main thread. Otherwise, you will 

receive the following run-time error. 

System.InvalidOperationException was unhandled 

Message="Cross-thread operation not valid: Application accessed 

domain object from a thread other than the main thread." 

Source="Slb.Ocean.Petrel.DomainObject" 

Common Patterns 

and Interfaces 

IIdentifiable 

There is not a general create, read, update, delete API for manipulating native 

Petrel domain objects, though there are some common patterns and 

interfaces. The API depends on the individual native Petrel domain object. 

The common patterns that native Petrel domain objects follow are: 

• Native Petrel domain objects are created by calling a create method on 

the parent container; there are no public constructors on native Petrel 

domain objects. 

• Native Petrel domain objects are deleted by calling a delete method on 

the object; many native Petrel domain objects have this functionality. 

PetrelSystem.PrimaryProject returns you the Project native Petrel 

domain object, which is the starting point for navigating through the domain 

model. 

Many native Petrel domain objects implement the following interfaces: 

• IIdentifiable 

• IDescriptionSource 

• IDomainObject 

• INotifyingOnChanged 

• INotifyingOnDeleted 

Many native Petrel domain objects have the following properties: 

• NullObject 

• LastModified 

Native Petrel domain objects that implement 

Slb.Ocean.Core.IIdentifiable have a durable identity via a Droid. A 

Droid is a Durable Runtime Object Identifier, which is a reference to an 

actual domain object. A Droid eliminates the need to hold on to the object 

itself. See Volume 1, Chapter 2, "The Ocean Core" on page 60 for a more 

detailed discussion of Droids. 

public interface IIdentifiable 

{ 

Droid Droid; 

} 




When persisting a custom domain object that has a reference to an 

identifiable native Petrel domain object, save only the Droid of the native 

Petrel domain object. When the custom domain object is "re-hydrated," the 

native Petrel domain object can be recreated from the Droid using the 

Resolve functionality of the DataManager or IDataSourceManager after 

the Workspace has become available. 

IDescriptionSource 

Native Petrel domain objects that implement 

Slb.Ocean.Core.IDescriptionSource can give out a name, a short 

description, and a long description via the IDescription interface. See 

Volume 1, Chapter 2, "The Ocean Core" on page 67. 

public interface IDescriptionSource 

{ 

IDescription Description { get; } 

} 

public interface IDescription 

{ 

string Name { get; } 

string ShortDescription { get; } 

string Description { get; } 

} 

IDomainObject 

Many native Petrel domain objects implement the 

Slb.Ocean.Data.Hosting.IDomainObject interface. 

public interface IDomainObject 

{ 

public IDataSource DataSource { get; } 

public bool IsGood { get; } 

} 

You can access the data source in which the domain object is persisted. 

IsGood gets a value indicating whether or not the domain object is deleted 

from its data source. This method can be slow, so use it with care. Note that 

a NullObject is never good. Trying to access a property of a "bad" object 

will probably throw an exception. 

INotifyingOnChanged 


Slb.Ocean.Petrel.DomainObject.INotifyingOnChanged interface in 

order to notify clients when they have changed. The Changed event is raised 

when the domain object has changed, but not when children are added or 

removed. See Volume 2, Chapter 1, "" on page 15. 

public interface INotifyingOnChanged 

{ 

event EventHandler Changed; 

} 

INotifyingOnDeleted 


Slb.Ocean.Petrel.DomainObject.INotifyingOnDeleted interface in 

order to notify clients when they have changed. The Deleted event is 




raised when the domain object has been deleted, but not when children are 

added or removed. See Volume 2, Chapter 1, "" on page 15. 

public interface INotifyingOnDeleted 

{ 

event EventHandler Deleted; 

} 

NullObject 

DOH uses the null object design pattern for hosted domain objects. This 

means that you will never receive a null when asking for a hosted domain 

object; you will receive a special null instance of the same type instead. This 

is an example showing the Surface NullObject property. 

public class Surface : ... 

{ 

public static Surface NullObject { get; } 

... 

} 

To test if a marker is part of a surface, compare its Surface property with 

the Surface.NullObject instead of comparing its Surface property with 

a null. 

Marker myMarker = ...; 

if (myMarker.Surface == Surface.NullObject) 

MessageBox.Show(“Marker is not part of a 

surface”); 

LastModified 

All native Petrel domain objects have a LastModified property that returns 

a LastModificationInfo structure. This structure supplies the time and 

date of the last modification as well as the name of the user who caused the 

modification. 

public struct LastModificationInfo 

{ 

public DateTime Time { get; } 

public string UserName { get; } 

... 

} 

To access information about when a native Petrel domain object was last 

modified, use its LastModified property. 

Surface mySurface = ...; 

string name = 

mySurface.LastModified.UserName; 

DateTime t = mySurface.LastModified.Time; 

Transactions 

A transaction represents a group of edits on some data (domain objects). 

Transactions are required for operations on native Petrel domain objects that 

will change the data: create, update, and delete. 




To use a transaction complete the following steps. 

1. Create a transaction. 

2. Lock domain objects that are going to be changed. 

3. Modify the domain objects. 

4. Commit the transaction. 

5. Dispose of the created transaction. 

In Petrel, transactions are used to batch event notifications. Petrel does not 

use a database, so changes to domain objects made within a transaction 

happen immediately. 

Transactions use the Slb.Ocean.Core.ITransaction interface. 

public interface ITransaction: IDisposable 

{ 

void Commit(); 

void Lock(params object[ ] objects); 

void LockCollection(IEnumerable 

objectCollection); 

... 

} 

Transactions can be created two ways. The first and most common way is 

through static convenience functions on the static convenience class 

Slb.Ocean.Core.DataManager. 

public static class DataManager 

{ 

public static ITransaction 

NewTransaction(); 

public static ITransaction 

NewTransaction(object context); 

public static ITransactionManager 

TransactionManager { get; } 

... 

} 

It is also possible to create a transaction via the 

Slb.Ocean.Core.ITransactionManager interface, available from the 

DataManager. 

public interface ITransactionManager 

{ 

ITransaction NewTransaction(object 

context); 

... 

} 




Since the transaction must be disposed when it is no longer needed, it is 

usually wrapped in a using statement. 

ITransaction trans; 

using (trans = DataManager.NewTransaction()) 

{ 

trans.Lock(...); 

} 

// create or update data 

trans.Commit(); 

... 

The rules for locking domain objects in Petrel are as follows. 

• Objects that are being updated or deleted must be locked first. If it is 

not locked and an attempt is made to modify the object, then a 

TransactionException will be thrown. 

• When an object is going to be created as the child of another object, 

then the parent object must be locked before the creation. 

• When an object is created inside a transaction it is implicitly locked. For 

example, if you create an object and then want to modify its name, you 

do not have to lock it. The lock you placed on its parent before the 

creation carries through to the new child. 

Note that all of the functionality of ITransaction is not supported in the 

Ocean 2006 native Petrel domain objects. TryLock and 

TryLockCollection have no meaning in Petrel; all locks will always 

succeed. Abandon is not supported; there is no rollback. As a practical 

matter, this means that omitting the call to Commit is currently the same as 

calling Commit, assuming that you have the transaction in a using block. 

Events will still be fired because the changes were already made to the data. 

The locked objects will also be unlocked. 

Data Source 

Petrel persists its data including hosted domain objects to a file, called the 

project file, via serialization. The native Petrel domain objects that 

implement IDomainObject allow you to access the data source via 

Slb.Ocean.Core.IDataSource. The Petrel data source is also available 

from the Slb.Ocean.Core.IWorkspace interface. 

public interface IWorkspace : 


{ 

IDataSource DefaultSource { get; } 

... 

} 




The data source allows the application developer to resolve Droids after the 

workspace is available and determine if the data store is dirty. 

public interface IDataSource: IDroidResolver 

{ 

bool CanResolve(Droid droid); 

object Resolve(Droid droid); 

} 

bool IsDirty { get; } 

event EventHandler IsDirtyChanged; 

... 

IDroidResolver.CanResolve(droid)==true 

is equivalent to: 

IDroidResolver.Resolve(droid)!=null 

There is a known bug that the Petrel data source always reports that the data 

source is clean: IsDirty always returns false. 

As a convenience, Resolve is also available as a static function on the static 

convenience class DataManager. Again, Resolve can only be called after 

the workspace has become available. 

public static class DataManager 

{ 

public static object Resolve(Droid droid); 

... 

} 

Domain Object 

Events 

Many native Petrel domain objects implement INotifyingOnChanged and 

INotifyingOnDeleted and thus publish Changed and Deleted events to 

allow an application to monitor lifecycle activity. Specific domain objects 

may publish more specific events. For example, Logs publishes 

DictionaryWellLogsChanged, MultiTraceWellLogsChanged, and 

WellLogsChanged events. 

Many native Petrel domain objects that are collections or that contain 

collections also publish specialized events for those collection changes. For 

example, BoreholeCollection publishes two collection changed events 




since it is a collection and contains collections: BoreholesChanged and 

BoreholesCollectionsChanged. 

Domain Object Hosting 

Well 

name = “C7” 

Changed 

Well 

name = “B4” 

Changed 

Fig. 1-3 

Changed Event 

Subscribe to the events on a domain object instance. 

BoreholeCollection bhc = ...; 

bhc.Changed += 

new EventHandler(bhcChanged); 

bhc.Deleted += 

new EventHandler(bhcDeleted); 

bhc.BoreholesChanged += 

new EventHandler 

(bhcBoreholesChanged); 

bhc.BoreholeCollectionsChanged += is 

new EventHandler 

 

(bhcCollectionsChanged); 

Unsubscribe from events also in the standard .NET way. This example shows 

the shorter form available in .NET 2.0. 

bhc.Changed -= bhcChanged; 

bhc.Deleted -= bhcDeleted; 

bhc.BoreholesChanged -= bhcBoreholesChanged; 

bhc.BoreholeCollectionsChanged -= bhcCollectionsChanged; 

Event delivery is coordinated with transactions. Events are queued in an 

EventService component and broadcast to listeners when the enclosing 

transaction is committed or disposed. 

Changed Event 

The Changed event includes arguments that give the object changed and the 

source of the change. The origin of the event source is always Petrel itself 

(EventOrigin.Internal) since Petrel does not support multi-process 




access to the native Petrel domain objects. The list of property names that 

have been changed is always empty in Petrel. 

public class DomainObjectChangeEventArgs : 

DomainObjectEventArgs 

{ 

public override int GetHashCode(); 

public string[] GetPropertyNames(); 

public override string ToString(); 

public IEnumerable PropertyNames {get; } 

public IDomainObject AffectedObject { get; } 

public EventSource EventSource { get; } 

... 

} 

The event handler accesses the information it needs from the event 

arguments. 

void bhChanged(object sender, 

DomainObjectChangeEventArgs args) 

{ 

Borehole b = args.AffectedObject as Borehole; 

... 

} 

If a domain object is changed multiple times within the same transaction, for 

example more than one property is changed, only one change event will be 

raised. 

Deleted Event 

Similarly, the Deleted event has arguments that give the affected object and 

its Droid. The Droid is only valid if the domain object is identifiable 

(implements IIdentifiable); otherwise, the Droid is empty and resolves to 

null. 

public class DomainObjectDeletedEventArgs : 

DomainObjectEventArgs 

{ 


public Droid Droid { get; } 

public IDomainObject AffectedObject { get; } 

public EventSource EventSource { get; } 

... 

} 


arguments. 

void bhDeleted(object sender, 

DomainObjectDeletedEventArgs args) 

{ 

Borehole b = args.AffectedObject as Borehole; 

Droid d = args.Droid; 

... 

} 




If a domain object is changed and deleted within the same transaction, only 

the delete event will be raised; no change events will be raised in this 

scenario. 

Collection Changed 

Events 

There could not be a generic collection changed event since the collection 

changing applies to both domain objects that are collections and domain 

objects that contain collections. While the events are specialized, they all 

follow a pattern in their use of the same argument class. The collection 

change events all have arguments that give what change happened, the list of 

added objects, and the list of removed objects. 

public class DomainObjectCollectionChangeEventArgs : 

HostingEventArgs where T = class; 

{ 


public IEnumerable AddedObjects { get; } 

public IEnumerable RemovedObjects { get; } 

public DomainObjectCollectionChangeTypes ChangeType { get; } 

... 

} 

public enum DomainObjectCollectionChangeTypes 

{ 

None = 0, 

Add = 1, 

Remove = 2 

} 

A change type of None means one of the following: 

• No changes. 

• Collection was reshuffled. 

• Added and removed objects are unknown. 


arguments. 

void bhcBoreholesChanged(object sender, 

DomainObjectCollectionChangeEventArgs args) 

{ 

if (args.ChangeType == DomainObjectCollectionChangeTypes.Add) 

{ 

foreach (Borehole bh in args.AddedObjects) 

... 

} 

... 

} 

Data Mining 

Ocean 2007 for Petrel carries the concept of Data Mining; for example, it 

supports browsing through the project to retrieve collections of domain 

objects of a given type. 

As we have seen in the previous section, there is no general pattern for 

object listing or creation. This is done through collections that represent the 

natural data organization. 




The Petrel project organization is hierarchical. It breaks collections in 

meaningful sub-collections so that the user is not faced with long list 

searches. There is no SQL-type query support in Petrel. When searching for 

data in a project, the user has to recursively search through nested 

collections. The API follows the same paradigm. 

The following example searches the Input data tree for Borehole objects 

with a given characteristic (they must contain a gamma ray log). This is done 

by traversing the nested hierarchy of BoreholeCollection instances. The 

example avoids recursion. 

public static void ListGRBoreholes () 

{ 

PetrelLogger.InfoOutputWindow("List all Boreholes with GR logs"); 

WellRoot wr = WellRoot.Get(PetrelProject.PrimaryProject); 

BoreholeCollection col = wr.BoreholeCollection; 

if (col == BoreholeCollection.NullObject) 

{ 

PetrelLogger.InfoOutputWindow("Project has no Borehole"); 

return; 

} 

// Traverse the global well logs for "Gamma ray" 

PropertyVersion glob = PropertyVersion.NullObject; 

ITemplate temp = PetrelUnitSystem.TemplateGroupLogTypes.GammaRay; 

foreach (PropertyVersion pv in wr.WellLogVersions) 

{ 

if (PetrelUnitSystem.FindTemplateForPropertyVersion(pv) == temp) 

{ 

glob = pv; 

break; 

} 

} 

if (glob == PropertyVersion.NullObject) 

{ 

PetrelLogger.InfoOutputWindow("Project contains no GR log"); 

return; 

} 




List bhcCol = new List(); 

List bhCol = new List(); 

bhcCol.Add(col); 

// Traverse the Borehole folders (simulate tail recursion) 

int i = 0; 

while (i < bhcCol.Count) 

{ 

col = bhcCol[i]; 

bhCol.AddRange(col); 

bhcCol.AddRange(col.BoreholeCollections); 

i++; 

} 

// Now traverse the Boreholes 

foreach (Borehole bh in bhCol) 

{ 

foreach (WellLog log in bh.Logs.WellLogs) 

{ 

IWellLogVersion lpv = log.WellLogVersion; 

ITemplate logTemp; 

logTemp = PetrelUnitSystem.FindTemplateForPropertyVersion(lpv); 

if (logTemp == PetrelUnitSystem.TemplateGroupLogTypes.GammaRay) 

{ 

PetrelLogger.InfoOutputWindow("Borehole " + bh.Name); 

break; 

Data Queries 

Domain Partitioning 

The Petrel data domain is organized in different hierarchies; access (and data 

mining) is done following the Petrel organization. 

The data trees found in a Petrel project are as follows. 

• Input 

• Models 

• Results 

• Cases 

In a Petrel project, there are no cross-domain relationships, although 

domains are crossed by applications. For instance, building a pillar grid may 

use a Shape.Surface object, originally computed from a 

Seismic.HorizonInterpretation instance to produce a 

PillarGrid.Horizon instance. Yet these instances will end up in unrelated 

data trees. 

The links between different representations of a Horizon are factual. 

• They overlap geographically and in geological time. 

• They carry the same name (enforced by grid construction). 

• The user knows which seismic horizon was used to create a given level 

in the pillar grid. 

The API, to retrieve such data, has to search data trees individually. 




Navigation 

Root objects 

Although trees are unrelated, data navigation is allowed in the same domain 

in specific cases as when there are data dependencies (deleting a Borehole 

will delete all the WellMarker instances that it contains). These cases are 

• markers to boreholes 

• interpretation subsets to seismic surveys where picks originated 

The API properties implementing these relationships are exposed in the 

relevant data chapters. 

All data queries will be done via root objects. Querying in a Petrel project is 

done by traversing the tree of containers where this type of object can be 

found. The search starts at the root. 

The root objects that let the API search the data trees in the project are as 

follows. 

• WellRoot 

• SeismicRoot (SeismicProject) 

• PillarGridRoot 

• AnalysisRoot and SimulationRoot 

The individual data trees are accessible from root objects, directly accessible 

from static methods by supplying the Project instance (referenced by 

PetrelProject.PrimaryProject). 

In an empty project, data trees have not been created yet. However, these 

root objects exist by default. 

Data queries start with root objects in the various trees that are displayed in 

Petrel. 

Root objects relate to specific data trees displayed in the Petrel project. 




Input 

Fig. 1-4 

Input tree showing seismic data and interpretation objects 

Input shows all data imported or generated prior to inclusion in a Petrel 

structural model (pillar grid). 

• Boreholes and Trajectories 

• Stratigraphy Columns with Markers 

• Seismic Data 

• Seismic Interpretation 

• Shapes 

• Unnested individual data 

Well and stratigraphy data in the input tree is accessible from an instance of 

the WellRoot class, returned in the class itself by a static Get method. 

Boreholes are leaves in a tree of nested collections all rooted under a main 

folder. This top-level folder is accessible from the WellRoot object. 

Note that the top level folder does not exist in an empty project or in one 

that has not been loaded with any well data. In that case the 




BoreholeCollection exposed in WellRoot is a NullObject, but a new 

folder is created when the method GetOrCreateBoreholeCollection is 

invoked. 

Stratigraphy is arranged in non-nested overlapping classifications, showing as 

individual stratigraphy folders. All these folders, represented by 

MarkerCollection instances can be retrieved from the WellRoot object. 

public sealed class WellRoot : ... 

{ 

public static WellRoot Get(Project project); 

public BoreholeCollection GetOrCreateBoreholeCollection(); 

} 

} 

public BoreholeCollection BoreholeCollection { get; } 

public IEnumerable MarkerCollections { get; } 

public IEnumerable WellLogVersions { get; } 

public IEnumerable 

DictionaryWellLogVersions { get; } 

public IEnumerable CheckShotVersions { get; } 

public IEnumerable PointWellLogVersions { get; 

... 

Seismic datasets, like boreholes, are arranged in a tree of nested 

SeismicCollection instances. The top level collection is found under the 

SeismicProject, which is only created if the project is loaded with seismic 

data. 

public sealed class SeismicRoot : ... 

{ 

public static SeismicRoot Get(Project project); 

public SeismicProject CreateSeismicProject(); 

public SeismicProject GetOrCreateSeismicProject(); 

} 

public SeismicProject SeismicProject { get; } 


InterpretationCollections { get; } 

... 

Unlike borehole folders, the SeismicProject object commands both 

datasets and interpretation hierarchies, stressing the creation rule for 

interpretation sets. Seismic interpretation cannot be created unless the 




SeismicProject has been created (enforcing the concept that a dataset is 

required before interpretation can be created). 

public sealed class SeismicProject : ... 

{ 

public InterpretationCollection 

CreateInterpretationCollection(string name); 

public SeismicCollection CreateSeismicCollection(string name); 

public Wavelet CreateWavelet(string name); 

... 

public string Name { get; } 


InterpretationCollections { get; } 

public IEnumerable SeismicCollections { get; 

} 

public IEnumerable Wavelets { get; } 

} 

Other objects, such as Shape domain instances are found in simple 

Collection folders. These folders are nested and the roots of folder trees 

are listed directly under the Project instance. 

public sealed class Project : ... 

{ 

public IEnumerable Collections { get; } 

... 

} 

public sealed class Collection : ... 

{ 

public Collection CreateCollection(string name); 

public PointSet CreatePointSet(string name); 

public PolylineSet CreatePolylineSet(string name); 

public RegularHeightFieldSurface 

CreateRegularHeightFieldSurface(string name, 

LatticeInfo lattice); 


} 

// indexer for collection members 

public IDomainObject this[int index] { get; set; } 

public int Count { get; } // number of objects in the collection 

// sub-collections 

public IEnumerable Collections { get; } 

public string Name { get; set; } 

// members 

public IEnumerable PointSets { get; } 

public IEnumerable PolylineSets { get; } 


RegularHeightFieldSurfaces { get; } 

public IEnumerable Wavelets { get; } 

... 

Details on the tree contents are exposed in the following data chapters. 




Models tree 

Fig. 1-5 

Model tree showing objects under pillar grid expanded 

Models tree displays reservoir models. Models of the same type are gathered 

in collections. Models contain a number of structural elements like pillar 

grids, their faults and horizon surfaces, and the 3D properties that assign 

values to each cell in the grid. Pillar grids contain both property distributions 

and fault face properties, all contained in the model. 

Collections of models are accessed directly under the project. 

Pillar grid models are the only models that are exposed in the Ocean API, so 

they are treated as a special case. The unique PillarGridRoot object 




returns pillar grid models, filtered or not, by their model collection 

containers. 


{ 

public IEnumerable ModelCollections { get; } 

... 

} 

public sealed class PillarGridRoot : ... 

{ 

public static PillarGridRoot Get(Project project); 

public int GetGridCount(ModelCollection modelCollection); 

public IEnumerable GetGrids(ModelCollection 

modelCollection); 

} 

public int GridCount { get; } 

public IEnumerable Grids { get; } 

Collections of models are represented by ModelCollection instances. 

Members of these collections are models of different types (the only type 

that is exposed in the Ocean API at the moment is the Grid type, which 

represents the pillar grid). The model collections are not nested. 

public sealed class ModelCollection : ... 

{ 

public int ModelCount { get; } 

public IEnumerable Models { get; } 


... 

} 

Properties under the pillar grid are organized in a nested collection tree. The 

root of that tree is unique and stored in the Grid class member 

PropertyCollection. New sub-collections can be created at any level of 

the property tree, but the root remains unique. 

public sealed class PropertyCollection : ... 

{ 

public Grid Grid { get; } 

public int PropertyCount { get; } 

public IEnumerable Properties { get; } 


// nesting 

public PropertyCollection ParentPropertyCollection { get; } 

public int PropertyCollectionCount { get; } 

public IEnumerable PropertyCollections { 

get; } 

} 

// create sub-collection 

public PropertyCollection CreatePropertyCollection(string name); 

public Property CreateProperty(PropertyVersion propertyVersion); 




Results and Cases 

tree 

Fig. 1-6 

Petrel Results and Cases tree data 

Cases display data analysis runs and reservoir simulation runs. Cases are 

enumerated by the AnalysisRoot instance. This AnalysisRoot object is 

unique and retrieved from a class static method by supplying the Project 

instance. 

Results show simulation result categories and result time series. Results are 

also accessed from the AnalysisRoot instance. 

public sealed class AnalysisRoot : ... 

{ 

public static AnalysisRoot Get(Project project); 

} 

public int CaseAnalysisCount { get; } 

public IEnumerable CaseAnalyses { get; } 

public int CaseCount { get; } 

public IEnumerable Cases { get; } 

public int ResultCategoryCount { get; } 

public IEnumerable ResultCategories { get; } 

public int ResultPropertyCount { get; } 

public IEnumerable ResultProperties { get; } 




Simulation cases are specific case runs loaded in the Petrel project from a 

simulation run executed with a number of alternative simulator products. 

These cases originated in simulators are accessible via the SimulationRoot 

instance. 

public sealed class SimulationRoot : ... 

{ 

public static SimulationRoot Get(Project project); 

} 

public int SimulationCount { get; } 

public IEnumerable Simulations { get; } 

Data Creation 

Creation of Petrel data domain objects is not separated from their placement 

in the project data trees. This is intentional and the API does not provide 

constructors for domain object classes. 

The placement in the project of newly created Petrel data domain objects 

follows the data tree organization that we have seen for data browsing. 

Methods to create specific domain object types are found in the class that 

naturally contains that domain object and never in the class that represents 

the object itself. 

These parent classes can be collection types or entities that possess 

collection-type members. 

Creation rules 

Creation of data domain objects in a Petrel project is governed by a number 

of unwritten rules. 

• Entity types are part of a collection. For instance, a Borehole is found in 

a BoreholeCollection. 

• Most collections are nested. This is inherent to the purely hierarchical 

nature of the Petrel data organization. Nesting lets the user organize the 

data tree so that a reasonable number of branches appear at any node. 

Therefore, creation will often include branching out in the tree by 

creating a new sub-collection. 

• There is no single data tree organization but a number of root objects 

that define the top level of each data tree. As we have seen earlier, data 

trees do not cross domains and single domains have several data trees. 

• Root folders may be created via the API, if needed. 

Parent types 

The classes that provide data creation can be characterized as follows. 

• The project class, to add elements at the top of the data trees 

• Root classes, specifically provided to create new data trees 

• Collection classes, allowing member creation and sometimes creation of 

sub-collections 




• Entity classes, generally providing methods to create properties 

Creating new 

hierarchies 

This is done with the Project class or root classes. 

From the project, we can create generic collections (that will contain newly 

created Shapes domain objects) and model collections (that will appear at 

the top level of the Models tree). 

The project also allows creation of Wavelet and PointSet objects that will 

appear outside of all data folders. 


{ 

... 

public Collection CreateCollection(string name); 

public ModelCollection CreateModelCollection(string name); 

public PointSet CreatePointSet(string name); 


} 

WellRoot provides creation methods for marker collections (stratigraphy 

columns) and borehole collections. Only the top level borehole collection can 

be created at that level, and it will fail if that unique folder object exists. A 

safer GetorCreate method is also provided. 

public sealed class WellRoot : ... 

{ 

public BoreholeCollection CreateBoreholeCollection(); 

public BoreholeCollection GetOrCreateBoreholeCollection(); 

public MarkerCollection CreateMarkerCollection(string name); 

... 

} 

SeismicProject can create seismic collections (2D or 3D seismic surveys) 

and interpretation collections. 

public sealed class SeismicProject : ... 

{ 

public InterpretationCollection 

CreateInterpretationCollection(string name); 

public SeismicCollection CreateSeismicCollection(string name); 


... 

} 

Other root objects are used for browsing but do not provide creation 

methods. 

Expanding trees 

Most collection types allow creation of objects and sub-collections, although 

not all of them (ModelCollection is read-only as new pillar grids cannot yet 

be created). Collections able to create objects consist of the following. 

• BoreholeCollection in the well domain 




• SeismicCollection and InterpretationCollection in the 

seismic domain 

• Collection in the shapes domain 

• PropertyCollection in the pillar grid domain 

All these collection types have similar creation methods. They are fully 

detailed in the online manual. We will just list one here, 

BoreholeCollection. 

public sealed class BoreholeCollection : ... 

{ 

// children of type collection 

public int BoreholeCollectionCount { get; } 

public IEnumerable BoreholeCollections { 

get; } 

// parent 

public BoreholeCollection ParentBoreholeCollection { get; } 

} 

// create a sub-collection 

public BoreholeCollection Create(string name); 

// children of type element 

public int Count { get; } 

public IEnumerator GetEnumerator(); 

// create a new element in the collection 

public Borehole CreateBorehole(string name); 

Non-collection types also sometimes provide creation methods to add 

structural parts to the entity defined. Such classes are as follows: 

• MarkerCollection in the well domain 

• HorizonInterpretation in the seismic domain 

• StreamlineSet and StreamlineSubset in the simulation domain 

These methods are specific to the classes concerned. We show one here as an 

example, MarkerCollection. 

public sealed class MarkerCollection : ... 

{ 

public Fault CreateFault(); 

public Horizon CreateFirstHorizon(); 

public Interface CreateInterface(); 

public void CreateZoneAndHorizonAbove(Horizon horizon, 

out Zone newZone, out Horizon newHorizon); 

public void CreateZoneAndHorizonAbove(Zone zone, 


public void CreateZoneAndHorizonBelow(Horizon horizon, 


public void CreateZoneAndHorizonBelow(Zone zone, 


public void CreateZoneAndHorizonIn(Zone zone, 

out Zone newZone1, out Horizon newHorizon, out Zone newZone2); 

... 

} 




Creating properties 

In all domains, property classes contain scalar values and are called properties 

or index values in a related classification and are then called dictionary 

properties. The creation of a property or a dictionary property is similar and 

takes either a property version or a dictionary property version as argument. 

Entity classes that provide creation methods for contained properties are the 

following. 

• Logs and MarkerCollection in the well domain 

• RegularHeightFieldSurface, Surface, and PointSet in the 

shapes domain 

• PropertyCollection in the pillar grid domain 

• StreamlineSet in the simulation domain 

All property owner types have the same type of interface, and we will just 

show one here as an example, the Logs class. 

public sealed class Logs : ... 

{ 

public WellLog CreateWellLog(PropertyVersion version); 

public DictionaryWellLog 

CreateDictionaryWellLog(DictionaryPropertyVersion version); 

... 

} 




Data Deletion 

Fig. 1-7 

Popup menu showing Delete... item 

Data deletion is invoked from the object to be deleted. Most domain objects 

provide a Delete() method. The action performed is equivalent to the 

delete menu entry in the corresponding object's context menu in the Petrel 

data tree. 

The method signature is the same across domains. We show the Borehole 

class here as an example. 

public sealed class Borehole : ... 

{ 

public void Delete(); 

... 

} 



Settings Information Access 


You can access settings information for native Petrel domain objects, 

including history and statistics. 

Fig. 1-8 

Settings Dialog 

Each type of settings information has a different set of interfaces to use to 

access it. 

Table 1-1 Settings Info Interfaces 

Information 

General 

settings 

Settings 

Dialog Tab 

Info 

Interfaces 

ISettingsInfo, 

ISettingsInfoFactory 

History Info IHistoryInfo, 

IHistoryInfoFactory 

Statistics Statistics Statistics, IStatisticsFactory, 

StatisticsService 




General Settings 

All native Petrel domain objects have basic information in the settings dialog 

Info tab. These include name, color, object type, and comments. 

Fig. 1-9 

General Information in Info Tab 

You can access these settings via ISettingsInfo. 

public interface ISettingsInfo : 

IPresentation 

{ 

string Text { get; set; } 

Color Color { get; set; } 

Bitmap TypeImage { get; } 

string TypeName { get; } 

string Comment { get; set; } 

bool IsReadOnly { get; } 

} 

public interface IPresentation 

{ 

Bitmap Image { get; } 

string Text { get; } 

} 




Get the settings and presentation interfaces via their factories. 

public interface ISettingsInfoFactory 

{ 

ISettingsInfo GetSettingsInfo(object o); 

} 

public interface IPresentationFactory 

{ 

IPresentation GetPresentation(object o); 

} 

Access the presentation and settings information using the following pattern. 

1. Get the appropriate factory service, I*Factory. 

2. Get the interface for the specific Petrel object, I*. 

3. Get information from the interface properties. 

SeismicCube c = ...; 

ISettingsInfoFactory sif; 

sif = 

CoreSystem.GetService( 

c); 

ISettingsInfo info = sif.GetSettingsInfo(c); 

Image i = info.Image; 

Color color = info.Color; 

String comment = info.Comment; 

Fig. 1-10 Settings Sample Output 

History 

Native Petrel domain objects typically have a history of actions performed on 

them. 

Fig. 1-11 Seismic Cube History 




Each history entry is an immutable record of a data change event about the 

domain object. These entries are part of the audit trail of an object. 

public sealed class HistoryEntry 

{ 

HistoryEntry(DateTime begin, DateTime end, 

string user,string operation, 

string args, string Version); 

HistoryEntry(string operation, string args, 

string Version); 

string AppVersion { get; } 

string Arguments { get; } 

string Operation { get; } 

string UserName { get; } 

DateTime BeginDate { get; } 

DateTime EndDate { get; } 

} 

Some domain objects may also give you the ability to add a new history entry 

via IHistoryInfoEditor. 

public interface IHistoryInfoEditor 

{ 

void AddHistoryEntry(HistoryEntry he); 

bool UpdateLastHistoryEntry(string userName, string operation, 

string arguments, stringappVersion); 

} 

This interface also allows you to update end time of the last history entry, in 

order to support long-running edit operations. 

Use the convenience class HistoryService to get the list of history entries 

and the history info editor, if supported. 

public interface HistoryService 

{ 

public static IEnumerable GetHistory( object o); 

public static IHistoryInfoEditor GetHistoryInfoEditor(object o); 

} 

Get the list of history entries and then access the needed information from 

each history entry. 


string h; 

foreach (HistoryEntry he in 

HistoryService.GetHistory(c)) 

{ 

h = h + he.BeginDate.ToString() + "-" + 

he.EndDate.ToString() + " " 

+ he.UserName + " " + he.Operation + 

" " 

+ he.Arguments + " " + he.AppVersion 

+ "\r\n"; 

} 




Fig. 1-12 Seismic Cube History Sample Output 

Typically, the oldest history entry is first in the list. 

Statistics 

Native Petrel domain objects typically have statistics, which are displayed in 

the Statistics tab of the settings dialog. 

Fig. 1-13 Seismic Cube Statistics 

Statistics are a collection of common information about the object. There 

are two different collections. One is axis information and the other is a set 




of attribute key value pairs. These are available from the Statistics class. 

public sealed class Statistics 

{ 

Statistics(IEnumerable axisInfo, 

IEnumerableattributes); 

IEnumerable AxisInfo { get; } 

IEnumerable Attributes { get; } 

} 

The contents of Statistics are immutable, and the contents of the class 

are a copy at the calling time. 

An AxisInfoItem describes spatial information about the domain object 

relevant for a particular axis. These are either related to a domain or to a 

dictionary/property version. 

public abstract class AxisInfoItem 

{ 

AxisInfoItem(string name, double min, double max); 

double Max { get; } 

double Min { get; } 


virtual double Delta { get; } 

abstract IUnitMeasurement UnitMeasurement { get; } 

} 

You use the convenience class StatisticsService to get statistics and also 

to determine if statistics are available for a given type. 

public class StatisticsService 

{ 

static Statistics GetStatistics( object o); 

static bool CanGetStatistics(Type type); 

} 

Get the statistics from StatisticsService and then access the axis and 

attribute information needed. 

string attrs, ai; 


Statistics stat = 

StatisticsService.GetStatistics(cube); 

foreach (AxisInfoItem item in stat.AxisInfo) 

ai = ai + item.Name + " Min " + 

item.Min.ToString() 

+ " Max " + item.Max.ToString() + 

"\r\n"; 

foreach (KeyValuePair kvp in 

stat.Attributes) 

attrs = attrs + kvp.Key + " " + kvp.Value + 

"\r\n"; 




Fig. 1-14 Statistics Axis Info Sample Output 

Fig. 1-15 Statistics Attributes Sample Output 




Active Object Access 

Active objects in Petrel set the scope for interactive operations. They are 

displayed in boldface in the Petrel explorer trees. 

Fig. 1-16 Active Petrel Objects 

Active objects are based on the type of object. At any given time, there can 

be multiple active objects of different types, as shown above. There is no 

more than one active object of a particular type. 

Whether there is an active object of a particular type depends on the type. 

Some types must always have an active object, like the Grid. Other types do 

not require an active object, like HorizonInterpretation. 


Fig. 1-17 No Active Horizon Interpretations 



You can access active objects via IActiveObjectService. This service 

allows you to query for and retrieve active objects. 

public interface IActiveObjectService 

{ 

bool CanGetActiveObject(); 

IActiveObject GetActiveObject(); 

bool CanGetActiveObjectInContainer(); 

IActiveObjectInContainer 

GetActiveObjectInContainer(); 

... 

} 

You can manipulate active objects using IActiveObject. This interface 

allows you to query, check the state, change the state, and retrieve the active 

object. 

public interface IActiveObject 

{ 

bool IsActive( TDomainObject o); 

bool CanActivate( TDomainObject o); 

bool CanDeactivate(TDomainObject o); 

} 

void Activate( TDomainObject o); 

void Deactivate(TDomainObject o); 

TDomainObject GetObject(); 

... 

The first step is to get an active object for a given type, and then you can 

manipulate it. Note that the ActiveObjectService is available from the 

PetrelSystem convenience class. 

IActiveObject activeGrid; 

activeGrid = PetrelSystem.ActiveObjectService.GetActiveObject(); 

Grid g = activeGrid.GetObject(); 

Grid g1 = FindFirstGridInProject(); 

activeGrid.Activate(g1); 

// following will throw exception; must always be an active grid 

activeGrid.Deactivate(g1); 

Grid g2 = FindSecondGridInProject(); 

// will activate g2 and deactivate g1 

activeGrid.Activate(g2); 




You may also be able to find an active object in a particular container via 

IActiveObjectInContainer. 

public interface 

IActiveObjectInContainer 

{ 

bool IsActive( TDomainObject o); 

bool CanActivate( TDomainObject o); 

bool CanDeactivate(TDomainObject o); 

} 

void Activate( TDomainObject o); 

void Deactivate(TDomainObject o); 

TDomainObject GetObject(object container); 

... 

You will need to check if the “in container” functionality is supported; it is 

not available for all types. 

IActiveObjectService activeOS = PetrelSystem.ActiveObjectService; 

if(activeOS.CanGetActiveObjectInContainer()) 

{ 

IActiveObjectInContainer activeGridIC; 

activeGridIC = activeOS.GetActiveObjectInContainer(); 

object container = ...; 

Grid g = activeGridIC.GetObject(container); 

} 

You can also register for events when the active object changes for a specific 

object type, either for activation or deactivation. This functionality is 

available from IActiveObject. 

public interface IActiveObject 

{ 

... 

event 

EventHandler Activated; 

EventHandlerDeactivated; 

} 

Use the specialized event argument class to get the affected object or the 

container. 

public class ActivationChangeEventArgs : EventArgs 

{ 

TDomainObject AffectedObject { get; } 

object Container { get; } 

ActivationChangeEventArgs(TDomainObject affectedObj,object 

container); 

} 




You can register for activation or deactivation events or both. 

IActiveObject activeGrid; 

activeGrid = PetrelSystem.ActiveObjectService.GetActiveObject(); 

activeGrid.Activated += gridActivated; 

... 

void gridActivated(object s, ActivationChangeEventArgs args) 

{ 

PetrelLogger.InfoOutputWindow("Activated: " + 

args.AffectedObject.Name); 

} 






2 Borehole and Geology 


Well Domain ................................................................................................46 

Stratigraphy .................................................................................................67 

2: Borehole and Geology 45 



Well Domain 

The well domain deals with all the physical entities that are encountered in 

and around the wellbore during the exploration and production activities. 

surface location 

kelly bushing 

(MD reference datum) 

mean sea level 

(subsea reference datum) 

borehole 

well log 

well marker 

trajectory 

Fig. 2-1 

Well Presentation in Ocean 

Borehole 

A borehole is materialized by a trajectory that starts somewhere near the 

earth’s surface and traverses the reservoir. It is used to produce reservoir 

fluids and also to measure precisely the petrophysical properties of the 

reservoir along the borehole path. 



Well Domain 

The Borehole class and its associated classes are shown below: 

Marker 

* 

WellLog 

1 

* 1 

* 

1 

DictionaryWellLog 

* 

WellRoot 

Borehole 

1 

1 

1 

1 

BoreholeCollection 

Logs 

1 

1 

Trajectory 

MultitraceWellLog 

* 

* 

PointWellLog 

Fig. 2-2 

Well Domain Classes 

Borehole Collections 

Finding Boreholes in 

the Project 

The data model of Petrel is organized in a hierarchical manner. It is therefore 

essential for the user that boreholes be grouped in collections. In the Petrel 

data domain, borehole collections do not carry specific semantic meaning; 

they can represent a field, but they can also group boreholes by completion 

type (injectors vs. producers). The collection is merely a folder and the 

organization lies with the user. 

The borehole collections themselves represent a complex hierarchy. Borehole 

collections can contain other collections. There is only one borehole 

collection at the root, the main “Wells” folder. That collection is accessible 

from the API as a static property of the BoreholeCollection class. 

Ocean provides a convenience class, WellRoot, which provides navigation to 

domain objects in the well domain including BoreholeCollection and 

MarkerCollection objects. BoreholeCollection collections may be 

nested while MarkerCollection collections may not. All Borehole objects 

exist under a BoreholeCollection, which is an IEnumerable 

generic enumerable type. The collection can be traversed with a simple 

foreach loop. To retrieve boreholes contained in nested collections, we have 




to call the sub-collections recursively. This example traverses the whole 

borehole set of a project: 

using Slb.Ocean.Petrel.DomainObject.Well; 

{ 

... 

} 

// depth-first search traversal 

// of the Borehole collection hierarchy 

WellRoot wr = WellRoot.Get( PetrelProject.PrimaryProject ); 

BoreholeCollection bhc = wr.BoreholeCollection; 

// check that the top Borehole collection is valid 

// empty projects will have a top collection set to null 

if (bhc.IsGood) 

{ 

PrintBoreholes(bhc); 

} 

return; 

private void PrintBoreholes(BoreholeCollection bhc) 

{ 

int count = 0; 

} 

PetrelLogger.InfoOutputWindow(bhc.Name + " Collection :"); 

foreach (Borehole bh in bhc) 

{ 

PetrelLogger.InfoOutputWindow("Borehole " + bh.Name); 

count++; 

} 

if (count == 0) 

PetrelLogger.InfoOutputWindow("Empty"); 

if (bhc.BoreholeCollectionCount > 0) 

{ 

foreach (BoreholeCollection bc in bhc.BoreholeCollections) 

PrintBoreholes(bhc); 

} 

return; 

The Borehole search returns a complete list of Boreholes with their folders. 

Fig. 2-3 

Listing Boreholes in the Project 



Well Domain 

Wellbore Identifier 

A well or wellbore requires multiple candidate identifiers, usually referred to 

as aliases. While a single identifier for a well and wellbore may be sufficient 

within an organization or business function, the general Exploration & 

Production community must accommodate alternate names using various 

naming conventions. Some examples of the business requirements for 

multiple identifiers follow. 

With oil companies operating wells in many different regions of the world, 

the process of naming wells and keeping track of them in a database requires 

more complexity to handle the majority of cases. 

The unique names assigned by a company to its well prospects are different 

than the names derived for wells on a lease tract or connected to an offshore 

platform, which are in turn different from the unique names administered by 

a regulatory agency, data vendor, or industry standards organization. 

Many companies arrive at their own unique system of naming wells, while 

others adhere to some standard like American Petroleum Institute (API). 

Many times, multiple identifiers must be kept for each well to deal with the 

complexity. For example, an American-based oil company may use the API 

designation for wells, but when they begin exploration in Mexico, they will 

not be able to store their well data in the database by API number. Likewise, 

they may store by well name, so they could drill a well on the Smith lease and 

call it the Trilobite #1 Smith, but if they drill another well a few years later 

on a different Smith lease, it could also have the name Trilobite #1 Smith. 

The Ocean Borehole class identifies itself by Name. Naming is free of 

constraints, which is common usage in the industry. For keeping standard 

naming with the Project, we have a UWI property in the class. 

Public sealed class Borehole : IDomainObject, 

IDescriptionSource,... 

{ 

public string UWI { get; set; } 

} 

Creating a New 

Borehole 

Creation of a new Borehole is done from the BoreholeCollection that 

is to contain the resulting borehole. Borehole creation is kept simple. The 

borehole does not have a trajectory yet. This is added later. The borehole 

needs a surface location, stored in the WellHead property and a 




KellyBushing elevation (from sea level) to mark the origin of all measured 

depth references in the borehole. 


using Slb.Ocean.Geometry; 

WellRoot wr = WellRoot.Get( PetrelProject.PrimaryProject ); 

BoreholeCollection bhc = wr.BoreholeCollection; 

if (! Bhc.IsGood) return; 

using (ITransaction trans = 

DataManager.NewTransaction()) 

{ 

trans.Lock(bhc); 

string wellName = "AField1"; 

Borehole bh = bhc.CreateBorehole(wellName); 

bh.UWI = "WELL001"; 

bh.WellHead = new Point2 (1500.0, 1500.0); 

bh.KellyBushing = 200.0; 

} 

// Add Trajectory 

... 

Trajectory 

Trajectory is a class that contains the definition of a borehole path, 

sometimes referred to as a deviation survey. It contains all of the geometrical 

elements of the borehole path through the reservoir. 

A Trajectory is a collection of trajectory records contained in 

TrajectoryRecord structures. The TrajectoryRecord structure has 

measured depth, azimuth, and inclination measurements. These are the raw 

records measured in the field from which the trajectory is computed. When a 

Borehole is created, the array of TrajectoryRecord structures may be 

appended after the WellHead and KellyBushing properties of the 

Borehole object have been set. 

public struct TrajectoryRecord 

{ 

public TrajectoryRecord ( double md, double inclination, 

double azimuth ); 

} 

public double MD { get; } 

public double Inclination { get; } 

public double Azimuth { get; } 

An alternative method of creating a borehole trajectory is to use the 

Trajectory class AppendPolyline method to derive the 

TrajectoryRecord values from a Polyline3 object. 



Well Domain 

The following code sample shows both methods of creating a borehole 

trajectory for the Borehole object in the previous sample. 


// Create array of TrajectoryRecords 

TrajectoryRecord[] traj = new TrajectoryRecord[numPts]; 

// Fill array values. 

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

{ 

double md = ...; 

double inclindation = ...; 

double azimuth = ...; 

traj[i] = new TrajectoryRecord( md, inclination, azimuth ); 

} 

// Append trajectory records to trajectory 

bh.Trajectory.Append( traj ); 

Borehole bh2 = ...; 

IPolyline3 polyline = ...; 

bh2.Trajectory.AppendPolyline( polyline ); 

We can access the Trajectory points for a Borehole by processing the 

TrajectoryRecord points in the Trajectory. 

// Printing the Trajectory to the Message log window 

Trajectory traj = bh.Trajectory; 

int i = 0; 

foreach (TrajectoryRecord tr in traj.Records) 

{ 

i++; 

PetrelLogger.InfoOutputWindow("Record no " + i + 

tr.Azimuth + ", " + 

tr.Inclination + ", at " + 

tr.MD); 

} 

Domain Transforms 

Points along the trajectory have to be retrieved in measured depth or in X, Y, 

Z to tie to other objects in the model. The Borehole API provides a 




transform method to retrieve trajectory points in all the domains listed under 

the Domain class. 

double MD = 0.0, X, Y, maxMD = 

bh.MDRange.Max; 

int index = 0; 

while (MD < maxMD) 

{ 

MD = bh.Transform(Domain.INDEX, 

(double)index, Domain.MD); 

X = bh.Transform(Domain.INDEX, 

(double)index, Domain.X); 

Y = bh.Transform(Domain.INDEX, 

(double)index, Domain.Y); 

PetrelLogger.InfoOutputWindow("coordinates 

at " + MD + 

" : X = " + X + " Y = " + Y); 

index++; 

} 

Fig. 2-4 

Borehole Transforms 

Checkshot Survey 

Ocean provides access to time-to-depth relationship data through the 

CheckShot domain object. A CheckShot object has a set of 



Well Domain 

WellLogSample objects that contain measured depth and two-way time 

values. The CheckShot class is defined as: 

public sealed class CheckShot : FacadeConvenience, IDomainObject, 

IDescriptionSource, 

IPropertyVersionContainer, 

IIdentifiable 

{ 

public IEnumerable BooleanProperties { get; } 

public int BooleanPropertyCount { get; } 

public Borehole Borehole { get; } 

public IDescription Description { get; } 

public int DictionaryPropertyVersionCount { get; } 


DictionaryPropertyVersions { get; } 

public Droid Droid { get; } 

public override LastModifiedInfo LastModified { get; } 

public static CheckShot NullObject { get; } 

public int PropertyVersionCount { get; } 

public IEnumerable PropertyVersions { get; } 

public int SampleCount { get; } 

public IEnumerable Samples { get; set; } 

public IEnumerable StringProperties { get; } 

public int StringPropertyCount { get; } 

public static int UndefinedDictionaryPropertyValue { get; } 

public PropertyVersion WellLogVersion { get; } 

public WellLogSample this[int index] { get; } 

public void Append ( IEnumerable stream ); 

public void CreateBooleanProperty ( string name ); 

public DictionaryPropertyVersion CreateDictionaryProperty ( 

DictionaryPropertyVersion property ); 

public PropertyVersion CreateProperty ( PropertyVersion property 

); 

public void CreateStringProperty ( string name ); 

public void Delete ( ); 

public bool GetBooleanProperty ( string property, double md ); 

public bool GetBooleanProperty ( string property, 

WellLogSample atSample ); 




public int GetDictionaryProperty ( 

DictionaryPropertyVersion property, double md ); 

public int GetDictionaryProperty ( 

DictionaryPropertyVersion property, 


public double GetProperty ( PropertyVersion property, double md 

); 

public double GetProperty ( PropertyVersion property, 


public string GetStringProperty ( string property, double md ); 

public string GetStringProperty ( string property, 


public static bool IsUndefinedDictionaryPropertyValue ( int 

value ); 

public bool IsWritableBooleanProperty ( string property, 

double md ); 

public bool IsWritableBooleanProperty ( string property, 

WellLogSample atSample 

); 

public bool IsWritableDictionaryProperty ( 

DictionaryPropertyVersion property, double md ); 

public bool IsWritableDictionaryProperty ( 



public bool IsWritableProperty ( PropertyVersion property, 

double md ); 

public bool IsWritableProperty ( PropertyVersion property, 


public bool IsWritableStringProperty ( string property, double 

md ); 

public bool IsWritableStringProperty ( string property, 


public void SetBooleanProperty ( string property, double md, 

bool propertyValue ); 

public void SetBooleanProperty ( string property, 

WellLogSample atSample, 

bool propertyValue ); 

public void SetDictionaryProperty ( 


double md, int propertyValue ); 

public void SetDictionaryProperty ( 


WellLogSample atSample, int propertyValue ); 

public void SetProperty ( PropertyVersion property, double md, 

double propertyValue ); 

public void SetProperty ( PropertyVersion property, 



public void SetStringProperty ( string property, double md, 

string propertyValue ); 

public void SetStringProperty ( string property, 


string propertyValue ); 

) 



Well Domain 

Creating Checkshot 

Surveys 

CheckShot domain objects are created by first creating a PropertyVersion 

for the checkshot. The property version is created under the root object for 

the wells, which must be locked in transaction. 

Using (Itransaction tr = DataManager.NewTransaction()) 

{ 

// Find root of all wells 

WellRoot wr = WellRoot.Get( PetrelSystem.PrimaryProject ); 

// lock the root object 

tr.Lock( wr ); 

// create the property version for the checkshot 

PropertyVersion pv = wr.CreateCheckShotVersion( "CheckShot" ); 

... 

Next the PropertyVersion is used to create the CheckShot using the 

CreateCheckShot method under the Logs class. At this point the borehole 

must be locked since we are creating a new object under it. 

... 

// Get borehole from user 

Borehole borehole = ...; 

// Lock the borehole 

tr.Lock( borehole ); 

// Create the checkshot using the property version created earlier 

CheckShot cs = borehole.Logs.CreateCheckShot( pv ); 

... 

The data for the CheckShot object is contained in an array of 

WellLogSample structures. The WellLogSample structure is also used to 

contain well logs for the borehole; therefore, the checkshot resembles a log 

curve in its construction. The WellLogSample struct is defined as: 

public struct WellLogSample 

{ 

public WellLogSample ( double md, float val ); 

} 

[UnitMeasurement( "Standard_Depth_Index" )] 

public double MD { get; } 

public float Value { get; } 

WellLogSample uses a UnitMeasurement attribute to define the units for 

the MD value. The MD, or Measured Depth, value is the distance from the 

surface location of the borehole of the point represented by this instance of 

the WellLogSample struct. 

The array of WellLogSample structs must have their MD values in ascending 

order and may not have duplicate MD values. The entire array of structs must 

be created and set for the CheckShot at once. You cannot insert individual 

entries into the CheckShot Samples property. 




Once the Samples property for the CheckShot has been set, the borehole 

may activate the CheckShot for use. When the CheckShot is activated, it 

will become the preferred depth to time relationship for the borehole. 

} 

... 

// Create array of WellLogSamples to hold data 

WellLogSample[] values = new WellLogSamples[ numberOfSamples ]; 

... 

// Add the WellLogSample for this depth 

values[i] = new WellLogSample( MD_val, time_val ); 

... 

// Set the Samples property to the wellLogSamples created 

cs.Samples = values; 

// Make this the active depth/time relationship for the borehole 

borehole.ActivateCheckShot( cs ); 

// Commit the property version and checkshot creation 

tr.Commit(); 

Accessing Checkshot Surveys 

Programatically CheckShot objects are found with the logs for a borehole 

under the Logs class (Borehole.Logs.). The corresponding data for the 

CheckShot is found under the Global Well Logs in the Petrel Explorer Input 

data tab. With regard to CheckShot objects, the Logs class definition is as 

follows: 

public sealed class Logs : IExtensionSource, ILockObjectProvider, 

IEventConsumer 

{ 

public int CheckShotCount { get; } 

public IEnumerable CheckShots { get; } 

public int CheckShotVersionCount { get; } 

public IEnumerable CheckShotVersions { get; } 

public event 

EventHandler 

CheckShotsChanged; 

public CheckShot CreateCheckShot(PropertyVersion 

CheckShotVersion); 

... 

} 



Well Domain 

Given a borehole, we can find its checkshot surveys and the data they 

contain by doing the following: 

... 


// Indicate number of checkshot surveys the borehole contains. 

PetrelLogger.InfoOutputWindow ("Borehole contains " + 

bh.Logs.CheckShotCount + 

" checkshot surveys."); 

// Process each checkshot 

foreach (CheckShot cs in bh.Logs.CheckShots) 

{ 

// Indicate number of data samples in the checkshot 

PetrelLogger.InfoOutputWindow("Checkshot contains " + 

cs.SampleCount + 

" samples."); 

} 

// Process each sample. 

foreach (WellLogSample wls in cs.Samples) 

{ 

... 

} 

Adding Properties to Checkshot Surveys 

CheckShot objects may be extended by properties. The properties added to 

a CheckShot can contain float, int, bool, or string values. The float 

and int properties are normal Ocean Property or DictionaryProperty 

objects that require a PropertyVersion or DictionaryPropertyVersion 

to create. The bool and string property types require only a name when 

created. In all cases the property values are placed at the MD values defined by 

the CheckShot Samples. You cannot place property values at locations 

other than the defined MD values. 

The data for the CheckShot must be added to the CheckShot before any 

property can be added. Adding the WellLogSample data for the CheckShot 

is shown in the earlier example code. With the data in place the desired 




property can be created. Here is an example adding a Boolean property to a 

CheckShot. 

CheckShot chk = ...; 

Borehole borehole = chk.Borehole; 

// Name for our property. Indicates inclinations < 30 degrees 

string sIncl = "Inclination < 30"; 

// some needed constants 

const int PI_DEGREES = 180; 

const int LIMITING_ANGLE = 30; 

using (ITransaction tr = DataManager.NewTransaction() ) 

{ 

tr.Lock(chk); 

// Create the property using the name. 

chk.CreateBooleanProperty( sIncl ); 

// Process each checkshot sample 

foreach ( WellLogSample sample in chk.Samples) 

{ 

} 

// Get the inclination of the point at the MD 

double incl = borehole.Transform( Domain.MD, sample.MD, 

Domain.INCLINATION ); 

// Compute the value in degrees 

double angle = ( PI_DEGREES * incl ) / Math.PI; 

// Check the value and set the property at this MD. 

if ( angle < LIMITING_ANGLE ) 

{ 

chk.SetBooleanProperty( sIncl, sample.MD, true ); 

} 

else 

{ 

chk.SetBooleanProperty( sIncl, sample.MD, false); 

} 

tr.Commit(); 

} 

There is no limit to the number of properties that may be added to a 

CheckShot object. The API provides a count of each type available and an 

enumerable property. A set of "Get" methods provides access to the 



Well Domain 

property data. Here is a sample that reads the Boolean property created 

above. 

CheckShot chk = ...; 

// Name of property used when it was created. 

string sIncl = "Inclination < 30"; 

// Check the count of boolean properties 

if ( chk.BooleanPropertyCount >= 1) 

{ 

// Look for the name of our property 

foreach ( string sProp in chk.BooleanProperties ) 

{ 

// Use the name to see if we have a match 

if ( sProp.Equals( sIncl ) ) 

{ 

// Process the samples. 

foreach ( WellLogSample sample in chk.Samples ) 

{ 

// Check sample. If inclination < 30, it should be true. 

if ( chk.GetBooleanProperty( sIncl, sample ) == true ) 

{ 

... 

} 

else 

{ 

... 

} 

break; 

} 

} 

} 

} 




Borehole Example 

Retrieving the Farthest Point along the Path 

In this example, a Borehole Trajectory is retrieved and transformed to 

the X and Y domains to project the trajectory on the horizontal plane. The 

point farthest away from the surface location is returned. 



Borehole bore = ...; 

Point2 wHead = bore.WellHead; 

Range1 mdr = bore.MDRange; 

Domain dIndex = Domain.INDEX; 

double maxIndex = bore.Transform(Domain.MD, 

mdr.Max, dIndex); 

int maxI = (int)maxIndex; 

double maxX, maxY; 

double dx = 0.0, dy = 0.0, d = 0.0, dist = 

0.0; 

for (int i = 0; i dist) 

{ 

maxX = Math.Abs(dx); 

maxY = Math.Abs(dy); 

dist = d; 

} 

} 

Well Completion 

Well completions refer to a depth range within a well. They can only be read 

via Ocean. Each object has a name and a depth range. 



int wci = 0; 

foreach (WellCompletion wc in bh.Completions) 

{ 

wci++; 

PetrelLogger.InfoOutputWindow("Completion 

no " + wci + ": " 

+ wc.Name + " from " + wc.StartMD + " to 

" + wc.EndMD); 

} 

Well Log 

WellLog contains the property values measured along the borehole path. 

They represent the property type object when the borehole is the geometrical 

entity, a partial view of the reservoir. WellLogs always refer to a 

PropertyVersion. 



Well Domain 


type (facies) 

WellLog type 

(porosity) 

Fig. 2-5 

Well Log Types 

There are two types of logs (for 1D log arrays): 

4. WellLog 

5. DictionaryWellLog 

WellLog represents a continuous log of Property values that cover a wide 

float range. It refers to a PropertyVersion for its template and 

classification. 

DictionaryWellLog is an array of integer values taken from an enumerated 

list of codes. These codes are defined in a DictionaryPropertyVersion. 




Creating a New WellLog 

Creating a new WellLog requires a PropertyVersion, built from an 

ILogTemplate (global well log). The global well log must be uniquely 

represented in the Borehole where the log is created. 




string name = ...; 

int numpoints = ...; 

double interval = ..., top = ...; 



{ 



ILogTemplate glob = 

pvs.FindTemplateByMnemonics("Porosity"); 


pvs.FindOrCreate(glob); 

trans.Lock(bh); 

WellLog log = bh.Logs.CreateWellLog(pv); 

// Build a time array to serve as time log 

WellLogSample[] tsamples = new 

WellLogSample[numpoints]; 

} 

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

{ 

double md = top + i * interval; 

float val = ...; 

tsamples[i] = new WellLogSample(md, val); 

} 

log.Samples = tsamples; 



DictionaryWellLogs behave exactly like the WellLogs except that they are 

filled with integer values and refer to a DictionaryPropertyVersion. 

The integer values that fill the log array are entries into a dictionary that 

converts these values into codes defined by string values. The codes are 

assigned contiguous ordinal numbers so that there is no missing integer value 

in the enumeration of codes and the total number of available codes is equal 

to the largest valid integer value plus one (counting starts at zero). 

New codes may be added by supplying a string value to the AddFacies 

method. This new code will be assigned to the next available integer value. 



Well Domain 

There is a way to find the Dictionary color table entry and pattern 

corresponding to a given code. 



DictionaryWellLog log = ...; 

IDictionaryColorTable dct; 

DictionaryPropertyVersion pv = 

log.DictionaryWellLogVersion; 

dct = 

PetrelSystem.ColorTableService.GetColorTable 

(pv); 

foreach (DictionaryWellLogSample dwls in 

log.Samples) 

{ 

if (!dwls.IsUndefinedValue()) 

{ 

DictionaryColorTableEntry dce = 

dct.Transform(dwls.Value); 

PetrelLogger.InfoOutputWindow(string.Format( 

"MD:{0}: {1} [{2}]", 

dwls.MD, dce.Name, dce.Color)); 

} 

} 

MultiTraceWellLog 

MultiTraceWellLog objects are logs where each sample contains an array 

of float values. The size of the array is constant throughout the log. Multitrace 

logs are used to record borehole electrical images for instance. They are 

accessible via the API like any normal log. 

Their individual samples are MultiTraceWellLogSample, a struct 

composed of a depth member (expressed in measured depth) and a Value 

array. It is reasonable to expect that the array of floats has a constant 

length throughout the collection of samples; however, this is not required by 

the API (or by Petrel). 

PointWellLog 

Fig. 2-6 

PointWellLog Domain Object 




The Well namespace provides the PointWellLog class to allow the user to 

place points on a borehole trajectory that are not related to horizons, 

surfaces, or faults. The points in a PointWellLog indicate points of interest 

for the user. When rendered they are displayed as discrete points not a log 

polyline. They may have properties attached to them in the form of string, 

Booleans, DictionaryProperty, or Property objects. The PointWellLog 

class definition is as follows: 

public sealed class PointWellLog : ... 

{ 

... 



public IEnumerable Samples { 

get; set; } 

public WellLogSample this[int index] { get; 

} 

public void Append ( 

IEnumerable stream ); 

public int PropertyVersionCount { get; } 


PropertyVersions { get; } 

public PropertyVersion CreateProperty ( 

PropertyVersion property); 

public double GetProperty ( PropertyVersion 

property, double md ); 

public double GetProperty ( PropertyVersion 

property, 


public void SetProperty ( PropertyVersion 

property, double md, 


public void SetProperty ( PropertyVersion 

property, 

WellLogSample 

atSample, 

double 

propertyValue ); 

... 

} 

PointWellLog domain objects are created from the Logs class just like 

WellLog and DictionaryWellLog domain objects. They require a property 

version, which is created from a string passed to the 



Well Domain 

WellRoot.CreatePointWellLogVersion method. Here is an example 

creating a PointWellLog. 


Using ITransaction tr = 

DataManager.NewTransaction( )) 

{ 

// Lock WellRoot to create the property 

version 

WellRoot wr = WellRoot.Get( 

PetrelProject.PrimaryProject ); 

Tr.Lock( wr ); 

// Create the property version 


wr.CreatePointWellLogVersion(“Pt Well Log”); 

// Lock the borehole to create the 

PointWellLog 

Tr.Lock( bh ); 

// Create the PointWellLog 

PointWellLog pwl = 

bh.Logs.CreatePointWellLog( pv ); 

} 

... 

The data for PointWellLog domain objects is stored in an array of 

WellLogSample structures. Each WellLogSample structure contains a 

measured depth and a data value. As with WellLog objects, the array of 

WellLogSample structures is created and then added in its entirety to the 

PointWellLog. The array of structures must have strictly increasing 

measured depth values. The code for this might look something like the 

following. 

... 

// Create list of WellLogSample structs 

List wls = new 

List( ); 

// Fill in data inside some kind of loop 

for (...) 

{ 

md = ...; 

// create this entry for list 

WellLogSample sample = new 

WellLogSample( md, (float)value ); 

} 

// Add sample to list 

Wls.Add( sample ); 

// Add list to PointWellLog 

pwl.Samples = wls; 

} 

... 




The PointWellLog object, having just been created in the previous sample, 

is implicitly locked in this sample. 

PointWellLog domain objects may be extended by the addition of 

properties. The properties may be in the form of Boolean, 

DictionaryPropertyVersion, String, or normal PropertyVersion 

types. Multiple properties may be added to a PointWellLog object. Normal 

Property and DictionaryProperty additions require a 

PropertyVersion or DictionaryPropertyVersion for creation. The 

Boolean and String property additions require a name defined by a string. 

Here is an example creating a porosity property and a Boolean property for 

the PointWellLog. 

... 

double myValue = ...; 

// Get the Property Version service 

PropertyVersionService pvs = 


// Use the porosity template to create a 

property version. 

ITemplate pt = pvs.FindTemplate( “Porosity” 

); 

PropertyVersion pv = pvs.FindOrCreate( null, 

pt ); 

// Create the property under our PointWellLog 

PropertyVersion myProperty = 

pwl.CreateProperty( pv ); 

// Assign the property version a name 

myProperty.Name = “Porosity”; 

// Assign values to the new property 

foreach (WellLogSample sample in pwl.Samples) 

{ 

pwl.SetProperty( myProperty, sample, 

myValue ); 

} 

... 

// Create a Boolean property 

pwl.CreateBooleanProperty( “TF_Test” ); 

// Assign true or false to the property 

samples 

foreach (WellLogSample sample in pwl.Samples) 

{ 

// Perform some test. If true, then set 

property true. 

if (...) 

{ 

pwl.SetBooleanProperty( “TF_Test”, 

sample.MD, true ); 

} 

else 

{ 

pwl.SetBooleanProperty( “TF_Test”, sample.MD, 

false ); 

} 

... 

} 



Stratigraphy 

Stratigraphy 

Fig. 2-7 

Stratigraphy 

The Stratigraphy Domain models all the physical entities used by geologists 

to understand the reservoir structure. These objects are related to the 

structural domain, but they serve merely as references for well data such as 

markers. 

Horizons and Zones are named here and tied to the seismic interpretation 

later by matching the well markers with the seismic horizons and faults. 

The Ocean API lets an application build an entire stratigraphic model. 

MarkerCollection 

Borehole 

Marker 

Property 

Surface 

Horizon 

Interface 

Fault 

Fig. 2-8 

Stratigraphy Classes 




Markers 

Horizon 

A Marker is a point on a well trajectory that is associated with some 

recognizable event, such as a geological top pick or a geophysical horizon. 

Many different disciplines within the Exploration and Production community 

use well markers. We must distinguish between several types of markers, 

depending on the type of surface it characterizes. 

The well marker is modeled as the intersection of a well trajectory and a 

Surface (Horizon, Interface, or Fault). A single surface will have 

similar types of well markers across wells. For example, if a fault intersects 

multiple well trajectories, it will be characterized with fault markers at the 

intersection with the boreholes. 

Horizons are part of the stratigraphy folder (MarkerCollection). They can 

be created in the Collection and then used to create markers in boreholes. 

They only serve as a common reference to all markers, from different 

boreholes that observe the same geological event. 

Horizons are characterized by type and stored in property 

Horizon.HorizonType which returns an enum HorizonType. 

public enum HorizonType 

{ 

Unknown, 

Conformable, 

Erosional, 

Base, 

Discont 

} 

Fault 

Zone 

Slb.Ocean.Petrel.DomainObject.Well.Fault links together all the 

Markers from different Boreholes that mark the presence of the same 

Fault. 

Fault only carries a Name property. It is created from the 

MarkerCollection object, which serves as a container for the stratigraphy 

column. 

Zone is an element of the stratigraphic layer hierarchy. It has a top and a 

bottom Horizon and a Name. 

Note that the Name may not be unique and can be changed by the Petrel user. 

Do not use it as a key. 

namespace Slb.Ocean.Petrel.DomainObject.Well 

{ 

public sealed class Zone 

{ 

public Horizon Base { get; } 

public string Comments { get; 

set; } 

public IDescription Description { get; } 

public string Name { get; set; 

} 

public Horizon Top { get; } 

} 

} 



Stratigraphy 

Creating a Stratigraphy 

Column 

The following example creates a new stratigraphy column and corresponding 

Markers in a given Borehole. 




// Create a Stratigraphy column and 

corresponding Markers in Borehole 

using (ITransaction t = 


{ 

// Find root of all wells 

WellRoot wr = WellRoot.Get( PetrelSystem.PrimaryProject ); 

// lock the root object 

t.Lock( wr ); 

// Create a new stratigraphy collection 

Project proj = 

PetrelProject.PrimaryProject; 

MarkerCollection mc = 

MarkerCollection.Create("Litho", proj); 

Zone[] zoneList = new Zone[4]; 

Horizon[] horList = new Horizon[5]; 

// Create Base Horizon 

horList[1] = mc.CreateFirstHorizon(); 

horList[1].HorizonType = 

HorizonType.Conformable; 

horList[1].Name = "Top Pay Zone"; 

// Create Fault 

Fault f = mc.CreateFault(); 

f.Name = "Main"; 

// First, create Pay Zone 

mc.CreateZoneAndHorizonBelow(horList[1], 

out zoneList[0], 

out horList[0]); 

zoneList[0].Name = "Pay Zone"; 

horList[0].Name = "Bottom Pay Zone"; 

horList[0].HorizonType = HorizonType.Base; 

// Add 3 Zones on top of Pay Zone 

for (int i = 1; i < 4; i++) 

{ 

mc.CreateZoneAndHorizonAbove(horList[i], 

out zoneList[i], out horList[i + 1]); 

zoneList[i].Name = "Zone " + i; 

horList[i].Name = "Top of Zone " + i; 

horList[i + 1].HorizonType = 

HorizonType.Conformable; 

} 




// Create Markers in Borehole for Fault 

mc.CreateMarker(bh, f, 1850); 

// Create Markers in Borehole for Horizons 

double[] md = {1980, 1920, 1870, 1848, 

1824}; 

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

{ 

mc.CreateMarker(bh, horList[i], md[i]); 

} 

t.Commit(); 

} 



3 Structural Domain 


Shapes .......................................................................................................72 

Surface..................................................................................................73 

PointSet.................................................................................................76 

3: Structural Domain 71 



The structural model is derived from both geological and geophysical 

interpretations around the reservoir. The structural model fills the gap where 

data is incomplete and builds the first volumes representing the formations 

in the underground. This is an essential step towards reservoir modeling. 

Fig. 3-1 

Structural Model 

Shapes 

Shapes are simple structural elements that are available in the Petrel domain 

model today. They are the input used by the user to build the static reservoir 

model. Shapes can be read, created, and updated. Property fields can be 

added to Surfaces and PointSets. The shape classes are Surface, 

PolylineSet, and PointSet. 

All three classes have a Domain property that specifies whether the shape is 

specified in two-way seismic travel time or in depth. 



Shapes 

DictionarySurfaceProperty 

Surface 

SurfaceProperty 

PolylineSet 

Polyline 

PointPropertyRecord 

PointProperty 

PointSet 

DictionaryPointProperty 

Fig. 3-2 

Shapes 

Surface 

A surface is a (usually gridded) height field. If a geologist is working on an 

area that has markers for 15 wells, 8 of the wells may be clustered fairly close 

together in a field, with the other wells widely scattered. In order to obtain a 

visual representation of the surface, the geologist thinks about the type of 

depositional environment that is represented and threads contours through 

the data points in order to have an idea of the subsurface that is represented. 

However, this technique is difficult for computers to emulate. Grids were 

developed as a convenient way for computers to turn data that may be 

irregularly spaced into a continuous surface model of regularly spaced points. 

Gridding algorithms were developed with a great deal of sophistication and 

flexibility in order to convert random data into data that is fairly distributed. 

If you think of plotting the well data on a piece of graph paper, the 

intersections of the x-axis and the y-axis would represent a grid node 

location. The third dimension (z) would represent time, depth, porosity, and 

so on, depending on the data that is being gridded. A grid will have a data 

value calculated for each grid node by using the original data as a starting 

point. 

Different gridding algorithms are available, with their own particular 

parameters, which may be changed in order to have the resulting grid fit the 

data in the best manner. Grids are one of the most fundamental building 

blocks of data in Exploration and Production work and are particularly 

valuable for the creation of contour maps, 3D model visualization of the 

surfaces, and display of the surfaces in cross section. In addition, they allow 

volumetrics to be calculated. 

The most common type of grid used is a rectilinear or Cartesian grid. The X 

and Y increments do not need to be the same, but they usually are. For 




Creating a New Surface 

example, the X grid increment may be 100 and the Y grid increment may be 

125. 

All gridded shapes in the Petrel data domain use Cartesian grids. The points 

in the surface object were interpolated from the original set of points to have 

a height field value at each node of a 2D lattice. 

The difference between a Surface and a seismic HorizonInterpretation 

is that the Surface does not have to be consistent with a seismic Survey, 

and it has a calculated height for each node in the lattice. There may be 

“holes” in the surface (absent values, in the form of float.NaN), but these 

holes mean real holes in the surface. However, when in a 

HorizonInterpretation, the holes just show points that have not yet been 

interpreted. 

Surfaces are found under surface collections. These are placed at the top level 

of the Input data tree of Petrel. New Collections cannot be created, but 

Surfaces can be added to existing Collections. 

The next version will handle height fields in a more specific manner. 

It is possible to create a new surface, given a surface collection. This is done 

by creating the Surface object first, then setting the height field. 

using Slb.Ocean.Basics; 



using Slb.Ocean.Petrel.DomainObject.Shapes; 



{ 

// Create a new Surface collection in the 

Input data tree 

Project proj = PetrelProject.PrimaryProject; 

trans.Lock(proj); 

Collection col = proj.CreateCollection("Surfaces"); 

int numi = 100, numj = 100; 

double rotation = 0, spacingX = 25,spacingY = 50; 

Point2 origin = new Point2(458000,6780000); 

RegularHeightFieldSurface surf; 

surf = col.CreateRegularHeightFieldSurface("Test", 

new LatticeInfo(origin.X, origin.Y, 

spacingX, spacingY, rotation, true, 

numi, numj, false, 0, 0, numi, numj)); 

} 

for (int j = 0; j < numj; j++) 

{ 

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

{ 

// give a sinusoidal shape to the Surface in both directions 

surf[i, j] = -1800 + 25 * 

(1 - Math.Cos(i * 2 * Math.PI / numi)) * 

(1 - Math.Cos(j * 2 * Math.PI / numj)); 

} 

surf.Name = "New Surface"; 


} 



Shapes 

Fig. 3-3 

Surface 

PolylineSet 

A polyline set is another possible representation for a surface that has not 

been interpolated using a horizontal grid. It is used to represent fault 

surfaces, but the object can represent any polyline collection. 

A polyline set differs from a fault interpretation in that it does not have to be 

consistent with a seismic survey geometry. 

PolylineSet contains an enumeration of polylines via its Polylines 

property. There is also an indexer in the class. 


PolylineSet pls = ...; 

int index = ...; 

IPolyline3 pl = pls[index]; 

Creating a New 

PolylineSet 

The API allows the creation of a new set of polylines, given a collection in 

the Petrel Input tree. 





double x0 = ..., y0 = ...; 



{ 

Collection scol = ...; 

trans.Lock(scol); 




PolylineSet pls = PolylineSet.Create(scol); 

IPolyline3 [] pllist = new IPolyline3[5]; 

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

{ 

Point3 [] pts = new Point3[10]; 

double startx = x0 + 10 * i; 

double starty = y0 + 10 * i; 

for (int j = 0; j < 10; j++) 

{ 

double delta = 100 * Math.Cos(j * Math.PI / 10); 

pts[j] = new Point3(startx + delta, starty + delta, 

-2000 + 10*j); 

} 

pllist[i] = new Polyline3 (pts); 

} 

pls.Polylines = pllist; 


} 

Fig. 3-4 

PolylineSet 

PointSet 

A point set is the simplest structural domain element accessible via the API. 

It is simply built from a list of XYZ points and added to a Collection in 

the Petrel Input tree. 



Shapes 

Creating a PointSet 

PointSet creation is possible by specifying the containing collection. The 

PointSet instance is created first, and then the set of points is added to the 

object. 





double x0 = ..., y0 = ...; 



{ 

Collection scol = ...; 

trans.Lock(scol); 

PointSet ps = PointSet.Create(scol); 

Point3 [] points = new Point3[5]; 

double originz = -1900; 

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

{ 

points[i] = new Point3 (x0 + 10 * i, 

y0 + 10 * i, 

originz + 10 * i); 

} 

ps.Points = new Point3Set(points); 


} 

Fig. 3-5 

PointSet 






4 Seismic and the Geophysical Domain 


Seismic Datasets ..........................................................................................80 

Seismic Interpretation.................................................................................108 

4: Seismic and the Geophysical Domain 79 



Seismic Datasets 

3D volume 

2D lines 

Fig. 4-1 


Geophysicists evaluate the reservoir by interpreting seismic reflections 

measured from the surface. This investigation method is less precise but 

covers a greater area than measurements done at the well for a far lesser cost. 

The user interprets some geologic features such as horizons and faults from 

these measurements, which are stored in the Petrel project as seismic 

datasets. The horizons and faults are built from points picked on reflectors 

that the user discovers in the graphical representation of the seismic data. 

Seismic Concepts 

Seismic data represent amplitude measured on seismic reflectors at given 

points in space. 

The reflector depth is characterized by the length on the time scale of the 

seismic wave from the source to the reflector echo. This distance is measured 

in milliseconds and represents two-way time or the time the seismic sound 

wave takes to go from the source to the reflector and back. Seismic data is 

digitized, and each sample is separated from the next by a sample interval, 

usually expressed in milliseconds. 

When the interpreter has built a comprehensive velocity model (i.e. when the 

sound wave travel time is known throughout the seismic measure range) the 

seismic data can be converted to depth. In Ocean, we read and create Seismic 

data in two-way time or in depth. 

For depth seismic to be available through the API, it has to have been either 

loaded or realized from depth conversion by the Petrel user. 

Seismic data is recorded in 2D or 3D surveys. These surveys are materialized 

in the Input data tree as Seismic folders (SeismicCollection instances in 

the API). 




Seismic Terms 

3D Survey 

3D Survey map 

Fig. 4-2 

Map view of 3D seismic survey 

3D data is binned, which means that each trace is stacked with all the other 

traces that fall inside the same cell of the 3D survey map. 3D data is 

therefore perfectly aligned, each node being defined by a lattice with an 

origin, spacings for inlines and crosslines, and a rotation angle. 

2D Survey 

2D Survey map 

Fig. 4-3 

Map view of 2D seismic survey 

2D surveys have exact geographical positions for each shot point. These 

positions are recorded while shooting the seismic and later loaded from 

navigation files. They are also part of the dataset description in the SEG-Y 

format. The particularity of 2D lines is that they are not showing as straight 

lines. 




Seismic Trace 

sample 

trace 

Seismic trace 

Fig. 4-4 

Color filled representation of seismic trace 

Each seismic trace is an array of amplitude (or other property) data values. 

Each trace in a survey will hold the same number of samples. 

Seismic Section 

Fig. 4-5 

Seismic line displayed in Interpretation window 

Seismic data is presented in an Interpretation window one section at a time. 

One section holds one 2D line or a specific section in the 3D cube: an inline, 

a crossline, or a time slice. 

Seismic Cube 

3D seismic cubes hold one amplitude value in each cell of a 3D lattice. 


9x11x16 amplitude cube 

Fig. 4-6 

Representation of 3D seismic data 




We find two types of field-recorded datasets in the Petrel Input tree: 

• 3D cubes 

• 2D lines 

SeismicCube 

In a 3D cube the seismic traces are binned, which means they are gathered, 

bin by bin in a lattice. All traces that fall in the same bin will be stacked 

together. 

lines from 3D 

volume 

lines from 3D 

sub-volume 

Fig. 4-7 

Seismic Cube 

The 3D cube lattice arrangement makes it easy to specify in space where 

each piece of seismic data resides. The lattice is regular and all we have to 

specify is an origin, an orientation, steps in the inline and the crossline 

directions, the number of shot points per inline, and the number of inlines 

per crossline. 

SeismicLine2D 

A 2D line is a dataset where a lesser number of shots are fired. The shots are 

placed in a line showing the actual position of the recording equipment. 




In a 2D line, the navigation data is loaded on top of the seismic amplitude 

data. For this reason, the API allows the user to clone a line but not to create 

one from scratch. 

Fig. 4-8 

2D Seismic Dataset 

SeismicCollection 

All seismic data is stored under a Seismic collection instance. All 3D cubes 

under the same collection will share the same lattice. 

Since Petrel 2007, Seismic collections are specialized, as they contain either 

3D or 2D datasets. They carry the property MemberType that lets the 

application distinguish between 2D and 3D collections. Many 2D surveys can 

be stored under the same (2D) collection, as there is no constraint on the 

shot locations. 

The following code example illustrates determining the type of data 

contained in a collection. 

using Slb.Ocean.Petrel.DomainObject.Seismic; 

public void Find3D() 

{ 

SeismicProject proj = 

SeismicRoot.Get(PetrelProject.PrimaryProject 

); 

if (!proj.IsGood) return; 

foreach (SeismicCollection col in proj.SeismicCollections) 

{ 

if (scol.MemberType == typeof(SeismicCube)) 

{ 

... 

} 

} 

} 




collection of 3D cubes 

and groups of 2D lines 

volume of 3D 

seismic traces 


group of 2D lines 

SeismicCube 

SeismicLine2DCollection 

SeismicLine3D 

SeismicLine2D 

3D 

inline 

or 

Xline 

Fig. 4-9 

Seismic Data Classes 

ITrace 

2D line of 

seismic traces 

individual indexed trace 

Individual traces are accessed from SeismicCube, SeismicLine3D, or 

SeismicLine2D either via an enumerator, Traces, or a function, GetTrace, 

which provides random order access. The samples inside the ITrace object 

are returned as an array. 

The seismic collection not only serves as a lattice definition for the 3D 

survey, but also as a container for datasets in the Petrel Input data tree. 


SeismicCube 

SeismicLine2DCollection 

Fig. 4-10 Seismic Data Layout 




Accessing Seismic Data 

Collection to Cube 

A seismic collection may contain many 3D cubes (based on consistent 

lattices). 


SeismicCollection sData = ...; 

IEnumerable all3D = sData.SeismicCubes; 

PetrelLogger.InfoOutputWindow("All cubes in " + sData.Name); 

foreach (SeismicCube one3D in all3D) 

{ 

PetrelLogger.InfoOutputWindow(one3D.Name); 

} 

Cube to Trace 

Seismic traces are accessed from the 3D cube via an enumerator. 

SeismicCube contains an IEnumerable property, Traces. 

The enumerator returns traces in storage order. 


SeismicCube one3D = ...; 

foreach (ITrace trace in one3D.Traces) 

{ 

... 

} 

access traces in storage order 

continue on next line 

Fig. 4-11 Seismic Cube Traces Access in Storage Order 

Traces can also be accessed in random order, by specifying the IJ index of 

the trace in the cube. I specifies the inline number and J specifies the 




crossline number. It is necessary to check that the cube can be written to, 

using the property IsWritable, before writing data into the cube. 



int numI = one3D.NumSamplesIJK.I; 

int numJ = one3D.NumSamplesIJK.J; 

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

{ 

for (int j = 0; j < numJ; j++) 

{ 

ITrace trace = one3D.GetTrace(i, j); 

... 

if (one3D.IsWriteable) 

{ 

// update trace values 

... 

} 

} 

} 

Fig. 4-12 Seismic Cube Random Trace Access 

Collection to 2D Survey 

A SeismicCollection may also contain many 2D surveys. Each 2D survey 

is represented by a SeismicLine2DCollection instance. 


SeismicCollection sData = ...; 

IEnumerable all2D 

all2D = sData.SeismicLine2DCollections(); 

PetrelLogger.InfoOutputWindow("All 2D surveys 

in " + sData.Name); 

foreach (SeismicLine2DCollection one2D in all2D) 

{ 

PetrelLogger.InfoOutputWindow(one2D.Name); 

} 




2D Survey to 2D Line 

A 2D survey is a collection of 2D lines. These are enumerated in the 

Seismic2DLineCollection instance. 


SeismicLine2DCollection one2D = ...; 

PetrelLogger.InfoOutputWindow("All lines in " + one2D.Name); 

foreach (SeismicLine2D oneLine in one2D) 

{ 

PetrelLogger.InfoOutputWindow(oneLine.Name); 

} 

2D Line to Trace 

Individual traces from a 2D line are accessible from an enumerator. Class 

Seismic2DLine contains an IEnumerable property, Traces. 


SeismicLine2D oneLine = ...; 

foreach (ITrace trace in oneLine.Traces) 

{ 

... 

} 

The traces are retrieved in storage order. 

access traces in storage order 

Fig. 4-13 Access 2D Line Traces in Storage Order 




Traces can also be accessed from a 2D line in random order. The GetTrace 

method in class SeismicLine2D takes a trace index argument and returns 

an individual trace. 



int index = 3; 

ITrace trace = oneLine.GetTrace(index); 

... 

The traces are indexed by their J position in the line. The trace instance holds 

its position in its J property. Its I property, in the case of a 2D seismic line, 

is always set to 0. 

j index 

Fig. 4-14 Accessing 2D Line Traces in Random Order 

Accessing Trace Samples 

Traces are arrays of samples. They have an indexer member that allows 

individual samples to be accessed by simply indexing the ITrace instance. 

namespace Slb.Ocean.Petrel.DomainObject.Seismic 

{ 

public interface ITrace 

{ 

int I { get; } 

int J { get; } 

int Length { get; } 

} 

} 

float this[int index] { get; set; } 




Samples are retrieved as floats. Undefined values are returned as NaN. 


ITrace trace = ...; 

... 

for (int k = 0; k < trace.Length; k++) 

{ 

// Retrieving the sample value 

double sample = trace[k]; 

} 

... 

// Setting the sample to a new value 

if (one3D.IsWriteable) 

{ 

trace[k] = ... 

} 

Flushing Individual Traces 

Individual traces should be flushed to control their transfer to disk storage. 

This is done on the trace container, the SeismicLine2D, or the 

SeismicCube instances. 




// Browse through the cube 

ITrace trace = ...; 

... 

// Flush the trace in the Seismic cube storage files 

One3D.DoneWith(trace); 

// Browse through trace in the 2D line 

trace = ...; 

... 

// Flush the trace in the Seismic line storage file 

OneLine.DoneWith(trace); 

Buffered Access to 3D 

Seismic Cubes 

The Ocean API provides an interface to access a block of seismic trace 

values, the ISubCube interface. 

The buffered block is defined as a sub-cube in all dimensions, so unlike trace 

by trace access shown previously, one does not have to retrieve full traces. 

This is particularly advantageous when reading a single time slice. 

The buffered access of ISubCube can be used when filling a newly created 

cube with values since write access, as well as read access, is availabe. 


public interface ISubCube : IEnumerable, IEnumerable 

{ 

Index3 MaxIJK { get; } 

Index3 MinIJK { get; } 

float this[Index3 index] { get; set; } 

void CopyFrom(float[, ,] data); 

float[, ,] ToArray(); 

} 



An ISubCube block is defined by calling a method on the original 3D 

seismic cube, and passing six values in arguments, three start indices, and 

three stop indices. 

public sealed class SeismicCube : ... 

{ 

public ISubCube GetSubCube(Index3 MinIJK, Index3 MaxIJK); 

} 

Getting a sub-cube buffer does not create an object in the Petrel project, and 

no new data entity appears on the data tree. The operation only creates a 

memory structure used for subsequent data access. 

The indexing used to retrieve data from the sub-cube buffer relates to the 

full extent of the original cube. See the example below. Note that ISubCube 

is a specialization of IEnumerable and can be used in a 

foreach loop to create automatically increasing indices. 

private void FillCube(SeismicCube orig, SeismicCube cube) 

{ 

int block_size = 100; 

for (int i = 0; i < orig.NumSamplesIJK.I; i += block_size) 

for (int j = 0; j < orig.NumSamplesIJK.J; j += block_size) 

for (int k = 0; k < orig.NumSamplesIJK.K; k += block_size) 

{ 

Index3 start = new Index3(i, j, k); 

Index3 stop = new Index3( 

Math.Min(i + block_size, orig.NumSamplesIJK.I - 1), 

Math.Min(j + block_size, orig.NumSamplesIJK.J - 1), 

Math.Min(k + block_size, orig.NumSamplesIJK.K - 1)); 

ISubCube from = orig.GetSubCube(start, stop); 

ISubCube to = cube.GetSubCube(start, stop); 

foreach (Index3 idx in from) 

{ 

to[idx] = from[idx]; 

} 

} 

} 

There are a number of methods in ISubCube to enhance data access 

performance. 

• A complete array may be pasted onto the sub-cube in one function call 

(CopyFrom()). 

• The block may be saved to an array for zero-based indexing. 




• The previous example is shown here with direct array access and an 

improved copy time. 

private void FillCube(SeismicCube orig, SeismicCube cube) 

{ 

int block_size = 100; 

for (int i = 0; i < orig.NumSamplesIJK.I; i += block_size) 

for (int j = 0; j < orig.NumSamplesIJK.J; j += block_size) 

for (int k = 0; k < orig.NumSamplesIJK.K; k += block_size) 

{ 

Index3 start = new Index3(i, j, k); 

Index3 stop = new Index3( 

Math.Min(i + block_size, orig.NumSamplesIJK.I - 1), 

Math.Min(j + block_size, orig.NumSamplesIJK.J - 1), 

Math.Min(k + block_size, orig.NumSamplesIJK.K - 1)); 

ISubCube from = orig.GetSubCube(start, stop); 

ISubCube to = cube.GetSubCube(start, stop); 

to.CopyFrom(from.ToArray()); 

} 

} 

Creating a Seismic 

Cube 

There are three methods used to create a seismic cube including: 

• Cloning an existing cube 

• Creating a sub-cube of an existing cube 

• Specifying the survey lattice 

The first method creates a copy of the original cube, leaving all traces empty. 

The second method also creates a cube but lets the caller specify decimation 

in trace range and in trace and sample spacing. The third method requires 

defining the cube origin, line spacing, sample spacing, range, and rotation. 

Cloning an Existing Cube 

Creating a cube by cloning an existing one is straightforward. 

The new cube is added to a SeismicCollection instance. It is not 

necessarily the container of the original cube, but it has to be compatible 

with the cube to be created. Use the CanBeAdded method to verify lattice 

compatibility. Actually, this rule is not enforced in the present version of 

Ocean, but CanBeAdded should be called for later compatibility. 


SeismicCollection sc = ...; 

SeismicCube oldCube = ...; 

if (sc.CanBeAdded(oldCube)) 

SeismicCube myCube = sc.CreateSeismicCube(oldCube); 

else 

PetrelLogger.ErrorBox(“Selected cube cannot be added to” + sc.Name); 

Creating a Decimated Cube 

To create a sub-cube of the original cube, we have to specify 

• A start offset, translation in IJK space for the cube origin 




• A new spacing step in all dimensions 

• A size in IJK, the number of inlines, crosslines, and samples 

We also have to specify a PropertyVersion for the newly created cube. 

This allows creation of attribute cubes. 

Fig. 4-15 Defining a Sub-cube from an Existing Cube 

The creation call should be protected by CanBeAdded. As before, we verify 

that the cube is compatible with the SeismicCollection. 



SeismicCube oldCube = ...; 

if (sc.CanBeAdded(oldCube)) 

{ 

// new origin is expressed in number of inlines and xlines 

// from old origin 

Index3 startPt = new Index3(20,10, 50); 

// new inline, crossline and sample spacing 

Index3 ptInc = new Index3(2, 2, 1); 

// total number of inlines, crosslines and samples, not to exceed 

// cube range 

Index3 newSize = new Index3(25, 25, 30); 

PropertyVersion pv = ...; 

SeismicCube newCube = sc.CreateSeismicCube(oldCube, startPt, 

ptInc , newSize, 

pv); 

} 

Creating a New Cube 

To create a new cube in a SeismicCollection, one has to specify the 

geometry of the cube: 

• Cube size in all dimensions 

• Origin of the cube in XYZ space 

• Unit vector specifying the spacing and the orientation of the inlines 




• Unit vector specifying the spacing and the orientation of the crosslines 

• Unit vector specifying the spacing of the trace samples 

• Data storage format (from 8-bit integer to float) 

• Vertical axis domain (two-way time or depth) 

• Property version 

• Clipping range 

public class SeismicCollection : ... 

{ 

public SeismicCube CreateSeismicCube(Index3 size, 

PropertyVersion propertyVersion, 

Range1 clippingRange); 

Point3 origin, 

Vector3 iUnitVector, 

Vector3 jUnitVector, 

Vector3 kUnitVector, 

Type storageType, 

Domain verticalDomain, 

} 

... 

Index3 size defines the number of inlines, crosslines, and samples per trace. 

Point3 origin specifies the position in space of the shallowest lower left corner 

(meaning inline 0, crossline 0, and sample 0). It is expressed in the project's projection 

coordinate system. 

The three Vector3 arguments, iUnitVector, jUnitVector, and kUnitVector 

specify spacing in all directions and rotation of the lattice in the horizontal 

plane from the North aligned projection system. 

origin 

k index 

i index 

j index 

time 

crossline 

inline 

Fig. 4-16 Seismic Cube Layout 




iUnitVector and jUnitVector specifies the rotation of the cube lattice 

from the North-aligned Cartesian projection system. The horizontal 

coordinates of the iUnitVector are as follows. 

(inline spacing) * cos(rotation angle) 

and 

(inline spacing) * sin(rotation angle) 

The horizontal coordinates of the jUnitVector are as follows. 

(crossline spacing) * sin(rotation angle) 

and 

(crossline spacing) * -cos(rotation angle) 

The units for the values for the iUnitVector and jUnitVector are 

expressed in the Invariant unit system of the project, or SI. For horizontal 

distance the units are meters. 

The kUnitVector argument specifies the spacing of data samples in the 

vertical domain. The units for kUnitVector are expressed in the Invariant 

unit system for the project for the Domain that is defined by the Domain 

argument to the Create method. For the ELEVATION_TIME domain, this 

is seconds and for ELEVATION_DEPTH, it is meters. 

Note that the i , j , k vectors should form an orthogonal system with k 

oriented towards the center of the earth. So the i , j , k system must verify 

the following rules. 

• The X and Y components of the k vector are equal to zero. 

• The Z component of I and J is equal to zero. 

• I and J are perpendicular to one another, i.e. the scalar product i . j is 

equal to zero. 




line spacing 

trace spacing 

Northing (y) 

(x j , y j , 0) 

25 

12.5 

origin 

(xi, yi, 0) 

Easting (x) 

Fig. 4-17 IJ Unit Vectors in the Projection Plane 

The last four arguments of the CreateSeismicCube method specify the 

trace sample domain and range. 

• Data format is controlled by System.Type argument. 

• K axis vertical domain is specified by the Domain argument. 

• Type of data is characterized by PropertyVersion. 

• Data in the cube will be clipped by the Range1 argument if 

the data is stored in integer or byte format. 



DataManager.NewTransaction() 

{ 


t.Lock(sc); 

Index3 size = new Index3(500, 1000, 2001); 

Point3 origin = new Point3(13579.75, 24680.08, 0.0); 

Vector3 iSpacing = new Vector3(10.82,6.25, 0.000); 

Vector3 jSpacing = new Vector3(-12.50, 21.65, 0.000); 

Vector3 kSpacing = new Vector3( 0.00, 0.00, 0.004); 




} 

if (sc.CanBeAdded(size, origin, iSpacing, jSpacing, kSpacing) 

{ 

Type dataType = typeof(float); 

Domain vDomain = Domain.TWT; 


Range1 r = new Range1(- 2048.0, 2048.0); 

SeismicCube cube = sc.CreateSeismicCube( 

size, 

origin, 

iSpacing, 

jSpacing, 

kSpacing, 

dataType, 

vDomain, 

pv, 

r); 

} 

t.Commit(); 

Creating a Seismic Line 

Creating a seismic line can only be done by cloning an existing 2D survey. 

This method is provided to allow creation of 2D seismic attributes. 

A PropertyVersion is specified so that the cloned 2D survey can represent 

any seismic attribute Property. 





{ 

SeismicCollection sCol = ...; 

SeismicLine2DCollection lineCol = ...; 


} 

t.Lock(sCol); 

SeismicLine2DCollection newCol; 

newCol = sCol.CreateSeismicLine2DCollection(lineCol, pv); 

foreach (SeismicLine2D line in newCol) 

{ 

foreach (ITrace trace in line.Traces) 

{ 

int index = ...; 

trace[index] = ...; 

line.DoneWith(trace); 

} 

} 

t.Commit(); 

The API only provides the capability to create an entire collection of 2D lines. 

This is due to the way 2D surveys are stored in the compressed SEG-Y format 

used in Petrel for seismic data storage. A single file (the data entity that is 

cloned) corresponds to the entire set of lines in the collection. 




Other Seismic Datasets: 

The Virtual Cube 

Original Cube 

Filtered 

Quality 

Fig. 4-18 Section on a Virtual Filtered Cube vs. Original 

Creation of virtual cubes in the Petrel data tree is done via the IAttribute 

interface. 

The main purpose of virtual cubes is to define new seismic attributes (filters 

on existing cubes), and the creation of virtual cubes is attached to the 

"Volume attributes" application in Petrel Geophysics. 

The IAttribute definition is found in the SeismicAttribute namespace, 

outside of the Petrel DomainObject namespace hierarchy. 

A seismic attribute is designed by providing the following classes: 

• A class implementing IAttribute 

• A class to hold user-specified attribute arguments 

• A UI class for the user to assign values to the attribute arguments 

• A class implementing IAttributeGenerator 




The first interface organizes the attribute computation, specifying the 

number of input cubes and the number of neighboring traces on which the 

attribute is computed. 

public interface IAttribute 

{ 

string CategoryName { get; } 

string Description { get; } 

string[] InputLabels { get; } 


int NumInputs { get; } 

Index3 OperatorSize { get; } 

PropertyVersion PropertyVersion { get; } 

Range1 ValueLimit { get; } 

} 

object CreateArgumentPackage(); 

IAttributeGenerator CreateGenerator(object argumentPackage, 

IGeneratorContext context); 

Control CreateUI(object argumentPackage); 

The InputLabels and NumInputs properties allow the IAttribute 

interface implementation to specify several input cubes. However, that 

functionality is not implemented yet, and the "Volume attributes" user 

interface will only take one input cube. 

The interface specifies three methods to instantiate the argument package, 

the generator that will compute traces on demand and the custom UI that 

will allow the user to specify his or her choice of argument values. 

Attribute arguments 

The attribute arguments are specified in a class whose public properties will 

be the attribute parameters set by the user and used by the generator to 

calculate trace values. 

The attribute argument implementation must be Serializable and 

implement ICloneable. Once instantiated the virtual cube is part of the 

project but contains no data in itself. Instead it must keep references to its 

input cube and save the argument values. 

[Serializable] 

internal class MyAttributeArguments : ICloneable 

{ 

private float m_param = 0.1291f; 

} 

public float MyParameter 

{ 

get { return m_param; } 

set { m_param = value; } 

} 

... 

Arguments can hold Ocean domain objects like process arguments, as the 

attribute computation is run in Petrel's main thread. The following example 

takes a second cube to apply a quality filter to the input cube. The input and 

the quality cube share the same survey. The attribute arguments are the 

secondary cube (Petrel domain object) and the two values in the second cube 




indicate the high and low quality values. Handling a domain object as an 

argument adds the difficulty that the argument value should not be serialized 

(the object reference would be invalid at restore time), but its Droid should 

be saved and serialized with the argument class and used when loading the 

project to re-create the reference. 


internal class AttributeArguments : ICloneable 

{ 

private Droid m_droid; 

private float m_highest, m_lowest, m_scale, m_offset; 

[NonSerialized] 

private SeismicCube m_Other; 

public AttributeArguments() 

{ 

} 

public SeismicCube OtherSeismicCube 

{ 

get 

{ 

if (m_Other == null) 

m_Other = DataManager.Resolve(m_droid) as SeismicCube; 

return m_Other; 

} 

set 

{ 

m_OtherSeismicCube = value; 

m_droid = m_OtherSeismicCube.Droid; 

} 

} 

public float Highest 

{ 

get { return m_highest; } 

set { m_highest = value; } 

} 

public float Lowest 

{ 

get { return m_lowest; } 

set { m_lowest = value; } 

} 

public float Scale 

{ 

get { return m_scale; } 

set { m_scale = value; } 

} 

public float Offset 

{ 

get { return m_offset; } 

set { m_offset = value; } 

} 

// ICloneable Members 

public object Clone() 

{ 

return MemberwiseClone(); 

} 

} 

In the example above, which takes a second seismic cube to indicate quality, 

we hold argument values for high and low values for the quality cube (chosen 




by the user) and compute a scale and offset to apply to the input seismic 

cube. The output will represent the input cube quality filtered. 

Custom UI 

As in the case of a Process, the IAttribute provides a method to create a 

set of argument values picked by the user. This Control instance will appear 

when the attribute is selected by the user in the "Volume attributes" 

application. 

Fig. 4-19 UI Design for the Virtual Attribute Cube 

The same user interface gets displayed when the user double-clicks on a 

virtual cube in the data tree and when the virtual cube is built with the 

IAttribute implementation. 

Attribute generator 

The attribute generator provides the method used by Petrel to calculate trace 

values on demand. This is the last class to be instantiated when creating a 

virtual cube instance, after the arguments and the UI. The attribute calls the 

CreateGenerator() method after the user has pressed the Apply or OK 

button on the attribute editor. 

namespace Slb.Ocean.Petrel.SeismicAttribute 

{ 

public interface IAttributeGenerator 

{ 

void Calculate(IAttributeData[] input, 

IAttributeData output, 

Index3 outputOffset); 

} 

} 




The main object of the generator class is to provide a Calculate() method 

that will be used to generate seismic traces on demand. The following 

example continues the implementation of our quality filter. 


class AttributeGenerator : IAttributeGenerator 

{ 

private AttributeArguments m_arguments; 

private bool m_equalGeometry = false; 

public AttributeGenerator(AttributeArguments arguments, 

IGeneratorContext generatorContext, 

SeismicAttribute origin) 

{ 

m_arguments = arguments; 

LatticeInfo lat = m_Arguments.OtherSeismicCube.Lattice; 

m_equalGeometry = (lat.Operations.Equals( 

generatorContext.InputCubes[0].Lattice) && 

(m_Arguments.OtherSeismicCube.NumSamplesIJK == 

generatorContext.InputCubes[0].NumSamplesIJK)); 

} 

public void Calculate(ISubCube[] input, 

ISubCube output,Index3 outputOffset) 

{ 

if (m_arguments.OtherSeismicCube == SeismicCube.NullObject || 

!m_arguments.OtherSeismicCube.IsGood) return; 

if (!m_equalGeometry) return; 

ISubCube input0 = input[0]; 

ISubCube otherSubCube = m_arguments.OtherSeismicCube.GetSubCube( 

outputOffset + input[0].MinIJK, 

outputOffset + input[0].MaxIJK); 

float offset = m_arguments.Offset; 

float scale = m_arguments.Scale; 

// Now the actual output loop. ISubCube is an Index3 enumerator 

foreach (Index3 index in output) 

{ 

// Get the index and value for the Other cube 

float otherValue = otherSubCube[outputOffset + index]; 

} 

} 

} 

// Compute the attribute 

float myValue = input[0][index]; 

output[index] = myValue * (offset + scale * otherValue); 

Attribute example 

With the classes designed above, we build an IAttribute implementation 

that will be instantiated at load time by the Ocean module that defines it. 

Note that the attribute instance will be serialized when the project is saved, 




with its argument package and generator instance, and should include only 

basic types in its private members. 


public class SeismicAttribute : IAttribute 

{ 

private Index3 m_operatorSize; 

private string[] m_inputLabels; 

public SeismicAttribute() 

{ 

m_inputLabels = new string[2]; 

m_inputLabels[0] = "CubeOne"; 

m_operatorSize = new Index3(1, 1, 1); 

} 

public object CreateArgumentPackage() 

{ 

return new AttributeArguments(); 

} 

public IAttributeGenerator CreateGenerator(object argumentPackage, 

IGeneratorContext generatorContext) 

{ 

AttributeArguments args = argumentPackage as AttributeArguments; 

return new AttributeGenerator(args, generatorContext, this); 

} 

public Control CreateUI(object argumentPackage) 

{ 

AttributeArguments args = argumentPackage as AttributeArguments; 

return new SeismicAttributeForm(args); 

} 

public string Description 

{ 

get { return "quality multiplier from secondary cube"; } 




} 

} 

public string[] InputLabels 

{ 

get { return m_inputLabels; } 

} 

public string Name 

{ 

get { return "Quality Filtering"; } 

} 

public int NumInputs 

{ 

get { return 1; } 

} 

public Index3 OperatorSize 

{ 

get { return m_operatorSize; } 

} 

public PropertyVersion PropertyVersion 

{ 

get 

{ 



return pvs.FindOrCreate( 

pvs.GetGlobalPropertyVersionContainer(), 

PetrelUnitSystem.TemplateGroupSeismicColor.SeismicDefault); 

} 

} 

public Range1 ValueLimit 

{ 

get { return new Range1(-8000.0f, 8000.0f); } 

} 

Attribute registration 

Having instantiated the attribute class, the module must register the new 

instance with the core service of type IAttributeService. This is done 

with Slb.Ocean.Core.CoreSystem, so that the new attribute is available 

when running the Volume attributes application. 

Public class MyAttributeModule : IModule 

{ 

... 

public void Integrate() 

{ 

IAttributeService service; 

service = CoreSystem.GetService(); 

if (service == null) 

{ 

throw new Slb.Ocean.Core.LifecycleExcption("Service missing"); 

} 

service.InstallAttribute(new MyAttribute()); 

} 

} 




Once the attribute is registered, it can be used to instantiate a virtual cube 

programmatically without running the "Volume attributes" application in 

Petrel. 

IAttributeService service; 

service = CoreSystem.GetService(); 

IAttribute attr = new MyAttribute(); 

SeismicCube original = ...; 

string name = "My Virtual Cube"; 

SeismicCube virtual = service.CreateVirtualCube(attr, original, name); 

To save the virtual cube with the project, three classes, the IAttribute and 

IAttributeGenerator implementations, and the arguments package class 

must be serializable. 

Other Seismic Datasets: 

Wavelet Data 

Fig. 4-20 Wavelet Display in Petrel 

A seismic wavelet is a regularly sampled sequence of dimensionless amplitude 

values. Such data is typically defined in the time domain and is convolved 

with a set of correlation coefficients to form synthetic seismic data. It can 

also represent a spatial filter, in which case its domain is a length. 

In Ocean, a wavelet is represented by the Wavelet class. The class defines 

and implements several rules to accommodate wavelets such that they will 

follow typical processing guidelines for convolution and filtering. These 

include 

6. rounding the number of samples up to the next power of two when the 

wavelet is created 




7. placing the original center sample of the wavelet at the rounded up 

sample count divided by 2 

8. padding the ends of the wavelet with values of 0 

The definition for the Wavelet class is 

public sealed class Wavelet : FacadeConvenience, IDomainObject, 

IDescriptionSource, 

IContainerMember, 

IContainerMember 

{ 

public IEnumerable Amplitudes { get; set; } 

public Domain Domain { get; set; } 

public bool IsWritable { get; } 


public double SamplingInterval { get; set; } 

public double SamplingStart { get; } 

... 

public double this[int index] { get; } 

} 

Wavelets are preferably created in SeismicCollection or SeismicProject 

domain objects. However, they may also be created under Project and 

Collection domain objects. Here is an example creating a wavelet. 



... 

// Get the project and find the root of all seismic data 

Project project = PetrelProject.PrimaryProject; 

SeismicProject sp = SeismicRoot.Get( project ).SeismicProject; 

// Start a transaction since we will create data. 

using (ITransaction tr = DataManager.newTransaction( )) 

{ 

// Lock the seismic project so the wavelet can be created 

tr.Lock( sp ); 

} 

// Create the wavelet using a provided name. 

Wavelet wavelet = sp.CreateWavelet( "MyWavelet" ); 

... 

When amplitude data is added to the wavelet it must be added in the form of 

an entire array of type double. Along with the amplitude data the sample 

interval and Domain of the wavelet must be provided. The following 




example illustrates creating and setting the data for the wavelet created above. 

// Get number of amplitudes in wavelet 

int numSamples = ...; 

... 

// Create array for wavelet amplitudes 

double[] samples = new double[numSamples]; 

// Fill array with data 

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

{ 

Samples[i] = ...; 

} 

// Set the wavelet amplitudes 

wavelet.Amplitudes = samples; 

} 

// Set the sample interval and domain 

wavelet.SampingInterval = 0.004; 

wavelet.Domain = Domain.ELEVATION_TIME; 

As mentioned in the rules listed earlier, the number of samples in the wavelet 

will be rounded up to the next power of two and the ends of the wavelet will 

be padded with zeros. In the following figure you can see a 13 sample 

wavelet provided by the user. The length of the wavelet is rounded up to 16 

samples, and the center of the original data is placed at the sample in the 

middle of the 16 sample (16 / 2 = 8). 

Fig. 4-21 Wavelet Storage 

When the SampleCount property for the wavelet is checked, the value will 

be the power of two value to which the wavelet was rounded. 




Seismic Interpretation 

Seismic interpretation produces references in the seiesmic cube space to 

seismic reflectors recognized by the geophysicist. These reflectors mark 

geological or rock property changes that the interpreter will tie with its 

structural model. 

Each pick in the seismic domain is represented by a point in XYZ space, the 

Z dimension being generally two-way time. The interpretation objects are 

collections of such points. 

Fig. 4-22 Set of Points Contributing to a Horizon Interpretation 

Grid Usage 

3D horizon interpretation is based on grids defined by the 3D seismic survey. 

The underlying lattice defines the X/Y geometry pattern (that is, the origin, 

rotation angle, and axis extents of the grid). To access points defined along 

the 3D grid of a given survey, we have to distinguish between parts of the 

interpretation that have been defined on different 3D surveys. 

2D horizon interpretation is just a collection of points following seismic 

lines. The API collects 2D interpretation point sets per 2D survey to ease 

navigation. 

In the case of 3D horizon interpretation, the lattice will be conformant with 

the seismic dataset on which the interpretation is built. The interpretation 

instances give access to lattice information, so that specific horizon points 

may be accessed for a particular grid I, J, K reference. Furthermore, the API 

will return the coordinates of each interpreted point. 




This lattice navigation for 3D interpretation is new in Ocean 2007.1, as 

lattice conformance is only implemented in Petrel 2007.1 and following 

versions. Legacy interpretation instances cannot be accessed from I, J, K 

references, although the user has the choice to convert old interpretation data 

to Petrel 2007.1 conformant interpretation instances (as long as the points 

coincide with some seismic survey definition). 


Classes 

Seismic interpretation is grouped under folders exposed in the Ocean API as 

InterpretationCollection instances. 

The interpretation instances are then separated in FaultInterpretation 

and HorizonInterpretation. Below these we find groups of points 

belonging to different seismic surveys (only for horizons, faults are 

undifferentiated) and property instances. 

InterpretationCollection 

FaultInterpretation 

HorizonInterpretation 

HorizonInterpretation3D 

HorizonInterpretation2D 

filtering 


IRegularHeightField 

navigation 

LineGeometry 

LatticeInfo 

Fig. 4-23 Seismic Interpretation Classes 

InterpretationCollectio 

n 

All interpretation instances must belong to a folder in the Petrel Input data 

tree of the type InterpretationCollection. 

The InterpretationCollection is the containment folder of all seismic 

interpretation instances. 

These folders are nested but not rooted under a single folder. This is why an 

IEnumerable is retrieved from the 

SeismicProject. 




Fig. 4-24 Nesting of seismic data and interpretation folders in Petrel Input 

tree 

InterpretationCollection folders are retrieved from the Petrel project 

in one of two ways. 

• From the SeismicRoot static instance, for legacy interpretation folders 

(containing interpretation that is not linked to seismic surveys). 

• From the SeismicProject unique instance, if it exists in the project, 

for all seismic interpretation that is related to seismic datasets (via 

SeismicCollection instances). 

The top folder in the interpretation collection hierarchy, in both cases, is held 

in the InterpretationCollections property in SeismicRoot or 

SeismicProject. The following example browses through 




InterpretationCollection instances in the project, looking through 

folders and down each sub-folder for FaultInterpretation instances. 

using System.Collections.Generic; 



SeismicRoot sr = SeismicRoot.Get(PetrelProject.PrimaryProject); 

List listcol; 

IEnumerable icolcol; 

InterpretationCollection icol; 

// legacy interpretation collections 

icolcol = sr.InterpretationCollections; 

listcol = new List(icolcol); 

for (int i = 0; i < listcol.Count; i++) 

{ 

icol = listcol[i]; 

PetrelLogger.Info("Legacy interpretation " + icol.Name); 

if (icol.InterpretationCollectionCount > 0) 

{ 

listcol.AddRange(icol.InterpretationCollections); 

} 

foreach (FaultInterpretation f in icol.FaultInterpretations) 

{ 

PetrelLogger.Info("Fault " + f.Name); 

} 

} 

// Petrel 2007 interpretation collections 

SeismicProject sp = sr.SeismicProject; 

if (sp == SeismicProject.NullObject) 

return; 

listcol.Clear(); 

listcol.AddRange(sp.InterpretationCollections); 

for (int i = 0; i < listcol.Count; i++) 

{ 

icol = listcol[i]; 

PetrelLogger.Info("Seismic datasets interpretation " + icol.Name); 

if (icol.InterpretationCollectionCount > 0) 

{ 

listcol.AddRange(icol.InterpretationCollections); 

} 

foreach (FaultInterpretation f in icol.FaultInterpretations) 

{ 

PetrelLogger.Info("Fault " + f.Name); 

} 

} 

Accessing Horizon 

Points 

Under the seismic data folder (exposed by the Ocean API as the 

SeismicProject instance), horizon interpretations are grouped per the 

seismic surveys (2D or 3D) whose datasets have been used when picking the 

horizon points. 




However, all these points are recognized as being part of the same structural 

boundary and may be retrieved as a single enumerable. 



HorizonInterpretation hor = ... 

IPoint3Set points = hor.Points; 

// report the number of points 

PetrelLogger.InfoOutputWindow( 

String.Format("horizon {0} has {1} points", 

hor.Name, hor.PointCount)); 

foreach (Point3 xyz in points) 

{ 

... 

} 

But the points coming from a seismic 3D survey may be distinguished from 

points picked on 2D lines or on other 3D surveys. This is done by using 

SeismicCollection instances (also located under the SeismicProject) to 

filter them out. 

Note that if several 3D surveys belong to the same hierarchy of 

SeismicCollection instances and therefore share the same lattice 

definition or use decimated lattices defined from the same original lattice in a 

parent collection, it is not necessary to have any distinction between their 

origin datasets. Therefore, when a SeismicCollection is passed as an 

argument to select a subset of interpretation points, the topmost parent of 

that collection is used. 

Given a SeismicCollection (2D or 3D), one can retrieve points by 

effectively applying the lattice filtering to the HorizonInterpretation 

instance. Note that the points are returned by a method and the point count 

is not accessible directly at this level. However, it will be accessible from the 

specialized instance HorizonInterpretation3D or 

HorizonInterpretation2D. 



SeismicCollection scol = ... 

// verify that the seismic collection corresponds to a 3D survey 

if (scol.MemberType == typeof(SeismicCube)) 

{ 

HorizonInterpretation hor = ... 

IPoint3Set points = hor.GetPoints(scol); 

// count the points 


foreach (Point3 pt in points) count++; 

PetrelLogger .InfoOutputWindow( 

String.Format("horizon {0} has {1} points in {2}", 

h.Name, count, scol.Name)); 

foreach (Point3 xyz in points) 

{ 

... 

} 

} 




Each interpretation class contains a list of Property instances and a list of 

DictionaryProperty instances, each instance having a reference to the 

appropriate property version type. 

InterpretationCollection folders are retrieved from the project with the 

static method GetInterpretationCollections. The following example 

browses through InterpretationCollection instances in the project, 

looking through folders and one-level down sub-folders for 

FaultInterpretation instances. 



FaultInterpretation fault = 

FaultInterpretation.NullObject; 

Project p = PetrelProject.PrimaryProject; 

IEnumerable 

colcol; 

colcol = 

InterpretationCollection.GetRootInterpretationCollections(p); 

foreach (InterpretationCollection icx in colcol) 

{ 

if (icx.FaultInterpretationCount > 0) 

{ 

foreach (FaultInterpretation ifx in icx. 

FaultInterpretations) 

{ 

fault = ifx; 

if (fault.IsGood) 

break; 

} 

break; 

} 

else if (icx.InterpretationCollectionCount > 0) 

{ 

foreach (InterpretationCollection subicx in 

icx.InterpretationCollections) 

{ 

if (subicx.FaultInterpretationCount > 0) 

{ 

foreach (FaultInterpretation subifx 

in subicx.FaultInterpretations) 

{ 

fault = subifx; 

if (fault.IsGood) break; 

} 

break; 

} 

} 

break; 

} 

} 

if (fault == FaultInterpretation.NullObject) 

{ 

PetrelLogger.InfoOutputWindow("Cannot find Fault Interpretations"); 

return; 

} 




Creating Interpretation 

Objects 

On top of the containment hierarchy, the InterpretationCollection 

serves also as folder data container in the Input data tree. All interpretation 

creation has to be done from an existing folder. 


HorizonInterpretation hor = ...; 

// Print the Horizon points 

PetrelLogger.InfoOutputWindow(“Listing all 

points in Horizon “ + 

hor.Name); 

foreach (Point3 p in hor.GetPoints()) 

{ 

PetrelLogger.InfoOutputWindow("X= "+ p.X + 

“Y= "+ p.Y +" Z= "+ p.Z); 

} 

InterpretationCollection folder = hor.InterpretationCollection; 

hor = folder.CreateHorizonInterpretation("New horizon Interp"); 

HorizonInterpretation 

Once created, the HorizonInterpretation is updated by replacing its set 

of points. The points are associated with the interpretation object in one 

function call, SetPoints. The old points are garbage collected. 

A HorizonInterpretation can also be modified by adding a Property 

object to it. The HorizonProperty instance contains a set of 

PointPropertyRecords. Only the value in each PointPropertyRecord 

can be set. The point geometry definition is inherited from the Horizon 

object. 




HorizonProperty or DictionaryHorizonProperty instances can be 

added to the HorizonInterpretation object by supplying the appropriate 

PropertyVersion or DictionaryPropertyVersion. 



HorizonInterpretation hor = ...; 

IPoint3Set pts = hor.GetPoints(); 

double x0 = ..., y0 = ...; 

using (ITransaction t = DataManager.NewTransaction()) 

{ 

trans.Lock(hor); 

} 

// Update the Horizon point set 

foreach (Point3 pt in pts) 

{ 

if (pt.X > x0 && pt.Y > y0) pt.Z = Double.NaN; 

} 

hor.SetPoints(pts); 

// Create a Property on the Horizon 

PropertyVersion pv = ... 

HorizonProperty prop = hor.CreateProperty(pv); 

prop.Name = “New Property”; 

... 


FaultInterpretation 

A FaultInterpretation object differs slightly from a 

HorizonInterpretation in that its points are arranged in a collection of 

polylines. This reflects the fact that the interpretation picks are chosen on 

Seismic sections, one polyline corresponding to one section. 

Note that the (Fault) Interpretation is not grid-based. Some of the 

points in the same section pick (same polyline) could be vertically placed on 

top of each other. 

The Fault polylines are retrieved in an enumeration. All polylines can be 

retrieved at once, or only the polylines picked on a given SeismicCube, or 

just the polylines picked on a given SeismicLine2D. The method 

GetPolylines is overloaded with three signatures. 

FaultInterpretation instances are updated by replacing their polylines. 

All polylines are set in one call to method SetPolylines. Like 

GetPolylines, SetPolylines is overloaded to replace 

• All polylines 

• Polylines picked in a SeismicCube 

• Polylines picked in a SeismicLine2D 

The three method signatures are provided for forward compatibility. In the 

present version, they are all equivalent. 




Like HorizonInterpretation, the FaultInterpretation can be 

modified by adding a Property object to it. In the Input data tree, the 

Property object will show under the containment of the FaultProperty 

instance. FaultProperty or FaultDictionaryProperty has to be 

supplied with a PropertyVersion or a DictionaryPropertyVersion 

instance. 



FaultInterpretation fault = ...; 

double x0 = ..., y0 = ...; 

// Update the Fault polylines 

using (ITransaction trans = DataManager.NewTransaction()) 

{ 

trans.Lock(fault); 

IEnumerable lineSet = fault.Polylines(); 

Polyline3 [] newSet = new Polyline3[fault.PolylineCount]; 

int iline = 0; 

foreach (Polyline3 pline in lineSet) 

{ 


foreach (Point3 p in pline) 

if (p.X > x0 && p.Y > y0) count++; 

Point3 [] newPoints = new Point3[count]; 

int jpoint = 0; 

foreach (Point3 pt in pline) 

{ 

if (pt.X > x0 && pt.Y > y0) 

{ 

newPoints[jpoint] = pt; 

jpoint++; 

} 

} 

newSet[iline] = new Polyline3(newPoints); 

iline++; 

} 

fault.SetPolylines(newSet); 

trans.commit(); 

} 




FaultInterpretation can also be modified by adding a FaultProperty 

or a FaultDictionaryProperty to it. This is done by supplying the 

appropriate PropertyVersion or DictionaryPropertyVersion. 



FaultInterpretation fault = ...; 

... 

PropertyVersion pversion = ...; 


{ 

trans.Lock(fault); 

FaultProperty prop = fault.CreateProperty(pversion); 

prop.Name = “New Property”; 

...; 

} 

PointPropertyRecord 

Each point-value pair in FaultProperty or HorizonProperty instances is 

retrieved as a PointPropertyRecord instance. 

PointPropertyRecord has a Geometry and Value property. Geometry is 

read-only and inherited from the interpretation object, 

HorizonInterpretation or FaultInterpretation. 



HorizonProperty hprop = ...; 

double x0 = ..., y0 = ...; 

foreach (PointPropertyRecord ptr in hprop) 

{ 

double newValue = ...; 

} 

if (ptr.Geometry.X > x0 && ptr.Geometry.Y > y0) 

{ 

ptr.Value = newValue; 

} 

DictionaryFaultProperty and DictionaryHorizonProperty objects 

contain DictionaryPropertyRecord instances, which have similar 

definitions but with a Value property that takes integer values. 






5 Reservoir Modeling 


The Static Reservoir Model .........................................................................120 

Pillar Grid...................................................................................................121 

Reservoir Simulation ...................................................................................163 

5: Reservoir Modeling 119 



The Static Reservoir Model 

The static reservoir model puts together the structural model, the geological 

interpretation, and the properties measured in several points in the reservoir. 

The final result is a set of Property objects distributed throughout the pillar 

grid mesh. 

Fig. 5-1 

Reservoir Model 

These 3D properties are to the pillar grid what well logs are to the borehole 

trajectory. They are static properties and do not represent the evolution of 

fluid movement through time. 



Pillar Grid 

Pillar Grid 

Fig. 5-2 

Pillar Grid Mesh and Pillars 

The pillar grid is built by Petrel using private gridding algorithms and user 

interaction. It makes the link between the structural work, defined by 

surfaces and their intersections, and the static reservoir model. The pillar grid 

implementation has a set of 3D properties that are earth model properties 

distributed in the cells of the grid. 

The Ocean API offers an access to the pillar grid and all its structural 

elements (read, with limited update) and to all its dependent 3D properties 

(full access). 

The pillar grid based static model in Petrel is based on a description of the 

reservoir separated horizontally by horizontal surfaces and divided into 

segments by faults modeled as pseudo-vertical fences. 

The Grid object defines the geometry of the static reservoir model. The 

gridding algorithm produces a mesh that tries to divide the segments 

horizontally into square cells. Vertically the cells are divided according to the 

stratigraphic model and further subdivided into layers. 

The Pillar Grid 

Structure 

The structural elements of the pillar grid are as follows: 

• Horizons 

• Zones 

• Faults 

• Segments 

The geometrical elements of the pillar grid are as follows: 

• Cell 




• Pillar 

• Node 

The Cell 

The cells are delimited by eight points and four pillar sections, making six 

faces like those of a die. However, none of the faces are planar. Each face 

will be viewed as two triangles. The triangles are not defined by the pillar grid 

geometry, just the corner points. 

The Pillar 

A pillar is a set of nodes that traverses the stratigraphy column. Each node in 

the pillar is at the same { I, J } place in the mesh built by the gridding 

algorithm. A particular type of pillar is the fault pillar, which is used in 

designing the pillar grid. 

The Node 

A node is the most basic element of the Pillar Grid. It represents a point in 

space and an {i, j, K} reference in the grid. 

Abstract Data Types 

The abstract data types used to describe the geometrical elements are: 

• Index3 {int I, int J, int K} 

• Point3 {double X, double Y, double Z} 

Index3 serves as a 3-dimensional index for nodes and cells. It is supported 

by a class in the Ocean services hierarchy. 

namespace Slb.Ocean.Basics 

{ 

class Index3 

{ 

public Index3 (int I, int J, int K); 

int I { get; } 

int J { get; } 

int K { get; } 

... 

} 

} 



Pillar Grid 

Point3 is used to contain any point reference in the Pillar Grid geometry. It 

is supported by a class in the Ocean Services class hierarchy like all generic 

geometry objects and services. 

namespace Slb.Ocean.Geometry 

{ 

class Point3 

{ 

public Point3 (double X, double Y, double 

Z); 

double X { get; } 

double Y { get; } 

double Z { get; } 

... 

} 

} 

Accessing the Cells 

The cell is the smallest volume element in the pillar grid. Each cell is 

referenced by index I, J, K. 

The index origin (cell {0, 0, 0}) is at the shallowest lower left corner of the 

grid. The grid dimensions are expressed in number of I indexes, number of J 

indexes, and number of K indexes. 

Note that the Petrel user can swap the display indexes. The API always 

returns the native index. The next version will support transformations to 

the UI domain. 

j 

k 

i 

Fig. 5-3 

Pillar Grid Mesh in i, j, k Space 




The Grid domain object, in 

Slb.Ocean.Petrel.DomainObject.PillarGrid namespace, contains grid 

dimension information. 

namespace 

Slb.Ocean.Petrel.DomainObject.PillarGrid 

{ 

public class Grid 

{ 

Index3 NumCellsIJK { get; } 

} 

} 

Point3 [] GetCellCorners(Index3); 

double GetCellVolume (Index3); 

... 

The total number of cells is the product of the number of cell indexes in all 

three dimensions. The numCellsIJK property in class Grid returns an 

integer for each axis dimension. 

using 

Slb.Ocean.Petrel.DomainObject.PillarGrid; 

Grid g = ...; 

Index3 idx = g.NumCellsIJK; 

long numCells = idx.I * idx.J * idx.K; 

As cell face triangulation is not explicit, there is an API function to return 

the volume of an individual cell. 

using 


Grid g = ...; 

Index3 index = new Index3(2,6,1); 

if (g.HasCellVolume(index)) 

{ 

double vol = g.GetCellVolume(index); 

PetrelLogger.InfoOutputWindow("Cell Vol: " 

+ vol.ToString()); 

} 

The Petrel user sees the reservoir model in X, Y, Z space. The API on the 

contrary, only sees a 3-dimensional array of cells. The X, Y, Z points are 

merely cells’ attributes. On the picture below, we see that that array is sparse. 



Pillar Grid 

Fig. 5-4 

3D Property in XYZ Space and IJK Space 

Collapsed Cells 

Not all cells are defined. Some cells within the IJK bounds are undefined 

because memory is not allocated all the way to the pillar grid corners to avoid 

waste. Cells can be outside the IJK range, but even if they are within range, 

they can be undefined. Then if they are within range and defined, they could 

be collapsed. 

Fig. 5-5 

Cells Outside, Cells Undefined, Cells without Volume 

Not all cells have volume. Cells have no volume if they have either: 

• Coincident top and base. The cell’s K level is close to an erosional 

Horizon. The layer has no thickness at that point. 




XYZ View 

IJK View 

Fig. 5-6 

Cells Collapsed Vertically 

• Coincident sides. The cell is next to a Fault and the mesh row or 

column is collapsing at that point. Since the cell array is 3-dimensional, 

it contains the same number of cells for each row (or column). The 

number of cells has to be equal to the maximum number in all rows (or 

columns). Thinner rows (or shorter columns) have cells with collapsed 

sides. 

XYZ View 

IJK View 

Fig. 5-7 

Cells Collapsed in the Horizontal Plane 



Pillar Grid 

Individual Cell Points 

Northwest 

Top 

Northeast 

Southwest 

Southeast 

Cell 

Base 

Fig. 5-8 

Cell and Cell Corners 

From individual cells we can retrieve geometrical information for all cell 

corners. Since the cell faces are non-planar, there are eight independent 

corners to each cell. The API gives access to nine points: the eight cell 

corners and the cell center, which is the equally weighted barycenter of these 

eight points. 

Individual points will be retrieved according to their relative position in the 

cell. The position is defined by elevation (Top or Base) and compass 

direction (Northwest, Northeast, Southwest, or Southeast). Directions to 

access cell corners are relative to grid IJK organization, not to geographical 




direction. Cell corner locations and relative directions are defined by a set of 

enumerations and a class. 

namespace SLb.Ocean.Petrel.DomainObject 

{ 

public enum Direction 

{ 

SouthWest = 0, 

NorthWest = 1, 

NorthEast = 2, 

SouthEast = 3, 

} 

} 

public enum TopOrBase 

{ 

Top = 0, 

Base = 1, 

} 

public enum CellCorner 

{ 

BaseSouthWest = 0, 

BaseNorthWest = 1, 

BaseNorthEast = 2, 

BaseSouthEast = 3, 

TopSouthWest = 4, 

TopNorthWest = 5, 

TopNorthEast = 6, 

TopSouthEast = 7, 

} 

public enum CellSide 

{ 

None = 0, 

Up = 1, 

Down = 2, 

North = 3, 

South = 4, 

West = 5, 

East = 6, 

} 

public static class CellCornerSet 

{ 

public static readonly CellCorner[] All; 

public static readonly CellCorner[] Base; 

public static readonly CellCorner[] Top; 

} 



Pillar Grid 

cell viewed from above 

Compass North 

NorthEast corner node 

i 

SouthWest corner node 

j 

Fig. 5-9 

Cell IJK Convention 

The direction Southwest is towards grid origin, or IJ index {0, 0}. 

Northeast is towards high indexes, or IJ index { numCellsIJK.I, 

numCellsIJK.J }. 

using 


Grid g = ...; 


if (g.IsCellDefined(index)) 

{ 

Point3 p = g.GetPointAtCell(index, 

Corner.NorthEast, 

} 

... 

TopOrBase.Top); 

Cell enumerations 

Cell corners and sides are defined by enumerations. 

Fig. 5-10 Cell Corners and Sides 




The CellCorner enumeration is used to define the position of a point 

relative to a cell. Points occur at the corners of cells. Top is the shallowest 

location of the cell and Base is the deepest location of the cell. 

namespace Slb.Ocean.Petrel.DomainObject 

{ 

public enum CellCorner 

{ 

BaseSouthWest = 0, 

BaseNorthWest = 1, 

BaseNorthEast = 2, 

BaseSouthEast = 3, 

TopSouthWest = 4, 

TopNorthWest = 5, 

TopNorthEast = 6, 

TopSouthEast = 7 

} 

} 

The CellSide enumeration is used to define the sides of the cell. 


{ 

public enum CellSide 

{ 

None = 0, 

Up = 1, 

Down = 2, 

North = 3, 

South = 4, 

West = 5, 

East = 6 

} 

} 

The Corner enumeration is used to define the corners of a cell without 

considering the Top or Base. 


{ 

public enum Corner 

{ 

NorthEast = 0, 

SouthEast = 1, 

SouthWest = 2, 

NorthWest = 3 

} 

} 



Pillar Grid 

The TopOrBase enumeration is used to define the vertical position relative to 

the grid. Top is the shallowest location of the cell and Base is the deepest 

location of the cell. 


{ 

public enum TopOrBase 

{ 

Top = 0, 

Base = 1 

} 

} 

The CellCornerSet class defines the CellCorners for a cell. 


{ 

public static class CellCornerSet 

{ 

public static readonly CellCorner[] All; 

public static readonly CellCorner[] Base; 

public static readonly CellCorner[] Top; 

} 

} 

All represents all cell corners, Base represents cell base corners, and Top 

represents cell top corners. 

The CellCornerSet class is used by the Grid.GetCellCorners method to 

get the positions of the corners of a cell as a Point3 array. 


using Slb.Ocean.Petrel.DomainObject.PillarGrid; 

Grid g = ...; 

Index3 index = new Index3(10, 20, 30); 

Point3 c[] = g.GetCellCorners(index, CellCornerSet.Top); 

... 

Node Access 

Nodes also can be accessed by IJK index. A node can be seen as a level in a 

pillar of the Pillar Grid. It is also placed at a corner of a cell. Nodes and cells 

can be outside the range or undefined. 

We will see later in the description of a fault in the pillar grid the special case 

of nodes on a faulted pillar. 




Nodes viewed from above. 

j 

(i=0, j=0) 

i 

Some node IJK’s 

can point to 

to undefined areas. 

Fig. 5-11 Node Access 

Node Index versus Cell Index 

We have one more index per dimension for nodes, when compared with cell 

indexes. The cell IJK index corresponds to the IJK index of its shallowest 

southwest corner. 



Pillar Grid 

Node 

(0,2,0) 

Node 

(0,1,0) 

Node 

(0,0,0) 

Node 

(0,0,1) 

Cell 

(0,0,0) 

Cell 

(1,0,0) 

Cell 

(1,1,0) 

Node 

(2,2,0) 

k axis 

Cell 

(1,1,1) 

Node 

(0,0,2) 

Cell 

(0,0,1) 

i axis 

Cell 

(1,0,1) 

j axis 

Fig. 5-12 Node Indexes Relative to Cells 

using 


Grid g = ...; 


if (!g.IsNodeInside(index)) return; 

if (g.IsNodeDefined(index, 

Direction.NorthEast)) 

{ 

Point3 p = g.GetPointAtNode(index, 

Direction.NorthEast); 

... 

} 

The example shows that we need to specify a Direction on the 

GetPointAtNode method. We will see why this is important when we look at 

Fault pillars. 

Pillar Access 

Grid geometry can also be accessed by IJ, meaning by two-dimensional 

index. Each IJ tuple within range will potentially correspond to a grid pillar. 

The IJ reference can be inside or not and can correspond to a pillar or not. 

The method IsNodeInside is overridden with Index2 as a node index to 




indicate a pillar index. A pillar is defined when method HasNodePillar 

returns true, again supplying an Index2 to specify the pillar. 

using 


Grid g = ...; 

Index2 index = new Index2 (2,6); 

if (g.IsNodeInside(index)) 

{ 

if (g.HasNodePillar(index)) 

{ 

PetrelLogger.InfoOutputWindow(“Pillar 

exists at Index {2, 6}”); 

} 

... 

} 

Pillar Grid Domain 

Objects 

* 

1 

* 

* 

* 

Grid 

Fault 

Segment 

Horizon 

Zone 

* 

* 

Property 

DictionaryProperty 

* * 

FaultProperty 

* 

FaultPropertyRecord 

Fig. 5-13 Pillar Domain Classes 

The Grid domain object carries reference to other domain objects that 

describe the Pillar Grid: 

Structural elements: 

• Fault 

• Segment 

• Horizon 

• Zone 

These structural elements describe earth model entities that compose the 

pillar grid. To these entities are attached properties, carried by other domain 

objects. In the Petrel domain model, geometrically defined entities and earth 



Pillar Grid 

Browsing through Pillar 

Grids in Models Tree 

properties are described in different objects. The borehole object, for 

instance, carries the well geographical description and the definition of its 

trajectory, while the well log object carries earth properties measured along 

the wellbore. 

Similarly, we have lists of domain objects describing earth properties, which 

are attached to the Grid object: 

• Property 

• DictionaryProperty 

• FaultProperty 

When browsing through the “Models” tree of a Petrel project, one can access 

all Grids in the project. This is done by accessing first the root list of model 

collections in the tree. The Project class ModelCollections property 

contains a collection of ModelCollecion objects in the project. 

One can retrieve the list of Pillar Grids attached to a model collection with 

the PillarGridRoot class method GetGrids, which takes a 

ModelCollection instance as argument. 

using 


using System.Collections.Generic; 

// Get all model collections from the project. 


IEnumerable mclist = proj.ModelCollections; 

// Process each model collection in the list 

foreach ( ModelCollection mc in mclist ) 

{ 

// Tell us which collection it is. 

PetrelLogger.InfoOutputWindow("Found Model Collection " + mc.Name); 

} 

// List the name of each grid in the collection. 

int i = 0; 

foreach ( Grid g in PillarGridRoot.GetGrids( mc ) ) 

{ 

i++; 

PetrelLogger.InfoOutputWindow("Grid no "+ i +" "+ g.Name); 

} 




Fault 

Fig. 5-14 Fault Planes, Pillar Based 

A fault is a surface that traverses the reservoir volume. The fault surface is 

modeled by a set of pillars which traverse the pillar grid at a single IJ index 

reference in Petrel static reservoir modeling. 

Pillars can be vertical, straight, or curved, but they always join nodes of same 

IJ index. We have to retrieve the position of each node along the pillar for 

the exact geometry of the pillars. 

The Fault object only carries a list of pillar references. The points along the 

fault are retrieved by accessing the node points from the Grid object. 

using 


Grid grid = ...; 

foreach (Fault fault in grid.Faults) 

{ 

foreach (Index2 i in fault.Nodes) 

{ 

... 

} 

} 

Fault nodes have the particularity of cutting horizons at more than one point. 

Along a Fault we thus retrieve more points than there are levels in the pillar 

grid. 



Pillar Grid 

The blue pillar 

has 3 different 

depth levels for 

the same level 

Fig. 5-15 Multiple Nodes for One IJK 

SE and NE cells connect to the same point 

Each node defined from its IJK index corresponds to a unique point in 

space, but when the node is on a Fault pillar, the point is unique only when 

viewed from the quadrant in which the observer places him or herself. 

In the picture below, the pillar traverses four levels but encounters eight 

nodes. For each IJK index one has to specify which side of the Fault it is 

placed in to retrieve a unique point in space. 

Fig. 5-16 Why a Single IJK Corresponds to Multiple Nodes 




The API will return a depth for an IJK node when the quadrant is specified. 

This is why the GetPointAtNode method requires a Direction argument; 

the node could sit on a pillar. 




Using 


Fault f = ...; 

Grid g = f.Grid; 

foreach (Index2 pillar in f.Nodes) 

{ 

int K = g.NumCellsIJK.K / 2; 

Index3 index = new Index3(pillar.I, 

pillar.J, K); 

Point3 p = g.GetPointAtNode(index, 

Direction.NorthEast); 

... 

} 

Fault Direction 

The API returns a set of Fault directions at each pillar. The Grid method 

GetFaultedDirections returns an array of up to four directions at each 

pillar. When the pillar is faulted, there are two, three, or four directions 

across the fault, depending on whether the fault is simple, branching, or 

crossing. 

The following code will return the maximum throw observed at a given 

Horizon on the pillars following a given Fault. 




using 



Horizon h = ...; 


if (h.Grid != g) 

{ 

PetrelLogger.ErrorBox("Pick Horizon/Fault 

from same Pillar Grid"); 

return; 

} 



Pillar Grid 

foreach (Index2 pillar in f.Nodes) 

{ 

Direction[] a = 

g.GetFaultedDirections(pillar); 

if (a.Length >= 2) 

{ 

Index3 node = new Index3(pillar.I, 

pillar.J, h.K); 

double max_depth = 0, min_depth = 

double.MaxValue; 

foreach (Direction dir in a) 

{ 

double depth = - g.GetPointAtNode(node, 

dir).Z; 

if (depth < min_depth) min_depth = 

depth; 

if (depth > max_depth) max_depth = 

depth; 

} 

double fault_throw = max_depth - 

min_depth; 

PetrelLogger.InfoOutputWindow("Fault 

throw at node (" + 

pillar.I + ", " + pillar.J + ") = " + 

fault_throw); 

} 

} 

Segment 

A segment is a contiguous block of cells bounded by fault surfaces. 

Fig. 5-17 Segments in a Pillar Grid 

The set of segments in the reservoir model creates a partition of the 

reservoir volume. 

• Each cell belongs to only one segment. 

• Two cells in the same segment can be joined by a path that does not 

cross any fault surface. 

• Any path that joins two cells in different segments will cross at least one 

fault surface. 




The Segment class offers a number of methods to check whether a cell or 

node is part of that Segment. 

namespace 


{ 

public class Segment 

{ 

public Grid Grid { get {};} 

public bool IsCellInside(Index2); 

public bool IsNodeInside(Index2, 

Direction); 

} 

} 

public IDescription Description { get {}; } 

... 

The method IsCellInside takes an Index2 as an argument, which 

specifies a cell column rather than a cell. This is because if a cell is inside a 

Segment, all the cells of that same IJ column are also part of the same 

Segment. Faults that separate segments are built with pillars that traverse the 

grid at a constant IJ index. Truncated faults join other faults by collapsing 

cells between their respective IJ indexes from the truncation point onward. 

Therefore two cells with the same IJ index cannot be in different segments. 

This is exposed by specifying only an IJ index in the 

Segment.IsCellInside method. 

The method Segment.IsNodeInside takes a pillar argument (IJ node index) 

and a Direction. The Direction is needed for pillars which are on the 

edge of the segment, as one direction may show the node inside and another 

direction may show the node outside the segment. 

Accessing Segment from Grid 

Segments can be accessed from the Grid by specifying a starting cell. The 

method GetSegmentAtCell is found in the Grid class. 


using 



Grid g = ...; 

Index2 idx = new Index2(28, 89) 

Segment s = g.GetSegmentAtCell(idx) 

for (int i = 0; i < g.NumCellsIJK.I; i++) 

{ 

for (int j = 0; j < g.NumCellsIJK.J; j++) 

{ 

Index2 c = new Index2(i, j); 

if (s.IsCellInside(c)) 

{ 

... 

} 

} 

} 


Pillar Grid 

Horizon 

A horizon marks the place in the reservoir model where a geological event 

occurred. 

Fig. 5-18 Horizon in a Pillar Grid 

Horizon is a surface, a volume boundary. It does not represent a layer in the 

reservoir but an interface between two layers. 

In the pillar grid, a horizon is fully characterized by a single K level across 

the entire model. 

From the Grid object, one can list the Horizons created in the model and 

retrieve their K indexes. 


Using 


Grid g = ...; 

foreach (Horizon h in g.Horizons) 

{ 

string msg = String.Format("Name: {0}, K: 

{1}”, 

h.Name, h.K); 

... 

} 

Zone 

A zone is an interval between two Horizons. 

Zones are organized in a two-level hierarchy. The top level zones separate the 

reservoir between two horizons. Sub-zones further subdivide zones into finer 

intervals. The last refinement is done at the cell level. 




Fig. 5-19 Zones and Horizons in the Petrel Data Domain 

A zone corresponds to two levels in the pillar grid, a top and a base. The 

Zone class returns both levels and allows navigation in the zone hierarchy. 

namespace 


{ 

public class Zone 

{ 

public Grid Grid { get; } 

public IDescription Description { 

get; } 

public Zone 

ParentZone { get; 

} 

public IEnumerable Zones { 

get; } 

public int ZoneCount { get; 

} 

} 

} 

} 

} 

public int TopK { get; 

public int BaseK { get; 

... 



Pillar Grid 

Zones can be accessed directly from the Grid object. 

Pillar Grid Fault Tracing 

Example 


using 


Grid g = ...; 

IEnumerable zones = g.Zones; 

foreach (Zone zone in zones) 

{ 

PetrelLogger.InfoOutputWindow(String.Format( 

"(Top={0}, Base={1})", 

zone.TopK, zone.BaseK)); 

} 

if (zone.ZoneCount > 0) 

{ 

// process sub zones 

} 

In this coding example, we follow the nodes of a fault and create a fault 

displacement property where we store the horizon gaps measured across the 

fault pillars. 

This deals with cell geometry and orientation. The cell whose property value 

gets filled is always to the right of the fault pillar path while traversing the 

fault pillars in order. 



using 


protected override void 

InvokeSimpleCore(FaultTrace.Arguments args) 

{ 

if (args == null) 

throw new 

ArgumentNullException("argumentPackage is 

null"); 

// Input argument: PillarGrid.Fault f 

// Output argument: PillarGrid.Property 

outProp 

Fault f = args.PillarGridFault; 


Property outProp = args.OutputProperty; 




The first thing is to create a “Fault Displacement” PropertyVersion and 

use it to create the 3D property. Get the template from the 

PetrelUnitSystem template group for FaultProperty objects. 



{ 

if (outProp == null) 

{ 

trans.Lock(g); 

ITemplate ptemp = 

PetrelUnitSystem.TemplateGroupFaultProperty. 

FaultDisplacement; 

IPropertyVersionService pvs; 

pvs = 


IPropertyVersionContainer pvc = null; 


pvs.FindOrCreate(pvc, ptemp); 

outProp = g.CreateProperty(pv); 

outProp.Name = "Fault Displacement"; 

g.AddProperty(outProp); 

} 

else trans.Lock(outProp); 

We are going to loop through the Fault nodes, keeping the last one in 

variable node and the current loop variable in next_node. We need two 

nodes to find a fault “cell.” Skip over the first node to have an interval in 

each loop. 

In the figure below you can see that the fault cell will be defined as the cell 

to the right of two concurrent nodes going from one node to the next in the 

fault. 

Node n + 1 

Node n 

Fig. 5-20 



Pillar Grid 

float undef = float.NaN; 

float displacement = undef; 

int K; 

Vector3 gap = new Vector3(0, 0, 0); 

IEnumerable nodes = f.Nodes; 

IEnumerable horizons = 

g.Horizons; 

Index2 node = null; 

Index3 cell; 

foreach (Index2 next_node in nodes) 

{ 

// skip over first node, 

// need node and next_node to frame 

interval 

if (node == null) { node = next_node; 

continue; } 

Inside the loop, check whether the Fault runs along the I axis (abcissa) or 

the J axis (ordinate). Also check whether the Fault is “increasing” or 

“decreasing” in IJ; this will determine which cell is “to the right of ” the edge 

from node to next_node. 

K = 0; 

// check whether the fault is along 

ordinates or abcissae 

bool fault_in_ord = node.I == 

next_node.I; 

// check whether the nodes increase in 

I,J or not 

bool fault_increasing; 

fault_increasing = 

(node.I+node.J)


Determining which cell is “right of ” the Fault edge depends on the axis 

alignment (ordinal or abscissa) and direction (increasing or decreasing). 

Fig. 5-21 

Cell next to Fault 

is (I-1,J) 

Fault going West 

Cell next to Fault 

is (I-1,J-1) 

Node n to Node n+1 

Fault going North 

Cell next to Fault is (I,J) 

Node n (I,J) 

Fault going East 

Fault going South 

Cell next to Fault is (I,J-1) 

Fault can be increasing or decreasing and moving along the I or the J axis. 

// determine in which cell (immediately 

right of fault 

// plane going from node to next_node) 

to set the property 

// going north, cell right of fault is 

node.I,node.J,horizon.K 

// going east, cell right of fault is 

I, J-1, K 

// going south, cell right of fault is 

I-1, J-1, K 

// going west, cell right of fault is 

I-1, J, K 

cell = (fault_increasing) ? 

((fault_in_ord) ? new Index3 

(node.I, node.J, horizon.K) : 

new Index3 (node.I, node.J - 1, 

horizon.K)) 

: 

((fault_in_ord) ? new Index3 

(node.I-1,node.J-1,horizon.K): 

new Index3 (node.I - 1, node.J, 

horizon.K)); 

Skip the last Horizon; we will compute displacement in horizon intervals. 

When we skip the last horizon, we still have to fill all the layers between the 

last Horizon and the current one. This is done with the last value of 

displacement. 

// Do not write below the deepest K 

level 

if (horizon.K >= g.NumCellsIJK.K) 

{ 

// Fill intermediate zones with top 

Horizon displacement 

while (K < horizon.K) 

{ 

outProp[cell.I, cell.J, K] = 

displacement; 

K++; 

} 

// bottom Horizon, exit loop and go 

to next fault node 

continue; 

} 



Pillar Grid 

Now we have to select the node with which we will compute the 

displacement. 

Fig. 5-22 

We need a node IJK and a direction to point to each side of the fault. 

// level left of fault 

// fault going north: north west of 

node 

// fault going south: south east of 

node 

// fault going east: north east of 

node 

// fault going west: south west of 

node 

Point3 level_before = 

g.GetPointAtNode(nodeIJK, 

(fault_in_ord) ? 

((fault_increasing) ? 

Direction.NorthWest : 

Direction.SouthEast) 

: 


Direction.NorthEast : 

Direction.SouthWest)); 

// From node, the cell right of fault 

is in the direction: 

// if fault is going north: north east 

// if fault is going south: south west 

// if fault is going east: south east 

// if fault is going west: north west 

Direction direction = (fault_in_ord) ? 


Direction.NorthEast : 

Direction.SouthWest) 

: 


Direction.SouthEast : 

Direction.NorthWest); 

We now need to skip collapsed cells, by going to the next cell “right of ” the 

cell next to the node edge, if the cell immediately next to the Fault has 

coincident sides. Note that the cell could be collapsed vertically and have no 

volume, but still have a non-null vertical projection. We will skip vertically 

collapsed cells, but our process will traverse all layers between the current 

horizon and the next. 




Skipping collapsed cells is done by adding the proper “step” to the currently 

selected cell. 

// if cell is empty, look for one with 

thickness in I or J 

// start from node 

nodeIJK = new Index3 (node.I, node.J, 

horizon.K); 

if (!g.HasCellVolume(cell)) 

{ 

// which way to go to skip over 

empty cells? 

// fault going north: increase I 

// fault going south: decrease I 

// fault going east: decrease J 

// fault going west: increase J 

Index3 step = (fault_in_ord) ? 

((fault_increasing) ? new Index3 

(1, 0, 0) : 

new Index3(-1, 0, 0)) 

: 

((fault_increasing) ? new Index3 

(0, -1, 0) : 

new Index3(0, 1, 0)); 

Point3 x1 = 

g.GetPointAtNode(nodeIJK, direction); 

Point3 x2 = g.GetPointAtNode(nodeIJK + 

step, direction); 

while (x1 == x2) 

{ 

cell = new Index3 (cell + step); 

nodeIJK = new Index3 (nodeIJK + 

step); 

x1 = x2; 

x2 = g.GetPointAtNode(nodeIJK + 

step, direction); 

} 

} 



Pillar Grid 

Now compute displacement between cells on each side of the Fault. 

// level right of fault, after 

skipping collapsed cells 

Point3 level_after = 

g.GetPointAtNode(nodeIJK, direction); 

gap = level_before - level_after; 

displacement = 

(float)System.Math.Abs(gap.Z); 

// Fill the intermediate zones with 

top Horizon displacement 

while (K < horizon.K) 

{ 

outProp[cell.I, cell.J, K] = 

displacement; 

K++; 

} 

K = horizon.K; 

} 

// loop to next node in Fault 

node = next_node; 

} 

args.OutputProperty = outProp; 


} 

return; 

} 

The figure below shows the result of running the fault tracing algorithm 

explained above. 

Fig. 5-23 Pillar Grid Fault tracing 

3D Property 

In the reservoir model, we call property, or 3D property, the distribution of 

an earth property in the Pillar Grid cells. 




Fig. 5-24 3D Property 

Each cell will return an individual value for that Property object. 

Property can contain a measurement quantity, like porosity, permeability of 

fluid content, or an index into an enumerated table of symbols, such as facies 

distributions. 

There are two classes of Property to hold grid data. 

• Property for measurement quantities, stored in double precision 

floating point numbers. 

• DictionaryProperty, stored as integer. 

The DictonaryProperty class is named that way because the integer values 

it stores are entries in a dictionary of symbols represented by a string of 

characters. The integer values have to be continuous and represent the index 

into the symbol enumeration. The DictionaryProperty values correspond 

to a DictionaryPropertyVersion classification. 

namespace 


{ 

public class Grid 

{ 

Property CreateProperty(PropertyVersion 

pv); 

DictionaryProperty 

CreateDictionaryProperty(DictionaryPropertyV 

ersion v); 

... 

void AddProperty(Property); 

void AddDictionaryProperty(DictionaryProperty); 

... 

} 

} 



Pillar Grid 

Accessing Property Values 

Accessing Property values is done by indexing directly the class instance, 

using the C# indexer member type. Indexer declarations are similar to 

property declarations, with the main differences being that indexers are 

nameless (the “name” used in the declaration is this, since this is being 

indexed) and that indexers include indexing parameters. The indexing 

parameters are provided between square brackets. 

namespace 


{ 

public class Property 

{ 

public float this [Index3] { get; set; } 

public float Min { get; } 

public float Max { get; } 


GetAllUpscaledCells (bool); 

... 

} 

} 

The same definition is provided for the DictionaryProperty class. The 

DictionaryProperty class also includes a method to add a symbol to the 

enumerated symbol table. This is done by adding a string-valued symbol, as 

the index will automatically get the next available one, augmenting the 

enumeration by one. 

namespace 


{ 

} 

} 

public class DictionaryProperty 

{ 

public int this [Index3] { get; set; } 

public int Min { get; } 

public int Max { get; } 

public int AddFaciesCode (string); 

... 




The following example shows how to create an upscaled copy of a 

Property. This is using a Transaction object to allow data creation in the 

Petrel project. 

Grid grid = ...; 

Property myProperty = ...; 



{ 

t.Lock(grid); 

Property outProp = 

grid.CreateProperty(myProperty.PropertyVersi 

on); 

grid.AddProperty(outProp); 

IEnumerable upCells = 

myProperty.GetAllUpscaledCells(true); 

foreach(Index3 index3 in upCells) 

{ 

outProp[index3] = myProperty[index3]; 

} 

t.Commit(); 

} 

FaultProperty 

Fault properties are used in Petrel to characterize fault transmissibility before 

the static reservoir model is fed to the simulation applications. They are 

contained in FaultProperty objects which are found in the Petrel Model 

tree in the pillar grid Fault Properties folder. FaultProperty objects have a 

PropertyVersion controlling their data type, and there can be only one 

FaultProperty of any given type in the folder. FaultProperty objects are 

different from general Property distribution in that they assign values to 

cells along the Fault pillars. 

public sealed class FaultProperty : FacadeConvenience, 

IDomainObject, 


{ ... 

public Fault Fault { get; } 

public IEnumerable FaultFaceProperties { get; 

} 

public int FaultFacePropertyCount { get; } 

public float Max { get; } 

public float Min { get; } 


public PropertyVersion PropertyVersion { get; } 


} 



Pillar Grid 

Fault properties are enumerations of FaultPropertyRecord instances. Each 

FaultPropertyRecord contains a cell IJK index and a Property value. 

public sealed class FaultFaceProperty : ILockObjectProvider 

{ 

public FaultFace Face { get; } 

public float Value { get; set; } 

} 

public struct FaultFace 

{ ... 

public Index3 Cell1 { get; } 

public Index3 Cell2 { get; } 

public Point3 FaceCenter { get; } 

public Point3[] FaceCorners { get; } 

} 

Here is an example that creates a FaultProperty that contains the data 

from a seismic cube that intersects a fault. The input arguments to the 

workstep include a Fault and a SeismicCube. 

protected override void InvokeSimpleCore(Arguments argumentPackage) 

{ 

Fault f = argumentPackage.Fault; 

SeismicCube c = argumentPackage.Cube; 

Grid g = fault.Grid; 

if (f == Fault.NullObject || c == SeismicCube.NullObject) 

{ 

PetrelLogger.ErrorBox("Fault and seismic cube required."); 

return; 

} 

// If the user didn't specify a PropertyVersion 

// then we'll create one... 

PropertyVersion pv = argumentPackage.FaultPropertyVersion; 

if (null == pv) 

{ 

PropertyVersionService pvs = PetrelSystem.PropertyVersionService; 

pv = pvs.FindOrCreate(g.ModelCollection.FaultPropertyVersions, 

c.PropertyVersion.UnitMeasurement); 

argumentPackage.FaultPropertyVersion = pv; 

} 

// Look for an existing FaultProperty based on the propertyVersion. 

Slb.Ocean.Petrel.DomainObject.PillarGrid.FaultProperty fp; 

fp = f.GetProperty(pv); 

using (ITransaction tr = DataManager.NewTransaction( )) 

{ 

if (fp == 

Slb.Ocean.Petrel.DomainObject.PillarGrid.FaultProperty.NullObject) 

{ 

tr.Lock(f); 

try 

{ 




fp = f.CreateProperty(pv); 

} 

catch (FaultPropertyException e) 

{ 

PetrelLogger.ErrorBox("Unable to create Fault Property.\n", 

e); 

tr.Abandon(); 

return; 

} 

} 

tr.Lock( fp ); 

// Create indices for accessing the seismic cube... 

Index3 traceTop = new Index3(); 

Index3 traceBot = new Index3(); 

Index3 valIndex = new Index3(); 

// Initialize variables for the max i,j,k. Not using 

// NumSamplesIJK inside loop can improve the performance 

// by an order of magnitude... 

int traceMaxI = c.NumSamplesIJK.I - 1; 

int traceMaxJ = c.NumSamplesIJK.J - 1; 

int traceMaxK = c.NumSamplesIJK.K - 1; 

foreach (FaultFaceProperty ffp in fp.FaultFaceProperties) 

{ 

Point3 facePoint = ffp.Face.FaceCenter; 

IndexDouble3 idx = c.IndexAtPosition( facePoint ); 

// Set indices for accesiing seismic trace at the facePoint... 

traceTop.I = (int)Math.Round(idx.I); 

traceTop.J = (int)Math.Round(idx.J); 

traceTop.K = 0; 

} 

traceBot.I = traceTop.I; 

traceBot.J = traceTop.J; 

traceBot.K = traceMaxK; 

if ((double.IsNaN(idx.I) || double.IsNaN(idx.J) || 

double.IsNaN(idx.K)) || (traceTop.I > traceMaxI) || 

(traceTop.J > traceMaxJ)) 

{ 

PetrelLogger.InfoOutputWindow("Point " + 

facePoint.ToString() + 

" outside cube."); 

continue; 

} 

// Get the seismic trace at this i,j... 

ISubCube sc = c.GetSubCube(traceTop, traceBot); 

// Get the seismic value at the location on the fault face... 

valIndex.I = traceTop.I; 

valIndex.J = traceTop.J; 

valIndex.K = (int)Math.Round(idx.K); 

float sampleVal = sc[valIndex]; 

// Set the fault face property... 

ffp.Value = sampleVal; 

} 

} 

tr.Commit( ); 



Pillar Grid 

When reading the FaultProperty, the geometry information is contained 

with the FaultFace and the property value is contained in the 

FaultFaceProperty object. Here is an example reading the 

FaultProperty objects for a fault. 


double avgVal = 0; 


// Process fault properties in fault 

foreach (FaultProperty fp in f) 

{ 

// Process fault face properties in fault property 

foreach (FaultFaceProperty ffp in fp) 

{ 

if (!double.IsNan( ffp.Value)) 

{ 

// Get the value 

avgVal += ffp.Value; 

count++; 

} 

} 

} 

// Get the position information for the face. 

Point3 fCenter = ffp.FaceCenter; 

Point3[] corners = ffp.FaceCorners; 

if (count > 0) 

{ 

PetrelLogger.InfoOutputWindow("Avg value: " + avgVal.ToString()); 

} 

Pillar Grid Intersection 

Service 

The IPillarGridIntersectionService is basically an engine that 

computes the intersections between a polyline (better a polyline implied by a 

sequence of TrajectoryRecord samples) and cells in a given Grid. 

This service replaces the earlier WellLog.GetLogInCells API, which only 

allowed the user to find the first and last log point within a cell. 

namespace Slb.Ocean.Petrel.DomainObject.PillarGrid 

{ 

public interface IPillarGridIntersectionService 

{ 

IEnumerable 

GetPillarGridPolylineIntersections(Grid grid, IPolyline3 

line); 

} 

} 

The GetPillarGridPolylineIntersections method computes the 

intersections between a polyline and the cells of a given Grid. It returns a list 

of SegmentCellIntersections describing the intersections or an empty 

list if no intersections exist. 

The intersections, if any exist, occur on cell faces (on single faces when 

entering or leaving or on a pair of cell faces inside the Grid). Cells without 




volume are also traversed. It is important that the Domain of the polyline 

argument is the same as that of the Grid. 

Fig. 5-25 Polyline Intersecting Grid Cells 

The resulting array of SegmentCellIntersections describes the instances 

of intersections with references to the leaving cell and/or entering cell. The 

position of each intersection is located on one or two cell faces, depending 

on whether the polyline enters the pillar grid (1 face), intersects a pair of cell 

faces internally (2 faces), or leaves the pillar grid (1 face). 

namespace Slb.Ocean.Petrel.DomainObject.PillarGrid 

{ 

public struct SegmentCellIntersection 

{ 

public SegmentCellIntersection(double 

intersectionInPolylineIndex, 

Index3 leavingCell, 

Index3 enteringCell, 

Point3 intersectionPoint, 

Vector3 surfaceNormal); 

public SegmentCellIntersection(double 

intersectionInPolylineIndex, 

Index3 leavingCell, 

Index3 enteringCell, 

Point3 intersectionPoint, 

Vector3 surfaceNormal, 

CellSide leavingCellSide, 

CellSide enteringCellSide); 

} 

} 

public Index3 EnteringCell { get; } 

public CellSide EnteringCellSide { get; } 

public double IntersectionInPolylineIndex { get; } 

public Point3 IntersectionPoint { get; } 

public bool IsNotEntering { get; } 

public bool IsNotLeaving { get; } 

public Index3 LeavingCell { get; } 

public CellSide LeavingCellSide { get; } 

public Vector3 SurfaceNormal { get; } 



Pillar Grid 

EnteringCell provides the cell index if the polyline segment enters a cell. A 

null is returned if the polyline leaves the Grid coming from the inside. 

EnteringCellSide provides the CellSide of the EnteringCell. 

IntersectionInPolylineIndex provides the fractional index into the 

polyline (array of points) used in the intersection computation. This implicitly 

defines a single segment (a pair of points) and the fractional index describes 

the relative distance between the intersection point and the points of the 

segment. 

IntersectionPoint provides the actual intersection point 

(Slb.Ocean.Geometry.Point3) in 3D. The point is defined in the context 

of Domain of the Grid. 

IsNotEntering returns true if the polyline segment leaves the Grid 

coming from the inside and false if this is an internal cell intersection. 

IsNotLeaving returns true if the polyline segment enters the Grid from 

the outside; false if this is an internal cell intersection. 

LeavingCell provides the cell index if the polyline segment leaves a cell. A 

null is returned if the polyline enters the Grid from the outside. 

LeavingCellSide provides the CellSide of the LeavingCell. 

SurfaceNormal provides the normal vector 

(Slb.Ocean.Geometry.Vector3) at the intersection. 

Let us look at a simple example to understand the information contained in 

SegmentCellIntersection. 

Fig. 5-26 Polyline Cell Intersection Scenarios 




For our example we consider the intersections of four different polylines 

with a simple grid composed of two cells. Polyline A starts and ends outside 

the grid, polyline B starts inside Cell1 but ends outside the grid, polyline C 

starts outside but ends in Cell2, and polyline D starts inside Cell1 and ends 

inside Cell2. This allows us to cover all possible scenarios. 

In the case of Polyline A, we get three SegmentCelllntersections 

corresponding to the three intersections at A1, A2, and A3. Polyline A enters 

the grid at A1, hence the intersection is on one cell face only (CellSide.Up 

of Cell1). A2 is an internal intersection located on two cell faces 

(CellSide.Down of Cell1 and CellSide.Up of Cell2). The polyline leaves 

the pillar grid at A3, hence the intersection is again on one cell face only 

(CellSide.Down of Cell2). For the first SegmentCellIntersection, 

IsNotLeaving is true because the polyline segment enters the grid from 

the outside. For the third SegmentCellIntersection, IsNotEntering is 

true because the polyline segment leaves the grid here coming from the 

inside. 

For each intersection, the IntersectionInPolylineIndex defines the 

relative distance between the intersection point and the end points of the 

polyline segment. A1 has fractional index 1.3 and lies between index 1 and 2 

of the polyline, A2 has fractional index 2.6 and lies between index 2 and 3 of 

the polyline. Similarly A3 has fractional index 4.4. 

The following table describes the three SegmentCelllntersections for 

polyline A. 

Table 5-1 Polyline A Intersections 

Polyline A Intersections 

SegmentCelllntersection 1 2 3 

EnteringCell 

Cell1 Cell2 null 

(0,0,0) (0,0,1) 

EnteringCellSide Up Up None 

LeavingCell null Cell1 

(0,0,0) 

Cell2 

(0,0,1) 

LeavingCellSide None Down Down 

IntersectionPoint A1 A2 A3 

IntersectionInPolyLineIndex 1.3 2.6 4.4 

IsNotEntering false false true 

IsNotLeaving true false false 

In the case of polyline B we get two SegmentCelllntersections 

corresponding to the two intersections at B1 and B2. The following table 

describes the two SegmentCelllntersections for polyline B. Since the 



Pillar Grid 

polyline starts within the grid, there is no SegmentCelllntersection with 

IsNotLeaving set to true. 

Table 5-2 Polyline B Intersections 

Polyline B Intersections 

SegmentCellIntersection 1 2 

EnteringCell Cell2 (0,0,1) null 

EnteringCellSide Up None 

LeavingCell Cell1 (0,0,0) Cell2 (0,0,1) 

LeavingCellSide Down Down 

IntersectionPoint B1 B2 

IsNotEntering false true 

IsNotLeaving false false 

In the case of polyline C we get two SegmentCelllntersections 

corresponding to the two intersections at C1 and C2. The following table 

describes the two SegmentCelllntersections for polyline C. Since the 

polyline ends within the grid, there is no SegmentCelllntersection with 

IsNotEntering set to true. 

Table 5-3 Polyline C Intersections 

Polyline C Intersections 

SegmentCellIntersection 1 2 

EnteringCell Cell1 (0,0,0) Cell2 (0,0,1) 

EnteringCellSide Up Up 

LeavingCell null Cell1 (0,0,0) 

LeavingCellSide None Down 

IntersectionPoint C1 C2 

IsNotEntering false false 

IsNotLeaving true false 

In the case of polyline D we get only one SegmentCelllntersection 

corresponding to the intersection at D1. The following table describes the 

only SegmentCelllntersection for polyline D. Since the polyline starts 

and ends within the grid, both IsNotLeaving and IsNotEntering are set 

to false. 

Table 5-4 Polyline D Intersections 

Polyline D Intersections 

SegmentCellIntersection 1 

EnteringCell Cell2 (1,1,2) 

EnteringCellSide 

Up 

LeavingCell Cell1 (1,1,1) 




Table 5-4 Polyline D Intersections 

Polyline D Intersections 

LeavingCellSide 

IntersectionPoint 

IsNotEntering 

IsNotLeaving 

Down 

D1 

false 

false 

Here is how you can get the IPillarGridIntersectionService service to 

find grid polyline intersections. 

... 

Grid grid; 

IPolyline3 line; 

... 

IPillarGridIntersectionService pgiservice; 

pgiservice = CoreSystem.GetService(); 

... 

IEnumerable intersectionsegments = 

pgiservice.GetPillarGridPolylineIntersections(grid, line); 

foreach(SegmentCellIntersection sci in intersectionsegments) 

{ 

Point3 pt = sci.IntersectionPoint; 

Index3 cell = sci.EnteringCell; 

CellSide enteringSide = sci.EnteringCellSide; 

... 

} 

... 

Data Analysis 

Data analysis is a Petrel process that computes statistics on a 

DictionaryProperty. 

Fig. 5-27 Data Analysis in Petrel 



Pillar Grid 

The results are stored with the DictionaryProperty but are not exposed 

as a class member as they are only present if the data analysis module has 

been run. 

The Ocean API exposes these statistical results as a virtual 3D property that 

can be accessed in memory. The virtual Property cannot be added to the 

Grid object, but values can be retrieved and copied in a newly created 

Property. 

Two types of statistics are retrieved: “Vertical Proportion,” the depth 

percentage of a given cell where a facies code (or any DictionaryProperty 

symbol) is found and “Attribute Probability,” the probability of finding a 

given facies code or DictionaryProperty symbol in a cell. 

Data analysis results are obtained from a fetcher interface, 

IDataAnalysisFetcher, whose implementation instance is returned by the 

static class PetrelProject.SimulationData. 

namespace 


{ 

public enum DiscreteDataAnalysisType 

{ 

VerticalProportion, 

AttributeProbability 

} 

public interface IDataAnalysisFetcher 

{ 

Property GetDiscreteDataAnalysis( 

DictionaryProperty property, 

DiscreteDataAnalysisType analysisType, 

int 

faciesCode 

); 

} 

} 




This example shows how to retrieve statistics in a Property that will be stored 

in the Petrel project for later use. 

DictionaryProperty prop = ...; 

Grid g = ...; 


IDataAnalysisFetcher f; 

f = 

PetrelProject.SimulationData.GetDataAnalysis 

Fetcher(prop); 

DiscreteDataAnalysisType t; 

t = 

DiscreteDataAnalysisType.VerticalProportion; 

Property stat = 

f.GetDiscreteDataAnalysis(prop, t, 0); 



{ 

trans.Lock(g); 

Property proportion = g.CreateProperty(pv); 

g.AddProperty(proportion); 

for (int i = 0; i < 

proportion.NumCellsIJK.I; i++) 

for (int j = 0; j < 

proportion.NumCellsIJK.J; j++) 

for (int k = 0; k < 

proportion.NumCellsIJK.K; k++) 

proportion[i, j, k] = stat[i, j, k]; 


} 



Reservoir Simulation 


The dynamic reservoir model focuses on production estimation over long 

periods of time. As the reservoir starts losing formation pressure, the flow of 

borehole fluid is modified. Simulation predicts the variations of fluid flow 

characteristics over time. It is an essential component in petroleum reservoir 

management. 

Case Run 

Summary Category Summary Template Summary Result 

Fig. 5-28 Simulation Domain 

Simulation Result 

Classes 

Simulation results, the list of production data as a function of time, are not 

listed as a domain object on the Petrel "Case" and "Results" trees. 

In the "Case" tree, we have the following objects: 

• Case objects that represent the input to a case analyzer or simulator. 

• Simulation objects that represent the simulation cases. 

In the "Results" tree we have the following object types: 

• Properties defined by ResultProperty objects that represent 

properties for which there are TimeSeries objects available. 

• Categories defined by ResultCategory objects that provide a filter, 

typically a well or field, when navigating to a TimeSeries. 

All these objects will determine the specific Simulation results. 




CaseDefinition 

CaseRun SummaryTemplate SummaryCategory 

SummaryResult 


TimeVector 

DataVector 

Fig. 5-29 Objects That Determine Specific Simulation Results 

Data Analysis and 

Simulation Cases 

The Cases tree lists data analysis and simulation case runs. Data analysis case 

runs are CaseAnalysis objects and simulation case runs are Simulation 

objects. Simulation objects derive from CaseAnalysis objects and 

include methods and properties to get time series and streamline sets for the 

simulation. 

It is important to note that Case, CaseAnalysis, and Simulation objects 

are read-only objects. You cannot create or modify these objects through the 

API if they have been created by the Petrel user. 

There are two root classes for accessing cases and simulations. 

AnalysisRoot provides navigation to Case and CaseAnalysis objects. 




SimulationRoot provides navigation to Simulation objects. Here is an 

example accessing each type of object. 

using Slb.Ocean.Petrel.DomainObject.Analysis; 

// Get the project 


// Get the root object for analysis for the project. 

AnalysisRoot aRoot = AnalysisRoot.Get( proj ); 

// Process each case 

foreach ( Case c in aRoot.Cases ) 

{ 

PetrelLogger.InfoOutputWindow( "Case " + c.Name ); 

} 

// Process each case analysis 

foreach ( CaseAnalysis ca in c.CaseAnalyses ) 

{ 

PetrelLogger.InfoOutputWindow( "Case run " + ca.Name ); 

} 

// Get the root simulation object 

SimulationRoot sRoot = SimulationRoot.Get( proj ); 

// Process each simulation object 

foreach ( Simulation sim in sRoot.Simulations ) 

{ 

PetrelLogger.InfoOutputWindow( "Simulation " + sim.Name ); 

} 

The Simulation class provides access to time series and streamline data 

through its properties and methods. 

namespace Slb.Ocean.Petrel.DomainObject.Simulation 

{ 

public sealed class Simulation : CaseAnalysis 

{ ... 

public IEnumerable TimeSeries { get; } 

public StreamlineSet StreamlineSet { get; } 

public IEnumerable GetTimeSeries( 

ResultProperty property ); 

public IEnumerable GetTimeSeries( 

ResultProperty property, 

ResultCategory category ); 

} 

Accessing 

Simulation Data by 

Time Series 

Time series contain simulation result values versus time. The simulation 

property data is typically displayed in the Petrel Function window with the 

time series as the X axis. A time series is composed of time samples and 

corresponding data samples. You can only read time series data through the 




API; writing time series is not possible in the current release. The 

TimeSeries class defines this type. 

namespace Slb.Ocean.Petrel.DomainObject.Analysis 

{ 

public sealed class TimeSeries 

{ 

public IEnumerable DataSamples { get; } 



public IDictionary Samples { get; } 

public IEnumerable TimeSamples { get; } 

} 

} 

The DataSamples property enumerates the result values for the series. The 

TimeSamples property enumerates date references parallel to the result 

values. The Samples property returns values based on a date key. 


SimulationRoot sr = SimulationRoot.Get( Proj ); 

ResultCategory rc = ...; 

ResultProperty rp = ...; 

string dateToTry = "08/01/2007"; 

DateTime keyDate = DateTime.Parse( dateToTry ); 

// Process each simulation 

foreach (Simulation sim in sr.Simulations) 

{ 

PetrelLogger.InfoOutputWindow("Simulation: " + sim.Name); 

} 

} 

// Process each time series in the simulation 

// for the provided ResultProperty and ResultCategory 

foreach (TimeSeries ts in sim.GetTimeSeries( rp, rc )) 

{ 

PetrelLogger.InfoOutputWindow("Time Series: " + ts.Name); 

// Print out the sample values 

foreach (double sample in ts.DataSamples) 

{ 

PetrelLogger.InfoOutputWindow(sample.ToString()); 

} 

// Print the value for each key in the series 

foreach (DateTime key in ts.Samples.Keys) 

{ 

PetrelLogger.InfoOutputWindow("Key: " + key.ToString() + 

" Sample: " + ts.Samples[key].ToString()); 

} 

// Print the value at the user provided date 

// Note: the users input DateTime must be an exact match. 

PetrelLogger.InfoOutputWindow( "Sample at " + Date + ": " + 

ts.Samples[keyDate].ToString( ) ); 




Result Filtering 

The TimeSeries data is read through the API and is filtered by simulation 

result properties and categories. 

A result property type, defined by the class ResultProperty, is a link to the 

PropertyVersion for the simulation data. It provides a filter for one 

measurement type. 


{ 

public sealed class ResultProperty : FacadeConvenience, 

IDomainObject 

{ 



public static ResultProperty NullObject { get; } 


} 

} 

ResultProperty objects are available as well as an enumerable property, 

ResultProperties, of the AnalysisRoot class. 





// Get a list of result properties 

List props; 

props = new List(aRoot.ResultProperties); 

The time series data may also be filtered by category. A category is 

represented by a Field, Group, or Well and is defined by the 

ResultCategory class. 


{ 

public sealed class ResultCategory : FacadeConvenience, 

IDomainObject 

{ 



public static ResultCategory NullObject { get; } 

} 

} 




ResultCategory objects are also available as an enumerable property of 

AnalysisRoot. 





// Get a list of result categories 

List cats; 

cats = new List(aRoot.ResultCategories); 

Filtering TimeSeries objects is done by using the ResultProperty and/or 

the ResultCategory objects to retrieve the TimeSeries object from the 

Simulation. This is done through the GetTimeSeries method. You may 

choose to filter only by ResultProperty or by both ResultProperty and 

ResultCategory. Here is an example that gets the TimeSeries for each 

ResultProperty and ResultCategory combination. 



// Get the root objects for analysis and simulation. 


SimulationRoot sRoot = SimulationRoot.Get( proj ); 

// Get a list of result properties and categories 

List props; 

props = new List(aRoot.ResultProperties); 

List cats; 

cats = new List(aRoot.ResultCategories); 

for (int i = 0; i < aRoot.ResultPropertyCount; i++) 

{ 

for (int j = 0; j < aRoot.ResultCategoryCount; j++) 

{ 

foreach (Simulation sim in sRoot.Simulations) 

{ 

foreach (TimeSeries ts in sim.GetTimeSeries(props[i], 

cats[j])) 

{ 

... 

} 

} 

} 

} 

Streamlines 

Streamlines define fluid paths in a reservoir. They have start and stop 

positions typically related to a completion interval in a borehole and are 




represented graphically by 3D polyline objects. They are created with respect 

to a DateTime so they may be grouped in time stamped collections. 

Fig. 5-30 Streamlines Between Two Wells 

Reading Streamline 

Data 

The Simulation class provides read access to streamlines through the 

StreamlineSet property referencing the StreamlineSet class. 




StreamlineSet allows the creation and reading of streamline boundaries, 

properties, and subsets. 

namespace Slb.Ocean.Petrel.DomainObject.Simulation.Streamline 

{ 

public sealed class StreamlineSet : FacadeConvenience, 

IDomainObject 

{ 


public static StreamlineSet NullObject { get; } 

public IEnumerable StreamlineBoundaries 

{ get; } 

public IEnumerable StreamlineProperties 

{ get; } 

public int StreamlineSubsetCount { get; } 

public IEnumerable StreamlineSubsets { get; 

} 

public PropertyVersion CreateNodeProperty( PropertyVersion 

pv); 

public PropertyVersion CreateSegmentProperty ( 

PropertyVersion pv ); 

public StreamlineSubset CreateStreamlineSubset ( 

DateTime dateTime ); 

public PropertyType GetPropertyType ( PropertyVersion pv ); 

public StreamlineSubset GetStreamlineSubset ( 

DateTime dateTime ); 

public bool HasProperty ( PropertyVersion pv ); 

} 

} 

A subset represents streamline related data for a given time step. Streamline 

subsets are defined by the StreamlineSubset class. You can navigate to a 

subset through the StreamlineSubsets property. 

Simulation sim = ...; 

DateTime keyDate = ...; 

StreamlineSet sls = sim.StreamlineSet; 

// Process each subset 

foreach ( StreamlineSubset subset in sls.StreamlineSubsets ) 

{ 

} 

// See if the date matches our requested date. 

if (sub.DateTime.Equals(keyDate)) 

{ 

... 

} 

A StreamlineSubset contains a set of Streamline objects for a given time 

as defined by its DateTime property. You can read all of them through the 




Streamlines property or a group for a particular boundary using the 

GetStreamlines method. 


{ 

public sealed class StreamlineSubset : FacadeConvenience, 

IDomainObject 

{ 

public DateTime DateTime { get; } 



public static StreamlineSubset NullObject { get; } 

public int StreamlineCount { get; } 

public IEnumerable Streamlines { get; } 

public StreamlineSet StreamlineSet { get; } 

public event 

EventHandler 

StreamlinesChanged; 

public Streamline CreateStreamline ( ); 


public IEnumerable GetStreamlines ( 

StreamlineBoundary streamlineBoundary ); 

} 

} 

Here is an example accessing all streamlines in a subset and then only those 

for a particular boundary. We will use the start boundary from the first 

streamline to later query for all streamlines with the same boundary. 

StreamlineSubset sub = ...; 

StreamlineBoundary bound = null; 

bool first = false; 

// Process all streamlines in subset 

foreach ( Streamline sline in sub.Streamlines ) 

{ 

// capture the boundary for the first one to use later 

if (first) 

bound = sline.StartBoundary; 

} 

...; 

// Process only those streamlines with the captured boundary 

foreach ( Streamline sline in sub.GetStreamlines( bound )) 

{ 

...; 

}\ 

Streamlines are defined by the Streamline class. The streamline Geometry 

property is a polyline (IPolyline3) defining the flow path of the streamline. 




Corresponding to this there may be node and segment properties for 

different PropertyVersion defined types of data. 


{ 

public sealed class Streamline 

{ 

public IPolyline3 Geometry { get; set; } 

public int GeometryCount { get; } 

public bool IsValid { get; } 

public bool IsWritable { get; } 

public int PropertyCount { get; } 

public StreamlineBoundary StartBoundary { get; set; } 

public StreamlineBoundary StopBoundary { get; set; } 

public StreamlineSubset StreamlineSubset { get; } 

public IEnumerable GetNodeProperty ( 


public IEnumerable GetSegmentProperty ( 


public bool HasGeometry ( ); 

public bool HasProperty ( PropertyVersion pv ); 

public void SetNodeProperty ( PropertyVersion pv, 

IEnumerable data ); 

public void SetSegmentProperty ( PropertyVersion pv, 

IEnumerable data ); 

} 

} 

Streamlines have boundaries that define their beginning and ending points. 

These boundaries may be defined at Borehole locations or they may be 

somewhere in the reservoir not related to a Borehole. The 

StreamlineBoundary class defines the type for a streamline boundary. 


{ 

public sealed class StreamlineBoundary : FacadeConvenience, 

IDomainObject 

{ 


public bool IsBorehole { get; } 


public static StreamlineBoundary NullObject { get; } 

} 

} 

When processing streamlines, you should check that the streamline is well 

defined by checking its IsValid property. IsValid is true if the 

streamline has at least three points, both start and stop boundaries, and all 




properties are valid as nodes or segments. Here is an extension of the 

previous example that processes streamlines for a boundary. 

// Process only those streamlines with the captured boundary 

foreach ( Streamline sline in sub.GetStreamlines( bound )) 

{ 

// Check for valid streamline 

if ( sline.ISValid ) 

{ 

// Process streamline points. 

foreach ( Point3 pt in sline.Geometry ) 

{ 

...; 

} 

} 

} 

Creating Streamlines 

Streamlines may be created under a StreamlineSubset. Once created it is 

advised that you set the Geometry and either node or segment properties 

immediately. Here is an example. 

StreamlineSubset sub = ...; 


IPolyline3 streamlinePoints = ...; 

double[] nodeValues = ...; 

using ( ITransaction tr = DataManager.NEwTransaction()) 

{ 

tr.Lock( sub ); 

Streamline myStreamline = sub.CreateStreamline( ); 

myStreamline.Geometry = streamlinePoints; 

myStreamline.SetNodeProperty( pv, nodeValues ); 

} 

tr.Commit( ); 

If you have boundaries you may set them as well using: 

myStreamline.StartBoundary = startBound; 

myStreamline.StopBoundary = stopBound; 

This must be inside the transaction. Currently the API does not support the 

creation of boundaries so you would have to use existing 

StreamlineBoundary objects. 






6 Input and Output 


Extending Import/Export.............................................................................176 

Open Petrel Binary Format ..........................................................................182 

RESCUE Format..........................................................................................183 

6: Input and Output 175 



Extending Import/Export 

Ocean allows three types of programmatic import and export: 

1. Extending the Petrel import/export capabilities with new file types and 

corresponding implementations. 

2. Using the Open Petrel Binary (OPB) format to import and export OPB 

files for a pillar grid instance. 

3. Using the RESCUE format to import and export a pillar grid instance. 

Petrel allows the end user to import and export Petrel project data. 

Fig. 6-1 

Petrel Import File Dialog 

The data import and export capabilities of Petrel can be extended to support 

new file types. These new file types will be added to the standard Petrel 

import/export dialog as if they were native to the system. The steps to add a 

new file type are: 

1. Derive from the abstract FileFormat class. 

2. Add the new file format to the IFileFormatCollection. 

The FileFormat class contains the information necessary to populate the 

standard Petrel import and export dialogs. It also determines if a particular 

object can be imported or exported, and it actually does the import and/or 

export work for the file type. 

public abstract class FileFormat 

{ 

public abstract ImportExportCapabilities Capabilities { get; } 

public abstract string Description { get; } 

public abstract string Extension { get; } 

public abstract string Name { get; } 

public abstract string TypeOfSubject { get; } 




abstract bool CanExport(object o); 

abstract bool CanImport(object parent); 

} 

abstract void Export(string filename, object o); 

abstract void Import(string filename, object parent); 

The ImportExportCapabilities enumeration describes what the file can 

do with the file: nothing, import, export, or both import and export. 

public enum ImportExportCapabilities 

{ 

None = 0, 

ImportOnly = 1, 

ExportOnly = 2, 

ImportExport = 3 

} 

This will determine if the file type is displayed in either of the standard Petrel 

import or export dialogs. 

The sample file format implementation will export a continuous well log to 

an ASCII file of MD and data values and import it back to a well. 

public class ImportExportWellLog : FileFormat 

{ 

public override ImportExportCapabilities Capabilities 

{ get { return ImportExportCapabilities.ImportExport; } } 

The values of the Description, Extension, and Name properties will be 

displayed in the standard Petrel import or export dialogs. The Extension 

should not return or include the ‘.’ in the file name; it should only return the 

file extension after the dot. The Name will also be displayed in the Format 

name column of the Petrel Import data table (Help->List of available 

formats). 

public override string Description 

{ get { return "Well log data with header in ASCII format"; } } 

public override string Extension 

{ get { return "asc"; } } 

public override string Name 

{ get { return "AsciiWellLog"; } } 




Fig. 6-2 

Standard Petrel Import Dialog with New File Name, Extension, and 

Description 

The TypeOfSubject property value will be displayed in the Data type 

column of the Petrel Import data table (Help->List of available formats). It 

gives the name of the type of object data that is imported or exported using 

the format. 

public override string TypeOfSubject 

{ get { return "WellLog"; } } 

Fig. 6-3 

Import Data Table with New FileFormat 




CanImport determines if the file format can be imported under the given 

parent; the parent can either be the root of the tree represented by null or a 

domain object within the tree. CanExport reports whether the specified 

domain object can be exported to the file format. 

public override bool CanImport(object parent) 

{ 

return (parent is Borehole); 

} 

public override bool CanExport(object obj) 

{ 

return (obj is WellLog); 

} 

Well logs are contained by boreholes, so the file format can only be imported 

if the parent is a Slb.Ocean.Petrel.DomainObject.Well.Borehole. The 

sample only exports well logs. 

The Import method performs the import of the specified filename on disk 

into a given parent object. If the parent is the root level of a tree, then its 

argument value will be null. If the parent is not a native Petrel domain 

object, it is the responsibility of the import implementation to add the child 

to the parent "Implement INotifyingEnumerable" in Volume 3, Chapter 13, 

"Custom Domain Objects" on page 770. The import implementation needs 

to place any new domain objects at the proper location in the Petrel tree 

hierarchy. 

Note that the implementation of Import depends on what type of data is 

being imported, what object is its container, and how the file is formatted. 

When dealing with native Petrel domain objects, it will use transactions when 

creating new data and follow the patterns and practices defined by the native 

Petrel domain object API. The data given to the Ocean API is always 

expected to be in the Invariant unit system; any unit conversions necessary 

must be done by the Import function. 

public override void Import(string f, object parent) 

{ 

if (!File.Exists(f)) return; 

Borehole b = (Borehole)parent; 

PropertyVersion pv = this.PropVersionFromHeader(f, b); 


{ 

trans.Lock(b); 

WellLog newWellLog = b.Logs.CreateWellLog(pv); 

List sampleList = new List(); 

StreamReader sr = new StreamReader(f, Encoding.ASCII); 

try 

{ 

// Read the file stream till end of stream 

... 




string mdData = data[0]; 

string valData = data[1]; 

double mdVal = Double.Parse(mdData); 

float val = float.Parse(valData); 

sampleList.Add(new WellLogSample(mdVal, val)); 

... 

newWellLog.Append(sampleList); 

} 

finally 

{ 

sr.Close(); 

} 


} 

} 

The Export method performs the export of the specified object into a specified 

filename on disk. Transactions are not needed since the export reads the 

data and is not creating data. The data from the Ocean API is always returned in 

the Invariant unit system. 

public override void Export(string f, object obj) 

{ 

if (File.Exists(f)) 

File.Delete(f); 

StreamWriter sw = new StreamWriter(f, true, Encoding.ASCII); 

WellLog wellLog = obj as WellLog; 

try 

{ 

this.WriteHeader(sw, wellLog); 

float val = 0.0f; 

double md = 0.0f; 

foreach (WellLogSample s in wellLog.Samples) 

{ 

md = s.MD; 

val = s.Value; 

... 

sw.WriteLine(s.MD + " " + s.Value); 

} 

sw.AutoFlush = true; 

} 

finally 

{ 

sw.Close(); 

} 

} 

} 

At this point, we have a FileFormat, but Petrel does not know that we have 

this new functionality to offer. The IFileFormatCollection service is 

available from the static convenience class PetrelSystem. 

public interface IFileFormatCollection 

{ 

void Add (FileFormat f); 

void Remove (FileFormat f); 

} 




The new FileFormat needs to be added to the file format collection; this is 

typically done in the module’s Integrate method. 

public void Integrate () 

{ 

PetrelSystem.FileFormats.Add(new ImportExportWellLog()); 

} 




Open Petrel Binary Format 

The IOpenPetrelBinaryFormat service imports and exports Open Petrel 

Binary (OPB) files for a 

Slb.Ocean.Petrel.DomainObject.PillarGrid.Grid instance. The 

limitations of this format are: 

1. User defined continuous templates are not exported; they are replaced 

with the ‘General’ template. 

2. User defined discrete templates are not exported; they are replaced with 

the ‘General discrete’ template. 

3. Property folders are not exported. Properties in these folders are 

exported to the parent Properties folder in the Models pane. 

4. Contact Sets are not exported. 

The Export method exports a specified pillar grid into a specified file on 

disk in the Open Petrel Binary format. The Import method performs the 

import of a grid in OPB format on disk into a 

Slb.Ocean.Petrel.DomainObject.PillarGrid.Grid instance. It will be 

placed into the given parent ModelCollection; if the parent is null, the new 

grid will be imported into the root of the Models tree. 

public interface IOpenPetrelBinaryFormat 

{ 

void Export(string filename, Grid pillarGrid); 

Grid Import(string filename, ModelCollection parent); 

} 

The Export method exports a specified pillar grid into a specified file on 

disk in the Open Petrel Binary format. The Import method performs the 

import of a grid in OPB format on disk into a 

Slb.Ocean.Petrel.DomainObject.PillarGrid.Grid instance. It will be 

placed into the given parent ModelCollection; if the parent is null, the new 

grid will be imported into the root of the Models tree. 

IOpenPetrelBinaryFormat opb; 

obp = CoreSystem.GetService(); 



RESCUE Format 

RESCUE Format 

The RESCUE (REServoir Characterization Using Epicenter) format is an 

open POSC standard for exchange of geomodels. Ocean supports import 

and export of both binary and ASCII RESCUE formats. 

The IRescueFormat service imports and exports Rescue files for a 


Rescue data model is not fully compatible with Petrel data model i.e. export 

and re-import may not be fully lossless. Some data, such as zone hierarchies, 

will be lost. 

public interface IRescueFormat 

{ 

void Export(string directory, Grid pillarGrid, bool isBinary); 

Grid Import(string filename); 

Grid Import(string filename, ModelCollection parent); 

} 

The Export method performs the export of the specified 

Slb.Ocean.Petrel.DomainObject.PillarGrid.Grid into a specified 

directory on disk. The data is stored in files within the specified directory 

which is created if it does not exist. Transactions are not needed since the 

export reads the data and is not creating data. The isBinary argument 

specifies the type (binary or ASCII) of Rescue file. The exported file names 

will have extension "bin" to indicate binary format and "txt" for ASCII 

format. All filenames will have a numeric extension following the "bin" or 

"txt" except the main Rescue file. 

Local disk (D:) 

provided directory 

main rescue file 

Rescue 

Rescue.bin 

Rescue.bin.31 

Rescue.bin.37 

... 

Fig. 6-4 

Exported Rescue Format File Names 

The Slb.Ocean.Petrel.DomainObject.PillarGrid.Grid domain object 

needs to satisfy the following criteria for allowing export to Rescue format. 

1. Zones and horizons must have unique names. 

2. Grid should have at least two horizons and one zone. 




3. Grid should have a limit (definition of area it encompasses). 

string directory = ...; 

Grid pillarGrid = ...; 

IRescueFormat rescueService = null; 

rescueService = CoreSystem.GetService(); 

try 

{ 

// Export as a Binary rescue file 

rescueService.Export(directory , pillarGrid, true); 

} 

catch(Exception e) 

{ 

PetrelLogger.InfoOutputWindow(e.Message); 

} 

The Import method performs the import of a Rescue file on disk into a 


Import method requires the main Rescue file name (that does not have a 

numeric extension). 

The imported grid will be placed into the first instance of ModelCollection 

under the models root. If the parent model collection is provided as an 

argument, the new grid will be imported into the specified 

ModelCollection. 

string filename = "Rescue.bin"; 

Grid pillarGrid = Grid.NullObject; 

IRescueFormat rescueService = null; 

rescueService = CoreSystem.GetService(); 

try 

{ 

pillarGrid = rescueService.Import(filename); 

} 

catch(Exception e) 

{ 

PetrelLogger.InfoOutputWindow(e.Message); 

} 



RESCUE Format 

The name of the new pillar grid is fixed by the system. It may be renamed by 

the user from the GUI. 

imported grid 

Fig. 6-5 

Imported Grid 

Since this is a service, it can be accessed via the general 

CoreSystem.GetService functionality. 

IRescueFormat rescueFormat; 

rescueFormat = CoreSystem.GetService(); 






Index 

D 

Data Analysis ...................................................................................................................................160 

DictionaryFaultProperty .................................................................................................................117 

DictionaryHorizonProperty ............................................................................................115, 117, 135 

DictionaryProperty ..................................................................................................................113, 150 

DictionaryPropertyRecord .............................................................................................................117 

DictionaryPropertyVersion ..............................................................................................................62 

DictionaryWellLog ......................................................................................................................61, 62 

Domain ...........................................................................................................................................7, 72 

Droid 

E 

IIdentifiable .....................................................................................................................................10 

export ...............................................................................................................................................176 

FileFormat .............................................................................................................................176, 180 

IFileFormatCollection .............................................................................................................176, 180 

OpenPetrelBinary Format ...............................................................................................................182 

I 

IDomainObject ...................................................................................................................................11 

IDroidResolver ..................................................................................................................................15 

IIdentifiable ........................................................................................................................................10 

import ...............................................................................................................................................176 

FileFormat .............................................................................................................................176, 180 

IFileFormatCollection .............................................................................................................176, 180 

OpenPetrelBinary Format ...............................................................................................................182 

Index classes 

Index2 ..................................................................................................................................133, 140 

Index3 ..........................................................................................................................................122 

INotifyingOnDeleted .........................................................................................................................11 

M 

ModelCollection ......................................................................................................................135, 182 

MultiTraceWellLog ............................................................................................................................63 

MultiTraceWellLogSample ...............................................................................................................63 

N 

NullObject ..........................................................................................................................................12 

O 

Open Petrel Binary format 

IOpenPetrelBinaryFormat ...............................................................................................................182 

© 2007 Schlumberger. All rights reserved. 

Index 187


P 

Petrel Trees 

Input .............................................................................................................................................116 

PetrelProject ....................................................................................................................................161 

PetrelUnitSystem ............................................................................................................................144 

Pillar ..................................................................................................................................121, 122, 133 

Point classes 

Point3 ...................................................................................................................................122, 123 

PointPropertyRecord ..............................................................................................................114, 117 

PolylineSet .........................................................................................................................................75 

Property .................................................................61, 72, 97, 113, 114, 116, 120, 135, 150, 161, 162 

Property versions 

S 

DictionaryPropertyVersion ................................................................................61, 115, 116, 117, 150 

PropertyVersion ...............................................................................................62, 115, 116, 117, 144 

Shapes ...............................................................................................................................................72 

SimulationData ................................................................................................................................161 

T 

Templates 

ILogTemplate ..................................................................................................................................62 

Transactions ......................................................................................................................................12 

ITransactionManager .......................................................................................................................13 



www.ocean.slb.com 

*Mark of Schlumberger 

Copyright © 2007 Schlumberger. All rights reserved. 07-IS-475

Petrel Data Access.book - Ocean - Schlumberger

Create successful ePaper yourself

Delete template?

Save as template?