Recent POSC Problem Reports and Change Requests

Updated: 12 December 1996

Epicentre Data Model

Request Number: 156	Date submitted: Mar 15 1994
Product: Epicentre Data Model
Status: resolved	Date resolved: 24 Oct 1996
Title: Subset Rule 12 only for mandatory relationships
Description: P1-19:- Subset RULE 12 should read "...if and only if there are no MANDATORY external relationships attached..."
Resolution: This error was fixed in v2.0.
-------------------------------------------------------------------------------------------
Request Number: 306	Date submitted: 14 Jun 1994
Product: Epicentre Data Model	Subsystem: Reference Code
Status: resolved	Date resolved: 24 Oct 1996
Title: Reference entity values for well status kind and condition
Description: A list of [company] codes for well status kind were submitted (by fax) for consideration. A list of [company] codes for well status condition were submitted (by fax) for consideration. No definitions accompanied the codes.
Resolution: I believe that POSC cannot make these well code part of the standard for two reasons: these are [company] codes and not public standards, and, they have no accompanying definitions.
-------------------------------------------------------------------------------------------
Request Number: 587	Date submitted: 14 Nov 1994
Product: Epicentre Data Model
Status: resolved	Date resolved: 24 Oct 1996
Title: Denormalize temperature and make it an attribute of p_electric_resvy
Description: From mapping well log header data (from a real well log - not from PI data), I would suggest the following improvement: I believe the resistivity of the mud is useless without knowing the temperature at which the resistivity measurement was made. There are two problems here: a) you need to denormalize temperature along with resistivity, and b) it seems like temperature needs to be an attribute of p_electric_resvy. Right now, the only way I could tie the temperature to the resistivity is to create an activity of measuring the mud.
Resolution: An attribute of temperature was added to Pty_electric_resistivity in release 2.1
-------------------------------------------------------------------------------------------
Request Number: 717	Date submitted: 06 Apr 1995
Product: Epicentre Data Model
Status: resolved	Date resolved: 24 Oct 1996
Title: Need to differentiate between area and surface area
Description: PTY_SURFACE_AREA is defined as "the amount of surface occupied by an object expressed in units of length squared." It is unclear if this means the gross area of a surface (i.e., a surface with dimensions of 2 cm by 3 cm is 6 cm2) or the surface area of a volume (i.e., a 2 cm3 lump of charcoal has a surface area of 1e6 m2). The latter is important when describing porous media exposed to chemically reactive fluids (e.g., methane in coal beds).
Resolution: Pty_surface_area was re-named Pty_area to reflect its true meaning. Pty_internal_Surface_area was added as a new concept (a new entity). Entities that previously had relationships to pty_surface_area had these replaced with relationship to pty_area and a relationship to Pty_internal_surface_area was added to the entity Rock_material
-------------------------------------------------------------------------------------------
Request Number: 718	Date submitted: 06 Apr 1995
Product: Epicentre Data Model
Status: resolved	Date resolved: 24 Oct 1996
Title: Cement sheath in wellbore is defined twice
Description: The entity POSITION_IN_WELLBORE has a relationahip to CEMENT which is defined as "Specifies the cement sheath which is positioned at this location". Also, a subtype of WELLBORE_COMPONENT_FACILITY called WELLBORE_CEMENT_SHEATH is defined as "The protective covering around a casing string within a wellbore. The cement sheath is intended to bond to both the casing string and the formation to provide stability and to bar fluid flow". This entity is related to MATERIAL_INSTALLATION to define the CEMENT used. Only one option should be defined.
Resolution: The relationship to Cement from Position_in_wellbore has been removed in release 2.1.
-------------------------------------------------------------------------------------------
Request Number: 721	Date submitted: 06 Apr 1995
Product: Epicentre Data Model
Status: resolved	Date resolved: 24 Oct 1996
Title: Use PTY_POPULATION to describe the population of an EARTH_SURFACE_AREA
Description: The property PTY_POPULATION is only attached to OTHER_SPATIAL_OBJECT, but should be used to describe the population of an EARTH_SURFACE_AREA; a new property of population density should also be defined: * make PTY_POPULATION a transient property * create new property of PTY_POPULATION_DENSITY (domain of "real/area") * attach PTY_POPULATION and PTY_POPULATION_DENSITY to EARTH_SURFACE_AREA
Resolution: The entity Pty_population_density was created as a subtype of Transient_property. A relationships to this entity was added to the entity Earth_surface_feature. These changes were effected in release 2.1.
-------------------------------------------------------------------------------------------
Request Number: 737	Date submitted: 13 Apr 1995
Product: Epicentre Data Model	Subsystem: Geophysics
Status: resolved	Date resolved: 24 Oct 1996
Title: Cannot describe bin nodes on a 2d line
Description: I have a 2d seismic line with stations at 55 ft intervals. I set up a local coordinate system with a single axis, and whose origin will be at the first station. I can then give locations as 0., 55., 110., 165., ... When I tried to do this in Epicentre, I found that only pty_geometry_2d_edge is supported. This requires me to set up a dummy axis and assign all 0's to it. I would suggest that pty_geometry_1d_edge also be in binset.
Resolution: An optional, one to many relationship was added for Binset and Pty_geometry_1d_edge. Binset was added to the uniqueness rule defined on the subtypes of Pty_geometry_1d_edge (i.e. Pty_geometry_simple_1d_edge and Pty_geometry_complex_1d_edge).
-------------------------------------------------------------------------------------------
Request Number: 778	Date submitted: 23 Jun 1995
Product: Epicentre Data Model
Status: resolved	Date resolved: 24 Oct 1996
Title: Inconsistent standard instances logical/relational
Description: The entity LITHOLOGY TYPE is a populated open reference entity in the logical specification. However, the relational table LITHOLOGY TYPE is not declared to be an open reference entity, and is not populated in the standard instances of the relational implementation.
Resolution: Lithology_type was converted to a local reference entity, as POSC provides no standard instance population for this entity. This change was effected in v2.1 release.
-------------------------------------------------------------------------------------------
Request Number: 843	Date submitted: 11 Aug 1995
Product: Epicentre Data Model
Status: resolved	Date resolved: 24 Oct 1996
Title: Cannot relate some Seismic_facilities to Seismic_geometry_set unless the details are also specified
Description: I cannot relate Seismic_facilities to Seismic_geometry_set unless the details are also specified. This is a result of the overly restrictive view that the relationship is only to support UID information. Proposed solution: 1) Eliminate the "limited use" relationships between them (i.e., Seismic_geometry_set attributes seismic_source_facility and seismograph_facility). Use the fact that only one Seismic_source_facility (or seismograph, etc) is in the general relationship in order to document the "limited use". 2) Modify the rules accordingly.
Resolution: The attributes Seismic_geometry_set.seismic_source_facility and Seismic_source_facility.limited_usage which represent the "limit use to/have limited use by" relationship between the entities have been deleted. The attributes Seismic_geometry_set.seismograph_facility and Seismograph_facility.limited_usage which represent the "limited use to/have limited use by" relationship between these entities have been deleted. The optional select rules (val1 and val2) on the entity Seismic_geometry_set have been deleted to align with the deletion of the attributes they constrain The attribute seismic_source_facility was removed from rule val5 on seismic_geometry_set. The attribute seismograph_facility was removed from rule val10 on seismic_geometry_set. These changes were all effect by release 2.1
-------------------------------------------------------------------------------------------
Request Number: 865	Date submitted: 16 Aug 1995
Product: Epicentre Data Model
Status: resolved	Date resolved: 24 Oct 1996
Title: PTY SPECIFIC AREA and PTY SURFACE AREA PER VOLUME have equivalent entity definitions
Description: The two property entities, SPECIFIC AREA and PTY SURFACE AREA PER VOLUME have entity definitions which are not sufficiently distinct. Their use is therefore ambiguous.
Resolution: This change request is a duplicate of change request 717, which has been resolved in release 2.1 by the renaming of pty_surface_area to pty_area and the introduction of a new entity Pty_internal_surface_area.
-------------------------------------------------------------------------------------------
Request Number: 879	Date submitted: 16 Aug 1995
Product: Epicentre Data Model
Status: resolved	Date resolved: 24 Oct 1996
Title: Well_log is not identified by the Wellbore that it represents
Description: Neither attribute wellbore nor attribute earth_surface_feature are part of the secondary idenfifier of a Well_log.
Resolution: Wellbore and Earth_surface_feature are now part of the secondary (natural) identifier of Well_log. This change effected in release v2.1.
-------------------------------------------------------------------------------------------
Request Number: 880	Date submitted: 16 Aug 1995
Product: Epicentre Data Model
Status: resolved	Date resolved: 24 Oct 1996
Title: A Well_log_trace is not identified by ref_well_log_trace
Description: Attribute ref_well_log_trace is not part of the secondary identifier of a Well_log_trace.
Resolution: Ref_well_log_trace has been added to the uniqueness clause of Well_log_trace. This change was made in the v2.1 release.
-------------------------------------------------------------------------------------------
Request Number: 882	Date submitted: 16 Aug 1995
Product: Epicentre Data Model
Status: resolved	Date resolved: 24 Oct 1996
Title: Attribute characterize is optional in the association entity Component_material
Description: Attribute characterize is optional in the association entity Component_material.
Resolution: The attribute characterize is now mandatory. This change was made in the v2.1 release.
-------------------------------------------------------------------------------------------
Request Number: 887	Date submitted: 16 Aug 1995
Product: Epicentre Data Model
Status: resolved	Date resolved: 24 Oct 1996
Title: Cement needs more identification
Description: Cement has only the mandatory ref_existence_kind as part of its secondary identifier. This means that I can have one instance of "planned" and one instance of "actual" cement.
Resolution: The optional attribute identifier has been added to the entity Cement and has been included in the uniqueness clause for this entity. This change made for release 2.1.
-------------------------------------------------------------------------------------------
Request Number: 895	Date submitted: 16 Aug 1995
Product: Epicentre Data Model
Status: resolved	Date resolved: 24 Oct 1996
Title: Material_sample needs more identification
Description: A Material_sample is not identified by the Sample_acquisition activity which acquired it or the Materials_processing activity which produced it.
Resolution: The attributes Produced_by_activity and Source_activity have been added to the uniqueness clauses of all subtypes of Material_sample (i.e. filter_cake, fluid_sample, and subtypes of Rock_sample:Core,drill_cuttings_sample, outcrop_sample, paleontology_slide, rock_powder_sample, rock_thin_section). These changes made in release v2.1.
-------------------------------------------------------------------------------------------
Request Number: 902	Date submitted: 16 Aug 1995
Product: Epicentre Data Model
Status: resolved	Date resolved: 24 Oct 1996
Title: Add rule to Pty_transient_property
Description: We appear to need a rule on Pty_transient_property that disallows end_time when ref_transient_period is "event".
Resolution: Rules were added to correctly govern the behavior of start_time and end_time in Activity, Pty_transient_property and Transient_association The change was made in release v2.1.
-------------------------------------------------------------------------------------------
Request Number: 918	Date submitted: 29 Aug 1995
Product: Epicentre Data Model
Status: resolved	Date resolved: 24 Oct 1996
Title: Boundary class has too many names
Description: Boundary_class has an attribute "name" and an attribute "kind," both of which mean the same thing. One should be removed.
Resolution: The local attribute Kind was removed from Boundary_class and from the uniqueness constraint. This change was made in v2.1.
-------------------------------------------------------------------------------------------
Request Number: 965	Date submitted: 16 Oct 1995
Product: Epicentre Data Model
Status: resolved	Date resolved: 24 Oct 1996
Title: Add display convention for LOCAL COORDINATE SYSTEM
Description: When a spatial object is described using a LOCAL COORDINATE SYSTEM, there is no means to discern how to render the object graphically - and current application vendors have different defaults. Therefore, add an optional attribute to LOCAL COORDINATE SYSTEM called REF DISPLAY ORIENTATION that specifies the default location of the origin of the rendering. This as a new subtype of REF CODE and should be an open reference entity. The population of REF DISPLAY ORIENTATION should include: L - left side of 1d R - right side of 1d U - top side of 1d D - bottom side of 1d LU - left upper corner of 2d RU - right upper corner of 2d LD - left lower corner of 2d RD - right lower corner of 2d LUF - left upper front corner of 3d LUB - left upper back corner of 3d LDF, LDB, RUB, RDB, RUF, RDF as other corners of 3d
Resolution: The reference entity Ref_display_orientation was added as a subtype of Ref_code. The relationship attribute Ref_display_orientation was added to Local_spatial_coordinate_system. Standard values were loaded into Ref_display_orientation. These changes were made in release v2.1.
-------------------------------------------------------------------------------------------
Request Number: 1015	Date submitted: 14 Nov 1995
Product: Epicentre Data Model
Status: resolved	Date resolved: 24 Oct 1996
Title: Data type required for exchange profile specification
Description: Exchange profiles and other exchange descriptors are specified in terms of sets of PSQL statements. A data type is required for these statements. The requested data type is: name: ndt_sql description: This describes the domain for a POSC SQL statement. Epicentre data type: string maximum number of characters: <unlimited> length type: variable The domain will be specified in the DAE sub-schema of Epicentre, and should be supported by projection methods, etc.
Resolution: A new data type, ndt_long_sql, has been introduced to support PSQL statements used in data exchange operations. This change was made in release v2.1
-------------------------------------------------------------------------------------------
Request Number: 1102	Date submitted: 24 Jun 1996
Product: Epicentre Data Model
Status: resolved	Date resolved: 24 Oct 1996
Title: Optional inverse singular relationships are implied to be mandatory.
Description: In versions of Epicentre previous to V2.0, optional inverse relationships with a cardinality of one were specified using BAG[0:1]. Beginning in V2.0 the BAG was dropped which implies that the attribute is required for an instance to exist. An example of this is the relationship between CONTRACT and CONTRACT_REMARK where the V2.0 Browser dictionary report specifies that a CONTRACT_CLAUSE has a BAG[0:1] inverse relationship to CONTRACT but the EXPRESS file does not specify an aggregate.
Resolution: The cardinality of BAG[0:1] has been restored for the following attributes; contract_clause.contract, proved_reserves.derived_from, ref_customery_unit_of_measure.first_si_conversion, geodetic_datum.geocentric_coordinate_system, binset_intersection.intersecting_geometry, ref_currency_unit.larger_unit, topological_object.source_space_time_operation, material_classification.uncertainty_class, well.well_surface_point, coordinate_system_axis.coordinate_system These changes were made in release v2.1.
-------------------------------------------------------------------------------------------
Request Number: 1115	Date submitted: 06 August 1996
Product: Epicentre Data Model
Status: assigned	Date resolved: 24 Oct 1996
Title: redundant uniqueness rule on depository_designation
Description: The uniqueness rule defined on depository_designation is redundant, since it inherits the uniqueness rule defined on contract_designation.
-------------------------------------------------------------------------------------------
Request Number: 1116	Date submitted: 19 Aug 1996
Product: Epicentre Data Model	Subsystem: Coordinate System
Status: assigned	Date resolved: 24 Oct 1996
Title: Applied coordinate transformation rule too restrictive
Description: 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.
-------------------------------------------------------------------------------------------
Request Number: 1117	Date submitted: 21 Aug 1996
Product: Epicentre Data Model
Status: assigned
Title: business_associate_privilege.description
Description: Business_associate_privilege.description is mandatory. It should be optional
-------------------------------------------------------------------------------------------
Request Number: 1118	Date submitted: 22 Aug 1996
Product: Epicentre Data Model
Status: assigned
Title: Need soil rock mechanics in data model
Description: Our department, Marine Surveys, is also working with geotecnique and rock soil mechanics. We cannot find these items in POSC's list of datamodel. Is this correct ? Do you have plans for including these items ? If yes, what is the time schedule?
-------------------------------------------------------------------------------------------
Request Number: 1119	Date submitted: 04 Sep 1996
Product: Epicentre Data Model
Status: assigned
Title: Need to find type of projection used
Description: I am currently trying to develop an application that extracts well coordinates from an Epicentre database in which I have loaded the Haddock dataset, in order to produce a map that shows the position of each well. The problem I have is that the coordinates that are stored in the database are projected coordinates, and in order to produce a map I need to have the corresponding geographical coordinates expressed In the WGS 72 geodetic datum. I managed to find the definition of the coordinate system in which the projected coordinates are stored, but I could not find which type of projection was used. Could you please tell me where that information is stored?
-------------------------------------------------------------------------------------------
Request Number: 1120	Date submitted: 08 Oct 1996
Product: Epicentre Data Model
Status: assigned
Title: earth_surface_feature should have identifier
Description: earth_surface_feature has 10 subtypes. Nine 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.
-------------------------------------------------------------------------------------------
Request Number: 1122	Date submitted: 10 Oct 1996
Product: Epicentre Data Model
Status: assigned
Title: inadequate licensing round information
Description: The licencing round activity does not seem to be clearly defined in Epicentre. The licencing round is the activity of allocating licences for a group of blocks as part of periodic rounds. The basic requirement of a licensing_round activity would be to define many surface_agreement that apply to many blocks (legal_survey_area). The licensing_round entity would have the general activity behavior and an additional attribute as follows: In surface_agreement: licensing_round (O, K: licensing_round) indicates the licencing round that defined this surface agreement. In licensing_round: surface_agreement (O, V: set[0,?] surface_agreement) specifies the surface agreements defined by the licensing round.
-------------------------------------------------------------------------------------------
Request Number: 1123	Date submitted: 10 Oct 1996
Product: Epicentre Data Model
Status: assigned
Title: generalize terminal formation
Description: The terminal formation of a drilled borehole may be reported as a lithostrat or chronostart or sometimes other geologic features. A modification to the model is required for changing the destination entity of the attribute wellbore.terminal_formation to point to a rock-feature instead of being restricted to a lithostratigraphic_unit: In wellbore: terminal_formation (O: rock_feature) The rock feature within which the wellbore terminates.
-------------------------------------------------------------------------------------------
Request Number: 1124	Date submitted: 10 Oct 1996
Product: Epicentre Data Model
Status: assigned
Title: generalize facility composition
Description: The facility_composition (and its two subtypes facility_assembly and facility_collection) 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 represent the whole. Although this model works in most situations, it is not flexible enough to allow a general_facility (i.e. a facility_reference_point) to be part of a facility (Well, wellbore, well_completion,etc..). We suggest the model should be made more generic and allow the part and the whole to point to facility.
-------------------------------------------------------------------------------------------
Request Number: 1125	Date submitted: 10 Oct 1996
Product: Epicentre Data Model
Status: assigned
Title: casing diameter inadequate
Description: The model seems to have a weakness for describing outside casing diameters. The entity that describes diameters in Epicentre is called pty_diameter regardless of being inner or outer diameters. The property is linked to the casing_string entity through the casing_string attribute. However, the inverse attribute from the casing_string to the pty_diameter is restricted to be the inner diameter only: effective_inner_diameter. The model needs to be changed to describe any diameter in the following manner: The casing_string.effective_inner_diameter would be changed to casing_string.effective_diameter. The pty_diameter entity needs a new attribute ref_diameter_type to type the diameter. This attribute would point to an fixed reference entity ref_diameter_type. The ref_diameter_type would have the following description: name ndt_name description ndt_comment code_alias ref_code_alias source ref_source source_reference ref_source_reference The values held in attribute name would be "inner" and "outer".
-------------------------------------------------------------------------------------------
Request Number: 1126	Date submitted: 10 Oct 1996
Product: Epicentre Data Model
Status: assigned
Title: formation integrity test missing
Description: Formation Integrity Tests can not currently be described in Epicentre. The definition of the Typical_activity value well step rate test complies with the definition of a FIT, but the model relates it as a sub-kind of well_potential_test whose definition differs completely from the definition of a Formation Integrity Test. An extension is required to describe any kind of integrity test within a wellbore by applying pressure. We suggest the following entity extension: Pressure Integrity Test A test to establish the integrity of the mechanical wellbore components or the borehole formations under pressure. During this test, fluid is pumped at a series of increasing rates, usually of a fixed time period and the resulting pressure at each rate measured. These tests usually occur during drilling operations. Typical examples include Formation Integrity Test, Leak Off Tests, Casing Shoe Tests, Cement Integrity Tests,etc. The Pressure Integrity Test entity would be a subtype of wellbore_activity with one additional attribute well_operation_fluid being a relationship to the well_operation_fluid entity.
-------------------------------------------------------------------------------------------
Request Number: 1127	Date submitted: 10 Oct 1996
Product: Epicentre Data Model
Status: assigned
Title: pressure integrity test inadequate
Description: The maximum prior surface pressure, stable surface pressure are all qualifiers of a pressure measurement made at the wellhead during a test when a leak off occured. The ref_property_qualifier entity describes this in Epicentre, but is currently only available in the Facilities & Equipment model through the pty_equipment_facility entity. It is not available in the specific property model, thus requiring an extension. We recommend that the ref_property_qualifier be linked to the specific property model at the property entity level. We also recommend that the ref_kind_descriptor be also linked to the property entity.
-------------------------------------------------------------------------------------------
Request Number: 1128	Date submitted: 10 Oct 1996
Product: Epicentre Data Model
Status: assigned
Title: missing cement density characteristic
Description: The cement used for a borehole cementation may be characterized by a volumic mass pty_density_liquid. Epicentre does not currently allow this description and we suggest the following attribute extension in the pty_density_liquid entity: cement (O,K: cement) may be a property of and the following attribute in cement: pty_density_liquid (O,V: set[0,?] pty_density_liquid) may have a property
-------------------------------------------------------------------------------------------
Request Number: 1129	Date submitted: 10 Oct 1996
Product: Epicentre Data Model
Status: assigned
Title: kick and kick_recovery missing
Description: A kick activity can not currently be described in Epicentre. It is needed as an instantaneous activity. A new subtype of activity kick is needed. The volume influx from the formation that generates the kick needs to be linked to the kick activity. This requires an extension for a kick_recovery, subtype of a well_test_recovery. In kick_recovery: kick (M,K: kick) specifies the activity which resulted in this fluid quantity being produced. In kick: kick_recovery (O,V: set[0,?] kick_recovery) indicates the various fluid quantities produced during the kick.
-------------------------------------------------------------------------------------------
Request Number: 1130	Date submitted: 10 Oct 1996
Product: Epicentre Data Model
Status: assigned
Title: missing core recovery percentage
Description: The percentage of recovery of a core from a coring activity can not be described in Epicentre. It is a unitless number that could be described by a property entity pty_core_recovery_factor. Its main attributes would be "core", "data_value" and "activity".
-------------------------------------------------------------------------------------------
Request Number: 1131	Date submitted: 10 Oct 1996
Product: Epicentre Data Model
Status: assigned
Title: redundant litho/chronostrat wellbore point
Description: 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.
-------------------------------------------------------------------------------------------
Request Number: 1132	Date submitted: 10 Oct 1996
Product: Epicentre Data Model
Status: assigned
Title: codes for typical_activities
Description: 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.
-------------------------------------------------------------------------------------------
Request Number: 1133	Date submitted: 10 Oct 1996
Product: Epicentre Data Model
Status: assigned
Title: logger's and driller's depth
Description: Property values may need to be qualified and may require descriptive fields. This is the case for the driller's depth or logger's depth flag that represents a label associated with the depth information. The extension defined for the FIT would be re-used, that is adding a ref_kind_descriptor attribute to the property entity, thus inherited by the pty_location_1D. The values of the ref_kind_descriptor are "logger" or "driller".
-------------------------------------------------------------------------------------------
Request Number: 1134	Date submitted: 10 Oct 1996
Product: Epicentre Data Model
Status: assigned
Title: link wellbore_point to geologic_feature
Description: The same extension as the lithostrat/chronostrat one is required for linking general_wellbore_point to many geologic_feature.
-------------------------------------------------------------------------------------------
Request Number: 1135	Date submitted: 10 Oct 1996
Product: Epicentre Data Model
Status: assigned
Title: add flow rates to well test recovery
Description: Oil/Gas/Condensate/Water rates cannot be described directly in the well_test_open_period_recovery entity yet. They can only be described in the pty_standard_volume _liquid/gas providing the start time of the period is known. This is not always the case and an extension is required to describe rates directly in the well_test_open_period_recovery: In pty_standard_volume_liquid_rate and pty_standard_volume_gas_rate: well_test_recovery (O, K: well_test_recovery) may be a property of In well_test_recovery: pty_standard_volume_liquid_rate (O, V: set[0,?] pty_standard_volume_liquid_rate) may have a property of pty_standard_volume_gas_rate (O, V: set[0,?] pty_standard_volume_gas_rate) may have a property of
-------------------------------------------------------------------------------------------
Request Number: 1136	Date submitted: 10 Oct 1996
Product: Epicentre Data Model
Status: assigned
Title: add densities of fluid components
Description: The different component of the test recovery (oil, gas, water and condensate) are described by fluid_pseudo_component, but the density of these components pty_density_liquid and pty_density_vapor can not be related to the fluid_pseudo_component. An extension is required in both the pty_density_liquid and pty_density_vapor to link them to the fluid_pseudo_component. In pty_density_liquid and pty_density_vapor: fluid_pseudo_component (O, K: fluid_pseudo_component) may be a property of In fluid_pseudo_component: pty_density_liquid (O, V: set[0,?] pty_density_liquid) may have a property of pty_density_vapor (O, V: set[0,?] pty_density_vapor) may have a property of
-------------------------------------------------------------------------------------------
Request Number: 1137	Date submitted: 10 Oct 1996
Product: Epicentre Data Model
Status: assigned
Title: add measurement point to wellbore
Description: The description of a measurement point within a wellbore with associated properties (pressure, temperature, rates etc.) does not seem to be entirely satisfactory. The only entity available is a temporary_completion that does not really represent the business concept carried by a measurement point. Shell EXPRO and SIEP came across the same problem and an extension to the model has been submitted. The extension requires the measurement_point entity to be linked to the spatial model (may be through a position_in wellbore) and to the relevant properties: pty_transient_pressure, pty_transient_temperature, pty_standard_volume_liquid_rate, pty_standard_volume_gas_rate. The depth information would still be carried by the pty_location_1D associated with the general_wellbore_point (position_in_wellbore). In general_wellbore_point: measurement_point (O, K: measurement_point) indicates a facility which is located by this wellbore position. In measurement_point: position_in_wellbore (O, V: set[0,?] position_in_wellbore) specifies the placement of a facility within a wellbore.
-------------------------------------------------------------------------------------------
Request Number: 1138	Date submitted: 10 Oct 1996
Product: Epicentre Data Model
Status: assigned
Title: add temperature and pressure to material
Description: It seems that any material may be characterized by its temperature (pty_temperature). For this pty_temperature, instead of: filter_cake (O, K: filter_cake) may be a property of fluid_system (O, K: fluid_system) may be a property of rock_material (O, K: rock_material) may be a property of Epicentre should be: material (O, K: material) may be a property of It seems that any material may be characterized by its pressure (pty_pressure). For this pty_pressure, instead of: filter_cake (O, K: filter_cake) may be a property of fluid_system (O, K: fluid_system) may be a property of Epicentre should be: material (O, K: material) may be a property of
-------------------------------------------------------------------------------------------
Request Number: 1139	Date submitted: 10 Oct 1996
Product: Epicentre Data Model
Status: assigned
Title: well test recovery needs identifier
Description: The recovery of a formation test must be identified by an identifier. This is currently missing in the model, thus requiring an extension (identifier attribute) at the supertype level in the well_test_recovery entity. In well_test_recovery: identifier (O, K: ndt_name) An alphanumeric string such as a label or a serial number, which acts to identify the object.
-------------------------------------------------------------------------------------------
Request Number: 1140	Date submitted: 10 Oct 1996
Product: Epicentre Data Model
Status: assigned
Title: generalize fluid recovery from test
Description: The wireline_formation_test_recovery is currently related to well_operation_fluid, reservoir_fluid_system and fluid_pseudo_component but not to fluid_sample. An extension is required to describes the fact that a fluid_sample may be the recovery of a wireline_formation_test and of any well_test_recovery. We suggest that the two attributes pointing to reservoir_fluid_system and well_operation_fluid be replaced by a fluid_system attribute to describe all possibilities. In well_test_recovery: fluid_system (O, K: fluid_system) specifies the fluid_system which is the source of this fluid quantity. In fluid_system: (O, V: set[0,?] well_test_recovery) indicates various fluid quantities which are produced from this volume of material.
-------------------------------------------------------------------------------------------
Request Number: 1142	Date submitted: 10 Oct 1996
Product: Epicentre Data Model
Status: assigned
Title: Grid missing element behavior is unclear when component grids have missing elements
Description: 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.
-------------------------------------------------------------------------------------------
Request Number: 1143	Date submitted: 10 Oct 1996
Product: Epicentre Data Model
Status: assigned
Title: Cannot assert usage of seismic facilities without specifying attibutes
Description: 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.
-------------------------------------------------------------------------------------------
Request Number: 1144	Date submitted: 10 Oct 1996
Product: Epicentre Data Model
Status: assigned
Title: Length of NDT_Name of 40 characters is too short
Description: 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!
-------------------------------------------------------------------------------------------
Request Number: 1145	Date submitted: 24 Oct 1996
Product: Epicentre Data Model
Status: resolved	Date resolved: 25 Oct 1996
Title: Equilibrium table parameters in numerical simulation model
Description: There are shown below equilibrium table parameters in a numerical simulation model, 1. How do I map them into Epicentre ? pcwoc - water-oil capillary pressure at the water-oil contact in psia(kPa). woc - depth to the water-oil contact in ft(m). pcgoc - gas-oil capillary pressure at the gas-oil contact in psia(kPa). goc - depth to the pas-oil contact in ft(m). 2. I think that viscous_compressibility would be a curve, but it is a single value in entity pty_viscous_compressibility. Why ?
Resolution: Item #1: The object in Epicentre that should contain this data is the entity FLUID_FEATURE_CONTACT where REF_FLUID_CONTACT 'oil-water' or 'gas-oil' as appropriate. This entity does not currently contain this information, so I would suggest an extension, something like: ENTITY pty_fluid_feature_initialization SUBTYPE OF (property); depth ndt_length; capillary_pressure ndt_pressure; fluid_feature_contact fluid_feature_contact; UNIQUE si: fluid_feature_contact, activity; END_ENTITY; Obviously, you would need one instance for each of the two contacts. Item #2: The fluid properties portion of Epicentre has not received as much attention as other parts of the model to date, but some problems have been found. Two known problems are that some fluid properties may be defined in more than one way, and some properties may not be defined at all. Originally, the model was designed for each type of property to be stored in a separate property entity - but this was later changed to store properties in an "element" data structure pointing a common set of pressure values -- and all the older property entities should have been removed but were not. This means that most of the fluid property entities in RESERVOIR_FLUID_SYSTEM could soon be removed or altered. I now expect that the full saturated/undersaturated oil property tables would be defined for a three dimensional table (pressure, temperature and saturation pressure [aka, bubble point pressure]) using the entity PTY_UNDERSATURATED_PRESSURE_CURVE (this sets up the framework and indices for the fluid property tables), and then the dependent fluid characteristics would be entered using one instance of PTY_ELEMENT_VALUE for each type of property, such as REF_QUANTITY_TYPE = 'viscous compressibility'. Notice that each PTY_ELEMENT_VALUE can point to the independent pressure-temperature-saturated_pressure values, and is like a column in a fluid property table. Also, this structure can be used to store all of the fluid characteristics. We are hoping that corrections to this model will be included in the near-term work plan for a reservoir simulation workgroup - we do not want to make changes until someone was interested in testing the model.
-------------------------------------------------------------------------------------------
Request Number: 1150	Date submitted: 22 Nov 1996
Product: Epicentre Data Model
Status: assigned
Title: Earth_surface_feature needs Pty_element_value
Description: Earth_surface_feature has no mechanism of assigning general properties such as "water depth". This could be accomplished by adding Pty_element_value as a property.