7. Managing Coordinate Systems
7.3 Considerations for Creating a Custom Coordinate System
Schlumberger Public
7.3 Considerations for Creating a Custom Coordinate System
Creating a custom coordinate system makes the Petrel project dependent on the source project in which the coordinate system definition resides. That project should not be deleted nor should the definition be changed arbitrarily.
Future upgrades of Petrel projects would migrate to other systems, which might not be automatically upgradable from the Mentor custom coordinate system. To prevent problems, the custom coordinate system parameters should be extensively documented in a system outside Petrel. Items to consider documenting are – 1. Petrel project names
2. OpenSpirit session information
3. Underlying OpenWorks project information 4. Actual coordinate and datum information
8.
Schlumberger Public
they can publish their results back to the Reference Project for the rest of the asset team to use.
The important thing to note is that object references that occur in a Petrel project (such as log tracks belonging to a well, horizons belonging to a model, and faults belonging to a workflow) are not disturbed by continuous movement across User and Reference Projects. Thus, Users can easily and frequently rearrange objects.
The Reference Project Tool uses the Petrel GUID to identify that a data object is the same between two projects. The Reference Project Tool does not do a
matching on data-item attributes, such as Well Name, Unique Well Identifier (UWI) etc.—only the GUID is used. The GUID of a data object stays the same when:
1. The data is copied using the Secondary Project (Petrel 2005) or the Reference Project Tool (Petrel 2007.1)
2. When the project is saved under a new name (Save As)
3. When the project is cloned on disk (copy/paste using Windows) 4. When data is moved inside the project from one folder to another
This Deployment Guide discusses how to configure Reference Projects for your Asset Teams and best practices around Reference Project use. For more on using the Reference Project Tool, refer to the Petrel Online Help.
8.1 Managing Reference Projects
Reference Projects are best managed by following a few simple guidelines:
Host the Reference Project on a shared network drive.
Designate a specific role to administer the projects.
Share the tree (use template projects).
Use the Reference Project only as a repository; do not use it for actual work.
Back up the Reference Project since there is no User authentication or revision history.
Use in a multi-domain environment to lessen the risk of overwriting data.
Use in small groups (four or five Users) to lower the chance of scale and data conflict.
8.2 Creating a Petrel Project Network
You can create Reference Projects by many methods, and this guide will discuss some options and lessons learned in the creation and use of the various methods.
Schlumberger Public
Petrel projects in the same coordinate system can be seen as a “Petrel Project Network”. This network is illustrated in 3Figure 12.
Figure 12: Petrel Project Network
The Reference Projects are the single point-of-entry and master repository for
“asset” seismic and well-related data. The Reference Project is stored on a common disk with read-only access for normal Users.
The Load Projects are temporary (or transient) projects used to populate the Reference Projects. They contain data from Petrel 2005 projects, secondary
projects, or data from OpenSpirit-enabled data sources. Load Projects are used for efficient quality control and realizing of seismic data.
The Work Projects extract seismic and well-related data from the Reference Project using the Reference Project Tool. Work Projects are open to local loading activities, but this should not be done with data that should have gone into the Reference Project.
The Results Project can be utilized to efficiently capture results from the Work Projects and to exchange data between Users working in the same geographical
Load1 Load2 Load3
Schlumberger Public
area. The Results Project must contain all “asset” seismic definition and well-related data loaded from the Reference Project.
8.3 Creating Reference Projects
You have the option of creating different kinds of Reference Projects with Petrel.
If you choose to create different types of Reference Projects, you can then enforce security permissions around those data types. You will need to do this manually through Windows Explorer by changing the permissions of the .petR file.
Some examples of Reference Project types are shown in Figure 13.
Figure 13: Examples of Types of Reference Projects
As Figure 13 suggests, you can create a Reference Project for seismic data and a Reference Project for wells per coordinate system, or you can combine those two types of data in a single input Reference Project that contains the seismic data, wells, logs, markers, etc.
You can also create a single Reference Project for final versions of interpretations and models, or combine that data with a Reference Project that contains all non-seismic data.
As a final consideration, you can create a Reference Project that captures data from other Reference Projects and acts as a milestone representation for backup and legal purposes.
Contains results and is used as a backup for management and legal purposes
Contains all input data, such as seismic data, wells, logs, markers, etc.
Contains all non-seismic data, such as input wells, interpretation and models.
Contains results and is used as a backup for management and legal purposes
Contains all input data, such as seismic data, wells, logs, markers, etc.
Contains all non-seismic data, such as input wells, interpretation and models.
Schlumberger Public
The types of Reference Projects that will work for your deployment depend on the scale and volume of your Petrel data. You may not require separate Reference Projects; instead, you may need to create a single Reference Project to act as the master repository. The amount of your Petrel data and the business rules that govern your data management environment should act as guidelines when deciding on which Reference Projects to create.
Creating a set of Reference Projects adds to the complexity of managing the environment but assists you in assigning access rights.
Reference Projects do not have more data storage capacity than other projects. They may have more practical storage since performance
considerations are not in effect, but they have no greater absolute capacity.
8.3.1 Restricting Access via Access Rights
Each project has its own access rights. By separating wells and seismic data from interpretation data, you can ensure that the wells and seismic data are not inadvertently changed.
The Reference Project with input data can be set to read-only. The interpretation Reference Project can be set to read-write for most Users. An administrator can periodically move data from the interpretation Reference Project to the input data Reference Project. This deems the interpretation as approved and changes the quality status of that work.
There are many possible configurations for Reference Projects, and companies should adapt the deployment of Reference Projects to meet their business needs.
8.4 Creating Seismic Reference Projects
Special consideration needs to be given to data organization and loading when creating Reference Projects for seismic data.
8.4.1 Organizing Data in the Seismic Main Folder
We recommend that you organize the seismic data in the Reference Projects by SEGY, realized and attribute versions under the seismic survey folder. This
organization makes it easier for Users to collect the data they need. Seismic survey folders should be directly located under the main seismic folder. In an upcoming Petrel release, support for seismic subfolders will be introduced. You will then be able to organize seismic surveys in logical folders (for example in folders named
“2D” or “3D”). As of this writing, this must not be done, mainly because of the connected seismic horizon interpretation.
Schlumberger Public
You should also give seismic vintages correct names as soon as possible after the loading so as to not confuse Users. Consider using the following model consisting of the version name plus the status in brackets:
a. final_mig (SEGY/realized) b. near_stack (SEGY/realized) c. mid_stack (SEGY/realized) d. far_stack (SEGY/realized) e. raw_stack (SEGY/realized) f. struct_smooth
g. phase_shift h. …
Consider rationalizing the name of the cube/line. You can change names at any time using a Petrel workflow. When the names are changed, synchronization using the Reference Project Tool carries the name update into the Work Projects.
The proposed folder structure in the seismic folder for 2D is:
SeismicMainFolder Vintages
Final_mig (SEGY)
Final_mig (realized)
Struct_smooth Survey2D
Segy
Line1 Line2
Realized8bit
Line1 [Realized]
Line2 [Realized]
StructSmooth
Line1 [StructuralSmooth][Realized]
Line2 [StructuralSmooth][Realized]
This subfolder structure can be created when realizing the data in the
SurveyManager or via a Petrel workflow. Note that when using a Petrel workflow to realize data or to calculate a seismic attribute, you must manually set the correct vintage in the SurveyManager for those lines afterwards.
Schlumberger Public
8.4.2 Loading Data into the Seismic Reference Project
When it comes to the Seismic Reference Project, data should be loaded into the project as SEGY and realized there. The binary files created when 2D seismic data are realized are stored in the .ptd directory of the project. The ZGY files created when realizing 3D seismic data can be stored in a dedicated folder on a (network) disk. Section 6.2 describes examples for this folder structure. Typically the
realized data is transferred to the Work Projects (thus copying the 2D realized data and linking the 3D ZGY files). The raw SEGY data stays in the seismic Reference Project in case a User needs to realize the line or cube using a different quality.
Another option is to create two separate seismic Reference Projects: one storing only realized 2D and 3D data and one with realized 2D and 3D data plus the
original SEGY data. Since project security is all or nothing at the project level, you may want to separate the data into different Reference Projects for better control over User access (read-only or read-write).
In Petrel 2007, seismic interpretation is linked to the GUID number of the seismic survey in the project. Therefore, it is important that all projects extract the survey definition from the Reference Project to make sure the survey GUID is the same. If two projects have loaded an external SEGY or ZGY file without the survey pre-loaded from the Reference Project, then the seismic survey is created on the fly, resulting in each project having the survey with a different GUID. Petrel will not be able to identify these surveys as the same (because the GUIDs are
different), and thus complicating the exchange of seismic interpretation between the two projects.
8.4.3 Loading 2D Seismic Data
Consider the following guidelines when loading 2D seismic data into the seismic Reference Project:
For performance reasons, it is essential to realize the 2D SEGY data as a binary Petrel format, supporting 8 bit and 16 bit integer or 32 bit float.
Once loaded, scan the lines for min/max in exact sense using the
SurveyManager or via a Petrel workflow. The latter allows for monitoring the progress to an ASCII file while scanning for min/max. This is specifically useful when one of the 2D SEGY files on disk is corrupted (potentially
causing SurveyManager to crash).
Preferably, display each line in an interpretation window after the min/max scan is done. This can be done in a Petrel Workflow. Upon display, you can export the plot to an .emf, .pdf, or.cgm file for documentation purposes.
Complete the realization after the full amplitude scan and using the option
“use symmetric around zero”. In case of spikes in the dataset (indicated by
Schlumberger Public
extreme min/max), visualize the section and clip away the spikes using a
“manual setting min/max”. Again, make sure the min/max is symmetric.
Ideally, you should set the min-max amplitudes per survey when realizing the data (so using UserDefinedMinMax range), and not per line. Visually inspect the “extreme” lines to avoid using noisy/spiky.
Use realized 8 or 16 bits (depending on the customer requirements).
Make sure the tick mark interval in a 2D map view is high or toggled off.
Having too many tick-marks displayed in the 2D map impacts performance.
You can run MistieAnalysis on the survey to correct for amplitude, phase, and time shifts.
You can perform Phaseshift using VolumeAttributes and can automate it for the whole 2D survey using a Petrel workflow.
You can use the SurveyManager to perform Staticshift on individual lines or on a whole survey.
Visualizing the loaded data can best be done in the interpretation window.
Visualizing the data in the 3D window will allocate a very large amount of memory. (The amount of 2D lines you can visualize depends on the amount of available memory.) Use FreeMemory occasionally.
If not necessary in the Work Project, remove the seismic lines linked to SEGY files. The best practice is to have only realized data in the Work Projects.
8.4.4 Loading 3D Seismic Data
Consider the following guidelines when loading 3D seismic data into the seismic Reference Project:
For performance reasons, it is essential to realize the 3D SEGY data as a bricked multi-resolution format called ZGY, supporting 8 bit and 16 bit integer or 32 bit float.
When 3D SEGY data (via SEGY file, OpenSpirit or via a Petrel 2005 project upgrade) is loaded, the geometry upon load is scanned and a warning is presented to the User when the cube is not 100% orthogonal. Petrel will force the non-orthogonal coordinates of the SEGY file into an orthogonal representation. The message log will give an indication of the maximum distance error calculated from the bin size of the survey.
You must scan the cube for min/max in exact sense once loaded. This can be best done directly in the Realize tab of the cube. You can inspect the histogram to spot spikes. Scanning a full volume may take some time, but this scanning can be cancelled using ESC. After about five minutes
(depending on the data set size), quite a few traces have been processed and the min/max should be estimated well enough. You can then manually
Schlumberger Public
set the range larger, ensuring it is still symmetric around zero:
abs(min)=max.
You should do the realization after the full amplitude scan using the option
“use symmetric around zero”. In case of spikes in the dataset (indicated by extreme min/max), visualize the section and clip away the spikes using a
“manual setting min/max”. Again, you must make sure the min/max is symmetric. If you do not do a full scan before realization, use the report tool to see what data will be clipped on realization.
Use 8 or 16 bits realizing, depending on the customer requirements.
Place the ZGY file in a common folder belonging to the Reference Project and give it an appropriate name (combination of survey and cube). Make sure to use the extension “.zgy”.
Preferably, run the realization of the cube on the machine where the disk file is located. Realizing a cube over the network will decrease both performance and network availability.
To properly share 3D seismic ZGY files, realize them to a ZGY directory that is related to your 3D reference project. This way multiple Petrel projects can link to a single set of ZGY volumes.
8.5 Reference Project Data Considerations
As a rule, to make the most of the Reference Project Tool in this network of projects, Users must enter data into this network only once and then distribute it further using the Reference Project Tool.
Corporate data loaded locally in the Petrel projects should be replaced by a version from these reference data stores (Reference Project or OpenSpirit data store). There are two scenarios:
If the corporate data does not yet exist in the Reference Project (you can check this using the Reference Project Tool), then it can be copied into the Reference Project using the Reference Project Tool. This will ensure the GUID for the data is the same. The data in the Work Project can stay as-is.
If the corporate data does exist in the Reference Project, but the Reference Project Tool does not recognize it to be the same entity, and then you should delete the data from the Work Project and repopulate it from the Reference Project.
Non-corporate data (proposed wells, attribute cubes, etc.) can stay in the Working Projects; no synchronization is required.
Replacing (deleting) wells in the Work Projects and re-populating them from the Reference Project (or via OpenSpirit) can potentially have a big impact on other
Schlumberger Public
data types (well tops, interpretation logs, etc.) and processes (workflows). A full replacement for well data is not recommended. Replacing (deleting) seismic data in the Work Project does not have an impact since the seismic interpretation horizon is not yet converted into the new representation.
8.5.1 Consolidating Well Data in a Reference Project
To synchronize well data, open the Work Projects one by one using the Petrel 2005 secondary project tool and select the wells you want to upload. Consider the following when performing this step:
Petrel will issue a warning when you try to upload an object with an
identical GUID. To determine the latest version of the object, use the Petrel 2007.1 reference tool later in the process. (A patch for merging wells
without the same GUIDs is under development.)
When encountering seemingly identical items but with different GUIDs, choose which version you want in the Reference Project. Note that it is not possible to exchange well logs between wells with different GUIDs, not even when they represent the same well. The well log has to be reproduced.
Many logs are derived from data in the working projects. (Zone logs, Synthetic logs etc). Note that these connections will be lost when you
upload these logs in your Reference Project; however, the items themselves will still be there.
Do not delete and replace any duplicate wells or logs in the Work Project with wells or logs from your Reference Project. This could have an
undesired impact on other project data (upscaled logs in a grid, interpretation logs, well-tops etc)
Use the Reference Project Tool in Petrel 2007.1 after conversion. This will show you all the identical objects, the latest version of identical objects and the duplicates.
8.5.2 Consolidating Seismic Interpretations in a Reference Project
If many Work Projects need to access the same seismic interpretation, you must synchronize the seismic surveys across the Work Projects since Petrel 2007.1 interpretation objects are linked to a specific survey.To synchronize seismic data, open the working projects one by one and populate the Reference Project with the “asset” seismic surveys. Consider the following when performing this step:
Take into account that the surveys need to be realized in a Petrel 2007.1 default format. Consider completing a bulk realization of the seismic surveys in Petrel 2007.1 before Interpretation upgrade.
Schlumberger Public
If already in the desired format, you can replace any duplicates (different GUID) in the working project with the seismic survey in the Reference Project to enable sharing of interpretation files.
Do not delete and replace the seismic surveys if there are any unrealized virtual cropped or attribute volumes that you want to keep associated with the duplicate. Realize those first or recreate them after replacement. Note that when you replace seismic data that is associated with a dynamic
Do not delete and replace the seismic surveys if there are any unrealized virtual cropped or attribute volumes that you want to keep associated with the duplicate. Realize those first or recreate them after replacement. Note that when you replace seismic data that is associated with a dynamic