
Diagnosing the Steel Failure in the SF Transit Center - gumby
https://www.popularmechanics.com/science/a29329189/salesforce-transit-center-cracks/
======
hinkley
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).

------
ogre_codes
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.

~~~
coldcode
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.

~~~
fotbr
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.

~~~
edmundsauto
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?)

~~~
ethbro
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

~~~
edmundsauto
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.

~~~
gamblor956
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.

~~~
edmundsauto
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.

~~~
gamblor956
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.

~~~
edmundsauto
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?

~~~
ethbro
[https://en.m.wikipedia.org/wiki/Nondestructive_testing](https://en.m.wikipedia.org/wiki/Nondestructive_testing)

------
supernova87a
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.

~~~
Filligree
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.

------
Aloha
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.

~~~
Animats
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.

~~~
pstuart
> SF General Hospital

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

------
fmajid
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.

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

~~~
bigger_cheese
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](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.

------
dgoog
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.

~~~
whalesalad
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?

~~~
gumby
The article even lists them and their corporate pedigrees.

