Equinor/Statoil’s Volve Dataset – Well Technical Data – part 2

The following article is based on the original blog post here, authored by CTO Marius Kjeldahl.

This is the second article about the topic. The first article can be found here: Equinor/Statoil’s Volve Dataset – Well Technical Data – part 1.

The next entry in the EDM xml data dump (after TOPLEVEL) is:

Marius Kjeldahl
CTO
TwitterLinkedinEmail
<MD_SITE_TIGHT_GROUP
  tight_group_id="T0001"
  tight_group_name="UNRESTRICTED"
  description="Unrestricted" />

Hard to say what this is used for now. Then we have:

<CD_POLICY
  customer_name="Norway"
  policy_id="vyxGFUk61o"
  error_surface="2"
  walk_type="0"
  error_model="3"
  scan_method="0"
  warning_method="0"
  error_output_level="2.448"
  survey_calc="0"
  vs_origin="0"
  is_readonly="N"
  reporting_standard="2"
  reporting_time="{ts '1970-01-01 00:00:00'}"
  password_1="46/5zflg"
  password_2="46/5zflg"
  error_level="2.878"
  use_casing="1"
  create_date="{ts '2006-03-17 10:28:48'}"
  create_user_id="GFOL"
  create_app_id="COMPASS"
  update_date="{ts '2018-03-15 15:00:09'}"
  update_user_id="STATOIL-NET\trelv(edm)"
  update_app_id="COMPASS"
  notify_minimum_separation="2.0"
  notify_cone="10.0"
  notify_projection_length="100.0"
  notify_offset_scope="1"
  />

Even though the entry starts with CD_, the app mentioned is Compass, and the data looks more like the type of data that Compass would need (related to trajectory modelling, default values related to error modelling). More interesting are the entries following this one:

<CD_SURVEY_TOOL
  survey_tool_id="5pod5"
  policy_id="vyxGFUk61o"
  tool_name="Magn, IFR, mag-corr, red QC, MSA Dual"
  tool_type="0"
  default_tool="0"
  is_readonly="N"
  description="Magnetic Tools (MWD, EMS) without gyro-verificatio"
  not_in_use="0"
  create_date="{ts '2015-10-02 11:56:58'}"
  create_user_id="trelv(TRELV@STATOIL.NET)"
  remarks="MWD-ifr-mag"
  create_app_id="COMPASS"
  update_date="{ts '2017-11-07 14:12:37'}"
  update_user_id="STATOIL-NET\trelv(edm)"
  tool_subtype="1"
  update_app_id="COMPASS"
  correlate="N"
  cost_per_run="0.0"
  cost_per_length="0.0"
  running_speed="0.0"
  is_single_shot="N"
  revision_date="{ts '1990-01-01 00:00:00'}"
  is_range_limited="N"
  inclination_range_min="0.0"
  inclination_range_max="0.0"
  azimuth_ew_exclusion="0.0"
  checksum_value="-147220640"
  />

Survey tools are measurement tools for figuring out where a drilled trajectory is actually located. Various techniques are used and the various techniques and specific tools have different accuracies. Measuring survey points involves using statistical techniques for estimating the most likely positions, and to get the probabilities of two well bores intersecting at an acceptable level (meaning highly unlikely). In addition to the actual tools used (and their parameters) the software would typically use actual error models for calculating the probabilities of intersection with other well bores (error models, IPM files, separation factors, NEV covariance matrices, error ellipses etc).

Other items refering to specific tools do this through the survey_tool_id, and for the specific example above I’ve seen it referenced in DP_TOOL_TERM and CD_SURVEY_PROGRAM entries. The DP_TOOL_TERM entries follow, and the first one mentioned is this one:

<DP_TOOL_TERM
  policy_id="vyxGFUk61o"
  survey_tool_id="5pod5"
  tool_term_id="35KHK"
  sequence_no="1"
  term_name="tvdsf2"
  vector_type="n"
  tie_type="n"
  c_range="0"
  c_value="1.2"
  c_units="-"
  c_formula="1.0"
  max_range="0.0"
  min_range="0.0"
  />

I’m not sure about the DP_ prefix here though, but this definitively looks like something related to error modelling. The attribute named term_name has the value tvdsf2 here, but other entries of the same type mention names like vsagmsixyz_2abixyz_2dbh etc. There are references to error model terms which are combined to define complete “error models”. These complete error models typically have names similar to the tool_name field in the CD_SURVEY_TOOL entries (Magn, IFR, mag-corr, red QC, MSA Dual). The actual definitions of these errors are usually easy to spot though, they consist of a whole lot of geometric formulas including lots of sin and cos terms. Again, I’m not sure if these error models are actually defined inside the EDM XML dump. Well, I take that back! Looking at the next DP_TOOL_TERM entry, it becomes a lot clearer:

<DP_TOOL_TERM
  policy_id="vyxGFUk61o"
  survey_tool_id="5pod5"
  tool_term_id="3QOnW"
  sequence_no="9"
  term_name="abixyz_2"
  vector_type="l"
  tie_type="s"
  c_range="0"
  c_value="0.0028"
  c_units="-"
  c_formula="latsf*(sin(inc)*cos(azm)*tan(dip)-cos(inc))/(gtot*(1-(sin(inc))^2*(sin(azm))^2))"
  max_range="0.0"
  min_range="0.0"
  />

These are definition of error terms, which combined make up error models used for modelling trajectory uncertainties from the specific measurement equipment used (survey tools). The first one I showed basically had a formula c_formula returning the constant 1.0, while the second one has a more interesting value with actual calculations taking place (sin and cos etc).

For what it’s worth, Oliasoft WellDesign already supports these kinds of formulas, and also complete error models where these are combined, so importing these is fairly easy. So let’s look at what DP_TOOL_TERMs exist for the first CD_SURVEY_TOOL entry we found (survey_tool_id="5pod5"). Actually, there are 31 DP_TOOL_TERM below eachother which all point to the survey_tool_id used. And the term_names for these are tvdsf2 abixyz_2 vsag msixyz_3 .... It seems CD_SURVEY_TOOL and DP_TOOL_TERMs joined by the survey_tool_id make up complete error models in the EDM XML data dump.

Next up in the file we have these entries:

<CD_WELLBORE_TYPE
  wellbore_type_id="1XhZv"
  wellbore_type_color="33023"
  policy_id="vyxGFUk61o"
  wellbore_type_name="Appraisal Exploration"
  />

This pretty much looks like name and color of a specific wellbore inside Compass (or similar). The next couple of entries look like these:

<DM_PARTNER policy_id="vyxGFUk61o" partner_id="I54Tk" partner_name="PETORO" />
<DM_PARTNER policy_id="vyxGFUk61o" partner_id="sQJqK" partner_name="STATOIL" />

Just below these again there are DM_PARTNER_CONTACT entries which just show the name and email of the specific partner_id used. I’ve seen (but haven’t commented) the policy_id field earlier also. For now I think it’s just an id for tying together specific information that can be used across wellbores (like “partners” shown above). After these I find:

<DP_ACRULE
  policy_id="vyxGFUk61o"
  acrule_id="70eAW"
  sequence_no="1"
  rule_name="SHUT IN WELL if 40m stands"
  rule_type="0"
  ac_ratio="1.25"
  ac_limit="0.0"
  ac_prob="2.878"
  is_default="N"
  />

This again looks like some kind of “policy” related to all items connected through the policy_id field, probably some kind of operational rule. The next entry in the file is probably very important:

<CD_PROJECT
  project_id="vnRTGWCauO"
  policy_id="vyxGFUk61o"
  geo_system_id="UTM"
  field_no="0"
  geo_zone_id="UTM-31N"
  geo_datum_id="ED50"
  project_name="SLEIPNER"
  def_mag_model="GEOMAGNETICREFERENCE"
  local_coord_origin="1"
  description_supplement="Norway"
  mag_calc_model="BGGM2002"
  use_local_scale_factor="1"
  vertical_coord_origin="1"
  state_no="20"
  system_datum_desc="Mean Sea Level"
  system_datum_offset="0.0"
  is_readonly="N"
  create_date="{ts '2003-05-14 00:00:00'}"
  create_user_id="steint"
  create_app_id="COMPASS 2000"
  update_date="{ts '2018-01-15 13:46:09'}"
  update_user_id="trelv(TRELV@STATOIL.NET)"
  update_app_id="COMPASS"
  tight_group_id="T0001"
  active_ui_unitsys_id="20"
  />

This looks like a project/site/wellbore definition. It contains some basic user info and what map reference is used (throughout the project probably), and other relevant references for calculations. Below CD_PROJECT I find around 70 entries such as this one:

<DP_PROJECT_TARGET
  project_id="vnRTGWCauO"
  project_target_id="0wZoY"
  dip_angle="0.0"
  dip_direction="359.05868882380656"
  target_tvd="9921.25984248"
  azimuth_start="0.0"
  target_geometry="0"
  azimuth_end="0.0"
  target_name="t2-east-west"
  tolerance_forward="0.0"
  tolerance_back="0.0"
  is_readonly="N"
  drill_confidence="95.0"
  is_drillers_target="N"
  is_point_map_coord_lock="N"
  tolerance_down="0.0"
  tolerance_left="0.0"
  tolerance_right="0.0"
  tolerance_up="0.0"
  create_date="{ts '2015-09-10 09:24:08'}"
  geo_latitude="58.44736272243206"
  create_user_id="sigulu(SIGULU@STATOIL.NET)"
  create_app_id="COMPASS"
  geo_longitude="1.89545342358172"
  geo_map_easting="1428891.07610977"
  update_date="{ts '2015-09-10 09:24:08'}"
  geo_map_northing="2.125720472432442E7"
  update_user_id="sigulu(SIGULU@STATOIL.NET)"
  update_app_id="COMPASS"
  x_offset="0.0"
  y_offset="0.0"
  target_azimuth="359.05868882380656"
  coord_type="1"
  target_hide="0"
  target_inclination="-0.941311176193313"
  penetration_azimuth="0.0"
  penetration_inclination="0.0"
  lock_penetration="N"
  drill_tolerance="0.0"
  />

This basically looks like drilling targets, essentially where one wants a wellbore to end up, and at what angles. Below these, we have entries such as the ones shown below:

<DP_PROJECT_TARGET_POINT
  project_id="vnRTGWCauO"
  project_target_id="9GlBA"
  target_point_id="1Cj4A"
  coordinate_down="0.0"
  point_type="1"
  coordinate_east="-82.31524619389653"
  coordinate_north="32.9260984775586"
  coordinate_up="14288.53976059312"
  sequence_no="42"
  />
<DP_PROJECT_TARGET_POINT
  project_id="vnRTGWCauO"
  project_target_id="9GlBA"
  target_point_id="FThy9"
  coordinate_down="0.0"
  point_type="0"
  coordinate_east="-132.34908136430002"
  coordinate_north="-203.57611548475"
  coordinate_tvd="10462.68425394154"
  coordinate_up="23.58923884505"
  sequence_no="1"
  geo_map_easting="1430688.3385332476"
  geo_map_northing="2.125679462245084E7"
  />

This just looks like generic points of interest in a project. The first one is just a 2D map reference. It could be where to place a rig or similar. The second one contains depth information as well, indicating this is a point and should try to drill to (probably to help the people planning the drilling operation in deciding how/where to approach and/or avoid certain areas).

The next entry again is also very interesting:

<CD_SITE
  site_id="WD03eCqbHz"
  project_id="vnRTGWCauO"
  tight_group_id="T0001"
  north_type="1"
  site_name="Volve F"
  block_name="15/9"
  convergence="-0.9480481838647284"
  default_rig_elevation="177.16535433"
  top_borehole_radius="13.2000000000528"
  create_date="{ts '2005-10-17 13:53:04'}"
  create_user_id="pio"
  is_field_center="N"
  is_readonly="N"
  lateral_error="0.0"
  create_app_id="COMPASS"
  coord_type="1"
  geo_latitude="58.441613005888726"
  update_date="{ts '2018-04-11 13:47:01'}"
  foresight_error="0.0"
  mag_crustal_total="0.44"
  update_user_id="trelv"
  mag_crustal_dip="0.51"
  geo_longitude="1.8874801409233095"
  mag_crustal_dec="1.29"
  mag_time_total="0.0989999999999999"
  mag_time_dip="0.0666666666666668"
  geo_map_easting="1427329.4648893"
  mag_time_dec="0.0500000000000002"
  update_app_id="COMPASS"
  geo_map_northing="2.12551296685502E7"
  scale_factor="0.9996517087406264"
  geo_offset_east_lease_line="0.0"
  geo_offset_north_lease_line="0.0"
  remarks="Centre of template set til slot 8. Coordinates set calculating from coordinates given in Fugro report 5868 issued 13.02.2007 - &apos;dimensional survey report for Statoil as&apos;. Link to report forund in F-12 portal under the sheet &apos;more&apos;."
  />

It’s a site definition, basically overall information about a drill site (location, size of hole and more). The next entry doesn’t look very interesting (yet anyway), it contains the following:

<DP_TEMPLATE
  site_id="WD03eCqbHz"
  template_id="lJJxG"
  ew_edge="0.0"
  ns_edge="0.0"
  num_rows="5"
  num_columns="3"
  name_direction="1"
  orientation="329.381951847036"
  short_name="F-"
  spacing_columns="4.9212598425"
  spacing_rows="7.38188976375"
  start_number="1"
  template_name="15/9-F-"
  template_north="10.2072156902302"
  template_east="-11.7518601699994"
  create_user_id="EDMADMIN"
  update_user_id="EDMADMIN"
  />

This mostly looks like some naming information, and user interface preferences (rows, columns…).

Next up I see CD_WELL_ALL and CD_WELL entries. There’s pretty much one of each linked by well_id, so these seem to exist in pairs. It could be that the designers of the system had to add more information to the well entries and selected to do this by adding another table and a one to one reference. Anyway, they look like this:

<DP_TEMPLATE
  site_id="WD03eCqbHz"
  template_id="lJJxG"
  ew_edge="0.0"
  ns_edge="0.0"
  num_rows="5"
  num_columns="3"
  name_direction="1"
  orientation="329.381951847036"
  short_name="F-"
  spacing_columns="4.9212598425"
  spacing_rows="7.38188976375"
  start_number="1"
  template_name="15/9-F-"
  template_north="10.2072156902302"
  template_east="-11.7518601699994"
  create_user_id="EDMADMIN"
  update_user_id="EDMADMIN"
  />
<CD_WELL_ALL
  well_id="2DfUHhBj3x"
  site_id="WD03eCqbHz"
  tight_group_id="T0001"
  active_ui_unitsys_id="20"
  coord_type="3"
  is_offshore="Y"
  geo_latitude="58.441654613354984"
  geo_longitude="1.8874629672899272"
  geo_offset_east="1427326.4271596414"
  geo_offset_north="2.125514492117473E7"
  is_subsea="Y"
  well_common_name="F-11"
  is_readonly="N"
  slot_ew="-3.2908269717713816"
  slot_ns="15.205570857722757"
  well_legal_name="NO 15/9-F-11"
  slot_radial_error="0.0"
  wellhead_depth="298.556430445"
  water_depth="298.556430445"
  convergence="-0.9480632423499218"
  create_date="{ts '2005-10-19 13:37:29'}"
  create_user_id="pio"
  create_app_id="COMPASS"
  update_date="{ts '2013-08-15 09:49:11'}"
  scale_factor="0.9996517102176208"
  update_user_id="pkai(PKAI@STATOIL.NET)"
  update_app_id="COMPASS"
  wrp_offset="0"
  wrp_tvd="298.556430445"
  />

These pretty much contain relevant information about an actual well, including map references, depths and some more meta data (users, applications etc). Next up I find these:

<CD_DATUM
  datum_id="0XCDw"
  well_id="2DfUHhBj3x"
  datum_type="3"
  phase="PROTOTYPE"
  datum_elevation="180.1181102355"
  datum_description="Rotary Table"
  date_established="{ts '2007-11-23 00:00:00'}"
  datum_name="Rotary Table"
  is_default="N"
  create_date="{ts '2010-09-22 12:55:43'}"
  create_user_id="meu(MEU@STATOIL.NET)"
  create_app_id="WELLPLAN 5000.1"
  update_date="{ts '2013-08-15 09:49:11'}"
  update_user_id="pkai(PKAI@STATOIL.NET)"
  update_app_id="COMPASS"
  />

Datum elevation is usually some kind of depth reference. What is a bit confusing is that there seems to be a lot of these, per well (joined through well_id). Since they mostly just contain a depth value (named datum_elevation), it’s a bit hard to imagine why there are so many for each well. Looking at the comments inside each entry, it could be that the application (Compass) just keeps a history of what these have been, and just uses the most recent one by default, or allows the user to select or add new ones. That’s my guess for now anyway.

After all the datum stuff, I find this interesting entry:

<CD_WELLBORE
  well_id="2DfUHhBj3x"
  wellbore_id="3W9ZjV2yj0"
  wellbore_type_policy_id="vyxGFUk61o"
  wellbore_type_id="APPR "
  parent_wellbore_id="uLkXB6Hbm2"
  is_deviated="Y"
  ko_md="8284.448818864501"
  well_legal_name="NO 15/9-F-11 A"
  wellbore_name="15/9-F-11 A"
  is_readonly="N"
  create_date="{ts '2009-01-13 13:25:10'}"
  create_user_id="marmo"
  create_app_id="COMPASS"
  update_date="{ts '2013-05-31 14:16:52'}"
  update_user_id="stgal(STGAL@STATOIL.NET)"
  update_app_id="COMPASS"
  default_fluid_id="VqFf0"
  />

Basically, this is the high level information for an actual wellbore. It contains names and references as usual (linked to CD_WELL throught well_id), but also relevant information on whether this is a deviated well with a kick off depth. It also contains a reference to another wellbore through parent_wellbore_id, which for this case is the wellbore that this deviated well started from. It’s kind of interesting that all the CD_WELLBOREentries have the is_deviated flag set to true. Not sure why that is, but it could be some user interface issue in Compass, just speculating.

Next up we have entries such as these:

<CD_ASSEMBLY
  well_id="2DfUHhBj3x"
  wellbore_id="3W9ZjV2yj0"
  assembly_id="01sXi"
  string_type="Casing"
  assembly_name="9 5/8&quot;"
  assembly_size="9.625"
  hole_size="12.250000000000002"
  plan_depth_type="0"
  md_assembly_base="8678.1496062645"
  tvd_assembly_base="8403.2808398614"
  create_date="{ts '2010-07-08 10:38:10'}"
  create_user_id="ksva(KSVA@STATOIL.NET)"
  create_app_id="COMPASS"
  update_date="{ts '2010-08-27 13:46:08'}"
  update_user_id="ksva(KSVA@STATOIL.NET)"
  update_app_id="COMPASS"
  />
<CD_ASSEMBLY
  well_id="2DfUHhBj3x"
  wellbore_id="3W9ZjV2yj0"
  assembly_id="0boe3"
  string_type="Casing"
  assembly_name="20&quot; Surface Casing"
  assembly_size="20.0"
  hole_size="26.000000000000004"
  plan_depth_type="0"
  md_assembly_base="4084.9737532645"
  tvd_assembly_base="4167.8477690122"
  create_date="{ts '2010-07-13 10:05:40'}"
  create_user_id="ksva(KSVA@STATOIL.NET)"
  create_app_id="COMPASS"
  update_date="{ts '2010-11-04 15:20:14'}"
  update_user_id="wada(WADA@STATOIL.NET)"
  update_app_id="COMPASS"
  />

These describe where casing sections / strings change in a wellbore. It’s not enough information to be used for actual casing design, but it does enable the applicaitons (Compass?) to visually indicate where various casing sections appear along the wellbore. But after these, we find entries such as the ones below:

<CD_ASSEMBLY_COMP
  well_id="2DfUHhBj3x"
  wellbore_id="3W9ZjV2yj0"
  assembly_id="0GmRW"
  assembly_comp_id="c1LiG"
  sect_type_code="DP"
  material_id="CS_AP1"
  grade_id="S"
  average_joint_length="31.1679790025"
  closed_end_displacement="0.030501605117665"
  catalog_key_desc="Drill Pipe, 5,500 in, 21,90 ppf, S-135, FH VAM EIS"
  connection_name="FH VAM EIS"
  fatigue_endurance_limit="19999.999999872"
  density="490.0"
  grade="S-135"
  length="8200.3772965551"
  id_body="4.778"
  linear_capacity="0.020858420093036"
  id_connection="3.5"
  material="CS_API 5D/7"
  joints="264"
  length_tool_joint="2.00131233595"
  makeup_torque="56261.240748604"
  poissons_ratio="0.3"
  min_yield_stress="134999.99999914"
  od_body="5.5"
  od_connection="7.25"
  thermal_expansion_coef="6.9E-6"
  ultimate_tensile_strength="144999.99999907"
  approximate_weight="21.9"
  youngs_modulus="3.0E7"
  service_class="P"
  sequence_no="100000"
  wall_thickness_percent="80.0"
  connection_torsional_yield="92400.015915146"
  comp_type_code="DP"
  />
<CD_ASSEMBLY_COMP
  well_id="2DfUHhBj3x"
  wellbore_id="3W9ZjV2yj0"
  assembly_id="0GmRW"
  assembly_comp_id="cnpIr"
  sect_type_code="BIT"
  average_joint_length="1.000656167975"
  closed_end_displacement="0.070185545661428"
  catalog_key_desc=", 0x16, 0x13, 0x15, 0,701 in&#xB2;"
  length="1.000656167975"
  linear_capacity="0.0"
  joints="1"
  od_body="8.5"
  approximate_weight="90.0"
  sequence_no="1200000"
  comp_type_code="PDC"
  tfa="0.0048789111171504"
  />

These entries map back to the CD_ASSEMBLY entries through the assembly_id field, and provide more information about the actual tools/pipes/material used in the casing section. These properties are needed for various stress calculations, torque and drag and CFD / temperature modelling. Please note that the two examples above shows to different kinds of assemblies. The first one is probably a drill pipe (comp_type_code="DP"), while the second one is a bit (comp_type_code="PDC" and sect_type_code="BIT"). There are other types of CD_ASSEMBLY_COMP entries as well, examples are DC, JAR, IBS, BS, MWD, HOO, BHM.... I’m not going into detail about all of these (yet at least).

Below these again I find entries like this:

<CD_BHA_COMP_BIT
  well_id="2DfUHhBj3x"
  wellbore_id="3W9ZjV2yj0"
  assembly_id="0GmRW"
  assembly_comp_id="cnpIr"
  />

and

<CD_BHA_COMP_DP_HW
  well_id="2DfUHhBj3x"
  wellbore_id="3W9ZjV2yj0"
  assembly_id="0GmRW"
  assembly_comp_id="c1LiG"
  />

These are used for connecting all the relevant assemblies (and -types) to specific wells and wellbores, and does not seem to contain any other useful information. It’s all probably related to how relational databases actually work, using ids to be able to join everything when needed. Unfortunately, this also means that it is a lot harder to build higher level objects like casing design or trajectory, because it has to be created by joining everything together before such objects can exist. There’s nothing wrong with relational databases and they do have lots of interesting properties (like speed and compactness), but exposing relational data in raw format as is done here makes it very hard for other systems to interact with (typically) higher level objects (the things we actually relate to, not individual pieces of it).

Next up we have entries like this:

<CD_BHA_COMP_JAR
  well_id="2DfUHhBj3x"
  wellbore_id="3W9ZjV2yj0"
  assembly_id="0GmRW"
  down_set_force="0.0"
  assembly_comp_id="cyPyH"
  down_trip_force="0.0"
  pump_open_force="0.0"
  friction_seal_force="0.0"
  up_set_force="0.0"
  up_trip_force="0.0"
  />
<CD_BHA_COMP_MOTOR
  well_id="2DfUHhBj3x"
  wellbore_id="3W9ZjV2yj0"
  assembly_id="0GmRW"
  assembly_comp_id="YMPP1"
  steering_tool_bend_angle="0.0"
  flowrate_1="475.50000000002"
  steering_tool_offset="0.0"
  flowrate_2="501.9268665"
  flowrate_3="554.7612735"
  kick_pad_length="0.0"
  flowrate_4="581.178477"
  kick_pad_od="0.0"
  kick_pad_offset="0.0"
  press_loss_1="91.373751"
  press_loss_2="101.52639"
  press_loss_3="123.282045"
  press_loss_4="136.335438"
  is_top_stabilizer="N"
  is_bottom_stabilizer="N"
  top_stabilizer_OD="0.0"
  top_stabilizer_length="0.0"
  top_stabilizer_distance="0.0"
  bottom_stabilizer_OD="0.0"
  bottom_stabilizer_length="0.0"
  bottom_stabilizer_distance="0.0"
  />
<CD_BHA_COMP_MWD
  well_id="2DfUHhBj3x"
  wellbore_id="3W9ZjV2yj0"
  assembly_id="0GmRW"
  flowrate_1="475.509663"
  assembly_comp_id="C8BtF"
  flowrate_2="501.9268665"
  flowrate_3="554.7612735"
  flowrate_4="581.178477"
  press_loss_1="393.052167"
  press_loss_2="438.013854"
  press_loss_3="535.189113"
  press_loss_4="587.402685"
  create_date="{ts '2010-11-09 13:33:00'}"
  create_user_id="wada(WADA@STATOIL.NET)"
  create_app_id="COMPASS"
  />
<CD_BHA_COMP_NOZZLE
  well_id="2DfUHhBj3x"
  wellbore_id="3W9ZjV2yj0"
  assembly_id="0GmRW"
  assembly_comp_id="cnpIr"
  nozzle_id="5luws"
  nozzle_diameter="13.0"
  nozzle_count="0"
  create_date="{ts '2010-11-09 13:32:59'}"
  create_user_id="wada(WADA@STATOIL.NET)"
  create_app_id="COMPASS"
  />
<CD_BHA_COMP_STAB
  well_id="2DfUHhBj3x"
  wellbore_id="3W9ZjV2yj0"
  assembly_id="0GmRW"
  stab_blade_od="8.375"
  assembly_comp_id="GD2nk"
  stab_blade_length="1.0"
  create_date="{ts '2010-11-09 13:33:00'}"
  create_user_id="wada(WADA@STATOIL.NET)"
  create_app_id="COMPASS"
  />

These are simple definitions of hardware used by other modules, so I am not going into more detail on these for now. After these we have entries like below:

<CD_WEQP_PACKER
  well_id="2DfUHhBj3x"
  wellbore_id="uLkXB6Hbm2"
  assembly_id="nc0MB"
  assembly_comp_id="Bibpj"
  packer_name="Packer @ 3064"
  packer_depth="9872.3753280445"
  plug_depth="9967.5196849995"
  hydraulic_set_pressure="1493.88831"
  slip_type="0"
  id_packer_bore="7.0"
  axial_load_change="0.0"
  axial_load_change_direction="0"
  is_seal_bore_present="N"
  seal_assembly_type="0"
  is_seal_movement_allowed="N"
  upward_movement_len="30.0"
  downward_movement_len="0.0"
  is_upward_nogo_present="N"
  is_downward_nogo_present="Y"
  bore_inner_diameter="7.0"
  upward_movement_length="0.0"
  downward_movement_length="0.0"
  packer_type_flag="8"
  running_string_flag="0"
  set_type="2"
  hydrostatic_set_pressure="0.0"
  is_annular_valve_seal_open="N"
  expansion_joint_depth="9871.3753280445"
  is_sheared="N"
  shear_pin_rating="10000.0"
  pbr_total_stroke="30.0"
  is_spaced_out="N"
  is_exp_joint_nogo_present="N"
  />

Packers are important for stress calculations, and the dataset contains definitions for six types of packers used.

After the packers, there are quite a few of these:

<TU_COMP_TEMP_DERATION_POINT
  well_id="2DfUHhBj3x"
  wellbore_id="3W9ZjV2yj0"
  assembly_id="0gQkP"
  assembly_comp_id="abbTu"
  point_id="1nQVa"
  deration_temperature="68.0"
  correction_factor="1.0"
  />

These contain temperature deration data for the related assemblies (basically how their ratings decrease at higher temperatures). It also has a reference to a new type of entity point_id. So far I have not found any <...POINT...> type of entries in the dataset. And the point_id mentioned in the example above also does not exist. So at this point I am unable to comment on what type of data point_id actually points to. It is also a strong indication that there is some data missing from the dataset, or that it is hidden inside of some of the blobs (Binary Large Objects) which are typically unreadable to any other systems except the ones that created them.

When opening up legacy systems, working with open systems in general and an important part of digitalization work when freeing data from legacy systems, it is very important to get rid of ALL blobs.

The previous article in this series can be found here.

The next article can be found here.

0
0
April 15, 2019