# FEM 3D truss analyzer produces forces that do not sum to zero at joints

I am writing some code for the analysis of 3D truss structures. The program is a typical implementation of the direct stiffness method for truss elements. While testing it and comparing results to other FEM programs, I encountered the following problem.

When I have a joint with zero-force truss elements (for example a joint where 3 non-coplanar truss elements meet), the forces in these elements do not equal zero, which contradicts the joint equilibrium equation. This only happens for space trusses. When I consider plane trusses and add zero-force joints (for example a joint where two non-colinear truss elements meet), everything works out okay.

I cannot see what causes this problem. Perhaps some additional form of static condensation is needed for the 3D-case?

My thought process is that if the force in an element equals zero, that means that $u_{i} - u_{j} = 0$, where $u_{i}$ and $u_{j}$ are the axial displacements of that element, expressed in its local coordinate system. Simply stated, no elongation means no force. Of course, the whole element can be displaced in a rigid-motion-manner only, if at all.

The problem seems to be the following. Assume you have a 3D truss defined, with no zero-force members. Attach 3 elements to it (i.e. a tetrahedron, which is stable by itself) so that the entire truss is stable again. Assume the joint where these elements meet is unloaded, hence all the forces in the added elements must equal zero. Of course, the other displacements and forces in the truss are not affected by this - it just acts the same as without the added three elements. Hence, the truss would somehow need to "know" that it must be displaced in such a manner that none of the three members is elongated (or contracted), i.e. they can only be displaced as a whole, rigidly.

This seems pretty weird and it hints that perhaps such situations should indeed be treated before the analysis. Then again, the direct stiffness method is, as far as I know, completely general and should be able to calculate any truss.

Further on, for 2D trusses this situation does not seem to arise at all; the zero force members are always recognized correctly by the direct stiffness method.

Below is an example of a truss where I encounter the problem. The image represents the element and node labeling of the truss.

From equilibrium of node 10013 (the upmost node), it follows that the forces in elements 112, 114 and 116 must equal zero. But, the program only calculated zero force in element 114. The forces in elements 112 and 116 are of order of magnitude similar to the other forces in the truss.

When I remove elements 112, 114 and 116, all the forces in the truss are calculated correctly when compared to another FEM solver (up to 3% difference, as mentioned above). • That does seem odd - if you have a member in x, a member in y, and a member in z, and a force in x, does it have force in the y/z members, or just the x? – Mark Jul 1 '15 at 21:47
• Does your code work if you manually remove the zero-force member? Is it a situation where you want to check for zero-force members before starting the analysis? – hazzey Jul 2 '15 at 4:50
• Mark, I did not try it out for the "orthogonal" case you mentioned, I will later today. – John Kimble Jul 2 '15 at 5:43
• hazzey, the code works when I remove the zero-force members. There are sometimes differences (cca 1% - 3%) when comparing displacements and forces with other FEM packages, but this seems okay. Also, I'm not sure I should implement zero-force checking before starting the analysis, since the direct stiffness method is completely general and should recognize this automatically. – John Kimble Jul 2 '15 at 5:45
• The fact you mention deflection intrigues me. As 0-force truss members, you wouldn't measure deflection for determining forces, or recalculate based upon deflection. My FEA book is back in the office, so I'd have to look at that in the morning. Treating everything as bendable beams, if you had a single force in the direction of 110 on node 10000, then you'd definitely have a registered deflection in 112 and 116 (and therefore forces) with (minimal) force on 114. So maybe you have something still acting "beam" when it should be "truss". – Mark Jul 9 '15 at 0:45

## 1 Answer

Just to let you know, I solved the problem. The element stiffness matrices had an error due to a typo, actually they were not even symmetric! Moral of the story: it's good to test for symmetry when you write a function which produces an element stiffness matrix. Anyway, thanks to all for your efforts and replies.