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

The following article is based on the original blog post here.

We continue to look at elements related to trajectory design and casing design from Equinor's released dataset from Volve.

Marius Kjeldahl
CTO
TwitterLinkedinEmail

The next set of headers I’m finding are survey related information (trajectories):

<CD_DEFINITIVE_SURVEY_HEADER
  well_id="2DfUHhBj3x"
  wellbore_id="3W9ZjV2yj0"
  def_survey_header_id="iM93r"
  phase="PLAN"
  effective_date="{ts '2013-07-01 00:00:00'}"
  create_date="{ts '2013-05-08 10:41:14'}"
  b_range="Y"
  bh_md="12004.63809999738"
  bh_tvd="9952.034120695102"
  create_user_id="stgal(STGAL@STATOIL.NET)"
  name="Wellpath"
  create_app_id="COMPASS"
  update_date="{ts '2013-07-01 14:31:43'}"
  planned_azimuth="21.24472989707695"
  update_user_id="thhi(THHI@STATOIL.NET)"
  is_readonly="N"
  update_app_id="COMPASS"
  ko_md="8251.6404199145"
  ko_tvd="7826.139054854131"
  vs_east="0.0"
  vs_north="0.0"
  acscan_md_min="-1140.9107154385615"
  acscan_md_max="869.0493370755241"
  acscan_radius_max="95.001685493573"
  acscan_ratio_max="2235.365324780968"
  directional_difficulty_index="6.149653836913327"
  maximum_dls_value="3.2512000000000008"
  maximum_dls_depth="11526.552240874082"
  tortuosity="2.3442803342029035"
  average_dogleg="2.3442803342029035"
  />

These are created by Compass, and contain survey related information, including links to the well (well_id) and wellbore (wellbore_id). I’m guessing bh_md and bh_tvd is the bottomhole information (the end of the drilled trajectory). Furthermore we have ko_md and ko_tvd, which probably is the kickoff point depth for this survey (meaning it’s a kick-off well from another well). It also contain dogleg related information (min, max, average).

After these, I’m finding these:

<CD_DEFINITIVE_SURVEY_STATION
  well_id="2DfUHhBj3x"
  wellbore_id="3W9ZjV2yj0"
  def_survey_header_id="iM93r"
  definitive_survey_id="1N3tV"
  azimuth="58.624316314247515"
  offset_east="-1019.0767804354808"
  offset_north="154.1907353425347"
  covariance_yy="1.0E-8"
  sequence_no="4"
  ellipse_vertical="0.0"
  covariance_yz="0.0"
  covariance_zz="0.0"
  covariance_xx="1.0E-8"
  data_entry_mode="0"
  covariance_xy="0.0"
  dogleg_severity="3.048"
  inclination="34.3183355185143"
  covariance_xz="0.0"
  ellipse_east="0.0"
  ellipse_north="0.0"
  md="8483.5301836931"
  casing_radius="7.0"
  tvd="8014.196038889808"
  global_lateral_error="0.0"
  />

This is a survey station point, taking into consideration the error models from the measurement equipment used. Covariances describe the combined error terms from the selected error model used. In addition there are various other related information, like casing width at that point, and information about the generated error ellipses (typically generated from the covariances) and position information.

Then we have:

<CD_SURVEY_PROGRAM
  well_id="2DfUHhBj3x"
  wellbore_id="3W9ZjV2yj0"
  tie_wellbore_id="3W9ZjV2yj0"
  def_survey_header_id="iM93r"
  survey_program_id="qIQwH"
  survey_header_id="1HKW5"
  md_base="12004.63809999738"
  md_top="8251.6404199145"
  sequence_no="0"
  not_in_use="0"
  override="0"
  />

I can not say with confidence what this is yet, but it looks like data about a trajectory range where surveys will be taken, probably using specific measurement equipment and error model. Then these:

<CD_VERTICAL_SECTION
  well_id="2DfUHhBj3x"
  wellbore_id="3W9ZjV2yj0"
  sequence_no="0"
  def_survey_header_id="iM93r"
  vertical_section_id="vV6kJ"
  tvd_start="298.556430445"
  vsa_type="0"
  vs_angle="21.24472989707695"
  vs_north="0.0"
  vs_east="0.0"
  vso_type="0"
  />

This sounds like trajectory sections that are marked as vertical (either straight down, or possibly meaning zero curvature with the given angle [inclination?]). For this to make any sense, the section should have a certain length as well. But if this is just a point in a list (given by sequence_no), the lengths would be implicit based on the position in the list. But since I’m only finding sequence_no equal to zero, this is probably wrong. So I’m a bit unsure how these are actually used, probably need to speak to a Compass user to figure it out.

Next up we have:

<DP_ANTICOL
  offset_well_id="2DfUHhBj3x"
  well_id="2DfUHhBj3x"
  wellbore_id="3W9ZjV2yj0"
  offset_wellbore_id="3W9ZjV2yj0"
  def_survey_header_id="iM93r"
  offset_def_survey_header_id="MQ9kY"
  />

Anti collision is related to survey point measurements, error models and covariance/error ellipses. The xml shown above doesn’t contain any actual information other than tying together / grouping other data objects.

Finally, I’m seeing just a few of these:

<WP_CASE_TORT_INT
  well_id="f8a0BsD35Y"
  wellbore_id="NMfISMBKlD"
  sequence_no="600000"
  def_survey_header_id="iFoyo"
  wp_case_tort_int_id="1Q8B4"
  />

I have no idea what these are yet.

Next in the file I’m seeing something “interesting” (from a software developer’s point of view at least). There are pairs of these entries:

<execsql command="delete from CD_FLUID where well_id='2DfUHhBj3x' and wellbore_id='3W9ZjV2yj0' and fluid_id='1WEoS'"/>

<CD_FLUID  well_id="2DfUHhBj3x"
  wellbore_id="3W9ZjV2yj0"
  phase="PROTOTYPE"
  conc_nacl="0.0"
  density="1.1490873082823"
  fluid_name="WBM 1.4 Conventional"
  fann_data_source="0"
  gels_0_sec="0.0"
  k_prime_parameter="0.0"
  fluid_id="1WEoS"
  n_prime_parameter="0.0"
  method="0"
  is_cement="N"
  percent_water="0.0"
  is_spacer_fluid="0"
  percent_oil="0.0"
  mudbase_type="0"
  plastic_viscosity="2.3173289254066"
  solids_sg_avg="0.0"
  rheology_model="2"
  temp_density="0.0"
  owr_oil="0.0"
  water_requirement="0.0"
  yield_point="2.067586372969"
  create_date="{ts &apos;2010-09-24 12:12:43&apos;}"
  create_user_id="meu(MEU@STATOIL.NET)"
  create_app_id="WELLPLAN 5000.1"
  update_date="{ts &apos;2010-11-25 08:54:22&apos;}"
  update_user_id="meu(MEU@STATOIL.NET)"
  update_app_id="WELLPLAN 5000.1"
  yield="0.0"
  is_foamed="N"
  class="Other"
  custom_base_fluid="Water"
  is_recalc_required="N"
  />

The first is an xml representation of an actual database command which deletes an entry from a database table named CD_FLUID. The second looks very much like the entry that the database command would delete. It could be that this is some kind of “archive” of deleted entries (fluids in this case). I sure hope these fluids aren’t Equinor secrets (something they tried to delete before dumping the data).

Next up we have more fluid data:

<WP_FLUID_TEMP
  well_id="2DfUHhBj3x"
  wellbore_id="3W9ZjV2yj0"
  fluid_id="1WEoS"
  temp_id="SS5H7"
  gels_zero_sec="9.6158313399559"
  n_prime_parameter="0.66297366167858"
  k_prime_parameter="0.0052824418590069"
  plastic_viscosity="17.59468995261"
  temperature="122.0"
  yield_point="9.6158313399559"
  quality="0.0"
  density="11.6835669818"
  is_foamed="N"
  m_parameter="0.0"
  mu_inf="0.0"
  fysa="0.0"
  is_quality="N"
  pressure="14.695948701525"
  base_density="11.6835669818"
  is_reference="Y"
  />

These are obviously fluid related data. It looks like data that in sum could be tables of fluid phase transition points (similar to those created by software like PVTSim or MultiFlash). Next:

<WP_FLUID_TEMP_FANN_DATA
  well_id="2DfUHhBj3x"
  wellbore_id="3W9ZjV2yj0"
  fluid_id="1WEoS"
  temp_id="SS5H7"
  fann_data_id="0T5H7"
  deflection="24.0"
  rpm="100.0"
  />

More fluid data, this time related to machine data (rpm - rotatio speed most likely).

Next there’s just a few of these:

<CD_FORMATION_INFLUX_GROUP
  well_id="6ekXXuRhFd"
  wellbore_id="FHcPbdxSIP"
  formation_influx_group_id="YLmVm"
  use_formation_influx="N"
  />

This again is just a grouping / relational entry, joining together other actual data in a group. Not much to comment. The next one is similar, related to fracture gradients:

<CD_FRAC_GRADIENT_GROUP
  well_id="2DfUHhBj3x"
  wellbore_id="3W9ZjV2yj0"
  frac_gradient_group_id="0G45J"
  phase="PROTOTYPE"
  name="Frac Gradient"
  create_date="{ts '2010-12-14 15:20:44'}"
  create_user_id="bdil(BDIL@STATOIL.NET)"
  create_app_id="StressCheck 5000.1"
  update_date="{ts '2012-05-15 12:48:48'}"
  update_user_id="sveio"
  update_app_id="StressCheck 5000.1"
  />

These groups probably contain entries of points like the ones found next in the file, like this:

<CD_FRAC_GRADIENT
  well_id="2DfUHhBj3x"
  wellbore_id="3W9ZjV2yj0"
  frac_gradient_group_id="0G45J"
  frac_gradient_id="04vxj"
  frac_gradient_emw="13.636391748758"
  frac_gradient_pressure="5368.652800122719"
  sequence_no="43300"
  tvd="7398.6220472145"
  />

These fracture gradients are mostly tables of depth and value information, where software would look up depths and use interpolation to find relevant values for any depth. These are typically related to the external pressure when calculating load cases for casing design, and to make sure a formation can hold the pressure applied when drilling without breaking.

After these, I find this:

<CD_HOLE_SECT_GROUP
  well_id="2DfUHhBj3x"
  wellbore_id="3W9ZjV2yj0"
  hole_sect_group_id="0cF2A"
  phase="PROTOTYPE"
  hole_name="Hole Section"
  create_date="{ts '2010-11-04 15:00:10'}"
  create_user_id="wada(WADA@STATOIL.NET)"
  create_app_id="COMPASS"
  update_date="{ts '2010-11-15 14:00:38'}"
  update_app_id="WELLPLAN 5000.1"
  md_hole_sect_base="14032.4803149045"
  />

Again, grouping information for hole section it seems, no actual data besides naming and references. The actual data it groups is more interesting, and follows, and looks like this:

<CD_HOLE_SECT
  well_id="2DfUHhBj3x"
  wellbore_id="3W9ZjV2yj0"
  hole_sect_group_id="0cF2A"
  hole_sect_id="14LRC"
  id_casing="18.73"
  sect_type_code="CAS"
  od_casing="20.0"
  comp_type_code="CAS"
  hole_size="18.73"
  sequence_no="101000"
  catalog_key_desc="20 in, 133 ppf, Tenaris ER"
  cof="0.25"
  linear_capacity="1.9133927157259"
  id_drift="18.543"
  length="3799.21259841"
  md_shoe="4281.8241469645"
  />

This is a casing section, containing the dimension of the casing and hole, as seen from WellPlan’s point of view.

Similar to fracture gradients, the data now show the same for pore pressures:

<CD_PORE_PRESSURE_GROUP
  well_id="2DfUHhBj3x"
  wellbore_id="3W9ZjV2yj0"
  pore_pressure_group_id="05YiH"
  phase="PLAN"
  name="Pore Pressure"
  create_date="{ts '2014-08-05 15:26:00'}"
  create_user_id="linbj(LINBJ@STATOIL.NET)"
  create_app_id="StressCheck 5000.1"
  update_date="{ts '2014-08-05 15:26:00'}"
  update_user_id="linbj(LINBJ@STATOIL.NET)"
  update_app_id="StressCheck 5000.1"
  />

<CD_PORE_PRESSURE
  well_id="2DfUHhBj3x"
  wellbore_id="3W9ZjV2yj0"
  pore_pressure_group_id="7d3cj"
  pore_pressure_id="01lK5"
  pore_pressure_emw="7.594318538170001"
  is_permeable_zone="N"
  pore_pressure="634.2182844994942"
  sequence_no="6900"
  tvd="1427.4934383145"
  />

Next up I’m seeing these:

<CD_SCENARIO
  well_id="2DfUHhBj3x"
  wellbore_id="3W9ZjV2yj0"
  scenario_id="DO0Bj"
  phase="PLAN"
  datum_id="nwpsa"
  survey_header_id="1HKW5"
  temp_gradient_group_id="ctgEE"
  name="15/9-F-11 A NWest PIL DG3 rev0"
  pore_pressure_group_id="05YiH"
  frac_gradient_group_id="aRFFk"
  def_survey_header_id="iM93r"
  is_readonly="N"
  create_date="{ts '2013-05-08 10:41:14'}"
  create_user_id="stgal(STGAL@STATOIL.NET)"
  create_app_id="COMPASS"
  update_date="{ts '2014-08-05 15:26:00'}"
  update_user_id="linbj(LINBJ@STATOIL.NET)"
  update_app_id="StressCheck 5000.1"
  />

These looks to tie together information related to a wellbore, tying in fracture and pore pressure tables. Coming from Compass it seems.

After entries like these, I’m seeing some more StressCheck data:

<TU_CASE_PARAMETER
  well_id="QI7CBPwysf"
  application_name="StressCheck"
  wellbore_id="UM4qDyAgt4"
  scenario_id="168VT"
  parameter_id="2fv1G"
  measure_id="57"
  parameter_name="PackerFluidDensity"
  parameter_value_num="8.6"
  />

<TU_CASE_PARAMETER
  well_id="QI7CBPwysf"
  application_name="StressCheck"
  wellbore_id="UM4qDyAgt4"
  scenario_id="168VT"
  parameter_id="9WXg2"
  measure_id="96"
  parameter_name="CompTotalAxialCompForce"
  parameter_value_num="0.0"
  />

These look like generic parameter settings in StressCheck, both used for load cases, but also other internal data inside StressCheck. There are something similar, probably coming from the user, after these, looking like this:

<TU_CASE_USER_PARAMETER
  well_id="QI7CBPwysf"
  wellbore_id="UM4qDyAgt4"
  scenario_id="168VT"
  application_name="StressCheck"
  user_parameter_id="d6H1L"
  user_id="sigulu"
  parameter_name="LegendBlob"
  />

Hard to say what data it contains, and the reference to “blob” usually means it is something that only makes sense to the program that created the “blob” (StressCheck), so this needs more detective work if it is something important.

The next entries are simple. These are dogleg severity override tables, basically allowing users to input larger dogleg values than arising from the actual trajectories (when they are calculated as smaller, larger calculated values are typically not overridden):

<TU_DLS_OVERRIDE_GROUP
  well_id="2DfUHhBj3x"
  wellbore_id="3W9ZjV2yj0"
  scenario_id="DO0Bj"
  dls_override_group_id="xvBMF"
  create_date="{ts '2014-08-05 15:26:14'}"
  create_user_id="linbj(LINBJ@STATOIL.NET)"
  create_app_id="StressCheck 5000.1"
  />

<TU_DLS_OVERRIDE
  well_id="RL86lBsbE6"
  wellbore_id="0OL2SUGd7c"
  md_top="298.88451443450003"
  scenario_id="B49qo"
  dls_override_group_id="we8Zf"
  dls_override_id="3JyQ7"
  md_base="4262.1391075945"
  dogleg_severity="0.508"
  create_date="{ts '2011-01-05 08:55:13'}"
  create_user_id="sveio(SVEIO@STATOIL.NET)"
  create_app_id="StressCheck 5000.1"
  update_date="{ts '2011-01-05 08:55:13'}"
  update_user_id="sveio(SVEIO@STATOIL.NET)"
  update_app_id="StressCheck 5000.1"
  />

Like lots of other data in the data dump, it is organized as a group with many sub entries (I’m showing one of each above). The actual dls override entry consist of a md_top and md_base, which probably indicates for which depths this override should be active.

The next entries start with TU_MMS_APD. I’m not exactly sure what they point to yet, but showing them here for completeness:

<TU_MMS_APD
  well_id="QI7CBPwysf"
  wellbore_id="MEyUIaCFhT"
  scenario_id="kWlCh"
  />

<TU_MMS_APD
  well_id="QI7CBPwysf"
  wellbore_id="UM4qDyAgt4"
  scenario_id="168VT"
  gas_gradient="0.005194803467701704"
  masp_calc_method="Default"
  depth_ref_point="RKB"
  />

<TU_MMS_APD_DETAIL
  well_id="QI7CBPwysf"
  wellbore_id="UM4qDyAgt4"
  scenario_id="168VT"
  apd_detail_id="5W3gD"
  />

Next up:

<TU_ZONE_PRESSURE_GROUP
  well_id="2DfUHhBj3x"
  wellbore_id="3W9ZjV2yj0"
  scenario_id="DO0Bj"
  zone_pressure_group_id="yfIY9"
  create_date="{ts '2014-08-05 15:26:14'}"
  create_user_id="linbj(LINBJ@STATOIL.NET)"
  create_app_id="StressCheck 5000.1"
  />

Again a grouping entry. The name is indicating some kind of zone pressure groups. I’m sure I’ll find references to these later.

After these I find:

<CD_SURVEY_HEADER
  well_id="2DfUHhBj3x"
  wellbore_id="3W9ZjV2yj0"
  tie_wellbore_id="uLkXB6Hbm2"
  survey_header_id="1HKW5"
  survey_type="100"
  phase="PLAN"
  tie_survey_header_id="TCT4E"
  definitive_plan="0"
  survey_name="15/9-F-11 A NWest PIL DG3 rev0"
  tie_on_type="0"
  md_min="8251.6404199145"
  md_max="12004.63809999738"
  tie_on_depth="8251.6404199145"
  create_date="{ts '2013-05-08 10:41:14'}"
  create_user_id="stgal(STGAL@STATOIL.NET)"
  is_readonly="N"
  create_app_id="COMPASS"
  update_date="{ts '2013-07-01 14:31:42'}"
  update_user_id="thhi(THHI@STATOIL.NET)"
  update_app_id="COMPASS"
  directional_difficulty_index="6.149653836913327"
  maximum_dls_value="3.2512000000000008"
  maximum_dls_depth="11346.43413063858"
  tortuosity="2.344280334202911"
  average_dogleg="2.344280334202911"
  />

<CD_SURVEY_STATION
  well_id="2DfUHhBj3x"
  wellbore_id="3W9ZjV2yj0"
  survey_header_id="1HKW5"
  survey_id="aRMnl"
  azimuth="67.83193675764484"
  survey_date="{ts '2013-05-08 10:41:13'}"
  offset_east="-1140.9107154385615"
  offset_north="95.001685493573"
  inclination="36.93"
  build_rate="0.0"
  md="8251.6404199145"
  tvd="7826.139054854131"
  sequence_no="0"
  dogleg_severity="0.0"
  plan_method="0"
  tool_face_angle="0.0"
  station_type="1"
  turn_rate="0.0"
  />

These look almost identical to the one I’ve already commented on, CD_DEFINITIVE_SURVEY_HEADER and `CD_DEFINITIVE_SURVEY_STATION. I’m sure there’s some logic to it.

Similar to frac and pore pressure tables described already, next up are similar tables for geo temperatures:

<CD_TEMP_GRADIENT_GROUP
  well_id="2DfUHhBj3x"
  wellbore_id="3W9ZjV2yj0"
  temp_gradient_group_id="008YR"
  phase="PROTOTYPE"
  name="Geothermal Gradient"
  create_date="{ts '2012-06-13 15:52:39'}"
  surface_ambient_temp="80.0"
  mudline_temp="40.0"
  create_user_id="yhuel(YHUEL@STATOIL.NET)"
  create_app_id="COMPASS"
  temp_or_grad_ind="0"
  temp_tvd="233.6"
  grad_tvd="0.018701416434277"
  />

<CD_TEMP_GRADIENT
  well_id="2DfUHhBj3x"
  wellbore_id="3W9ZjV2yj0"
  temp_gradient_group_id="008YR"
  temp_gradient_id="EL08l"
  temperature="204.8"
  sequence_no="100000"
  tvd="8996.391076079499"
  />

Next up I’m seeing something that look like data from drilling equipment and OpenWire. I don’t know too much about those yet, so just showing them here:

<CD_WB_REAL_TIME_CONFIG
  well_id="2DfUHhBj3x"
  wellbore_id="3W9ZjV2yj0"
  config_id="dDOE1"
  code="WOB_MAX"
  curve_mnemonic="WOB_MAX"
  />

<CD_WB_REAL_TIME_CONFIG
  well_id="2DfUHhBj3x"
  wellbore_id="3W9ZjV2yj0"
  config_id="PUPgH"
  code="MDEP"
  curve_mnemonic="BITDEP"
  description="Updated from OpenWire"
  />

Next up there is wellbore formation data such as this:

<CD_WELLBORE_FORMATION
  well_id="2DfUHhBj3x"
  wellbore_id="3W9ZjV2yj0"
  wellbore_formation_id="3JSNK"
  phase="PROTOTYPE"
  dip_angle="0.0"
  formation_name="Hod_Fm_Top"
  sequence_no="12"
  create_date="{ts '2012-06-13 15:52:47'}"
  create_user_id="yhuel(YHUEL@STATOIL.NET)"
  prognosed_depth_type="0"
  prognosed_md="9961.6141731885"
  create_app_id="COMPASS"
  update_date="{ts '2012-06-22 12:50:46'}"
  prognosed_tvd="8865.847811273268"
  update_user_id="yhuel(YHUEL@STATOIL.NET)"
  update_app_id="COMPASS"
  />

This looks like depth references (along a trajectory) to formation data.

Next up we have:

<DP_MAGNETIC
  well_id="2DfUHhBj3x"
  wellbore_id="3W9ZjV2yj0"
  magnetic_model_id="Wb6iH"
  sequence_no="0"
  declination="-1.6666141934440468"
  declination_date="{ts '2010-12-31 00:00:00'}"
  dip_angle="71.62644156179012"
  field_strength="50438.96683711698"
  model_name="GEOMAGNETICREFERENCE"
  />

This relates to magnetic measurements used by survey station error modelling, containing the relevant measurement parameters (declinationdip_angle and field_strength), and references to when the measurement was done.

The next article will deal with the remaining data and will be linked in here when ready, but a sneak peek is that it looks like it will contain a lots of blobs and encoded binary attachments. It will demonstrate the issue with lots of legacy thick client software, where the data they expose is not readable to anybody but themselves. For all practical purposes, it’s internal data. Exposing internal data in a binary format typically means this data is useful for anything but backups (assuming the legacy software that created them can actually read them back, that’s not always the case either).

The next article (which conclude the analysis of the EDM dump) can be found here:

0
0
April 15, 2019