So *DISTRIBUTING COUPLING indeed works properly with shells and it’s just a matter of setting the weights. For now, *COUPLING with *DISTRIBUTING seems unusable with shells, but maybe there are some workarounds. As I said above, I posted on the CalculiX forum to discuss it since it’s another limitation on the solver’s side: Coupling constraints with shells - Analysis issues - CalculiX (official versions are on www.calculix.de, the official GitHub repository is at https://github.com/Dhondtguido/CalculiX).
1 Like
This is CASE 3 In Case they are useful as reference. Good agreement too.
*NODE
1,0,-0.127,0
2,0.254,-0.127,0
3,0.254,0.127,0
4,0,0.127,0
5,0.508,-0.127,0
6,0.762,0.127,0
7,0.762,-0.127,0
8,0.381,0,0
9,0.508,0.127,0
10,0.0635,-0.127,0
11,0.127,-0.127,0
12,0.1905,-0.127,0
13,0,-0.0635,0
14,0.0635,-0.0635,0
15,0.127,-0.0635,0
16,0.1905,-0.0635,0
17,0.254,-0.0635,0
18,0,0,0
19,0.0635,0,0
20,0.127,0,0
21,0.1905,0,0
22,0.254,0,0
23,0,0.0635,0
24,0.0635,0.0635,0
25,0.127,0.0635,0
26,0.1905,0.0635,0
27,0.254,0.0635,0
28,0.0635,0.127,0
29,0.127,0.127,0
30,0.1905,0.127,0
31,0.5715,-0.127,0
32,0.635,-0.127,0
33,0.6985,-0.127,0
34,0.508,-0.0635,0
35,0.5715,-0.0635,0
36,0.635,-0.0635,0
37,0.6985,-0.0635,0
38,0.762,-0.0635,0
39,0.508,0,0
40,0.5715,0,0
41,0.635,0,0
42,0.6985,0,0
43,0.762,0,0
44,0.508,0.0635,0
45,0.5715,0.0635,0
46,0.635,0.0635,0
47,0.6985,0.0635,0
48,0.762,0.0635,0
49,0.5715,0.127,0
50,0.635,0.127,0
51,0.6985,0.127,0
*ELEMENT,TYPE=S4
1,26,30,3,27
2,47,51,6,48
3,1,13,14,10
4,10,14,15,11
5,11,15,16,12
6,12,16,17,2
7,13,18,19,14
8,14,19,20,15
9,15,20,21,16
10,16,21,22,17
11,18,23,24,19
12,19,24,25,20
13,20,25,26,21
14,21,26,27,22
15,23,4,28,24
16,24,28,29,25
17,25,29,30,26
18,5,34,35,31
19,31,35,36,32
20,32,36,37,33
21,33,37,38,7
22,34,39,40,35
23,35,40,41,36
24,36,41,42,37
25,37,42,43,38
26,39,44,45,40
27,40,45,46,41
28,41,46,47,42
29,42,47,48,43
30,44,9,49,45
31,45,49,50,46
32,46,50,51,47
*NSET,NSET=NSET_DCOUP
2
3
5
8
9
17
22
27
34
39
44
*NSET,NSET=NODE_SELECTION
2
3
5
9
17
22
27
34
39
44
*ELSET,ELSET=DEFAULT
2
3
4
5
7
8
9
11
12
13
15
16
17
19
20
21
23
24
25
27
28
29
31
32
*ELSET,ELSET=COMPONENT
1
6
10
14
18
22
26
30
*SURFACE,NAME=LEFT
3,S3
7,S3
11,S3
15,S3
*SURFACE,NAME=RIGHT
2,S5
21,S5
25,S5
29,S5
*SURFACE,NAME=INNER_LEFT
1,S5
6,S5
14,S5
10,S5
*SURFACE,NAME=INNER_RIGHT
18,S3
22,S3
30,S3
26,S3
*SURFACE,NAME=SSET_DCOUP
1,S5
6,S5
10,S5
14,S5
18,S3
22,S3
26,S3
30,S3
*MATERIAL,NAME=MATERIAL
*ELASTIC,TYPE=ISOTROPIC
68947572931.68,0.3
*DENSITY
7850
*MATERIAL,NAME=MATERIAL(2)
*ELASTIC,TYPE=ISOTROPIC
68947572931.68,0.28
*DENSITY
7850
*SHELL SECTION,ELSET=DEFAULT,MATERIAL=MATERIAL
0.00508
*SHELL SECTION,ELSET=COMPONENT,MATERIAL=MATERIAL(2)
0.00508
*BOUNDARY
1,2,,0
1,1,,0
1,3,,0
1,5,,0
4,2,,0
4,1,,0
4,3,,0
4,5,,0
6,2,,0
6,1,,0
6,3,,0
6,5,,0
7,2,,0
7,1,,0
7,3,,0
7,5,,0
8,3,,0
13,1,,0
13,2,,0
13,5,,0
18,1,,0
18,2,,0
18,5,,0
23,1,,0
23,2,,0
23,5,,0
38,1,,0
38,2,,0
38,5,,0
43,1,,0
43,2,,0
43,5,,0
48,1,,0
48,2,,0
48,5,,0
*AMPLITUDE,NAME=Ax_8_1
0,0
1,444.8221615261
*ELEMENT,TYPE=DCOUP3D
40,8
*ELSET,ELSET=E1
40
*DISTRIBUTING COUPLING,ELSET=E1
3,1
27,2
22,3
17,2
2,1
9,1
44,2
39,3
34,2
5,1
8,15
**3,-0.25
**27,-0.5
**22,-0.5
**17,-0.5
**2,-0.25
**9,-0.25
**44,-0.5
**39,-0.5
**34,-0.5
**5,-0.25
**8,4
*STEP,NLGEOM=YES,INC=100,AMPLITUDE=STEP
*STATIC
0.1,1,0,0.1
*CLOAD,AMPLITUDE=Ax_8_1
8,1,1
*NODE FILE,GLOBAL=YES,OUTPUT=2D
U,RF
*EL FILE
S,NOE,E,ENER
*CONTACT FILE
CDIS,CSTR
*END STEP
Deactivated weight on the inp refer to the surface based distribution.
@Matej Perhaps PrePoMax could have *DISTRIBUTING COUPLING (helpful since the surface-based version doesn’t work with shells) implemented with some predefined weight distributions automatically handled internally. Like the 3 options (linear, quadratic, etc.) in Abaqus listed here. But it might be better to make (or split) a new thread in Feature Requests.
as i understand, distributing coupling keyword is low level of coupling type distributing and lack of rotational moment loads feature. it seems current feature of coupling type distributing in PrePoMax not to be mixed or replaced by distributing coupling for only specific case of translation loads problem in shell of CalculiX. When some work around using weight factors applied, may not really needed since surface/edge traction is available internally in PrePoMax and it can be extended to support rotational moment loads.
Both types of distributing couplings have some limitations in terms of what can be applied and to which DOFs
So it would be good to have a switch in PrePoMax.
1 Like
separated feature still okay probably, it can be useful and more appropriates using Dcoup3D element as hinged connector instead of playing around in weight factor to fit load or displacement (translation/rotation) compared to coupling type distributing/kinematic currently available.
The simplest version would be a switch and automatically determined weight factors. This would be useful just to bypass the limitations of surface-based coupling. Ultimately, it could be a separate advanced coupling type with a way to set weights manually, but I guess that it would be rarely used and GUI wouldn’t add much with respect to using Keyword Editor.
1 Like
indeed, event limited to translational only it’s have similarly with surface traction available internally and user may expect to be extended to support rotational also for both load and displacement. Direct assigned force or displacement as nodal by precalculated of weight distribution instead of using coupling feature can be useful in defining load follower or not, eliminating conflict and convergence issue in large deformations analysis.
Couplings + Nlgeom is also interesting, but was discussed a few times on the CalculiX forum. Anyway, we got the proposed implementation so maybe let’s stop on that for now and wait for eventual feedback regarding distributing couplings with shells on the ccx forum.
1 Like
probably it’s a limitation of CalculiX due to beam or shell expansion and knots. General constraint using equation can be a solution since using linear ones as i tested in beam end release and point mass (rigid links) available in their forum.
There might be a different reason here since kinematic coupling is nonlinear eliminative constraint like rigid body, while distributing couplings are enforced in a completely different way. Perhaps I will ask Guido if he doesn’t reply on the CalculiX forum.