• Borehole
• Cloud of points
• Seismic blocks
• Geophysical data
• Meshes
  ...

• dxf -> https://gdal.org/drivers/vector/dxf.html
  https://ezdxf.mozman.at/
• tif

tests/test_geological_formats/test_fault.py ... [ 7%]
tests/test_interfaces/test_to_binary.py E [ 10%]
tests/test_io/test_base_struc_io.py . [ 13%]
tests/test_io/test_read_profiles.py s. [ 18%]
tests/test_io/test_read_topography.py ss [ 23%]
/home/runner/work/_temp/f2105052-8883-464a-82e6-b86455ebf15d.sh: line 3: 2823 Segmentation fault (core dumped) pytest
tests/test_io/test_surface_reader.py ......
Error: Process completed with exit code 139.

I am getting an ImportError because I think the latest version of Pandas (v1.4) has changed some internal references to the Types used by Subsurface.

It looks like FilePathorBuffer has been split into two separate types. Perhaps it is not a great idea to import private Types from Pandas?

tests\test_accessor.py:29: in <module>
    from subsurface import StructuredData
C:\Users\trhal\miniconda3\envs\s38\lib\site-packages\subsurface\__init__.py:1: in <module>
    import subsurface.reader
C:\Users\trhal\miniconda3\envs\s38\lib\site-packages\subsurface\reader\__init__.py:5: in <module>
    from .topography.topo_core import read_structured_topography, read_unstructured_topography
C:\Users\trhal\miniconda3\envs\s38\lib\site-packages\subsurface\reader\topography\topo_core.py:3: in <module>
    from subsurface.reader.readers_data import ReaderFilesHelper, ReaderUnstructuredHelper
C:\Users\trhal\miniconda3\envs\s38\lib\site-packages\subsurface\reader\readers_data.py:9: in <module>
    from pandas._typing import FilePathOrBuffer
E   ImportError: cannot import name 'FilePathOrBuffer' from 'pandas._typing' (C:\Users\trhal\miniconda3\envs\s38\lib\site-packages\pandas\_typing.py)

I stumbled on this now while trying to push volume data to Liquid Earth. The StructuredData has five data sets named Features and Properties, X, Y, and Z. I talked to @Leguark and the bug looks obvious enough (as summarized in this title). For now I will proceed without modifying Subsurface because I can create a new StructuredData with only one data array (e.g. data_array = ss.StructuredData.from_numpy(geo_model.solutions.s_regular_grid.data.property_matrix.data) and achieve my current goal.

Dom has done already a function on simpeg to read at least one of the formats

https://programtalk.com/vs2/python/12012/simpeg/SimPEG/Utils/io_utils.py/

Transfered Issue 681 from the gempy repository.

User @neha845 reported an AttributeError when trying to read in a welly project via subsurface:

The class WellyToSubsurfaceHelper contains the methods to create a welly project and export it to a subsurface data class.
Error in the following line of code.
wts = sb.reader.wells.WellyToSubsurfaceHelper(collar_df=collar, survey_df=survey, lith_df=lith)

Screenshots

Desktop (please complete the following information):

• OS: Windows
• GemPy Version - 2.2.10

Trying on the same dataset as provided in the t21 tutorial - kim_ready.csv
https://github.com/cgre-aachen/gempy_workshops/blob/33e4f8651250494c1e76f4c7149aa8a021ce5ddb/workshops/Transform2021/t21_gempy.ipynb

https://github.com/holoviz/spatialpandas looks like it will expand into multi-dimensional uses better than straight geopandas. It is still in beta, but it is worth considering, at least.

We might be able to leverage this for some spatial operations on points and things.

Would be nice to have a better logo for subsurface

GemPy Tests are failing upstream as subsurface still uses cell_array/point_array in their PyVista functions.

Dear,

in Python 3.7 with a simple import subsurface I get the following error:

---------------------------------------------------------------------------
ImportError                               Traceback (most recent call last)
~\AppData\Local\Temp/ipykernel_16000/343840351.py in <module>
----> 1 import subsurface as sb
     2 from subsurface.reader import ReaderFilesHelper
     3 from subsurface.reader.wells import read_collar, read_lith, read_survey, WellyToSubsurfaceHelper, welly_to_subsurface

~\anaconda3\envs\gempy\lib\site-packages\shiboken2\files.dir\shibokensupport\__feature__.py in _import(name, *args, **kwargs)
   140         flag = -1
   141     pyside_feature_dict[importing_module] = flag
--> 142     return original_import(name, *args, **kwargs)
   143 
   144 _is_initialized = False

~\anaconda3\envs\gempy\lib\site-packages\subsurface\__init__.py in <module>
----> 1 import subsurface.reader
     2 import subsurface.interfaces
     3 import subsurface.writer
     4 from subsurface.structs import *
     5 from ._version import __version__

~\anaconda3\envs\gempy\lib\site-packages\shiboken2\files.dir\shibokensupport\__feature__.py in _import(name, *args, **kwargs)
   140         flag = -1
   141     pyside_feature_dict[importing_module] = flag
--> 142     return original_import(name, *args, **kwargs)
   143 
   144 _is_initialized = False

~\anaconda3\envs\gempy\lib\site-packages\subsurface\reader\__init__.py in <module>
     3 from .profiles import *
     4 
----> 5 from .topography.topo_core import read_structured_topography, read_unstructured_topography
     6 
     7 from .readers_data import ReaderFilesHelper, ReaderWellsHelper, RawDataOptions

~\anaconda3\envs\gempy\lib\site-packages\shiboken2\files.dir\shibokensupport\__feature__.py in _import(name, *args, **kwargs)
   140         flag = -1
   141     pyside_feature_dict[importing_module] = flag
--> 142     return original_import(name, *args, **kwargs)
   143 
   144 _is_initialized = False

~\anaconda3\envs\gempy\lib\site-packages\subsurface\reader\topography\topo_core.py in <module>
     1 import numpy as np
     2 
----> 3 from subsurface.reader.readers_data import ReaderFilesHelper, ReaderUnstructuredHelper
     4 from subsurface.structs import StructuredData, UnstructuredData
     5 from subsurface.reader.mesh.surfaces_api import read_2d_mesh_to_unstruct

~\anaconda3\envs\gempy\lib\site-packages\shiboken2\files.dir\shibokensupport\__feature__.py in _import(name, *args, **kwargs)
   140         flag = -1
   141     pyside_feature_dict[importing_module] = flag
--> 142     return original_import(name, *args, **kwargs)
   143 
   144 _is_initialized = False

~\anaconda3\envs\gempy\lib\site-packages\subsurface\reader\readers_data.py in <module>
     2 import io
     3 from dataclasses import dataclass, field
----> 4 from typing import Union, Literal, Dict, Optional, List, Callable, Any
     5 
     6 import numpy as np

ImportError: cannot import name 'Literal' from 'typing' (C:\Users\leomi\anaconda3\envs\gempy\lib\typing.py)

I assume the error is because typing.Literal is only available from Python 3.8 and up. However, the setup.py file in the subsurface repo states that it should work on Python 3.7.

Any ideas?

I try this Tutorials,and the result is like this.

need help,plz.

We need to define structured elements in the same way we did with unstructured. This is, going from the xarray based object: StructuredData to vtk/pyvista objects

Compilation of formats the library should be able to export import:

• Geosoft .grd
  • Import
  • Export

I am using welly and striplog to load and export an UnstructuredData object. By now I understand how to use the libraries, now I just need to create the right API

I just moved gio to this organization. The projects have overlapping goals; gio was/is only for surfaces, while subsurface is maybe also for 1d and 3d+ datasets.

Maybe subsurface should depend on gio (and also on lasio, segyio, and other 'basic' data loaders).

In order to make any to_subsurface() or from_subsurface() function to work seamlessly on every library that wants to implement them, we would need to determine a standard reference system on subsurface.
This way, if a given library A converts their data structures to a subsurface object, another library B can open it without having to worry about how A defines their coordinates.

After a brainstorming with @Leguark , we ended up in some conclusions:

• subsurface should use a right-handed coordinate system with z axis point upwards and x and y axis as horizontal ones.
• There will be no assumption on the direction of x and y coordinates: they can either be pointing towards east and north, respectively, or towards southwest and southeast, respectively.
• Each library should manage their own coordinate conversions on their to_subsurface() and from_subsurface() functions.

These choices are based on the default reference system in PyVista, which sounds very rational.
This means that we would keep a fairly easy way to plot subsurface objects in PyVista.

What do you think?

After the discussion on #12 and the new proposed base_structures (see sdd.md for more info), only the elements center (cells in vtk lingo) have assigned attributes.

We need to decide if point data is a fundamental field or if it should be added at the elements level (Polydata in vtk lingo)

What's the goal of this project?

• cpg -> https://github.com/GeospatialPython/pyshp
• dbf -> https://dbfread.readthedocs.io/en/latest/
• prj -> ?
• qpj
• shp -> https://github.com/GeospatialPython/pyshp
• shx
• ers https://gdal.org/drivers/raster/ers.html

Reading the segy files in subsurface/test/data/segy

Useful libraries:
https://github.com/equinor/segyio

https://segysak.readthedocs.io/en/latest/_examples/notebooks/QuickOverview.html

Using Utha forge data (@banesullivan should we share the link here?) being able to link the following libraries

Loaders

• Loading boreholes
  • lasio
  • welly
  • Striplog
  • wellpathpy?
• Loading seismic
  • segyio
  • segysak
• Grids
  • Discretize
  • Verde?
• Loading Topography
  • map2loop
  • gemgis

↓

subsurface --> Storage --> Visualization pyvista

↓

Modelers

• GemPy
• Simpeg
• pygimli
• geostatspy

Context

Within the current proposed data levels, there are:

• element - basic geometrical objects that all software integrating with subsurface should implement
• geological_object - elements that represent a some geological concept, e.g. fault

This distinction is great, since it means if one software exports a fault, another software that knows nothing about "faults" can still import and use it as a surface element.

Problem

What about a geological_object that requires multiple elements to represent, say, a fault zone with multiple faults or a geological model with a surface for each formation? In these cases, each component of the object is still an element, but really these elements must be taken together to have meaning.

Currently, when importing a geological model into software that knows nothing about "geological models" the best we can do is import it as a bunch of separate, unrelated surface elements... And even that is dicey because there is no standard way to locate the elements within the unknown geological_object.

Solution 1: Be strict!

One option is we just require geological_objects to be elements; faults or geological_formations are ok, but fault_zones or geological_models are not. Then, we leave it up to the client to sort and associate these element with whatever arbitrary metadata makes sense on a case-by-case basis.

Solution 2: Composite data type

Another option is introduce an additional data type that is a composite of elements. The composite would have no geological meaning; it is just a way to bucket multiple elements together. Just like elements, though, composites are fundamental and must be supported on software import.

Looking back at the geological model problem - the software that doesn't know about "geological models" now is able to interpret it as a composite. It knows where to find the child elements (say, under an elements key...?), and after import the different surface elements are still grouped together.

(This idea comes from OMF - it made the format much more flexible to support complex data types without introducing additional primitives: https://github.com/gmggroup/omf/blob/dev/omf/composite.py )

• dxf: https://ezdxf.mozman.at/docs/tutorials/index.html

The Python files here have a mix of tabs and spaces for the indentation. Everyone should switch their IDE to prefer spaces per PEP8: https://www.python.org/dev/peps/pep-0008/#tabs-or-spaces

I'll be making the switch in #12 but raised this issue to remind those who are still using tabs to switch

I am setting up a conda environment and then using the requirements.txt to setup dependencies but the command fails due to the dependency python==3.7 dep. I don't usually list python as a dep. should we remove that?

After #42 is closed, we should write a documentation page stating the standard coordinate system that will be used in subsurface.
Adding formal explanations and examples would be awesome.