GEOS-DEV / GEOS

GEOS Simulation Framework
GNU Lesser General Public License v2.1
222 stars 89 forks source link

Handle input data from a complex source #2953

Open untereiner opened 9 months ago

untereiner commented 9 months ago

Describe the issue For now, one input mesh is read from from one vtu file. Their are also surfaces embedded in this vtu file using the potpourri ability of this file format.

I am considering more complex files format where data is (or can be) organized semantically. There is of course RESQML but we can also consider VTK composite meshes such as vtkPartitionedDataSetCollection

It is not fairly possible to add a new node in Problem. It would require a new manager and to find a place in the order of the managers.

Proposed cleanup I suggest for now to add a new abstract level above MeshGeneratorBase that would allow a new subtree of classes to handle such cases I am already using it with the branch feature/untereiner/wip. I will propose a cleaned version

Additional context Add any other context about the problem here.

TotoGaz commented 9 months ago

I do not understand what mesh feature is missing ? BTW, fractures are defined in their own separate vtu file, all the vtu files being combined into a vtm file. The same is meant to be done for embedded surfaces.

untereiner commented 9 months ago

I should have missed something because on my side I have a vtu file with an UnstructuredGrid and surfaces inside. No feature is missing for using meshes stored in vtu files. The refactor allows to use other formats where the API of MeshGenerationBase doesn't fit