Fink - Some Fundamentals of Depth Conversion - Jas_99

July/August/September 1999 UserNet 1

Some Fundamentals of Depth Conversion: Part 1

by Larry Fink

Introduction

Determining the correct spatial position of seismic reflections is one of the most important jobs of the seismic interpreter; after all, wells are drilled in depth, not in seismic time. This is article one of a three-part series giving a practical introduction to various methods of converting seismic time to depth, also know as “depth conversion.” The workflows in these articles act as a guide through the most scientifically valid methods for converting time interpretations to depth. The most “scientifically valid” method will depend on the quality and type of data available as well as the geologic complexity. The best depth conversion applies solid scientific principles and requires a minimum number of assumptions.

In the good old days before computers, geophysicists used simple zero order depth conversion methods. These techniques involved little more than simply re-labeling time contours as depth. But as more and more dry holes were drilled, the oil patch began to realize that depth conversion was not so trivial a task. As Albert Einstein stated so eloquently “For every complex problem, there is a simple solution... that is wrong!”

Most depth conversions use a collection of tools and workflows to achieve an optimal depth solution. There are currently seven main depth conversion workflows:

1. Volume Based Depth Conversion

2. Horizon Based Depth Conversion

3. Dix Velocity Inversion

4. Coherency Velocity Inversion

5. Dix-Coherency Hybrid Velocity Inversion

6. GeoStatistical Velocity Inversion

7. Migration Velocity Analysis with Prestack Depth Migration

This article provides an overview of depth conversion and gives a brief background of workflows 1 and 2. Article two will explain workflows 3 through 6. Article three will detail workflow 7 and summarize the depth conversion series. Graphically, the series will step through the “Depth Conversion Continuum” shown in Figure 1.

Technical Newsletter for Landmark Users


Figure 1. The Depth Conversion Continuum.

Why Depth Conversion?

Let’s begin by first understanding why a proper depth conversion is so important. First, a proper depth conversion is critical for mapping the top of geologic structure. This is illustrated by the simple example of Figure 2. Using a velocity function from the discovery well and the structural cross section from Figure 2, a step-out well was drilled. Much to the geologists’ surprise, the top of pay came in 1000 feet below prognosis.



Figure 2. Common Problem with Single Function Depth Conversions.

This happened because the depth conversion used an average velocity of 9000 ft/s down to 2.0 seconds, while in reality, due to the structure, this velocity is really 10000 feet per second. It follows that the geologists’ simplified velocity model led to the 1000-foot depth conversion error at 2.0 seconds.

Second, a proper depth conversion is critical to determining the correct lateral position of a structure. This type of depth conversion problem is as old as prehistory, when the first spear fisherman tried to catch a fish (Figure 3).



.Figure 3. Ray-bending causes the spear fisherman to miss the fish

For the fisherman, the bending of the light waves at the air/water interface causes the fish to appear offset from where it really is. Similarly, for the dry hole driller, the bending of the seismic energy at the fast/slow layer interface causes the image of the geologic structure to appear offset from the actual structure (Figure 4).



Figure 4. Ray-bending causes the driller to miss the target.

Many interpreters mistakenly believe that seismic “migration” corrects this problem. In fact, seismic time migration does not account for ray bending at layer interfaces! Only a depth migration can properly account for this phenomenon.

Volume-Based Depth Conversion

This begs the question, “What do I do if I do not have a depth migration?” The answer is actually quite simple: Do the interpretation on the time migrated data and then run a map migration on the interpreted map. Map migration properly accounts for seismic ray bending at geologic layer boundaries. The specifics of map migration will be covered in article two of the series. Once an interpreter believes there is a need for more than a re-labeling depth conversion, the next question to ask is, “How accurate must it be?” The answer depends on whether the prospect is a large structure or a subtle stratigraphic trap. Accurate depth conversion techniques move data laterally as well as vertically. If the prospect has limited areal extent, such as a meandering channel or pinnacle reef, it requires a more accurate depth conversion solution. Having clear objectives for the depth conversion project better ensures that the techniques employed meet the goals. This saves time and effort, because only the simplest and fastest technologies need be applied to meet the constraints.

Rather than the single velocity function that the poor geologist drilled 1000 feet off structure, using a “volume of velocities” to convert the interpretation from time to depth would be much more accurate. The “volume-based” workflow provides a quick and easy approach to depth conversion.



1. You use well data and seismic-derived velocity data to create time-to-depth curves (TD curves).

2. You then use the TD volume to depth convert seismic data, interpreted time horizons, and faults, using a vertical stretch technique.

3. You can improve accuracy of the depth model by integrating sparse well data with continuous velocity information extracted from seismic data.

4. Synthetic seismograms are also often used to help tie the wells to the seismic interpretation before the volume of velocities is generated.

This workflow is applicable in areas of simple geology that can be found in many basins around the world. The structural events need to be fairly flat and the interval velocities for these layers should vary gradually both laterally and in depth. This vertical stretch technique may be considered a “zero order” depth conversion.

Horizon-Based Depth Conversion

As an alternative approach or addition to the volume workflow, you may find it useful to construct a “horizon-based” velocity model. The horizon-based workflow provides structural control for velocity interpolation and allows validation of the depth model using ray tracing. In addition to enhanced model visualization, the horizon-based workflow provides model property editing tools. The creation of a depth/velocity model also helps to visualize the subsurface and provide a canvas for interpretation (Figure 5).



Figure 5. Three-layer horizon-based model.

Often a geophysical model is created to support different types of “what if” investigations, as well as to assess the validity of acquisition and processing parameters. This conversion technique can be considered a “first order” depth conversion. One method of generating velocities for this horizon-based method involves what are called “pseudo velocities.” Pseudo velocities are calculated at the well positions by dividing a depth interval by a time interval (Figure 6).



Figure 6. Pseudo-velocity calculation.

Once you have calculated the velocities, you can quality check the model by displaying vertical slices throughout its entirety (Figure 7).



Figure 7. Vertical slice through the 3-layer depth conversion model.

The volume and horizon techniques provide quick velocity modeling and depth conversion solutions. These workflows help interpreters meet short-term deadlines and also provide reasonable accuracy relative to the expected degree of geologic/velocity complexity. However, the accuracy of the solution is limited by the method of determining the interval velocity field and by the depth conversion technique used. Therefore, it is important to validate the accuracy of the model and to subjectively assign it a degree of risk. If the model does not “validate,” a more rigorous depth conversion technique must be used.

A simple validation is to compare the depths from the model with the depths from the well tops. Another validation may be to compare the synthetic time data to the original seismic data. A final validation involves ray tracing using zero-offset image rays. These validation methods will be described in part two of the article.



Reservoir Framework Builder 1.0 Released

by Robert Chelak

Landmark Graphics Corporation is pleased to announce its first UNIX®-NT interoperable software solution, Reservoir Framework Builder 1.0, or RFB. RFB is certified on the NT system using a Pentium II class CPU and 24-bit OpenGL® graphics. RFB is designed to aid in building structurally and stratigraphically complex framework models used by Stratamodel. You can keep all your input data on UNIX data servers but have complete accessibility by RFB on an NT system.

RFB's primary goal is to allow you to produce these complex framework models in a timely manner with a state-of-the-art, easy-to-use interface. RFB manages all the files needed to construct these models so that you can concentrate on generating a more accurate reservoir model.

For release 1.0, RFB accepts input from the Stratamodel data structures for grids, wells, and pointsets. RFB can also use gOcad®’s triangulated surfaces, or tsurfs, as input.

The underlying topology and geometry engines for RFB are gOcad-based. Stratamodel gridded surfaces are initially converted to gOcad tsurfs for use by the engine. At the end of the workflow these surfaces are converted back into Stratamodel grids for final model construction in the Stratamodel product.



In addition to providing an easy and fast methodology for building more complex faulted models with Stratamodel, RFB also increases your productivity by providing the following:

• Initial grids that have different dimensions are automatically exported with uniform dimensions.

• All inputs are 3D objects that can be easy manipulated by the interface.

• All surface files generated or edited in the system are managed by the system architecture.

• The easy-to-use, detachable icon interface is arranged for step-by-step workflows.

• Micro models from field-wide data can be created very quickly and easily as different scenarios.

• A comprehensive set of editing tools enables you to manipulate horizons and faults in 3D with algorithms to smooth and reshape surfaces.



• Algorithms are automated where necessary.

• Fault models are based on age or dominance order.

• Model persistence at every stage of the model building process enables you to return to a working point exactly where you left off.

• RFB automatically creates the files and grids Stratamodel needs from the fault model and generated surfaces.



• UNIX-NT interoperability allows the direct connection of RFB files on NT and Stratamodel projects on UNIX.

• RFB offers a quick preview of the framework model before it is built in Stratamodel.



• New functionality improvements to StrataMap, such as a direct read/write of the RFB or Stratamodel framework control file, complement the RFB workflow.

• A full set of online help and documentation is provided in a web-based form.



Better. Easier. What’s New in PetroWorks 1998.2

by Dan Krygowski

Introduction

With an infusion of funding from Halliburton Energy Services (HES) through the IPSI (Intracorporate Petrophysical Software Initiative) project, PetroWorks development is continuing at an elevated pace. The first fruits of that IPSI funding will appear to clients with the release of the PetroWorks 1998.2 family of products, scheduled for late in the third quarter of 1999.

This release represents the most significant increase in functionality since the inception of PetroWorks, and is aimed not only at the asset team, but also at full-time petrophysical professionals.

IPSI

IPSI is an HES-funded effort begun in April of 1998 and scheduled to end in December of 1999. Its purpose is to enhance Landmark’s infrastructure (through additions to OpenWorks, PetroWorks, and StratWorks) so that HES can have a robust, industry-recognized base on which to build its logging (wireline and MWD) interpretation technology.

The IPSI project covers four broad development areas:

• Enhancement of the data model and addition of multivalued data such as borehole images, sonic waveforms, and MRIL echo trains

• Improved data input and output, including DLIS format data

• Enhancement of plotting capabilities, to more accurately and flexibly display wellbore data

• Enhancement of PetroWorks applications, notably the ModelBuilder rapid application development environment

One of the strengths of the IPSI project is that the internal needs of Halliburton exactly parallel the needs of Landmark’s petrophysical clients. The results of the IPSI project will directly benefit all Landmark clients by providing needed functionality in a shorter time.

Expansion of the PetroWorks Product Family

One of the results of the IPSI activity is the expansion of the PetroWorks product family from two products (LogEdit and PetroWorks) to three products (LogEdit, PetroWorks Asset, and PetroWorks Pro). The development team, with the marketing and sales channel, felt that the division of PetroWorks into two products at this time was an appropriate way to enhance the “Easier” part of the PetroWorks “Better. Easier.” development mantra.

In this release, the differences between PetroWorks Asset and PetroWorks Pro are small in number, but the differences between the products will grow in PetroWorks 1998.5 and releases beyond. This division also provides the means to target different markets with appropriately-functioned products which better meet the individual segment needs. The table below shows the functionality of the individual products and the location of the functionality on the menubar headings.



The Landmark sales staff has information about LogEdit, PetroWorks Asset, and PetroWorks Pro pricing and upgrade opportunities.

New and Enhanced Functionality

Main Menu Bar ReorganizationThe main menu bars for all the PetroWorks products have been rearranged to better reflect a general petrophysical workflow. The specifics are shown in the table below.

Table 1:

Main Menu Headin g

Functionalit y LogEdit 98.2 PetroWorks Asset 98.2

PetroWorks Pro 98.2

OpenWorks Data Import

Data Input OpenWorks ASCII Curve LoaderOpenWorks Binary Curve Loader

OpenWorks ASCII Curve LoaderOpenWorks Binary Curve Loader

OpenWorks ASCII Curve LoaderOpenWorks Binary Curve Loader

OpenWorks Data Export

Data Output OpenWorks Well Data Export

OpenWorks Well Data Export

OpenWorks Well Data Export

LogEdit, PW Asset, PW Pro: Data Prep

Editing and Preparation

LogEdit LogEditEnvironmentals

LogEditEnvironmentals

PW Asset, PW Pro: PreInterp

Analysis: deterministic

PreInterpretation:Log Functions, Reconnaissance

PreInterpretation:Log Functions, Reconnaissance, Shale Volume



LogEdit, PW Asset, PW Pro: Interpret

Analysis: deterministic

Interpret: QuickInterp, MultiMineralUser Models

Interpret: QuickInterp, Complex Lithology, Dual Water, Shaly Sand, OnePhiSw, MultiMineralCased Hole:Pulsed Neutron User Models

Analysis: user programming

MathPack MathPack ModelBuilder MathPack

Visualization Single Well Viewer

MapViewCrossplot/HistogramsSingle Well Viewer

MapViewCrossplot/HistogramsSingle Well Viewer

Results/Displays

Summation, Sensitivity

Summation, Sensitivity

LogEdit, PW Asset, PW Pro: Utilities

Data Utilities Curve Alias List Manager, Curve Utility, Display,Header/Trailer Editor,LithCurve, Log Import/Export,Strat Column Editor, Strat Unit Editor, Tabular List,Well Template Editor, Well Template Transfer

Curve Alias List Manager, Curve Utility, Display,Header/Trailer Editor,LithCurve, Log Export UtilityOW-XTF Conversion,Strat Column Editor, Strat Unit Editor, Tabular List,Well Template Editor, Well Template Transfer,Wellbore Parameter Editor

Curve Alias List Manager, Curve Utility, Display,Header/Trailer Editor,LithCurve, Log Export UtilityOW-XTF Conversion,Strat Column Editor, Strat Unit Editor, Tabular List,Well Template Editor, Well Template Transfer,Wellbore Parameter Editor

Table 1:

Main Menu Heading Functionality LogEdit 98.2 PetroWorks

Asset 98.2PetroWorks Pro 98.2



ModelBuilderModelBuilder is a rapid application-development environment that is specific to PetroWorks Pro. It allows you to add your own algorithmic code in a straightforward manner using standard FORTRAN or C, and creates a true PetroWorks application from that code, complete with user interface, connections to the Wellbore Parameter Editor, and connections to the OpenWorks database. For petrophysical applications that do not need an interactive graphical data interface, ModelBuilder offers a development environment in addition to the OpenWorks development kit. It is suitable for client developers and third-party vendors alike. ModelBuilder was described in detail in the first quarter 1999 issue of UserNet.

Although ModelBuilder itself is only available in PetroWorks Pro, the interpretive applications built with ModelBuilder can also be run from PetroWorks Asset.

Interpretive ModelsAs a test of its development, ModelBuilder was used to rapidly develop a number of interpretive applications, or models. The existing Basic Interpretation was redeveloped in ModelBuilder as two applications, Preliminary Reconnaissance (formerly Prep) and QuickInterp (formerly the rest of Basic Interpretation). These two applications and MultiMineral, along with the new Log Functions, provide the interpretive capabilities for PetroWorks Asset. The intent here is to provide Asset teams with the means for rapid and straightforward interpretation capabilities that guide the users through first-order evaluations.

Six more complicated interpretive applications designed for shaly sands, complex (including carbonate) lithologies, and pulsed neutron analysis are included in PetroWorks Pro. These models are intended for more detailed evaluations, and are built from well-regarded algorithms.

User ModelsUser Models designates a place for ModelBuilder-based interpretive applications that are written by clients. Clients wishing to share their work with in-house colleagues (or even the wider PetroWorks community) can “publish” their applications, which causes the applications to appear in this location. ModelBuilder-based applications are essentially algorithmic black boxes that allow other users access to data and parameters of the model writer’s choosing, but that block them from accessing (and potentially changing) the original source code.

Wellbore Parameter EditorThe Wellbore Parameter Editor (WPE) is a spreadsheet-style interface for parameter entry. It is the visible connection to the ppp subsystem, which manages the parameters and their storage in the OpenWorks database.



WPE has parameter inheritance mechanisms that allow for specification of parameters on several processing levels. WPE uses visual cues to make you aware of the state of each parameter, and it responds to changes in the OpenWorks Units of Measurement system so that wellbore data with diverse measurement units can be correctly processed in a multiwell multizone environment. WPE was described in the second quarter 1999 issue of UserNet.

Crossplot EnhancementsWith this release it is possible to use the Landmark PD (Pointing Dispatcher) mechanism to send information from Crossplot to a cell or a group of cells in the Wellbore Parameter Editor. The Send Crossplot Information window allows you to send the minimum, maximum, or average of the x-, y-, or z-axis values of a group of active points. The values of a specific point or of the cursor location can also be sent. This feature allows you to graphically pick parameters and to immediately send those parameter values to WPE for display and storage.



Access to Curve Instances: Curve Alias List ManagerWith this release, curves can be accessed in one of three ways:

• by curve name (this was the only previous method)

• by curve detail (curve name, run number, and version number)

• by curve alias (ordered list referenced by a near-English, POSC-inspired alias name).

Curve details are available only when a single well is selected. Curve aliases are intended to be used in multiwell processing, especially when a diverse curve namespace is desired (for example, to help denote the source of a curve). The Curve Alias List Manager (CALM) is the means by which you can modify default alias list names: adding, removing, or reordering the names on the list.



The Curve Alias List Manager and the access to curve data were detailed in the second quarter 1999 issue of UserNet.

Improvements to Single Well Viewer and Well Template EditorThe improvements to SWV and WTE include the use of curve aliases in creating templates and displaying data, and the ability to display the template and its data at the scale selected by the user. The new StratWorks Header/Trailer Editor has also been included in PetroWorks as part of the StratUtils group of utilities that is shared between the two products.

SummationSummation has been almost completely rewritten, with a great deal of input and help from Conoco and Statoil. This version calculates reservoir sums from exact pick depths, rather than snapping the calculation to the nearest data point. It also has provisions for choosing how the data point represents the part of the formation that it measures, and for determining how to count pay in thinly bedded intervals.



Help DocumentsThe changes made between PetroWorks 1998.1 (Release 98Plus) and PetroWorks 1998.2 have generated over 500 pages of new help material. Because of the anticipated release of PetroWorks 1998.5 in the first quarter of 2000 and the expected volume of enhancements in that release, it was decided not to revise the existing PetroWorks documentation, but to supplement it with material on the additions and enhancements. Choosing Online Manual from Help will bring up a “gateway” page. This page is arranged in the order of the items on the PetroWorks family menus, and designates “new” and “unchanged” topics for each item as appropriate. It’s a new and very useful way to locate information regarding PetroWorks functionality.



And Finally

There are numerous changes to the PetroWorks family of products, including the creation of “Asset” and “Pro” versions from the existing product. The primary goal in PetroWorks development has been, and will continue to be, succinctly expressed as “Better. Easier.”

The number of changes in the 1998.2 releases are fairly small in number, but represent significant increases in actual functionality. These changes, and current development aimed at the next product release, are intended to significantly improve Landmark’s petrophysical capabilities for casual and full-time users alike. We also believe that these changes combined with those planned for the next release, and the availability of the OpenWorks development kit and ModelBuilder, can provide the vehicle of choice for continued widespread development of interpretive techniques for wellbore data.



What's New in StratWorks 1998.1.2

by Jerry Greengold

StratWorks 1998.1.2 is now available on Landmark’s ftp site (ftp.lgc.com) in /patches/StratWorks. Changes and additions for the release are overviewed in this article.

Changes Affecting Multiple Applications

1. Curve Aliasing : Two significant changes have occurred:

• Prioritized curve aliasing allows you to define the order in which missing curves are replaced for displays and calculations.

• Curve Alias List Manager, a new OpenWorks utility accessed from the Curve Dictionary, allows you to create, edit, save, and restore curve alias lists. The curve lists are listed and selectable in the curve track of the Well Template Editor, and the results are reflected in templates containing curve tracks in Correlation, Cross Section, Lithology, Single Well Viewer, Wellbore Manager, and MapView (Log Signature Maps). In addition, within MapView ➛ Isochore , mapping will honor these lists when using curve thresholding. You can select an Alias List such as Gamma_Ray and then, within that list, list all the specific gamma ray curves (GR, SGR, CGR) in the order you want them selected for display. The program displays the highest priority curve it can find. PetroWorks and RAVE also use these prioritized curve lists.

2. Pick Kind : A new field in the database for the Pick table is available for access. Pick Kind allows you to assign to the pick a “kind” such as Unconformable, Conformable; you can also use Pick Kind to designate how you arrived at the location of the pick (from core, from logs, from cuttings) or to designate which product made the pick (StratWorks, SeisWorks, PetroWorks). You can select Pick Kind while creating and editing picks within Correlation; you can add additional “kinds” using the OpenWorks Data Domain Manager. In essence, this is much like “Geologic Feature,” another means of sorting picks. You set the kinds you wish to extract from the database within the Pick Line and Pick Name tracks of the Well Template Editor. These selections are then displayed in applications using templates that contain these tracks, such as Correlation, Cross Section, Single Well Viewer, Wellbore Manager, and MapView (Log Signature Maps). Pick Kind has also been added to the list of data types that can be posted for a pick in the Well Template Editor Pick Name track. The Well Template Transfer Utility has been updated to account for Pick Kind.

Changes to Individual Applications and Utilities

1. Color Ramps : You can now edit the 64 colors associated with a color ramp. Each of the 64 colors is shown on a Color Editor panel, allowing you to set each one individually using RGB, HLS, or HSV values and to interpolate between any two selected colors.



2. Cross Section : Two changes were made.

• Interpolate mode added to Seismic Backdrop overlay option. This new option allows you to “smooth” out the variable density display and remove some of the “blockiness” seen in these displays in prior releases. Individual “cells” are less noticeable because colors from cell to cell are more smoothly interpolated in this mode.

• Utility for upgrading R97 Cross Section session files to R98 Cross Section session files added: Users who created fairly sophisticated Cross Sections in R97 can now upgrade their R97 or Cross Section saved session or R97 LASPRM files to R98 Cross Section session files. Invoke this utility (found in $OWHOME/StratWorks/bin/c97sh) from the command line:

<prompt> c97sh &

A dialog box where you can specify the input R97 LASPRM or session file and the name of the target R98 session file appears.

3. Header/Trailer Editor : We have added support for the extraction and display of data from the Petrophysical_Parm_Value Table.

4. MapView : Well-specific templates are now supported by the Log Signature option so each well can display a different template. Well specific templates can be set in either Correlation or Well Template Editor.

5. Single Well Viewer : Three changes were made:

• We have added a depth readout to the status line, which reports the depth for the current location of the cursor in the window.

• There is a new option to view the on-screen plot zoomed to hardcopy size. The window zooms in automatically so that if you were to lay the hardcopy up next to your screen, the two would be the same size. In other words, it puts the application into a true scale mode rather than a preview mode in which the entire plot is displayed.

• We have added a zoom window to Single Well Viewer that operates in the same fashion as the windows in Correlation and Cross Section.

6. Strat Column Editor : There is now a limited access mode which allows you to alter only interpreter-specific features of surfaces and units such as colors, line styles, fills, etc. Faults can be manipulated in this mode. (They are not restricted by this mode.) A new shell script called horzsh2, located in $OWHOME/StratUtil/bin, initiates the limited access mode of the Strat Column Editor. You can run this script from the command line of an xterm.

7. Wellbore Manager : The import and export functions removed from the previous release have been reinstated.

8. Well Template Editor : We have renamed the Geocolumn track to Strat Column track. For R98/R98.1 we added the Interpolate Undefined Units option to the Geocolumn (now Strat Column) track display parameters. However, occasionally, surfaces from other strat columns were used, causing confusing results from the unit interpolation. In R1998.1.2 you can specify which surfaces are used to draw units by choosing either all active surfaces or only the surfaces that define the column displayed in the track.



A Utility to Query 2D Lines and Their Associated 2v2 Files: line2v2

by James Zhou

An interactive script, line2v2, allows SeisWorks/2D users to query 2D lines in a working project and their associated 2v2 files in the corresponding master project. When you display seismic data in seismic views, you may find it useful in the situations where your master project contains thousands of lines and each line has different sets of 2v2 files. You will get a blank seismic view if the line selected for display does not have the related 2v2 files listed as Primary Seismic File and Auxiliary Seismic File in the Seismic Display Parameters dialog in SeisWorks/2D. You can avoid this situation with this script, which produces the association of lines and 2v2 files in three ways as described below.

Getting the Script

This script, line2v2, is located on isite in:

/patches/SeisUtils/unsupported_LGC_Scripts

You can use ftp to download it as an ASCII file and place it in the $OWHOME/SeisUtils/bin directory on your system for general usage in the Landmark environment.

Running the Script

1. Start the script from an xterm with the following command:

%> line2v2 <2d_working_project>

If you do not provide the script with a 2D working project or if the input 2D working project is not found on your system, the script will simply exit with appropriate messages.

With a correct working project, the script first checks the master project and then lists the options you can choose:

%> line2v2 fl2d

This utility displays the associationof lines and 2v2 files in SeisWorks2D projects. There are three options:

1) list all lines and related 2v2 files2) list all 2v2 files for a given line3) list all lines for a given 2v2 file

Output is saved in line2v2.log file.

Hit <Return> to Continue ...

Working Project: fl2d

Master Project: lgc_fl2d

List All Lines And Associated 2v2 Files: 1



List All 2v2 Files for A Particular Line: 2List All Lines for An Individual 2v2 File: 3

Enter An Option (1, 2, 3 or 'q' to Exit):

2. Enter 1 to list all lines in the working project and associated 2v2 files in the master project. This may take awhile if you have many lines, 2v2 files, and project directories. An example output follows:

G89A-1027_____________________

dep8a0001

dep8b0001

dep8c0001

mig000001

mig080001

tmp080001

G89A-1028_____________________

dep8a0001

dep8b0001

mig000001

mig080001

G89A-1029_____________________

dep8a0001

G89A-1030_____________________

dep8a0001

dep8b0001

mig000001

mig080001

G89A-1031_____________________

dep8a0001

dep8b0001

mig000001

mig080001

G89A-1032_____________________



dep8b0001

mig000001

mig080001

G89A-1033_____________________

dep8b0001

mig000001

mig080001

G89A-1034_____________________

dep8b0001

mig000001

3. Next you will be prompted for the options again. Enter 2 to list all 2v2 files for a particular line you choose.

4. You can either copy and paste a line from a line list that is generated by the script, or type in the line name, which must be 30 characters long, depending on your input to the question below:

Do You Want to Print Line Names? <y/n>

If you enter y , a list of lines is generated. You can copy a line name from the list and paste it as the input to the program, and the 2v2 files are displayed for the selected line:

G89A-1027_____________________

G89A-1028_____________________

G89A-1029_____________________

G89A-1030_____________________

G89A-1031_____________________

G89A-1032_____________________

G89A-1033_____________________

G89A-1034_____________________

Select 30-Character Line Name: G89A-1027_____________________

G89A-1027_____________________

dep8a0001

dep8b0001

dep8c0001



mig000001

mig080001

tmp080001

If you know the line names, which can be printed in the utility, lincat, you can simply enter n to the above question and type in the line name as the input to the program to list its associated 2v2 files. But you must make sure that the line name you enter is 30 characters long. Otherwise, line2v2 won’t be able to find the line in the working project.

5. You will be prompted for the options again. Enter 3 to list all lines for a given 2v2 file. You can either copy and paste a 2v2 file name from a 2v2 file list created by the script or type in the file name, which must be 9 characters long, depending on your input to the question below:

Do You Want to Print 2v2 File Names? <y/n>

If you enter y , a list of 2v2 files is created. You can copy a 2v2 file name from the list and paste it as the input to the program, and the lines which have the given 2v2 file are printed:

dep8a0001dep8b0001dep8c0001mig000001mig080001tmp080001

Select A 9-Character 2v2 File Name: dep8c0001

Seismic Data File: dep8c0001

G89A-1027_____________________G89A-1029_____________________

If you enter n to the above question, a list of 2v2 files will not be created. In this case, you need to input the 2v2 file name, which must be 9 characters long. A 2v2 file name is composed of the processing level (5 characters long) and the version number (4 characters long) in bcm2D.

6. You can terminate the program by entering q when you are prompted for the options. All the output on the screen is saved for printing in line2v2.log file in the current directory. This script can be interactively used with SeisWorks/2D when you display seismic lines in seismic views.

Please note that this is an unsupported script. You are welcome to send your comments, suggestions, and questions to James Zhou at [email protected].



Customizing the Document Browser and the Error Logger

by Mike Lockhart

There are two tools supplied with OpenWorks which can be customized beyond their default scope. These are the Document Browser and the Error Logger. Both the Document Browser under Utilities (Fig. 1) and the Error Logger under Utilities (Fig. 4) are normally found on the OpenWorks launcher bar.

Each can be expanded in scope to provide an added utility for the user.

Document Browser

Figure 1. Location of the Document Browser.

The Document Browser is normally started from the OpenWorks Command Menu with the following line in the 'launcher.dat' file:

“Document Browser” “dbrw 2>$HOME/run/dbrw.err 1>&2 &”

In the default state, this tool provides a mechanism to browse all of the help documentation for OpenWorks (Fig 2). However, it can be modified to access any Landmark documentation available to you.



Figure 2. The Document Browser lists the available manuals.

Landmark online documentation is written in FrameMaker®, a desktop publishing application. If you have a FrameMaker license available to you, you can, of course, start FrameMaker and view any FrameMaker file that you can find. In most environments, however, this is not the usual case. What is always available, however, is a license to view ‘FrameMaker’ files, which is supplied with OpenWorks.

When you start OpenWorks, the FrameMaker viewer is automatically started:

54 delorean:~/usenet/customizing 10:35am > ps -ef | grep viewerlockhart 14454 1 0 08:23:37 ? 0:02 /r98/frame/bin/sgi.irix.mips/viewer +viewerIsServer -rpcProp _Frame_LGC_RPC

It is the viewer which opens the appropriate online Help files whenever you click on a Help topic. In order for viewer to find the appropriate files, it scans an environment variable called HELPDIR.

rolls{r98}% echo $HELPDIR/big/solaris_r98:/big/solaris_r98/StratWorks:/big/solaris_r98/StratUtil:/big/solaris_r98/GeoDataLoad:/big/solaris_r98/PetroWorks:/big/solaris_r98/Geo-dataWorks:/big/solaris_r98/GeoDataLoad



OpenWorks Help is set up so that the viewer looks for the first occurrence of a requested file in a “docs” directory in the HELPDIR path. These “docs” directories are usually at the application’s first level. HELPDIR is usually set from your “.lgclogin” (or equivalent) by statements like the following:

if ( -d ${STRATUTILHOME}/docs) then setenv HELPDIR "${HELPDIR}:${STRATUTILHOME}" endif

in the appropriate application stanzas.

Virtually all Landmark applications are started by scripts that also set this variable, so that Help files are accessible by the application. So, where is all this taking us? It takes us to a file:

$OWHOME/dat/doc.dat

This is the file that the Document Browser opens. The default file contains references to OpenWorks and GeoDataLoad help files only, but this ASCII can be modified to allow access to any FrameMaker file on your system. This can be useful:

• You can open any Landmark FrameMaker Help file without opening the application.

• If you have other applications that use FrameMaker, you can look at their Help documentation without bringing up the application.

• You can even bring up the browser without starting OpenWorks.

Here's a sample of “doc.dat” and some rules for customizing:

"System Administration" "none" "none"" Planning the Installation" "none" "none"" Planning the Installation - TOC" "planinst.hyperTOC.doc" "home"" Overview" "overview.hyper.doc" "home"" Understanding OpenWorks 5.0" "undstowr.hyper.doc" "home"" Supported Configurations" "configur.hyper.doc" "home"" Understanding Project Management" "undsprj.hyper.doc" "home"" Final Planning" "undsprj.hyper.doc" "Final Planning"

When you edit the file, follow these rules:

• no blank lines

• no provision for comment lines

• three items per line:

— title (your choice)

— Help file name - must be a FrameMaker document

— tag

The edited information must be enclosed by double quotes. No duplicate titles are allowed—any after the first will not be displayed. Duplicate help file names will follow normal path rules—first found, first displayed.



Looking at the example above, these notes explain some of the commands.

• The entries “none” and “none” after the “System Administration” entry indicate that “System Administration” is a heading.

• Indention will create a structural tree.

• The third element, “tag,” normally says “home,” indicating that the program will go to the first page in the file.

• “Final Planning,” in the last line, goes to a page within that title.

Here is part of a customized file that allows access to all the Release Notes:

"Release Notes" "none" "none"" R98Plus Release Notes" "R98PlusReleaseNotes.hyper.doc" "home"" EarthCube" "EarthCube_Release_Notes.hyper.doc" "home"" Fault Mover" "RelNotes98.1" "home"" GeoData_Loading" "GDLReleaseNotes.hyper.doc" "home"" Geo-dataWorks" "GDLReleaseNotes.hyper.doc" "home"" OpenExplorer" "OEReleaseNotes" "home"" OpenWorks" "none" "none"" OpenWorks" "OWReleaseNotes.hyper.doc" "home"" OpenWorks - Cert4 "OWReleaseNotes.hyper.doc" "home" PetroWorks" "ReleaseNotesPW.hyper.doc" "home"" PetroWorks Advanced" "ReleaseNotesPW_ADV.hyper.doc" "home"" PostStack" "relnotes_1998.2.fm "home"" Rave" "RAVE_1998.1_Release_Notes.hyper.doc" "home"" SeisWorks" "SeisWorksReleaseNotes" "home"" SynTool" "ReleaseNotes.doc" "home"" Wellbore Planner" "ReleaseNotesWBP.hyper.doc" "home"" WellborePlnCnvrt" "ReleaseNotesWBP_Convert.hyper.doc" "home"" ZMAPPlus" "98.1RelNotesSC" "home"

To allow access to all these files, HELPDIR has been expanded in this example:

63 delorean:/r98/SeisWorks/docs 1:40pm > echo $HELPDIR/r98:/r98/GeoDataLoad:/r98/OpenVision:/r98/SeisWorks:/r98/SynTool:/r98/StratUtil:/r98/Zycor:/r98/CA_Zycor:/r98/TDQ:/r98/Geo-dataWorks:/r98/EarthCube:/r98/PostStack:/r98/Rave:/lib/docs:/r98/WellborePlnr:/r98/Stratamodel/help_files:/r98/Oasiis:/r98/SigmaView:/r98/PetroWorks:/r98/WellboreMgr

Some applications don’t follow the rules:

• SynTool—uses a directory called “doc,” not “docs”• PostStack, Stratamodel—”docs” directory is buried down the tree• SigmaView—docs directory is usually in help directories• Third Party—documentation could be anywhere



For these situations, you can create appropriate soft links:

68 delorean:~ 1:44pm > ls -l $OWHOME/SigmaView/docslrwxrwxrwx 1 lockhart cust_sup 23 Jun 17 11:07 /r98/SigmaView/docs -> /apps1/sigmaview/oa52/help/

76 delorean:/r98 1:47pm > ls -l PostStack/docslrwxrwxrwx 1 root sys 21 Nov 18 1997 PostStack/docs -> ./ port/docs/post/docs/

Figure 3. This is what a customized “doc.dat” file will look like in the browser window. This allows access to all help files on this user’s system.



If you want to run the browser in a non-Landmark environment, try this script:

#***************************************************************72#!/bin/csh## This script will do the following:## 1. Check for the existence of $OWHOME/dat/doc.dat# 2. Set up the path HELPDIR.# 3. Fire up the FrameMaker viewer# 4. Fire up the OpenWorks Document Browser.## 1. The document browser uses the file $OWHOME/dat/doc.dat to# find the appropriate help files. This file can be customized,# and the rules can be summarised as follows:## 1. Three items per line: Title, name of the help file and a # location tag. These items must be " delimited. For example:#"Release Notes" "none" "none"#" SeisWorks" "none" "none"#" 3.1 Release Notes" "SeisWorksReleaseNotes31""home"## Note that "none" "none" denotes no file (implies a heading),# indentation shows the structure, and "home" says "start of# the file". Titles must be unique (or any after the first# will not be displayed), and there must be no duplicate help# file names## Define OWHOME

setenv OWHOME /r98

if ( ! -e ${OWHOME}/dat/doc.dat ) then echo " No ${OWHOME}/dat/doc.dat. Exiting." exit 1endif

# 2. First off we set up the HELPDIR path. This is required,# since the browser assumes that all help files are in 'docs'# directories under the directories listed in $HELPDIR## First OpenWorks#

if ( ! -d ${OWHOME} ) then echo "${OWHOME} does not exist. Exiting."endif

if ( -d ${OWHOME}/docs ) then setenv HELPDIR "${OWHOME}"endif



## Rather than go through the whole tedious business of running # .lgclogin (or its equivalent), manually set the directory path# below. Note that a 'docs' directory, containing the help files# must exist. Use links to collect the odd ones out (like# SynTool, PostStack. Oasiis...). Comment out anything you don't# want.#

if ( -d ${OWHOME}/GeoDataLoad/docs ) then# GeoDataLoad setenv HELPDIR "${HELPDIR}:${OWHOME}/GeoDataLoad"endif

if ( -d ${OWHOME}/SeisWorks/docs ) then# SeisWorks setenv HELPDIR "${HELPDIR}:${OWHOME}/SeisWorks"endif

if ( -d ${OWHOME}/Syntool/docs ) then# Syntool setenv HELPDIR "${HELPDIR}:${OWHOME}/Syntool"endif

if ( -d ${OWHOME}/Zycor/docs ) then# ZMAP+ setenv HELPDIR "${HELPDIR}:${OWHOME}/Zycor"endif

if ( -d ${OWHOME}/CA_Zycor/docs ) then# Contouring Asst. setenv HELPDIR "${HELPDIR}:${OWHOME}/CA_Zycor"endif

if ( -d ${OWHOME}/PostStack/docs ) then# PostStack/PAL setenv HELPDIR "${HELPDIR}:${OWHOME}/PostStack"endif

if ( -d ${OWHOME}/Rave/docs ) then# Rave setenv HELPDIR "${HELPDIR}:${OWHOME}/Rave"endif

if ( -d ${OWHOME}/TDQ/docs ) then# TDQ setenv HELPDIR "${HELPDIR}:${OWHOME}/TDQ"endif

if ( -d ${OWHOME}/OpenVision/docs ) then# OpenVision setenv HELPDIR "${HELPDIR}:${OWHOME}/OpenVision"endif

if ( -d ${OWHOME}/EarthCube/docs ) then# EarthCube setenv HELPDIR "${HELPDIR}:${OWHOME}/EarthCube"endif

if ( -d ${OWHOME}/StratUtil/docs ) then# StratWorks setenv HELPDIR "${HELPDIR}:${OWHOME}/StratUtil"endif



if ( -d ${OWHOME}/Geo-dataWorks/docs ) then# Geo-DataWorks setenv HELPDIR "${HELPDIR}:${OWHOME}/Geo-dataWorks"endif

if ( -d ${OWHOME}/PetroWorks/docs ) then# PetroWorks setenv HELPDIR "${HELPDIR}:${OWHOME}/PetroWorks"endif

if ( -d ${OWHOME}/WellborePlnr/docs ) then# Wellbore Planner setenv HELPDIR "${HELPDIR}:${OWHOME}/WellborePlnr"endif

if ( -d ${OWHOME}/Stratamodel/help_files/docs ) then# Stratamodel setenv HELPDIR "${HELPDIR}:${OWHOME}/Stratamodel/help_files"endif

if ( -d ${OWHOME}/Oasiis/docs ) then# Oasiis setenv HELPDIR "${HELPDIR}:${OWHOME}/Oasiis"endif

if ( -d ${OWHOME}/SigmaView/docs ) then# SigmaView setenv HELPDIR "${HELPDIR}:${OWHOME}/SigmaView"endif

## Uncomment the following to check the directories searched#

# echo ${HELPDIR}

## 3. Fire up Frame Viewer#

${OWHOME}/bin/startfview &sleep 10

## 4. Fire up the document browser.#

${OWHOME}/bin/dbrw >& $HOME/run/dbrw.err &#***************************************************************72

This script, with a little editing, may fill your needs. You can find this script, customizing.txt, on isite in /patches/SeisUtils/unsupported_LGC_Scripts.

You can add this script to .mwmrc (Solaris) or .auxchestrc/.4dwmrc on an SGI, etc. to start the browser without being in a Landmark environment.



Error Logger

Figure 4. Location of the Error Logger.

In a similar vein to the Document Browser, OpenWorks provides a convenient method of running some applications with the error level increased and the output redirected to a log file for further examination. Logging errors is often necessary for troubleshooting problems. Error Logger is started with the following command from the OpenWorks Command Launcher:

"Error Logger" "owe 2>$HOME/run/owe.err 1>&2 &"

Figure 5. The default appearance of this application.

Use the scrolling list on the left to select the application whose error level you wish to change, then change the error level by selecting the appropriate button on the right.



Note that only the environment variable ERR_LEVEL is set, as this is the main diagnostic for OpenWorks. If you are troubleshooting other applications, then you must make provision to set other appropriate debug variables, for example:

SeisWorks LGC_DEBUG0(off)/1(on)

OpenVisionOVDEBUG1 - 100 (values from least => most verbose)

SC3DEBUG1 - 10 (values from least => most verbose)

For system call tracing, you can also use truss (Solaris) and par (SGI).

The syntax is:

Solaris: truss <application>

SGI: par -s -SS <application>

This tool can be similarly customized to run any Landmark application by editing the file

$OWHOME/dat/errorlog.dat

The format is <Description> : <application>

• Do not use leading blanks, blank lines, or comments.

• Note that the line items with leading blanks are header items to make the file more readable.

• The application can be a script that would allow for further customization, such as setting the various debug options as noted above.

Figure 6. How a modified file might look.
