pmgbergen / porepy

Python Simulation Tool for Fractured and Deformable Porous Media
GNU General Public License v3.0
248 stars 88 forks source link

Addressing separate uni-dimensional components of general mixed-dimensional objects #603

Open jwboth opened 2 years ago

jwboth commented 2 years ago

Mixed-dimensional primary variables can be broken apart into the uni-dimensional components using the DofManager, as it stores the maps between single grids and DOFs via e.g. grid_and_variable_to_dofs. For general expressions, no similar capability is provided currently.

An typical example for which this could be interesting: One defines the mixed-dimensional Darcy flux using AD expressions. Using the AD functionalities the expression for the flux can also be evaluated for potential post-processing etc. Now it is not possible in a uniform way to address all components associated to a single grid, e.g., all components corresponding to the faces of the grid of highest dimension.

A general method with this functionality seems to be of interest and should be considered in the development.

jwboth commented 2 years ago

MergedOperator essentially knows the block structure of its range from the dimensions of the single matrices which are glued together in the parse routine. When in addition knowing the index of a single grid in a grid_list which is used to set up a discretization object, one also knows which block to address. These two components allow to circumvent the above issue using rather little code as long as no other option exists.

keileg commented 2 years ago

I think what we should do is to implement an under-the-hood sorting of grids and mortar grids when they are passed to Ad operators and discretization. This should make the ordering of grids, and thus of the unknowns of a secondary variable like fluxes, deterministic.

An ordering of the grids is most readily derived from the GridBucket- actually it already exists in the dictionary item node_number. The main obstracle that I see is what to do if the GridBucketis changed, say, if a new grid is added due to fracture propagation. We will need to think of this, but the answer may very well be that in this case, one should make a new GridBucketand carefully transfer information from the old one.

IvarStefansson commented 2 years ago

Regarding your last point on dynamic grid buckets, I think it might be useful to keep in mind the vague idea we have of separating the geometry description from grids, which is probably necessary if we are ever to do any serious propagation.

keileg commented 2 years ago

I completely agree (although it is only indirectly relevant for this issue).