#subsurface development

https://github.com/softwareunderground/subsurface

Software design description:

https://hackmd.io/M5SDrwCWSI-oVNOvKnGDJA?edit

Catch-up meeting I (2020/09/28, 16:00 UTC)

YouTube recording: https://youtu.be/-fnbWPhW-1Q

Dom: Could we add attributes to primary structures? (eg. a colormap, a json); a dict or something to pass, like meta-data
Zane: Problem of agreeing on a thing, even if it is strike/dip people hugely disagree
subsurface should just be subsurface, and the other packages should have the wrappers for it
Martin: what if you want to move, e.g., from PyGIMLi to GemPy?
Lindsey: optional meta read-in
Dom: so all packages should write to_subsurface and from_subsurface functions
Dieter: Some sort of a type attribute, e.g., mtype (for mesh-type) or etype (for element-type); type is fundamental to Python, and so is dtype for NumPy, and having something similar could prove very valuable down the road. Think of a good name.
Rowan: It has to be useful and save people time, then it will be used
How much stuff should we allow (how many arguments/attributes, or just dicts)
Collect snippets that lie around on GitHub to read in certain data formats - but when doing thin make sure to not increase dependencies, all optional => at a later point it might become subsurface-io
Florian: From user perspective it would be nice to have high-level meta data; have a hierarchy of objects
Dom: As long as the high-level stuff is always the same it is fine and doesn't matter too much