Contact Mechanics - Friction Test
-
- Posts: 2319
- Joined: 25 Jan 2019, 01:28
- Antispam: Yes
Re: Contact Mechanics - Friction Test
This is the sif and mesh that produced a contact load of 10 with a normal force of 10 applied, no side motion. If I try to drag the body it isn't 10 anymore. I believe the cube is tipping or trying to and the contact load is not uniform.
Re: Contact Mechanics - Friction Test
Ah I see.. I still had the side motion. Now I get the same result. I guess the side motion confuses ELMER, even though the Normalforce is (or should) not changed by it. I also changed Friction Contact back to Logical True in your sif and I still get the same results, so the reason for the wrong results is very likely the side motion.
-
- Posts: 2319
- Joined: 25 Jan 2019, 01:28
- Antispam: Yes
Re: Contact Mechanics - Friction Test
I believe the cube is trying to tip over and the contact is not uniform, it is mostly bearing on the front edge and makes those values very high. I am testing with much wider and thinner blocks to reduce tipping.
I also do not get the right normal load with gravity load.
I also do not get the right normal load with gravity load.
Re: Contact Mechanics - Friction Test
Also strange is that when I put
Normal Force = Real $ -9.81 * 7810.0
at the top of the cube, I get the right value as Displacement Contact Normalload in Paraview. But when I put
Normal Force = Real $ -9.81 * 7810.0 * 10.0e-6
(because this would be the correct Normalload), I get a different value in Paraview. And also based on your sif I found out that you get the right Normalload with SaveScalars when you put
Variable 2 = Displacement Contact Normalload
Operator 2 = boundary max
instead of boundary sum. With your sif, I get 10 in every timestep in the dat-file. And with the side motion, the Normalload is not even correct in the first timestep and also different to the output in my terminal. Just everything very frustrating.
Normal Force = Real $ -9.81 * 7810.0
at the top of the cube, I get the right value as Displacement Contact Normalload in Paraview. But when I put
Normal Force = Real $ -9.81 * 7810.0 * 10.0e-6
(because this would be the correct Normalload), I get a different value in Paraview. And also based on your sif I found out that you get the right Normalload with SaveScalars when you put
Variable 2 = Displacement Contact Normalload
Operator 2 = boundary max
instead of boundary sum. With your sif, I get 10 in every timestep in the dat-file. And with the side motion, the Normalload is not even correct in the first timestep and also different to the output in my terminal. Just everything very frustrating.
Re: Contact Mechanics - Friction Test
With gravity load it doesn't work for me either.
The tipping over could be an effect, but usually it should not happen with the friction coefficent and normalload being quite low. The problem could be that the calculated Fstatic and Fdynamic are way too high. In my terminal output they are always WAY too high and do not even fit the equation Fstatic = mustatic * Normalload. An output I get is for example
mustatic: 0.29999999999999999
mudynamic: 0.20000000000000001
NodeLoad: 596.22347870600356
Fstatic: 745810.77674066077
Fdynamic: 497207.18449377362
where Fstatic and Fdynamic are clearly not 596 * 0,2 or 0,3
When ELMER really applies a force that high in the opposite direction of the displacement it would be physically correct that a torque appears and the cube tips.
The tipping over could be an effect, but usually it should not happen with the friction coefficent and normalload being quite low. The problem could be that the calculated Fstatic and Fdynamic are way too high. In my terminal output they are always WAY too high and do not even fit the equation Fstatic = mustatic * Normalload. An output I get is for example
mustatic: 0.29999999999999999
mudynamic: 0.20000000000000001
NodeLoad: 596.22347870600356
Fstatic: 745810.77674066077
Fdynamic: 497207.18449377362
where Fstatic and Fdynamic are clearly not 596 * 0,2 or 0,3
When ELMER really applies a force that high in the opposite direction of the displacement it would be physically correct that a torque appears and the cube tips.
-
- Posts: 2319
- Joined: 25 Jan 2019, 01:28
- Antispam: Yes
Re: Contact Mechanics - Friction Test
case 1 of plate contact test (lower height than cube), normal load only no side pull, contact normal load is correct, but there is a significant slip load even though there is no transverse motion.
-
- Posts: 2319
- Joined: 25 Jan 2019, 01:28
- Antispam: Yes
-
- Posts: 2319
- Joined: 25 Jan 2019, 01:28
- Antispam: Yes
Re: Contact Mechanics - Friction Test
With motion, Contact Friction = Logical True,
With Contact Friction = Logical False, same answer as with True
Normal load and slip load wrong
With Contact Friction = Logical False, same answer as with True
Normal load and slip load wrong
- Attachments
-
- Slip_with_motion.png
- (36.48 KiB) Not downloaded yet
Re: Contact Mechanics - Friction Test
So the cube trying to tip over is probably not the reason for the wrong forces, because the plate would not try to flip. That was your intention trying this, right?
I finally managed to get my terminal output right and the calculation of Fdynamic and Fstatic is correct for normalforce and no side motion, so somehow the displacement must distort the normalload and thus all the calculations are false.
I finally managed to get my terminal output right and the calculation of Fdynamic and Fstatic is correct for normalforce and no side motion, so somehow the displacement must distort the normalload and thus all the calculations are false.
-
- Posts: 2319
- Joined: 25 Jan 2019, 01:28
- Antispam: Yes
Re: Contact Mechanics - Friction Test
Correct on the first question.
Not sure what the issue is with the motion part. I tried turning on and off many of the parameters, and tried the different contact types. The all have the same result.
I wonder if there is a coordinate system issue with motion?
Not sure what the issue is with the motion part. I tried turning on and off many of the parameters, and tried the different contact types. The all have the same result.
I wonder if there is a coordinate system issue with motion?