equinor / equinor/interpretation-models
Model SurfaceGrids/Horizons properties (Attribute Maps)
- Dominant language
- Python
- Stars
- 1
- Forks
- 0
- PR merge metrics
- No merged PRs in 30d
Description
We need to decide how to represent properties/attributes of a surface grid or horizon. Ideally research how OSDU (core) models it and try to align with that.
In OpenWorks LCM (common model), there are two separate tables, one for SurfaceGrid (structural surface - depth or time) and another for SurfaceGridProperties (other attributes). The SurfaceGridProperties has a link to a "surface_grid_parent_id", i.e., the structural surface that is its parent. They should all hav the same grid. For horizons there is a simiar treatment.
In OpenWorks Native Model, there is no concept for associating multiple properties of the "same" grid. The grid has domain time, depth or there, and there is no concept of parent, so there is no link between properties and a structural grid.
In Petrel, a surface grid can have multiple properties. That means the same record points to multiple arrays - one with the structure (depth or time) and any number of arrays containing other attributes defined on the same regular grid points. Same for horizons.
Currently in this repo we are following more or less a hybrid between OW Native and LCM - all grids from OW, both SurfaceGrid and SurfaceGridProperties end up in the same table (SurfaceGrid) but it exposes an optional "parent_id"
Previously there has also been discussion of attributes that are not hierarchically linked to one structural horizon, but rather to two of them (e.g. the average of an attribute between those two horizons). This does not map entirely to either the LCM or Petrel modelling of "properties of a horizon". Cases like that should also be taken into consideration.
Related comment: https://github.com/equinor/interpretation-models/pull/1#discussion_r2913287749
Contributor guide
No contributing guide indexed for this repository
Assessment
This issue has not been assessed yet.