The 9/11 Forum

Dealing with the Hat Truss

Simplest thing is to make its contribution be global sharing. It would be possible to distribute according to what's hanging and what's supporting, and maybe down the road that will happen. To start, it would be advantageous to have all force directed downward, where a moment calculation could provide tension, however slight and short lived. At any rate, a non-uniformly distributed load from considering unbalanced damage is probably a second order correction, so let the hat truss apply deficit loads uniformly or (more conservatively) apportioned by capacity of remaining columns.

Harder to be loose with terminology now. The hat truss is clearly a member, and an element of the model. But it isn't a column. Is it a fiber? A very special fiber, if so.

Its function can be reduced to two parameters: 1) the proportion of load failed columns transmit to it versus neighboring columns (a scalar), and 2) whether redistribution is equal to all columns or scaled according to their current capacity (a choice). The use of booleans, conceptually, is sometimes a problem because of misclassification of two-valued enumeration types as bools. It would be in this case also, because it isn't really uniform and not-uniform, it's uniform and by current capacity. Then it's seamless to add more possibilities like 'by design capacity' and even 'by quadrant' and so on by using an enum.

This is a very powerful visual tool. In the example you are using, I assume columns of equal strength and loading and of course in a 10x10 grid. The core had less than half the number of columns and they were very different in size/strength.

Here are the relative areas of the columns on floor 80 in sq ft.

1.61 0.98 1.18 0.86 0.77 1.17 0.98 1.61
0.55 0.61 0.57 0.55 0.55 0.57 0.61 0.55
0.63 0.63 0.39 0.16 0.14 0.37 0.67 0.58
0.55 0.75 0.42 0.33 0.32 0.58 0.58
0.55 0.65 0.57 0.39 0.36 0.58 0.58 0.55
1.65 1.02 1.35 1.21 0.72 1.23 1.02 1.65

The unequal column size must be related to inside the core floor loads (shafts vs occupancy-toilets, tenant use, corridors) Just a guess.

I could do the calcs for the 93rd floor and see if the ratios change.

SanderO wrote:This is a very powerful visual tool.

Thanks. It looks like a cartoon, but it has a lot more in common with a simulation than a simple illustration. It basically carries forward the same sort of process you followed with your diagram. Because it does all the work, it's a snap to make the rules a bit more complex and still quickly get a result.

In the example you are using, I assume columns of equal strength and loading and of course in a 10x10 grid.

Yes. It's a starting point for testing.

The core had less than half the number of columns and they were very different in size/strength.

Here are the relative areas of the columns on floor 80 in sq ft.

Excellent, thank you. This is exactly what I'm looking for.

The unequal column size must be related to inside the core floor loads (shafts vs occupancy-toilets, tenant use, corridors) Just a guess.

Question: is the most realistic initial condition to have the imposed loads match capacity? Stronger columns take up more?

I could do the calcs for the 93rd floor and see if the ratios change.

Very good.

One assumes that the engineer sizes the columns for the axial loads with a margin of safety (chosen FOS) and architectural considerations. The latter is less of an issue with interior tenant spaces, but it could drive column dimension and form in columns adjacent to shafts.

Clearly the FOS value drives the total amount of steel and the developers are looking for cheap and the engineers are looking for strength (more FOS - larger columns) and the architects are looking for small (usually).

I think one can assume the FOS was relatively uniform from top to bottom... and the typical floor loads were the same from top to bottom as well... mech floors being the exception.

The core steel was reportedly all ASTM A 36 but the with the facade they had to use stronger steel up top for a thinner wall thickness up top. This was because the facade columns were dimension constrained to 14x14 and so as the wall thickness increased the void inside grew smaller and smaller and became too small for the proper bolt spacing. Hence the stronger, thinner plates for the facade box columns with sufficient void inside on the lower floors to accommodate the bolts.

SanderO wrote:One assumes that the engineer sizes the columns for the axial loads with a margin of safety (chosen FOS) and architectural considerations.

Okay, so the initial distribution will be ideal load/capacity matching for uniform FOS. Then the redistribution after failures can take various forms.

Finally looks like I have a reason to be interested in the FEMA WTC Performance Study. My linear approximation of capacity reduction vs temperature should probably be adjusted.

SanderO wrote:Here are the relative areas of the columns on floor 80 in sq ft.

1.61 0.98 1.18 0.86 0.77 1.17 0.98 1.61
0.55 0.61 0.57 0.55 0.55 0.57 0.61 0.55
0.63 0.63 0.39 0.16 0.14 0.37 0.67 0.58
0.55 0.75 0.42 0.33 0.32 0.58 0.58
0.55 0.65 0.57 0.39 0.36 0.58 0.58 0.55
1.65 1.02 1.35 1.21 0.72 1.23 1.02 1.65

Just from looking at these values, I already get the sense that a naive local redistribution scheme is going to avalanche like crazy. There are pronounced mismatches in adjacent columns, like 1.65/0.55 and 0.55/0.14. Suppose a corner (1.65) fails and 30% of its load is transferred to the hat truss and the remaining 70% go 30/30/10 to edge/edge/inner-corner. A nominal load for the corner is 1.65/0.55 = three times greater than for the 0.55 edge column. The portion transferred under this scheme would be 3 x 0.3 = 0.9 times the nominal load the edge column is meant to bear. Since it starts with a matched design load, the corner failure takes it up to 1.9x design load. If the FOS is 2, it's on the verge of failure.

Mild heating, and it goes. It originally had five nearest neighbors, now down to four from the corner loss, and two of those have already picked up load from that failure. It's easy to see how a quick cascade can remove a region, and how decent stability is going to have major hat truss involvement. The more large-scale the redistribution, the less susceptible to cascade.

The four corners are the big kahunas. Tower 1 had the corners spared and only three or four of the columns in the center of the long row went *away* from the plane strike similar to what my cartoon shows. Tower 2 was quite different if you look at what NIST claims. It lost 3 at the corner including a big kahuna.

Notice that in the progression to total core failure the last few columns bend over and become the horse shoe shapes obviously still well connected at both ends... just acting like noodles.

Do you know off the top of your head which ones went noodly? Just curious.

Negative on the noodles. I'd be surprised if NIST didn't log this somewhere.

I've attached a cartoon of the core columns on floor 80. All have been rotated to the same flange orientation which is NOT how they were in the building. I've put the 80th floor facade column/panel in for comparison and shown where the shafts were located with hatches. I believe the horse shoe column was a rolled wide flange section. My guess is that the horse shoe is 702, 703 or 802.

All the buckled core columns I've remember seeing in photos were rolled sections. My memory is hazy on this.

Very nice, thank you. Not sure what to make of the information; like I say, just curious.

There's an old programming adage, 'You should always throw the first one away." My philosophy is, you should throw away at least the first two, and more if possible. Well, I threw the first one away, and here's the second one.

Still frame in progress:


Attached also is a huge (~2MB) gif which shows the whole process in animation. The trial was simple random amount of damage applied to random columns on each step. Load sharing is global. T, P, and C character annotations on the bar graph refer to Total, Core and Perimeter.

Very cool! You really can't consider the facade columns as individuals. First the trusses were connected to every other column... but more importantly they acted as triple because the the spandrels. If you run the sim again combine 3 facade columns and treat them as one.

The failure was surely less random... beginning with the taken out columns from the plane impacts. The whatever fires were in play would be localized and spread... but not across the shafts... which is why I supplied the last layout. Floor 80 had all local shafts as all local cars up there departed from 78.

If there were fires burning in the core it would have to be supported by floors I would assume. The fire could follow the main corridors and local elevator lobbies... but there were not many combustibles in them I would think.

I suspect that the core failure was about the 24 perimeter columns anyway. These were the columns supporting the OOS flooring... and adjacent to the area where combustibles would be found including pooling of fuel and fuel soaked carpets and furniture.

Interesting how the rapid onset occurs. I run it a bit slower with some sort of clock. But it's very instructive of how a tube in tube structure can go from standing to global failure in an instant. Calling Richard Gage, calling Richard Gage... rapid onset of collapse is not ONLY seen in controlled demolitions.

SanderO wrote:...Interesting how the rapid onset occurs. I run it a bit slower with some sort of clock. But it's very instructive of how a tube in tube structure can go from standing to global failure in an instant. Calling Richard Gage, calling Richard Gage... rapid onset of collapse is not ONLY seen in controlled demolitions.

My engineering "gut feeling" tells me that tube in tube is more vulnerable to cascade failure and the characteristic exponential runaway. Don't ask me to prove the point - my brain is miles behind the "gut feeling".

Ozzie,

I think what happens in the tube in tube .... in the case of the twins... the rapid core collapse up top essentially created the ROOSD mass. And ROOSD mass loves OOS floors... much more than the grided column arrangement like the Sears towers which I suspect would never go ROOSD from a plane strike on the 93rd or the 80th floor.

Don't ask me to prove the point - my brain is miles behind the "gut feeling".

SanderO wrote:Very cool! You really can't consider the facade columns as individuals.

I could see the deficiency there.

First the trusses were connected to every other column... but more importantly they acted as triple because the the spandrels. If you run the sim again combine 3 facade columns and treat them as one.

Yes, that can be done. Even gradations more true to the real thing, where the triplets are very strongly coupled but still distinct and capable of some diffential action, all controlled by variable settings or logical functions.

The failure was surely less random... beginning with the taken out columns from the plane impacts.

This was the first full run of the new program so I opted for random but regular input. Scared up some bugs along the way. Regular input, with variations, is good for that. Think of the trial above as a test pattern.

A lot of things need to be incorporated, starting with simple local load sharing, then hybrid complex local/global sharing via the hat truss. Then more sophisticated and meaningful methods of applying damage and affecting capacity like fire maps, lateral support loss, and so on. Then, explicit introduction of floors in some way, either as elements or nested within their own distinct, parallel sub-simulation. List is long.

The whatever fires were in play would be localized and spread... but not across the shafts... which is why I supplied the last layout.

Excellent. The development of heating effect routines will be a multiphase effort (everything here is iteratively evolving). It would be nice to be able to program fire behavior in a variety of ways. I'm thinking about capturing the NIST fire/temp maps and using them as input.

Fire patterns are (more than) one step removed from the ultimate goal, which is capacity changes over time. Fire drives heating, but the relation between fire conditions over time and the resulting temperature distribution over time is very complex and has high uncertainty. The ideal relationships between temperature and capacity are only a rough approximation, too. Then, other things besides heat reduce capacities. There are many paths to one capacity value at a specific time.

Right now, the model supports setting capacities in any arbitrary way at any step, but there's no logic feeding that process yet, hence the random capacity reductions of the previous run; very easy. I have to program some additional stuff to do more interesting damage patterns. I can easily specify column loss manually as part of the initial conditions or target certain columns on particular steps. So the plane damage will be easy. Targeted capacity loss by region, with or without a random component, is a little more work but you could see I had the beginnings of it in the first program.

The important thing at this stage was to complete a solid and flexible framework for plugging in custom behavior as it's later developed. Everything feeds the capacity values, and the capacity values drive the evolution of the system. Now the engine is in place to orchestrate and execute the process, almost anything can be plugged in. All takes time of course.

Interesting how the rapid onset occurs.

Isn't it? It is by its nature always an accelerating process. When it gets towards the end, the self-reinforcing feedback (fail -> capacity loss -> redistribution -> fail) explodes.

I run it a bit slower with some sort of clock.

Ah, there's a sticky part. Right now, it is nearly atemporal. All it has concerning time is strict ordering of the steps; that is, the order of steps follow the arrow of time, but whatever time interval occurs between steps is unspecified and is virtually guaranteed to vary from step to step, perhaps by many orders of magnitude. Depends on the thing being modeled and the properties assigned to it. More in a later post.

In order to "slow this down" natively, without introducing the dimension of time at all, I can slow the amount of capacity reduction at steps approaching the critical threshold. This will produce smaller avalanches of failures at each step and draw out the process somewhat. Still can't call it time. Yet.

But it's very instructive of how a tube in tube structure can go from standing to global failure in an instant. Calling Richard Gage, calling Richard Gage... rapid onset of collapse is not ONLY seen in controlled demolitions.

It is very instructive and this is one of the premiere features of cascading failure. One or more quantities grow dynamically. Mass/momentum with a snowball effect, size and scope with network failure and domino chains, or rapidity of failure about a critical point like in this type of model.