fatiando / rockhound

NOTICE: This library is no longer being developed. Use Ensaio instead (https://www.fatiando.org/ensaio). -- Download geophysical models/datasets and load them in Python
BSD 3-Clause "New" or "Revised" License
34 stars 15 forks source link

Support for common libraries' types #51

Closed banesullivan closed 2 years ago

banesullivan commented 5 years ago

Description of the desired feature

With more 3D datasets to come like #50, it might be useful to have utilities in here that would make discretize, PyVista, PyGIMLi or GemPy meshes/types of these datasets.

While xarray is awesome, most users will want a type that they are familiar with and having a clear way to use these datasets with common libraries like those mentioned would help gain users (and developers).

Are you willing to help implement and maintain this feature? Yes/No

Definitely! But I'll need guidance on what these methods should be called and where/how they should be implemented.

Perhaps some sort of to_pyvista(), to_discretize(), etc. methods that will only execute if the needed library is available - thus keeping `rockhounds dependencies to a minimum?

leouieda commented 5 years ago

Hi Bane, glad to have you on board! This is a good point. Thank you for bringing it up!

I'm a bit hesitant to add this to RockHound. xarray has quickly become the defacto standard for regular grids across scientific Python. I do think that the code you mention should exist (converting xarray to discretize, etc) but I wonder if it wouldn't be better for the individual projects to have such functionality?

The problem with putting it here is that we would have to keep up with changes to these projects' formats, putting a large burden on us (who might not use some of these libraries).

I also think that having these models/datasets easily available in a standard format might encourage other projects to slowly adopt some standard (which ever that is).

What do you think?

In the end, the amount of work would be the same but the home for these functions would be different.

banesullivan commented 5 years ago

I do think that the code you mention should exist (converting xarray to discretize, etc) but I wonder if it wouldn't be better for the individual projects to have such functionality?

This makes a lot of sense - for some reason I was thinking xarray was 2D only as that's how I've always used it but I'm seeing now that it can be 3D.

My hesitation and reason for posting here is that it might be difficult to have a standard from_rockhound or from_xarray method in external projects because of the differences between individual datasets. For example, the SEG data and models from #50 include triangulated surfaces (can these be represented in xarray?) and regularly gridded volumes - which, to me, look quite different from the examples currently in rockhound.

It almost seems like those packages (discretize/ PyVista / etc.) would have to implement a routine for each dataset and not be able to support all example datasets here.

I think I might need to see how the various data types in #50 are structured in rockhound after implementation before I'll see a clear way to build a link between all these different datasets and external projects that have types with which users might be more comfortable.

leouieda commented 5 years ago

My hesitation and reason for posting here is that it might be difficult to have a standard from_rockhound or from_xarray method in external projects because of the differences between individual datasets.

You're right about that. There is no way we can have all of this be completely generic right now. For regular meshes, the xarray structure we would create here is going to be pretty standard. So I don't see much trouble in converting generic 3D xarray DataArrays to discretize et al.

The triangulated surfaces are more challenging. xarray doesn't handle those and that's where there currently isn't any strong contender. But maybe pyvista could be the one.

In summary, I would rather adopt a standard and have other libraries import from a standard into their own specific formats. Otherwise, we're going to quickly get out of sync and have a terrible time testing everything.

I think I might need to see how the various data types in #50 are structured in rockhound after implementation before I'll see a clear way to build a link between all these different datasets and external projects that have types with which users might be more comfortable.

I agree. We should try to do just the regular mesh part first and leave the triangulated surfaces for a follow up. That way we can experiment.