I’m ran a little out of attempts. I have this data set.
runway_tst.inp
A brick with friction sliding along a runway with a constant velocity and under gravity load.
It runs smoothly to finish with ccx ver. 2.19 & 2.20 but with ver. 2.21 & 2.22 of ccx it stops after a number of iterations with too many cutbacks.
With ccx 2.21 & 2.22 I have without success tested different option, element size, step size, swap of master slave, node to surface and surface to surface.
My current conclusion will be that something instability must have happened between ver. 2.20 and 2.21 but anyway I could have missed some necessary setting.
Running under ccx ver. 2.20 it look like this
You impose an initial velocity and a displacement boundary conditions into the x-direction to the brick nodes:
*Initial conditions, Type=Velocity
brick_nodes, 1, 0.75
*Boundary, Amplitude=runway_speed
brick_nodes, 1, 1, 1
This may be a conflict, you may only need one of the two settings.
I would further recommend to reduce the friction for the initial tests:
*Surface behavior, Pressure-overclosure=Linear
1.E+06,
*Friction
0.01
Then it should run with ccx version 2.22 .
1 Like
@johanngil , thanks for the note on the brick_nodes velocity, I didn’t had focus at this card.
I don’t know if it should be general, but in this case the convergence/divergence is quite affected by the stick slope, which in my mind also make sense, since a heavy stick slope will require extreme small steps to follow. I can wonder why the default stick slope has been define as high as 1000000000.
Both curves have been run with
*Surface behavior, Pressure-overclosure=Linear
1e+10, 2860000
*Friction
0.2,
but the leftmost with stick slope of 1000 and the rightmost with 100000. Both curves converge to the same value, leftmost with a smooth run in and rightmost with many
fluctuation before converging.
Currently I have a little concern that the gravity load must have a deviation.
I did that test some time ago but starting from rest and increasing the platform angle slowly. The aim was to check if friction value match with the tan(angle) at which the block starts to slide. I found that it’s not convenient to abuse from the K value more than necessary. It made my surface “sticky”. Like what you see. You could also check if the speed is the expected.
1 Like
Whom it must concern should notice that in case of diverge problems with ccx ver. 2.22 Dynamic Implicit it might be worthy to check the same data set with ver. 2.20.
With these key setting ccx ver 2.20 become stable after a short period of fluctuations complete opposite to ccx ver. 2.22 with diverge after a short period.
*Solid section, Elset=brick, Material=ABS
*Solid section, Elset=runway, Material=ABS
**
*Surface interaction, Name=Surface_contact
*Surface behavior, Pressure-overclosure=Linear
10000000000, 2860000
*Friction
0.2, 1000000
**
*Contact pair, Interaction=Surface_contact, Type=Surface to surface, Adjust=0
slave, master
**
*Amplitude, Name=runway_speed
0, 0, 1, 0.75
**
*Initial conditions, Type=Velocity
brick_nodes, 1, 0.75
**
*Step, Nlgeom, Inc=100000
*Dynamic, Solver=Pardiso, Alpha=-0.3
1E-06, 0.05, 1E-07, 4e-04
**
*Output, Frequency=1
**
*Boundary, op=New
*Boundary, Amplitude=runway_speed
brick_nodes, 1, 1, 1
**
*Boundary
brick_nodes, 2, 2, 0
runway_ground, 1, 3, 0
**
*Cload, op=New
*Dload, op=New
*Dload
brick_gravity, Grav, 9.82, 0, 0, -1
**
For ccx ver. 2.20 the reaction force looks like this
A comparison between 2.20 and 2.22 until 2.22 diverge will look like this. It’s ccx 2.20 on the leftmost graph.
Comparing step size between 2.20 and 2.22 show the curves follows each other until app. 5E-05 where 2.22 for some unknown reason suddenly get lost and totally give up opposite to ver 2.20 which continues until max step size and continue stable at this value.
1 Like
I will appreciate if anyone could give me a little hint.
I have this data set where a box in Dynamic Implicit is rotation around a center point.
When I define an angular velocity of 6.28 rad/sec and define an analysis time of 2 sec. I then expect the box to having 2 cycles around the center, but it only takes 1 cycle. It seems like something unexpected happens at 1 sec.
Does anyone have a hint about the data set or should i look into the code of ccx ?
**
*Node
1, 0.0, 0.0, 0.0
2, 1.0, 0.0, 0.0
3, 1.0, 1.0, 0.0
4, 0.0, 1.0, 0.0
5, 0.0, 0.0, 1.0
6, 1.0, 0.0, 1.0
7, 1.0, 1.0, 1.0
8, 0.0, 1.0, 1.0
9, 0.0, 0.0, 2.0
10, 1.0, 0.0, 2.0
11, 1.0, 1.0, 2.0
12, 0.0, 1.0, 2.0
13, -1.0, 2.0, 1.0
14, -1.0, 2.0, 1.0
**
*Element, Type=C3D8, Elset=Box
1, 1, 2, 3, 4, 5, 6, 7, 8
2, 5, 6, 7, 8, 9, 10, 11, 12
**
*Nset, Nset=Rigid_Body
1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12
**
*Elset, Elset=all
1, 2
**
*Material, Name=ABS
*Density
1020
*Elastic
2000000000, 0.394
**
*Solid section, Elset=all, Material=ABS
**
*Rigid body, Nset=Rigid_Body, Ref node=13, Rot node=14
**
*Amplitude, Name=omega
0, 0, 2, 6.28
**
*Initial conditions, Type=Velocity
14, 3, 6.28
**
*Step, Nlgeom, Inc=10000
*Dynamic, Solver=Pardiso
0.01, 2, 1E-05, 0.05
**
*Output, Frequency=2
**
*Boundary, op=New
*Boundary, Amplitude=omega
14, 3, 3, 1
*Boundary
13, 1, 3, 0
14, 1, 2, 0
**
*Node file
U
**
*End step
HI fgr.
Your initial condition is right but your amplitude is not. You want to complete two revolutions (4Pi) at the end of the analisys (2s).
*Amplitude, Name=omega
0, 0
2, 12.5663
**0, 0, 2, 6.28
1 Like
@Disla , thanks for support 