Add a GridWrapper for managing grid data (#97) · Issues · dorie / dorie

Add a GridWrapper for managing grid data

This issue is directly linked to the new parameter input scheme outlined in #86 (closed) and implemented in !82 (merged). I open the separate issue to discuss this feature with regard to #94 (closed).

Description

The new parameter input scheme has the purpose of making the soil layer specification more flexible, while ensuring that parameter data coincides with grid data. Following the approach of DUNE, we can use arrays and maps to associate data with the respective grid entity indices and/or IDs (see the docs of `Dune::IndexSet).

This means that the task of building a grid also encompasses reading additional data. To that end, the Simulation has to build the grid itself. This could complicate building a structure like the CoupledSimulation proposed in #94 (closed).

Proposal

Remove the argument grid from the constructor of RichardsSimulation.
Add a GridWrapper to RichardsSimulation. The wrapper distinguishes two cases:
1. Rectangular grids:
  
  The wrapper creates a grid using the Dune::GridFactory. It then reads an HDF5 file containing a mapping from cell to medium layer index. It then load-balances the data and the grid.
2. Unstructured grids:
  
  The wrapper calls the Dune::GmshReader to create a grid and read the medium layer information directly from the mesh file. It then load-balances the data and the grid.
The grid might have to be load-balanced again during a run, and therefore, the data has to be load-balanced. This could be a task of the GridWrapper, or a GridMapper structure attached to it.
Share the GridWrapper between different simulations, not only the grid.

How to test the implementation?

Reading data correctly will be part of the tests implemented in !82 (merged).

Related issues

#63 (closed): Meta issue on parameterization
#86 (closed): New parameterization input scheme

This issue is directly linked to the new parameter input scheme outlined in #86 and implemented in !82. I open the separate issue to discuss this feature with regard to #94.

### Description
The new parameter input scheme has the purpose of making the soil layer specification more flexible, while ensuring that parameter data coincides with grid data. Following the approach of DUNE, we can use arrays and maps to associate data with the respective grid entity indices and/or IDs (see [the docs of `Dune::IndexSet](https://www.dune-project.org/doxygen/2.6.0/classDune_1_1IndexSet.html#details)).

This means that the task of building a grid also encompasses reading additional data. To that end, the `Simulation` has to build the grid itself. This could complicate building a structure like the `CoupledSimulation` proposed in #94.

### Proposal
* Remove the argument `grid` from the constructor of `RichardsSimulation`.

* Add a `GridWrapper` to `RichardsSimulation`. The wrapper distinguishes two cases:
   1. Rectangular grids:

The wrapper creates a grid using the `Dune::GridFactory`. It then reads an HDF5 file containing a mapping from cell to medium layer index. It then load-balances the data and the grid.

2. Unstructured grids:

The wrapper calls the `Dune::GmshReader` to create a grid and read the medium layer information directly from the mesh file. It then load-balances the data and the grid.

The grid might have to be load-balanced again during a run, and therefore, the data has to be load-balanced. This could be a task of the `GridWrapper`, or a `GridMapper` structure attached to it.

* Share the `GridWrapper` between different simulations, not only the grid.

### How to test the implementation?
Reading data correctly will be part of the tests implemented in !82.

### Related issues
* #63: Meta issue on parameterization
* #86: New parameterization input scheme

To upload designs, you'll need to enable LFS and have admin enable hashed storage. More information