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

Fix MOAB canonical ordering during element splitting #167

Merged
merged 6 commits into from
Oct 21, 2024

Conversation

connoramoreno
Copy link
Collaborator

Corrects implementation of MOAB canonical ordering. Changes are as follows:

  • Changes MOAB canonical ordering for both wedges and hexahedra to coincide with element splitting shown in ParaStell publication (Moreno, Bader, Wilson, 2024)
  • Adds documentation explaining MOAB canonical ordering for posterity

Closes #166

@gonuke
Copy link
Member

gonuke commented Oct 10, 2024

Should we have a test for this somehow?

@connoramoreno
Copy link
Collaborator Author

connoramoreno commented Oct 10, 2024

I'm not sure how we'd test canonical ordering of tetrahedra/splitting of elements directly but one test that we should probably add is to ensure no elements with negative volume are present

Copy link
Member

@gonuke gonuke left a comment

Choose a reason for hiding this comment

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

A quick question before we move forward....

source_mesh.create_mesh()

assert len(source_mesh.volumes) == num_elements_exp
assert len([i for i in source_mesh.volumes if i < 0]) == num_neg_vols_exp
Copy link
Member

Choose a reason for hiding this comment

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

Nice - does this fail with the old/wrong canonical ordering?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

With the old canonical ordering, this doesn't fail on the test equilibrium, but it does fail with WISTELL-D. On WISTELL-D using these parameters, the number of elements is as expected but 108 elements (1.47%) have negative volume.

Copy link
Member

@gonuke gonuke left a comment

Choose a reason for hiding this comment

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

@gonuke gonuke merged commit e330994 into main Oct 21, 2024
3 checks passed
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.

Negative volumes in source meshes
2 participants