Define well data type

[perolavsvendsen]

Context

This task is connected to #501

Subtasks

• [ ] Agree on and describe format for exported well data
• [ ] Describe use case examples
• [ ] Agree on minimum viable context/metadata
• [ ] Implement in fmu-dataio assuming that the starting point is an xtgeo.Well object

Definition of Done

• An end user can implement an export script in FMU workflows, that exports well data with context (metadata) according to FMU data standard.
• The implementation is sustainable and intuitive, and follow existing conventions in fmu-dataio

[perolavsvendsen]

Discussions 13/12-2023 @jcrivenaes @HansKallekleiv

• There are endpoints on SSDL that can offer well paths and logs. However, no guarantee that these logs match those used in FMU.
• Operations can (will) happen to paths and logs before/during FMU runs.

Consider doing this: ---- Iteration 0 ----

• [ ] Design/make export functionality for paths/logs to be inserted into FMU
• [ ] Export wells/logs out of FMU, upload to Sumo, consume in Webviz

Options:

• Export single object, split to multiple objects prior to upload
• Export single object, upload single object, consume single object
• Export multiple objects, upload/consume multiple objects

Well paths:

class: well_path??
data:
  name: <name as in RMS etc>
  content: well_path
  well_path:
    logrun: XX
    datum: msl

Well logs:

class: well_log??
data:
  name: <name as in RMS etc>
  content: well_log
  well_log:
    logrun: XX
    datum: msl
    discrete: True
    discrete_codes:
      1: ValueThree
      2: ValueTwo

OR export as one table path + logs? xtgeo.well.Well-object contains:

• Path
• All logs as table

As one object:

data:
  content: well
  well:
    logrun: XX
    datum: msl
    logs:
      MyLog:
        discrete: True
        discrete_codes:
          1: ValueThree
          2: ValueTwo
      MyOtherLog:
        discrete: True
        discrete_codes:
          1: ValueThree
          2: ValueTwo

Sounds like we are leaning towards something like this:

• In export script (inside/outside RMS), arrive at an xtgeo.well.Well object.
• Feed that to fmu.dataio.ExportData.export()
• fmu-dataio knows the object
• Under the hood, split the object into separate files. One for path, one per log.
• Consider some book-keeping here, aligned with metadata definitions. E.g. define a uuid for this well object, which is inserted into each resulting files metadata. That way, they can be linked afterwards.
• We can consider putting references into the path object to the existing log objects, but that has to be done with care - what if we append/remove something later?
• Probably, this will play nice with Elasticsearch: 1) Query the wells via their paths to obtain the path + the uuid, then 2) query the logs with the same uuid.

Some basic requirements as always:

• [ ] Any additions to the metadata must follow the same conventions as we are already using
• [ ] Export patterns intended to be placed inside FMU must follow the same patterns as established.

---- Iteration 1 ----

• [ ] Reduce size of exported data (e.g. concatenate discrete logs)
• [ ] Add links to masterdata. Option to just use data.name as for stratigraphic objects? Can data.name be linked to uwi (well name as a string, Universal Well ID)

Ever-returning discussion: What about masterdata (for wells) in FMU?

Translation, as for stratigraphic column? "12/2-7": "smda":

[HansKallekleiv]

uwi exists in RMS. Accessible in the API as well.wellbore.uwi.
It might not always be defined, but if it is defined it should be enough to tie the well to masterdata.

==> Include uwi in metadata when exporting wells from rms.