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

First, some terminology errata:

  1. 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 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).

Updated model

Adding these moments to our model is quite simple:

  1. 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
  2. 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 \]

  1. 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 free-floating 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 equations-unknowns 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+3V-3G\)

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

  • Unknowns: \(6E\)
  • Equations: \(3E+3(E+1)-3G = 6E+3-3G\)

And the difference unknowns - equations is \(3(G-1)\). 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+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.


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


watch my devlogs about it

and thanks for reading!