Dear All,
I am handling a bar in GetFEM++ framework. This post is questioning about unexpected nonzero values in a stiffness matrix K. I believe that thinking about it helps deeper understanding of the framework.
The problem considered is:
"""
Bar:
01 (point: 0, 1; convex: 0 (01), segment or 1dsimplex))
(2 dof (u, v) on a single point)
Coordinate system:
^ y, v, Fy

> x, u, FxExpected for the convex 0 (01):
K U = F
[ 1, 0, 1, 0] [u0] [Fx0]
[ 0, 0, 0, 0] [v0] [Fy0]
[1, 0, 1, 0] [u1] [Fx1]
[ 0, 0, 0, 0] [v1] [Fy1] (K: stiffness matrix, U: displacement vector, F: force vector)
(A bar should have zero stiffness in the transverse direction (i.e. y or vdirection here).)
"""
I believe that we can handle a bar using FEM_PK(1, 1) ((1, 1): first 1 for 1dsimplex (i.e. segment), second 1 for 2nodes on a segment).
However, obtained K has unexpected nonzero values:
"""
Obtained for the convex 0 (01) :
K U = F
[ 1, 0, 1, 0] [u0] [Fx0]
[ 0, 0.5, 0, 0.5] [v0] [Fy0]
[ 1, 0, 1, 0] [u1] [Fx1]
[ 0, 0.5, 0, 0.5] [v1] [Fy1] (K22, K24, K42, K44 are expected to be 0.)
"""
Can we know why K has 0.5 values like this? This behavior is unexpected for me (or possibly for people with structural background), but I guess that this behavior is logically expectable and explainable. I searched getfemusersarchives and looked into FEM_PK, GT_PK and some implementations but could not find the reason. The reason would be about the same interpolation of u and v if K22, K24, K42, K44 were 1, but actually they are 0.5.
Could you please give your comments? Any ideas are welcome. It really helps understanding the framework.
Attached is the script for python3. The script explicitly obtains stiffness matrix K using gf.asm_linear_elasticity(...). The other part is similar to Roman's one:
[Getfemusers] Solving truss structure in GetFEM++ (via Python)
https://lists.nongnu.org/archive/html/getfemusers/201103/msg00009.html*I like GetFEM++ way: separative design (GeoTrans, Mesh, Fem, Im, ...); high and low layers (Model, asm_...); point and convex; and so on.and so on.
Best regards,
Alex Spring