equinor / equinor/xtgeo

Discussion: Idea for refactoring parts of grid

Open
#641 0 comments 0 reactions 0 assignees View on GitHub
Dominant language
Python
Stars
122
Forks
67
Avg merge
1d 20h
Merged PRs (30d)
19

Description

As a part of (or replacement of) some points in #556, methods calculating various properties related to the geometry of the Grid class (ie. not belonging to actnum or the grids properties) could be separated into using a public facing interface. In #640 a design idea for an abstract class, implemented by Grid (and possibly also directly by `RoffGrid` and `EclGrid`) through which several methods of Grid can be replaced (for instance `get_cell_volume`, `get_xyz_cell_corners`, `get_xyz_corners`, `get_layer_slice`, `get_geometrics`, `get_randomline`, `get_dz`, etc.) by a function which the interface knows nothing about.

This means more flexibility for the user, and less implementation details for us.

Contributor guide

Open the contributing guide

Research direction

Start by reading discussions #556 and #640, then review the listed Grid geometry methods: get_cell_volume, get_xyz_cell_corners, get_xyz_corners, get_layer_slice, get_geometrics, get_randomline, and get_dz. The issue does not define the interface or a concrete completion boundary; done would require an agreed design and corresponding separation of these methods from Grid implementation details.

Written by the indexing model from the issue text.

Assessment

Tech stack
python
Domain
backend-api-design, data
Issue type
Refactor
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.