And now it’s all this

I just said what I said and it was wrong
Or was taken wrong

Moment diagrams for simply supported beams

April 3, 2024 at 3:33 PM by Dr. Drang

I thought I’d run through how the moment diagrams in the last post were made. It’ll probably take two articles to get through it all.

Let’s start with the three simple spans.

We’ll generate the moment diagram for a single simply supported beam and then apply it to each individual span.

Note here that $w$ is the uniform intensity of the load along the beam. It can be measured in pounds per foot, kilonewtons per meter, or any units that work out to force per length. The total load on beam is $wL$.

We start by drawing the free body diagram for the beam, replacing the supports with their associated reaction forces.

There are two unknowns, $R_A$ and $R_B$, and two equations of statics:¹

$$\∑F_y=R_A+R_B-wL=0$$ $$\∑M_A=R_{B}L-wL\left(\frac{L}{2}\right)=0$$

The first represents the sum of all the forces in the vertical direction, and the second represents the sum of all the moments about the left end of the beam (Point A). The solution to these two equations is

$$R_A=R_B=\frac{wL}{2}$$

You could have gotten this same answer with no algebra by taking account of symmetry. Because the structure is symmetric and the loading is symmetric, the reaction forces must also be symmetric.² (I guess there’s a little algebra because you need to know that the two equal reactions add up to $wL$, but that really doesn’t count, does it?)

With the reaction forces determined, we move on to determining the bending moment within the beam. When a structure is in equilibrium, every portion of it is in equilibrium. So we can consider just part of the beam, a section of length $x$ starting at the left end, and draw its free body diagram:

Because we have conceptually cut the beam at a distance $x$ from the left end, we’ve exposed the internal shear, $V$, and moment, $M$, and can write the equations of statics for this portion of the beam.

$$\∑F_y=\frac{wL}{2}-wx-V=0$$ $$\∑M_x=M+wx\left(\frac{x}{2}\right)-\left(\frac{wL}{2}\right)x=0$$

In the second equation, we’re taking moments about the right end of this portion.

Solving these two equations gives us

$$V=w(\frac{L}{2}-x)$$

and

$$M=\frac{wx}{2}(L-x)$$

Although the shear matters in beam design, the moment is typically more important, so we’ll focus on that. The equation for $M$ is that of a parabola, with $M=0$ at $x=0$ and $x=L$ and rising to a peak of

$$M=\frac{w{L}^2}{8}$$

at midspan, $x=L/2$.

For the middle span of the three-span bridge, $L=12a$, so

$$M=\frac{w(12a{)}^2}{8}=\frac{144w{a}^2}{8}=18w{a}^2$$

at its center. And for the two side spans, $L=7a$, so

$$M=\frac{w(7a{)}^2}{8}=\frac{49w{a}^2}{8}=6.125w{a}^2$$

at their centers. These are the labeled dots in the moment diagram at the top of the post.

To make the moment diagram in Mathematica,³ we have to start by taking the generic equation for $M$ and rewriting it as three equations that work in the individual spans, where the origin of the $x$ coordinate is at the left end. That will look like this:

$$M=\{\begin{array}{ll}\frac{wx}{2}[7a-x]& \mathrm{for}0\le x\le 7a\\ \frac{w(x-7a)}{2}[12a-(x-7a)]& \mathrm{for}7a<x\le 19a\\ \frac{w(x-19a)}{2}[7a-(x-19a)]& \mathrm{for}19a<x\le 26a\end{array}$$

To get Mathematica to plot this, we need to nondimensionalize the moment and the horizontal coordinate so we’re plotting pure numbers, with no $w$ or $a$ terms left in the expressions. We do that by dividing through by $w{a}^2$ to nondimensionalize $M$ and by introducing a new variable, $u=x/a$, to nondimensionalize the horizontal coordinate. That gives us

$$m=\frac{M}{w{a}^2}=\{\begin{array}{ll}\frac{u}{2}[7-u]& \mathrm{for}0\le u\le 7\\ \frac{(u-7)}{2}[12-(u-7)]& \mathrm{for}7<u\le 19\\ \frac{(u-19)}{2}[7-(u-19)]& \mathrm{for}19<u\le 26\end{array}$$

Now we’re ready to move to Mathematica for the plotting.

First, we define three $m$s, one for each span, and then use the Piecewise function within Plot to get a moment diagram that covers all three spans:

    m1 = 1/2*u*(7 - u);

    m2 = (u - 7)/2*(12 - (u - 7));

    m3 = (u - 19)/2*(7 - (u - 19));

    Plot[Piecewise[{{m1, u <= 7}, {m2, 7 < u <= 19}, {m3, u > 19}}],
     {u, 0, 26},
     ImageSize -> Large, 
     PlotStyle -> Thick, 
     Ticks -> {Table[t, {t, 0, 18, 2}], Table[t, {t, 0, 26, 2}]}]

That gives us the moment diagram shown at the top of the post, except for the dots and the labels at the peaks of the parabolas. I added those “by hand” in Preview.

Simply supported beams are called “statically determinate” structures because we can determine all the internal and external forces through statics alone. That won’t be the case for the three-span continuous beam, which we’ll analyze in the next post.

---

Structural continuity and the Francis Scott Key Bridge

April 1, 2024 at 5:06 PM by Dr. Drang

I don’t have anything particularly insightful to say about the collapse last week of the Francis Scott Key Bridge in Baltimore. But while reading some of the early reports on the collapse, I noticed two seemingly contradictory comments on the role of structural continuity in the bridge’s behavior, and I wanted to talk about them.

Image from Fvasconcellos on Wikipedia

The first is from this Wired article, which was pointed out to me by Leon Cowle:

“It’s a dreadful tragedy and something you hope never to see,” says David Knight, a bridge expert and specialist adviser to the UK’s Institution of Civil Engineers. But commenting on footage of the bridge collapse, he says he is not surprised by the manner in which it crumpled.

Large steel structures may seem invulnerable, but steel, explains Knight, is relatively lightweight for its size. As soon as it is pushed or pulled the wrong way with enough force, it can fold like paper. In this case, the Francis Scott Key Bridge was a “continuous,” or unjointed, bridge that had a 366-meter-long central truss section. (Truss bridges use steel beams, arranged in triangular shapes, to support their load.) The central truss was made up of three horizontal stretches, known as spans, with two sets of supports holding these above the water. It was the third-largest structure of its kind in the world.

“When you take a support away, there is very little in the way of robustness,” says Knight. “It will drag down, as we saw, all three spans.” The separate approach spans remain standing.

To start with, I doubt very much that anyone old enough to remember September 11, 2001, thinks that large steel structures are invulnerable, but let’s put that aside. The impression I got from reading this is that Knight thinks continuity contributed to the collapse, that it allowed the bridge to drag itself down once one of the interior supports was taken out by the ship.¹

Another view on structural continuity came from Abieyuwa Aghayere, a professor in the Civil, Architectural and Environmental Engineering department at Drexel University, in this interview with WPVI in Philadelphia:

Aghayere analyzes structural collapses. He was surprised that this type of bridge, known as a continuous truss bridge, completely failed.

“When something is continuous, it is supposed to at least hang on,” he said. “What I saw was that once the pier that was supporting that span gave way, the bridge just went down. There was no hesitation.”

Aghayere thinks continuity is good and that it typically allows a structure to withstand damage.

So we have two experts who seem to have opposite ideas about the value of continuity. Who’s right?

First, let’s look at what continuity is and how it affect the behavior of structures in general. We’ll start with an elementary structure that has some of the continuity of the Key Bridge.²

This is a three-span continuous beam of length 26a with a uniform load of intensity w applied to it (a has units of length and w has units of force per length). The three spans have lengths in the ratio 7:12:7 because the Key Bridge’s spans are about 700, 1200, and 700 feet. The beam is one long piece running from the left support to the right, with no joints in between. This is what’s meant by “continuous.”

Lots of three-span bridges, especially when the spans are short, are made with joints at the two interior supports because they’re easy to construct that way. Schematically, we’d draw such a bridge like this:

There aren’t really hinges at the interior supports, but we draw it that way to indicate that the connections at those locations are rotationally flexible—they don’t transfer much bending moment from one span to the next. The result is a structure that acts like three simple spans, one after the other.

Bending moments are proportional to the stresses in a structure, and structural engineering students spend a good chunk of their time learning how to calculate moments and draw moment diagrams. Here’s the moment diagram for the bridge with hinges at the supports:

Note that $w{a}^2$ has units of force per length times length squared, which works out to force times length, as expected for a moment.

For the continuous beam, the moment diagram is this:

This shows the value of continuity. By making the bridge act like one long beam instead of three shorter beams, the peak moment in the structure has been reduced by almost half. Therefore we can reduce the stresses by almost half if we make the bridge continuous across the supports.

As a practical matter, though, we wouldn’t use the same beams if we changed the design from three simple spans to a continuous structure. We’d take advantage of the lower moments to give the continuous beam a smaller cross section, saving material and cost.

This isn’t to say that all structures should be made continuous. Providing continuity often involves greater building costs because of increased labor and the need for more or specialized construction equipment. There are always tradeoffs to be made. In the Francis Scott Key Bridge itself, the approach spans on either side of the three spans that collapsed look to be simple spans. Apparently, their shorter length—about 300 feet—didn’t create bending moments that justified the additional construction complexity that comes with continuity.

Now let’s look at what happens when we lose one of the interior supports. We’re not going to consider the forces involved in the impact itself, we’ll just assume the support magically disappeared.

If our structure is made of three simple spans, removing an interior support turns it into a mechanism, and the two spans that were propped up by the now-missing support fall down. There are no calculations to be done; two spans are lost but the other survives.

Because of the joint at the right interior support, the right span survives the loss of the left interior support. The left two spans don’t drag it down with them. This is a point in favor of the “continuity is bad” argument, but I don’t think it’s strong enough to win out over the continuity advantage we showed above. After all, if we didn’t design with continuity, the central span would have to be considerably larger, and it would still end up in the river.

If our structure is continuous, removing an interior support leaves us with a two-span continuous beam that looks like this:

This is not a mechanism and would not necessarily fall into the river, a point in favor of the “continuity is good” argument. But let’s look at the moment diagram for this structure.

The peak moments are now over three times what they were before the support was removed. So while it’s conceivable that the bridge would stay up, the likelihood that it would do so is low.

Dr. Aghayere’s comment that continuity should allow a structure to “at least hang on” reminded me of something I learned in a structural reliability class over 40 years ago. Another student of my thesis advisor, a guy who was a few years ahead of me on the path to his Ph.D., had done a study of the reliability of continuous structures under different modes and sequences of failure. He learned that under typical design codes, the redundancy³ provided by continuity often doesn’t do much to increase the structure’s overall reliability. That’s because, as we talked about earlier, designers typically take advantage of continuity to reduce the cross sections of their structure’s components. The upshot is that failure in a particular location tends to lead to another failure elsewhere in the structure. In the case of the Key Bridge, it only took a couple more failures after the loss of the pier to bring the rest of the bridge down.

In short, while Mr. Knight’s and Dr. Aghayere’s comments on continuity are correct in theory, they aren’t very helpful in practice. No one would have designed the Francis Scott Key Bridge without taking advantage of continuity. Even if they hadn’t, the main span would still be blocking ship traffic and would be a bigger mess to clean up. And although continuous structures can survive the loss of some components, it’s very unlikely that long spans like this can survive the loss of an interior support.

The key to keeping bridges up over navigable waters is to build independent protective structures near—but not too near—the piers. The protective structures can get damaged by impact as long as they don’t transfer the load into the pier they’re meant to protect (that’s the “independent” part). Dr. Aghayere questioned the lack of protective structures in his interview, and he got that part exactly right.

---

My Mac 40th anniversary draft

January 23, 2024 at 9:01 PM by Dr. Drang

I assume that most of you have already listened—at least in part—to the latest episode of Upgrade, the 40th Anniversary of the Mac Draft. Any podcast with both John Gruber and John Siracusa is going be longer than your average Upgrade; I’m impressed they brought it in at 2½ hours. The whole show is good, but the Hall of Shame section is just hilarious.

I don’t have the sort of encyclopedic Mac knowledge the draft participants—Shelly Brisbin, Stephen Hackett, Dan Moren, Jason Snell, and the aforementioned Johns—have, but I do want to mention what my picks would be for two of the categories: first Mac and best/favorite Mac software.

My first Mac slips in between Siracusa’s original 128k Mac and Shelly’s Mac Plus.¹ It was the 512k Mac, popularly known as the Fat Mac because it had so much memory. I bought it in early 1985, when I was was in grad school, and wrote my thesis on it. I took advantage of a discount through the University of Illinois, and added on an external diskette drive, an ImageWriter printer, and the cool canvas carrying bag, in which I hauled the Mac between my apartment and office—just like in Apple’s marketing literature of the time.

I tend to think of the Fat Mac as the first truly useable Mac, mainly because it had enough RAM for apps to have some breathing room. Even better, Switcher, which allowed you to run multiple apps at once before MultiFinder, gave the Fat Mac a giant advantage over the original. I was teaching a course in the spring semester of ’85 and made up my tests on the Mac, making the illustrations in MacPaint and then switching over instantly to paste them into a MacWrite document.

As for my best/favorite Mac software, I’m going to do the traditional podcast draft thing and talk about how I was torn between two apps, thus giving me effectively two picks. But before that, I need to point out that the choices made by those on the podcast are all objectively better than mine. I’m deliberately choosing apps that are weird but were very useful to me in the early years. They also showed off the Mac’s user interface to great advantage.

The app I nearly chose was Macintosh Pascal, written by THINK Technologies (who went on to publish Lightspeed Pascal and Lightspeed C, which had the greatest programmer slogan ever: “Make mistakes faster”) and distributed by Apple.

This was an interpreted Pascal, so the code ran relatively slowly, but the lack of a compilation step made the edit/debug/edit/debug cycle go quickly. On the editing side, Macintosh Pascal was my introduction to syntax highlighting, which you can see (sort of) in the screenshot above. This was the Mac’s font styles used to great effect. Debugging was also done visually by dragging a stop sign to the line of code that needed a breakpoint. These are things we take for granted now, but they were a revelation to me in 1985.

So with my not-quite-choice out of the way, here’s my fave: Claris CAD.

Am I kidding? No. This was a fantastic program for the kind of drawing I was doing back in the early ’90s and am still doing today. It wasn’t drafting, per se, but it did involve the kinds of construction typically done on a drafting table: lines tangent to circles, circles tangent to lines, lines perpendicular to other lines, and so on. The cursor would snap to features of the drawing and show a preview of how the next item would be drawn. It nearly always did exactly what I wanted.

And this is not just hazy nostalgia; I thought Claris CAD was an amazing program at the time. It was simply more in tune with the drawing of manufactured objects than were (and are) apps more obviously based on Bezier curves.

These apps were not only great, they are perfect for a draft. No one would snipe them.

---

A Typinator snippet for plotting

January 14, 2024 at 12:02 PM by Dr. Drang

My last post ended with this graph:

It was made, as most of my graphs are, using Python and Matplotlib. Here’s the code that did it:

python:
 1:  #!/usr/bin/env python
 2:  
 3:  import matplotlib.pyplot as plt
 4:  from matplotlib.ticker import MultipleLocator, AutoMinorLocator
 5:  import numpy as np
 6:  import sys
 7:  
 8:  # Array of angles in degrees
 9:  theta = np.arange(0.5, 90.0, 0.5)
10:  
11:  # Arrays of friction coefficients
12:  muFloor = 1/(2*np.tan(theta*np.pi/180))
13:  muBoth = np.sqrt(1 + np.tan(theta*np.pi/180)**2) - np.tan(theta*np.pi/180)
14:  
15:  # Create the plot with a given size in inches
16:  fig, ax = plt.subplots(figsize=(6, 4))
17:  
18:  # Add the lines
19:  ax.plot(theta, muFloor, '-', color='#1b9e77', lw=2, label="Floor only")
20:  ax.plot(theta, muBoth, '-', color='#d95f02', lw=2, label="Wall and floor")
21:  
22:  # Set the limits
23:  plt.xlim(xmin=0, xmax=90)
24:  plt.ylim(ymin=0, ymax=2)
25:  
26:  # Set the major and minor ticks and add a grid
27:  ax.xaxis.set_major_locator(MultipleLocator(15))
28:  ax.xaxis.set_minor_locator(AutoMinorLocator(3))
29:  ax.yaxis.set_major_locator(MultipleLocator(.5))
30:  ax.yaxis.set_minor_locator(AutoMinorLocator(2))
31:  # ax.grid(linewidth=.5, axis='x', which='major', color='#dddddd', linestyle='-')
32:  # ax.grid(linewidth=.5, axis='y', which='major', color='#dddddd', linestyle='-')
33:  
34:  # Title and axis labels
35:  plt.title('Leaning ladder problem')
36:  plt.xlabel('Ladder angle (degrees)')
37:  plt.ylabel('Friction coefficient')
38:  
39:  # Make the border and tick marks 0.5 points wide
40:  [ i.set_linewidth(0.5) for i in ax.spines.values() ]
41:  ax.tick_params(which='both', width=.5)
42:  
43:  # Add the legend
44:  ax.legend(loc=(.58, .62), frameon=False)
45:  
46:  # Save as SVG
47:  plt.savefig('20240110-Friction comparison graph.svg', format='svg')

In broad outline, this is how nearly all of my Matplotlib graphs are made, because I have a Typinator snippet that inserts generic plot-making code that I modify to set the limits, tick marks, legend, etc. that are appropriate for the graph.

By the way, I don’t think I’ve mentioned here that I’ve switched to Typinator. Ergonis was having a sale at the tail end of 2022, and I decided to give it a go. I had been using Keyboard Maestro for my snippets for several years, but KM isn’t truly meant for text expansion, and I wanted to move to something more built-for-purpose. TextExpander would, I suppose, be the obvious choice, but I didn’t want another subscription. Typinator looked to have all the features I needed, and I haven’t regretted the choice in the year I’ve been using it.

Anyway, here’s the Typinator definition of my plotting snippet:

As you can see, the abbreviation is ;plot. As you can’t see, at least not fully, the expansion is this:

import matplotlib.pyplot as plt
from matplotlib.ticker import MultipleLocator, AutoMinorLocator

# Create the plot with a given size in inches
fig, ax = plt.subplots(figsize=(6, 4))

# Add a line
ax.plot(x, y, '-', color='blue', lw=2, label='Item one')

# Set the limits
# plt.xlim(xmin=0, xmax=100)
# plt.ylim(ymin=0, ymax=50)

# Set the major and minor ticks and add a grid
# ax.xaxis.set_major_locator(MultipleLocator(20))
# ax.xaxis.set_minor_locator(AutoMinorLocator(2))
# ax.yaxis.set_major_locator(MultipleLocator(10))
# ax.yaxis.set_minor_locator(AutoMinorLocator(5))
# ax.grid(linewidth=.5, axis='x', which='both', color='#dddddd', linestyle='-')
# ax.grid(linewidth=.5, axis='y', which='major', color='#dddddd', linestyle='-')

# Title and axis labels
plt.title('{{?Plot title}}')
plt.xlabel('{{?X label}}')
plt.ylabel('{{?Y label}}')

# Make the border and tick marks 0.5 points wide
[ i.set_linewidth(0.5) for i in ax.spines.values() ]
ax.tick_params(which='both', width=.5)

# Add the legend
# ax.legend()

# Save as PDF
plt.savefig('{{?File name}}.pdf', format='pdf')

Typinator uses special syntax for placeholder text. In this case, the placeholders are

• The plot’s title: {{?Plot title}}
• The x-axis label: {{?X label}}
• The y-axis label: {{?Y label}}
• The file name: {{?File name}}

I don’t have to remember this syntax. The {…} popup menu has a bunch of placeholder options and will insert the correct code when you define the placeholder.

When I type ;plot, this dialog box appears to enter the text for each placeholder:

Typinator remembers the last text I entered for each placeholder, which makes things go faster if I’m doing a series of similar graphs.

If you go through the snippet, you’ll see that many of the lines of Matplotlib code are commented out, in particular those that set the formatting of the graph. That’s because I usually like to see what Matplotlib comes up with by default. If I don’t like the defaults, I uncomment the appropriate lines and start tinkering. You’ll also notice that this produces PDFs by default; that’s because the plots I make for work have always been PDFs. As I expect to be writing very few work reports from now on, I’ll probably change the file format in the last line from PDF to SVG or PNG.

---

Newer posts Older posts

Site search

Meta

• drdrang at leancrew
• Blog archive
• RSS feed
• JSON feed
• Mastodon
• GitHub repositories

Recent posts

Credits

This work is licensed under a Creative Commons Attribution-Share Alike 3.0 Unported License.

© 2005–2023, Dr. Drang