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

Spurious Contact/ Incorrect Penetration detection #29777

Open
maxnezdyur opened this issue Jan 31, 2025 · 2 comments · May be fixed by #29802
Open

Spurious Contact/ Incorrect Penetration detection #29777

maxnezdyur opened this issue Jan 31, 2025 · 2 comments · May be fixed by #29802
Labels
P: normal A defect affecting operation with a low possibility of significantly affects. T: defect An anomaly, which is anything that deviates from expectations.

Comments

@maxnezdyur
Copy link
Contributor

Bug Description

Found example of spurious contact when working on explicit contact. MWE below shows incorrect penetration values.

Steps to Reproduce

[Problem]
  solve = false
[]
[Mesh]
  [block_one]
    type = GeneratedMeshGenerator
    dim = 3
    nx = 3
    ny = 3
    nz = 1
    xmin = 4.5
    xmax = 5.5
    ymin = 4.5
    ymax = 5.5
    zmin = 0.001
    zmax = 1.001
    boundary_name_prefix = 'ball'
    elem_type = TET4
  []
  [block_two]
    type = GeneratedMeshGenerator
    dim = 3
    nx = 10
    ny = 10
    nz = 1
    xmin = 3
    xmax = 7
    ymin = 3
    ymax = 7
    zmin = -2
    zmax = 0
    boundary_name_prefix = 'base'
    boundary_id_offset = 10
    elem_type = TET4
  []
  [block_one_id]
    type = SubdomainIDGenerator
    input = block_one
    subdomain_id = 1
  []
  [block_two_id]
    type = SubdomainIDGenerator
    input = block_two
    subdomain_id = 2
  []
  [combine]
    type = MeshCollectionGenerator
    inputs = ' block_one_id block_two_id'
  []
[]

[AuxVariables]
  [penetration]
    order = FIRST
    family = LAGRANGE
  []
  [closest_point_x]
    order = FIRST
    family = LAGRANGE
  []
  [closest_point_y]
    order = FIRST
    family = LAGRANGE
  []
  [closest_point_z]
    order = FIRST
    family = LAGRANGE
  []
[]

[AuxKernels]
  [penetrate]
    type = PenetrationAux
    variable = penetration
    boundary = base_front
    paired_boundary = ball_back
    quantity = distance
  []

  [penetrate11]
    type = PenetrationAux
    variable = closest_point_x
    boundary = base_front
    paired_boundary = ball_back
    quantity = closest_point_x
  []

  [penetrate13]
    type = PenetrationAux
    variable = closest_point_y
    boundary = base_front
    paired_boundary = ball_back
    quantity = closest_point_y
  []

  [penetrate15]
    type = PenetrationAux
    variable = closest_point_z
    boundary = base_front
    paired_boundary = ball_back
    quantity = closest_point_z
  []
[]

[Executioner]
  type = Steady

  solve_type = 'PJFNK'
[]

[Outputs]
  exodus = true
  execute_on = TIMESTEP_END
[]

Figure below is from running the above file.
Image

MWE came from work with explicit contact. Spurious contact below happened with a penalty node face method.
Image

Impact

Spurious contact prevents users from trusting results.

[Optional] Diagnostics

No response

@maxnezdyur maxnezdyur added P: normal A defect affecting operation with a low possibility of significantly affects. T: defect An anomaly, which is anything that deviates from expectations. labels Jan 31, 2025
@maxnezdyur
Copy link
Contributor Author

@recuero
Do you know if the _closest_point in PenetrationInfo is always supposed to be on the face of the element that the node is using to compute its distance? PenetrationInfo doesn't have a lot of documentation, so having trouble finding what each of the members are supposed to be.

maxnezdyur added a commit to maxnezdyur/moose that referenced this issue Feb 3, 2025
@maxnezdyur maxnezdyur linked a pull request Feb 3, 2025 that will close this issue
maxnezdyur added a commit to maxnezdyur/moose that referenced this issue Feb 3, 2025
@recuero
Copy link
Contributor

recuero commented Feb 4, 2025

It's supposed to as far as I recall. There may be an issue with tets and close projections. I think I ran into something like this years ago.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
P: normal A defect affecting operation with a low possibility of significantly affects. T: defect An anomaly, which is anything that deviates from expectations.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants