WELL

From PPDM Wiki
Jump to: navigation, search

Contents

Well Components

The WELL Table can be used to store information about Planned and actual wells and for most well components:

Each component should be described on a separate row in the WELL table, using the column WELL_LEVEL_TYPE to state which kind of component you are capturing. When you are done, you may have several rows in the WELL table.

The WELL_XREF table is used to capture the relationships between the various components.

Table Use

The following columns are intended for information that is (or should be) captured elsewhere in the Well Module. A copy can be made into the Well table, if required by your circumstances, such as for database or application performance. However, in many cases where well data is purchased from a data supplier, the value will be provided directly for the WELL table. This is especially convenient where the procedure for copying the appropriate value involves manual interpretation.


Well Table Columns

Many columns in the WELL Table represent information that is mastered in another table in PPDM. However, it can be very difficult to populate all of these columns in their normalized "home location", and much important contextual information may simply not be available if you are collecting well information from a regulatory agency or a data vendor. In this case, you should examine the columns one at a time and decide on a good Business Rule that you can apply consistently across your implementation.

The data administrator should decide how to achieve acceptable data quality if the same information is stored in two places. This could be done, for example, by quality checks on loading or by using database triggers to populate one column from the other.


  • The source for the BOTTOM_HOLE_LATITUDE column is WELL_NODE.LATITUDE (foreign key BASE_NODE_ID). Coordinates in the WELL table may substantially improve the performance of many applications. Keep in mind that coordinates may change during the life of a well; good business rules are needed to keep this information up to date.



  • The source for CURRENT_STATUS is WELL_STATUS.STATUS (for latest STATUS_DATE). The WELL_STATUS table may store many kinds of status representations. If you decide to denormalize one of them into this table, establish a business rule and store it in PPDM_RULE tables


  • The source for DEEPEST_DEPTH is WELL_ACTIVITY.EVENT_DEPTH (for the record that describes the deepest drilling event). Often the DEEPEST DEPTH is needed in well header information for cases when detailed information about well drilling activities is not available, or when this information is obtained from a regulatory agency or a data vendor. In that case, DEEPEST_DEPTH should be considered to be an "As Reported" value. Keep in mind that all other activities in the wellbore should be shallower than the deepest depth that is reported.


  • The DEPTH_DATUM column describes the type of reference for depths reported in the well. It is often the kelly bushing, rotary table or derrick floor, which is the level having a measured depth of zero. Elsewhere in the Well Module (e.g., WELL_LOG_TRIP), it is possible that a different datum is used for the depths. As you populate DEPTH DATUM, be aware that a well may have more than one depth datum, particularly if more than one rig may have conducted work on the well site.


  • DEPTH_DATUM_ELEV is the elevation (e.g., height above mean sea level) of the depth datum. Subsurface elevations may then be computed as DEPTH_DATUM_ELEV-MEASURED_DEPTH, provided the measured depth is “true vertical”.


  • DRILL_TD is the total depth reported by the driller (or operator). It is the length from the datum (at surface) to the bottom of the hole, measured along the wellbore. This total depth may vary somewhat from the total depth measured by logging tools or other means, especially in a very deep well.


  • The source for FINAL_DRILL_DATE is WELL_ACTIVITY.EVENT_DATE. See the note for DEEPEST_DEPTH, as in the WELL table this value may represent an "As Reported" value.


  • FINAL_TD may be redundant with DRILL_TD, but this column can also be used to capture the preferred value for total depth, which may disagree with the driller’s depth.


  • The source for FINAL_TD is WELL_ACTIVITY.EVENT_DEPTH. See the note for DEEPEST_DEPTH.


  • GROUND_ELEV_TYPE describes the type of datum for the ground elevation. Allowable values are in R_WELL_DATUM_TYPE.


  • INITIAL_CLASS is the assigned “class” of the well, often derived from the Lahee classifications, such as New Pool Wildcat. The designation may change in the life of the well, but the explorationist’s interest is chiefly in the initial assignment as an indicator of why the well was drilled.


  • LEASE_NAME and LEASE_NUM provide basic connections to the PPDM Land Module, although no foreign key is assigned in this version of the Model. A well is usually part of a lease or other type of permit to drill and operate. This information is denormalized, and should by preference be stored in the LAND RIGHTS module. Relationships between the well and ALL the land rights is stored in LAND_RIGHT_WELL. In some regions of the world a well may be held by only one land right that exends from the surface the PreCambrian (or the middle of the earth). In other regions, rights to the surface and the subsurface may be granted separately, and more than one land right may be required. Surface land rights (may be called a permit or a lease or a license) may expire in some cases, requiring an operator or owner to seek a new surface land right.


  • LOG_TD is the maximum depth achieved by the wireline logging tools. It provides another estimate of the total depth of the well, separate from the calculation made by the driller. In some wells, the logs were never run to the bottom (e.g., hole collapse), so LOG_TD might be a much smaller value than DRILL_TD. The source for LOG_TD may come from one of two locations. The WELL_ACTIVITY table was created to capture a full event record over the life of a well, and can store logging event information. At this time, this information is also in WELL_LOG_TRIP.BASE_DEPTH. We expect to resolve this duplication in future releases by removing event information from logs, cores, test and so on. This column may be difficult to populate programmatically because each log trip may have a different depth. It's also important to keep in mind that over time, multiple rigs may come on-site for a well operation - each rig may have a differnt reference elevation (such as a KB elevation). This can influence the value in LOG_TD.


  • MAX_TVD is the total depth of the well as measured vertically from the datum. It should be computed from directional surveys, if available. Otherwise, it should be left null.


  • The source for MAX_TVD is WELL_DIR_SRVY_STATION.STATION_TVD. This is difficult to populate programmatically because there may be multiple surveys, and none may have reached total depth. Often, this value is derived "as reported" unless the user has access to complete drilling history information.


  • NET_PAY is the cumulative thickness of productive reservoir in the well. Normally, this value refers to only the producing zone in the well, although it is possible to have multiple pay zones. Detailed information is captured in WELL_PAYZONE, as the WELL table provides only a summary.


  • The source for NET_PAY is WELL_PAYZONE.NET_PAY. This is difficult to populate programmatically because there may be multiple pay zones in the well. It's important to have consistent business rules in place if you are deriving this information.
  • OLDEST_STRAT_UNIT is the oldest unit (“formation”) encountered in the well. In faulted or overturned strata, the oldest unit is not necessarily found at the bottom of the well.


  • The source for OLDEST_STRAT_UNIT is STRAT_WELL_SECTION.STRAT_UNIT_ID, where CERTIFIED_IND = Y and the oldest unit is determined from STRAT_UNIT_AGE. You must also specify STRAT_NAME_SET_NAME. As many interpretations for stratigraphy in a well may exist, it's important to understand and document the business rules you use to derive this information.


  • OPERATOR is the name of the business associate currently holding the permit to drill and responsible for reporting the drilling activity to the regulatory agency. The operator may be acting on behalf of other partners in the well. The present operator is not necessarily the one at the time the well was drilled. A complete history of operatorship, and all other services provided on a well, can be captured in WELL_BA_SERVICE. The column in the WELL table is denormalized from WELL_BA_SERVICE.
  • The source for PLUGBACK_DEPTH is WELL_PLUGBACK.TOP_DEPTH (for latest PLUGBACK_DATE and/or selected PLUG_TYPE).


  • PRIMARY_SOURCE is the link to the main source of the data in WELL_VERSION. In some areas of the world, well header information may be collected from several sources. Each source is stored in WELL_VERSION, and a set of business rules (which may be quite complex) are used to derive a complete set of preferred (or most trusted) values for the WELL table.


  • PROFILE_TYPE is a general description of the profile of the well, such as vertical or deviated. In complex wells that have many well bores it is more appropriate to capture this at the well bore level rather than at the well set level.
  • The source for RIG_ON_SITE_DATE is WELL_ACTIVITY.EVENT_DATE (for ACTIVITY_TYPE describing the arrival of the rig at the well site).


  • The source for RIG_RELEASE_DATE is WELL_ACTIVITY.EVENT_DATE (for ACTIVITY_TYPE of “rig release”). This is probably never used as the source of data for the WELL table.


  • SOURCE_DOCUMENT describes the original data source, if known. In contrast, WELL.SOURCE describes the supplier of the data as loaded. For example, the source document might be a well report submitted to the government, and the source is the data vendor who collected and delivered the data to a client.


  • The source for SPUD_DATE is WELL_ACTIVITY.EVENT_DATE (for ACTIVITY_TYPE of “spud”). This is probably never used as the source of data for the WELL table.


  • STRAT_NAME_SET_NAME is required to ensure uniqueness of any STRAT_UNIT referred to in the WELL table (e.g., TD_STRAT_UNIT).


  • SURFACE_LATITUDE and SURFACE_LONGITUDE hold a copy of the surface coordinates of the well, derived from WELL_NODE using the foreign key WELL.SURFACE_NODE_ID. To ensure data quality, it is essential to maintain the links between these tables.


  • The source for SURFACE_LATITUDE is WELL_NODE.LATITUDE (foreign key SURFACE_NODE_ID). Coordinates in the WELL table may substantially improve the performance of many applications. Keep in mind that coordinates may change during the life of a well; good business rules are needed to keep this information up to date.


  • TD_STRAT_UNIT is the deepest formation encountered in the well.


  • The source for TD_STRAT_UNIT is STRAT_WELL_SECTION.STRAT_UNIT_ID, where CERTIFIED_IND = Y and PICK_DEPTH is at the total depth for the wellbore. You must also specify STRAT_NAME_SET_NAME. If you capture the arrival at TD in the WELL_ACTIVITY table, this can be associated with an appropriate stratigraphic unit using WELL_ACTIVITY_COMPONENT. However, keep in mind that associating stratigraphic formations with depths is a highly interpretive process, so the identity of the deepest formation may change over time.


  • WELL_GOVERNMENT_ID may be any string describing the well, as assigned by the regulatory agency. It is not used in the primary key for this table, although it may be identical to WELL.UWI in some jurisdictions.This column is denormalized, and should only be used if needed for query performance. The standardized home for all names and identifiers for wells is WELL_ALIAS


  • WELL_LEVEL_TYPE should be used to identify the type of well component that is captured in this row of data. Details about the well components that have been identified may be found in the [www.whatisawell.org|"What is a Well"] project


  • WELL_NUM may be any string describing the well, as assigned by the operator or by the owner of the database. It is not used in the primary key for this table, but may be useful to simplify or shorten the well designations on maps and printed lists.This column is denormalized, and should only be used if needed for query performance. The standardized home for all names and identifiers for wells is WELL_ALIAS


  • WELL_NUMERIC_ID is a unique number for use in spatial queries. Note that it is not the same data type as WELL.UWI. This column is denormalized, and should only be used if needed for query performance. The standardized home for all names and identifiers for wells is WELL_ALIAS


  • The source for WHIPSTOCK_DEPTH is WELL_ACTIVITY.EVENT_DEPTH (for ACTIVITY_TYPE of whipstock).

Table Comment

WELL: A table for general and header information about a well. A well is an actual or proposed hole in the ground, designed to exchange fluids between a subsurface reservoir and the surface (or another reservoir) or to enable the detection and measurement of rock properties. A wellbore is a cylindrical hole created by a drill. A well may consist of zero, one, or more wellbores; their relationships are described by the table WELL_XREF. Information from other well tables (e.g. key dates and depths) may be included (denormalized) for convenience. The term "well" is used in the column name and comments to mean "well", "wellbore", either, or both (depending on the context). The column WELL_LEVEL_TYPE is used to describe which type exists in a row of data.

PPDM On-line Documentation (P.O.D.)

PPDM 3.7.1
PPDM 3.8

Tables that are used by WELL

Tables that use WELL

Retrieved from "http://www.ppdm.org/wiki/index.php/WELL"
Personal tools