pmgbergen / porepy

Python Simulation Tool for Fractured and Deformable Porous Media

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Unify mixed-dimensional grid generation

jhabriel opened this issue · comments

Ideas on how to unify mesh generation

Our idea to unify the mixed-dimensional grid generation is the following one: Create a new module mesh_generation.py that will contain a worker method with signature:

def create_mixed_dimensional_grid(
    fracture_network: Union[FractureNetwork2d, FractureNetwork3d],
    grid_type: Literal["simplex", "cartesian", "tensor_grid"],
    mesh_arguments: dict[str],
    **kwargs,
) -> pp.MixedDimensionalGrid:
    ...

Inside the method, there will be a heavy deal of translation between what is being passed as arguments and the current way of generating mixed-dimensional grids for the case of simplices and quads.

Most of the effort will indeed go the translation process, sanity checks, and documentation of the method.

What's required from the user side.

To generate a mixed-dimensional grid from scratch, the user will simply need to call two methods, namely

fracture_network = pp.create_fracture_network(list_of_fractures, domain, dimension)
mdg = pp.create_mixed_dimensional_grid(fracture_network, grid_type, mesh_arguments)

Note that the first function will be provided by #780

@keileg Can you weigh in on these ideas?

General approach looks good to me.

  1. I think domain can be inferred from fractures and domain, which cannot both be empty.
  2. Why not single call:
    mdg, fracture_network = pp.create_mixed_dimensional_grid(fracture_list, domain, grid_type, mesh_arguments)
  3. I would appreciate if the passed mesh_arguments to be invariant w.r.t. the other arguments.

Thanks for the feedback @IvarStefansson.

  1. Yes, we will considered this option first. This should be doable, unless, for some reason, the dimension is required explicitly to create a fracture network.

  2. This is indeed doable, although I have no strong preferences, I'm slightly inclined towards keeping them as two separate functions. This, mainly to the number of **kwargs we're dealing with. Eirik, what's your preference?

  3. Yes, that's the idea.

This makes sense to me.

@jhabriel all your suggestions are good to me. Thank you!

Regarding your point 2 @IvarStefansson, both functions act as data generators for two different objects, so I prefer two callings instead one.