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.
First, some terminology errata:
Mmm... Yep, that's it.
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 non-vertical 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).
Adding these moments to our model is quite simple:
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.
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!
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, with 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.
There are a few special cases here:
Now, given \( E \) edges (beams) and \( V \) vertices (beam ends), of which \( G \) vertices are touching the ground/walls, the total numbers are
Finally, it is a basic fact from graph theory that a connected graph is a tree if and only if \( E=V-1 \), 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
And the difference (unknowns - equations) is \( 3(G-1) \). In this case
If the graph is not a tree, we have \( V\leq E \), so the number of equations is \( 3E+3V-3G \leq 6E-3G \), 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.
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.
As 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.)
Here are a few interesting systems that have large enough support moments:
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: |
I hope this new model is better than my previous one :)
And, as always, thanks for reading!