Closed banesullivan closed 2 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.
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.
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.
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
orGemPy
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?