Beruflich Dokumente
Kultur Dokumente
The Schlumberger GeoFrame Developers Kit (GFDK) lets developers build new programs that interoperate with the suite of GeoFrame applications. The kit is very extensive and powerful if used correctly.
Course Overview
The Introduction to GFDK course is designed to equip a developer with the tools necessary to use the GFDK effectively. The GFDK is an immense code base spanning the entire GeoFrame source code. Without a little guidance, it can be fairly easy to get lost. This course provides users with the important steps to successfully write their own GFDK programs by explaining various settings and supplying numerous example programs. With the knowledge acquired from this class, each student should be able to take the example programs, compile, link, and run them, as well as make their own GFDK programs. The Introduction to GFDK course specifically covers the following topics: GFDK Documentation Getting around in GeoFrame Setting up the Development Environment IESX DK IESX Data Access GeoViz On Connect GFDK Integration
Documentation
The GFDK has plenty of relevant documentation, which can be found on the GFDK Bookshelf. While this course uses many of the concepts from each of the documents, only three documents are of particular interest: IESX Data Access, GeoViz On Connect, and GFDK Integration. However, it is encouraged to look at the other documents on the GFDK Bookshelf for your general knowledge, as this course tries to serve as a one-stop shop, which bases itself from the need-to-know concepts in the GFDK Bookshelf documents. So, if you want more information than this class provides, please feel free to peruse the GFDK Bookshelf.
2. Select your project, enter your password, and click Connect. 3. Click Application Manager
4. Click Help, and the GeoFrame Help document pops up. 5. Click the GeoFrame System button. 6. Click GeoFrame Developers Kit Bookshelf.
Project Manager
The Project Manager enables the workstation user to login to GeoFrame. It also enables you to create, edit, delete, and archive (back up/restore) projects, and administer user access to projects and individual data types. A project is the highest level of data containment in the GeoFrame system. Each project is password-protected to assure data security. For a GeoFrame user, the Project Manager provides tools for: Selecting a Database Server Connecting to a Project Naming a Data Owner Accessing the Application Manager Creating a Project Adding or Removing Users Making Storage Settings Editing Project Information Using the Access Rights Manager Setting the Merge Options Backing up a Project Restoring a Project Recovering a Project Deleting a Project
For a GeoFrame Database Administrator (DBA), the Project Manager has additional functionality that includes: DBA Match Rule Editor Disks (DBA) Users (DBA) Tablespaces Devices
1. Select GeoFrame from the GeoFrame menu on Geonet. 2. Enter proman & in a GeoFrame xterm window. 3. Select the Project icon from the GeoFrame Application Manager window.
Process Manager
The Process Manager allows you to build and run chains of GeoFrame modules to analyze and interpret your oilfield data. When modules are linked together in chains, the output from one module is input to the next module in the chain. In Process Manager, you can: Create a new chain of modules Modify an existing chain Use one of the default chains provided, or rename and modify it to suit your needs Create and save a container called an activity for the chain; the activity becomes part of your database Set data focus Generate and execute a script file to automate commonly used procedures Set the data parameters for a module before you run it Control the execution of a module
Data Manager
The Data Management Catalog is the primary interface to the GeoFrame data managers, loaders and unloaders, and tools. The Products area is divided into these categories: Data Managers o General o Completed Intervals o Colormap o Cores o Drillstem Tests o Grid Libraries o Grids o Horizon Patches o Interpretation Data o Seismic Interpretation Manager o Layers
o Litho Zones o Log Curves o Markers o Surfaces o Wells and Boreholes o Zone Versions Loaders and Unloaders o ASCII Load o Data Load o Data Save o Grid Load/Export o Raster Loader o WitsML Load Tools o Access Rights Manager o Catalog Editor o DIPLOG to DLIS Converter o DLIS to LIS Converter o DLIS Utilities o LIS to DLIS Converter o Lithofacies Catalog Editor o Log Curve Preference System Editor o Marker Preference System Editor o Merge preference Setting Tool o Quality Control Tool o Script Builder o User Collections
Development Environment
To setup the user environment to compile, link, and run GFDK programs, you should perform the following steps: 1. setenv GF_PATH <GFDK_install_dir>/geoframe_44_<sun|lnx> where
<GFDK_install_dir> is the directory where the GFDK was installed, and <sun|lnx> is either sun or lnx, depending on what platform the GFDK is being installed on. 2. source $GF_PATH/bin/gfpath_define.csh 3. gfpath $GF_PATH You may now build programs in the baseline pointed to by $GF_PATH, or set up your own local working baseline.
A GeoFrame (GF) baseline is a directory structure that contains a complete set of source and object files necessary for GeoFrame system and application program development. To access a GF baseline for development, you create a search path between your user area, where your files reside, and the baseline to which you are developing. A search path is an ordered list of directories used to search for files needed to complete a task. When you add a GF baseline to a user area search path, users can access the baseline resources without making local copies of baseline files. The search path identifies the following for a particular directory: The sets that are defined locally The default set, if one exists (typically set to default_set) The next area (directory) in the search path
The gfpath command creates a path between your working directory and a GF baseline. Since the gfpath command allows you to specify the next area (directory) in a search path, when the next area is a GF baseline, the baseline and its search path are appended to your local search path. Consequently, the baselines sets are available to your working directory.
When a baseline is included in a directorys search path, you can modify only locally defined sets. You cannot write to the sets defined in the baseline.
The command gfpath -create and the UNIX command mkdir are not used for the same purpose. The gfpath create option not only creates a directory but also manipulates a search path. Likewise, do not confuse the gfpath command with the UNIX cd command. The cd command changes the UNIX current working directory but does not affect your search path.
serves. The client process in this model is an application that uses the input/output facilities provided by the server. The GeoFrame Process Manager and the programs it executes are X clients. In addition, a window manager is an optional third component in the X environment. GeoFrame client programs use the Motif Window Manager. The X server runs on your workstation. The necessary initialization of the environment includes setting various environment variables, setting X defaults and resources, starting the X server process, and starting the Motif Window Manager. The Process Manager and GeoFrame application program clients usually execute on your workstation, although you can also execute a client program on a remote host. Check with your site system administrator to find out how to start the X server process and how to start the Motif Window Manager in your environment. Once you have the X server and Motif Window Manager running, you can issue the following command from an xterm or X console window to start the Project Manager: > proman &
For more information on the IESX DK, including a full listing of APIs, error codes, etc., open the IESX Data Access document on the GFDK Bookshelf.
Project
A project is a collection of exploration data and any associated user (support) data that forms the basis of an interpretation or analysis. The data is usually collected by geographic area. Projects are completely independent of each another. Each project has a single owner, but the project may be shared by other users or accessed concurrently by other users. Access to some project data may be restricted to designated users, based on the data access rights assigned by the project owner. There are 3 types of GeoFrame projects: standalone, shared project, and sub-project. Stand-alone projects are projects that behave similar to projects in GF 3.x where you can share seismic data. Shared projects are generally master projects containing well data that you do not want to modify. Shared projects allow sharing of the well data only to subprojects where you can modify the well data. When you create a sub-project, you must select a shared project to inherit the well data.
Data relationships within a project are established by linking the various kinds of data to each other. Some project data is stored in Oracle, in GF bulk data, in IESX data storage locations (DSLs), and in the Charisma data store. A DSL corresponds to a directory in a filestructured volume. Directory references are relative to the volume rather than to the device on which the volume is mounted, thus providing support for the storage of data on dismountable devices such as optical disks. File references are of a non-system-specific form, and reference the data storage location name, rather than a directory name.
GeoFrame data contains storage repositories for project, coordinate and unit information as well as for wells and well related data. Starting with GeoFrame 4.0, the following IESX data types are stored in GeoFrame: IESX project name, password, DSL locations Seismic survey and line information Complete suite of interpretation data (horizons, faults, contacts, etc.) Projection, coordinates, units
Please refer to the SDM Data Item Report and ADI Reference Manual for a complete explanation on GeoFrame DataItems. The best way to view the SDM Data Item Report is with an internet browser such as Mozilla. Open a GeoFrame xterm and type the following: >mozilla $GF_PATH/wk_sdm/direport/index.html To access the ADI Reference Manual, click on Application Data Interface (ADI) Reference Manual in the GFDK Bookshelf.
In the IESX database, an entity is referred to as a data object. Many IESX objects are stored in GeoFrame. Examples of IESX data stored in GeoFrame are: 3D and 2D surveys 2D lines Surfaces (horizons, faults) Interpretation (attributes, fault cuts, contacts, fault boundaries) Grids Well data (wellsets, well, borehole, markers, logs, deviations surveys, checkshots)
The only objects not residing in the GeoFrame database are the actual seismic volumes and paths. The following diagram conceptually shows where data objects and DataItems are stored.
Exploration object
Exploration objects are the primary data objects of a seismic project. Examples of exploration objects are seismic lines (2D) and seismic volumes (3D). Exploration objects are stored in the GeoFrame database. Each exploration object may have several representations. Representations of a seismic line exploration object may include the seismic data itself, the interpretation of the seismic data, and the location of the seismic traces. An exploration object may have multiple instances of a particular kind of representation. For example, a single seismic line may have several instances of seismic data representations (original data, migrated data, stacked data). An exploration object does not actually store its representations; instead, it provides a method of organizing and relating them to each other in the database. An exploration object consists of the data collected (or derived) at a set of observation points, plus data that pertains to the object as a whole. For example, the observations collected at a single point for a seismic line include a seismic trace (or possibly multiple
traces), the interpretation at that trace, and the location of the trace. This common set of observation points defines the spatial relationships among the various representations of an exploration object. The basis of an exploration object is the entity that defines the organization of the observation points. For example, the basis for a seismic line exploration object is the seismic data itself, since it establishes the position of the observation points. It forms the basis for the interpretation and the trace locations. Observation points correspond to surface locations. The set of observation points for an exploration object may be singular (such as a well location), linear (such as a 2D seismic line), or form a 2D rectangular grid (such as a 3D seismic volume). The organization of observation points does not imply that the locations of the points form equivalent geometric figures. 2D seismic lines form a linear array of observations; the points need not be geometrically colinear.
Survey
A survey is an area or prospect defined by topographical, geological, or geophysical measurements. A project may contain many surveys as defined by the explorer.
A survey can be classified as a left-handed or right-handed survey. The easiest way to remember is to look down the first inline. If subsequent inlines are to the left, then the survey is left-handed. If subsequent inlines are to the right, then the survey is righthanded. Survey origin is defined to be the location of the minimum i and j (IESX internal coordinate system) and not the actual location where loading starts.
For a given survey, there may be several classes which can represent the different processing methods applied to the survey data. Examples of seismic classes are original, migrated, stacked, etc. For a given survey and a given class, a unique 3D seismic volume is defined. In 2D data, a 2D survey represents a grouping of 2D lines. 2D lines are equivalent in hierarchy to 3D surveys. For a given 2D survey, a given 2D line and a given class, a unique 2D seismic volume is defined.
Well data
[Borehole] data
Well data is stored in the GeoFrame database. The data can be retrieved directly using GFDK ADI calls or indirectly using IESX DK calls. IESX DK well data consists of well boreholes, deviation surveys, checkshots, markers and log curve data. IESX DK does not handle well data; it deals with borehole data. In GeoFrame, well data refers to the well head data such as well name, well UWI, status, and surface location, whereas borehole data refers to the rest of the well. Borehole data may include: name, UWI, API, bottom location, hole condition, index, elevation information, flow direction, deviation survey, checkshots, markers, and log data.
Markers
Markers are used to indicate the intersection of horizons or surfaces on a well trajectory. Markers have attributes such as name, type, color, source, seismic pick time or depth, index, and associated surface.
Log class
Log classes are entities used to differentiate the same type of log data that was acquired at different times using the same logging tool. It is a way of creating versions. Typical log classes are Sonic and Gamma. Log classes act as containers for log data. The data is stored in log representations in the GeoFrame database.
Log representation
Log curves are stored in log representations in the GeoFrame database. Each log representation stores a single log curve. A log representation belongs to both a log class and an exploration object. Each log classexploration object pair may have many log representations.
Checkshots
Checkshots are also known as DVT relationships (D = depth, V = velocity, T = time). The relationship provides the mapping between these three parameters. Each borehole
has a preferred checkshot; that is, all time/depth/velocity relationships are derived from the preferred table.
Deviation survey
A deviation survey contains borehole path points delineating the borehole paths orientation in the earth. Deviation points also represent the departure points of a borehole from vertical. Deviation points are duplets of delta-x versus delta-y, deviation degree versus azimuth, MD versus TVD, and so on.
Models are created and edited by the Seismic Interpretation Manager in the Application Managers Seismic Catalog. If no model is created, a default time and a default depth model are created. These default models contain all horizons and faults of the corresponding domain. When you open an application in IESX and interpret on a seismic line, those interpretations are added to the selected model in the active domain. If no model is selected, the Default model in the active domain is chosen. IESX DK applications and servers behave the same way.
Horizon
Horizons are DataItems in the GeoFrame database and act as containers for horizon attribute data. The GeoFrame database has two types of horizons: seismic and geological. Horizons can be viewed as surfaces with interpreted attributes such as Time, Amplitude, Snap, and so on. Calculated attributes can also be generated for a horizon. Only seismic horizons are returned from IESX DK interfaces. See the GeoFrame DI Report for more information on horizon surfaces.
Grid data
Grid data are stored in GeoFrame and consist of a binset which controls the orientation and extent. Grid data has a value (may be null) for every node in a regular spaced framework. Starting with GF4.0.4, binsets can be skewed. A new member (skew_angle) was added to the htp_grid_data_geom_s to denote the skew angle if the binset is skewed. Hence, a skew angle of 0 or 90 degrees means that the binset is not skewed. There are two types of grid supported by IESX DK: interpreted vs. computed grids. Interpreted grids are grid data generated by interpretation applications and are generally limited by the binset corresponding to a seismic survey extent. Thus, interpreted grids are tied to seismic surveys. All horizon attributes data are now stored in GeoFrame as interpreted grids and they are accessed via the htp_hor_xxx interfaces. Interpreted grids are covered in the next section. Computed grids are grids resulting from arithmetic operations or any other grid operations (i.e., isochron, etc) or simply any 2 dimension arrays of grid data. Computed grids can also be skewed. Computed grids are access via htp_grid_xxx functions. Interpreted grids always belong to an interpretation model while computed grids are model independent. Fault surfaces generated by tessellation or by gridding are stored in GeoFrame as computed grids and not as interpreted grids. The GeoFrame grid system has adopted orientation 2 (LHP - left hand plane) as the only recognized orientation, meaning all grid data are returned and written via IESX DK in the
orientation depicted below with a certain rotation angle skew_angle and with the z values in the line direction (index increasing fastest along the cdp axis).
Grid routines return a reversed flag to indicate if line coordinates are flipped from RHP (right hand plane) to LHP. The rotation angle indicates the direction of the CDP axis. The skew_angle tells you about its orthogonality. Non-orthogonality is defined when mistie is greater than 0.5 meters. Knowing these three values, the actual orientation of the grid can be determined. The following figure shows the possible orientations and angles:
Horizon attribute
Starting in GeoFrame 4.0, all 3D horizon attributes are stored in the GeoFrame database as interpreted grids, and they are associated with a seismic binset. 2D horizon attributes are stored in GeoFrame as line data. 2D and 3D horizon attribute data are accessed via htp_hor_xxx and htp hor_attr routines. Each attribute [grid] has a property code and unit which are stored in the GeoFrame property catalog and viewable via sqlplus. Property unit can be unitless.
Attributes not requiring attribute names and generated by MisTie applications are: Tie_Point_Total_Time_Correction Tie_Point_Phase_Shift Mis_Tie_Phase_Correction Mis_Tie_Static_Time_Correction Mis_Tie_Variable_Time_Correction Tie_Point_Time_Quality
Only Acoustic_Amplitude requires that the attribute name be the seismic class name. Acoustic_Amplitude generated from Seismic Interpretation has the attribute name built as class_name#amp while the acoustic amplitude generated by AutoPix has the attribute name as class_name#amp2. The complete attribute name has the following format: property code, space, ampersand as delimiter, space, attribute name as in property_code & attribute_name. The attribute names can be actual seismic class name, blank, or user-
defined names. Examples of attribute names where migrated is a seismic class name are listed below: Time Acoustic_Amplitude & migrated Acoustic_Amplitude & migrated_#amp2 Time & migrated_#time1
To get the complete list of the GeoFrame property code, run sqlplus on the baseline account or on your project and query for property_cat and property_catr respectively. To get property code from a catalog baseline, you will need Administrator privilege. The list of property codes obtained from your project and from the catalog baseline is identical. In order to get property codes from your project, your project must have interpretation or you must have caused the loading of the property codes into your project (for example, launch horizon dialog).
If you need help with the sqlplus queries, please refer to Chapter 3 in the IESX Data Access document on the GFDK Bookshelf.
Horizon patches
Multi-valued horizons were added in GFDK 4.0 to support interpretation in thrust faulted areas. When you are interpreting in normal faulted areas, a single value horizon is sufficient even though the horizon is broken or separated into multiple pieces or parts located at different depth or times. This is because these parts do not overlap. In areas characterized by thrust faulting (reverse faults), the concept of patch is introduced to supplement the single horizon name and to identify the individual pieces or parts that can overlap and are located in different fault blocks at different times or depths. The IESX Horizon Patch concept allows individual parts of the same thrust-faulted horizon to be stored under a single horizon name and also store those parts or patches as belonging to the horizon. A thrust fault causes a piece of a horizon to be displaced upward to a shallower depth (lesser time) relative to a piece of the horizon in an adjacent unthrusted fault block. The figure below illustrates the concept of patches for horizon h. The figure shows that thrust faults A and B cut horizon h into three individual pieces. Each horizon piece has the same horizon name but is also identified with a horizon patch name (horizon patches 1, 2 and 3). Arrows indicate the direction of movement along the fault planes. Horizon patch 1 is displaced upward relative to horizon patch 2, and horizon patch 2 is displaced upward relative to horizon patch 3. Each horizon patch can be selected and interpreted independently since they are stored separately in the GeoFrame database.
When you add a horizon to an interpretation model, a default horizon patch is created for the new horizon. Patch names are named sequentially as 001, 002 by default unless overridden by a user defined patch name. GeoFrame provides the capability to re-order patches in the Horizon Patches Data Manager in the Data Management Catalog.
Fault
Faults are DataItems in the GeoFrame database and act as containers for fault interpretation data. The fault record is stored in the GeoFrame database. Starting in IESX 4.0, fault surfaces are generated in IESX Seismic Interpretation applications and stored in the GeoFrame database as grids regardless of whether those surfaces were generated by tesselation or by gridding. See the GeoFrame DI Report for more information on fault surfaces.
Fault cut
A fault cut is a polyline defined by i, j, z in an exploration object in the GeoFrame database, where i = crossline j = inline z = time or depth A fault cut is a 2D projection of a single fault. Typically, a fault contains many fault cuts. A fault cut must be contained by a single exploration object.
Interpretation contact
An interpretation contact is a point defined by i, j, z in an exploration object in the GeoFrame database. Interpretation contacts are usually used to mark a point at which two objects touch. A contact may be one of several types: Horizon-Horizon Horizon-Fault Fault-Fault Pinchout Term (termination) Unused
Fault boundary
A fault boundary, like a fault cut, is a polyline defined by the real-world x, y, z coordinates and stored in the GeoFrame project. Because fault boundaries are defined by real-world coordinates, they may span exploration objects. A fault boundary is associated with a given horizon and fault. Contacts are not longer associated with fault boundaries.
depending on the arrangement of the observation points. A 2D seismic line has a 1D LCS, and a 3D seismic volume has a 2D LCS. The degree of a local coordinate system specifies whether the LCS has one or two dimensions. A local coordinate system does not define a vertical dimension because the units of vertical distance vary among different exploration objects or representations of the same object. A local coordinate system is normalized to the observation points of the objectthe distance between adjacent observation points is 1. A local coordinate system is nondiscrete, and points intermediate to the observation points may be specified. The interpretation of these non-integral coordinates depends on the type of access made to the database. Typically, it implies an interpolation of the data. A local coordinate system is considered to be infinite. The extent of the finite sub-region of this infinite space where data is actually defined is maintained by the database. Typically, specified coordinates lie within or near this extent of defined data. The origin of the LCS no longer corresponds to the first observation point for which data is loaded. It is defined to be the minimum LCS values. No assumption should be made that LCS coordinates are positive. The values of LCS can be positive, negative, and 0. However, the LCS increments are always positive. A linear mapping is defined between user-defined coordinates, such as line numbers and CDP numbers, and an LCS. No assumption should be made that minimum LCS correspond to minimum RCS (line and CDP numbers). In many instances, as LCS values are increasing, RCS values may be decreasing. The best way is to look at the transformation tables for the corresponding axis - inline and CDP transformation tables for 3D surveys and SP and CDP tables for 2D lines. When data for an observation point (such as a seismic trace) is loaded, this mapping is used to compute the local coordinate of the trace. In cases where the physical organization of data is the same as the local coordinate system, the local coordinate is used to determine where the data is stored in the physical structure. This allows data to be loaded into a representation of an exploration object in an arbitrary order.
Seismic class
Seismic classes in the IESX database are entities used to organize seismic data into various groups. A seismic class does not contain seismic data; the data is stored in the IESX database in seismic representations. Examples of seismic classes might be Original Data and Filtered Data.
Seismic representation
Seismic representations are the entities in the IESX database that contain the seismic data. A seismic representation belongs to both a seismic class and an exploration object. There can only be one seismic representation for each seismic class and exploration object pair. The seismic representation contains the line/volume header for the seismic data. This header is an expanded version of the SEG-Y line header.
Trace header
Each trace contains a header, which is a superset of the SEG-Y trace header, and sample data. Each trace contains the same number of samples. This number is set when the seismic representation is created. To represent nonrectangular surveys (2D exploration objects) with the rectangular seismic representation, each trace has an existence flag in its header. This flag can take on one of three possible values: DB_LIVE_TRACE indicates a normal trace DB_DEAD_TRACE indicates a trace in which all samples are zero DB_NULL_TRACE indicates a trace that does not exist in the seismic survey, although it is in the rectangular area of the seismic representation
DB_NULL_TRACE traces exist because of restrictions in the storage mechanism, but are marked to allow applications to treat them as needed.
A bat brick varies in size from 8K to 256K. Within a volume, the brick size is constant. BAT can reuse bricks that have been marked as deleted.
Path
A path is used to specify the region of an exploration object that is to be read or written by database routines. It is also used as a mechanism for communication between applications and other toolkit routines. For example, a path could be used to specify the portions of a seismic volume to be displayed by a seismic display routine. A path is specified by an exploration object, a spatial region, and a vertical range. The spatial region is composed of a set of figures. The figures may be areal (usually a rectangle), linear (polylines), or singular (points). The local coordinate system for the exploration object is used to specify the vertices of the figures. The spatial region defines a set of observation points. This set of points is made up of the points interior to areal figures, along linear figures, and near point figures. The vertical range for a path is a pair of values specified in units of time or depth. The range may be specified relative to a zero time or depth (from a datum), relative to a time or depth data (from the time of first sample TFS), or relative to a horizon. A sub-range of the path may be established by specifying a range within the set of observation points, a decimation within that range, and a sub-range of the vertical range. When data is read or written, the data is within the sub-range of this path. Initially, all paths are of the type DB_PATH_VIRTUAL. Only when a constructed path is saved does it become DB_PATH_PERMANENT. A path of type DB_PATH_VIRTUAL exists only within the context of the current execution, whereas a path of the type DB_PATH_PERMANENT is saved with a name for future reference. The paths of type DB_PATH_TEMP exist between two sessions, to restore the saved context. They do not exist (on the disk) once the session is restored. The concept of paths is extended in a 2D or 3D survey to encompass traverse through multiple surveys and exploration objects. These are commonly known as trips. The current implementation of trips limits the trip type to DB_TYPE_POLYLINE and DB_TYPE_LIST. All other conditions that apply to paths are valid with regard to the type of persistence, ranges, extents, and so on.
IESX DK Model
The IESX DK allows users to develop applications that appear as integrated components of IESX or as stand-alone applications loosely tied to the IESX database. The IESX DK applications are the clients in a clientserver model. Each client application has a server. The client and server use sockets and shared memory to communicate with each other.
The IESX DK server can be either IESX User Applications or one of the stand-alone servers thtp or batch_thtp. IESX User Applications provide different means for launching the integrated IESX DK application. Communication between the IESX server and IESX DK applications are done via sockets and shared memory. Small packets of information are communicated via socket, whereas large packets of information (for example, seismic traces) are communicated via the shared memory. Each IESX DK clientserver pair has one socket and one shared memory. Because of the shared memory, IESX DK servers and clients must be run in the same memory space (on the same CPU). The IESX DK server sets up the socket and the shared memory during initialization and sends this information to the client application. Setup of the socket and the shared memory in the client application is done in the htp_init_comm interface call. The IESX DK server is always listening in a predetermined socket for requests from the IESX DK client application. Termination of the socket and release of the shared memory is done in the htp_term_comm call. In general, when an IESX DK application wants information, it makes an htp_xxx API call, which sends the data type of the request via the socket. The server receives the requested data type and calls the appropriate htp routines to service the request. Additional information (name and data) may be sent by the IESX DK applications to the server in the shared memory, to complete the processing. For ease of use and maintenance, all these interprocessing communication calls are embedded in the htp_xxx API calls. htp data is generally grouped into a structure to ease additions to the members of the structure without modifying the IESX DK API sequence call from IESX applications. Whereas the IESX DB uses tokens for handling data objects, IESX DK uses the name of the data object. This makes programming and support easier, because the IESX DB tokens have no context outside IESX. A survey, input class, and output class must be defined before any seismic or interpretation attribute objects (such as horizon attributes, fault cuts, contacts, and the preferred fault boundary set) are accessed in either read or write mode. You can generate a dummy output class if your IESX DK applications are for read-only. Well data does not require the selection of survey or seismic classes for access. IESX DK maintains internally a list of the following defined objects: Seismic path points Horizon attribute in and out path points Fault path points Contact path points List of defined horizons, patches, and attribute names
After an IESX DK executable file is selected, the IESX DK server starts the IESX DK application as a new process. Both the IESX server process and the IESX DK application process go into an initialization phase wherein they establish a communication channel between themselves. The communication is based on TCP-BSD sockets and shared memory. The next stage is for the two participants to handshake and exchange any initial data. For example, the user procedure can obtain the list of horizon attributes and faults, the selected path, and so on. At this point the user procedure can reset any of these selections. The user procedure may also define new traversal paths along which the data is to be fetched. This option allows the user process to traverse the data randomly. The paths can be distinct for different accesses; for example, the seismic access path and the interpretation access path could be different from each other. 1. In the initial processing phase, the application does the following operations: a. Defines a domain. b. Defines an interpretation model. This step can override the previous step in selecting a domain. It is much more efficient to select a model and a domain at the same time than selecting a domain and an interpretation model separately. c. Defines the I/O access patterns for each data type to be accessed (that is, each seismic, interpretation, fault, and contact has its own input and output paths). This occurs only once, at the beginning. d. Obtains the access path(s) for the survey for each of the data types. e. Obtains the list of selected horizons, patches, and attributes. f. Creates horizons, patches, and attributes if needed. g. Defines a new set of horizons, patches, and attributes. h. Obtains the set of faults selected for fault data access. i. Defines a new set of faults (or creates it if it does not exist). j. Obtains the line header information pertaining to the current survey. 2. Operations c-j can be repeated after the initialization phase. These operations allow the user procedure(s) to select and define data access based on earlier accesses. 3. After applications are past the initial handshake data exchange, they drop into a processing loop where they can do the following operations, assuming that the IESX DK application has a selected survey, and input and output class, horizon attributes, faults, and contact data: Get the seismic trace data.
Put the seismic trace data. Get horizon-patch-attribute information (either in trace mode, path mode, or rectangular mode). Put horizon-patch-attribute information (either in trace mode, path mode, or rectangular mode). Get fault information. Put fault information. Get contact information. Put contact information.
Template
The IESX DK provides a template C source code file as well as a template makefile to give you a starting point for creating your own IESX DK programs. It is strongly recommended to use these templates when building your own IESX DK programs. Both files are found in the ies_htp set. Depending on your platform, you need to select the correct makefile. If you are using a Linux system, then you should use make_template_linux.dat. Otherwise, if you are on a UNIX system (Sun/Solaris), then you should use make_template.dat. There is only one template C source code file (dk_template.c). It can be built with either makefile depending on the platform you are on. The template program is comparable to a Hello world program. The IESX DK template program initializes communication to GeoFrame, prints out After init comm to the xterm, terminates the process, and ends communication with GeoFrame.
makefile to compile and link the source files to generate one executable. Basically, modify the OBJECTS variable and add the additional source files to the bottom of the makefile. To write your own IESX DK code, open the source file (my_dk.c) with a text editor and add your code directly above the all_done label. Depending on the types of data objects you are planning to use in your application, you may need to modify the boolean flags set in the common_in structure. At the end of this chapter, we provide a few IESX DK example programs.
Template
For GeoFrame compliant IESX DK programs there are three important template files: a source code file, a .lnk_def file, and a .sql file. Again, it is recommended to make copies of these files and adapt them as necessary. The template files are found in the ies_htp set. The gf_template.c file is the template source code file for GeoFrame compliant IESX DK programs. The gf_template.lnk_def file should be used regardless of platform to link GeoFrame compliant IESX DK programs. The gf_template.sql file is the template sql file. You will use the sql file to register your IESX DK program with GeoFrame.
In the .lnk_def file, you will need to change the gf_template.o to the .o files for your source files. In the source file, you will add your code in the RunApplication function after the comment /* add your codes here */. In the .sql file, you should change all instances of gf_template with the name of your executable. Please look at the end of this chapter to find IESX DK example programs.
Also, each record in the iesx_user_appl.dat file should start at the beginning of a new line.
This often occurs during the development of a newer IESX DK library. For example, your default system is running IESX DK version 3.7.0, but you are developing for IESX DK 4.0.4. In order to sync the IESX DK server and your DK applications, you must invoke thtp from the proper baseline (GFDK 4.0). In this case, this server does not see IESX DK applications linked with version 4.0.4. You have not recompiled and relinked your IESX DK applications with the latest IESX DK libraries. For example, you have launched IESX DK server from GFDK 4.0 while your DK applications were compiled and linked under GFDK 3.x.
The arguments arg1, arg2, ....... argN are passed from batch_thtp to main() in the DK application. However, argc in main() is the total number of arguments passed, including the user-defined argument. The first three arguments in argv are reserved for the DK server to pass information to the DK application. Argv[3] is always the number of the user-defined arguments.
arg3 - Number of user-defined arguments arg4 - First of the user-defined arguments arg5 - Second of the user-defined arguments, and so on.
So, for example, if we want to run the dk_template example program in the ema_cloud project, type the following at a GeoFrame xterm: >batch_thtp ema_cloud ema_cloud bin/dk_template
1. From the IESX Session Manager, select User Applications. The User Applications selection window opens as shown below.
When the User Applications window opens, a project has already been selected.
When the user selects the survey dialog box from File->Survey, the following dialog is displayed:
Selections inside the survey dialog box: Surveys List all available surveys in the project. Use the Select all or Select none buttons below this list to select all available surveys or to clear all selections. You can select one or more surveys. 2D lines List available 2D lines when a 2D survey is highlighted. Use the Select all or Select none buttons below this list to select all available 2D lines or to clear all selections.
Input class List classes when a survey (2D or 3D) is highlighted. For a single 3D survey or a single 2D line, all classes belonging to the input survey or line are listed. For multiple surveys or multiple line selections, only the seismic classes that are common to the selected surveys are listed. Output class Select an output class for the selected operation. The output class is labeled as attribute volume. Line, CDP, and Trace ranges: For multiple survey and/or multiple line selection, line range and CDP range text boxes are dimmed (inaccessible). If a single 3D survey is selected, both the line and CDP range may be specified. If a single 2D line is selected, only the trace range may be specified.
The Start and End of the Line range, CDP range, and Trace range are shown above each text box. To restore the full range, simply click on the input class for the type of data selected.
Decimation: Line decimation applies to 3D data only. (It is dimmed for 2D data.) The CDP/trace decimation entry decimates 3D data by the CDP increment, and 2D data by the trace increment.
Attribute volume: Class Name Display the name of the selected Output volume. You can change the name. Description Enter a description of the selected Output volume. Any combination of characters (including spaces) can be used, up to the end of the text box. Command Buttons The three command buttons at the bottom of the Survey dialog box are Path, OK, and Cancel:
Path Specify a previously defined traverse, rectangular, or polygonal path (area) for processing. This option is applicable only to 3D data. Selection of this button opens the Path selection dialog box in which to select or enter the path. Note: Selection of a polygonal path dims the Line, CDP, and Trace ranges in the Survey dialog box; that is, they are inactive. OK Save the survey data selections and close the dialog box. If the output class does not exist, a new output class is created. Cancel Disregard the survey data selections and close the dialog box. After selecting a survey, you can now change the domain, otherwise the default is Time. 2. In the User Applications dialog box, select User->Domain and choose either Depth or Time. 3. Click on one application.
Click on Start to launch the application or click on Select interpretation to select an interpretation. If you clicked on Select interpretation , the Select Interpretation dialog box opens as shown below.
Select horizon attributes, faults, all contacts, and/or fault boundaries to be sent to user-written executables. You can change their order by moving them up or down or you delete them from the list. You can also create a new horizon, horizon attribute, or fault by entering a new name in the corresponding text box and pressing the Create button. Click on OK to accept the selected interpretation and close the dialog box, or click Cancel to discard the changes.
Note: Alternatively, you can define horizons, horizon attributes, and/or faults programmatically.
If you clicked Start, then a progress box is displayed indicating the progress of the selected operation. 4. Click on File->Exit to close the User Applications dialog box or select another application and click Start.
If IESX DK applications do not appear in the list box, the possible causes are: You did not recompile your IESX DK applications against the new IESX DK library. You are invoking an old thtp that does not see the new IESX DK applications. In GeoFrame, you will need to invoke thtp from your GeoFrame work area. You may have forgotten to update the iesx_user_appl.dat file to register your IESX DK application. You may have forgotten to set the IESX_USER_APPL environment variable.
2. Click Select->Project and highlight a project in the list, or enter a project name in the Project text box. 3. Enter the project password. 4. Use Select->Survey to select the data focus (survey, input and output class).
If not selected, your application must set the data focus programmatically before any seismic, horizon attributes, faults, contacts, or fault boundaries can be retrieved.
5. Select the IESX DK application to run. The path to that executable is displayed in the Path text box. 6. Verify that the path is correct.
If not, modify the path in the iesx_user_appl.dat file. 7. If the domain is not set, it is default to Time. 8. Press Start. thtp sets up the socket, initializes the shared memory, and initializes all thtp structures according to your selection. The Close menu allows you to exit or quit. The exit option allows thtp to remember the project name for subsequent invocations of thtp.
To view your created 3d survey, open Basemap, hit Post->Surveys, select your survey, and hit Apply or OK. To view your trace data, open Seis3DV, hit Display->Seismic line, select the proper domain, survey, class, and inline/crossline, and hit OK. To check the trace values, zoom in on an area of interest and hit Shift+MB1.
>make f ies_htp/make_fault_example_linux.dat For Solaris, type the following at the GeoFrame xterm in your GeoFrame work area: >make f ies_htp/make_fault_example.dat Upon a successful build, you will see htp_fault_example in your bin directory. If there are syntax errors in compilation, fix them, and try to build again.
make_grid_example.dat Solaris makefile make_grid_example_linux.dat Linux makefile If you do not have these files, copy them from the GeoFrame baseline now ( >cp $GF_PATH/ies_htp/*grid_example* ies_htp/ ). For Linux, type the following at the GeoFrame xterm in your GeoFrame work area: >make f ies_htp/make_grid_example_linux.dat For Solaris, type the following at the GeoFrame xterm in your GeoFrame work area: >make f ies_htp/make_grid_example.dat Upon a successful build, you will see htp_grid_example in your bin directory. If there are syntax errors in compilation, fix them, and try to build again.
GeoViz On Connect
GeoViz On Connect is a suite of libraries and sample code which allows third party developers to write code which can access and modify data in GeoViz. GeoViz On Connect comes with the GeoFrame CD. It is installed and ready to use when you install the GeoFrame Developers kit. After installation, you will find the following files in the ies_geoviz_ogl directory below the baseline root directory: gvon.h C include file for On Connect plugins gvon.a C library of routines for connection to GeoViz plugin, plugin.c, plugin_xd.c, plugin.h Example plugin and corresponding source code
gfdk_geoviz.pdf The documentation file including a full listing of APIs plugins.txt Example plugin catalog file
This chapter covers the following topics: Data available to GeoViz On Connect Building your own GeoViz plugins Registering and launching GeoViz plugins GeoViz plugin example
For more information about GeoViz On Connect including a description of all of the available APIs, please read the GeoViz On Connect document on the GFDK Bookshelf.
The best way to build your own GeoViz plugins is to add the ies_geoviz_ogl set to your GeoFrame work area by using the gfpath command: >gfpath add set ies_geoviz_ogl Then, you will want to copy the correct version of the gvon.a library (depending on your platform and whether you are 32-bit or 64-bit), gvon.h, and your source code into the ies_geoviz_ogl set you added to your GeoFrame work area. In our case, we copy plugin.c, plugin_xd.c, and plugin.h.
Type the following to build your plugin: >cc -xtarget=ultra -xarch=v9 -xO4 -o plugin \ plugin.c plugin_xd.c gvon.a -lXm -lXt -lX11 -lgen -lm At this point, if your plugin built successfully, you should see plugin in your ies_geoviz_ogl set. Go ahead and move plugin into your bin directory.
Practical Example
Copy the plugins.txt catalog file from $GF_PATH/ies_geoviz_ogl to your ies_geoviz_ogl set. Modify the plugins.txt catalog file to include the directory name of the plugin executable. NOTE: Since you copied plugin into your bin directory, you can put in an entry of the form DemoPlugin plugin. The first word DemoPlugin is what will appear in the OnConnect Plugin Launch dialog list of plugins.
Now, in your GeoFrame xterm, type the following: >setenv GEOVIZ_PLUGINS ies_geoviz_ogl/plugins.txt >setenv GV_INTERP_CACHE 1
Launch GeoViz. Load a seismic volume. Select User->Plugins Choose DemoPlugin. Hit OK or Apply.
The plugin counts the number of samples per trace that falls within the interval and multiplies the number by the volumes z sample rate. For the Time domain, the attribute is written out as Time_Interval. For the Depth domain, the attribute is written out as Gross_Thickness. 3. Net Thickness / Gross Thickness (Ratio) The plugin calculates the ratio of 1 divided by 2 (from above). The attribute is written out as Ratio. 4. Average of Volume Values (within interval & range) The plugin averages up the volume values per trace that fall within the user-specified volume value range and within the interval. The attribute is written out as Avg_Amplitude. 5. Sum of Volume Values (within interval & range) The plugin sums all of the volume values per trace that fall within the user-specified volume value range and within the interval. The attribute is written out as Sum_Amplitude.
Building plugin_volattr
In order to build plugin_volattr, you need the following files in your ies_geoviz_ogl set: plugin_volattr.c Main source file plugin_volattr_xd.c XDesigner generated source file for the plugin's dialog plugin_volattr_xd.h XDesigner generated include file for the plugin's dialog plugin_volattr_res.h Resource header file for appearance of plugins dialog gvon.h The GFDK C include file for OnConnect plugins gvon.a C library of routines for connection to GeoViz Follow the steps in Building your own GeoViz plugins by replacing plugin with plugin_volattr to build the executable.
Running plugin_volattr
The following steps explain how to run plugin_volattr: Register plugin_volattr by adding an entry to plugins.txt. At the GeoFrame xterm, set the GEOVIZ_PLUGINS environment variable to point to plugins.txt. Also, set the GV_INTERP_CACHE environment variable to 1. Launch proman.
Launch GeoViz. Load at least two seismic horizons. Load a seismic volume. NOTE: Make sure to load a volume that has inlines and crosslines that the top and bottom horizons have too. Hit User->Plugins Choose the plugin_volattr entry. Hit OK or Apply.
Select a Top Horizon and Bottom Horizon. Choose the Domain. Specify a valid range of volume values. Choose the attribute that you want to the plugin to generate. Hit Run.
Once the progress has reached 100%, you can save the attribute to the GeoFrame database by performing the following: Hit Display->Horizons
Hit Save. Enable the Save Draped Attribute toggle. Enable the horizon name toggle and name it. The default is to write to the top horizon. Enable Overwrite. Hit OK.
NOTE: For every attribute that you want to save to the top horizon, you will need to execute the following sequence: 1. Setup the plugin parameters. 2. Hit Run. 3. Hit Save in the Display Horizons dialog. 4. Enable the Save Draped Attribute toggle, enable the horizons toggle and name it, and hit the Overwrite diamond. 5. Hit OK.
To view the attribute, you can use GeoViz or Basemap Plus: In GeoViz, get to the Modify Horizon/Fault dialog. From GF4.4 on, hit MB3 on the displayed horizon that we saved the attribute to, and select Property... Change the coloring to Ribbon, enable the Change Attribute toggle, and hit OK. A small dialog will pop up to prompt you to select an attribute. Choose the desired volume attribute and hit OK. For GeoViz versions before GF4.4, hit Tools->Modify, select the appropriate horizon, and hit Modify Then, change the attribute as in GF4.4 and on. In Basemap Plus, post the horizon and under Attribute choose the desired volume attribute before hitting OK or Apply.
GFDK Integration
As mentioned earlier, the GFDK is the application programmers interface (API) allowing developers to directly access the Standard Data Model (SDM). The GFDK consists of the Application Data Interface (ADI), other associated API subsystems, and seismic data extensions. The ADI is subdivided into the Application Query Interface (AQI), the object-oriented relational data access subsystem, and the Application Port Utilities (APU), the bulk data access subsystem. The goal of this section is not to go in depth on the ADI, APU, and AQI, but to make you aware that they exist and point you to the correct document to help you write your own
GFDK programs using the GFDK APIs. Also, we give a brief explanation about some of the other documents on the GFDK Bookshelf. We conclude this section with an example on how to manipulate DataItems. For more information on the GFDK, please read the GFDK Integration document on the GeoFrame Bookshelf.
Data Stores
The geoscience bulk and non-bulk data available to the ADI are stored in an Oracle relational database and associated bulk data files (called Array Data Server or ADS files).
The ADI locates data in, reads data from, and writes data to the data stores, performing all the alignment, gating (resampling), filtering, and conversion on this data.
data will then be given to the application. The ADI consists of two sets of functions: AQI functions and APU functions. By comparison to AQI functions, APU functions are used to read and write multi-valued attributes of DIs where more complex access is required. The value may be thought of as a special attribute of the DI. For example, for a multi-value DI such as Array, an application might want to specify a beginning extent, interval between consecutive values, count of how many values to access, along with any filtering or units conversion to perform on the values. The application uses the ADIs APU functions to accomplish such access. Other APU functions are provided that can be used by applications to lock and unlock DIs to access and to send notification when a DI has been changed.
Reference
For more details on ADI, AQI, and APU including a listing of APIs, please see the Application Data Interface (ADI) Reference Manual on the GFDK Bookshelf.
CSL Utility
The CSL Utility library is a collection of miscellaneous functions of general utility. The code resides in the GeoFrame baseline in the csutil set ($GF_PATH/csutil). Some of the functionality is essential for running GeoFrame and GFDK programs, especially the memory-management and exception-handling services. One important rule to remember is that data needs to be registered with GeoFrame in order for GeoFrame to use it. For example, if you are trying to create and name a well deviation survey using the aqi_CreateDI API, you need to call utl_Save on the name for GeoFrame to successfully write the DI. String_t dev_survey_name_for_GF = utl_Save(dev_survey_name); a_dev_survey = aqi_CreateDI(aBorehole, qWell_Deviation_Survey, qWell_ Deviation_Survey, NULL, &Status, qName, dev_survey_name_for_GF, NULL); utl_FreeBlock(dev_survey_name_for_GF);
Reference
Please refer to the CSUTIL Reference Manual on the GFDK Bookshelf for more details and a listing of APIs.
Reference
Please see the Application Runtime Control Reference Manual on the GFDK Bookshelf for more information including a listing of APIs.
ValueTypes
The ValueTypes (VT) library is an extensible library of routines for tagging the types of data that move through the GeoFrame system and for performing some operations on the information returned. The library includes a variety of services for the following items: Registered strings called atoms Symbolic functions Extended arrays called lists Data types called ValueTypes
Atoms
An atom is a registered string that improves performance when doing symbolic processing. The C typedef for an atom is vt_Atom_t. In C, it behaves like String_t. In particular, you can call standard C functions like printf, strcat, and strlen on an atom. In the VT library, an atom is a unique 32-bit ID that is not dynamic and that should not be modified or freed. A naming convention is used for atoms. A C identifier that pertains to a particular atom is prefixed with the letter q. For example, an atom that has a value of Name would have a C identifier of qName.
Reference
For a listing of APIs and more information on ValueTypes, please see the ValueTypes (VT) Reference Manual on the GFDK Bookshelf.
Units Library
The Units Library is a library of routines for representing, managing, and accessing measurements and their units in the GeoFrame system. This library provides programmers with the following capabilities: Create, access, and set unit systems Invoke an editor to inspect, change and save unit systems Determine if an entity is a valid unit or measurement, if units are convertible, or if units are synonyms Retrieve units, measurements, conversion factors, dimensions of units or measurements, unit synonyms, and storage or display units Convert data from one unit to another
Reference
Please see the Units Library Reference Manual on the GFDK Bookshelf for more details and a listing of APIs.
SDM
The goal of the Standard Data Model is to provide a foundation from which a coherent unified data model may be developed. The overall purpose of the data model is to provide an architecture for the database that allows many different applications to access the same data, while reducing the need to store the data in many different places. The data model must be as general as possible if it is to be flexible enough to encompass data from many different applications. A good data model is crucial when complex applications are tightly integrated and accessing the same data. Integrating applications by using an underlying data model reduces the amount of redundant data, and access to the data is more efficient. A relational database is used for the management of data. By allowing data to be stored in a central database instead of flat files, the job pf the petroleum professional becomes much easier, with less chance of losing data, having to keep track of multiple copies of the same data (for example, inputting a datum with every piece of data for a well), or having to rebuild valuable information for each application. The main goal of using the data model is to reduce the time it takes to move the data among the numerous applications required to acquire, process, interpret, and so on the data.
Reference
For more information, please see the SDM Data Modeling User Document on the GFDK Bookshelf. To access the SDM Data Item Report, perform the following at a GeoFrame xterm: >mozilla $GF_PATH/wk_sdm/direport/index.html
Description
The gfdk_well_example executable is an example of how you can use the GFDK to write your own code to interact with GeoFrame. The program exemplifies how one can manipulate DataItems related to fields, wells, and boreholes in a GeoFrame project. Specifically, gfdk_well_example queries the GeoFrame database to see if a field named Well_Manip_Field exists. If it does not, then the program creates it. Then, gfdk_well_example attempts to select all wells that are in the Well_Manip_Field field that have a name that starts with Well_Manip Well and create a new well by appending a number to the end of the name. So for example, if the Well_Manip_Field has one well named Well_Manip Well1, then the program will create a new well named Well_Manip Well2. Next, a changeable X and Y location for the well are specified in creating a well position. Afterwards, the program creates a borehole with the same name as the well, and fills in the Borehole UWI attribute. Finally, an activity and array are created.
Then, you will need to copy the gfdk_well_example.* files into the gf_school set that you added to your GeoFrame work area: >cp $GF_PATH/gf_school/gfdk_well_example.* gf_school/ Now, you should see at least three gfdk_well_example files in your gf_school directory: gfdk_well_example.c Main C source file gfdk_well_example.lnk_def Linker file gfdk_well_example.sql SQL script At this point, you should be able to build gfdk_well_example, by issuing the following command at the GeoFrame xterm: >gbuild -update bin/gfdk_well_example Upon a successful build, you should see gfdk_well_example in your bin directory. If you decide that you want to make changes to the program, such as changing the X and Y location of the well, you can edit the gfdk_well_example.c file and then rebuild the program using gbuild. To register gfdk_well_example, you will login to your project with sqlplus and run the provided gfdk_well_example.sql script. To login to your project, you need to set the TWO_TASK environment variable to point to the correct database server (which can be found in the first combo box on the Login tab in proman). You will also need to know your projects catalog (which also can be found on the Login tab in proman). So at the GeoFrame xterm, type the following: >setenv TWO_TASK database_server_name >sqlplus proj_name/proj_passwd After sqlplus has launched, you can register gfdk_well_example with your GeoFrame project: SQL>@gf_school/gfdk_well_example.sql catalog_name You may see some errors or warnings, which may be discouraging, but if youve run the script correctly, you can check that gfdk_well_example was registered properly by issuing the following commands: SQL>select name from module_cat; You should see GFDK_Well_Example Application listed.
SQL>select name from module_image; You should see GFDK_Well_Example listed. SQL>select code,module_code from module_command; You should see two entries: RunCommand and AbortCommand each associated with GFDK_Well_Example. To exit sqlplus, type the following: SQL>exit At this point you should be ready to run the gfdk_well_example program.
Click the Catalog Builder icon (the 3rd icon on the left-hand toolbar). In the Catalog Builder, hit the Show All button. Scroll through the Module Selection dialog, select the GFDK_Well_Example Application, and hit OK. Hit Export in the Catalog Builder and hit OK in the Confirm popup.
To run the GFDK_Well_Example Application, hit MB3 on the module, and select Run. As the program is running, some messages will print to the GeoFrame xterm to indicate to you what the program is doing. Upon successful completion of the run, the modules outer box will change colors to a light brown. A failure is indicated with red.
The General Data Manager is a very powerful tool that allows you to access data within your project, and we encourage you to read the help document (Help->On Module) to learn how to use it for its maximum potential. However, becoming a Data Manager expert is out of the scope of this course, so well leave it up to you. By default, the General Data Manager is in graph mode, which makes it easier to see the hierarchical dependency of DataItems and their attributes. To see the results of the gfdk_well_example program, do the following: Click on the Project object to set the Data Focus. Hit MB3, select Expand by Type, and choose Field Find the Well_Manip Field object and hit MB1 on it. Hit MB3 on the Well_Manip Field object and select Full Expand.
Depending on how many times you have run the gfdk_well_example program, you should see the following expansion:
In this example, we have run the gfdk_well_example program three times. To view more information on any of the data objects, simply double-click on it, or select it with MB1 and hit the i icon. Go ahead and double-click on the Well_Manip Well1 object and you can see its X and Y surface location (due to floating point fuzz, the numbers may be slightly different than specified in the code). When deleting, be extremely careful because there is no way for the operation to be undone. Also, keep in mind that when attempting to delete a parent object, all of its children are generally deleted as well, unless a child is dependent upon another parent object, in which case, you must delete the child object first. In our simple example, lets say that we do not want three wells, but we actually want only two wells in the Well_Manip Field. Lets delete the Well_Manip Well3 object: Select the Well_Manip Well3 object. Hit Edit->Delete. Hit OK.
GeoFrame has now deleted the Well_Manip Well3 object and its children, and the hierarchical graph updates.
Wrap up
Congratulations!!! You have made it through the Introduction to GFDK training course. In the class, you have learned about how to find the plethora of documentation included with GeoFrame and how to navigate in GeoFrame. Additionally, you have learned about the differences between the IESX DK, GeoViz On Connect, and the GFDK, and where to use which developers kit. Finally, weve provided you with several example programs so that you can learn how to write your own programs. We hope this guide was helpful to you. If you have further questions or would like to learn more than this course has to offer, we encourage you to delve into the documents found on the GFDK Bookshelf. For support, please contact your authorized Schlumberger field contact and have them submit a support ticket on your behalf.