dm in landmark appl env eng sep 2011

Fundamentals of Data Management in Landmark applications environment.

Naila Huseyn-zadaManaging Consultant Data ManagementLandmark Software & Services (Halliburton)

Fundamentals of Data Management in Landmark applications environment

Have you ever faced the situation when data seemed to exist, but they were unstructured and isolated from each other? Have your ideas gotten broken into a mass of heaped information? Have you been frustrated by various data being chaotically placed in different databases from previous researches? Many of you will answer - yes, alas! Such things happen in our wealth of information technologies, and the larger a company is, the more these occurrences may happen.

The search for a new way to handle these situations has led to the development of a data management program, which has already made considerable contributions to the success of some leading companies. It is known that the effectiveness of decision making directly depends on the quality and timeliness of the given information. The data quality means the reliability of each data unit, and the speed of data gathering depends on the speed of access to it, which is only possible with effective data structuring within the company and the use of high-speed applications and techniques. Thus, if the responsibility for data quality lies on the shoulders of a workgroup, department, or company data managers, then the decision for a data management concept and the type of technical base depends on a company itself.

As a data manager within the Landmark applications environment, I have gained extensive experience working on various projects for different companies, which are outlined in this article. First, I would like to highlight the data management concept offered by Landmark as well as to define what qualitative data are and how to structure them in the framework of Landmark applications. Secondly, I would like to help Landmark users to get as much use from the functionality of the classical package applications as is already available for them for efficient data management. Thirdly, I would like to acquaint users with applications from the modern data manager, including WOW™, CDA, and PowerExplorer® programs. Finally, I would like to draw attention to the modern problems in data management as a means to educate and train data managers in the oilfield industry.

What is the “Classical package” of Landmark applications and the OpenWorks® project database?The current “Classical package” for Landmark applications is a family of integrated OpenWorks® applications

based on the platforms, UNIX and Linux. The underlying system of the OpenWorks family represents a base structure for geological and geophysical applications designed to perform the following:

seismic interpretation in 3-D and 2-D log-curve analysis geological interpretation velocity modeling mapping data managementData collection for sharing and collaboration is called

the OpenWorks project. The OpenWorks application includes two types of projects—project databases and interpretation projects. The OpenWorks project database is organized in the Oracle relational database and represents a set of more than 1,000 tables capable of storing more than 10,000 data elements, including various geological, geophysical, and petrophysical data, such as well information, log curves, faults, seismic navigation, production data, interpretation, etc.

The number of interpretation projects that represent a subset of the data or a certain area of interest can be unlimited within a project database. Physical data are located in a database for interpretation projects to refer to. Such a model enables the avoidance of data duplication, provides an economy for disk space, and strengthens data protection while preserving data integrity.

Some types of data, particularly seismic files and horizon 3-D, are within the directories of the OpenWorks system hierarchy rather than in the database tables. The OpenWorks system also stores a large amount of other files and data, including culture data, color maps, format files, etc. As a whole, the dataset of a project database is only limited by the available disk space.

The OpenWorks application represents a structured database, providing reliable storage and quick access to data. Because of its extensive capabilities, the OpenWorks project database R5000 has earned the Word Oil journal award for “Best Data Management Solution” in 2008. Our task is to use the full capabilities of the OpenWorks software for the creation of an efficient system for data management within the oil industry.

Naila Huseyn-zada 4/21/2023 of 14

Fig. 1—OpenWorks database is a basis for various geological and geophysical interpretation. All data in the OpenWorks project database and its environment are inter-connected, which allows users to work

with high-productive applications for teamwork.


What is OpenWorks data management, and what should the expert in this area know?

The OpenWorks database contains a wide range of operations for managing its data, including:

the gathering, analysis, processing, and placing of the data in a project database

data quality check associating data with each other data administrating, both in a project and in a system data transferring from a project to a project and from

a project to an application workflow and standard development data archiving documentingThese operations assume a degree of knowledge in

various areas. Depending on the volume of data and a suite of applications, data management can involve a single universal expert or a team with a variety of duties and activities. However, experience shows that for either case, those involved in data management within the Landmark applications should possess a certain level of knowledge, which includes the understanding of geology and geophysics as well as knowledge in the following areas:

UNIX/Linux operating system and commands OpenWorks project database Conception of the Oracle® relational database Geodata loading and management Seismic data loading and management StratWorks®, SeisWorks®, and Z-MAP Plus™ applications WOW, CDA, and PowerExplorer applications SQL (structured query language) Shell, AWK, and/or Perl scripting languages Data medium Basic foundation of documenting and reportingThis amount of knowledge is not gained in one day or by one training. Anyone interested in this knowledge should

possess goal-seeking behavior, inquisitiveness, and an eagerness for self-development. Unlike other specialties in which a considerable quantity of books and manuals are available, the data management program, particularly in the area of geo-research, will not provide an abundance of literature in this field. Mastery, rather, comes with practice.

Data management begins with a name.That statement should not surprise anybody. Standard practice for data management begins with naming individual

source files, wells, maps, projects, and directories and deciding where the data should be stored. The list of all possible data is long, but the task of naming these data exists at each stage of the data management program.

We are free to choose names according to our practices, but each expert, workgroup, and company should have a standardized naming scheme. Data analysis is highly effective if a workgroup has a system in place for naming and allocating data. For example:

Data could be grouped in directories according to maps, graphic files, source data files of a certain project, etc.; File names are informative, and, therefore, there is no need to look through the contents of each file in search of

necessary information; Names of key parameters are integrated in the framework for both a single project as well as a whole database.For example, if the same parameter in different wells of a project has a different name, it can complicate the analysis

of a group of wells. Implementing a standardized naming scheme enhances many data management operations, such as the transfer of data between different projects and data archiving.

When reading through these recommendations for a successful data management system, you may wonder why these guidelines are so unique. While these recommendations may seem obvious and simplistic, the fact is that they are often overlooked and rarely implemented because too much time is spent on the analysis of the available data.


Fig. 2—World Oil Award to OpenWorks database for “Best Data Management Solution” 2008. Over the last 10 years, Landmark applications received 4 additional awards by the World Oil journal: GeoProbe® software in 2001 for the “Best Development, Production, and Reservoir Data Solution”; AssetView™ software in 2003 for “Best Visualization Solution”; GeoProbe software again in 2004 for “Best Data Visualization Solution”, and DecisionSpace® Desktop application in 2010 for “Best Visualization and Collaboration Solution”.


Moreover, it is often easier to start from scratch than to find the available data. A naming scheme in a workgroup is especially useful during data transmission from the client to the customer. Historically, it has been common for data files to be named after employee family members, pets, etc.; however, it would be more beneficial to use names in conjunction with the content of the data.

Therefore, the first principle of effective data management is to create a standardized naming scheme and to effectively apply it to the company data management program.

What are the key objectives required of a corporate naming scheme?

Experience shows that any naming scheme is better than no system at all. As a basis for developing a standardized naming scheme, I suggest adhering to a specific concept of listing the company’s key objectives and incorporating data management fundamentals and criteria of data quality control. This experience can be adopted, developed, and adapted to a company’s specific needs. The following is a basic list of key items that would require the use of a standardized naming scheme:

files, directories, file system database and interpretation projects of

OpenWorks applications well headers, statuses, symbols, lists log curves, aliases stratigraphic columns, surfaces, formations,

attributes lithological columns, classes, symbols seismic surveys, 2-D lines and 3-D volumes,

horizons, faults velocity models maps, grids, point sets, polygons sessions, color maps, graphic files, culture data format files for data import/export archival catalogs

Let’s begin with basics of file naming and the convenience of using prefixes.

A file name should be informative, reflecting the actual content of data, and should be an appropriate length and be as unique as possible. It is best to avoid using names with 1–2 characters; while they can be convenient in the short term, using these names permanently is unacceptable. Extremely long file names, as a rule, are unreadable at first sight, and in some cases, can exceed the admissible file name length. For different variations of the same data, it is desirable to use an original file name with the addition a version number or edition date. Because the Landmark classical package works in UNIX/Linux systems, it is important to use their wide range of capabilities and to understand the specifics of these systems so that file names are assigned using the appropriate characters and symbols allowed by the operating system.

When using the OpenWorks software and its applications, each user should be assigned an interpreter ID, which should not exceed 5 characters. StratWorks, PetroWorks®, and Z-MAP Plus interpretation data, including grids, contours, well correlation, startigraphic columns and surfaces, well lists, well templates, etc., are assigned to the interpreter ID. The interpreter ID is a convenient key-in data search, and it is recommended to create a clue for using it.

Many modules of applications in browser windows are capable of sorting data by various fields, and consequently, if the capital letter in the interpreter ID is used as a prefix at the beginning of a name, then when sorting the data alphabetically, your data will be grouped together. This simple reception allows for the facilitating of a particular data search. The use of a prefix is not only convenient when naming the data that will be assigned to a database, but also any other data that may be stored in common directories of a project (session files, format files, etc).

A little bit about the file extensions


Fig. 3—Typical flowchart of data loading to the OpenWorks project database. The process of data loading, irrespective of their types, includes stages of data gathering, preliminary processing, and actually loading with QC on each stage. QC checks the uniformity of names, as outlined by a company’s naming system. Adhering to company procedures and standards is also an important part of data control.


File extensions should be used for describing data types. Unlike Windows, where a type of file is defined solely by its extension, in UNIX/Linux systems, the extension has no significant importance. A file can have one, two, three, or more extensions, or no extension at all because the system recognizes it as only a file name and nothing more. For example, you can easily create a simple text file and type the extension gif or sh. The system will not try to open the file as a picture or a shell script based on the extension provided because for OS, it is not the file name that is important, but its index description. For the convenience of UNIX/Linux experts, it is acceptable to adhere to standard extensions.

The guidelines for file extensions mentioned above apply exclusively to UNIX/Linux systems. In Landmark applications, the rules for extensions are completely different; applications actively use and distinguish between many extensions, which are specific for each application. Documenting within the Landmark application is supplemented by appropriate catalogs for data types and their extensions.

As you can see, extensions are convenient and important in the definition of the data types; it is necessary to be instructed in their use and to put them into practice.

All about well headersThe OpenWorks database offers about 200 tables as well as all data forms in the Well Data Manager module for

all possible well information, but the main data forms that categorize a well according to its type and locations include Well Header, Elevation, TD, Directional Survey, and Positional Log. OpenWorks Well headers are developed to provide as much information as possible, and we should use this capability to the maximum. Well Header offers many fields. We will first consider the fields that identify the well name, namely UWI, Common Well Name, Well name, and Well Number.

In an ideal situation, each well would possess a certain unique identification number within a company, corporation, or country. If such information is not present, then we should devise a rule for creating UWIs. The Common Well Name field, as indicated by its name, should contain the full name of a well; the Well Name field can be filled by a shorter name of a well, and the number of a well can be entered into the corresponding field. Such well naming allows using the option of Landmark applications to display a name of any header fields and/or well number listed above according to a task or the desire of expert, which is highly useful in the case of regional analysis and mapping.

The following Well Header fields are especially important and demand attention: XY surface, XY borehole Elevation and Elevation type Total Depth Current Well Status CRS Data Source Remark

Position Log Data of a well are calculated based on the coordinates of well head and the directional survey data adjusted for elevation and the Cartographic Reference System. Calculated by the table of the positioned log data, the coordinates of well buttonhole are automatically written to the Well Header. The elevation and total depth values inserted into Well Header are replicated in the corresponding data forms.

It is highly important that the key fields contain accurate information, otherwise all subsequent well interpretations may be erroneous. Besides, the absence of parameters can lead to incorrect visualization of a well in applications. For example, the absence of a Total Depth value does not allow for the visualization of a well in the StratWorks Correlation panel.

It is necessary to pay special attention to the Current Well Status field of a Well Header. By default, the absence of this information is identified by status UNKNOWN, but if there is correct information in the field, it is possible to build maps in StratWorks and Z-MAP Plus applications with drawing symbols of well statuses, and also to visualize wells in AssetView™ software with defined colors matching a particular well’s status. OpenWorks database offers a set of standard well statuses in corresponding control tables and assigned symbols to these statuses. These data can be extended and corrected through the Well Symbol Editor and Data Domain Dictionary. The history of well statuses, aside from the Well Header, can be fixed in the special OpenWorks table—Well Status History. This information is useful in studying the history of a field.

The Field Data Source of Well Header is also highly informative in the analysis and search of data sources. Because data management also includes the knowledge of data sources, it is necessary to pay attention to records of similar information as well. In the absence of corresponding fields, any other information pertinent to the Well Header can be entered into the field, Remark.

It is necessary to remember that there are no trivial fields in Well Headers. There are a few more fields, which, in the presence of the unified data, can be used as keywords in sorting, including Basin, Country, Field, Operator, and Platform ID. The data in these fields are not essential, and, as a result, data are not entered into these fields or entered without paying attention to spelling. While manually creating or editing Well Headers, OpenWorks database verifies the entered data in these fields with special validation tables. If nothing was entered into these fields, the system assigns the default value—UNKNOWN.



In cases of batch data loading and loading data by the ASCII Loader, the data validation is not often activated, and if in headings of the loaded data there are records of these fields (it is often observed in the headers of log curves in LAS format), then all possible samples of a country or field writings are loaded to the OpenWorks project tables. It is, therefore, difficult to be consistent if the OpenWorks project offers a wide variety of data (for example, AZERBAIJAN, Azerbaijan, AZE). Such a discrepancy is immediately discovered in applications, including Well Data Manager, WOW, and AssetView programs, in which a search by keys is offered and, thereby, renders the search inefficient.

Regardless of how large or small an OpenWorks project is based on the numbers of wells, it is necessary to fill in all the above-listed fields correctly according to the generally-accepted naming scheme, thereby creating the basis for merging data into large regional projects. The utility Data Dictionary allows the correcting of validation tables of OpenWorks projects and adapting them to the naming scheme designed by a workgroup or company.

The primary goals of well headers data management are: Naming scheme development for well names, statuses, and their symbols; Correct entering of the information into header fields; Periodic audit of well headers.

Stratigraphic dataOpenWorks database offers the capability for each interpreter to create his own stratigraphic column for well

analysis. Experience shows that this possibility generates a mass of well picks and stratigraphic formations. A detailed study of this mass found that several of the picks, in fact, have the same names, but different registers, syntax, and abbreviations were used in the naming, and, as a result, these picks do not match each other (e.g., Pick A, PickA, pick A, pick a, etc.). Variations are endless.

The occurrence of such a name variety in identical picks is based on the fear of interpreters “losing” and “not recognizing” their own interpretation, which indicates insufficient understanding of the OpenWorks and StratWorks application capabilities.

For OpenWorks database creation and storage, identical picks with the same names is not complex, as the Pick Observation Number (the arbitrary number designating a particular pick) and Data Source (the interpreter ID) parameters are being assigned to each pick. Therefore, the interpretation is assigned to the concrete interpreter ID that the security system of OpenWorks data is based on; the applications do not allow the pick assigned to interpreters by another interpreter to be changed without special permission. Permission might be granted in the case of carrying out a group interpretation when several users are associated with one interpreter ID.

This feature prevents data duplication and the complicated procedure of comparing and merging results of interpretation under one interpreter ID, or the necessity to assign the data to public ownership. OpenWorks database


Fig. 4—The basic module for well data management. The Well Data Manager is the utility that allows users to view, edit, and delete well information from a database. A user displays information by using data forms. Each data form contains data from one database table, such as pick data, fault data, or log curve data, enabling a user to be focused only on necessary information.

Fig. 5—The basic stratigraphic frame of an OpenWorks project. Stratigraphic column defined by the Strat Column Editor utility establishes interrelation between surfaces and stratigraphic units.


also allows for decisions of specific tasks by a single user to use several interpreter IDs and to have various versions of interpretation assigned to these interpreter IDs.

The unification of stratigraphic names is just as necessary for a single project as it is for the whole database. There are quite a lot of advantages for it, for example, pick data transferring together with other well data from project to project, which enables regional analysis without adaptation of the data and additional association of the stratigraphic column. Moreover, the unification of pick names and stratigraphic formations enables the use of production data in StratWorks database (this topic is covered widely in the “Production Data” section). Stratigraphic formation attributes (Zone Strat Attribute), including formation pressure, permeability, porosity, water saturation, etc., also demand an effective naming scheme, otherwise the difficulties appear in mapping in StratWorks database.

The primary goals of stratigraphic data management are: Naming scheme development for formations, surfaces, picks, and formation attributes; Creating the standard stratigraphic column; Correctly entering data into a database; Periodic auditing of pick data.

Log curve dataFor the unification of log-curve names,

Landmark offers a list of more than 500 curve names by default, based on the Schlumberger curve names list. Upon loading the log curve into an OpenWorks project, a curve, whose name is not described in the above-mentioned list, the Curve Loader utility offers two options—to pick a log curve name from the list of available names or to add a new name to this list.

Whether or not the log-curve name unification assumes that within a project or a database as a whole, that the log curve of one type will be named identically, for instance, in the presence of set of variants of names, it is reasonable to use a minimum of variants of gamma logs: GR = {gamma, GR, GR_v1}.

The unification of log-curve names, aside from data ordering, offers the following advantages in applications:

creating the unified well templates that simplifies well data analysis in StratWorks and PetroWorks;

selecting a long list of wells that instantly accelerates the log-curve display in

SeisWorks and AssetView application; shortening a list of log-curve names that simplifies the data selection for manipulation; OpenWorks database enables the joining of log curves into groups corresponding to certain acquisition data

denoting the Logging Service Name (e.g., a set of log curves “MUD_GAS”). It provides usability in the management, processing, and edition of the data, both for PetroWorks software and for data transferring to third-party applications, for which the OpenWorks application is a database. If log curve data are processed, interpreted, or cannot be associated with some specific set, then such log curve data are loaded as composite/processed data. The specific service name can be added to the database via the Data Domain Manager. The primary goals of log curve data management are:

Naming scheme development for log curves and logging service names; Correct entering of the data into a database; Edition of the log curve parameters in Curve Dictionary—log curve types, amplitudes, color; Periodic audit of log curve data.

Production dataThe OpenWorks database enables the storing of oil, gas, condensate, water production, and injection data daily,

monthly, and cumulatively, as well as perforation, completion, and treatment data. These data can be identified by wells, an oilfield facility, leases, or by fields. In my practice, production and injection data were assigned to wells, and OpenWorks database served as a database for DTVIP, GeoGraphix®, and DSS applications. The usability of such storage is obvious—the database reliably protects against losses; the data are periodically updated, and named applications easily import the necessary data to particular working projects. In classical applications, it is possible to build bubble maps in StratWorks on the basis of production and injection data and to visualize these diagrams in AssetView software. One of the basic elements for the storage of production, injection, and perforation data is the producing zone identified by


Fig. 6—Log-curve interpretation in PetroWorks® Asset software. The log-curve data processing in the classical package is carried out by applications of the PetroWorks family. This package of petrophysical applications is directed on the decision of a wide range of tasks, the analysis of log curve data, and petrophysical interpretation.


Zone_Name parameter, which should be correctly associated with the corresponding stratigraphic formation. In case an association is made, the production and injection data become accessible in StratWorks database.

The second important point in data loading of production and injection is the unit of measure of their volumes. If the production or injection is measured in units that are not supported by OpenWorks database, e.g., in tons, the unit (“TON”) is indicated in the special field VO_USER_DEF, or production data can be converted into acceptable units by OpenWorks, particularly barrels. For such conversion, a value for a substance’s specific weight is also required. After the recalculation, the edited data can be loaded to the database. I believe that the first method is more rational, as there is no recalculation or possible mistakes and errors.

OpenWorks offers a set of tables for storing all possible production and injection data. In addition, the mentioned data in these tables can store information about the analysis of a produced substance (oil, gas, and/or water), production zone properties (reservoir thickness, pressure, permeability, water saturation, reservoir temperature, etc.), annotation information for production and injection entities, etc. The primary goals of production data management are:

Naming scheme development for production zone; Correct entering of data in to a database; Periodic audit of data for regular updating.

In addition to well dataWe have already discussed the data that are actively used by our customers, but the full list of data, which

Landmark applications work with and which can be stored in OpenWorks, is great enough. Covering all the data is obviously not possible for this article. I will present only a short addition to well data. The StratWorks application works with the following data:

Well Core (Shift Values, Core, Core Description, Sample Description, Sample Analysis, Sample Property); DST & RFT (DST Job Header, DST/RFT Cushion, DST/RFT Fluid, DST/RFT Materials to Surface, DST/RFT

Summary, DST/RFT Pressure); Well Test (Well Test, Well Pressure, Well Pressure AOF, Well Pressure AOF 4 Pt, Well Pressure Bottomhole); Well Planning (Well Plan, Plan Parameters, Targets, Optimization Parameters); Well Drilling (Rigs, Platforms, Slots, Drilling Objectives, Drilling Summary, Mud Reports); Well Equipment (Casing, Completion, Liner, Packer, Perforation, Plugging, Tubing).

The primary goals of well data management are: Initial data QC and validity check; Correct entering of data into a database; Periodic audit and QC of data.

Seismic dataThe allocation of seismic and seismic interpretation data in OpenWorks database differs from other types of data

allocations; for example, not all data relating to seismic are stored in an OpenWorks project database. OpenWorks tables store 2-D lines navigation data, 3-D survey data, 2-D horizons, faults, horizon and seismic data catalogs, seismic, and horizon data-processing history, as well as information about the physical allocations of data, which are stored out of the Oracle database as flat files. The data stored in Oracle database include seismic data, 2-D and 3-D, and 3-D horizons.

As mentioned earlier, all these data can be associated with the so-called interpretation projects (IP), which represent the logical data collection. Any number of interpretation projects can be created in one OpenWorks project database. As a result, data are being associated with IP virtually, but not physically, in which the IP enables the sharing of data dynamically, thereby eliminating the necessity for copying and subsequently duplicating the data. User access to the IP is controlled at the level of each project. Such decision of access improves data security by means of restricting the visibility of data to foreign users.

Each IP contains its own data, including color maps, format and sessions files, etc. IP files, which are not stored within OpenWorks projects database, are located in the hierarchy of the file system according to the special allocation schema, as described in the $OWHOME/conf/dir.dat file. The structure of such a file, for example, may look as follows:

/pa OTHER_FILES/pb 3d_horizons



/pc 3d_seismicAccording

to the given allocations schema, the file system, /pb contents 3D horizon files, /pc – seismic data, and /pa, and all other files imply certain extensions (color maps, sessions files, etc). Such a schema for file allocation is not mandatory and can be changed for each specific case.

For the usability of seismic data allocation and

management and especially for the usability of carrying out backups, it is recommended to store the files of infrequently-updated data (seismic files) separately from files that are updated often. Such allocation allows for the development of a back-up schedule so that file systems with dynamic data can be backed up regularly.

Interpretation projects are based on the following primary data: seismic data 2-D and 3-D navigation data horizons faultsFor work usability, the names of all above-mentioned data should be unified, not contain metasymbols, and be

informative and readable. Using prefixes helps to conduct a fast search and selection.Fault interpretation in SeisWorks, PowerView, and DecisionSpace Desktop applications is based on so-called

segments, the smallest part of a fault. For usability during the interpretation, fault segments are assigned to a fault just after the final decision of an interpreter to keep the concrete version of interpretation. If such an operation is not performed on time, a mass of unassigned segments appears in the database, which complicates data ordering, data manipulation, and most importantly, decelerates the speed of selecting a fault from a database. The primary goals of seismic data management are:

Considered data allocation in file system hierarchy; Name scheme development for horizons, faults, and seismic volumes; Name scheme development for maps and grids; Periodic audit of horizon and fault data; Removal test and mistaken interpretation; timely assignment of fault segments.

Lists and lists managers


Fig. 7—Data structure in OpenWorks environment. OpenWorks database stores project data in the Oracle database and in a file system; the last one also contains applications files. This diagram represents all basic components of OpenWorks database, which implement data storage and allocations.


OpenWorks database enables the restriction of the data selection for a working session of any applications by various lists, from which the most actively used are well lists, lists of horizons lists, and faults. The lists enable the joining of data of interest and are especially useful in large projects, as they significantly reduce the time for searching and loading data into applications. Lists of horizons and faults can be created in SeisWorks software directly at the data

selection from a project. For wells, a separate utility, the Well List Manager, possesses a wide range of capabilities in which a search can be conducted by well details (log curves, picks, fault picks, and zone strat attributes), comparisons of among already available lists, and broadcasting a selection to applications without creating a list. Lists can also be used for data transferring, both between interpretation projects (SeisWorks Data Transfer) and between OpenWorks projects (Project Data Transfer).

Using lists, it is possible to create and modify interpretation projects. In addition to the above-named utilities, there are other utilities that can be used for creating and working with lists. Field List Manager uses the data from fields and wells assigned to them. This utility is useful for large projects that cover various oil fields. As previously mentioned, inserting information into the Well Headers field creates the usability for appropriate well selection and its associated list. The Lease List Manager enables the uniting of wells by leases, and Seismic List Manager manages by lists of the seismic 2-D lines. The grid lists unit grids, which are useful for grid visualization in AssetView, thereby enhancing the search for required data.

Through the use of OpenWorks projects over the years, much of the information

accumulated has served to be useful, while some has not. There is certainly a risk of wasting time searching through these multiple lists, which naturally reduces efficiency, which is why well lists, other lists, and all data in general, should be periodically audited and the outdated information removed.

The primary goals of list management are: Name scheme development for lists; Creating general-purpose lists; Periodic audit of lists and the removal of outdated lists.

Data import and export. Data manipulationsAfter this short discussion on the types of data that can be managed in the OpenWorks database, we will talk

about the utilities for loading and unloading these data. In OpenWorks database, there are various utilities, each of which is compatible with certain types of data. ASCII Loader imports well data to the OpenWorks database in text format, ASCII, while Well Data Export is used to export well data in ASCII format. The Curve Loader imports log curve data, directional survey and position log data, synthetic seismograms, and time-depth tables.

The Data Import/Data Export Wizard allows you to load and unload mapping data. The Seismic Data Loader/Seismic Data Export is used to import and export navigation data of 2-D seismic lines. All these utilities are provided by a sample of format files by default and are highly useful for creating your own format files.

The export option is available in many of these utilities. In the Well Data Manager, the data can be exported in PDF, XLS, HTML, and text formats. The Pack & Go function in the Seismic Data Manager allows for the exporting and importing of horizon and seismic data files. The Data Domain Manager, Map Data Manager, Curve Dictionary, as well all list managers have the capability to export into text format.


Fig. 8—Lists managers. Lease, Field, Seismic and Well List Manager. Each of these managers enables the creation of lists through a simple selection of the required data or by way of certain criteria. The Pointed Dispatcher allows users to send the selected data to other applications.


Besides the ability to load in a graphical interface, OpenWorks database offers special programs for batch loading well and log-curve data. These programs are run from a command line and used for single or multiple loading. In the case of multiple loading, it is necessary to create a script with the series of loading, which can then be carried out consistently and without additional intervention. This capability is highly useful when loading a large amount of data. With regular loading of data to OpenWorks database, the script execution can be automated by setting start-up via the job-scheduler UNIX utility - cron.

The Project Data Transfer (PDT) feature is used for the transferring of data between OpenWorks projects and interpretation projects. This utility works with several data types stored in OpenWorks database. Moreover, PDT is capable of transferring data between projects that are located in various Oracle databases. As you can see, once loaded to OpenWorks, data and interpretation data can be easily transferred from project to project, bypassing the necessity for unloading and subsequent loading.

For the loading of seismic data in SEG-Y format, users are able to take advantage of the PostStack Data Loader feature (incomplete version of PostStack/PAL), intended for seismic data loading to Landmark formats—bricked file (.bri), compressed file (.cmp), 3-D vertical section file (.3dv), and time-slice file (.3dh), as well as for seismic data exporting from Landmark formats to SEG-Y. Full package PostStack/PAL contains a set of 45 possible seismic data processing operations. However, for interpretation project (IP) management and seismic data loading, the applications of PostStack Data Loader are quite sufficient. The primary goals of data manipulation management are:

Name scheme development for source data and format files; Creating general-purpose format files; Source data storage and archiving system development; Documentation on source data storage; Periodic audit and removal of outdated format files.

Data management applicationsSo far, we have covered OpenWorks database, the primary database of the Landmark classical package, and all of

the possible data that can be stored in it and actively used by applications, the necessity of a naming scheme for each data type, the capabilities for data manipulation in the OpenWorks environment, and the tasks facing data managers. It is important to remember that while OpenWorks database is the main database for applications, it also allows for some applications to have their own database. For example, Z-MAP Plus software creates files with metadata MFD, with graphical data ZGF, and many other files. These files can be included or not included in the OpenWorks hierarchy, but either way, the application creates its own database. GeoProbe software actively works with OpenWorks and SeisWorks data, but at the same time, creates its own hierarchy of directories, both with its own data and data converted from other applications. In this same way, ProMAX® software creates libraries of seismic data and so forth.

The main principles stated for an OpenWorks database are applicable to all possible geo-data and to each of the databases as well as the tasks of data management for a whole set of various geo-data, data storages, databases, project data, etc., as follows:

Development of a name scheme for each type of data Development of a data allocation system in a file system hierarchy Development of a storage system of source data Development of an archiving system of completed projects Documentation conducted about the data availability, receipt, and transmission


Fig. 9—The basic data flows of input and output from OpenWorks database projects. Landmark offers the series of utilities for data import and export, which help a user to transfer between applications working in the OpenWorks environment and other third-party applications and databases.


Data quality control on each stage of working with them Periodic data audit and the removal of mistaken, temporary, and outdated data Creation standard templates, lists, columns, colour maps, format files, etc.Irrespective of their size, the presence of various databases and data storages are observed by today’s oilfield

companies. Below are two primary goals: Creation of verified and reliable data that can be used as a basis for project creation; Integration of databases into one general interface for facilitated access to each element of data and for

effective data quality control.I have shown that for the first task solution, OpenWorks database, as a base, is the most appropriate option. For the

second task solution, as an aid for data managers, Landmark offers a whole list of applications for solving problems both within a working group and a corporation. The following sections discuss four applications, which are effective for reaching the primary goals of data management and meeting the general requirements of a medium-sized company.

Web OpenWorks (WOW)As previously mentioned in the beginning of this article, the primary goals of efficient data management include

the reduction of time spent on data retrieval required for making a business decision, the simplification of the search for previous interpretation data, and the completion of quality checks on the available data. These and many other tasks are solved by the WOW application. The WOW application allows access to data through the company intranet. The easy-to-use interface allows for the viewing and analyzing of data from all databases of such Landmark applications, including OpenWorks, SeisWorks, GeoProbe, Z-MAP Plus, ProMAX, CDA, VIP®, Asset Journal™, as well as the third-party application, Geolog.

It is remarkable that when viewing the application data, the applications that created these data are not being used. WOW program also has the capability of providing QC data and comparison analysis across multiple projects, which is especially useful for data managers. For OpenWorks data QC, queries and scripts are written on SQL, the set of which can be extended by existing script files. With the results of any query, the so-called reports, can be saved in Excel format. For graphic data, there is a converter ZGF to shapefiles (data format for ArcGIS) in the WOW program and a converter OpenWorks basemaps to KML (format for Google Earth).

WOW has many other valuable features. However, the most important feature is the efficient accessibility it provides to all geo-data available in a company network. This application is a valuable tool, not only for a data manager, but also for any expert, especially for upper-level management for whom it is important to view all of the geo-data of a company.

Corporate Data Archiver™ The importance of backing up this information is clear as soon as the first digital document appears. It cannot be

otherwise, as the data loss and inability to restore it quickly leads to severe losses. There have been cases in which commercial organizations that have experienced a loss of data have gone out of business. Many companies today make the decision to archive their data; however, archiving presents yet another problem: how, once archived, can the data then be found and restored? A highly-detailed description of the data can be found in the archival documentation, but this is not always the case, especially for the geo-data.


Fig. 10—Access to Z-MAP Plus data through the WOW interface. WOW interface easily solves many data management tasks and, among them, such tasks as joining data into one interface and even e-mailing to users the notifications about data updates.


Landmаrk offers users the Corporate Data Archiver™ (CDA) application, which only makes copies of the data on media for archiving. The CDA application creates an organized archive of the data as well as information and data from a particular activity, such as a field study or prospect evaluation.

CDA application organizes data into logical archives. For example, the archive can contain multiple geological and geophysical projects, Linux directories containing varied applications data, and documents from Microsoft Office from different shared folders. Thus, detailed “snapshots” of projects are produced, which are always accessible online, even after the archive is transferred to external media, such as tapes or disks, and removed from the system. Snapshots contain such extensive data in the archive that there is no need for restoration just to see the data.

In addition to the CDA program, with this application, OpenWorks, SeisWorks, Z-MAP Plus, GeoProbe, ProMAX, and VIP projects are archived, and snapshots of projects in a set of files in HTML format are accessible in WOW. CDA at the objective level creates the metadata in the Oracle database, but it is possible to work with application itself in Linux, like with the WOW application.

Asset Journal™Sooner or later, any

group, department, or company as a whole will realize the need for the creation of an electronic library of the documentation on geo-researches. As a result, Landmark recommends the Asset Journal easy-to-use application for creating documents in HTML format. Asset Journal application edits and operates all types of information, including common files, screen captures, tables, audio files, and images. Thus, Asset Journal application enables the creation of all possible documents and organizing them into libraries, including reports, procedures, atlases, presentations, notes, and notices. In addition, the ability to access Asset Journal projects through WOW software enables continuous access to company documents. Moreover, using this application while working on a project allows experts to prepare a report directly in an operating time.

PowerExplorer™If you work for a globally-dispersed corporation, as most modern oil companies are, or different databases for

geo-data are available, it is often difficult to centralize and identify dispersed information resources and knowledge, including the spatial data in files and databases, ESRI, or Landmark ZGF. In large companies, data managers need the capability to view data from different sources, saving information for the creation of basemaps and efficient transferring of information in a timely and cost-effective manner.

Let’s say, for example, that management needs to make an important decision regarding a particular lease and there is a deadline to find all information on this lease as well as its limits, say, a radius of 2–3 km. The problem becomes complicated when this information is contained in different company databases. PowerExplorer database is ideal for these types of situations. This package allows you to carry out this type of search quickly and qualitatively. The selected information arrives in the project, bypassing the tiresome and dangerous stage of exporting data to external files. Thus, the dilemma of centralizing the different databases and granting a common interface for search and transfer of this data for future research is resolved by the PowerExplorer application.

The PowerExplorer application is based on web technologies and contains the broadest capabilities for viewing and managing spatial and tabular geo-data. The application is capable of integrating every possible geo-data store, including OpenWorks, SeisWorks, Z-MAP Plus, CDS, MDS, ArcGIS, GeoFrame projects, etc. A user has direct access to the data from the database without the risk of duplication.


Fig. 11—Snapshots of seismic horizons in the Corporate Data Archiver application. The possibility of creating tiny images of seismic horizons, cubes, and lines renders CDA irreplaceable both for archiving and for an estimation of the data in the cleaning process.


Because the PowerExplorer application is capable of performing quick and effective searches of different geo-data, it provides unobstructed data exchange between various applications and, most importantly, gives data managers the opportunity to have complete knowledge about the available data for easy estimate and quality control.

Fig. 12—Window PowerExplorer application with data sample of the AOI. The Area of Interest Wizard allows users to easily create a geographical area with which they want to work and to operate them to add other sources of the data for display.

AfterwordIt is important to remember that only with a proper attitude towards information, no matter how small or large,

in combination with the use of these technologies, is it possible to be successful in data management. The success in data management, cost-based at first glance, will pay for itself in repeated profit through the reduction of errors in decision-making owing to incomplete or unreliable information. Experts can now spend their time working with the data rather than searching for them and trying to understand the degree of their reliability.

As a whole, the scale of a data management is huge. Challenges associated with data management are extensive and require efficient application toolkits for the most difficult customer needs. Using WOW, CDA, and PowerExplorer applications, Landmark offers users a whole spectrum of applications for data management that are interesting, multi-purpose, and effective in solving problems for large corporations; these applications include TeamWorkspace®, Reference Data Manager, Advance Data Transfer, Corporate Data Store, and PetroBank® Master Data Store™. These applications solve problems specific to that particular application and should not be used interchangeably. Altogether, they will allow for the creation of not only an effective data management system, but a degree of company satisfaction. The description of all Landmark applications for a data management is not included in this article, but detailed information about these applications can be found at www.lgc.com.

It is necessary to note that in addition to using these technologies and the availability of proper instructions for data management, through daily work, a keen interest in data management and in the capabilities of available applications, constant search for new decisions, innovation and enthusiasm in the business will lead to positive results.

If this article has proven useful to you, then it has succeeded in reaching its goal. Please send your responses on my corporate email [email protected], and I will be glad to continue the discussion on the topic of data management using the Landmark classical applications with you.

Reference



OpenWorks® Software Data Management. OpenBook June 2009, Release 5000.0.1.0 OpenWorks® Software Data Import/Export. OpenBook June 2009, Release 5000.0.1.0 OpenWorks® Release 5000.0.2.0 Data Model. OpenBook June 2009 “Corporate Data Archiver™ Software” data sheet, H05675-A4 03/10 “PetroWorks® Asset Software” data sheet, H04854-A4 03/08 “PowerExplorer® Software” data sheet, H04857-A4 01/08 “WOW™ Software” data sheet, H05653-A4 03/10

All trademarks and copyrights referenced in this article are property of their respective owners. All rights reserved.
