# #subsurface development
> https://github.com/softwareunderground/subsurface

Software design description:
> https://hackmd.io/M5SDrwCWSI-oVNOvKnGDJA?edit
###### tags: `t20-gostin`

[ToC]

## Catch-up meeting I (2020/09/28, 16:00 UTC)
> YouTube recording: https://youtu.be/-fnbWPhW-1Q

#### Participants
- Miguel (GemPy)
- Martin Bentley
- Bane Sullivan (PyVista)
- Carsten (PyGIMLi)
- Dominique Fournier (SimPEG, geoh5py)
- Florian Wagner (PyGIMLi)
- Lindsey Heagy (SimPEG)
- Rowan Cockett (SimPEG)
- Thomas Günther (PyGIMLi)
- Zane Jobe
- Dieter Werthmüller
- Franklin Koch (OMF)

### Some few notes (please add as you see fit)

- 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