OpenWorks® 5000.0.1.5 Development Kit Release Notes

OpenWorks® 5000.0.1.5 Development Kit Release Notes

OpenWorks® 5000.0.1.5 Patch Software Development Kit

Release Notes

Introduction......................................................................................................................... 2 System Requirements.......................................................................................................... 3 Gdi Class Differences ......................................................................................................... 5 Fixed Problems ................................................................................................................... 6 Enhancements and New Functionality................................................................................ 7 New Application Programming Interfaces (APIs)............................................................ 25 Licensing........................................................................................................................... 29 Installation......................................................................................................................... 30 Third-Party Licenses......................................................................................................... 31 Contacting Support ........................................................................................................... 32 Trademarks ....................................................................................................................... 33

Release Notes of 34 August 2009


Introduction

This version of the OpenWorks® Development Kit is compatible with the OpenWorks® 5000.0.1.0 release.

Please refer to the OpenWorks Runtime Release Notes with respect to bug fixes.

Refer to the OpenWorks® Software Development Kit User’s Guide for detailed information on using the Development Kit.

Complete OpenWorks SDK documentation is located in $OWHOME/devkit/doc directory.

Halliburton acknowledges that certain third party code has been bundled with, or embedded in, its software. The licensors of this third party code, and the terms and conditions of their respective licenses, may be found at the following location:

[Installdir]\docs\Third_Party.pdf

Header changes between R5000.0.1 and R5000.0.1.5Patch are as follows. In the Pick structure the following are now defined as floats:

float user_def_num_1;

float user_def_num_2; float user_def_num_3;



System Requirements

This release of the OpenWorks Development Kit 5000.0.1.5 requires the following platforms and software versions:

Product/package: Red Hat Enterprise Linux 5.0 (32-bit and 64-bit)

Certification OS: Red Hat Linux 4 Update 4

Motif: 2.2/X11R6

g++: 3.4.6

g77: 3.4.6

Oracle: 10g

Product/Package: Sun Solaris 10 (32-bit)

Certification OS: Solaris 10 11/06

C++ Compiler: C++ Studio 11

C Compiler: C Studio 11

Fortran Compiler: Fortran Studio 11

Oracle: 10g

Studio 11 Patches: 120760-06 120761-02 121015-02 121017-02 121019-02 121021-02 121023-02



Product/Package: Windows (32bit and 64bit)

Certification OS: Windows XP (32bit) & Windows 2003 (64bit)

Visual Studio 2005 with SP1

Oracle 10g



Gdi Class Differences

Listed under General Information, class differences include changes within classes, removal of classes and new classes to the software are described in detail.

What’s New:

Descriptive Class Differences

Detailed Class Differences between OW 5000.0.0.3 and OW 5000.0.1.0



Detailed Class Differences between OW 5000.0 and OW 5000.0.1.0

Detailed Class Differences between OW 2003.12 and OW 5000.0.1.0



Fixed Problems Defect Description

• 807965 Bounding box suboptimal calculation around a 2D seismic navigation line, errors reported for lines that bend back upon themselves with lfind_(…) and spsrch_(…) API.

• 813719 hrzrw_(…) API does not read correctly z value for 2D trimmed lines.

• 813821 hrzhdr_plus_(…) API does not immediately commit property changes.



Enhancements and New Functionality

The 5000.0.0 release of OpenWorks Development Toolkit contains the following revisions and enhancements:

Data Model Changes

New features incorporated in OpenWorks 5000.0.0 are listed in the following sections.

Well Location/Borehole Model

The gdiWellLocation_t is now parent to gdiWellEntire_t (and gdiWell_t and gdiWellShort_t). The gdiWellLocation_t becomes the surface location of the well. The gdiWellEntire_t becomes part of the borehole.

The location types have been divided into surface location types and bottom hole location types. The older types had a loc_type field that indicated surface or bottom ('T','B'). The new surface types have a well_location_id as key that ties it to gdiWellLocation_t. The new bottomhole types have a wellid as key that ties it to gdiWellEntire_t.

Location Type Is Now And Also

gdiCarterLoc_t gdiCarterSurfaceLocation_t gdiCarterBHLocation_t

gdiCongressLoc_t gdiCongressSurfaceLocation_t gdiCongressBHLocation_t

gdiDlsLoc_t gdiFpsSurfaceLocation_t gdiDlsBHLocation_t

gdiGeodeticLoc_t gdiGeodeticSurfaceLocation_t gdiFpsBHLocation_t

gdiGeodeticLoc_t gdiGeodeticSurfaceLocation_t gdiGeodeticBHLocation_t

gdiNarrativeLoc_t gdiNarrativeSurfaceLocation_t gdiNortheastBHLocation_t

gdiNeLoc_t gdiNortheastSurfaceLocation_t

gdiNorthSeaLoc_t gdiNorthSeaSurfaceLocation_t gdiNorthSeaBHLocation_t

gdiNtsLoc_t gdiNtsSurfaceLocation_t gdiNtsBHLocation_t

gdiOcsLoc_t gdiOcsSurfaceLocation_t gdiOcsBHLocation_t

gdiOhioLoc_t gdiOhioSurfaceLocation_t gdiOhioBHLocation_t

gdiTexLoc_t gdiTexasSurfaceLocation_t gdiTexasBHLocation_t

The gdiWellLoc_t location type has been removed.



These following location types have been added to the OpenWorks 5000.0.0 release:

gdiFractureJobFracWell_t

gdiFractureJobMonitorWell_t

gdiFractureJobStage_t

gdiFracTreatmentFormation_t

gdiFunctionAttribute_t

gdiFunctionSetAttribute_t

gdiGeoShapeAttribute_t

gdiGeoShapeSet_t

gdiGeoShapeSetAttribute_t

gdiGeoreferencedImageCatalog_t

gdiGgxSurfGuidingPts_t

gdiGgxWellMetadata_t

gdiGxFaultFieldPt_t

gdiGxStratFieldSection_t

gdiInterWellAttribute_t

gdiPrestackHorizonData_t

gdiPrestackHorizonHdr_t

gdiPrestackHrznDataAttribute_t

gdiRFunctionAttribute_t

gdiRFunctionProperty_t

gdiRFunctionSetAttribute_t



gdiRFunctionSetCategory_t

gdiRShapeAttribute_t

gdiRShapeSetAttribute_t

gdiShapeNodeProperty_t

gdiSyntheticHorizonData_t

gdiSyntheticHrznDataAttribute_t

gdiVerticalImageFile_t

gdiXyzFunction_t

gdiXyzFunctionProperty_t

gdiXyzFunctionSet_t

gdiDepthInterval_t

gdiGeoShape_t

gdiGeoShapeNode_t

gdiMicroseismicEvent_t

gdiSeismic3DList_t

gdiSeismic3DListMember_t

gdiSurfacePoint_t

gdiWellLocation_t

gdiWellSurfaceAltLocation_t

gdiWellLocationAlt_t

gdiWellBHAlternateLocation_t

gdiWellLocationUwiAlt_t



gdiWellLocationRemark_t

gdiWellLocationNameAlt_t

Reference Tables Renamed

Several reference tables have been moved from the "VC" name to the "R" style name.

VC Name R Style Name

gdiVcCompany_t gdiRCompany_t

gdiVcCountry_t gdiRCountry_t

gdiVcCountyName_t gdiRCountyName_t

gdiVcIntType_t gdiRInterestType_t

gdiVcStateName_t gdiRStateName_t

gdiVcWellClass_t gdiRWellClass_t

gdiVcWellDateType_t gdiRWellDateType_t

gdiVcWellStatus_t gdiRWellStatus_t



Fault Plane Trimesh Changes

gdiFaultPlaneTrimesh_t has been made less complex by removing the gdiFltSegAssignment_t connection between gdiFaultSegment_t and gdiFaultPlane_t. The relationship was many-to-many, but now is a one-to-many (one gdiFaultPlane_t to many gdiFaultSegment_t).

The gdiGeomTrimesh_t has been replaced by gdiFaultTrimesh_t. The gdiGeomPolyline_t is removed. The control pointsets are in a separate table accessed by gdiControlPoint_t. Each point is an entry in this table.

An effort has been made to retain the old model in the form of a view (gdiFaultPlaneTrimesh_t). This is not entirely backward compatible. The control pointsets are not included in the new class.

Horizon Datatypes

One of the key features in 5000.0.0 is tighter integration of Seismic Horizon data with OpenWorks. 2D Horizons are stored completely in Oracle. 3D Horizons are catalogued in OpenWorks, but the bulk data continues to be stored in external files in the same formats that were previously supported. The OpenWorks data model for horizons adds more key meta-data that was unavailable in previous SeisWorks data models. Horizons can be attached to an OpenWorks Surface. Horizons representing different attributes of the same structural horizon are grouped together by a shared Horizon Attribute Header.

The corresponding gdi class structures are new in this release:

gdiRHorizonAttribute_t

gdiRHorizonClass_t

gdiRHorizonName_t

gdiRInterpretationVersion_t

gdiRInterpretationStatus_t

gdiRSeisPickOnset_t

gdiHorizonData_t

gdiHorizonListHeader_t

gdiHorizonListMember_t



gdiHorizonAttributeHdr_t

gdiMistieFunctionHdr_t

gdiMistieFunctionMember_t

gdiSeismicDataSet_t

gdiShiftHdr_t

gdiShiftMember_t

Post-Stack Seismic Data Set Cataloging

Both pre-stack and post-stack seismic data sets can now be catalogued in OpenWorks. All post stack seismic data sets used by interpretation applications integrated with OpenWorks will be catalogued in the database. Metadata will be stored about the data sets and they will be tied to the processing history model that records how the data set was generated. The actual seismic trace data will continue to be stored external to OpenWorks in the same formats that have been used in the past. The primary table used to catalogue post-stack seismic is Seismic data set.

The following corresponding gdi class structures have been added:

gdiSeismicDataSet_t

gdiRInterpretationStatus_t

gdiRSeismicClass_t

gdiRSeismicVersion_t

gdiShiftHdr_t

gdiShiftMember_t

Pre-Stack Seismic Data Set Cataloging

Pre-stack seismic data sets can now be catalogued in the OpenWorks database. For pre-stack data sets, we support a selective publishing workflow. Not all pre-stack data used in the processing applications from Landmark software will be catalogued in OpenWorks database. The processing applications will support a publishing step where selected pre-stack data sets can be catalogued in OpenWorks and associated with the stacked data sets generated from them using the OpenWorks processing history model. This will allow the interpretation applications to readily view the pre-stack data associated with a particular



stacked data set. Pre-stack data is catalogued in the table SEISMIC_PRESTACK_DATASET.

The corresponding gdi class structures added in this release are:

gdiSeismicPreStackDataset_t

gdiRSeismicVersion_t

Seismic Storage in Interpretation Projects

The OpenWorks header tables that reference external files do not contain full path names. They contain a relative path that is resolved using a Seismic directory management system very similar to what was done in previous versions of SeisWorks. Seismic Files are still stored in directories defined by the config file dir.dat just as in the past. But there are no SeisWorks projects in R5000. All data is accessed from an OpenWorks project perspective and "OpenWorks Interpretation Projects" replace SeisWorks projects.

For a 3D survey, all external file data is stored in the directory defined by the Directory_name_3D attribute on binset_grid. For 2D data, each 2D line will be associated with a 2D storage area. The 2D storage area will define a directory that is shared by many 2D lines. All data for a particular line is stored in a single 2D storage area. A 2D storage area is in many ways analogous to a SeisWorks 2D master project in older versions of the software. The physical path for a given file is formed by searching each file system listed in dir.dat for files with a directory name as specified by the storage area and the specified file name.

The corresponding gdi class structure added is: gdiSeis2DStorageArea_t

Removed Legacy Production Model

The gdiWellPdenVolRecord_t and gdiWellPdenVolDisp_t have been removed. They have been replaced by the following:

gdiWellPdmMonthlyProd_t

gdiWellPdmDailyProd_t

gdiWellPdmMonthlyInjection_t

gdiWellPdmDailyInjection_t

gdiWellPdmProdCums_t

The new tables are specific to various period types (for example, "MONTHLY", "DAILY") that were represented by the "period_type" field in the legacy types.



The new tables are specific to production or injection types that were represented by the "prod_or_inj" field in the legacy types.

The new tables have fields for activity types of measurements, i.e., "ACTUAL", "ALLOCATED", "SIMULATED", that were represented by the "activity_type" field in the legacy types.

The new tables have fields for product types (for example, "OIL", "GAS", "CONDENSATE") that were represented by the field "product_type" in the legacy types.

An example of one of these mappings follows:

From To

gdiWellPdenVolRecord_t.wellid “33” gdiWellPdmDailyProd_t.wellid “33”

gdiWellPdenVolRecord_t.pden_type “WELL” gdiWellPdmDailyProd_t.pden_type “WELL”

gdiWellPdenVolRecord_t.zone_name “ZONE A” gdiWellPdmDailyProd_t.zone_name “ZONE A”

gdiWellPdenVolRecord_t.data_source “PI” gdiWellPdmDailyProd_t.data_source “PI”

gdiWellPdenVolRecord_t.vol_start_date “1992-12-11”

gdiWellPdmDailyProd_t.prod_dt “1992-12-11”

gdiWellPdenVolRecord_t.volume 452 gdiWellPdmDailyProd_t.vo_oil_prod 452

gdiWellPdenVolRecord_t.activity_type “ACTUAL”

gdiWellPdenVolRecord_t.prod_or_inj “PROD”

gdiWellPdenVolRecord_t.product_type “OIL”

gdiWellPdenVolRecord_t.period_type “DAILY”



Another example of mapping follows:

From To

gdiWellPdenVolRecord_t.wellid “33” gdiWellPdmMonthlyInjection_t.wellid “33”

gdiWellPdenVolRecord_t.pden_type “WELL” gdiWellPdmMonthlyInjection_t.pden_type “WELL”

gdiWellPdenVolRecord_t.zone_name “ZONE A” gdiWellPdmMonthlyInjection_t.zone_name “ZONE A”

gdiWellPdenVolRecord_t.data_source “PI” gdiWellPdmMonthlyInjection_t.data_source “PI”

gdiWellPdenVolRecord_t.vol_start_date “1992-12-11” gdiWellPdmMonthlyInjection_t.prod_dt “1992-12-11”

gdiWellPdenVolRecord_t.volume 452 gdiWellPdmMonthlyInjection_t.vo_gas_prod 452

gdiWellPdenVolRecord_t.activity_type “ACTUAL”

gdiWellPdenVolRecord_t.prod_or_inj “INJ”

gdiWellPdenVolRecord_t.product_type “GAS”

gdiWellPdenVolRecord_t.period_type “MONTHLY”

Removed PdmRms Model

Some portions of the Production Data Reserves Management Security data model were not consumed by the customer base hence those definitions have been removed.

The corresponding gdi class structures removed are:

gdiPdmRmsBkdelta_t

gdiPdmRmsBkmemo_t

gdiPdmRmsBkprod_t

gdiPdmRmsNonbkmemo_t

gdiPdmRmsPhase_t

gdiPdmRmsReserves_t



gdiRRmsChange_t

gdiRRmsRescat_t

Removed Resim Case Types

Some Reservoir Simulation portions of the data model were not consumed by the customer base hence those definitions have been removed.

The corresponding gdi class structures removed are as follows:

gdiResim_t

gdiResimCase_t

gdiResimTimeStep_t

In the class gdiScenario_t, resim_case_id field has been removed.

Removed Grid Property Types

Some Earth Model Grid portions of the data model were not consumed by the customer base hence those definitions have been removed.


gdiGridAnalysisParm_t

gdiGridPropBoundary_t

gdiGridPropAnalysis_t

gdiGridPropAnalysisInput_t

gdiGridPropAnalysisOutput_t

gdiGridPropCatalog_t

gdiGridPropExtStorage_t

Removed Pim Data Type

The gdiWellLoc_t location type from OW5000.0.0.3 has been removed from the OW5000.0.1.0.



Earth Model Changes

Some Earth Model portions of the data model were not consumed by the customer base hence those definitions have been removed.


gdiEm3DRegularGrid_t

gdiEmCoordSys_t

gdiEmGrid_t

gdiEmGridProp_t

gdiEmGridRegion_t

gdiEmProcess_t

gdiEmProcessInput_t

gdiEmProcessOutput_t

gdiEmRealizationProp_t

gdiEmRsrvPtyRealSet_t

gdiEmStudyObject_t

In addition, a new model replaces the following structures:

gdiEarthModelStudy_t

gdiFaultFaultContact_t

gdiFaultNetwork_t

gdiFaultNetworkFault_t

gdiFaultSurfaceContact_t

gdiStructuralModel_t



gdiStructureModelHorizon_t

gdiSurfaceSurfaceContact_t

gdiHorizonCleaningArea_t

gdiHorizonPatch_t

Seismic Geom Set Views

Views of Seismic Geom Set 2D Line and Seismic Geom Set 3D Survey have been created. The gdiSeis2DLine_t is a view built on gdiSeisGeomSet2DLine_t and gdiBinsetGrid2DShptTrace_t. The gdiSeis3DSurvey_t is a view built on gdiSeisGeomSet3DSurvey_t and gdiBinsetGrid3DGrid_t.

Interpretation Notes

This new model provides a means to add text and images to interpretations. The note can have a three-dimensional position. It can be attached to specific data objects. Display information can be part of the note. Hyperlinks can be included.

gdiINoteClassification_t

gdiINoteDataObject_t

gdiINoteDocument_t

gdiINoteDocumentLink_t

gdiINoteImage_t

gdiINoteImageSymbol_t

gdiINoteTextBlock_t

gdiInterpretationNote_t

gdiInterpretationSet_t

gdiInterpretationSetTemplate_t

gdiISetCategory_t



gdiISetDataObject_t

gdiISetDynamicQuery_t

gdiISetFolder_t

gdiISetProperty_t

gdiISetTemplateFolder_t

gdiISetTemplateObjType_t

gdiExternalDataObject_t

gdiMdmMimeType_t

gdiMdmMimeApplication_t

Synthetic Seismic 2D

A synthetic 2D seismic trace model is provided with the addition of the following gdi classes:

gdiSynthSeis2D_t

gdiPreferredSeismic2D_t

gdiRSynthetic2DType_t

Interpretation Projects

Interpretation Projects contain no tables or data, only views of data stored in the project database.

The Interpretation Projects view of the data can be in a different cartographic system.

These views follow one of several patterns.

• Local Views

• Data in local views is unique to a particular interpretation project (IP) but stored in a table in the project database (unshared data).



• The master project table has the _all name added to the logical table name and has extra PK value of interpretation_prj_id.

• The Project database view shows all data related to interpretation projects for a project database.

• Interpretation Projects are a logical subset of the Project database.

• Unconstrained Views

• Unconstrained views show all rows in the project database for each and every interpretation project. (unconditionally shared)

• Types:

• R tables and VC tables – Information used across projects

• Faults and Surfaces – Similar to reference table data in that it is used across projects

• Ellipsoid – A “mathematical” surface

• Parent Subset View

• Parent subset views subset data by a list of IDs identifying top level objects.

• For example, they show data for all wells in the selected list of wells.

• In general, all tables associated with WELL, 2D Line, or 3D Survey are parent subset views. (Decimated 2D Locations are an exception.)

• Dynamic AOI

• The views subset data dynamically by Area Of Interest (AOI).

• Carto conversions are performed automatically, as needed.

• Dynamic AOI with a Carto restriction

• These views subset data dynamically by Area of Interest (AOI) and CRS_ID (carto).



• Data is only visible if it is in the same carto and AOI. Examples include: Fault Segment, Grids, and Point Sets.

Datum Shifting in gdi

Gdi classes with datums now expose two datums: the storage datum and the working datum. Only the storage datum is saved to the database. It represents the datum that the stored values are relative to. The working datum is the datum that the values are relative to after they have been read. The working datum is generally the project datum for time data and sea level (0.0) for depth data.

The datum and replacement velocity in OpenWorks projects are used to establish the depth of time zero. Both fields have no bearing on horizon or seismic z values in the depth domain. If you have a survey in one Interpretation Project that has a replacement velocity of 2000 m/s and a datum of 100 meters and the same survey in a different Interpretive Project with a replacement velocity of 2500 m/s and a datum of 110 meters, both display a depth horizon as the same value. If 1000 meters is in the first project, it is 1000 meters in the second one.

Below is a summary of how the datum is referenced and how the information is filled out by the application.

On read:

Storage datum shows how data is stored.

Working datum shows how data is returned. This is the project datum.

Z values are relative to working datum.

On insert or update:

Set storage datum to datum of line or survey. (If instance has been read, this is filled out). If left blank, gdi gets the datum based on the seis_geom_set_id (if instance is associated with a line or survey). Fault control points are not associated with a line or survey.

Either set working datum to project datum or leave it blank, which causes gdi to use project datum.


Gdi will datum shift Z values from working datum to storage datum.

Read Example: Project Datum = 500 ms Replacement velocity = 5000 ft/sec Fault segment datum = 100 ms Fault segment z values = 200 ms, 400 ms



Two-way time doubles this shift To adjust the ft/sec with the ms units, use 1/1000 factor. (datum correction: 160 = ((500 - 100)/ (5000/1000)) * 2)

Values returned in gdi structure: Working Datum = 500 ms Storage Datum = 100 ms Fault Segment Z values = 200 + 160 = 360 ms, 400 + 160 = 560 ms

Write example: Assume that we are editing the segment we just read and the z values were changed from 360 ms and 560 ms to 370 ms and 570 ms.

Values set in gdi structure: Working Datum = 500 ms Storage Datum = 100 ms Fault Segment Z values = 370 ms, 570 ms

Datum correction is still 160 ms.

The z values subtracted 160 ms from their values before saving.

Fault Segment Values in db = 210 ms, 410 ms

Depth Data

The project datum is not used for depth data. Sea level is the datum, so zero (0.0) is used.

On read:

Storage datum shows how data is stored.

Working datum returns as 0 (Sea Level).

Z values are relative to working datum (0).

On insert or update:

Set storage datum to datum of line or survey (If instance has been read, this is filled out.) If left blank, gdi gets the datum based on the geom_set_id (if instance is associated with a line or survey). Fault control points are not associated with a line or survey.

Either set working datum to 0 or leave blank, which causes gdi to use 0. (This could be set to some other value and gdi would adjust accordingly, but this would be a non-typical use.)


Gdi would datum shift Z values from display datum sea level to storage datum.



Oracle Advance Queuing-based (AQ) Data Change Messaging

• We now use Oracle AQ to broadcast data change notification not Pointing Dispatcher (PD).

• PD is used for client-side communication.

• Messages are reliably delivered to any application using the project anywhere on the network.

• No special configuration is needed to receive messages.

• If you can access the database, you can get data change messages.

• Messages are forwarded to all Interpretation Projects sharing the data.

• You can change a well in one IP and all listeners interested for that well in any IP will be notified.

• New messages broadcast to define transaction boundaries.

• This allows receiver to update display at the end of a transaction.

• These changes greatly simplify workflows involving monitoring of real-time data updates across multiple machines on a network.

• No binding changes are required.

• gdiNotifyProject allows listening for changes on a specific project.

• Automatic Carto Conversioning on the fly for Geoscience Database Interface (GDI) Subsystem

Select District Operations

District is a filter to block or allow access to generic projects.

District offers specialized (controlled) access to the data.

Project data and flat file data are affected.

Concept of grouping data by Districts rather than Oracle System Identifiers (SIDs).



A SID can contain projects from multiple Districts.

Each OpenWorks project contains the appropriate District name

A District references only one SID.

The location of the $OWHOME/conf directory is now pointed to by: OW_CONF_DIR instead of OW_PMPATH.

Users that need a specialized conf area must set the OW_CONF_DIR variable to the appropriate directory. A valid district.dat file must be contained in any directory pointed to by the OW_CONF_DIR variable.

The format of the file is specified in the header of the district.dat file.

The location of the owdir.dat and dir.dat files (if any) are defined in the path within the district.dat file.

When the district is set, the SID is not selectable.

The SID defined for any district must be specified in the tnsnames.ora file.

The OW_SYS_DATA directory location is no longer defined in the owdir.dat file.

The location of OW_SYS_DATA is now defined in the lgcenv.cf file.



New Application Programming Interfaces (APIs)

GDI Subsystem

API Function

gdiAddSet Adds an array of instances to the project

gdiCloseFetch Uses with gdiFetch to cancel the cursor

gdiCreateVector Creates and initializes the vector

gdiDeleteSet Deletes all instances of a class from the project

gdiDeleteSetWithClause Deletes all instances of a class from a project constrained by a user clause

gdiDeleteSubset Deletes all instances of a class from a project constrained by a field

gdiDeleteSubsetWithClause Deletes instances of a class from a project constrained by parent key and a clause

gdiDistinctSet Use with gdiFetch to return data in batches

gdiDistinctSetWithClause Use with gdiFetch to return data in batches with user clause

gdiDistinctSubset Use with gdiFetch to return data in batches

gdiDistinctSubSetWithClause Use with gdiFetch to return data in batches constrained by parent key with clause

gdiGetAllSubClasses Retrieves a list of all gdi subclasses

gdiGetDepthDirection Gets depth as a negative below sea level (default) or positive below sea level



GDI Subsystem, continued

API Function

gdiInitiateVector Initializes vector

gdiIsFieldNotSet Checks if instance field is not set by the user

gdiIsFieldSet Checks if instance field is set by the user

gdiReadVectorList Reads the Vectors of an array of instances

gdiReadVectorSet Reads all the Vectors in the database of a class

gdiReleaseVectors Frees all vector memory associated with an array of gdi structures but not the array itself

gdiSetDepthDirection Sets depth as a negative below sea level (default) or positive below sea level

gdiSetOuomOnRead Sets the unit abbreviation for this field on reading from the project

gdiSetOuomOnWrite Fills the unit abbreviation for this field on write

gdiSetReportFormat Sets the report format for the gdiReportClassData function

gdiSetVectorAccess Sets the gdiVector access property

gdiUnsetPriortyList Unsets the user priority list preference



PD (Pointing Dispatcher) Subsystem

The new PD APIs are intended to replace older APIs in terms of functionality. The bulk of the changes with respect to these APIs are using integer variables and arrays instead of the longs in the older APIs. These changes are implemented to facilitate the 64-bit platforms. To maintain backward compatibility with the older style, the previous APIs are still available. The new style APIs are listed below:

pdDelete – Deletes all requests for the specified template

pdQuerySize – Determines the size of the PD template which has most recently arrived.

pdReadDouble – Retrieves the data templates containing only PDFLD and double-precision data

pdReadFloat – Retrieves the data templates containing only PDFLD and real (float) data

pdReadGen – Retrieves a generic data template

pdReadInit – Retrieves data templates containing only PDFLD and integer data

pdReadSimple – Retrieves a simple PD data template

pdRegisterCB – Registers a callback function receiving PD data with client callbacks

pdRegisterRead – Registers a callback function for receiving PD data

pdSendDouble – Sends data templates containing only PDFLD and double-precision data

pdSendFloat – Sends data templates containing only PDFLD and real (float) data

pdSendGen – Sends a generic data template

pdSendInt – Sends data templates containing only PDFLD and integer data

pdSendSimple – Sends a simple PD data template



Environmental Subsystem

ffaGetDirList – Gets a list of all ffa directories matching relative path

getFindDistrictList – Gets the list of all district CommonNames

getFindDistrictListForSid – Gets list of all appropriate district CommonNames

getFindDistrictPath – Gets the path for specified key (district CommonName)

getFindDistrictSid – Gets the Sid for specified key (district CommonName)

lgc_getdistrict – Returns the contents of the district.dat file

lgc_iszero – Tests value for being small enough to consider as zero

lgcValidFilename – Tests for generic (all platforms) valid characters within the filename

SSM (Session State Management Subsystem)

ssmGetDistrict – Returns the session’s current district

ssmGetSIDWithDisplay – Returns the session’s current working SID

ssmQueryDistrict – Returns the current district, if it is set

ssmSetDistrict – Sets the session’s current working district

ssmSetDistrictNotify – Adds a callback to be notified when the current session’s district is changed

ssmSetDistrictNotifyCD – Adds a callback to be notified when the current session’s district is changed (with client data argument)



Licensing Landmark’s Application Manager (LAM) is the license system used to control access to Landmark applications. LAM is based on Macrovision’s FLEXnet Publisher. A new LAM version is required for the 5000.0.0 release. You cannot have both Release 2003 and Release 5000.0.0 license files running on the same server.

IMPORTANT! If you have a 2003 version of LAM server, YOU MUST UNINSTALL IT before installing the LAM 5000.0.0 server.

Failure to uninstall all previous versions of LAM Server before installing LAM Server 5000.0.0 will result in a duplicate FLEXnet Publisher service that replicates itself until it crashes Windows. The procedures for uninstalling LAM server are detailed in the section “LAM Server Uninstall” in the LAM Guide—Linux, Solaris, and Windows (LAM.pdf), located in the Products\OpenWorks\Install\LAM folder.

FLEXnet Publisher licensing is available for networked application and standalone application use. FLEXnet Publisher standalone licensing may be used in conjunction with a network card or through a FLEXnet Publisher dongle (bitlock) where no PC network identification is possible.

The OpenWorks Software Development Kit is licensed on a per developer basis. An OpenWorks license feature must be available on the customer’s license server.



Installation

To use the software, you need to create a development kit directory under $OWHOME. Place the tar image in the $OWHOME/devkit directory and uncompress the development kit. Using GNU's gzip utility with the -d flag, kit file the development kit. Once this has been completed, GNU's tar utility can now be used with the –xvf flags on the tar image to extract the files. The gzip and gtar utilities can be found at this location:

ftp://labrea.stanford.edu/pub/gnu/ or ftp://gatekeeper.dec.com/pub/GNU/

Example Usage:

% gzip -d R5000Solarisdevkit.tar.

% gtar -xvf R5000Solarisdevkit.tar

The R5000Solaris.tar file contains both the OpenWorks and SeisWorks development kits. These kits are placed in the "devkit" and "swdevkit" directories respectively. After installation, it is suggested that you build and run the sample applications to ensure that your environment is working properly.

Makefiles are shipped with the OpenWorks development kit and are located in $OWHOME/devkit/src/examples directory. Edit the makeifle and set the OWHOME and the ORACLE_HOME and the makefile should build the sample programs.

Once the makefile has been modified, usage to build the hello application is as follows:

make –f Makefile.Solaris hello

Finally, ensure the following environmental variables are set:

OWHOME – The OpenWorks runtime location

LD_LIBRARY_PATH – Path list that contains all locations required for execution of development kit applications.

ORACLE_HOME – The Oracle installation location. (Client or Server)

Typically, OWHOME and ORACLE_HOME are set correctly for an OpenWorks user. LD_LIBRARY_PATH will need additional elements added to it to allow for building and running of devkit applications. Usually this will be the location of the OpenWorks devkit libraries from the OpenWorks devkit installation, and this should be added to the beginning of the LD_LIBRARY_PATH.


ftp://labrea.stanford.edu/pub/gnu/%20or%20ftp:/gatekeeper.dec.com/pub/GNU/


Third-Party Licenses

The OpenWorks® Software Development Kit includes software from third-party software vendors or sources. The third-party licenses for the OpenWorks® Development Kit are identical to the licenses for OpenWorks runtime installation.



Contacting Support

Landmark software operates Technical Assistance Centers (TACs) in Australia, the United Kingdom, and the United States. Additional support is also provided through local support offices around the world. Local support office information is listed below. If problems cannot be resolved at the district level, our escalation team is called to resolve your incidents quickly.

Support information is always available on the Landmark Support internet page located at:

http://css.lgc.com/InfoCenter/index?page=home

Support for the OpenWorks devkit can be obtained by contacting [email protected]. Landmark/Asia Pacific 11th Floor Menara Tan & Tan 207 Jalan Tun Razak 50400 Kuala Lumpur Malaysia Tel: 011-61-8-9481-4488 Fax: 011-61-8-9481-1580 Help Desk: 011-61-8-9481-4488 Email: [email protected]

Landmark/EMEA Hill Park South Springfield Drive Leatherhead, Surrey GU22 7NL England Tel: 011-44 (0) 1372 868-686 Fax: 011-44 (0) 1372 868-601 Help Desk: 011-44 (0) 1372-868-686 Email: [email protected]

Landmark/The Americas 2107 CityWest Blvd., Bldg 2 Houston, TX 77042-3051 USA P.O. Box 42806, Houston, TX 77242 U.S.A. Tel: 713-839-2200 Help Desk: 1-877-435-7542 Fax: 713-839-2168 Email: [email protected]


http://css.lgc.com/InfoCenter/index?page=home

mailto:[email protected]





Trademarks © 2009 Halliburton All Rights Reserved

This publication has been provided pursuant to an agreement containing restrictions on its use. The publication is also protected by Federal copyright law. No part of this publication may be copied or distributed, transmitted, transcribed, stored in a retrieval system, or translated into any human or computer language, in any form or by any means, electronic, magnetic, manual, or otherwise, or disclosed to third parties without the express written permission of:

Halliburton | Landmark Software & Services 2107 CityWest Blvd, Building 2, Houston, Texas 77042-3051, USA

P.O. Box 42806, Houston, Texas 77242, USA Phone: 713-839-2000 FAX: 713-839-2401

Web: www.halliburton.com/landmark

Trademarks 3D Drill View, 3D Drill View KM, 3D Surveillance, 3DFS, 3DView, Active Field Surveillance, Active Reservoir Surveillance, Adaptive Mesh Refining, ADC, Advanced Data Transfer, Analysis Model Layering, ARIES, ARIES DecisionSuite, Asset Data Mining, Asset Decision Solutions, Asset Development Center, Asset Development Centre, Asset Journal, Asset Performance, AssetConnect, AssetConnect Enterprise, AssetConnect Enterprise Express, AssetConnect Expert, AssetDirector, AssetJournal, AssetLink, AssetLink Advisor, AssetLink Director, AssetLink Observer, AssetObserver, AssetObserver Advisor, AssetOptimizer, AssetPlanner, AssetPredictor, AssetSolver, AssetSolver Online, AssetView, AssetView 2D, AssetView 3D, BLITZPAK, CasingLife, CasingSeat, CDS Connect, Channel Trim, COMPASS, Contract Generation, Corporate Data Archiver, Corporate Data Store, Data Analyzer, DataManager, DataStar, DBPlot, Decision Management System, DecisionSpace, DecisionSpace 3D Drill View KM, DecisionSpace AssetLink, DecisionSpace AssetPlanner, DecisionSpace AssetSolver, DecisionSpace Atomic Meshing, DecisionSpace Nexus, DecisionSpace Reservoir, DecisionSuite, Deeper Knowledge. Broader Understanding., Depth Team, Depth Team Explorer, Depth Team Express, Depth Team Extreme, Depth Team Interpreter, DepthTeam, DepthTeam Explorer, DepthTeam Express, DepthTeam Extreme, DepthTeam Interpreter, Design, Desktop Navigator, DESKTOP-PVT, DESKTOP-VIP, DEX, DIMS, Discovery, Discovery Asset, Discovery Framebuilder, Discovery PowerStation, DMS, Drillability Suite, Drilling Desktop, DrillModel, Drill-to-the-Earth-Model, Drillworks, Drillworks ConnectML, DSS, Dynamic Reservoir Management, Dynamic Surveillance System, EarthCube, EDM, EDM AutoSync, EDT, eLandmark, Engineer’s Data Model, Engineer’s Desktop, Engineer’s Link, ESP, Event Similarity Prediction, ezFault, ezModel, ezSurface, ezTracker, ezTracker2D, FastTrack, Field Scenario Planner, FieldPlan, For Production, FZAP!, GeoAtlas, GeoDataLoad, GeoGraphix, GeoGraphix Exploration System, GeoLink, Geometric Kernel, GeoProbe, GeoProbe GF DataServer, GeoSmith, GES, GES97, GESXplorer, GMAplus, GMI Imager, Grid3D, GRIDGENR, H. Clean, Handheld Field Operator, HHFO, High Science Simplified, Horizon Generation, i WellFile, I2 Enterprise, iDIMS, Infrastructure, Iso Core, IsoMap, iWellFile, KnowledgeSource, Landmark (as a service), Landmark (as software), Landmark Decision Center, Landmark Logo and Design, Landscape, Large Model, Lattix, LeaseMap, LogEdit, LogM, LogPrep, Magic Earth, Make Great Decisions, MathPack, MDS Connect, MicroTopology, MIMIC, MIMIC+, Model Builder, Nexus (as a service), Nexus (as software), Nexus View, Object MP, OpenBooks, OpenJournal, OpenSGM, OpenVision, OpenWells, OpenWire, OpenWire Client, OpenWire Direct, OpenWire Server, OpenWorks, OpenWorks Development Kit, OpenWorks Production, OpenWorks Well File, PAL, Parallel-VIP, Parametric Modeling, PetroBank, PetroBank Explorer, PetroBank Master Data Store, PetroStor, PetroWorks, PetroWorks Asset, PetroWorks Pro, PetroWorks ULTRA, PlotView, Point Gridding Plus, Pointing Dispatcher, PostStack, PostStack ESP, PostStack Family, Power Interpretation, PowerCalculator, PowerExplorer, PowerExplorer Connect, PowerGrid, PowerHub, PowerModel, PowerView, PrecisionTarget, Presgraf, Pressworks, PRIZM, Production, Production Asset Manager, PROFILE, Project Administrator, ProMAGIC, ProMAGIC Connect, ProMAGIC Server, ProMAX, ProMAX 2D, ProMax 3D, ProMAX 3DPSDM, ProMAX 4D, ProMAX Family, ProMAX MVA, ProMAX VSP, pSTAx, Query Builder, Quick, Quick+, QUICKDIF, Quickwell, Quickwell+, Quiklog, QUIKRAY, QUIKSHOT, QUIKVSP, RAVE, RAYMAP, RAYMAP+, Real Freedom, Real Time Asset Management Center, Real Time Decision Center, Real Time Operations Center, Real Time Production Surveillance, Real Time Surveillance, Real-time View, Reference Data Manager, Reservoir, Reservoir Framework Builder, RESev, ResMap, RTOC, SCAN, SeisCube, SeisMap, SeisModel, SeisSpace, SeisVision, SeisWell, SeisWorks, SeisWorks 2D, SeisWorks 3D, SeisWorks PowerCalculator, SeisWorks PowerJournal, SeisWorks PowerSection, SeisWorks PowerView, SeisXchange, Semblance Computation and Analysis, Sierra Family, SigmaView, SimConnect, SimConvert, SimDataStudio, SimResults, SimResults+, SimResults+3D, SIVA+, SLAM, SmartFlow, smartSECTION, Spatializer, SpecDecomp, StrataAmp, StrataMap, StrataModel, StrataSim, StratWorks, StratWorks 3D, StreamCalc, StressCheck, STRUCT, Structure Cube, Surf & Connect, SynTool, System Start for Servers, SystemStart, SystemStart for Clients, SystemStart for Servers, SystemStart for Storage, Tanks & Tubes, TDQ, Team Workspace, TERAS, T-Grid, The Engineer’s DeskTop, Total Drilling Performance, TOW/cs, TOW/cs Revenue Interface, TracPlanner, TracPlanner Xpress, Trend Form Gridding, Trimmed Grid, Turbo Synthetics, VESPA, VESPA+, VIP, VIP-COMP, VIP-CORE, VIPDataStudio, VIP-DUAL, VIP-ENCORE, VIP-EXECUTIVE, VIP-Local Grid Refinement, VIP-THERM, WavX, Web Editor, Well Cost, Well H. Clean, Well Seismic Fusion, Wellbase, Wellbore Planner, Wellbore Planner Connect, WELLCAT, WELLPLAN, WellSolver, WellXchange, WOW, Xsection, You’re in Control. Experience the difference, ZAP!, and Z-MAP Plus are trademarks, registered trademarks, or service marks of Halliburton.




All other trademarks, service marks and product or service names are the trademarks or names of their respective owners. Halliburton acknowledges that certain third party code has been bundled with, or embedded in, its software. The licensors of this third party code, and the terms and conditions of their respective licenses, may be found at the following location:

OpenWorksInstallDir\docs\third_party.pdf Windows OpenWorksInstallDir/docs/third_party.pdf Linux & Solaris

OpenWorks® 5000.0.1.5 Development Kit Release Notes

Documents

Transcript of OpenWorks® 5000.0.1.5 Development Kit Release Notes