[EPIC] Import of external faults and fractures

[CusiniM]

Description

The goal of this issue is to track progress on import of external faults and fractures through VTK, both for conforming and embedded discretization approaches.

Work Scope

• import of conforming features (faults and fractures) through vtk
• import of embedded fracture networks through vtk

side objectives, since we will focus on the input file format, will include gaining insights in

• possible ways to import wells through vtk (format may be similar to the one used for embedded fracture networks)
• use of the outputs of GEOS as input for other simulations These points are out of the scope of this issue but closely related.

Issues in this EPIC

• [x] https://github.com/GEOS-DEV/GEOS/issues/2308
• [x] https://github.com/GEOS-DEV/GEOS/issues/2413
• [ ] https://github.com/GEOS-DEV/GEOS/issues/2681
• [ ] https://github.com/GEOS-DEV/GEOS/issues/2376

[untereiner]

I am looking on a way to reuse the output of GEOS as an input. I stumbled on this article talking about deprecation of multiblocks. I think Faults and Fractures would benefit from the vtkPartitionedDataSetCollection object. The fractures could be organized with a vtkDataAssembly (organized also with the CellElementRegions). What do you think ?

This collection of "meshes + values" could be seen as a data (data considered as meshes + values) repository where GEOS' components could find their inputs (domain discretization, faults/fracture network surfaces, wells grahs, etc). It reminds me the work on RESQML. I started something here: feature/untereiner/VTKCompositeMesh

[TotoGaz]

Hello @untereiner

We had a talk with kitware and vtkMultiBlockDataSet is not deprecated. We also reached the conclusion that it was better for us to consistently use vtkMultiBlockDataSet in geos and maybe migrate if we need all at once.

In the way to reusing the outputs, one question was about the nodes. We currently write each region in its own block; so nodes used for the definitions of multiple regions will be defined in multiple blocks. IIRC our discussion with kitware, that would force us to manage the "merge". Nothing that can't be done, but still to be done.

Eventually, it's OK to support vtkPartitionedDataSet* utilities if this brings us some new cool features 😉

[untereiner]

Yes, well, it is too much used to deprecate it... but a replacement is already there...

For what I heard, some users would find reusing outputs as a new cool feature :smiley: As a first step I will look at how to import the good soldier vtkMultiBlockDataSet.

I think that vtkPartitionedDataSetCollection in conjunction with vtkDataSetAssembly could bring a more reliable way of specifying relationships, especially with faults, fractures and wells