Inplace_volumes: Include relative sorting of ZONE

[perolavsvendsen]

User story

As a consumer of FMU Initial Inplace Volumes, I would like to know the relative order of the ZONE values, so that I can display them correctly.

Background/description

Inplace volumes are exported as CSV-formatted tables, where ZONE is a standard (index) column. The values ZONE correspond to the zones in the grid from which the volumes were calculated. However, no information is currently included on the relative sorting of these values. The (normally) correct way to sort these is stratigraphic, from youngest to oldest.

(Other possible sortings are also used, e.g. by volume value.)

A possible mitigation of this would be to get and include the relative order of ZONE values in the outgoing metadata so that consumers can use that as a guide for sorting the tables when displaying.

Tasks

• Investigate if we can actually know the internal stratigraphic order (do they appear stratigraphically sorted from the RMS volumetrics job?) (Assumption is that they do.)
• Get the internal sorting, and include it in metadata.

Suggested metadata structure

This is highly related to the larger topic of "internal master data". However, as a step on the way, perhaps do this as part of the specific metadata structure for inplace volumes, e.g.:

# consider this as pseudo-code, may not reflect the actual implementation
data:
  product:
    name: inplace_volumes
  content: inplace_volumes
  inplace_volumes:
    zones: # sorted dictionary, i.e. enumerating it gives sort order
      - name: MyZoneA
        smda:
          identifier: My Zone. A # if in the stratigraphic column
      - name: MyZoneB
        smda:
          identifier: My Zone. A # if in the stratigraphic column

There are many other, possibly better, implementations of this. The above included as one example, for discussion.

Alternative: Add code/label mapping for discrete parameters?

data:
  product:
    inplace_volumes:
  content: inplace_volumes
  inplace_volumes:
    mapping:
      ZONE:  # same as parameter name?
        - name: MyZone
          code: 1
        - name: MyOtherZone
          code: 2

Requirements

• Can be sustainably and consistently produced
• Positive or negligible negative influence on user experience
• Positive or negligible negative influence on robustness & changeability

Feedback

• Webviz

FMU results epic

• https://github.com/equinor/fmu-results-activities/issues/3

Related

• Inplace Volumetric Table ordering by identifier values webviz#728

[anders-kiaer]

Related comment perhaps: #337 (comment)

[anders-kiaer]

Another potentially related issue from RMS master list: https://github.com/equinor/rms-master-list/issues/9#issuecomment-2317343722

RMS-65348 - Extract "stratigraphic columns" - V14.5

[jcrivenaes]

I would think that zone descriptions/ordering should be on a higher level than just in-place volumes. Perhaps it belongs more to model than individual data?

[perolavsvendsen]

I would think that zone descriptions/ordering should be on a higher level than just in-place volumes. Perhaps it belongs more to model than individual data?

Yes, this would typically be a (FMU) master data thing. But it would be beneficial to have this also in the metadata for inplace volumes. So if there was master data available, the export function could get it from there. But I think, as a first iteration, we could solve this by getting it directly from RMS? fmu-dataio should have this information already when the inplace oneliner runs, I think.

(The (FMU) master data discussions are not done, but I imagine that if ZONE was in some central masterdata we would still have to confirm that the zoning in RMS is synched to it. So would probably read zoning from RMS anyways.)