Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Make application geometries with non-matching grids #1312

Open
keileg opened this issue Jan 23, 2025 · 6 comments
Open

Make application geometries with non-matching grids #1312

keileg opened this issue Jan 23, 2025 · 6 comments
Assignees

Comments

@keileg
Copy link
Contributor

keileg commented Jan 23, 2025

Currently the available model geometries used for testing (e.g., applications/model_geometries.py) exclusively apply matching geometries. We should make a few cases available.

Suggested approach for the initial steps:

  1. Take as a starting point the mixin SquareDomainOrthogonalFractures (2d geometry, up to fractures), and create a mixin that inherits from this class.
  2. Make simple functionality to convert the grid covering this geometry to a non-matching grid. This will likely involve overriding set_geometry to (after call to super) to modify self.mdg.
  3. We will only refine the fracture and (later) mortar grid; the 2d grid will stay. The level of sophistication in the refinement (and possibly coarsening) will be specified under way. This should also make it work for Cartesian grids.
  4. We need to find a test case to which we want to apply the geometry. To be specified.
  5. A 3d case might be included later. To be decided.

It is an open question how many of the tests, and PorePy functionality in general, will be able to deal with non-matching grids, but that is a secondary concern.

@jhabriel
Copy link
Contributor

Just to give my unsolicited two cents since I'm currently working with non-matching grids:

Another option, instead of focusing on individual geometries (such as SquareDomainOrthogonalFractures) could be to produce non-matching grids starting from matching mdgs via a mixing NonMatchingGridGenerator. This can be catered to several levels of flexibility, but for testing sake, an easy take could be to pass global refinement targets for, say, subdomains of dimension n-1, and interfaces of dimension n-1 and then use replace_subdomains_and_interfces().

@keileg
Copy link
Contributor Author

keileg commented Jan 24, 2025

I agree that your suggestion is more useful in a general setting @jhabriel. If we end up applying non-matching grids more regularly, we will likely do something in the direction you sketch, or better, rely on functionality that you implement.

The goal of this project is however limited to enabling testing on non-matching grids at all, and then (later) to do some diagnostics of which models are ready for non-matching grids. I expect this to be an efficient generator of GH issues.

@keileg
Copy link
Contributor Author

keileg commented Feb 5, 2025

@IngridKJ @zhangyh0713 I took a short peak at the branch you are working on, and want to offload my thoughts here: it seems you are well under way; just be aware that the domain you are working with (SquareDomainOrthogonalFractures) can have 0, 1, or 2 fractures; steered by self.params (see implementation). You should be careful not to replace a fracture which is not present.

When the mixin geometry is in place, I think we will use the new grid in one test, perhaps tests/models/test_fluid_mass_balance.py::test_unit_conversion. If this works, I think we are good, and can make a full PR. If it does not work, we need to look into why, but it could very well be that this is also outside the scope of this issue.

@IngridKJ
Copy link
Contributor

IngridKJ commented Feb 5, 2025

Thank you for the feedback, @keileg! We are aware of the usage of self.params to determine how many fractures the grid should have. But yes, I see now that the code might break down if there are less than 2 fractures present as we hardcode two refinement ratios (ratios = [3, 2]). Is this what you are referring to?

@keileg
Copy link
Contributor Author

keileg commented Feb 5, 2025

Is this what you are referring to?

Partly yes. Also, if you try to replace a fracture grid, but self.params['num_fracs] (or whatever that parameter is called) is set to 0, there will be trouble.

@zhangyh0713
Copy link

Thanks for the feedback @keileg ! We will fix this problem:)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants