Index of Problems/Changes

Recent POSC Problem Reports and Change Requests

Updated: 12 December 1996

Data Exchange

Request Number: 1019 Date submitted: 20 Nov 1995
Product: Data Exchange
Status: resolved Date resolved: 24 Oct 1996
Title: fundamental exchange operations
Description: Specify exchange operations in terms of fundamental conceptual operations (select, merge, internalize, externalize, ...) rather than in terms of composite operations.
Resolution: The entities Dae_exchange_profile, Dae_data_store_root, Dae_data_set_header were added to replace the concept of Dae_exchange_header. This change made in release v2.1.
-------------------------------------------------------------------------------------------
Request Number: 1147 Date submitted: 25 Oct 1996
Product: Data Exchange
Status: assigned
Title: How to propagate inverse relationships
Description: The DAE spec is not clear on the behavior to control the propagation of inverse relationships.

For example, if I have attribute C is an inverse relationship of entity A, where C is a set of [0,?]. This occurs often especially with many-to-many's that are resolved, but also occurs in other cases. I would like to specify that "some" of the C's propagate. How do I do this?

More specifically, I have seismic_acquisition_activity, with attribute business_associate_activity_role specified (which is an inverse relationship). I would like to be able to propagate only those for which business_associate_activity_role.ref_business_associate_activity_role = 'some value'. How is this done? Or will the propagation pick up all the business_associate_activity_role instances and further propogate them?

Reference Entities

Request Number: 1082 Date submitted: 30 Apr 1996
Product: Reference Entity
Status: resolved Date resolved: 25 Oct 1996
Title: Standard for codes and symbols for well locations, etc.
Description: I am trying to find out if there is a standard for codes and symbols for
WELL LOCATIONS
LITHOLOGY PATTERNS
PALENTOLOGY PATTERNS

For example:

WELL LOCATIONS (MAP SYMBOLS) from the GEOSHARE manual use: 

    CODE      MNEMONIC                           SYMBOL
                                                _____
     0        DEVELOPMENT-PROPOSED             |  |  |
                                               |     |
                                               |_____|
Resolution: POSC is not standardizing on well symbols and patterns. This policy was decided on by the membership, and has not been changed.

Sample Implementation

Request Number: 1121 Date submitted: 09 Oct 1996
Product: Sample Implementation
Status: assigned
Title: Problem setting up sample implementation
Description: I obtained POSC's CD-ROM of v2.1 release yesterday, and I tried to work the sample implementation, but some error info occured. I use ORACLE 7 on my SUNOS, I do it as follows: 
    sqldba>create tablespace posc_model_tab
           datafile 'posc_model_tab.dat' size 70M
           default storage(initial 5k next 10k
           minextents 1 maxextents 121 pctincrease 0);
    sqldba>create user posc identified by posc
           default tablespace posc_model_tab
           quota unlimited on posc_model_tab;
    sqldba>grant xxx to posc;
    --------------------------------------
    unix_promt>database_setup.script posc posc

but some error occured as follows: 

    CREATE TABLE SEIS_GEOM_SET
    ORA-00604:error occured at recursive SQL level 1
    ORA-01547:failed to allocate extent of size 30 in tablespace 'system'
   ... ... ...  ... ...
    insert into att_col_grp_map(ATTRIBUTE_S,ATT_COL_GRD_MAP_S,...)
    LDA error(ocom):code is 1001, op is 0 
    ORA-01001:invalid cursor
    -------------------------------------------

I couldn't correct these errors, and so it failed. Please tell me how to correct it.

----------------------------------------------------------------------------------------------------
Request Number: 1148 Date submitted: 31 Oct 1996
Product: Sample Implementation
Status: assigned
Title: Win95 file for compatability layer is not usable
Description: On the V2.1 CD, the file for the Windows 95 version of the Compatibility Layer is unusable.
Resolution: The entities Dae_exchange_profile, Dae_data_store_root, Dae_data_set_header were added to replace the concept of Dae_exchange_header. This change made in release v2.1.

POSC Browser

Request Number: 1141 Date submitted: 10 Oct 1996
Product: POSC Browser
Status: resolved Date resolved: 16 Oct 1996
Title: file ILPRODGA is damaged
Description: The file ILPRODGA is supposed to show a wellbore and wellhead picture but instead shows a blank panel that obscures the buttons at the bottom of the screen.
Resolution: A corrected version of the file has been posted to the anonymous FTP server and a link to it is included in the V2.1 Errata Page.

V2.1 CD

Request Number: 1146 Date submitted: 25 Oct 1996
Product: POSC V2.1 CD
Status: resolved Date resolved: 25 Oct 1996
Title: Where is Oracle DDL on V2.1 CD
Description: Can you tell me the directory and file name of the projected ORACLE DDL on the POSC SIP Spec 2.1 CD?
Resolution: For the projected ORACLE DDL, look on the POSC SIP Spec 2.1 CD in: 
   ~/SourceCode/CompatLayer/Unix/v2.1.7.C_DDL.tar.Z
Because of the long file names in this directory, you will need to be using Unix or Windows 95 to access the file.

Epicentre Express

Request Number: 1103 Date submitted: 24 Jun 1996
Product: Epicentre Data Model
Status: resolved Date resolved: 24 Oct 1996
Title: uniqueness at wrong level on subtypes of ref_property_type
Description: ref_descriptive_property and ref_quantity_rpoerty have uniqueness clauses declared in the Epicentre EXPRESS. More properly, the uniqueness should be declared at the supertype of these; i.e. ref_property_type.
Resolution: The uniqueness constraints were deleted from the subtypes of ref_property_type and moved to the supertype. This change was made for release v2.1.
--------------------------------------------------------------------------------------------------
Request Number: 1149 Date submitted: 22 Nov 1996
Product: Epicentre EXPRESS
Status: assigned
Title: Need corrections to Express-I in documents
Description: I have been doing some work to use the Express-I footprint definitions on the POSC webserver. During the course of this development I have encountered a number of places where it would be useful to correct the Express-I in the POSC documents for the benefit of other POSC members. 
===========================================
Report number 13

In the Bottomhole_Location_North_East Express-I the line
within the

      bottomhole_north_east = PTY_LOCATION_2D {

object the line

        ref_unit_of_measure(M,L)        --> (@PRV_m; @PRV_m); };

should read

        ref_unit_of_measure(M,L)        --> (@PRV_m, @PRV_m); };

===========================================
Report number 19

In the Drilling_Mud Express-I

  mud_pit = MUD_PIT {
     SUBOF(GENERAL_FACILITY);
     ref_existence_kind(M, K)           --> @PRV_actual;
     name(K)                                  --> 'well 4217734922'

should be

  mud_pit = MUD_PIT {
     SUBOF(GENERAL_FACILITY);
     ref_existence_kind(M, K)           --> @PRV_actual;
     name(K)                                  --> 'well 4217734922';

===========================================
Report number 11

In the NAD27_coordinate_system Express-I the line

     geodetic_datun                          <-- (@PRV_NAD27_geodetic_datum};

should read

     geodetic_datum                          <-- (@PRV_NAD27_geodetic_datum); };
                  ^                                                        ^
===========================================
Report number 1

In the document describing Express-I there is a section that says

   In-line comments are denoted by a double dash `--' and terminated by a
LINEFEED.
   For example:

        well --> @well_1;          -- This is an in-line comment

If this rule is correct then the above line reads

        well

rather than the intended

        well --> @well_1;

You cannot even make the sequence '-- ' into the comment since

     well_alias                         <-- (@well_1_alias_1); };

would be incorrectly altered.  I suggest that the '//' form
of comment is used instead.  This seems to be the convention that
GEMSIG are using in their examples.

===========================================
Report number 10

In the Bin_point_travel_time_coordinate_system and TVD_coordinate_system
models the line

     identifier(M, K)                        --> ' mean sea level';

should be

     identifier(M, K)                        --> 'mean sea level';

===========================================
Report number 12

In the NAD27_coordinate_system Express-I the line

      PRV_EPSG_reference = REF_SOURCE_REFERENCE [

should read

      PRV_EPSG_reference = REF_SOURCE_REFERENCE {

===========================================
Report number 2

The Express-I descriptions have backquotes at the start of
strings, I guess that the "smart-quotes" feature of Word has
inserted them.  These should be replaced by forward quotes in
the formal Express-I text.

===========================================
Report number 16

In the Drilling_Mud Express-I

        ref_unit_of_measure(M)          --> @PRV_lbm/galUS; }; };

breaks the syntax, it should be something like

        ref_unit_of_measure(M)          --> @PRV_lbm_per_galUS; }; };

===========================================
Report number 14

The Bottomhole_Measured_Depth Express-I refers to both the
Elevation_MSL_coordinate_system and MD_coordinate_system
Express-I.  Since these both have an object

        RV_MyCompany = REF_SOURCE {
          name(M,K)       --> 'Oil Patch Inc'; };

defined there is some ambiguity about the meaning of this
construct.

I would suggest that changing the entry in MD_coordinate_system
to

           source(M)                               --> @RV_MyCompany2; };
    .
    .
    .
        RV_MyCompany2 = REF_SOURCE {
          name(M,K)  --> 'Oil Patch Inc'; };

would be the quickest way to remove the question;

===========================================
Report number 17

In the Drilling_Mud Express-I

        real_value(M)                   -->10.3

should be

        real_value(M)                   -->10.3;

===========================================
Report number 18

In the Drilling_Mud Express-I

  fluid_loss = PTY_FLUID_LOSS {
     well_operation_fluid(K)            --> @mud; };

should be

  fluid_loss = PTY_FLUID_LOSS {
     well_operation_fluid(K)            --> @mud;

===========================================
Report number 20

The names of the Well_Logging_Activities Express-I is not always consistent, so
in
Well_Log_Header we have

     wellbore_trip                      --> #Well_logging_Activities.trip_1;
     business_associate            --> #Well_logging_Activities.contractor;
     activity(K)                          --> #Well_logging_activities.log_run;

in Drilling_Mud

     containing_activity(K)             -->#Well_Log_Activities.activity;

===========================================
Report number 24

In Log_Trace_Data

     SUBOF (POSITION_IN_WELLBORE, EDGE));

should be

     SUBOF (POSITION_IN_WELLBORE, EDGE);

===========================================
Report number 21

In Well_Logging_Activities Express-I

     material_installation              <--
(#Drilling_Muddrilling_mud_installation);

should be

     material_installation              <--
(#Drilling_Mud.drilling_mud_installation);

===========================================
Report number 27

In Well_Log_Header Express-I

      derrick_floor =_DERRICK_FLOOR_REFERENCE {

should be

      derrick_floor = DERRICK_FLOOR_REFERENCE {

===========================================
Report number 25

In Well_Log_Header

     source(M)                          --> RV_MyCompany; };

should be

     source(M)                          --> @RV_MyCompany; };

===========================================
Report number 23

There are some common syntax errors in the Drillstring_Composition
Express-I

      collar_connection = EQUIPMENT_ITEM_CONNECTION {
         from_equipment(M, K)               --> @collar;
         to_equipment(M, K)                  --> @stabilizer; ) };

      stabilizer_connection = EQUIPMENT_ITEM_CONNECTION {
         from_equipment(M, K)               --> @stabilizer;
         to_equipment(M, K)                  --> @mud_motor; ) };

      mud_motor_connection = EQUIPMENT_ITEM_CONNECTION {
         from_equipment(M, K)               --> @mud_motor;
         to_equipment(M, K)                  --> @bit; ) };

The ") }" strings should all be just "}"

===========================================
Report number 15

In the Drilling_Mud Express-I

     typical_material(M, K)             --> @mud_type;}

should be

     typical_material(M, K)             --> @mud_type; };

===========================================
Report number 22

In the Well_Logging_Activities Express-I

  trip_depth = PTY_LOCATION_1D {
     wellbore_point(K)                  --> @#Well_Log_Header.bottom_hole_point;

should be

  trip_depth = PTY_LOCATION_1D {
     wellbore_point(K)                  --> #Well_Log_Header.bottom_hole_point;

===========================================
Report number 26

In Wellbore_stratigraphy Express-I the following objects should be added

      RV_stratigraphic_top = BOUNDARY_TYPE {
         kind(M,K)                          --> 'Top of formation'; };
 
      RV_stratigraphic_base = BOUNDARY_TYPE {
         kind(M,K)                          --> 'Base of formation'; };
         };

===========================================
Report number 29

In Drilling_Mud Express-I

      PRV_ohm_meter = REF_DEFIVED_SI_UNIT {

should be

      PRV_ohm_meter = REF_DERIVED_SI_UNIT {

===========================================
Report number 30

In Well_Logging_Activities Express-I

  pass_depths= PTY_SIMPLE_GEOMETRY_1D_EDGE {

should be

  pass_depths= PTY_GEOMETRY_SIMPLE_1D_EDGE {

===========================================
Report number 3


In the "Geologic Information" part of the "Examples of Epicentre
Usage" document there is an Express-I description that starts

    MODEL Wellbore stratigraphy;

Which should start

    MODEL Wellbore_stratigraphy;

===========================================
Report number 3

In the "Geologic Information" part of the "Examples of Epicentre
Usage" document there is an Express-I description that starts

    MODEL Wellbore stratigraphy;

Which should start

    MODEL Wellbore_stratigraphy;

===========================================
Report number 32

In Well_Logging_Activities Express-I,  I believe that

      hole_location = WELLBORE_INTERVAL {
         SUBOF (EDGE, POSITION_IN_WELLBORE);
         identifier(K)                                 --> '8 .5 inch borehole';
         wellbore_component_facility(K)     --> @hole_segment;

should read

      hole_location = WELLBORE_INTERVAL {
         SUBOF (EDGE, POSITION_IN_WELLBORE);
         identifier(K)                                --> '8 .5 inch borehole';
         wellbore_component_facility(K)     --> (@hole_segment);

===========================================
Report number 34

In Well_Logging_Activities Express-I

     welbore_activity                   <-- (@trip_1, @log_run);

should be

     wellbore_activity                   <-- (@trip_1, @log_run);

===========================================
Report number 31

In Well_Log_Header Express-I

     #Well_Logging_Activities.circulating_wellbore_fluid_system,

should be

     #Well_Logging_Activities.RV_circulating_wellbore_fluid_system,

===========================================
Report number 35

In Elevation_MSL_coordinate_system Express-I

     datum_for_axis                          <-- (@msl_elevation_axis);
     orient_axis                                <-- (@msl_elevation_axis); };

should be

     datum_for_axis                          <-- (@elevation_msl_axis);
     orient_axis                                <-- (@elevation_msl_axis); };

===========================================
Report number 40

In the Drilling_Mud Express-I

     processed_material                 <-- (@mud_sample);

should be

     processed_material                 --> (@mud_sample);

===========================================
Report number 28

In Well_Log_Header Express-I

      RV_document_content = REF_DATA_COLLECTION {

should be

      RV_document_content = REF_DATA_COLLECTION_TYPE {

===========================================
Report number 33

In Drilling_Mud Express-I there are a number of entries such as

        unit_of_measure(M)              --> @PRV_s; }; };

that should be

        ref_unit_of_measure(M)              --> @PRV_s; }; };

===========================================
Report number 4

In the description of coordinate systems the Express-I line

    PRV_NAD27_Texas_North_Cen = PROJECTED_OORDINATE_SYSTEM {

should read

    PRV_NAD27_Texas_North_Cen = PROJECTED_COORDINATE_SYSTEM {

===========================================
Report number 39

In the Well_Logging_Activities Express-I

     referenced_by                      --> @pass_schedule; };

should be

     referenced_by                      <-- @pass_schedule; };

===========================================
Report number 38

In the Well_Logging_Activities Express-I

      truck = LAND_VEHICLE {
         equipment_storage                  <-- (@truck_location);

there is no equipment_storage attribute in LAND_VEHICLE

===========================================
Report number 36

In Well_Logging_Activities Express-I there is a reference to a
trip_location object which is not created.

===========================================
Report number 37

In Drilling_Mud Express-I we have the following

      mud_filtration = FLUID_PROCESSING {
         .
         .    };

      mud_filtrate = FLUID_FILTRATE {
         produced_by_activity               --> @mud_filtration; };

Wheras this subset of the Epicentre definition would seem to disallow this

    ENTITY fluid_filtrate
     SUBTYPE OF (
      fluid_sample
     );
    END_ENTITY;

    ENTITY fluid_sample
     SUBTYPE OF (
      fluid_system,
      material_sample
     );
    END_ENTITY;

    ENTITY material_sample
     SUBTYPE OF (
      inventory_object
     );
     produced_by_activity : OPTIONAL sample_acquisition ;
    END_ENTITY;

    ENTITY sample_acquisition
     ABSTRACT SUPERTYPE OF (ONEOF(
      fluid_sample_acquisition,
      rock_sample_acquisition
     ))
     SUBTYPE OF (
      activity
     );
    END_ENTITY;

    ENTITY fluid_processing
     SUBTYPE OF (
      materials_processing
     );
    END_ENTITY;

    ENTITY materials_processing
     ABSTRACT SUPERTYPE OF (ONEOF(
      fluid_processing,
      rock_processing
     ))
     SUBTYPE OF (
      activity
     );
    END_ENTITY;

===========================================
Report number 5

Each Express-I example has a schema identifier of the form

    SCHEMA_DATA Epicentre_V2.0;

I believe that these should be

    SCHEMA_DATA Epicentre_v20;

since the dot character is not normally valid in identifiers.  Even
better would be

    SCHEMA_DATA Epicentre_v21;

===========================================

Report number 7

In the description of coordinate systems the Express-I line

    PRV_EPSG_reference = REF_SOURCE_REFERENCE [
       ref_source(M,K)                         -->@PRV_EPSG; };

should read
                                              v
    PRV_EPSG_reference = REF_SOURCE_REFERENCE {
       ref_source(M,K)                         -->@PRV_EPSG; };

===========================================
Report number 6

The Schema name for the Epicenre Express file should identify
the version, I would suggest changing the line

    SCHEMA epicentre;

to

    SCHEMA Epicentre_v21;

===========================================
Report number 9

A number of the Express-I descriptions contain constructs like

  RV_MyCompany_inventory_control = REF_NAMING_SYSTEM [
     kind(M,K)                          --> 'Oil Patch Inc - Inventory Control';
     description                        --> 'The identification system for all
inventory
                                             items of Oil Patch Inc. See,
Corporate
                                             Proceedures Manual, Section V for a
                                             specification of the naming
system.';
     source(M)                          --> @RV_MyCompany; };

changing these to a structure like

  RV_MyCompany_inventory_control = REF_NAMING_SYSTEM [
     kind(M,K)                          --> 'Oil Patch Inc - Inventory Control';
     description                        --> 'The identification system for all
inventory \
                                             items of Oil Patch Inc. See,
Corporate \
                                             Proceedures Manual, Section V for a
\
                                             specification of the naming
system.';
     source(M)                          --> @RV_MyCompany; };

would make the job of creating parsers easier.
===========================================
Report number 8

In the Spud_Date Express-I model the line

    spud_well = TYPICAL_ACTIVITY {

should read

    RV_spud_well = TYPICAL_ACTIVITY {

===========================================
Report number 41

In the NAD27_coordinate_system Express-I

  PRV_Greenwich = PRIME_MERDIAN {

should be

  PRV_Greenwich = PRIME_MERIDIAN {

===========================================
Report number 43

In the NAD27_coordinate_system Express-I the line

     ref_quanity_property(M, K)              --> @PRV_longitude;

should be

     ref_quantity_property(M, K)              --> @PRV_longitude;
             ^
===========================================
Report number 45

In the Drilling_Mud Express-I the lines

  Rmf = PTY_ELECTRIC_RESISTIVITY {
     well_operation_fluid(K)            --> @mud_filtrate;

should be

  Rmf = PTY_ELECTRIC_RESISTIVITY {
     well_operation_fluid(K)            --> @mud;

===========================================
Report number 44

In the Elevation_MSL_coordinate_system Express-I the lines

  elevation_msl_axis = VERTICAL_DEPTH_SYSTEM_AXIS {
     SUBOF (COORDINATE_SYSTEM_AXIS);
     ref_quantity_property(M, K)             --> @PRV_elevation;

should be

  elevation_msl_axis = VERTICAL_DEPTH_SYSTEM_AXIS {
     SUBOF (COORDINATE_SYSTEM_AXIS);
     ref_quantity_property(M, K)             --> @PRV_vertical_depth;

===========================================
Report number 46

In the Wellbore_stratigraphy Express-I the WELLBORE_INTERVAL
object wbi_1 sets its existence_kind.  The WELLBORE_INTERVAL
object does not have such an attribute.

===========================================
Report number 47

In the Wellbore_stratigraphy Express-I the
GENERAL_WELLBORE_POINT objects 'KB', 'gwbp_1', 'gwbp_2',
'gwbp_3', 'gwbp_4' all set 'existence_kind'.  There is no such
attribute.

===========================================
Report number 49

In the Wellbore_stratigraphy Express-I the line

     earth_model_object                 --> (@gwbp_1, @gwbp_3, @gwbp_4);

should be

     earth_model_object                 <-- (@gwbp_1, @gwbp_3, @gwbp_4);

===========================================
Report number 48

In the Wellbore_stratigraphy Express-I the

  COORDINATE_TRANSFORMATION_ACTIVITY object conversion
  GEOSCIENCE_INTERPRETATION          object picking

both have the line

     existence_kind(M,K)                --> @PRV_actual;

which should be

     ref_existence_kind(M,K)            --> @PRV_actual;

===========================================
Report number 50

In the X_Y_TVD_coordinate_system Express-I the line

     coordinate_system(K)                    --> (@local_coord_sys); }; (*
bag[0,1]*)

should be

     coordinate_system(K)                    <-- (@local_coord_sys); }; (*
bag[0,1]*)

Index of Problems/Changes POSC Home Page
Updated: December 12, 1996. Send questions and comments to webmaster@posc.org

Copyright © 1996 Petrotechnical Open Software Corporation. All rights reserved.
POSC ® and the POSC logo ® are registered trademarks and Epicentre™ is a trademark of Petrotechnical Open Software Corporation.