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

Check tangential tolerances in PenetrationThread #29802

Open
wants to merge 1 commit into
base: next
Choose a base branch
from

Conversation

maxnezdyur
Copy link
Contributor

closes #29777

@maxnezdyur maxnezdyur changed the title fix tang check (#29777) Check tangential tolerances in PenetrationThread Feb 3, 2025
@maxnezdyur
Copy link
Contributor Author

This fixes a corner case. In which we have 3 penetration infos, all 3 of them are invalid but because the first 2 cause "NEITHER_WINS` causes the third option to win by default without checking if it is a valid info.

@maxnezdyur maxnezdyur marked this pull request as ready for review February 3, 2025 21:51
@maxnezdyur maxnezdyur requested a review from lindsayad as a code owner February 3, 2025 21:51
input = 'close_tet.i'
exodiff = 'close_tet_out.e'
recover = false # steady solve
requirement = "The system will shall be able to ensure contact points are within tangential tolerances."
Copy link
Contributor

Choose a reason for hiding this comment

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

Suggested change
requirement = "The system will shall be able to ensure contact points are within tangential tolerances."
requirement = "The system shall be able to ensure contact points are within tangential tolerances."

Copy link
Contributor

Choose a reason for hiding this comment

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

Actually, shouldn't it say "The system shall ensure contact points..."? We've been trying to avoid saying "be able to".

@GiudGiud
Copy link
Contributor

GiudGiud commented Feb 4, 2025

but because the first 2 cause "NEITHER_WINS` causes the third option to win by default without checking if it is a valid info

I see the logic below for the comparisons between two and I m not sure this is the right fix. Seems like we are now discarding non-winning solutions earlier?

@GiudGiud
Copy link
Contributor

GiudGiud commented Feb 4, 2025

looks like you wrote that part of the contact decision making logic @bwspenc

@moosebuild
Copy link
Contributor

Job Documentation, step Docs: sync website on d572a3b wanted to post the following:

View the site here

This comment will be updated on new commits.

@moosebuild
Copy link
Contributor

Job Coverage, step Generate coverage on d572a3b wanted to post the following:

Framework coverage

4965c6 #29802 d572a3
Total Total +/- New
Rate 85.23% 85.23% +0.00% 100.00%
Hits 108491 108492 +1 3
Misses 18794 18794 - 0

Diff coverage report

Full coverage report

Modules coverage

Coverage did not change

Full coverage reports

Reports

This comment will be updated on new commits.

@maxnezdyur
Copy link
Contributor Author

I see the logic below for the comparisons between two and I m not sure this is the right fix. Seems like we are now discarding non-winning solutions earlier?

With the fix we are discarding non-valid solutions at the last possible moment. When switch_info is called, that is when a solution is completely accepted. We have this tangential check in other parts of the code, but there was a corner case where it doesn't get found.

@maxnezdyur maxnezdyur requested a review from bwspenc February 4, 2025 15:24
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.

Spurious Contact/ Incorrect Penetration detection
4 participants