-
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
Add a line search in newton solve to find contact point #28149
Conversation
Dont die horribly when it fails refs idaholab#28148
Handle problematic case
Job Documentation on 722f6fd wanted to post the following: View the site here This comment will be updated on new commits. |
Job Coverage on 5304267 wanted to post the following: Framework coverage
Modules coverageCoverage did not change Full coverage reportsReports
Warnings
This comment will be updated on new commits. |
so I looked at this more after talking with @bwspenc we already check that we find a face for every secondary node, so these changes are just weeding out bad faces (previously accepted by not checking the newton tolerance...) Thoughts on the way forward here? I have a 600kb mesh from discussion we could use for a test case. I could probably get it down to 300kb |
why is the checking on not having leftover unmatched secondary nodes only done on Jacobian computation?
|
Small optimizations in search solves Dont include verbose output for failed searches, we do not need all contact point searches to pass, only one and only the best one
ok now there's real failures from rejecting nodes |
the warning was added in #9832 |
@sveerara why only on Jacobian? |
Ok forgot to commit some code |
Add variables to avoid being inconsistent in all the heuristics
mesh is reduced to only the problematic area
better while loop format Co-authored-by: Alex Lindsay <alexander.lindsay@inl.gov>
Failures unrelated |
{ | ||
thisElemInfo.push_back(pen_info); | ||
p_info.push_back(pen_info); | ||
} |
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.
else
break_valgrind_tests_with(MEMORY_LEAK);
I'll put up a fix shortly.
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.
thanks
Hopefully this fixes our new valgrind errors in next, in a bug apparently introduced by idaholab#28149. Refs idaholab#28148 This code really needs an overhaul to get rid of new/delete everywhere, but I'm trying to make a minimal fix here to get next working ASAP.
Hopefully this fixes our new valgrind errors in next, in a bug apparently introduced by idaholab#28149. Refs idaholab#28148 This code really needs an overhaul to get rid of new/delete everywhere, but I'm trying to make a minimal fix here to get next working ASAP.
Hopefully this fixes our new valgrind errors in next, in a bug apparently introduced by idaholab#28149. Refs idaholab#28148 This code really needs an overhaul to get rid of new/delete everywhere, but I'm trying to make a minimal fix here to get next working ASAP.
Hopefully this fixes our new valgrind errors in next, in a bug apparently introduced by idaholab#28149. Refs idaholab#28148 This code really needs an overhaul to get rid of new/delete everywhere, but I'm trying to make a minimal fix here to get next working ASAP.
Hopefully this fixes our new valgrind errors in next, in a bug apparently introduced by idaholab#28149. Refs idaholab#28148 This code really needs an overhaul to get rid of new/delete everywhere, but I'm trying to make a minimal fix here to get next working ASAP.
Dont die horribly when it fails
refs #28148
See #28091 and #27934
Note that the line search does not save this input. We still dont converge to the right contact point, and get a warning along with debugging information from libmesh.