-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
Set verify_holes to false in RGMB FlexiblePatternGenerator mesh subgenerator calls #28317
Conversation
Keeping an eye on it: https://civet.inl.gov/job/2370876/ |
I assume the problem here is downstream of our failure to fix libMesh/libmesh#3497 ? But I'd love to be reassured that that's more than an assumption, that the It's probably a good idea to turn off this check either way, since it is going to give us false positives until we can fix it, but if we let a bad test case slip through then we'll find ourselves stuck getting true positives after we fix it. |
Job Documentation on e80e72d wanted to post the following: View the site here This comment will be updated on new commits. |
@roystgnr yes these changes are needed to get the Conda Intel Mac tests pass, which was triggered when adding the feature in this PR - #28231. Basically the idea here is to delete the outermost layer created by the RGMB mesh generators and triangulate this layer instead, which will facilitate stitching of assembly mesh structures without having any hanging nodes. Since we're just triangulating a layer that was previously deleted through the mesh subgenerators, we can be sure that the hole (layers not deleted in assembly) is contained within the outer boundary (outermost assembly boundary). These checks happen through the mesh subgenerators that are called before this deletion and triangulation step. |
@milljm looks like the devel tests that were previously failing now pass |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
the holes are placed programmatically, and the flexible pattern sub-generator already checks that they dont overlap iirc
this should be safe to do for now though we can re-enable it if we find that users have a way to make the hole placement invalid
Reason
Design
Impact
refs #28316