Computing forces in a system of beams, properly
The great thing about posting stuff online is that somebody will inevitably come to tell you where you’re wrong :)
In my previous post I explored how one can compute the forces and stresses in a system of interconnected beams. There were a few things that I got a bit wrong there, so this post is an attempt to fix those things and to implement a better force computation algorithm.
Contents:
 Terminology
 Moments
 Updated model
 Determinacy
 A bit of graph theory
 Stresses
 Examples
 Interactive playground
Terminology
First, some terminology errata:
 What I called hinges are, in fact, fixed supports.
Mmm… Yep, that’s it.
Moments
Solid objects don’t just move, they also rotate. Thankfully, I didn’t forget about it in the last post, and I included the torque conservation for each beam to my system of equations to solve.
What I did forget about, though, is the fact that connections between objects can produce torque without applying a force. Imagine pushing a screwdriver perpendicularily into a wooden plank and starting to rotate it around the screwdriver axis: there is no force here, we’re not pushing the plank in any direction. Instead, we’re directly applying rotation to it.
Here’s another demonstration that hints towards this. Consider a nonvertical beam glued to the ground somehow:
Clearly, the ground acts on it by a force that cancels gravity. This force also creates a moment, forcing the beam to rotate (clockwise, in this case). But the beam is glued with super glue, it cannot rotate! Yet there is no other force acting on this beam.
What is acting on this beam is a moment at the gluing point, which cancels the moment created by the force. So, the ground acts on the beam both by a force (represented here as a straight arrow) and by a moment (represented as a circular arrow).
Updated model
Adding these moments to our model is quite simple:
 In addition to a force vector \(F\) acting on each end of a beam, we have an extra moment \(M\) (a scalar in 2D, a vector in 3D) on each end as well
 The torque balance equation for each beam should include its moments at both ends:
\[ F_a \times (r) + F_b \times r + M_a + M_b = 0 \]
 For each connection, we need an extra equation for torque balance at this connection: the sum of all moments of all beams connected to this point must be zero
\[ M_{a1} + M_{a2} + M_{b3} = 0 \]
Here, \(M_{a1}\) is the \(M_a\) moment of the first beam conected to this point (if it is connected with the \(a\) end and not the \(b\) end), and so on.
Determinacy
We’ve added two more scalar unknowns per each beam, and only one new equation for each beam connection. How exactly the system has changed depends on the exact topology, but it seems that typically we’ve nudged the system towards the underdetermined regime.
This is, however, exactly what I’d expect. It turns out that most complex systems are like this, – they have more unknowns than equations, – and they are usually called statically indeterminate systems in engineering.
Properly solving such systems requires either adding simplifying assumptions (a common one being that beams are, in fact, simply trusses), or adding more equations derived from the properties of the beam materials.
Though, improperly solving this system can still be done using least squares!
A bit of graph theory
Based on my experiments, it seems that the only case when the system is exactly solvable is when the beams form a tree (i.e. no loops) and this tree is connected to the ground or walls at exactly one point. In all other cases, the system is statically indeterminate. And if the system is just flying in the air, it is overdetermined or sometimes singular, which makes sense: there’s no way this system is actually at rest.
We can use a little bit of graph theory to prove what I said in the previous paragraph. Our beams naturally form a graph, wich beams themselves being the edges, and beam endpoints being the vertices. Let’s assume that this graph is connected, – otherwise there are several independent beam structures that can be analyzed separately.
 For each edge of this graph (i.e. for each beam), we have 6 scalar unknowns and 3 scalar equations.
 For each vertex of this graph, we have just 3 scalar equations.
There are a few special cases here:
 A freefloating end of a beam doesn’t feel any forces or moments; however, to simplify counting, let’s say it still has both a force and a moment at this free end, and also the corresponding equations that simply tell that the force and moment are both zero.
 A vertex that touches the ground/walls doesn’t have corresponding equations; alternatively, is has 3 extra unknowns (the force and moment applied to the ground/walls). In any case, the equationsunknowns balance is the same.
Now, given \(E\) edges (beams) and \(V\) vertices (beam ends), of which \(G\) vertices are touching the ground/walls, the total numbers are
 Unknowns: \(6E\)
 Equations: \(3E+3V3G\)
Finally, it is a basic fact from graph theory that a connected graph is a tree if and only if \(E=V1\), otherwise \(E\geq V\) and the graph is not a tree (contains cycles).
So, if our beam structure forms a tree, we substitute \(V=E+1\) to get
 Unknowns: \(6E\)
 Equations: \(3E+3(E+1)3G = 6E+33G\)
And the difference unknowns  equations
is \(3(G1)\). In this case
 If \(G=0\), i.e. the structure is floating in the air, the difference is \(3\), so there are 3 more equations than unknowns, and the system is overdetermined
 If \(G=1\), i.e. the structure connects to ground/walls at exactly one point, the difference is \(0\) and the system is square
 If \(G>1\), the difference is positive and the system is underdetermined
If the graph is not a tree, we have \(V\leq E\), so the number of equations is \(3E+3V3G \leq 6E3G\), and the difference unknowns  equations
is \(\geq 3G\), meaning it is always either square (which happens e.g. if the system is a single beam loop floating in the air), or, more typically, underdetermined again.
Stresses
The addition of rotating moments complicates our bending stress calculation. In the previous post we’ve derived that the bending only depends on the beam’s orientation, which is no longer the case, and we need to account for these new moments. If a beam is rotated clockwise at the left end, and counterclockwise at the right end, it is clearly being bent downwards.
At to how exactly do we compute this bending now, I’ll probably postpone this until the next post in this series, which is going to be about a system of connected solid cubes :)
(I’m too lazy to figure it out right now.)
Examples
Here are a few interesting systems that have large enough support moments:
Interactive playground
Here’s an updated interactive playground. It shows forces acting on beams as straight arrows, and moments as curved arrows. The moment arrows show which way this moment wants to turn the beam. Thus, there are 4 arrows in total for each beam: one force and one moment at each end. Note that forces or moments that are too small are not shown here.
Left click and drag to create beams (they automatically connect to each other via hinges fixed supports if their endpoints coincide), right click to remove beams. You can select whether to show forces or stresses using the control panel below the thing, toggle showing the gravity force, and also change the scale of the force vectors.
Force scale: 
As always, check out my road building & traffic simulation game
Costa Verde Transport Department on Steam 

watch my devlogs about it
and thanks for reading!