Change Request Report For Epicentre Version 2.2

Report generated 26-Mar-1997 23:39:54.

List of topics:

Topic: Activity

0562 Add "triggers" to SCHEDULE_CONSTRAINT and ACTIVITY_TEMPLATE_CONSTRAINT
Version: 2.2
Assigned to: Jenny Meader
The concepts of cause and effect are not well described in the ACTIVITY model. In both SCHEDULE_CONSTRAINT and ACTIVITY_TEMPLATE_CONSTRAINT it appears that stating "the first activity caused (or will cause) the second activity" is not possible.
Status: completed

Changes:

  1. 0562.001 Add cause and effect to the activity model. (Duplicate)
    Add activity_cause_and_effect as a subtype of association, with two relationships to activity. Components changed:
0639 Causal relationship between activities
Version: 2.2
Assigned to: Jenny Meader
Many models of drilling activities tag each activity with 'what' and 'why' codes. In Epicentre, all 'what' information is recorded through the activity_type. This includes the recording of significant observations such as a kick, which is modeled as an event activity. However, there is no direct equivalent to the 'why' code. The semantics of the 'why' code is to indicate that the purpose of the activity is to recover from a particular event. So it represents a causal dependence of an activity on an event. The fact that one activity follows another can be modeled in Epicentre using the schedule_constraint. However, the semantics of this usage are unclear. There is a need in Epicentre for a construct that clearly models causal dependence between activities. Note that this causal dependence includes some repesentation of the 'state' of an operation.
Status: completed

Changes:

  1. 0639.001 Add cause and effect to the activity model. (Add)
    The entity activity_cause_and_effect was added. This is a subtype of association and has two relationships to activity - one pointing to he causing activity and the other to the resulting activity. Components changed:
0739 Clarification on modelling of directional survey analysis
Version: 2.2
Assigned to: Jenny Meader
I would be grateful if you could clarify a couple of issues regarding the use of DIRECTIONAL_SURVEY_ANALYSIS (computed deviations). How do you recommend relating a DIRECTIONAL_SURVEY_ANALYSIS to the WELLBORE_DIRECTIONAL_SURVEY from which it was derived ? We are currently using the containing_activity attribute for this purpose. This does not seem like a perfect solution, however, as the analysis activity is not necessarily a dependent part of the original survey. A DIRECTIONAL_SURVEY_ANALYSIS often uses a particular computation method to explicitly define the wellbore trajectory, from a set of azimuths, inclinations etc. Examples of such methods are 'Average angle', 'Radius of curvature', 'Minimum curvature'. Where do you recommend that such methods are defined in Epicentre ? There appear to be at least two candidate choices: the activity type and the activity class, neither of which seems entirely satisfactory. At present, we are leaning towards the former.
0803 Sequencing actual activities with Schedules seems inappropriate
Version: 2.2
Assigned to: Jenny Meader
Since actual activities can also be described in a precedence scheme, the use of Schedule constraint to establish the sequencing seems inappropriate. Perhaps the entity name is too restrictive. Also why are two schedule activities required to associate activities? And why is a Schedule involved? Is the sequencing at least partially redundant with Object Ranking?
Status: completed

Changes:

  1. 0803.001 Add cause and effect to the activity model (Duplicate)
    The association entity activity_cause_and_effect, and two optional relationships from activity to the entity have been added to Epicentre. Components changed:
0817 Missing equipment items and facilities for Core/Fluid Analysis
Version: 2.2
Assigned to: Jenny Meader
Missing are entities to model types and instances for laboratory equipment. Examples include: Instruments to measure Surface Tension, Dynamic Surface Tension, Interfacial Tension, Dynamic Interfacial Tension, Contact Angle, Dynamic Contact Angle.
Status: deferred
Information on this is still being researched.
0886 Interprocess_data needs complex data types added
Version: 2.2
Assigned to: Gary Masters
Interprocess_data needs complex data types added as attribute values, including both element and geometry (line, surface, volume).
0890 Questionable Wellbore_activity behavior
Version: 2.2
Assigned to: Jenny Meader
A Wellbore_activity is not identified by the Wellbore in which it occurs. A Wellbore has both a "used by" relationship to Activity and a "where occured" relationship to Wellbore_activity.
Status: completed

Changes:

  1. 0890.001 Add wellbore to the identifier of wellbore_activity. (Modify)
    The optional attribute wellbore was added to the identifiers of all the subtypes of wellbore_activity. Components changed:
0891 Typical_activity is incorrectly defined
Version: 2.2
Assigned to: Jenny Meader
Typical_activity is currently described as a reusable design; however, the POSC instances define types/kinds such as "checkshot analysis". It appears that the Activity_template attempts to perform the reusable design function. If so, The descriptions should be modified appropriately and a new relationship added between Activity and Activity_template to specify conformance to a design.
0947 BOREHOLE_GENERATION_RUN
Version: 2.2
Assigned to: Jenny Meader
We need the functional equivalent of a "conventional coring run" subtype of BOREHOLE_GENERATION_RUN. There is no way in the entity CORE to distinguish whether the core is a sidewall core or a conventional core (an inference can be made if optional attributes to activities are populated). There is also no way to differentiate whether or not the BOREHOLE_GENERATION_RUN was a coring run or regular drilling run unless you check the drill string equipment - which is NOT desireable. So, there is no easy or effective way to query a data set to find out if a conventional core was attempted or retrieved from a well.
Status: completed

Changes:

  1. 0947.001 Add kind attribute to core. (Add)
    The attribute kind was added to core. This attribute is controlled by the POSC open reference entity ref core, which was added for this purpose. Established a relationship from core to wireline logging pass to allow wireline coring activities. Components changed:
1132 codes for typical_activities
Version: 2.2
Assigned to: Jenny Meader
It is often necessary to classify typical activities with code values (as well as plain english names). For example a drillstem test activity may be one of the following: drillstem test for cased hole, drillstem test for open hole, extended well test or injectivity test. These typical activities have an associated codes: DSTC, DSTO, EWT, INJ. At the moment, the model does not allow typical_activity to have a ref_code_alias to describe these codes. Associated ref_code_alias to reference entities is only valid for the subtypes of ref_code. We suggest that this mechanism should also be available for subtypes of reference_behavior (typical_activity, coordinate_system, etc..). The implication on the model would be to add an attribute in the ref_code_alias entity that points to the reference_behavior entity.
Status: completed

Changes:

  1. 1132.001 add class alias entities (Add)
    Add class alias entities with relationships to classification system and the specific class entities. Also add ref_classification_system to qualify classification_system, to distiguish between naming system (classification system) and what kind of thing it is. Components changed:

Topic: Coordinate System

0834 Reference north needed for azimuths in deviation surveys
Version: 2.2
Assigned to: Robert Aydelotte
There is no clear-cut way in Epicentre to capture the reference north direction used in wellbore directional surveys. For the purposes of such surveys, azimuth values are reported not against magnetic or true north, but against some reference north local to the survey, whose offset against true or magnetic north is recored in the survey. This has been discussed in numerous projects, including SAVE, and POSC data modellers, including John Bobbitt, have taken onboard the need for a data model extension. This should be done for Epicentre 2.1, as the issue will arise regularly.
0906 Need rule on Coordinate_system
Version: 2.2
Assigned to: Gary Masters
Coordinate_system appears to need a rule which checks that the axes match the constraint. The following is suggested: constraint_type_valid : axis_type_correlation( SELF ); FUNCTION axis_type_correlation ( coordinate_system : coordinate_system ) : BOOLEAN; ALIAS csa FOR coordinate_system.coordinate_system_axis; REPEAT i := LOINDEX(csa) TO HIINDEX(csa); IF NOT ( csa[i].ref_quantity_property IN coordinate_system.ref_coordinate_system_constraint.ref_axis_typ e[i].ref_quantity_property ) THEN RETURN (FALSE); END_IF; END_REPEAT; END_ALIAS; RETURN (TRUE); END_FUNCTION;
Status: completed

Changes:

  1. 0906.001 Add new rule. (Add)
    Add rule that constrains the Ref_quantity_property instance specified by each Coordinate_system_axis to be in the set allowed by the specified instance of Ref_coordinate_system_constraint. This rule is not currently supportable by POSC because functions are not supported. The rule has been included as a remark in order to show the intent of the model. Components changed:
0908 Ref_coordinate_constraint instance is ambiguous
Version: 2.2
Assigned to: John Bobbitt
Ref_coordinate_constraint instance "depth time system" only specifies one ref_axis_type but its description implies two.
1029 Description for Ellipsoids
Version: 2.2
Assigned to: Robert Aydelotte
The EPSG data includes information about ellipsoids that can be captured in the description/remarks/comment attribute Ellispoid does not have any description/remarks/comments attribute. This attribute should be added so that the epsg information can be captured.
Status: completed

Changes:

  1. 1029.001 Add description to ellipsoid (Add)
    A missing description attribute has been added to ellipsoid to hold descriptive comments and remarks. Components changed:
1116 Applied coordinate transformation rule too restrictive
Version: 2.2
Assigned to: Robert Aydelotte
Applied coordinate transformation has a rule that states that the source and target systems must be different. This does not allow coordinate readjustments, which is a very common transformation. Often a set of locations is given in a particular coordinate system. For one reason or another, the locations may need to be adjusted to bring them in line with other locations. The coordinate transformation activity was introduced to aid in distinguishing the set of coordinate values that result from the transformation. The transformation itself can (name and values) can be recorded through the coordinate_transformation and related entities. However, to make sense of the whole, it is necessary to say that the coordinate transformation is a readjustment within the same coordinate_system. The way all this information is tied together is through the applied_coordinate_transformation. Since the readjustment is within a single coordinate system, the source and target coordinate systems are the same.
Status: completed

Changes:

  1. 1116.001 Delete rule for different source and target coordinate systems (Delete)
    The different related instance rule for applied_coordinate_transformation that says that the source must be different from the target has been deleted. Components changed:

Topic: Cartography

0724 Add average elevation and water depth to earth surface feature
Version: 2.2
Assigned to: Robert Aydelotte
For any EARTH_SURFACE_FEATURE, add properties of average elevation and average water depth.
Status: completed

Changes:

  1. 0724.001 Create property elevation/water depth for earth_surface_feature. (Add)
    A new property was created to record the average elevation of an earth_surface_feature. A new ndt, ndt_elevation, was defined for the elevation value in data_value. Components changed:
0725 Meaning of inclination and azimuth for general surface area
Version: 2.2
Assigned to: Eric Hatleberg
Properties of PTY_AZIMUTH and PTY_INCLINATION_FROM_VERTICAL attached to GENERAL_SURFACE_AREA are unclear as to their meaning and intended use since a GENERAL_SURFACE_AREA is defined to be an area of the Earth's surface. Are they intended to be average strike and dip, or something else?
Status: deferred
Spatial considerations of these issues will receive more complete treatment in version 3.0.
0761 ndt name too short for geopolitical features
Version: 2.2
Assigned to: Gary Masters
Attribute name in geopolitical_feature allows 40 characters. Since I have chosen to instantiate the conventional short form of a country name, this is sufficient for all but a couple. But it does force me to shorten a couple of names. On the other hand, attribute identifier from earth_surface_feature_alias is also ndt name, which is too short for about 50 -60 of the long forms of country names. For example, the short form is 'United Kingdom', which is OK. But the long form is 'United Kingdom of Great Britain and Northern Island', whic is 51 characters. A solution would be to allow at least 60 characters for this identifier.
Status: completed

Changes:

  1. 0761.001 (Duplicate)
    Components changed:
0810 Geodetic_zone.surface_fluid_phase_condition
Version: 2.2
Assigned to: Robert Aydelotte
A surface_fluid_phase_condition is not an appropriate attribute for a geodetic_zone. This relationship inherited from the fact that an earth_surface_feature can be a pfnu. I believe the subtyping is at too high a level.
Status: completed

Changes:

  1. 0810.001 Add a new subtype of wellbore_component_facility for the concept of wellbore_measurement_point. It was added as a subtype of product_flow_network_unit. (Modify)
    earth_surface_feature was removed as a subtype of product_flow_network_unit and its subtypes of geopolitical_feature, field, regulatory_area, discovery_area and geologic_province were added. Components changed:
1038 name (identifier) at wrong level for earth_surface_feature
Version: 2.2
Assigned to: Robert Aydelotte
All subtypes of earth_surface_feature have either name or identifier as an attribute. Earth_surface_feature does not have this attribute. I suggest that name (or identifier) be moved up to be an attribute of earth_surface_feature. The uniqueness should still be placed at the lower level, as is now done. This change would make it possible to access the names (identifiers) of all earth_surface_features. Now you have to do this query for each of the subtypes individually.
Status: completed

Changes:

  1. 1038.001 Add attribute identifier to earth_surface_feature (Add)
    A new attribute added to earth_surface_feature. Components changed:
  2. 1038.002 Delete existing identifiers and names (Delete)
    Delete the existing identifiers and name attributes of the subtypes of earth_surface_feature. Components changed:
  3. 1038.003 Modify uniqueness rules for identifiers (Modify)
    Modify the uniqueness rules for the subtypes of earth_surface_feature to delete the original attribute and add identifier. Components changed:
1120 earth_surface_feature should have identifier
Version: 2.2
Assigned to: Robert Aydelotte
earth_surface_feature has 10 subtypes. 9 of them have identifier as a (M,K) attribute (field does not have the K, but its 3 subtypes do). The other subtype, geopolitical_feature, has name (M,K). It seems that identifier should be at the earth_surface_feature level, and be inherited by the subtypes. Advantages: This would allow a select to be written for earth_surface_feature. As presently constituted, the select must choose the subtype. Thus, select some_entity.earth_surface_feature[regulatory_area].identifier can be simplified to select some_entity.earth_surface_feature.identifier. Disadvantages: There may be more than one of the same identifier values (under different subtypes). It is then necessary to select the preferred subtype (no different than present, though). The attribute of gepolitical_feature would be changed from name to identifier. Note: Of course, the uniqueness constraint would be kept on the subtype, so that an identifier could be reused in a different subtype.
Status: completed

Changes:

  1. 1120.001 (Duplicate)
    Components changed:

Topic: Document Management

0328 How are the device normalized coordinates actually specified?
Version: 2.2
Assigned to: m*
Graphical elements are specified to have locations in Device Normalized coordinates, yet are provided with typical spatial coordinates. Perhaps they should be assigned an appropriate set of coordinates in the proper coordinate system.
0353 notification dates
Version: 2.2
Assigned to: Robert Aydelotte
Permit needs a "notification_date" as well as application_date and effective_date.
Status: completed

Changes:

  1. 0353.001 Add notification date to permit_specification (Add)
    A new attribute notification_date was added to the entity permit_specification. Components changed:
0374 Tapes and composite documents
Version: 2.2
Assigned to: Gary Masters
The document/document_specification model appears to have too little compound behavior to meet the following requirements: 1. A single logical document (document_specification) is written to tape (electronic_document ?) and spans several tapes. There are no relationships or attributes to manage the grouping and sequence of a tape. 2. Several logical documents (document_specification) are written as separate files (electronic_document) to a single tape (electronic_document ?). 3. A box of hardcopy documents is included in an inventory and loaned as a single inventory item (hardcopy_document ?) but has a contents list of separate physical documents. 4. Many conference papers (document_specification) are bound into a single volume of proceedings (hardcopy_document).
0731 ndt rational in hardcopy document
Version: 2.2
Assigned to: Robert Aydelotte
I'm not sure that ndt_rational survived into 2.0. It doesn't seem to be everywhere it should be. But I am sure that it doesn't include units. This makes the x_scale and y_scale attributes tough to work with. These should have domain ndt_any_quantity.
Status: completed

Changes:

  1. 0731.001 Fix map scale attributes (Modify)
    The attributes that describe the x- and y-scales of maps were generalized to be either unitless or to have units. Components changed:
1181 Documents specifications need classific
Version: 2.2
Assigned to: Gary Masters
Typical_document_specification is documented to be a "reusable" design but the standard instances appear to be a mixture of class and class-of-class (e.g., "map" and "bathymetry map") of document specification.
Status: completed

Changes:

  1. 1181.001 Add entities and relationships (Add)
    Add entities Document_specification_class, Document_specification_classification and Document_spec_class_classification. Add relationship to allow Document_specification to be classified. Components changed:

Topic: Earth Model

0557 Feedback from Zonation Modelling
Version: 2.2
Assigned to: Eric Hatleberg
As part of the pilot project we [Tigress] are currently engaged in with Shell, we have assessed the zonation section of the Epicentre 2.0 [snapshot] model. We worked on the data model mapping independently, but had useful input from Iain Morrison. Iain also reviewed our final mapping documentation. During the course of the Tigress-Epicentre mapping, we came across a number of problems/limitations which we discussed with Iain. On some we were able to apply workarounds, and on others we had to defer attention (cartography related aspects). Having just completed the data model mapping, we wish to make some recommendations in this area for incorporation into the production version of Epicentre 2.0. Briefly, the Tigress zonation model is concerned with the types of rock ('zones') encountered by wellbores along their trajectories and the various properties associated with the zones at the well intersections. These properties we refer to as zonal parameters. Zonal parameters constitute various geological and petrophysical properties, such as mud resistivity, mud filtrate salinity, sonic matrix response, sonic clay response, sonic fluid response, etc, and form the input to many of our borehole corrections and formation evaluation algorithms. Zonal parameters may also be output parameters such as net sand thickness, hydrocarbon pore volume, average porosity, saturation, clay volume etc. (the outputs of zonal averaging). Thus, each occurrence of a well in a multi-well zonation has its own set of parameters. The zones themselves must be named/typed and need to be associated with graphical rendering information. The problems/limitations we encountered are addressed below: (i) Modelling of zonal parameters/properties The Epicentre way of representing the intersection of a rock type and a wellbore is to use a SUBSURFACE_ROCK_SEGMENT. This entity, however, has only a limited number of properties associated with it ( 27 ). In Tigress, there are 205 possible properties, as well as user-defined ones. We think it unreasonable that Epicentre is so restrictive. Indeed, it is our understanding that the SUBSURFACE_ROCK_SEGMENT used to have a generalised property attached. This is no longer present in Epicentre 2.0. We would like to see the attachment re-established. The work around is to associate an OTHER_COMPOSITE_SPATIAL_OBJECT with the SUBSURFACE_ROCK_SEGMENT. Instances of this can be associated with any property. Even using this, however, we find that the available properties in the whole of Epicentre are not sufficient and we have to resort to using PTY_EQUIPMENT_FACILITY to define some new properties. We find that the above is untidy. It would be nice to be able to associate a SUBSURFACE_ROCK_SEGMENT with more properties and to allow it direct access to a generalised property such as PTY_EQUIPMENT_FACILITY, specific to geology, geophysics and petrophysics. (ii) Arbitrary zone names In Tigress, the zones, as well has having 'Dictionary Type' descriptions, i.e. standard geological classifications and associated hierarchies (e.g. Chronostrat., Litho.), can have arbitrary names. (e.g. Zone1, Zone2, Oil1, Oil2, Gas, Water etc.). With Epicentre, the natural equivalent of a zone is a ROCK_FEATURE. This means that the application must create lots of ROCK_FEATURES with these arbitrary names. ROCK_FEATURE is, however, meant to be of type REFERENCE_BEHAVIOUR and is not intended to hold such arbitrary values created in such an uncontrolled manner. Since the determination of a rock feature itself can be an interpretative process, we feel that the Tigress approach allows more flexibility. Although our geologists usually pick zones from a pre-defined geological dictionary, our petrophysicists and reservoir engineers invariably use an arbitrary naming convention. We therefore recommend that in addition to ROCK_FEATURE you include another sub-type to GEOLOGICAL_FEATURE, say an unresolved rock feature, that does not exhibit reference behaviour. (iii) Zone colour/pattern and association with GRAPHICAL_ELEMENT The zones also need to be rendered in the Tigress application. However, a zone ( or GEOLOGIC_FEATURE ) is a fairly abstract concept and the type of rendering information that needs to be stored is at the type level (i.e., what colours and pattern to use, but not what shape and location ). A GEOLOGIC_FEATURE can only be associated with a GRAPHICAL_ELEMENT which describes very specifically a particular area on the screen. We believe that a GEOLOGIC_FEATURE should be associated with something like a PATTERN_FILL_TYPE. (iv) Modelling foreground, background colours and bitmaps Tigress specifies patterns using a bitmap and foreground and background colors. We have found no way of mirroring this in Epicentre. Epicentre can represent a hatch-line pattern, or a pattern cell which is specified using further graphical elements (a very detailed CGM-like specification ). To map Tigress to Epicentre completely would require us to 'translate' (actually simulate with lines) all the bitmaps. We think that the inclusion of bitmap types in Epicentre would be very useful. The above raises an important question about interoperability. With Epicentre, one is forced to go into extreme detail in areas where inter- operability is not desired. We probably don't want to store rendering information beyond application-specific codes. In the case of zonations, it only matters that application A and application B are self consistent; it doesn't matter if they render the zones differently.
Status: completed

Changes:

  1. 0557.001 Remove stratigraphic feature subtypes and allow material classification (Duplicate)
    The various stratigraphic feature subtypes duplicated behavior found in material class without the benefits of a generalized design. Material concepts were commingled with classification methodology. Therefore, these subtypes were deleted with the intention that the material class structures will provide the classification function. Components changed:
0576 CHRONOSTRATIGRAPHIC UNIT needs more subtypes
Version: 2.2
Assigned to: Eric Hatleberg
CHRONOSTRATIGRAPHIC UNIT entity has 6 subtypes: EONOTHEM, ERATHEM, SYSTEMS, SERIES, STAGES, SUBSTAGES. We would like 2 more. We need to add the possibility to decompose SYSTEMS in subsystems like: lower "something" - Example: lower miocene. In the same way we need to decompose the SERIES in subseries. For example: upper cenomanian ... It could be done inserting SUBSYSTEMS in between SYSTEMS and SERIES and inserting SUBSERIES in between SERIES and STAGES with the same types of relationships.
Status: completed

Changes:

  1. 0576.001 Remove stratigraphic feature subtypes and allow material classification (Duplicate)
    The various stratigraphic feature subtypes duplicated behavior found in material class without the benefits of a generalized design. Material concepts were commingled with classification methodology. Therefore, these subtypes were deleted with the intention that the material class structures will provide the classification function. Components changed:
0581 Need more CHRONOSTRATIGRAPHIC UNIT subtypes
Version: 2.2
Assigned to: Eric Hatleberg
Concerning the CHRONOSTRATIGRAPHIC UNIT, we need more subtypes in order to be able to indicate the following items: "lower" jurassic or "upper" aptian. It could be resolved with the insertion of: SUBSYSTEMS in between SYSTEMS and SERIES and SUBSERIES in between SERIES and STAGES.
Status: completed

Changes:

  1. 0581.001 Remove stratigraphic feature subtypes and allow material classification (Duplicate)
    Components changed:
0600 New "interpreted interval" in a wellbore
Version: 2.2
Assigned to: Eric Hatleberg
There is a general need for a kind of "interpreted interval" in a wellbore. Business need presentation (using the chronostratigraphy): there is a very classical interpretation problem with different types of geological determinations. Example is the fact we are sometimes obliged to say "albian-aptian" for an interval. The underlying concept is: it is maybe "albian" ; it is maybe "aptian"; it is maybe "albian" and "aptian", but there is no present possibility to give more precision and to chose one of these solutions. It means that an interval may have to point at two CHRONOSTRATIGRAPHIC UNITS. We have identified the same need for an interval which may have to point at two BIOSTRATIGRAPHIC UNITS. We have identified the same need for an interval which may have to point at two PALEOENVIRONMENTs (concept presently covered by the MATERIAL CLASS entity). Because, in case of uncertainty, it may be necessary to say for example: "continental to deltaic". Presently we use the SUBSURFACE ROCK SEGMENT entity to cover these different cases. But it is not a very clean way to solve our problem because we are obliged to use the IDENTIFIER attribute of this entity to "name or specify" the interval. So, there is a strong need for specific intervals for these different cases. In conclusion, this message covers two needs: 1) The first need is about the fact we need specific "named" intervals for these above cases. 2) The second need: it is necessary to have the possibility to say that an interval may point at two CHRONOSTRATIGRAPHIC UNITs (or two PALEOENVIRONMENTs or two BIOSTRATIGRAPHIC UNITs). It means it is necessary to have explicit "top or first" and "bottom or last" relationships from CHRONOSTRATIGRAPHIC UNIT/PALEOENVIRONMENT/BIOSTRATIGRAPHIC UNIT to the WELLBORE INTERVAL subtypes.
Status: completed

Changes:

  1. 0600.001 Remove stratigraphic feature subtypes and allow material classification (Duplicate)
    Components changed:
0604 "description interval" (cf. Request number 209)
Version: 2.2
Assigned to: Jenny Meader
We are back again with what we call a "geological description". I recall that it is a free text attached to any interval in a wellbore. We cannot use the DESCRIPTION attribute of an other WELLBORE INTERVAL subtype because a "description" generally includes several lithologic beds. So it is really a full apart concept. In the M4 snapshot, there was a WELLBORE DESCRIPTION INTERVAL. This concept seemed to cover our business need. But in the new V2 Snapshot there is no more WELLBORE DESCRIPTION INTERVAL.
Status: completed

Changes:

  1. 0604.001 (Duplicate)
    Components changed:
0611 Reliability of an "interpreted" interval
Version: 2.2
Assigned to: Eric Hatleberg
We would like to be able to give a degree of reliability to, for example, a chronostratigraphic attribution. Example: such interval is declared to be APTIAN and this interpretation is said to be "reliable" (or "doubtful" or ...). This need is valid for any kind of interpretation: chronostratigraphy, biostratigraphy, paleoenvironments ...
Status: completed

Changes:

  1. 0611.001 Modify uncertainty class relationship (Modify)
    Allow uncertainty class to modify many material classification. Populate standard instances for uncertainty class. Components changed:
0647 Geologic and reservoir engineering integration
Version: 2.2
Assigned to: Eric Hatleberg
The logical data model has some inconsistencies in how rock and fluid properties, spatial properties and classification names are applied/related to certain major entities and their sub-types. These differences seem to represent different viewpoints as held by the Geological and Reservoir Engineering disciplines. The goals of inter-discipline data sharing and integrated data management require that these different views and inconsistencies within the data model be resolved into a single integrated approach. The ROCK_FEATURE (Geological view) and ROCK_FLUID_FEATURE (Engineering view) entities are both sub-types of GEOLOGIC_FEATURE. While ROCK_FEATURES are named by complex hierarchical classification schemes, ROCK_FLUID_FEATURE is named/classified more simply by basic geometric/spatial aspects of the feature. In addition, associated properties (e.g. porosity, permeability, water saturation, etc.) are directly related to/carried with ROCK_FLUID_FEATURE but an additional relationship must be utilized between ROCK_FEATURE and ROCK_BODY to get those properties associated with a ROCK_FEATURE. Unless these different viewpoints and inconsistencies are resolved it may be very difficult to develop application software independant of a specific discipline viewpoint. (This would threaten the basic goal of inter-discipline data sharing.)
Status: completed

Changes:

  1. 0647.001 Remove stratigraphic feature subtypes and allow material classification (Duplicate)
    Components changed:
0684 ref_fault_side has name too short
Version: 2.2
Assigned to: Eric Hatleberg
The domain for ref_fault_side.name is ndt_short_name. Presently, the only instances are 'hanging wall' and 'footwall', both of which fit. However, since it is an open entity, there may be the need to put in more descriptive values that are more than 15 characters. Recommend the domain be changed to ndt_name.
Status: completed

Changes:

  1. 0684.001 Change domain of ref_fault_side.name to ndt name (Modify)
    The domain of ref_fault_side.name has been changed to ndt_name. Components changed:
0784 Missing entities for Basin modelling applications
Version: 2.2
Assigned to: Eric Hatleberg
Missing Geologic_features for: Petroleum System, Systems tract, Seal, Source, Trap, Migration path or conduit, aquifer recharge and discharge areas. Missing Geologic process types for: Petroleum migration, secondary migration, flushing of a reservoir, hydrocarbon deasphalting, hydrocarbon maturation, diagenesis, orogeny, faulting, etc.
Status: deferred
Basin modeling and geologic processes have complex interactions that will be more thoroughly addressed in a latter version.
0793 Unique names for ROCK FEATURE is too restrictive
Version: 2.2
Assigned to: Eric Hatleberg
The geologic community does name geologic features, but the uniqueness constraint is only administered at the level of the subclasses.
Status: completed

Changes:

  1. 0793.001 Remove stratigraphic feature subtypes and allow material classification (Duplicate)
    Components changed:
0794 features.
Version: 2.2
Assigned to: Eric Hatleberg
PTY SURFACE AREA is both a characteristic of EARTH SURFACE FEATURE and GENERAL EARTH SURFACE AREA. This appears redundant and confusing.
Status: completed

Changes:

  1. 0794.001 Modify definition for earth surface feature (Modify)
    The definition of earth surface feature was clarified to show semantic for of an object with general properties. Components changed:
0892 Need properties for source rock kinetics
Version: 2.2
Assigned to: Eric Hatleberg
Organic matter maturation analysis describes properties for: Activation Energy, Petroleum Potential (mg petroleum/ g TOC) and Petroleum Potential as a function of Activation Energy. A Kinetic scheme or model is a list of [petroleum potential, activation energy] points for a sample. !end_text From masters Tue Aug 15 12:21:39 1995 Date: Tue, 15 Aug 1995 12:21:37 -0500 From: Gary Masters To: problem@POSC.org Subject: Change Request Content-Length: 606 X-Lines: 20 Status: RO !submitter: Gary Masters !submitter_email: masters@posc.org !submitter_phone: (713) 784-1880 !submitter_fax: (713) 784-9219 !submitter_company: POSC !submitter_address: 10777 Westheimer, Suite 275, Houston, Tx 77042 ???product_subsys: Any ???hardware: Any !os: Any !os_version: Any !problem_synopsis: Typical_activity needs a rule !problem_description: !text Typical_activity needs a rule to control which Activity subtypes can point to an instance based on attribute super_kind.
Status: deferred
The application of these properties to rock material is still under review.
0919 Boundary type should be removed
Version: 2.2
Assigned to: Eric Hatleberg
The distinction between boundary_type and boundary_class is unclear. A feature_boundary allows one boundary_type, and many boundary_classes. But no one can give a clear guideline on what should be in boundary_type and what should be in boundary_class. I suggest boundary_type be eliminated, and all classifications be done through boundary_class.
Status: completed

Changes:

  1. 0919.001 Boundary type removed (Delete)
    Boundary classification's functionality was enhanced so it could refer to multiple objects and include various descriptions of a boundary. Duplication of this role was removed by deleting boundary type. Components changed:
0921 pty_bulk_volume only half there
Version: 2.2
Assigned to: Eric Hatleberg
"Bulk Volume" is a term which has two distinct usages. Although the materials-handling definition chosen by Epicentre is the most intuitive, it is in conflict with conventional usage in reservoir analysis. Ther, "bulk volume" is not a volume at all, but a volume fraction used to describe component proportions in (porous) rock. For example, here is the SPWLA definition of "Bulk Volume Water": The quantity of formation water present in a unit volume of rock; the product of Water Saturation and Porosity. There are severral alternatives for dealing with the problem. At the very minimum, the conflict should be documented and a suitable property created for the reservoir people. (e.g., Pty_Bulk_Volume_Fraction). Additionally, to avoid erroneous use bny reservoir people, you could consider replacing Pty_Bulk_Volume by a less ambiguous (albeit less handy) name, such as Pty_Material_Bulk_Volume.

Changes:

  1. 0921.001 Specify condition of pty bulk volume as a volume. (Modify)
    Clarify the name and definition of pty bulk volume total to signify a volume measurement. Components changed:
  2. 0921.002 Add pty bulk volume fraction for percent fraction of volume. (Add)
    Pty bulk volume fraction was added to cover fractional volumes which are used in for bulk volume water in formation evaluation. Components changed:
0922 Pty_Hydrogen_(Oxygen_)Index
Version: 2.2
Assigned to: Eric Hatleberg
Apparently there are at least two common types of "Hydrogen Index." The Epicentre definition is: The mass of hydrocarbon generated by pyrollytic treatment of kerogen as a proportion of the mass of the source organic material. The definition from SPWLA, one with which any petrophysicist is familiar is: The ratio of the number of hydrogen atoms per unit volume of a material to the number in pure water. Hydrogen index is the physical property to which neutron logging responds. Because of this ambiguity, I suggest that Pty_Hydrogen_Index and its sister Pty_Oxygen_Index be renamed to: Pty_Kerogen_Hydrogen_Index Pty_Kerogne_Oxygen_Index
Status: completed

Changes:

  1. 0922.001 Chnage entity name of pty hydrogen index and pty oxygen index (Modify)
    The name of the entity pty hydrogen index has been changed to pty pyrolysis hydrogen index. The name of the entity pty oxygen index has been changed to pty pyrolysis oxygen index. Components changed:
0946 unclassified geologic feature
Version: 2.2
Assigned to: Eric Hatleberg
Users may construct earth model objects of with minimal semantics, such as isothermal surfaces, time lines, or constant saturation zones. These objects are currently forced to be classified as rock features (lithology based), fluid features (fluid based), or other prespecified class. We need a non-abstract geologic feature, which may be further classified in the EPICENTRE hierarchy.
Status: deferred
Much of the semantic of these proposed object are found in current entities but there are potential gaps which are currently being reviewed.
0950 the earth or borehole materials.
Version: 2.2
Assigned to: Eric Hatleberg
Well logging measures the properties of earth materials such as rocks and fluids or the properties of the mud system. As such, the trace values should be modelled as properties of the respective materials.
Status: deferred
Well log traces measure properties of material at a specified location. Further investigation is necessary to reveal the implications of allowing well log traces to characterize a rock material independent of its location and how to accomplish this.
1049 geologic_target and stratigraphic_feature
Version: 2.2
Assigned to: Eric Hatleberg
There does not seem to be any reasonable way to say that the geologic_target that intersects my wellbore is a particular stratigraphic_feature such as a lithostratigraphic_unit. I would think that we should be able to say that the geologic_target is a particular geologic formation; and this doesn't seem to be easily done in v2.0 of Epicentre. It appears that there may be similar problems with the other sub-types of rock_feature; e.g., geologic_structure and drilling_imposed_target.
Status: completed

Changes:

  1. 1049.001 Generalize terminal formation (Duplicate)
    Components changed:
1081 Mistake in definition of lithostratigraphic_unit
Version: 2.2
Assigned to: Eric Hatleberg
The definition of LITHOSTRATIGRAPHIC_UNIT says "Lithostratigraphic bodies are further classified into a hierarchy containing supergroup, group, formation, member, and unit." The last term of the hierarchy should be "bed" instead of "unit".
Status: rejected
Lithostratigraphic unit was deleted to solve another problem.
1094 Unable to load formations, sequences, etc.
Version: 2.2
Assigned to: Eric Hatleberg
For example, I would like to load the Monterey formation(?). At first glance this would be a lithostratigraphic_formation. But the geologic column from which the information is taken calls it a sequence. Which is it? Actually it is both. In fact, it may not be a formation (although that is its name). The problem with Epicentre 2.1b is that I must choose. In this case, I should choose both (and bostratigraphic zone also, since it can be characterized by its fossil content). Also note that there are cases when I don't have any idea which to choose. I can only classify a section of rock as a geologic formation without knowing whether it is lithostratigraphic, stratigraphic, or biostratigraphic. I need geologic_formation to be non_abstract WITHOUT the "must select subtype" rule. I also need to have the and/or available for the subtypes. Alternatively, I could have the geologic_formation be the bottom subtype, with a many-to-many classification.
Status: completed

Changes:

  1. 1094.001 Remove stratigraphic feature subtypes and allow material classification (Duplicate)
    Components changed:
1095 Many classifications of feature boundary.
Version: 2.2
Assigned to: Eric Hatleberg
The base of the Monterey formation (top of the Temblor) is an erosional unconformity. It is recognized on seismic. It can be recognized lithostratigraphically and biostratigraphically. I am unable to instantiate this information. When instantiating this feature boundary, I must first of all pick among stratigraphic_marker, biostratigraphic_marker, chronostratigraphic_marker, and lithostratigraphic_marker. It is in fact all four. Having chosen (arbitratily) one of those four, I would then ilke to classify it. I have two attributes I could use: boundary_type and boundary_classification. Not having clear guidance, I would probably choose boundary_type = 'erosional' (since that is the nature of the boundary), and boundary_classification = {'seismic', 'stratigraphic', 'biostratigraphic', 'choronstratigraphic', 'lithostratigraphic'}. Is this proper? Is this how I store the information that it could be any of these subtypes? Also, I do not see the uniqueness rule on the feature_boundary. This would allow me to store the "base of Monterey' as a lithostratigraphic_marker and as a stratigraphic_marker (and others), when I would probably only want it store once.
Status: completed

Changes:

  1. 1095.001 Expand relationships from geologic feature to boundary classification (Duplicate)
    Components changed:
1096 How do you store marker picks
Version: 2.2
Assigned to: Eric Hatleberg
I wish to store marker picks from a wellbore. I can store these as vertexes (wellbore_point), and store the interval that they demarcate (wellbore_interval). I can now instantiate a relationship from the vertex to a feature boundary to say, for example, that the wellbore_pick ('pick 1') is the 'top of Stevens B', 'pick 2' is the 'top of Stevens C', and the wellbore_interval, 'interval 1' is the 'Stevens B sand'. Is this correct? What if I change my interpretation to say that the 'pick 1' is actually the 'top of Stevens A', and that 'interval 1' is the 'Stevens A sand and Stevens B sand'. It seems that I would be in trouble if I had originally instantiated the relationship to the feature_boundary and the geologic_feature. Another question: How do I say that the 'top of Stevens B' and 'top of Stevens C' are the top and base of the 'Stevens B sand'. On way to do this is to instantiate the many-to-many relationship between a geologic_feature and feature_boundary. Another way is to say that the feature_boundary's have a relationship to a face, which is part of a shell, and the shell is the shell that bounds the region, which is the formation. Are these two methods semantically equivalent? Which is preferred? If I do both, are there consistency rules that govern these relationships? And finally, how do I name these to allow a change of interpretation (the 'top of Stevens B' is the top of Stevens B, but the point I pick, and interpreted to be the top of Stevens B may change to be 'top of Stevens A'.)
Status: completed

Changes:

  1. 1096.001 Expand relationships from geologic feature to boundary classification (Add)
    Boundary classification relationships were augmented to allow the explicit association of a boundary to two objects, primary and secondary. Components changed:
  2. 1096.002 Delete Relationships (Delete)
    Deleted the "represent the boundary of" relationships form from Rock_feature to Feature_boundary and from Rock_fluid_feature to Fluid_feature_contact because they are redundant to the new Boundary_classification relationships. Components changed:
1098 Creation of a reference entity ref_wellbore_interval
Version: 2.2
Assigned to: Eric Hatleberg
In order to map the data needed for the BDPETRO project, we had to create the following extension to the Epicentre model: Reference entity: ref_wellbore_interval Objective: It has been created for the mapping of the data <> and <>. When a core plug is extracted from a core, the <> is the length of the part of the core whose lower point is the center of the core plug, and that is considered to be homogeneous with the core plug. All the analysis made on the core plug will be extrapolated to this part of the core. In the same way the <> is the length of the part of the core whose upper point is the center of the core plug, and that is considered to be homogeneous with the core plug. So, the reference entity ref_wellbore_interval is used to qualify a wellbore_interval in a simple way. Extension: In order to create the entity ref_wellbore_interval, we have adapted the entity ref_wellbore_point.
Status: completed

Changes:

  1. 1098.001 Add kind attribute to core. (Duplicate)
    A core plug sample can be described by its kind (change 0947.001) and shown as extracted from a rock material by the relationship of a rock feature part to a rock material (change 0450.001) Components changed:
1109 Description of boundary_type
Version: 2.2
Assigned to: Eric Hatleberg
Boundary_type is a local reference behavior. It has description attribute. It would be useful to be able to define the boundary types that we instantiate.
Status: completed

Changes:

  1. 1109.001 Boundary type removed (Duplicate)
    Because boundary type was deleted in 0919 the request to add an attribute boundary type.kind is rejected. Components changed:
1131 redundant litho/chronostrat wellbore point
Version: 2.2
Assigned to: Eric Hatleberg
It seems there are two ways to model the fact that a wellbore point may represent a lithostrat or a chronostrat: The first method links the general_wellbore_point.geologic_feature to a lithostratigraphic_unit or a chronostratigraphic_unit. the relationship is direct but it does not allow the point to represent both a lithostrat and a chronostrat (O,K,I:geologic_feature). The other method implies the use of a topological_relationship between the general_wellbore_point and a wellbore_interval representing the lithostrat or chronostrat. To model both geologic_feature, two topological_relationship and two wellbore_interval would be needed. We suggest that the cardinality of the relationship from the general_wellbore_point to the geologic_feature be made as a set[0,?] to represent the concept of a point intersecting both a lithostrat and chronostrat. The semantic of the relationship conforms to this concept: specifies a geologic feature intersecting the path of a wellbore: In general_wellbore_point: geologic_feature (O,K,I: set[0,?] geologic_feature) specifies a geologic feature intersecting the path of a wellbore
Status: completed

Changes:

  1. 1131.001 Remove stratigraphic feature subtypes and allow material classification (Duplicate)
    Components changed:
1134 link wellbore_point to geologic_feature
Version: 2.2
Assigned to: Eric Hatleberg
The same extension as the lithostrat/chronostrat one is required for linking general_wellbore_point to many geologic_feature.
Status: completed

Changes:

  1. 1134.001 Remove stratigraphic feature subtypes and allow material classification (Duplicate)
    Components changed:

Topic: E&P Business

1115 redundant uniqueness rule on depository_designation
Version: 2.2
Assigned to: Robert Aydelotte
The uniqueness rule defined on depository_designation is redundant, since it inherits the uniquenss rule defined on contract_designation.
Status: completed

Changes:

  1. 1115.001 Remove duplicate uniqueness constraint for depository_designation. (Delete)
    The entity depository_designation had two uniqueness conatraints. The local one was deleted. Components changed:
1117 business_associate_privilege.description
Version: 2.2
Assigned to: Robert Aydelotte
Business_associate_privilege.description is mandatory. It should be optional
Status: completed

Changes:

  1. 1117.001 Make description optional in guideline_or_privilege. (Modify)
    The attribute description in guideline_or_privilege was originally defined to be mandatory. It was changed to optional. Components changed:
1159 Add address grouping for a business associate.
Version: 2.2
Assigned to: Gary Masters
Add the capability of specifying, for a Business_associate, a group of addresses with a role (e.g., "West coast office", "residence").
Status: completed

Changes:

  1. 1159.001 Add new entity and new relationships (Add)
    Add new entity Ref_address_qualifier. Add new "be qualified by" relationship from Address to Ref_address_qualifier. Add new "be specified for" relationship from Address to Facility. Add new "be located at" relationship from Phone_number to Physical_address. Add new rule on Address to say that at least one of business_associate or facility must be specified. Components changed:
  2. 1159.002 Modify uniquess constraint and relationship aggregate. (Modify)
    Modify attribute ref_phone_number in Phone_number to be a SET and modify its description accordingly. Modify the uniquess constraint on Phone_number to remove ref_phone_number. Modify the uniquess constraint on all subtypes of Address to add facility. Modify diagram EPB to add new relatinships and new entity. Components changed:
1168 Cannot use REF_CONTRACT_DESIGNATION with INTEREST_DESIGNATION
Version: 2.2
Assigned to: Robert Aydelotte
The attribute INTEREST_DESIGNATION.KIND points to REF_INTEREST_DESIGNATION, replacing CONTRACT_DESIGNATION.KIND (pointing to REF_CONTRACT_DESIGNATION). This removes REF_CONTRACT_DESIGNATION from the subtype. Therefore, an INTEREST_DESIGNATION cannot define a BUSINESS_ASSOCIATE as an "operator" with 53% working interest.
Status: completed

Changes:

  1. 1168.001 Alter attribute name in contract designation (Modify)
    The attribute kind in contract designation has been changed to role and no longer is specialized in interest designation. The uniqueness rules for depository designation and contract designation are changed because they reference the renamed attribute. Components changed:

Topic: Facilities & Equipment

0655 Need simulation well groups
Version: 2.2
Assigned to: Robert Aydelotte
Following a meeting of the parties involved in the Reservoir Simulation Mobil project on December 8th-9th 1994 at the POSC Europe offices, a number of issues arose with regard to the Epicentre data model. The meeting was concerned with the well production aspects of reservoir simulation. This issue was allocated to ERC Tigress for submission to POSC. There is a need to be able to aggregate wells into well groups for simulation purposes. Likewise, it should be possible to form hierarchies of well groups. - required as a basis for controls on simulation runs - required for simulation reporting purposes - well production-related properties need to be provided as attributes for the new well group entity The existing WELL_PATTERN entity did not seem suitable for simulation well grouping purposes.
Status: completed

Changes:

  1. 0655.003 Delete attributes replaced by new relationships (Delete)
    The attributes well_pattern.well_pattern_participation and well_completion.well_pattern_participation were no longer needed with the addition of relationships to product_flow_network_group_participation. Components changed:
  2. 0655.001 Add product_flow_network_group and product_flow_network_group_allocation (Add)
    A new general concept of product_flow_network_group has been added to describe a group of product_flow_network_units. To describe the participants in this group, product_flow_network_group_allocation has also been added. Components changed:
  3. 0655.002 Adjust well_pattern_participation to product_flow_network_group_allocation (Modify)
    The new product_flow_network_group_allocation is the supertype of the existing entity well_pattern_participation. The same applies to product_flow_network_group and well_pattern. Relationships and attributes for these existing entities were modified to accomodate their new subtypes. Components changed:
0699 catalog_equipment not subject to guideline_or_privilege
Version: 2.0
Assigned to: Jenny Meader
CATALOG EQUIPMENT is not related to GUIDELINE OR PRIVILEGE. It should be made a subtype of TYPICAL OBJECT to correct this. This change will allow statements like "this type of pipe should be inspected every two years" to be instantiated in Epicentre.
Status: completed
This change was actually done in v2.0, but was never recorded as completed then.
0734 Seismic vertices
Version: 2.2
Assigned to: Gary Masters
In any description of seismic data, there is a need to select certain points of importance and give their locations. This is generally important so that the survey can be tied to the earth. With all of the points hidden in arrays, it is hard to do this. In particular, it is impossible to give relationships to other entities in Epicentre. For example, I wish to use the "first" station point of a seismic line as the origin or a local coordinate system, or as the shifted origin of a standard projected coordinate system. In order to do this, I need to instantiate a "vertex" that has the semantics of "first shot point". The only vertices I can find that do this would be seismic_facility_node or earth_position_vertex. The seismic_facility_node doesn't work well, because it requires the instantiation of a seismic_facility (which gives more meaning to the station than is intended). The earth_position_node is defined in terms of interpretation. I.e., it does not carry the proper semantics. I would suggest that a seismic_point be related to a seismic_geometry_set and be given a semantic meaning through a type. This would allow us to instantiate "first station", "last station", "bin set corner ..." points, and other earth points of interest.
Status: completed

Changes:

  1. 0734.001 Add new entities and relationships (Add)
    Add entity Seismic_acqusition_vertex with a mandatory relationship to one Seismic_geometry_set. Add entity Seismic_processing_vertex with a mandatory relationship to one Binset_grid. Make both entities subtypes of Technical_object and Earth_surface_point. Add entity Ref_acqusition_vertex to specify the type of array node that the acquisition vertex represents. Add a "be a property of" relationship from Pty_location_2d to the two new vertex entities Components changed:
0854 General facilities have inadequate identification
Version: 2.2
Assigned to: Gary Masters
A General_facility should be able to be identified by one Facility. For example, a Well_logging_system is naturally identified by the Wellbore which is being logged.
Status: completed

Changes:

  1. 0854.001 Add attributes (Add)
    Add new attributes identifying_facility to General_facility and identified_facility to Facility to represent the new relationship. Components changed:
  2. 0854.002 Modify diagram and SI rules (Modify)
    Add the new relationship to diagram EQF1. Add attribute identifying_facility to the Secondary Identifier rule for all subtypes of General_facility. Components changed:
0855 Catalog_bottom_hole_assembly appears to be inappropriate
Version: 2.2
Assigned to: Gary Masters
Catalog_bottom_hole_assembly appears to be inappropriate since a BHA is not manufactured but is dynamically assembled/disassembled at a well site. It would appear to be more appropriate as a Typical_facility.
Status: completed

Changes:

  1. 0855.001 Delete entity. (Delete)
    Delete entity Catalog_bottom_home_assembly. Components changed:
0859 There is no "heavy weight" drill pipe
Version: 2.2
Assigned to: Gary Masters
We either need to add a "heavy weight drill pipe" or modify the description of Drill_pipe to allow it to be classified as "heavy weight". The description of Drill_pipe specifically states that it is "A relatively thin walled" tube.
Status: completed

Changes:

  1. 0859.001 Modify description (Modify)
    Modify the entity description to allow the pipe to be "heavy". Use the definition for "drill pipe" from "Manual of Oil and Gas Terms", Williams and Meyers, 8th edition. Components changed:
0883 optional
Version: 2.2
Assigned to: Jenny Meader
Equipment_item.identifier and Catalog_equipment_item.identifier are optional and they are the only component of the secondary identifier. Does this mean that I can only have one equipment item with a null identifier?
Status: completed
Equipment_item has the following attributes in its secondary identifer: identifier, ref_existence_kind, catalog_equipment. Identifer and catalog_equipment are optional. Catalog_equipment has only identifer included in its secondary identifier and it is optional. This does mean The expected behavior for identifers with optional attributes has now been detailed in the methodology document.
0894 Typical_facility documentation and usage are inconsistent
Version: 3.0
Assigned to: Jenny Meader
Typical_facility appears to be thought of as a type/kind similar to Typical_activity even though it is documented as a reusable design. Typical_facility, Typical_activity, Typical_material and Catalog_equipment all seem to be muddled as to the type/kind versus design issue.
Status: deferred
This will be clarified in version 3.
1043 Problems mapping certain properties into gravel_pack
Version: 2.2
Assigned to: Robert Aydelotte
I'm having problems mapping three different properties into gravel_pack. The first of these is the screen density : That is the number of screen slots per unit length. We have a need for a property that can handle this. The second problem is to map the screen inner and outer diameters into gravel_pack. There is a screen_diameter attribute but this can only map one of these properties. Would there be any way of extending this property to handle a set[0,?] of diameters AND allow us to differentiate between the members of the set?
Status: completed

Changes:

  1. 1043.001 Add screen density, inner and outer screen diameters to gravel_pack. (Add)
    Add attributes screen_inner_diameter, screen_outer_diameter and screen_density to gravel_pack. Components changed:
  2. 1043.002 Delete unspecific diameter from gravel_pack. (Delete)
    Delete screen_diameter from gravel_pack. Components changed:
1051 Create PACKER equipment_item/facility type
Version: 2.2
Assigned to: Robert Aydelotte
There is a need for a PACKER type. When using the set_packer activity it would make sense to be able to hook it up to a PACKER facility.
Status: completed

Changes:

  1. 1051.001 Add new subtypes of wellbore component facility, add attributes (Add)
    Many new subtypes of wellbore component facility are added to describe items found in a typical wellbore schematic. Also, attributes of wellbore tubular facility are added as non-versionable characteristics, together with attributes of other subtypes of wellbore_component_facility as versionable or non-versionable as appropriate. Components changed:
  2. 1051.002 Move and rename subtypes of wellbore component facility (Modify)
    Entities which were subtypes of other entities are moved into wellbore component facility. Some are re-named to make them more consistent and recognizable. This also affected their uniqueness clauses. Components changed:
  3. 1051.003 Remove attributes and entities (Delete)
    Some attributes are now being defined at the supertype level, and are deleted from subtypes. Also, some properties were removed to add as atributes. Components changed:
1058 Need an "electronic document repository" facility for file storage
Version: 2.2
Assigned to: Gary Masters
In order to capture the archiving of a SEG-Y document on a tape, we need to add an entity of the Facility Class, corresponding to the electronic document repository. This entity should be related to 1 or more "electronic documents" and utilize 1 or more "magnetic storage media". This entity should contain information about formatting, operating system, space utilization (blocks/bytes used), file length, and % of media utilized.
Status: completed

Changes:

  1. 1058.001 Add entity (Add)
    Add entity Digital_storate_faciltity as a subtype of General_facility. Components changed:
1124 Generalize facility composition
Version: 2.2
Assigned to: Jenny Meader
The facility_composition has two attributes pointing to the two facilities involved in the composition. The facility_composition.part points to the facility that represent the part and the facility_composition.whole points to a general_facility that points to the whole. Although this model works in most situations, it is not flexible enough to allow a general_facility (e.g. a facility_reference_point) to be part of a facility (well, wellbore, well_completion etc.) We suggest the model be made more generic and allow the part and the whole to point to facility.
Status: completed

Changes:

  1. 1124.001 Add wellbore_component_facility composition behavior (Add)
    The recusive relationship of one wellbore_component_facility assembly pointing to the unique list of the wellbore_component_facilities that are its parts gives most of the required composition behavior, together witht the wellbore_component_facility_connectn association. Components changed:
1170 equipment_class.name too short
Version: 2.2
Assigned to: Jenny Meader
The name attribute in equipment_class is too short to be able to load the POSC/CAESAR snapshot C/D standard instances.
Status: completed

Changes:

  1. 1170.001 Increase the length of the name attribute in classification class (Modify)
    The domain of the name attribute in classification_class has been changed from ndt_name to ndt_long_name. Components changed:
1175 Redundant identifiers
Version: ?
Assigned to: Gary Masters
Facility_reference_point and Injection_facility both have an attribute "identifier" in addition to an inherited attribute "name". Both attributes are part of the secondary identifier.
Status: completed

Changes:

  1. 1175.001 Delete attributes (Delete)
    Delete identifier from entities Facility_reference_point and Injection_facility. Components changed:
  2. 1175.002 Modify uniqueness constraint (Modify)
    Remove identifier from the uniqueness constraint on Facility_reference_point and Injection_facility. Components changed:
1177 Be able to assemble types of equipment
Version: 2.2
Assigned to: Jenny Meader
There are many times in our business when we need to describe the use of a number of items of a given type. The only information we know is the type and the quantity of the items. This is very common in making up casing, tubing, drillstring etc.
Status: completed

Changes:

  1. 1177.001 Add entities to allow equipment composition of catalog_equipment (Add)
    The entities equipment_composition (abstract) and its subtypes, equipment_item_assembly, equipment_item_collection, catalog_item_assembly, catalog_item_collection have been added as a replacement for equipment_item_composition. Catalog_item_assembly and catalog_item_collection have new relationships from catalog_equipment, and the "part" relationship from equipment_item to equipment_item_composition has been replaced with the two relationships from equipment_item; one to equipment_item_collection and one to equipment_item_assembly. Components changed:
  2. 1177.002 Replace equipment_item_composition with equipment_composition (Modify)
    Equipment_item_composition has been deleted and replaced with the more general concept of equipment_composition. Components changed:
  3. 1177.003 Allow catalog_equipment to be installed in a facility (Add)
    Add the following subtypes to equipment_installation: catalog_item_installation and catalog_equipment_installation. Add the attributes that point from these to equipment_item and catalog_equipment respectively and also add the corresponding inverse attributes. The relationship from equipment_item to equipment is installation is replaced by the relationship from equipment_item to equipment_item_installation. Components changed:
  4. 1177.004 Move relationship from equipment_item to equipment_item_installation (Modify)
    The relationship from equipment_item to equipment_installtion has been moved to equipment_item_installation. Components changed:

Topic: Geophysics

0845 Add nominal 3d seismic array description.
Version: 2.2
Assigned to: Gary Masters
Add nominal 3d array description to Seismic_receiver_facility and Seismic_source_facility. For example, group pattern (e.g., linear, parallelogram, rectangle), row count, row spacing, group base length (of row). Element_spacing would then refer to elements within a row. Element_count would then be the total count from all rows.
Status: completed

Changes:

  1. 0845.001 Add attributes (Add)
    Add new attributes row_count, row_spacing and array_base_length to Seismic_receiver_facility and Seismic_source_facility. Add a new instance of Classification_system and several new instances of Facility_class to describe the array pattern. Components changed:
  2. 0845.002 Modify attribute description (Modify)
    Modify the description of element_spacing to restrict it to spacing between elements within a row of a group. Modify the description of element_count to make clear that it is the total of all rows. Components changed:
0846 Need count of acquisition stations.
Version: 2.2
Assigned to: Gary Masters
Need a way of saying that there were N stations independent of how many have been actually instantiated. That is, the number defined may not match the number actually used.
Status: completed

Changes:

  1. 0846.001 Duplicate request (Duplicate)
    This request is a duplicate of request number 1004. Components changed:
0920 Shots are not ordered
Version: 2.2
Assigned to: Gary Masters
Epicentre has the ability to give station ordering using acquisition_index, which is used in conjunction with a seismic station grid. However, there is no such ability to give shot order in conjunction with the source event grid. This capability should be added.
Status: completed

Changes:

  1. 0920.001 Add attribute (Add)
    Add attribute source_event_order to entity Seismic_geometry_set. Components changed:
1000 General objective or purpose of a seismic survey
Version: 2.2
Assigned to: Gary Masters
We need to indicate, in the same way that we do for a well, what is the general purpose of the seismic survey. For the present time we plan to extend Epicentre making a new relation-attribute to SEISMIC GEOMETRY SET : seismic survey purpose.
Status: completed

Changes:

  1. 1000.001 Add new entities and relationships (Add)
    Add new entities Seismic_geometry_classification and Seismic_geometry_class with many-to-one relationships from Seismic_geometry_classification to Seismic_geometry_class and Seismic_geometry_set. Components changed:
  2. 1000.002 Modify diagram. (Modify)
    Modify diagram GPA1 to add entities Seismic_geometry_classification and Seismic_geometry_class. Components changed:
1003 Seismic survey line count
Version: 2.2
Assigned to: Gary Masters
We need to indicate for a seismic survey how many lines have been surveyed in all, independent of the fact they are "source" or "receiver". As it is derived information, we have decided to make an extension in the entity PTY SEISMIC GEOMETRY SUMMARY : line_count.
Status: completed

Changes:

  1. 1003.001 Add new attribute. (Add)
    Add attribute station_line_count. See also Change Request 1004. Components changed:
1004 Seismic survey point count
Version: 2.2
Assigned to: Gary Masters
We need to indicate for a seismic survey how many points have been surveyed in all, independent of the fact they are "source" or "receiver". As it is a derived information we decide to make an extension in the entity PTY SEISMIC GEOMETRY SUMMARY : survey_point_count.
Status: completed

Changes:

  1. 1004.001 Add attributes. (Add)
    Add attributes station_point_count and station_point_total. Components changed:
1006 Seismic line point kind
Version: 2.2
Assigned to: Gary Masters
We need to indicate, for a seismic line, the kind of point this line is made of: source point, receiver point, etc. For the present time we are making an extension in PTY GEOMETRY SUMMARY.
Status: rejected
This semantic is currently supported by attribute ref_seismic_geometry in entity Seismic_geometry_set. The standard instances of Ref_seismic_geometry allow one to say that the line is a "source line" or "receiver line". In future major releases of Epicentre, this semantic may be moved to the new Seismic_geometry_class entity which would allow one to classify the geometry set based on the predominate facility usage of the set.
1011 Antenna - first CDP distance
Version: 2.2
Assigned to: Gary Masters
We need to keep track of the distance in between the antenna and the first Common Data Point. As we don't see this attribute in Epicentre, we are making an extension of PTY SEISMIC GEOMETRY SUMMARY.
1143 Cannot assert usage of seismic facilities without specifying attibutes
Version: 2.2
Assigned to: Gary Masters
Rule "val11" and the documentation for attribute seismic_facility in entity Seismic_geometry_set prevent me from asserting that facilities were used without specifying the attributes which give the detailed usage.
Status: completed

Changes:

  1. 1143.001 Modify attribute description. (Modify)
    Modify the description of attribute seismic_facility in order to change "must be used" to "may be used". Modify rule "val11" to allow attribute seismic_facility to exist without the other attributes. Components changed:
1161 Add a near source flag for each bin node.
Version: 2.2
Assigned to: Gary Masters
Add an attribute to entity Binset_grid which specifies whether or not each bin node was "near" any source event. This would allow one to say that a source event occurred at or near each node without knowing the specific source event.
Status: completed

Changes:

  1. 1160.001 Add new attribute. (Add)
    Add new attribute bin_source_event_logical of type ndt_logical_array. Components changed:
1163 Add description of each bin node.
Version: 2.2
Assigned to: Gary Masters
Add an attribute which allows a description to be defined at each node of entity Binset_grid
Status: completed

Changes:

  1. 1163.001 Add new attribute (Add)
    Add attribute bin_node_description with a new type ndt_comment_array. The ndt requires a new Ref_property_set instance of "comment only" with a corresponding new Ref_descriptive_property instance of "comment". Components changed:
1164 Add acquisition outline to seismic geometry sets and Binset
Version: 2.2
Assigned to: Gary Masters
Add an "acquisition outline" attribute to entities Seismic_geometry_set and Binset. This would represent a "map view" geometrical outline of the set (e.g., Pty_geometry_2d_ring).
Status: completed

Changes:

  1. 1164.002 Modify uniqueness constraint (Modify)
    Modify the uniquess constraint on Pty_geometry_2d_ring to add attributes seismic_geometry_set and binset_grid. Components changed:
  2. 1164.001 Add relationship (Add)
    Add a relationship from one Seismic_geometry_set to many Pty_geometry_2d_ring. Add a relationship from one Binset to many Pty_geometry_2d_ring. Components changed:
1165 Add section count to seismograph platform.
Version: 2.2
Assigned to: Gary Masters
Add a "section count" attribute to entity Seismograph_platform.
Status: completed

Changes:

  1. 1165.001 Add attribute (Add)
    Add new attribute section_count to entity Streamer. Components changed:
1166 Add nominal sweep taper length to seismic source facilities.
Version: 2.2
Assigned to: Gary Masters
Add a "nominal sweep taper length" attribute to entity Seismic_source_facility.
Status: completed

Changes:

  1. 1166.001 Add new attribute. (Add)
    Add new attribute vibrator_sweep_taper_length. Components changed:
1167 Add nominal depth to seismic receiver facilities.
Version: 2.2
Assigned to: Gary Masters
Add a "nominal depth" attribute to entity Seismic_receiver_facility
Status: completed

Changes:

  1. 1167.001 Add attribute. (Add)
    Add new atribute nominal_receiver_depth. Components changed:

Topic: High Level

0535 'kind' attribute for 'other_xxx' entities
Version: 2.2
Assigned to: Jenny Meader
Epicentre V2.0 (Snapshot) provides a number of entities named "other_xxx". For example, "other_earth_surface_boundary" and "other_earth_surface_area". These typically represent subtypes of the "d - none of the above" variety and reflect the inability to catalog all possible subtypes of a supertype. However, in any given implementation, one may want to further typify the "other_xxx" entity. This would best be done using a "kind" attribute whose type is a companion local reference entity (e.g., "ref_other_xxx_kind"). We have noted the following "other_xxx" entities where this is needed: other_activity other_composite_spatial_object other_earth_surface_area other_earth_surface_boundary other_fluid_sample (note that other_material already has a "kind") other_observation_event other_typical_facility POSC should consider adding a "kind" attribute to these. Our modeling efforts are assuming this will be done.
Status: rejected
The behavior of "other_" entities was made consisitent in the v2.0 release by removing all the "kind" attributes.
0644 Logical delete flag required for reference data
Version: 2.2
Assigned to: Jenny Meader
We would like a logical delete flag on all reference data instances. This is assuming that once a reference instance has been instantiated, it will never be deleted, even if it becomes obsolete in future versions of Epicentre. A boolean, with "true" for a value that is currently valid and "false" for those that are obsolete would do it.
Status: completed

Changes:

  1. 0644.001 Add status and version information to standard instances (Add)
    The optional attributes status and version have been added to referebnce_behavior. Status is a list of standard values controled by an enumerated data type, and version is a relationship to an open reference entity. The status attribute gives information of the status of the instance, for example; current,provisional, deprecated, and version gives the version of Epicentre when this status was assigned to this instance of reference_behavior. Components changed:
0749 Natural Keys for Alias
Version: 2.2
Assigned to: Jenny Meader
Object_alias has as its natural keys (K): effective_date, expiry_date, and ref_naming_system. Not included in the natural keys are: identifier, and the (in each subtype) reference to the object. Although both of these are mandatory. Identifier should be part of the natural keys. Probably, also, should be the reference to the object.
Status: completed

Changes:

  1. 0749.001 Add object subtype into alias secondary identifiers (Modify)
    The follwoing subtypes of object_alias did not include the object they are an alias for in their uniqueness clause. This has been rectified. The identifier attribute in the alias subtypes in NOT included as part of the uniquness clause as this would mean that for a given ref_naming_system, at a given period of time, there could be more than one possible value of an alias for an object. So, for example, a well could have several API numbers at the same time. This is not hte behavior needed. Components changed:
0768 Inconsistent naming in class and classifications
Version: 2.2
Assigned to: John Bobbitt
Consider material_class, facility_class, equipment_class and their respective class_classifications (material_class_classification, etc.) All three class_classifications have member as a relationship. The inverse of these are (resp) material_class_classification, facility_class_members, equipment_class_classification. The other (the parent) relationship is classification (in material_class_classification), and class_of in the other two. This is a minor inconsistency. But the inverses (resp) are classified, facility_class_classification, and equipment_class_members. Put these into a table, and you will see the inconsistencies. Since the definitions of these inverse relationships aren't meaningful, it is difficult to determine which inverse goes with which forward. I have not looked at the other class_classifications that exist, but the problem is probably still present with those.
Status: completed

Changes:

  1. 0768.001 Add rule that constrains the Ref_quantity_property instance specified by each Coordinate_system_axis to be in the set allowed by the specified instance of Ref_coordinate_system_constraint. This rule is not currentlysupportable by POSC because functions are not supported. The rule has been included as a remark in order to show the intent of the model. (Modify)
    Add new rule.
0867 identifier?
Version: 2.2
Assigned to: Jenny Meader
What is the expected behavior when "null" values are in a secondary identifier? This definition will be required for interoperability.
Status: completed
A paragraph explaining the expected behavior has been added to the POSC Epicentre Methodology document, within the section on Secondary Identifiers, that describes the expected behavior.
0884 description attribute
Version: 2.2
Assigned to: Jenny Meader
Boundary_type and Relative_rank (reference behavior) do not have a description attribute. Perhaps all reference behaviors should be checked.
Status: completed

Changes:

  1. 0884.002 Boundary type deleted ()
    Because boundary type was deleted in 0919 the request to add an attribute boundary type.kind is rejected. Components changed:
  2. 0884.001 Add a description attribute to subtypes of reference_behavior (Add)
    An optional description attribute was added to all the subtypes of reference_behavior from which it was missing and was required. Components changed:
0905 Grid_modification attribute need better documentation
Version: 2.2
Assigned to: Robert Aydelotte
Grid_modification.first_element and second_element should be documented as to how to calculate the values [i.e., i + (j-1) ni + (k-1) ni nj].
Status: completed

Changes:

  1. 0905.001 Modify description of attribute first_element (Modify)
    Add formula to descripiton of first_element in grid_modification. Components changed:
  2. 0905.002 Modify description of attribute second_element. (Modify)
    Add formula to descripiton of second_element in grid_modification. Components changed:
0927 ref_currency_unit should reference acronym
Version: 2.2
Assigned to: Jenny Meader
As presently instantiated, ref_currency_unit attributes name and acronym are given and are unique for each instance. Recommend that ndt_currency be altered to reference ref_currency_unit.acronym rather than ref_currency_unit.name. This would allow the dae to change its structure also. This would require also that acronym be made mandatory.
Status: completed

Changes:

  1. 0927.001 Use acronym to reference ref_currency_unit instead of name (Modify)
    The si identifier of the entity ref_currency_unit has been modified from name to acronym. Components changed:
1047 Add preferred well location
Version: 2.2
Assigned to: Jenny Meader
In V2.0 Epicentre data model, there is no place to identify a preferred well location in the well location property table. There is a business need to identify which location is a preferred one. A possible solution is to add a column 'Preferred' to the well location property table to indicate the location preference This request is resulted from a discussion at the Landmark Seismic Subsetting workshop from 1/22-1/26/96 and we would like it to be included in the Epicentre 2.1 release.
Status: completed

Changes:

  1. 1047.001 Add preferred property behavior to Epicentre (Add)
    The boolean flag "preferred_flag" was added to the entity Property. If the value of this is True then this is the preferred value of this property type for the object which it describes. Components changed:
1062 connected attribute for grids
Version: 2.2
Assigned to: Robert Aydelotte
The connected attribute for grid_1d_equal is not well-defined. It should be made clearer of the effects for data that does not use the full grid. The connected attribute should be given for grid_parametric and grid_1d_unequal, with the above sentence in mind.
Status: completed

Changes:

  1. 1062.001 Change definition of connected in grid_1d. (Modify)
    Definition of attribute clarified to describe behavior of connected grids. Components changed:
1084 attributes
Version: 2.2
Assigned to: Jenny Meader
Object_of_interest is described as having only identifying attributes and relationships (changes to which give [rise to] a new instance), and relationships to property subtypes (which could change without giving rise to a new instance). Actually there may be (and invaribly are) attributes which are not identifying, and which can change without giving rise to a new instance, and yet are not relationships to property subtypes.
Status: completed

Changes:

  1. 1084.001 Correct description of Object_of_interest (Modify)
    Object_of_interest was previously described as having only identifying attributes (changes to which give rise to a new instance), and relationshipsto property subtypes. In fact, there may be attributes that are not identifying, and which can change without giving rise to a new entity. The description of Object_of_interest now reflects this. Components changed:
1110 Peculiar wording on attribute definition: object_of_ranking
Version: 3.0
Assigned to: Eric Hatleberg
The definition given for the object_of_ranking attribute for object_of_interest and all of its subtypes is peculiar.
Status: deferred
This is not currently broken, but may be re-visited for the property model changes in v3
1142 missing elements
Version: 2.2
Assigned to: Gary Masters
The behavior of missing elements on grids composed of other grids is unclear when the component grids themselves have missing elements. The behavior should documented to be cumulative with the composed grid inheriting all characteristics of the component grids. For example, in seismic a 2D binset grid may have missing elements such that the grid is L shaped. If a 3D data set (cube) is formed using the 2D binset grid plus a 1D vertical time grid then the "columns" of the cube should be considered missing.
Status: completed

Changes:

  1. 1142.001 Alter description of attribute. (Modify)
    Alter the description of attribute missing_element to clarify the behavior. Components changed:
1144 Length of NDT_Name of 40 characters is too short
Version: 2.2
Assigned to: Jenny Meader
We have hit a situation that the identifier field of 40 characters is too short to accomodate some data being migrated from legacy databases. We have had to extend the following columns to 50 characters as a temporary workaround, but would like to see a general extension of the NDT_Name field to 50 or more characters covering all attributes that are based on NDT_Name: Table Name Attribute Name ============ ============== BSASC bsasc_id BSASC_ALIAS id COORDINATE_SYS coordinate_sys_id CORD_SYS_ALIAS id FIELD field_id ERTH_SFTR_ALIAS id WELL well_id WELL_ALIAS id WELLBORE_ALIAS id Note that while the wellbore_id in table WELLBORE is defined as 50 characters, the id column in WELLBORE_ALIAS is only 40!
Status: completed

Changes:

  1. 1144.001 name domain too short for some requirements (Modify)
    40 characters is too short for Geopoliticial_feature names. The identifier inherited from the supertype, Earth_surface_feature, was modified to have a new ndt, ndt_long_name. The Earth_surface_feature_alias identifier was changed to ndt_long_name to correspond. The identifier was moved from the supertype of Eaarth_surface_feature_alias, object_alias, and put into all of its subtypes, with the same ndt domain (ndt_name) for everyhting except for Earth_surface_feature alias. Components changed:
  2. 1144.002 move identifier attributes from object_alias to subtypes (Add)
    To handle name length change for earth_surface_feature and its alias, the identifier attribute of object_alias has been removed and an equivalent attribute added at the subtype level Components changed:
  3. 1144.003 lengthen earth_surface_feature name and remove identifier from object_alias (Delete)
    To handle name length change for earth_surface_feature and its alias, the identifier attribute of object_alias has been removed and an equivalent attribute added at the subtype level Components changed:

Topic: Materials

0450 Classification schemes: Geologic Features
Version: 2.2
Assigned to: Eric Hatleberg
Many existing systems permit user-defined geological classification schemes. In general, these schemes provide relationships to order the different classes (cf subtypes of chronostratigraphic unit) and to aggregate finer classifications into coarser ones (cf contain/be_a_part_of for chronostrats, lithostrats and