The utility in all Java-based OpenWorks^® Data Managers, Tools > Listen to OW Session Changes, allows you to launch different data managers across projects (ALL_DATA or Interpretation Projects that may or may not overlap) from the same OpenWorks software session for comparison and decision making.

• In Project Status, set the OpenWorks Project to Proj A. Launch Seismic Data Manager and display some 2D data.
• Seismic Data Manager > Tools > Uncheck “Listen to OW Session Changes.”
• Set another project (Proj B) in Project Status.
• Launch Seismic Data Manager again and display some 3D data for Proj B.
• Sesimic Data Manager > Tools > Uncheck “Listen to OW Session Changes.”
• Set another project (Proj C) in Project Status.
• Launch in Well Data Manager for Proj C.

Note: The active project is shown in OpenWorks Launcher and the Pointing Dispatcher-enabled data manager will have a green border. The following image shows that four different data managers are launched from different projects from the same OpenWorks session.

This utility also allows launching same data managers with different measurement systems.

No related posts.

In some cases, you will need to install both versions of Landmark Drilling Applications on the same computer. Here you can find some tips to make it easier.

If you have previously installed Engineer’s Data Model^TM 2003.21, remove Landmark Software Manager (LAM) 2003 before installing R5000. To do this, use “Add or Remove Programs” from the Microsoft^® Windows control panel. (Don’t forget to backup your license file.)

After that, make sure that no LAM registry entries exist in Microsoft Windows. Use Regedit to find out.

Now, follow the steps below.

• Expand HKEY_LOCAL_MACHINE by clicking on +.
• Expand SOFTWARE by clicking on +.
• Expand Landmark Graphics Corporation by clicking on +.
• Select LAM.
• Press delete key or select delete from edit menu.
• Confirm key delete by pressing “Yes” button.

And repeat for HKEY_CURRENT_USERS.

You can now start the R5000 installation by first launching the Engineer’s Desktop (EDT) 3rd-party components.

In this part of the installation, the Engineer’s Data Model (EDM) R5000 software will install LAM 5000.

After that, continue installing EDM and EDT R5000 to complete the installation.

If you don´t have EDM 2003.21 previously installed, it becomes easier, you can install it as normal.

Don’t forget LAM 5000 can handle both licenses (R2003 and R5000), but LAM 2003 can´t handle an R5000 license.

Enjoy R5000!

No related posts.

Migrating Existing Projects

For 5000.0.0, the GeoProbe^® software data directory structure has dramatically changed to allow for a more thoughtful handling of multi-survey objects. Older vintage projects must be migrated to follow this directory structure. Beneath the top-level OpenWorks^® or GeoProbe software project, GeoProbe objects are now separated based upon whether they exist on a project or survey level. By making this change, the same horizon or fault can now extend from one survey area, or 2D line, to another. In addition, state files now encompass all objects within a project and are no longer restricted to only saving objects or a survey-by-survey basis.

As more GeoProbe objects are converted to honor world coordinates in future releases, they will eventually move out of the individual survey directories into the project directory. Currently, objects that can span multiple surveys include horizons, swFaults, 2D data, TSurf and AGF files.

In previous releases, the GeoProbe working directory was based on your shortcut name. This directory could be located anywhere on your system for GeoProbe projects and under the SeisWorks directory for OpenWorks-connected projects. In 5000.0.0 and moving forward, this working directory has been uncoupled from the shortcut name and better aligns with the OpenWorks 5000.0.0 data model.

GeoProbe-only projects can still be located anywhere on your system, but now the working directory can be any name of your choice, with the project and individual survey directories beneath it. For OpenWorks-connected projects, the working directory defaults to be under the connected OpenWorks project in OW_PROJ_DATA, but this can also be anywhere on your system.

Understanding Project Directories

Project Subdirectories
Beneath the GeoProbe Working Directory are directories for both the project-level objects as well as survey-specific objects. As one project may contain multiple surveys, data objects contained on a project level are those that can encompass the entire project space. The graphic below describes where data object directories for a particular project are located (in this example, an OpenWorks-connected project).

All previously created GeoProbe projects must have their data objects copied into a directory structure that matches this format. In almost all cases, this simply involves moving the Object directory (e.g. volumes, faults, swFaults) under the project directory or the appropriate survey directory. However, you’ll notice that there is a Horizons directory on both the project and survey level. Old horizons, of *.hzn extent, should be copied into the survey-level directory. These horizons are still valid for loading into the GeoProbe session, but should then be saved in the new format of *.mzn as described in the following section.

Horizon Directory Structure

As a single horizon can be interpreted across multiple surveys and 2D lines, this has necessitated the use of a tiered directory structure to save such a horizon to the GeoProbe working directory. New horizons in GeoProbe are saved in the following manner.

• A master index file, called .mzn will be created in the project/Horizons directory. This ascii file will point to the individual surveys and lines and their applicable horizon pieces. When loading the horizon from disk, the Horizon Load GUI will search for this file.
• Under each 3D survey, there will also be directories called /Horizons. Here will be the actual binary horizon interpretation files for the parts of the horizon that fall in that survey’s boundaries. These files will have the format of MZN.mzn.
• Portions of the horizon that are interpreted on 2D lines are saved in the project/Horizon2D directory. Under this main directory will be a directory with the same name as the horizon. This secondary directory will then contain a series of *.xml files, which will retain the naming convention of the 2D lines on which each horizon piece was interpreted.

In the example below, we have interpreted and saved a horizon called Green across two surveys and three 2D lines in an OpenWorks connect project.

Merging Existing Horizons and Faults

Follow these steps to migrate existing GeoProbe horizons to the new 5000.0.0 format and to merge horizon pieces into a single horizon object.

1. For the same horizon interpreted in multiple surveys, copy or move your *.hzn files into the appropriate survey directories for your project.
2. In GeoProbe, load these individual horizon pieces into the session.

3. Highlight the horizon pieces, and click Merge. Using this dialog, merge the pieces into a single, new horizon.
4. Save the new horizon. The next time you load this single horizon, you have the choice of either loading the horizon for the entire project or only the part of your survey of interest.

Follow these steps to merge swFault segments into a single, multi-survey swFault object.

1. In GeoProbe, load the same fault interpreted in multiple surveys – in this example, fault_a and fault_b.
2. With fault_b highlighted, click Interpret to launch the swFault Interpretation dialog.
3. Unassign the segments in fault_b.

4. From the swFaults Object Manager, highlight fault_a and highlight Unassigned segments.
5. In the swFault Interpretation dialog, click Assign.

6. The two faults are now merged into one. Save the swFault.

Related posts:

1. Upgrade GeoProbe Projects Not Connected to OpenWorks
2. Horizon Upgrade and Interpretation Projects in R5000
3. Framework Building with ezModel in GeoProbe R5000

You should be aware of several things when installing Engineer’s Data Model^TM (EDM) Engineering Project Database Software R5000. These tips can make your life easier and will help get you started right away using this tool.

General Tips

• Wellcat is no longer an island, but is now part of EDM.
• SQL2005 replaces MSDE. This also aligns with the Drillworks suite, which has been using this for a while.
• If you have R2003 apps installed on your system, remember to uninstall LAM2003 and delete any traces of it from the Microsoft Windows registry. You should then install LAM2005 and also generate a corresponding R5000 license. If for some reason you plan to install R2003 and R5000 apps at the same time, there is no need to install LAM2003.
• Importing .XMLs from previous R2003 apps works fine. But the other way around is not recommended.
• You can use R5000 in a Microsoft Windows 7 environment from 5000.1.8.

Tips for Backing Up and Attaching Database Files for EDM R5000

Think about this scenario: You are heavy Wellplan user with a vast BHA and Fluids library and a number of customized workspaces and catalogs. Backing up all these data types could be painful, depending on how you do it. You could export individual .XMLs files for each type of item, but this takes time, and in my opinion, keeps most people off the safe practice of backing up files frequently.

Instead you can speed the process up dramatically. Go to the database folder (C:\Landmark\EDT_5000.1\EDM\Databases) and copy the .MDF and .LDF files. You could ZIP those if you want and put them away for when you actually need them. That’s when it gets interesting; here is a suggested sequence of steps to follow when trying to attach a database file for EDM R5000 using SQL 2005.

Before, you go any further, please remember to always work with copies – just in case something goes wrong, you will always have a way out.

• Using the SQL Server Management Studio Express 2005, eliminate the current database.

• From Microsoft Windows, add the SQL user with full rights on the database files. Use the original files as a reference.

• Copy the database files to the corresponding route.

• Attach the database files.

• Run a query to unlock the EDM user in the EDMDB database file, so you can start working.

Have a good time with R5000!

No related posts.

Use this procedure to upgrade your GeoProbe^® only flat-file data structures that are not connected to OpenWorks^® software. The user will be able to access any object stored in OpenWorks directly from OpenWorks after the OpenWorks project has been migrated to R5000.

Pre-conversion Data Survey
1.  Determine which surveys fall within the same Interpretation Project. These surveys must be moved under the same top-level project directory.
2.  Make lists of horizons and swFaults for each survey to be migrated.
3.  Make a master list of the horizons and faults common to multiple surveys that need to be merged.

Copy Directories
4.  Create a new directory to hold the converted data.

/top_level_interpretation_project

5.  Create a project directory under this directory.

/top_level_interpretation_project

6.  Copy over survey directories containing GeoProbe software flat files.

Update data
7.  Run GeoProbe and create a shortcut for the new top-level Interpretation Project. All necessary directories will be created by GeoProbe.
8.  Merge cross-survey horizons.
9.  Merge cross-survey swFaults.
10.  For R5000.0.1.0, load wells from the survey directories and resave. These wells will now be world-coordinate objects stored in the /project directory. The old wells can be deleted after the new well files are confirmed to be correct.
11.  For R5000.0.1.0, GeoProbe shapefiles (*.iv) can be loaded from the survey directory. The load toggle specifying the coordinate framework (world or survey) must be set correctly.

Related posts:

1. Tips for Managing Your GeoProbe Projects in R5000
2. Horizon Upgrade and Interpretation Projects in R5000
3. Framework Building with ezModel in GeoProbe R5000

How to convert latitude and longitude to X and Y values and vice versa

When data is exported, an appropriate cartographic reference system (CRS) for export is selected. This may or may not be the project CRS. If the CRS does not exist in OpenWorks, it can be created within the Map Projection Editor. If the project uses a different CRS, the Well Data Export utility converts the data from the project CRS to the specified CRS at export time. When exporting location data or transferring it to another project, the data is saved back to the orig_x_lat, orig_y_lon, and orig_crs_id fields.

Will changing the CRS name in Well Header allow OpenWorks^® R5000 software to run a cartographic conversion?

No, cartographic conversions only occur during data load. After the well is already loaded, changing the original CRS name in Well Data Manager will not modify the latitude/longitude or X/Y coordinates. If this information needs to be modified for an existing well, it is best to reload the correct data and allow the loader to overwrite the well header information.

Data storage and load

When you create an OpenWorks project, you specify a corresponding CRS to use when storing and calculating project map data. This is called the project CRS. The project CRS is usually the one most often used in the area of the world in which you’re working. Raw data will not always be available in that particular CRS. When you load data, you specify the CRS used when the data was recorded. If the CRS corresponding to the data is not the same as the project CRS, and it does not exist in OpenWorks, you should create it in the Map Projection Editor before loading the data. After you indicate the CRS corresponding to the data, the ASCII Loader converts the data to the project CRS at load time. This means that all data is stored in the same cartographic units.

When loading any location data the original input values will be saved in the orig_x_lon, orig_y_lat and orig _crs _id fields. These values may be either lat/lon or X/Y depending on the original data. The orig _crs _id field will indicate either a projection coordinate system (projection CS) or a geographic coordinate system (geographic CS) accordingly.

Related posts:

1. Cartographic Reference System Transform Changes in OpenWorks R5000

Structural and stratigraphic traps have traditionally been a challenge to accurately image. The ezModel™ module in GeoProbe^® R5000 software can help you build a structural framework based on faults and truncated surfaces. An ezModel interpretation allows the generation of complex structural models for salt and other complex structural environments.

1) Create a Fault Network

Define and identify relations between the faults (cross/cut).

2) Import Horizons into the Model

After generating the fault network, import horizons into the model. The example horizons shown here are autochthonous salt and the Upper Jurassic Kimmeridgian. The goal is to truncate the Kimmeridgian against the salt body where it pierces the anticline so that you can determine if the two horizons are conformable or not.

After both horizons are loaded, they will cross each other. Below you can see the intrusion of a salt body crossing the Upper Jurassic Kimmeridgian anticline because you haven’t established a relationship between them.

3) Define the Relationships between the Surfaces

Define the relationship in the Type tab where we will change the surface from conformable to unconformity. The Kimmeridgian anticline is conformable and the salt body is unconformable.

The conformance between the horizons now shows how the Upper Jurassic is limited by the salt body and how the horizons are limited by the previously created fault network.

4) Visualization and Creation of Reverse Fault Polygons

In the example below, we can see a reverse fault under an overthrust block.

Now fault polygons can be created from reverse faults just as from normal faults.

5) Results

This methodology will provide a complex structural model from a good interpretation.

Related posts:

1. Tips for Managing Your GeoProbe Projects in R5000
2. Upgrade GeoProbe Projects Not Connected to OpenWorks

Landmark recently announced plans to release OpenWorks^® 5000.0.3.0 on Oracle 11g only. Based on customer feedback, Landmark has extended OpenWorks 5000.0.3.x to include release on Oracle 10g, enabling customers more flexibility in their planning and timing for moving to OpenWorks on Oracle 11g.

Landmark will now release OpenWorks 5000.0.3.x on both 10g and 11g as described below.

Related posts:

1. Benchmarks Available to Help Tune Oracle Server for OpenWorks R5000
2. Oracle Tips

Many customers are planning R5000 upgrades in anticipation of their adoption of DecisionSpace^® Desktop software, leading to such questions as: How do we begin? Show me the best practices? Who is using R5000 now? Who do we contact for help?

If you’re among the customers ready to get started with R5000, this article highlights the most important aspects to consider for initiating and planning your R5000 Upgrade Project.

For this discussion, let’s assume that your organization has already made decisions about sponsoring the project and defining roles and responsibilities for the project team. This could include organization roles like the project sponsor normally assumed by the PMO, E&P or IT organizations. And you, as the project manager have been assigned the responsibility of managing the project for the organization.

Defining the initial scope, resources and stakeholders are some of the activities that as project manager you should complete in the process of initiating and planning the project. In the case of R5000, and specifically in defining the scope, some decisions will need to be made around:

• The selection of the projects to be upgraded (active and inactive projects);
• How basic or extended the data cleanup process and data standards designs and definitions should be;
• The inventory of the current applications;
• The current and future IT infrastructure;
• Type of resources needed;
• The project approach and implementation strategy.

The selection of the projects to be upgraded (active and inactive projects)

When selecting the active OpenWorks^® and SeisWorks^® software projects to be upgraded, it is important to keep in mind that a prioritized project schedule should be done based on business objectives. For example, you might not want to upgrade the OpenWorks and SeisWorks projects being used during a deep water well or lease sale deadline. Also, some organizations share OpenWorks projects data with other partners, and when building the project upgrade schedule, take into account this business dependency as well. You do not want to leave your organization’s partners isolated from the business by upgrading the project in your environment only – remember that R5000 is not backward compatible. An initial conversation with the organization’s partners about your plan to go to R5000 will help them anticipate making any change (upgrade) to their Landmark environments, too. Regarding the OpenWorks and SeisWorks inactive projects, these could be upgraded in a separate R5000 Upgrade Project or just added as an activity to be executed right before closing the R5000 Upgrade Project. 

A common question is “Should inactive projects be archived in R2003 or upgraded to R5000, and then archived?” The recommended approach is to run the PreR5000 tool, make the necessary cleanup, upgrade to R5000, and then archive. Although it is possible to upgrade a R2003 backup directly into R5000, if data errors are found during the upgrade process and the R2003 environment is no longer available, it will be difficult to correct the data errors in the R2003 project.

Basic or extended data cleanup process and data standards designs and definitions

As recommended in the article R5000-Where Do I Start?, the R5000 data migration starts with a general analysis of the R2003 projects and seismic data. A set of mandatory and optional data issues are reported by the Landmark utility. Data managers should decide whether to only solve the mandatory issues or the optional ones as well. Mandatory issues need to be solved before upgrading to R5000 to avoid upgrading errors due to data conflicts. The analysis of the reports coming from the Landmark utility is going to give you a good an idea of how much effort (time and resources) is involved in the data cleanup process. In some small organizations – let’s say with less than 20 OpenWorks projects – the mandatory data cleanup process may take between 10 and 15 days (estimated). Keep in mind, that time effort can vary depending on the data conditioning on each OpenWorks project. Some organizations have decided to leave the optional data cleanup process to be done after upgrading to R5000 and closing the Upgrade Project.

The following are the mandatory data issues to be solved before upgrading the projects to R5000.

1. Master projects duplicate horizon files per master
2. Master project duplicate seismic files per master
3. SeisWorks 2D line data with possible upgrade duplication
4. SeisWorks 2D lines with seismic data across multiple masters
5. OpenWorks projects in multiple districts (long)
6. OpenWorks projects in multiple districts (short)
7. SeisWorks projects in multiple districts and different OpenWorks projects
8. SeisWorks projects in multiple districts and same OpenWorks project
9. 2D lines with horizon files with incorrect size
10. OpenWorks 3D surveys with inconsistent navigation to SeisWorks
11. SeisWorks 3D projects without an OpenWorks survey

Data management standards will need to be designed for managing OpenWorks data. Standardization is recommended around the naming of OpenWorks projects data bases, Interpretation Projects, coordinate reference system, districts, Interpretation IDs and horizons, and in some cases, you may also need to create usage standards. This is a good time to think about rationalizing OpenWorks, SeisWorks and Master Projects, as well as districts, SIDs and users accounts. All of these activities require time for design, planning, data management expertise and lot of interaction with the data managers.

The inventory of current applications

The most important thing about the Landmark applications inventory analysis is to ensure other vendors’ applications are R5000 compliant. The Landmark SDK program has been successfully driving R5000 integration with customers’ vendor applications. However, involving the applications vendors’ representatives soon (during the planning phase) will give you enough time to determine their compliance, complete applications integration tests and achieve end-user acceptance criteria, helping to ensure the business continuity after upgrading the OpenWorks projects to R5000.

The current and future IT infrastructure

Analyzing IT inventories will help you determine if a hardware procurement process should be put in place or at least if some hardware refreshment is necessary in your IT infrastructure environment for the upcoming R5000 implementation. Make sure the hardware changes and upgrades you plan meet the R5000 compatibility requirements. Review your applications inventory and system requirements as per the Landmark product supported platform specifications. At the end, what we all look for in a computer system is a better performance, so make a good selection of hardware, and see your Landmark representative for the latest recommended platforms.

Type of resources needed

What type of resources should you need to execute this Upgrade Project? An R5000 Upgrade Project involves several roles that participate along the execution of the project – project sponsor, project manager, technical leaders, data managers, system and OpenWorks administrators, trainers and support are the roles you will need to execute the project. Small organizations have succeeded in their R5000 Upgrade Projects by assigning seismic data managers with project management skills to represent some or all of these roles. In large organizations, the situation can be quite different since they can have different resources assigned for each of the roles.

The project approach and implementation strategy

The best practice for the R5000 implementation strategy has been planning an asset-by-asset rollout and making sure you have accomplished the end-user acceptance criteria on that asset before moving to the next asset in plan. However, some organizations have made successful deployments by rolling out two or three assets at the same time and having a good project plan, experienced and skilled resources, and a quality plan in place. The deployment plan should be designed to avoid business disruptions, so it is recommended that the OpenWorks and SeisWorks projects upgrade process is made during weekends, Fridays or overnight. System administrators and end-users should be well trained on R5000 before they start to use the upgraded projects. It is recommended that end-users start working on the new R5000 environment as soon as they leave the training room. Training is one of the most important pieces of this Upgrade Project and a fundamental key to your change management plan.

An R5000 Upgrade Project has a phased approach: Preparation, Training and Deployment. In upcoming articles, I will write about the key aspects of every phase when monitoring, controlling and executing an R5000 Upgrade Project.

If you take into consideration the aspects mentioned in this article, you are ready to build a good project plan to upgrade your Landmark environment to R5000. Please do not forget to include in your project plan the following project management components as well:

• Communications Plan
• Quality Plan
• Change Management Plan
• Risk Mitigation Plan

You may want to contact your Landmark representative to request the R5000 Upgrade Project Planning tools that Landmark has developed for the R5000 Upgrade Projects. These tools are based on R5000 Upgrade Projects lessons learned and best practices. The Project Plan, Project Charter, Project Schedule, Work Breakdown Structure and Dictionary and other tools are available via your Landmark account manager.

No related posts.

There are many fine tools for viewing OpenWorks^® R5000 project data spatially and for performing GIS operations, e.g. DecisionSpace^® Desktop and PowerExplorer^® software, not to mention various GIS products like ESRI’s ArcView. But sometimes, as an end user or data manager, all one really wants to do is take a quick peek at an OpenWorks project in a map just to see what’s there, without needing to perform any complex GIS analysis.

This is where Google Earth, and to some extent ESRI’s ArcGIS Explorer, come into their own: these are consumer-oriented ‘Earth browser’ tools, and their main advantage – other than ease of use – is that they come with licensed imagery and cultural layers to provide a rich visual mapping experience¹.

Landmark’s WOW^TM software provides tools to make integration with Google and ESRI easy: there are command-line and GUI utilities to create .kmz files from OpenWorks well, 2D line and 3D survey data. These .kmz files are in fact .zip files containing a .kml² file with spatial information, and associated image files for well and other symbols. In fact, the WOW server can be used to stream spatial content to Earth browser software via a network link. A related utility can also write shapefiles³ for use in ESRI and other GIS products.

The screen capture below illustrates the simplicity and clarity of mapping in Google Earth, with data objects visible and selectable. Overpost resolution is particularly good. Combined with the ability to toggle on or off display of individual or groups of features, and to link back to WOW, this makes Google Earth and similar apps an excellent choice for simple spatial visualization.

Notes:
¹ Although free, and freely downloadable, check the license terms before using these products commercially or for publishing images from these products.
² KML is an international standard XML-based file format used to display geographic data in an Earth browser. See http://en.wikipedia.org/wiki/Keyhole_Markup_Language.
³ Shapefiles are commonly used for storing geospatial vector data for use in GIS systems. See http://en.wikipedia.org/wiki/Shapefile.

No related posts.