Skip to content

Uniform refinement of mixed topology meshes #3756

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

Open
wants to merge 31 commits into
base: main
Choose a base branch
from

Conversation

chrisrichardson
Copy link
Contributor

Allows mixed topology meshes, e.g. triangle+quad, or hex+pyramid+prism+tet to be refined globally.

This also works for pure or quad hex meshes, for example.

@chrisrichardson chrisrichardson requested a review from jorgensd June 20, 2025 06:40
Copy link
Member

@jorgensd jorgensd left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not quite done reviewing, but here are my initial comments.

@chrisrichardson chrisrichardson marked this pull request as ready for review June 23, 2025 09:53
Copy link
Contributor

@schnellerhase schnellerhase left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should maybe the entry point for uniform_refine and the already present refine share a common API? refine already supports uniform refinements by marking of all edges, and in the future the refinement routines implemented here could be extended to non uniform cases.

Also the partitioner creation, especially for refinement aware identity_partitioner to come #3661, should be available for the uniform refinement. This would be easiest to accomplish if the entry point is a shared one.

@chrisrichardson
Copy link
Contributor Author

chrisrichardson commented Jun 23, 2025

About unifying the interface:
Yes, in principle, we can do that. At the moment, I see this as slightly "experimental", and there are a couple of rough edges to clean up. I think making a common entry point should come last.

For some near future PRs, we can look at:

  • using the coordinate map to compute the "midpoints" of edges, etc. for higher-order input. We can't create higher-order output meshes easily, since that requires initialising edges on the new mesh.
  • In the Python layer, setting the ufl_domain to something other than None
  • Creating a Python wrapper outside of dolfinx.cpp
  • Supply a custom partitioner

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

Successfully merging this pull request may close these issues.

3 participants