-
Notifications
You must be signed in to change notification settings - Fork 298
Added sliding boundary nodes to VariationalMeshSmoother #4216
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
Added sliding boundary nodes to VariationalMeshSmoother #4216
Conversation
… 3D, not sliding edge nodes.
…re considered for sliding boundary constraints. This helps with adjacent corners nodes in triangular elements.
…ain tests to account for barely-moved subdomain boundary nodes that coincide with the mesh boundary.
… sides are sometimes not found.
…ks better, but both constaints should be conmbined for strict enforcement.
Implemented structs to represent Point, Line, and Plane constraints and logic to combine (intersect) them. This is more robust than the previous version and gives the correct constraints for nodes that are both subdomain boundary nodes and external boundary nodes. Ref libMesh#4082
Replaced DistortSquare class with the DistortHypercube class, which generalizes dimension and distorts boundary nodes within boundaries instead of leaving them unchanged. The helper also checks all applicable node dimensions instead of receiving the dimension to check as a parameter. Renamed the `center_distortion_is` helper function to `distortion_is` and updated to check sliding boundary nodes for distortion.
Instead of looking for the boundary between sub_id2 and sub_id2, we now look for the boundary between sub_id1 and "not sub_id1". This better handles cases where multiple faces of an element have neighbors of multiple different subdomain ids.
…LaplaceSmoother functions.
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.
There's surprisingly little for me to complain about, for such a large PR.
Job Coverage, step Generate coverage on f8c37d4 wanted to post the following: Coverage
Warnings
This comment will be updated on new commits. |
From Slack, for public reference: "Okay, just pushed the polymorphic approach. Let me know which one you prefer and we'll stick with that." "I think I like the std::variant version better. Sorry to make you go to so much work! I'd be okay with either version." "Yes, the polymorphic feels a bit more cluttered, doesn’t it? No worries, I was interested in how it would turn out" I think my only remaining real complaint is that, even if we end up relying on exceptions here, at a minimum we need to disable the tests relying on them until the --disable-exceptions CI passes. |
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.
I'm thrilled with this now except for a couple of the whitespace changes; @pbehne is going to rewrite history now, and has sworn he won't edit anything else but whitespace in the process.
d2b4489
to
57c7c4e
Compare
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.
Looks good to me although I can't really comment on the technical details. I think some of the new std::variant
and std::visit
C++17 code could potentially be commented more. I know that it's possible to look up how these things work, but (to my knowledge) we don't use this anywhere else in the library so it would be handy to have a nearby comment explaining how these "modern" C++ concepts help to implement the overall design.
Job Min gcc on f8c37d4 : invalidated by @jwpeterson Retry to see if "failed to get checksum" error is resolved automatically |
FYI @pbehne this PR seems to have broken the
so the fix should be simple, just use the non-deprecated |
Thanks for the heads up, I'll add the fix to #4218! |
FYI, only the deprecated version shows up in doxygen. I had to go look at |
OK, that's interesting... I guess Doxygen is somehow seeing the "pre-processed" version of the source (and the defines are somehow set such that it doesn't generate docs for the non-deprecated version)? Maybe that's a normal Doxygen thing, I don't know. |
Yeah, I figured I'd mention it since I recall @roystgnr mentioning that he and you typically just use the header files themselves for documentation. As someone less familiar with the library, I prefer doxygen so I don't have to dig through parent headers to see what a given class does and doesn't inherit. |
I think the problem is that we only update the libMesh Doxygen manuallly, by which I mean "almost never", by which I mean "Oh my God the files still have copyright 2002-2018 headers". The libMesh Doxygen on the MOOSE site gets autoupdated, which I guess I thought was good enough ... but it doesn't matter if the MOOSE copy marks something as deprecated if that's not the copy everybody is reading. |
Pull Request: Sliding Boundary Constraint Refinement and Dimensional Generalization
Summary
This pull request implements sliding external and subdomain boundary node constraints in the
VariationalMeshSmoother
In addition to expanding test coverage to test sliding boundary nodes, 1D and 3D test cases were added to the unit test suite.
Highlights
Constraint Framework Refactor
PointConstraint
,LineConstraint
, andPlaneConstraint
classes to represent fixed nodes, nodes constrained to a line, and nodes constrained to a planeintersect()
interface for combining constraints usingstd::variant
PointConstraint
if constraints fail to intersect cleanlySliding Boundary Enhancements
Expanded Tests and Validation
DistortSquare
withDistortHypercube
, supporting 1D, 2D, and 3D skewingReferences
Visualization of
testVariationalHexMultipleSubdomains
TestThe distorted mesh is on the left, smoothed mesh is on the right.
