Diagnosing the Steel Failure in the SF Transit Center | Hacker News Reader

Diagnosing the Steel Failure in the SF Transit Center

popularmechanics.com

91 pointsgumby34 comments

I worked briefly as a bike mechanic and spent some time working on old cars. During that time picked up a mild fascination with failure analysis and one or two tricks.

If a bolt or a flange fails, you can look at the oxidation patterns and see if the failure happened all at once or over time. Most of the times I encountered a piece of metal where only half of the fractured surface was shiny, indicating that this piece has been failing for quite some time. It's a bit unsettling to think about how many fasteners around you might be in that state so I... don't. But there virtue in disassembling and reassembling old equipment, and inspection is certainly part of that.

My buddy in college was in the ME program and he came to me excited one day because he'd just learned about metal failure and figured out why airplane structural members have so many holes in them. Weight, of course, but also it turns out the shockwave when a crack starts can propagate the crack, not unlike how breaking 5 boards karate style is only about 2x as hard as breaking one. If that force hits a hole in the material it travels around the circumferences and it acts more like a spring. Thus drilling a hole in the end of a crack to stop it.

So a localized flaw in the wrong spot in the material can start a fracture, and spread into material that's up to standards.

If I remember my physics at all, there's more torque on the end of the beams, so in theory a crack could start anywhere but it might be more likely near the ends. Still, a crack that close to a weld seems pretty sketchy. If I saw that in a bike, I'd presume the metal was damaged in the assembly process. I encountered cases of both materials defect and manufacturing defect. In particular a case of bad epoxy from Trek (assembly) a couple years before excessively anodized aluminum rims showed up on Cannondales (material defect).

It's so crazy how something as subtle as the order of welds and whether they ground the welds would so dramatically affect the strength of huge structural components.

Steel is funny stuff; you do everything right but one thing, and that bites you. But unlike the FIU bridge disaster the building was designed with proper safeguards so that one flaw would not knock the whole thing down. Read the FIU report, it's very interesting. I always try to write code assuming something somewhere will break, at least you want it to do nothing harmful not matter what. With large real world projects, failure can kill people very easily, and being redundant is a real requirement, not a nice to have. From a steel standpoint I marvel at the Brooklyn Bridge, almost 150 years old, and has less issues than any other NY bridge.

My memory might be wrong, but wasn't the Brooklyn Bridge built when steel was still a relatively new thing? Its properties weren't entirely understood, or even well understood, so as a result, it was tremendously over-built.

Now, everything is about how little material you can use, how close to the minimums you can get and still maintain a theoretical factor of safety. The problem is that in doing so, small mistakes have a much bigger impact.

I am not a structural engineer, but have close friends who are pretty senior. In a long conversation one night, we spoke about this. He said there is a pull towards using less material / close to the minimums, driven by the builder. But the engineering team has final say (modulo their customer finding another shop).

Most relevant, he said in his experience, everything is still overbuilt. They engineer it to meet spec, then add in safety factor of 2-8x. (Said safety factors are also part of the specification, interestingly! What if software estimates had a specific set of fudge factor guidelines like this?)

I think the other posters usage of overbuilt implies exceeding a reasonable safety factor.

The begs the question: what is a reasonable safety factor? My structural eng friends say they disagree all the time with the builders on that front. They even disagree with each other.

The difference between physical engineering and computing is that their world is unknown, while ours is known.

Both of these subject to individual exceptions, but broadly true.

You can't request a steel or wood beam and then say "Here are its exact properties".

You can instatiate a class of MyFooType and say "Here are its exact properties".

In that sense, physical engineering is essentially a Bayesian approach, where reality is always unknown. But with high probability greater than some number of deviations from the mean.

Source: architecture / BC major before CS

Respectfully, I strongly disagree. Software components, in isolation, may be understandable. Software systems are significantly more complex and often have completely unexpected properties.

Not to dismiss the challenges of physical engineering, but as you say -- it's essentially Bayesian, with very strong priors available. Physical reality, on the human scale, can be comprehended with relatively straightforward equations, mod some fudge factor. We can account for the unknowns in the physical world with that; whereas software's complexity isn't limited to linear changes -- complexity can quickly grow exponentially.

Shared this with the engineers and programmers at my company. They all had a good laugh.

Software is deterministic. Reality is not. Engineering is significantly harder than programming, and programmers have only themselves to blame for not properly handling failure modalities.

No harm intended to the GP's feelings, but glad someone got a chuckle.

I feel really bad for the poor (insert variety of) biologists on here.

I think we're using different meanings for software. I'm using it to include all things around building software -- requirements gathering, writing, shipping, maintaining, ops, deployment, etc.

Software is not predictable. That's why nobody can accurately predict how long a project will take.

Software is predictable compared to reality because every part of it is deterministic, or can be programmed to be deterministic.

The fact that most programmers are incapable of properly coding their software to be deterministic says more about the quality of the programmer than the difficulty of the field.

Reality doesn't have to be deterministic to be predictable. Software components can be (theoretically) deterministic and still have unpredictable behaviors in complex systems.

The fact that these welders didn't clean the acetylene edges doesn't mean that this outcome was unpredictable. Wouldn't it say as much about the welders as the difficult of the field?

https://en.m.wikipedia.org/wiki/Nondestructive_testing

As I heard it, "Anyone can build a bridge that doesn't fall down, it takes an engineer to build one that barely doesn't fall down."

The Brooklyn Bridge started construction in 1869. The Bessemer Process for producing steel was the hot, new disruptive technology making large steel bridges feasible. Early mills attempting to use the Bessemer process routinely failed to make quality steel, so there was a level of distrust and high safety margins were well warranted.

Wikipedia has a list of bridge failures curated by inexplicable means. As I scan from the 1800s into the 1900s I see failures of iron bridges, but it isn't until 1907 (a lifetime of engineering after the Brooklyn Bridge) that I see a steel bridge fail during normal conditions, and that is during construction. (Not having a support washed out or a being struck by a steamer.)

Yes, during construction, a combination of the recommendation of one of his most trusted collaborators, William Paine (also a civil war brother in arms of Washington Roebling), and the fact that the sponsors were contemplating running Pullman train cars across the bridge led to the unprecedented decision to go 100% steel.

As an aside, Washington Roebling's father was remembered as a great engineer, but he was also an incredibly abusive and cruel husband and father, leaving Washington with significant psychiatric sequelae that affected him throughout his life:

https://www.nytimes.com/2017/08/08/books/review/erica-wagner...

Yes, I remember hearing that they had to convince the public it was safe by having elephants cross it first.

I looked it up, and it turns out that there was an elephant march, but it was delayed until long after the (for-humans) opening, but still was a big spectacle:

https://ephemeralnewyork.wordpress.com/2011/12/22/the-elepha...

The Eads bridge[1] is also an example of a very early (opened in 1874) use of steel. I don't know about how over engineered it is, but it is still used for automobile and light rail today.

[1] https://en.wikipedia.org/wiki/Eads_Bridge

Bad steel in the Brooklyn Bridge was caught by Robeling before it was too late. The scandal brought down the Tweed Ring.[1]

[1] https://erenow.net/common/the-great-bridge-the-epic-story-of...

On things like wind towers, every inch of weld is inspected, not just visually, using methods like ultrasound.

Completely non-intuitive to me how the polishing of a hole could prevent cracking (and was not done properly).

But then reading below how drilling a hole at the end of a crack to prevent it propagating, maybe it has to do with that concept.

It doesn't prevent cracking, it removes microcracks that are already there. Martensite may not literally be a hole in the metal, but it has many of the same properties.

It's interesting how stuff like this works out - this looks like it was resolved in a fairly simple way, no epic lawsuits, just an analysis, and then a fix.

San Francisco builders have a lot of experience in beefing up structural support in existing buildings. All but 20 of the unreinforced masonry buildings in San Francisco were reinforced by 2014. Unfortunately nine of them are at SF General Hospital.

> SF General Hospital

I'm sure Zuck has a couple more bucks he could throw there.

Another reason why SF declared no confidence in the TJPA is that they somehow managed to accrue liability for the Millennium Tower (a.k.a. the Leaning Tower of SOMA) even though that disaster was clearly caused by the property developer’s cutting corners on the foundation.

Wondering if there’s a way to learn more about how they modeled the brittle crack growth

Not my area of expertise - I did two semesters of solid mechanics as part of my engineering degree 10 years ago. All I really remember is hoop stress and Kic

The wikipedia article on Fracture mechanics (https://en.wikipedia.org/wiki/Fracture_mechanics) seems to be pretty good - explains some of the mathematics involved - which is a start towards modelling it. See section on predicting crack paths.

You'd also need to know how the structural member was loaded and it's geometry - software like ANSYS is used for modelling this.

This is what happens when non-engineers try to do engineering related things. There's a lesson here for all the not-coms in SF pretending to be software companies.

What a colossal waste of tax payer money - not that SF or the wider general California population care.

Pretty sure that the engineers involved in the project were all working for top tier firms in their respective domains. How is your comment at all relevant?

The article even lists them and their corporate pedigrees.

You're right. This project was doomed from the moment Mark Benioff sat his massive ego down in front of an AutoCAD session to design it!

(/s, just in case)

Reply on news.ycombinator.com