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

Add a line search in newton solve to find contact point #28149

Merged
merged 6 commits into from
Jul 18, 2024

Conversation

GiudGiud
Copy link
Contributor

@GiudGiud GiudGiud commented Jul 16, 2024

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.

@GiudGiud GiudGiud self-assigned this Jul 16, 2024
@moosebuild
Copy link
Contributor

moosebuild commented Jul 16, 2024

Job Documentation on 722f6fd wanted to post the following:

View the site here

This comment will be updated on new commits.

@moosebuild
Copy link
Contributor

moosebuild commented Jul 16, 2024

Job Coverage on 5304267 wanted to post the following:

Framework coverage

182f6e #28149 530426
Total Total +/- New
Rate 85.07% 85.06% -0.00% 82.93%
Hits 104585 104607 +22 34
Misses 18360 18367 +7 7

Diff coverage report

Full coverage report

Modules coverage

Coverage did not change

Full coverage reports

Reports

Warnings

  • framework new line coverage rate 82.93% is less than the suggested 90.0%

This comment will be updated on new commits.

@GiudGiud
Copy link
Contributor Author

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

@GiudGiud GiudGiud marked this pull request as ready for review July 17, 2024 05:14
@GiudGiud GiudGiud requested a review from lindsayad as a code owner July 17, 2024 05:14
@GiudGiud
Copy link
Contributor Author

why is the checking on not having leftover unmatched secondary nodes only done on Jacobian computation?

  if (recheck_secondary_nodes.size() > 0 && _patch_update_strategy != Moose::Iteration &&
      _subproblem.currentlyComputingJacobian())
    mooseDoOnce(mooseWarning("Warning in PenetrationLocator. Penetration is not "

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
@GiudGiud
Copy link
Contributor Author

ok now there's real failures from rejecting nodes

@lindsayad
Copy link
Member

lindsayad commented Jul 17, 2024

the warning was added in #9832

@GiudGiud
Copy link
Contributor Author

@sveerara why only on Jacobian?

@GiudGiud
Copy link
Contributor Author

Ok forgot to commit some code
My bad

Add variables to avoid being inconsistent in all the heuristics
@GiudGiud GiudGiud closed this Jul 18, 2024
@GiudGiud GiudGiud reopened this Jul 18, 2024
mesh is reduced to only the problematic area
better while loop format

Co-authored-by: Alex Lindsay <alexander.lindsay@inl.gov>
@GiudGiud
Copy link
Contributor Author

Failures unrelated

@GiudGiud GiudGiud merged commit 2812e4a into idaholab:next Jul 18, 2024
46 of 49 checks passed
@GiudGiud GiudGiud deleted the PR_contact branch July 18, 2024 23:34
{
thisElemInfo.push_back(pen_info);
p_info.push_back(pen_info);
}
Copy link
Contributor

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

thanks

roystgnr added a commit to roystgnr/moose that referenced this pull request Jul 19, 2024
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.
N4hom pushed a commit to N4hom/moose that referenced this pull request Jul 30, 2024
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.
TheGreatCid pushed a commit to TheGreatCid/moose that referenced this pull request Aug 1, 2024
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.
TheGreatCid pushed a commit to TheGreatCid/moose that referenced this pull request Aug 14, 2024
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.
Leni-Yeo pushed a commit to Leni-Yeo/moose that referenced this pull request Aug 28, 2024
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.
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.

4 participants