EPIC: Sustainable handling of master/reference data inside FMU

[perolavsvendsen]

Background

All data produced by FMU workflow shall be tagged with the corresponding entities in SMDA, where applicable. This is fundamental for consumers to be able to utilize the data, and for ensuring basic governance. Currently, we include the following:

General tags (field, discovery, country, coordinate reference system and stratigraphic column) are included in the general SDMA block in produced metadata. They are configured using global_variables.yml.

In addition, there is currently functionality for linking to individual horizons/units in the stratigraphic column. This is done via data.name, which acts as the identifier and is thus matched to the stratigraphic column. Internal names of horizons (e.g. inside RMS) are not, and can not be, expected to follow the stratigraphic column. Therefore, we currently change the name of horizons upon export. This is done via a lookup dictionary located in global_variables.yml.

Elements that are connected to a unit in the stratigraphic column, will have data.stratigraphic=True and the value of data.name will be identical to the corresponding identifier in the stratigraphic column.

Going forward, more master/reference data will be expected to be included in outgoing FMU results, particularly well UUIDs (i.e. this issue)

Topics to consider

• Should configuration of master/reference data still be in global_variables, or should we consider doing this online instead. Standalone Radix application, SMDA, Sumo, etc.

Definition of Done

• All data produced by all FMU workflows are tagged with the corresponding master/reference data where applicable.
• Handling of master/reference data in FMU workflows are comprehensible and user friendly.
• Handling of master/reference data in FMU workflows are expandable, scalable and changeable.

[To be further refined.]