Rebar and reinforced concrete
October 19, 2024 at 2:34 PM by Dr. Drang
A recent episode of the 99% Invisible podcast, “Brilliantly Boring,” covers a topic near and dear to my heart: reinforced concrete—more specifically, the rebar that does the reinforcing. The show does an excellent job in a short period. I just want to fill in some details.
The show is structured around the Alvord Lake Bridge in Golden Gate Park. Built in 1889, it’s one of the earliest reinforced concrete structures that’s still around. It was designed by Ernest Ransome, the guy who made rebar (almost) what it is today.
Iron and steel bars were used to reinforce concrete before Ransome. Joseph Monier of France is usually credited with starting the systematic study and use of reinforced concrete back in the 1850s. But as far as I know, the reinforcing bars and wires that Monier used were smooth, round bars with no texture or bumpiness. Ransome used bars that were made of square stock that had been twisted, like this:
Image from Walcoom Corporation.
The twist helps prevent the bar from slipping relative to the concrete. This makes them act together, which is how reinforced concrete gets its strength. In the show, they say that the twist “gives it an adhesive quality to the concrete itself,” which isn’t quite right. What the twist does is provide what’s called mechanical interlock. For a twisted bar to slip, it has to both break the adhesive bond with the surrounding concrete and push it out of the way so it can slide past. This extra resistance to slip is what made twisted bars work better.
Nowadays, we almost always use what are called deformed bars, which have little ribs on the surface to provide the interlock.
Image from Walcoom Corporation.
But twisted rebar had a strong run in the early days of reinforced concrete. Many years ago, a friend and coworker of mine was directing some repair work at the Unity Temple in Oak Park, Illinois. This is a Unitarian Universalist church designed by Frank Lloyd Wright at the beginning of the 20th century. One day my friend called me into his office. “You have to see this,” he said, as he handed me a three-foot length of twisted rebar. “This is original Frank Lloyd Wright rebar. I found it in the trash. They were going to throw it away!” So I got to hold a piece of architectural and structural engineering history because of my friend’s dumpster diving.
Why do we need to use rebar? As they say in the podcast, concrete is strong in compression but relatively weak in tension. The usual rule of thumb is that its tensile strength is about one-tenth its compressive strength. This pretty much limits unreinforced concrete to structures that never undergo tensile stresses. But if we put rebar into concrete where tension will develop, that tension will be carried by the steel, and we can use concrete in almost any kind of structure.1
There is a problem, though. The highest tensile stresses tend to occur at the outer edges of structures, right along the surface. So to get the most benefit from rebar, we want to put it as close to the surface as possible. Unfortunately, concrete is porous, and water can work its way in, come in contact with the steel, and cause it to corrode. This has two effects:
- It reduces the amount of competent steel, weakening the structure.
- The iron oxide corrosion products take up more volume than the original steel. The expansion of the corroding rebar creates an outward pressure on the surrounding concrete, leading to cracking and spalling. This further exposes the rebar, leading to more corrosion in a vicious circle.
To protect the rebar from water infiltration, there are design rules about how far from the surface the rebar must be placed (this is called concrete cover). But as we said earlier, placing the rebar away from the surface makes it less effective in resisting tensile stresses. As in all types of design, there are trade-offs, and here the trade-off is between strength and longevity.
As you may know, salt water is more corrosive than fresh water because of the chloride ions from the dissolve NaCl. So reinforced concrete in coastal environments and northern climates, where salt is used on roadways, is especially susceptible to deterioration from rebar corrosion. If you look up while driving under any number of old reinforced concrete bridges in Chicago, you’ll see plenty of rusted and exposed rebar.
If you want to see Ransome’s work, and are leery of going to the Alvord Lake Bridge (the podcast says it’s in a sketchy section of the park), you can go to the Cantor Center for Visual Arts on the Stanford campus. The original building was built in 1891, just a couple of years after the bridge, and is made of reinforced concrete as designed by Ransome. The building was expanded in the early 1900s, using masonry construction, which was a bad idea. The new wings collapsed during the 1906 earthquake, leaving only Ransome’s work still standing. His part of the building also survived the Loma Prieta earthquake of 1989, the 35th anniversary of which was just a couple of days ago.
By the way, although Stanford’s page about the building says it used “a new method of cast-in-place concrete reinforced with twisted metal rods,” just like the Alvord Lake Bridge, James MacGregor’s well-regarded textbook, Reinforced Concrete: Mechanics & Design, says that while Ransome used twisted bars in other structures, he “used discarded cable car rope as beam reinforcement” in the museum. I don’t know which is correct, but the helically wound wires in cable car ropes would also provide good mechanical interlock.
It took me a while to write this post, mainly because I kept veering off on tangents about Frank Lloyd Wright’s home and office in Oak Park, strain compatibility, the weird belief among some people that Roman concrete was better than today’s, compression-only structures, rebar size nomenclature, and the tendency for concrete to use the waste products of other industries (like flyash and, perhaps, discarded cable car rope). I hope you appreciate how I managed to edit it down.
-
Yes, I know that rebar is also used to resist compression and shear. I’m trying to keep things simple. ↩
Expanding
October 15, 2024 at 10:41 AM by Dr. Drang
Regular readers1 know that I like to watch mathish YouTube videos from Numberphile, Stand-up Maths, and Mind Your Decisions. Unfortunately, this leads YouTube’s machine learning system to believe that I want to watch all math videos, no matter the level or quality. So it keeps pushing dull videos at me in which an overhead camera records the hands and pen of the presenter writing out line after line of elementary math. There are apparently an infinite supply of these things.
Occasionally, one of these videos has something in the thumbnail frame that catches my eye, and I click on it despite myself. Here’s a video I saw last night that pretends there’s a connection between a binomial expansion and Stephen Hawking. What it really does is solve what it says is a problem from a high school entrance exam. No Hawking at all.
The goal is to simplify this expression:
It could be argued that this is already in a pretty simple form—it’s certainly compact—but in this case, “simplify” means to get rid of the exponent.
If you can bear the tedium of the video, you’ll see that its solution goes through some algebra and various levels of substitution. It takes a very long time, and not just because the presenter insists on writing out every little step along the way.2 The entire approach to solving the problem is inefficient.
Because this is an exam problem, getting the solution quickly is important. To my mind, the fastest solution is to expand the binomial directly. I don’t have the binomial coefficients memorized up to the 10th degree, but Pascal’s Triangle can be built in a jiffy:
1
1 1
1 2 1
1 3 3 1
1 4 6 4 1
1 5 10 10 5 1
1 6 15 20 15 6 1
1 7 21 35 35 21 7 1
1 8 28 56 70 56 28 8 1
1 9 36 84 126 126 84 36 9 1
1 10 45 120 210 252 210 120 45 10 1
You know how to put this together, right? Each new row starts and ends with a 1, and the other terms come from the sums of the terms in the previous row diagonally to the left and right, e.g.,
and so on. Because of the symmetry, you only have to calculate about half the terms.
So the expansion of is
where I’ve used identities like
and
to simplify each term in the expansion.
Now we can do the various multiplications and collect the terms with and without the terms to get
which gives us the correct answer:
While there may be some cleverness to the YouTuber’s method of substitution and resubstitution, this is certainly more straightforward and less likely to generate algebra mistakes—both of which are important when you’re under pressure during a test. The main thing to remember is that the odd powers of have negative signs and the even powers don’t.
I suppose it’s unfair for me to insult someone who’s trying to help students, but his slow solution isn’t going to be very helpful. And he shouldn’t pretend that his video has anything to do with Stephen Hawking.
-
Can you be a regular reader of a blog as irregularly published as this one? Discuss. ↩
-
Yes, I realize that this is an instructional video meant for young people and there’s value in a methodical pace. But no one who can follow the math in this video needs to see every single addition and multiplication. ↩
Touch and run
September 24, 2024 at 12:21 PM by Dr. Drang
Here’s one last bit of followup on my Finder/Terminal tool posts. In the first post on the topic, I mentioned that I had created a bunch of zero-length JPEG files using the touch
command. And in both the first and second posts, I talked about how long the sel
command took when there were hundreds of files to select. I thought it worth a post on how I made hundreds of zero-length files to test out the script.
The short answer is this:
run -f 'img-{:03d}.jpg' 500 | xargs touch
which created, in the current directory, 500 files named img-001.jpg
through img-500.jpg
. We’ll turn this into a long answer by going through each part.
You won’t find the run
command on your computer unless you read this post from a few years ago, in which I gave its Python source code. But I used run
because I have it and like it. We’ll get to using commands that are on your computer further down.
The usage message for run
is this:
Usage:
run [options] <stop>
run [options] <start> <stop>
run [options] <start> <stop> <step>
Generate a run of integers or characters. Similar to jot and seq.
Options:
-f FFF formatting string for number
-s SSS separator string
-c characters instead of integers
-r reverse the run
-h show this help message
The run of numbers can be integers or reals, depending on the values of start,
stop, and step. The defaults for both start and step are 1. If -c is used,
then start and stop must both be given as characters and step (if given) is an
integer.
As you can see, I used run
with an -f
option to put each number generated into a string. The formatting code used in the argument to -f
follows the Python format string syntax. Most of the code is repeated verbatim; the part inside the curly braces tells run
to format each number as three characters long with leading zeros, if necessary. The output of the run
command is
img-001.jpg
img-002.jpg
img-003.jpg
.
.
.
img-499.jpg
img-500.jpg
What we want to do is run the touch
command with each one of these filenames as its argument, e.g.,
touch img-001.jpg
The main purpose of touch
is to update the modification timestamp on the given file. But if the file given as the argument to touch
doesn’t exist, a zero-length file of that name is created. It’s this feature we’re going to exploit.
The problem with the way touch
works is that it doesn’t take the filename from standard input—it needs it to be an argument. So we can’t just pipe the output of run
into touch
. Luckily, the xargs
command is available. It constructs an argument list from standard input (the list of img-nnn.jpg
file names) and executes the given utility (touch
) with that argument list. Boom. On my M1 MacBook Air, it takes about a tenth of a second to create all the files.
But run
isn’t necessary. There are two commands already on your Mac, jot
and seq
, that do much the same thing as run
. I wrote run
because I don’t like the syntax of either jot
or seq
, but they’re both fine for this simple case. We can create the same files as above with
jot -w 'img-%03d.jpg' 500 | xargs touch
or
seq -f 'img-%03.0f.jpg' 500 | xargs touch
Both jot
and seq
use printf
-style formatting codes, which are the parts that start with percentage signs. Note that jot
uses -w
instead of -f
as the option and that seq
treats the numbers as floating point values instead of integers. This latter is why its number formatting bit has to be %03.0f
instead of the simpler 03d
. These minor annoyances are some of the reasons I wrote run
.
Unsurprisingly, jot
and seq
are faster than run
, but they’re all so fast I had to use the time
command to learn the difference between them. My preference for the syntax of run
far outweighs its tiny additional runtime.
Update 24 Sep 2024 4:37 PM
Are you surprised to see an update? You shouldn’t be; there’s always more than one way to do it. In this case, the additional way was suggested by Jonathan Buys on Mastodon and it uses brace expansion:
touch img-{001..500}.jpg
No need for piping. Although I’ve linked above to the bash manual, the brace expansion works in zsh, too.
For me, there are a few downsides to this:
- I find it hard to remember brace expansion (although I may find it easier after writing this).
- When I do remember brace expansion, I tend to use a hyphen between the numbers instead of a pair of periods, and that doesn’t work at all.
- I like to double-check the filenames before creating the files, and I can issue the
run
command by itself to make sure the names are what I want before adding the pipe toargs touch
.
Now, it’s true that the Jonathan’s brace expansion solution can be checked by running something like
echo img-{001..020}.jpg
to check the file names (in this case, there’s no need to generate all 500) before reissuing the command with touch
instead of echo
, so there’s more than one way to run a test, too. Thanks to Jonathan for the suggestion!
Improved Finder/Terminal tools
September 20, 2024 at 4:32 PM by Dr. Drang
A couple of days ago, I got an email from Loren Halter, who had some improvements to my Finder/Terminal tools. I was going to add another update to that post, but realized I had more to say about Loren’s stuff than would fit comfortably in an update. So here we are with a new post.
First, Loren put his work in this gist, so you can review and copy them for your own use. There are three functions Loren includes in their .zshrc
dotfile1 to ease the use of the Finder and Terminal together. They are lsf
, cdf
, and sel
, and we’ll go through each of them in turn.
lsf
is a variant of the ls
command that lists, in the Terminal, the contents of the front Finder window. I can’t say that I foresee myself using this function, as the Finder window itself shows its contents. Presumably, Loren uses this to feed a list of file names to another command, but I prefer doing that sort of thing with my Terminal’s working directory set to the directory that contains the files of interest; in such cases, ls
suffices. But it may be just the thing for you.
Next comes cdf
, which changes your working directory to that of the front Finder window. It is essentially the cd
command combined with my ;dir
abbreviation. While it’s not a huge timesaver, I do this combination enough that I decided to add it to my .bashrc
. As I was scrolling through the file to find a good place to put it, I found a function called cdff
, which was apparently a long-forgotten attempt on my part to do the same thing (I assume the ff
part meant “front Finder”). I won’t show it to you, because both the AppleScript and shell scripting aspects of it were a horrible mess. I suspect it didn’t even work, which is why I don’t remember anything about it.
Anyway, I decided to take Loren’s idea for cdf
and make my own version of it:
bash:
1: function cdf() {
2: target=$(osascript -e 'tell application "Finder" to return POSIX path of (target of front Finder window as alias)')
3: cd "$target"
4: }
Comparing Loren’s version with mine, you’ll see the error handling code in theirs that I’ve not included in mine—I’m just an outlaw, I guess. What I wanted was for my cdf
to work exactly as combining cd
with ;dir
would, and I don’t really see much danger in not including the try/on error
code.
(What Loren’s code handles that mine doesn’t is the case in which there are no open Finder windows. Loren’s cdf
will then cd
into the Desktop folder; mine will belch out an error message. I don’t want that protection because my goal is to never work in the Desktop directory. In my experience, doing so, even “temporarily,” leads to a clutter of files on the Desktop that sit there far longer than they should. If you’re more disciplined than I am, by all means, use Loren’s version.)
Which leaves us with sel
. I mentioned in my earlier post that my version of sel
could take several seconds to run if it’s selecting hundreds of files. In my tests, Loren’s code runs in about a third of the time as mine. That considerable reduction in runtime came from changing the way AppleScript constructs the list of files to select. You may recall that my version of sel
generates AppleScript that looks like this
applescript:
tell application "Finder"
set theFolder to target of front window as alias
set theFiles to {}
tell folder theFolder
set end of theFiles to file "20240915-001.jpg"
set end of theFiles to file "20240915-002.jpg"
set end of theFiles to file "20240915-003.jpg"
set end of theFiles to file "20240915-004.jpg"
set end of theFiles to file "20240915-005.jpg"
set end of theFiles to file "20240915-006.jpg"
set end of theFiles to file "20240915-007.jpg"
set end of theFiles to file "20240915-008.jpg"
set end of theFiles to file "20240915-009.jpg"
set end of theFiles to file "20240915-010.jpg"
end tell
select theFiles
return
end tell
and then runs it. Loren’s sel
generates AppleScript that looks more like this:
applescript:
tell application "Finder"
set theFiles to {}
set end of theFiles to POSIX file "/Users/drdrang/Library/Mobile Documents/com~apple~CloudDocs/blog-stuff/finder-terminal/20240915-001.jpg" as alias
set end of theFiles to POSIX file "/Users/drdrang/Library/Mobile Documents/com~apple~CloudDocs/blog-stuff/finder-terminal/20240915-002.jpg" as alias
set end of theFiles to POSIX file "/Users/drdrang/Library/Mobile Documents/com~apple~CloudDocs/blog-stuff/finder-terminal/20240915-003.jpg" as alias
set end of theFiles to POSIX file "/Users/drdrang/Library/Mobile Documents/com~apple~CloudDocs/blog-stuff/finder-terminal/20240915-004.jpg" as alias
set end of theFiles to POSIX file "/Users/drdrang/Library/Mobile Documents/com~apple~CloudDocs/blog-stuff/finder-terminal/20240915-005.jpg" as alias
set end of theFiles to POSIX file "/Users/drdrang/Library/Mobile Documents/com~apple~CloudDocs/blog-stuff/finder-terminal/20240915-006.jpg" as alias
set end of theFiles to POSIX file "/Users/drdrang/Library/Mobile Documents/com~apple~CloudDocs/blog-stuff/finder-terminal/20240915-007.jpg" as alias
set end of theFiles to POSIX file "/Users/drdrang/Library/Mobile Documents/com~apple~CloudDocs/blog-stuff/finder-terminal/20240915-008.jpg" as alias
set end of theFiles to POSIX file "/Users/drdrang/Library/Mobile Documents/com~apple~CloudDocs/blog-stuff/finder-terminal/20240915-009.jpg" as alias
set end of theFiles to POSIX file "/Users/drdrang/Library/Mobile Documents/com~apple~CloudDocs/blog-stuff/finder-terminal/20240915-010.jpg" as alias
select theFiles
return
end tell
Now, I think my code is more elegant looking, and it takes advantage of some nice AppleScript features; but again, Loren’s runs in about a third of the time. Loren believes this speedup comes from his code using the full path to each file, eliminating the work AppleScript has to do in the tell folder
block of my code. I agree.
When faced with the choice between elegant but slow autogenerated code that no one sees and cruder but speedy autogenerated code that no one sees, I know which one I’m going to take. I still preferred having sel
as a command script rather than a function, and I also wanted it written in my style to make it easier to update if necessary. So I incorporated Loren’s insight into my sel
, giving me this:
bash:
1: #!/bin/zsh
2:
3: # Open Finder window to the current directory and select all the files
4: # in that directory whose names are passed to this script via stdin.
5:
6: # Open a Finder window to the current directory.
7: open .
8:
9: # Construct the AppleScript in three parts.
10: # 1. Initialize variables and start telling theFolder.
11: applescript='tell application "Finder"
12: set theFiles to {}
13: '
14:
15: # 2. Add all the files from stdin to theFiles list
16: while read f; do
17: thisFile="$PWD/$f"
18: applescript+=" set end of theFiles to POSIX file \"$thisFile\" as alias
19: "
20: done
21:
22: # 3. Stop telling theFolder and select theFiles. Return nothing.
23: applescript+=' select theFiles
24: return
25: end tell'
26:
27: # Run the AppleScript.
28: echo "$applescript" | osascript -
The key is in Lines 17–18, where the full path to each file is assembled using the PWD
environment variable.
Again, Loren’s code has error handling that mine doesn’t, although in this case the error handling basically just throws up a dialog box telling you what the failure is. In my sel
, error messages are printed in the Terminal by the system.
Thanks to Loren for the code improvements and a better understanding of AppleScript.
-
I think they’ll all work just as well from a
.bashrc
file if you’re a stick-in-the-mud like me. ↩