Data Management Preparations for R5000

Transcription

1 Data Management Preparations for R5000 The changes in R5000 are insidious and in many cases rather complex. In this presentation I will simplify things and present things rather black and white. This is partially to keep things simple so as not to confuse, but is also because some of the fine details of R5000 is still being polished ;-) 1

2 Why do any preparation? Some cleanup may be mandatory for the upgrade to work Seisworks projects no longer exist worth thinking about how to create your seismic interp n env in OpenWorks. Tremendous potential to do much better than a 1:1 migration of your existing projects. Horizons with same name in multiple projects with different horizon attributes > conflict when migrating 2

3 What Opportunities? Horizon & Seismic Cataloging Seismic horizons related via stratigraphy to attribute horz Merge existing projects to large Project Databases Multiple Interp n Projects reading ONE version of : Nav and trace data Well data Logs Faults Change data in one intp n project and all other listening intp n projects on that project database will be automatically updated 3

4 2003 and R5000 project maps Before discussing the DM issues I will set the scene by giving a short description of the R5000 environment. I will use project coverage maps to illustrate the differences between OW 2003 and R5000 data storage architecture. As with much of this presentation the maps are provided by Landmark. 4

5 Current Project Model Before R5000 P1(UTM54) P2(UTM55) Currently (pre R5000) users create multiple projects for data in a region, this results in data duplication and a high cost of maintenance (updating/synchronizing a well that is in more than one project, etc) This situation is a consequence of many factors, For example: Limitations in OW and applications to work with data in different cartographic reference systems, Poor performance of large datasets Data management applications that do not allow managing large datasets efficiently (e.g. creation of lists), Lack of information (some people have created an OW project for each seismic survey they have), etc. 5

6 New (R5000) Project Model Interpretation Projects in R5000 GIPP54(UTM54) GIPPSLAND (UTM 55) One project database covers the whole area. Users can create interpretation projects in different CRS. When reference data is updated in the interpretation projects, the master project also gets updated. The interpretation projects are VIEWS on the project database NOT copies of the data. Benefits include: -Less data to manage (update/synchronize) -Flexibility (users can see data and report results in different CRS -Security (an Interpretation project with one or a few wells can be created and access granted to a contactor) 6

7 R5000 OpenWorks Project Model Interpretation Project 1 View Interpretation Project 2 View Interpretation Project 3 View Interpretation Project 4 View Project Database Original CRS Shared Data: Wells Logs Seismic Data Horizon Catalog 2D Horizons Picks Reference Values OW Master Project Project Database Interpretation Project Project CRS List of Lines/Surveys List of Wells Unconstrained Views Constrained Views 1. Earth Models, Grids, Contours, Pointsets, SW Fault Polygons & Trimesh 2. Fault Segments, Control Points Seismic Seismic DataSet DataSet Files Files 3D 3D Horizon Horizon Flat Flat Files Files This is an alternative way of representing things. The data is stored once in the project DB and can be seen by one or more interpretation projects. Each of the intn projects can have a different CRS even if they are looking at the same data. Each interp n project is defined as a combination of coordinates, well list, line list, survey list, etc. 2D horizons are stored in the DB 3D horizons are stored externally but catalogued in the DB Trace data is external to the DB 7

8 Project Database vs. Interpretation Project Project Database Interpretation Project Here we see a simple example of a shot point map from the project DB and a subset of the data as seen by an interpretation project. Again, in gross terms what you see in the interpretation project is a VIEW on the data stored in the project DB the data is not actually stored in the interp n project. Any correction/updates to the data in the proect DB will automatically be seen in the interp n projects. NOTE: Depending on how the interp n project was defined, additions to the data stored in the project DB may not be seen in the interp n project (eg data outside the AOI of the interp n project ) 8

9 Overview of Interpretation Projects Any number of Interpretation Projects can be created within a single Project Database. They share data dynamically, not via a copy User access is controlled at the Interpretation project level Enhanced security through limited data visibility Automatic, dynamic cartographic conversion in API Much of the data duplication associated with our current model is eliminated This all sounds good.. But it has some profound consequences for the data that we currently have stored in OW

10 What can be Prepared? Run Landmark s s prer5000 Merge existing projects to large Project Databases Prepare ONE version of : Nav and Trace data Well data Logs Picks Well/wellbore Interpreters Landmark s prer5000 module can audit the status and indicate things to clean up. You have time now to merge the relevant projects in a controlled manner prior to running the upgrade scripts. -Doing it now, while the before and after projects are on the same model, makes it easier to QC the results. -Where you do not want to merge the projects now you should still homogenise your data so that you have only one version of line names, well_uwi s, log mnemonics, etc R5000 supports the well/wellbore model. Ie a Single well header (well_location) for multiple wellbores(well_master) - closer to the EDM model. This data can be stored in OW now. -Clean up data_source in preparation for Interpretation ID model (membership of groups) new internal identified Oracle users. 10

11 The broken Record Prepare your standards Log mnemonics Stratigraphic columns (for picks, horizons, etc) Clean your data to comply with your standards Logs Picks Grids Faults Identify your corporate (QC( QC d) ) versions Organise your interpreters (data_sources( data_sources) Build your merged projects (where desired) The title is for any Monty Python fans ;-) With R5000 it is critical that you have a much higher level of consistency than most companies have today. Today you can survive with duplicate data in different OW projects where the well names/locations are slightly different, or any of your standards (logs/picks/company names/etc) are slightly different, - obviously putting all of these variations into one project is just going to make life difficult for the G&G staff and dramatically increase your interpretation risk. 11

12 How to Prepare Run prer5000 Run Audit_Report Distribute your standards to your projects Curve dictionary transfer Ref data distribute Identify non compliant data and cleanup Log data manager Strat cleanup Horizon data manager Fault data manager Identify duplicate data /merge projects Project compare Nav compare My first bullet on this slide suggests that part of your preparations should be to run the PreR5000 utility. 12

13 PreR5000 Report Utility This is a Landmark utility that will be supplied with R5000. I don t know how much of this you can actually read, but the utility consists of a huge collection of SQL scripts that you can run against each of your 2003 projects and generate a very detailed set of reports about what would happen to your data if you upgraded to R5000 with the data as it currently is in the 2003 project. It removes all of the guessing of what data will upgrade correctly and what might/will cause problems. 13

14 PreR5000 Report Batch Reviewing results using prer5000report where there are many OpenWorks projects can be cumbersome prer5000reportbatch executes all queries against all projects, producing a hyperlinked set of html pages for rapid browsing Once generated, reports are completely portable and can be linked into WOW, or zipped up and sent for offsite analysis Can also play a role in post migration QC Another way at looking at things. Very Detailed listings of things to fix. NOTE what happens if you do NOT clean up! The reports give you an excellent, detailed review of what needs to be done.. It is still up to you to get the work done. 14

15 How to Prepare Run prer5000 Run Audit_Report Distribute your standards to your projects Curve dictionary transfer Ref data distrubute Identify non compliant data and cleanup Log data manager Strat cleanup Horizon data manager Fault data manager Identify duplicate data /merge projects Project compare Nav compare The rest of the bullets are conceptually obvious the challenge is actually doing it. ;-) We, and our existing customers, obviously feel that you can make life much easier for yourselves by using RoQC Tools for doing this cleanup (and for managing your OW environment generally). I am not going to show any of our tools in this presentation if you are interested in seeing what we can do for you, please book a demonstration, either while you are here or when you return to work. For those that are interested I have a demonstration setup with me in the hotel. 15

16 Upgrade/Migration QC maximum Before-Expected-Actual audit for every single data record Level of Migration QC middle-ground The R5000 migration software didn t crash minimum 16

17 Data Management Preparations for R5000 Questions? 17

18 No More Seismic Projects - What does this mean? Seismic interpretation related data will be accessed through an OpenWorks project perspective Seismic oriented applications will have access to any 2D/3D data No more OW_PMPATH, plist.dat, plist 18

19 Does all data go into Oracle? 2D and 3D seismic will continue to be stored as flat files external to Oracle 3D horizons will continue to be stored as flat files Color maps, format definitions, etc. will also continue to exist as files 2D horizon data will be stored in Oracle 19

20 R R5000 Wells, Fault plane, segments, control points, heaves OpenWorks Project OpenWorks Project Database Wells, Fault plane, segments, control points, heaves, horizon catalog, seismic catalog, 2d horizon data OW 3D Survey fl3d_nw OW 3D Survey fl3d_nw Survey Directory name - fl3d_nw SW Project Create Copies OW Survey to define SW project OpenWorks IP Create from 3d survey Seismic trace data, 3d horizons uses dir.dat SW Project fl3d_nw - standalone OpenWorks Interpretation Project FL3D_NW Horizon Catalogs, Fault Trimesh,, Grids Seismic trace data, Horizons, Map data, control files uses dir.dat SW Project Directory fl3d_nw OW Interpretation Project FL3D_NW Directory Session, map, control files uses owdir.dat 20

21 R R5000 Wells, Fault plane, OpenWorks OpenWorks Project segments, control points, Project Database heaves Wells, Fault plane, segments, control points, heaves, horizon catalog, seismic catalog, 2d horizons vectors OW 2d Lines Not 2d Survey OW 2d Lines Not 2d Survey Line Directory name lgc_master SW Project Create Copies OW 2d lines to define SW project OpenWorks IP Create from 2d line list Seismic trace data, 2v2 uses dir.dat SW Project fl2d - standalone OpenWorks Interpretation Project FL2D Horizon Catalogs, Fault Trimesh,, Grids Seismic trace data, horizons in master area, Map data, control files in project area, uses dir.dat SW Project Directory fl2d, master area lgc_master OW Interpretation Project FL2D Directory Session, map, control files uses owdir.dat 21