Memory usage in Contact modules

[makeclean]

Quick question, Ive got a 'toy' problem which resembles our children's favourite Danish building blocks. There are two blocks next to each other, along the long face as seen below.

In total there are 1583 nodes on each surface (4928 edges and 3346 triangles if that matters - dont think it does) and trying to get this problem setup and running on my desktop, requires more than 128 Gb of memory ?!?! That seems excessive to me, any suggestions here would be appreciated.

[makeclean]

So memory usage is around 18.2 Gb until computing initial stateful property values, and then it rockets up fairly quickly to 128 Gb and then is killed.

[aeslaughter]

What type of properties are you using that are stateful? Saving the state requires that values of the material properties are stored for every quadrature point in your mesh. It is common to have a large memory demand with stateful properties.

[makeclean]

nothing of note which makes it weird

[lindsayad]

With your dock_slippy.i input I am not seeing memory usage above about 300 MB

[lindsayad]

Replying on this thread so I can leave the other one to talk about convergence. Congrats @makeclean you've unearthed two large memory issues. Here is this ticket: #16836

[lindsayad]

Ok after #16845, for your lego input, I go from this graph:

which was taken from the middle of initing stateful props, and shortly before I canceled the simulation so my computer wouldn't run out of memory to this graph:

which was taken after initing stateful properties...because now we can get to that point without running out of memory. So 84 GB for stateful properties (and that number was still growing) to 4GB. I'm a big fan. Thanks for your helpful inputs @makeclean !

[makeclean]

Some progress, it seems the two objects in contact must be separate mesh blocks, is that true MOOSE folks?

[lindsayad]

What contact formulation are you using? With respect to contact vs. dirichlet condition: the dirichlet condition would win because it runs after constraints. A MWE would be great yea, thanks!

[makeclean]

Ok, I can't reproduce the problem with my simple block example, where should I put the mesh from the example above?

[makeclean]

Its regular contact not dirichlet

[lindsayad]

If two surfaces were part of a contact group, and those surfaces also had nodes that were part of a fixed 0 displacement boundary, what would happen?

Right here you asked what would happen if you had a surface that was simultaneously designated for contact and was part of a fixed 0 displacement boundary, which is presumably a Dirichlet BC.

[makeclean]

oh i see, sorry, bit slow tonight :)

[makeclean]

Also, further weirdness, I have what I'm calling a 'docking' problem - but basically I have a 'rubber' hollow sphere (as shown in the image) and a stainless steel 'sphere' I am forcing the displacement as a function of time so that they start seperate and then get into contact later. In this case gravity is acting along the +ve z axis, there is a 0 displacement condition on the flat bottom of the rubber hollow sphere. I also constrain the x,y movement of the sphere with 0 displacement condition, such that the sphere only moves along the z axis. There are 3 contact surfaces; the outside part of the stainless sphere (a), the entry part into the hollow sphere (b) and the inside of the hollow sphere (c) and I have frictional contacts setup for ac and bc. All is great, contact is made the rubber deforms, but eventually we get a convergence failure at the minimum timestep.

I've tried turning on AMR, but this leads to segfaults and also some weird deformations that you'll see in the next image, and some oddly connected mesh elements.

So my questions are manifold, but

1. should contact and AMR work concurrently?
2. Ive tried taking both to second order but this leads to both PETSC segfault-ing
3. should I try just a finer mesh?

Happy to share inputs, can I attach them here?

[makeclean]

@recuero I got a hex version of my problem meshed and I see the exact same behaviour for 1st/2nd order meshes, i.e. for 1st the calculation runs for a bit, makes contact and then eventually takes tiny time steps and fails with the 2nd order one failing when contact is made.

[recuero]

@makeclean Any chance you can share the hex mesh/es? I have run relatively complex first order problems with hex meshes without any issues. In principle, I'd think the first order mesh should work. For the second-order case, it does look like nasty debugging is in order. If I get the mesh and input deck, I can see if it stops at the same place in the code. Thanks for trying this.

[makeclean]

Could you send me your email address? I should point out for the behaviour above, I was using my original input, not your modified one.

[recuero]

You can use this address: amrecuero85 at gmail dot com.

[GregVernon]

@makeclean If you're wondering how to mesh a sphere with hexes in Cubit, there's a sphere mesh scheme that has the logical structure of 7 cubes (one in the middle, one for each face) as shown below:

volume <vol_id> scheme sphere

Will produce the mesh shown on the right:

[makeclean]

No, that problem runs fine. I cant'reproduce the contact memory usage problem, except in the original geometry.

…

On Thu, 2021-01-28 at 12:09 -0800, Alex Lindsay wrote: The dock problem should also show the memory usage problem right? I see that you are using finite strain — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.

[bwspenc]

I'm jumping into this pretty late. It sounds like some of the memory issues have been resolved. I'd just add here that the patch_size parameter in the Mesh block can affect memory usage. That controls the size of the set of nodes on the primary face nearest to the secondary node that contains the faces that are considered for contact with that node. Back in the day, you had to set this really large when you had large sliding between the surfaces, because that set of nodes was static, but now that we have the patch_update_strategy=iteration option, that is dynamically updated, so you can get by with a pretty small patch. If I remember right, the set of candidate faces consists of all of the faces that contain the nodes that are found in the patch. That means that you can probably set it to something close to the number of nodes on a face. Maybe you can get by with a patch size of 10 or less.