"Inside Job": Hidden energy in reports by Prof. Bazant, Dr. Greening and D. Thomas

I see the forum supports (some) HTML. Non-breaking spaces give indent. Next post I'll try HTML instead of BBCode since they don't mix well. Like I can't get Courier font now.

The initialize method for the class (equivalent to C++ constructor):
[color=#349d58]03 [color=#fca8ad]def [color=#b4e09f]initialize[color=#b0b0b0](height[color=#b0b0b0], stretch[color=#b0b0b0], block[color=#b0b0b0], stories)
[color=#349d58]04    [color=#0490e8]@height [color=#b0b0b0]= height[color=#b0b0b0];
[color=#349d58]05    [color=#0490e8]@stretch [color=#b0b0b0]= stretch[color=#b0b0b0];
[color=#349d58]06    [color=#0490e8]@block [color=#b0b0b0]= block[color=#b0b0b0];
[color=#349d58]07    [color=#0490e8]@stories [color=#b0b0b0]= stories[color=#b0b0b0];
[color=#349d58]08    [color=#0490e8]@distance [color=#b0b0b0]= [color=#b4e09f]dropDistance[color=#b0b0b0](height[color=#b0b0b0], stretch)[color=#b0b0b0];
[color=#349d58]09    [color=#0490e8]@compacted [color=#b0b0b0]= [color=#0490e8]@stretch [color=#b0b0b0]* [color=#0490e8]@height[color=#b0b0b0];
[color=#349d58]10    [color=#0490e8]@block_height [color=#b0b0b0]= [color=#0490e8]@block [color=#b0b0b0]* [color=#0490e8]@height[color=#b0b0b0];
[color=#349d58]11    [color=#b4e09f]puts[color=#b0b0b0]([color=#5c78f0]"nFloors,t,crush_y,v,B_thickness,roofline")[color=#b0b0b0];
[color=#349d58]12    [color=#b4e09f]step[color=#b0b0b0]([color=#4580b4]0.0[color=#b0b0b0], ([color=#0490e8]@stories [color=#b0b0b0]- [color=#0490e8]@block)[color=#b0b0b0]*[color=#0490e8]@height[color=#b0b0b0], [color=#4580b4]0.0[color=#b0b0b0], [color=#0490e8]@block)[color=#b0b0b0];
[color=#349d58]13 [color=#fca8ad]end


It's also the entry point for execution, the only method called outside the class. Just create an instance of Collapse and it starts to run, putting results to the terminal/console.

Lines 4-7 set the parameters.

Lines 8 - 10 calculate three internal data members: distance, compacted and block_height. These are convenient to precalculate because in this scenario they don't change. Distance is the distance to collision which is story height minus compacted height. The compacted variable is the squashed height of a story. The block_height is just the height of the upper block in meters.

Line 11 writes a header for the CSV output to follow.

Line 12 is the meat, the first call to step with the initial arguments. After this, it recurses until termination.

So much for HTML formatting. The forum supports very little.

On to the next method, step:

[color=#349d58]14 [color=#fca8ad]def [color=#b4e09f]step[color=#b0b0b0](t[color=#b0b0b0], y[color=#b0b0b0], v[color=#b0b0b0], nFloors)
[color=#349d58]15     b_thickness [color=#b0b0b0]= (nFloors [color=#b0b0b0]- [color=#0490e8]@block) [color=#b0b0b0]* [color=#0490e8]@compacted[color=#b0b0b0];
[color=#349d58]16     roofline [color=#b0b0b0]= y [color=#b0b0b0]+ b_thickness [color=#b0b0b0]+ [color=#0490e8]@block_height
[color=#349d58]17     y [color=#b0b0b0]= [color=#4580b4]0.0 [color=#fca8ad]if y [color=#b0b0b0]= [color=#0490e8]@stories[color=#b0b0b0];
[color=#349d58]23     [color=#b4e09f]step[color=#b0b0b0](t [color=#b0b0b0]+ td[color=#b0b0b0], y [color=#b0b0b0]- [color=#0490e8]@height[color=#b0b0b0], postVelocity[color=#b0b0b0], nFloors [color=#b0b0b0]+ [color=#4580b4]1)[color=#b0b0b0];
[color=#349d58]24 [color=#fca8ad]end

This method calculates the dynamics of an inelastic collision between slabs. Slabs are an idealization of an already crushed story. So the stretch parameter could've been called slab height, but it's better to keep the terminology consistent with Bazant, plus retain the true meaning. Later, if you want to run more complex models, where stretch really means stretch, this keeps it consistent all the way through.

Explanation to follow. Please note that I had to change square brackets to parentheses because of BBCode parser error in line 18. The six values separated by commas and suffixed with join should be grouped in brackets. Because of this, the code above cannot be executed, but the original full listing before is correct.

Now getting a little more annoyed that the forum isn't good for posting this stuff. I should have just linked to it elsewhere and I believe I will.

Originally posted by buddhasystem
What I haven't seen so far in this thread is actual coupling between the floors due to columns running the height of the building and being rather violently deformed. When you forcible move columns around, it's simply impossible that the integrity of various connections of structural elements on a few layers below would somehow persist.

Sure enough. The thread is focused on an alleged error by Bazant, naturally straying here and there. But there's little doubt that floor assemblies were wrenched free by distortion.

On a sad note, I witnessed the collapse myself. To me it looked like peeling a banana. If the columns are being peeled away, I can't imagine you can consider the strength of the next layer at the nominal level.

Even though I've looked at hundreds(?) of videos, some of them hundreds of times, I don't envy you. I think I'd be scarred for life if I saw it in person.

Method step.

The arguments to this method are:

t: current step time
x,v: the dynamic quantities x and v for the leading position of the crush front
nFloors: number of stories currently crushed plus count of stories in upper block

Line 15 calculates the current thickness of the debris zone.
Line 16 calculates the position of the roofline.
Line 17 is just to rectify small y to zero for clean graphing purposes
Line 18 outputs the record of calculated data for the current step
Line 19 calculates the time to freefall the distance between slabs
Line 20 calculates the velocity immediately prior to collision
Line 21 calculates the velocity immediately following collision, assumed to be fully inelastic
Line 22 tests for completion (all lower stories crushed) and terminates the recursion if yes
Line 23 calls the enclosing method recursively with the updated values

Remarks:

A rigid top is used. A LOT of people have a problem with that, for reasons both good and bad. Just accept for now that it's a good enough approximation and that starting with a two degree of freedom model not only complicates things tremendously, but once you've gotten to that point, you see that all that effort doesn't buy much. Bazant used this simplification for the same reason, but do see Bazant & Le for rigorous justification of the rigid top.

This script only models the crushdown phase. It ends when the crush front reaches ground, leaving the rigid top there still intact (but with high velocity!)

You'll notice this script has no test for arrest. That's because, in this simple model, there is no structural resistance and so there will be no arrest. It's momentum-only, exactly like Greening's first set of calculations in his paper before adding E1 (energy to crush one story). Since momentum transfer alone can't arrest, no need to test for it. Inelastic collisions dissipate a hell of a lot of energy in this case, so much so that a "weak" building's collapse dynamics is dominated by it and not structural resistance.

The step- or story-wise approximation is valid, as opposed to a continuum formulation, because of the assumption of no momentum transfer to the intact stories below, only the impacted story. This is not strictly true but good enough for the government (literally).

The incorporation of stretch (or finite slab thickness) means that the coordinate of the crush front jumps ahead discontinuously following collision, which makes sense: another story has been swept up, and now the bottom of that story is leading the way.

Originally posted by Akareyon
Haha, that's the problem. Commodore 64 BASIC V2.0 and POV-Ray script, that's all (quite mighty, though!).

But I guess I'll understand fake code or some Java pidgin so I can translate.

By the way, I once had a C64 (great machine) and I've done a lot of POVRay, just not recently. POVRay is bitchin'.

------------

As to the rest of the class Collapse, there are a few helper methods to do calculations and that's it. The rest of the script sets example input and runs.

The point of all this is that a teeny bit of code recreates Greening's momentum-only calculations with the added parameter of stretch, and comes within a rat's ass of Bazant's results without breaking a sweat. Stretch is very nice to introduce at an early stage because it's so easy and it really does affect the dynamics (see graphs). Besides, of all the unrealistic simplifications, having infinite compaction is probably the most absurd.

Here are graphs of some sample output, varying the stretch parameter:

Crush zone bottom coordinate (blue is 0.2 stretch, red is 0):


Same for the coordinate of the roofline:

That's it for now. I said I'd only put a few comments in - what a laugh!

The results above reproduce the simple part of Greening's paper, and these results in turn have been confirmed in physics engine simulations. It's quite close to the actual collapse dynamics, which is INCREDIBLE considering there's nothing to it.

That fact alone should be mighty compelling, if you can follow the argument to this point.

Sometime later, we can go over the next step up in complexity if you like. In the meantime, feel free to get Ruby and run the script. Tweak and see what you get. You can exhaust the range of interesting input in probably less than an hour. In that short time, you'll get more insight into inelastic accretion than most people have in a lifetime.

reply to post by IrishWristwatch


Please see my comment on previous page. Thank you.

This one?

Originally posted by buddhasystem
What I haven't seen so far in this thread is actual coupling between the floors due to columns running the height of the building and being rather violently deformed. When you forcible move columns around, it's simply impossible that the integrity of various connections of structural elements on a few layers below would somehow persist. On a sad note, I witnessed the collapse myself. To me it looked like peeling a banana. If the columns are being peeled away, I can't imagine you can consider the strength of the next layer at the nominal level.

If so, see reply above.

Sorry your post got lost in a sea of my dribble.

reply to post by IrishWristwatch


Thanks, sorry to bother you.

Originally posted by buddhasystem
reply to post by IrishWristwatch

 

Thanks, sorry to bother you.

No, it's cool and I wasn't trying to brush you off. Just that, while you're pointing out something very pertinent to the actual collapses, it's hard to say much more about it than you did. Modeling such effects in a meaningful way is a tall order. Without a pretty extensive simulation, I'm limited to saying "yeah".

Originally posted by IrishWristwatch

Originally posted by buddhasystem
reply to post by IrishWristwatch

 

Thanks, sorry to bother you.

No, it's cool and I wasn't trying to brush you off. Just that, while you're pointing out something very pertinent to the actual collapses, it's hard to say much more about it than you did. Modeling such effects in a meaningful way is a tall order. Without a pretty extensive simulation, I'm limited to saying "yeah".

There are packages out there that would do that, and I'm sure they have been used to same effect.

After all, people routinely do this.

I'm not saying it's impossible (in fact all I said was it's difficult) . I'll tell you the same thing I tell anyone else who says something is simple (or routine): by all means, have at it.

If you seriously wanted to pursue it, you could contact Enik who did this, this and this, among others. Probably still has his structure data files, however crude they may appear to be at first glance. Given what an incredible pain in the ass it was to make them, I'm sure you'll find them quite a jumpstart on any such endeavour.


Edit: oh, and I forgot. You'll need an Abaqus (or equivalent) seat and a pretty high-end machine. Even so, prepare to dedicate that machine to run for weeks on end.

Originally posted by buddhasystem
There are packages out there that would do that, and I'm sure they have been used to same effect.

After all, people routinely do this.

edit on 17-11-2011 by buddhasystem because: (no reason given)

Actually, it's kind of funny you linked that, since the simulation was done with the program Impact. I've had some hands-on experience with Impact, and I can assure you it is not a package that can "do that" (simulate a tower). I was very impressed with the auto collision (especially for freeware), but in playing with simpler models I know it took a lot of tweaking to get that to run and it can't possibly be that accurate to fine detail, though it may look that way.

Very simple Impact models take forever to run and blow up with singularities at the drop of a hat. Here you'll see where I first started playing with it (bullet/coin demo file) and ran into problems immediately. The problems were such that I dropped it in favor of other FEM environments like Calculix. All of them are a huge pain in the ass to deal with.

Edit: and, once you've toiled for months to get a model like Enik's, and run it for a week or two, you find you get pretty much the same result in terms of overall dynamics that comes out of the simple little script I posted above.

This is just great, we're coming from two different directions still heading the same way.

Look, it'll take me a few hours, days and weeks to familiarize myself with Ruby, I've just looked at the documentation and not tried one thing yet, you've got a headstart here, but I'm a good runner. I've once transcribed the runes on the first page of Tolkien's Lord Of The Rings based on the runes translated from the inscription on Balin's grave before I knew that other editions of the books had a complete description of them in the appendix. If I count the lines the notes are on in a symphony, I know how to transcribe them to a GameBoy melody. Other people read runes and musical scores fluently.

Let me try something.

My approach was to do the simple math of describing the forces and energies as they were before initiation and comparing them to the values I get once "the stone is sinking". Of course, they were oversimplified and only average values. Now, with PLB's and your patient help, I finally get why we've not been speaking the same language the whole time. Bazant is throwing something through the roof and I'm trying to bring the whole building down, just as I was trying to explain how my "umbrella model" works. I build a core of glass (or pasta), rest a heavy hat truss on the core and let the perimeter hang as a curtain from the edge of the hat truss. Easily could this sort of structure also support a few floor slabs. Now I give the hat truss a knock on the head and, once moving, its weight will crush (or sink) through the brittle glass structure, given the same parameters as in PLB's ice palace example, and exhibit a behaviour quite similar to the one we're discussing. The heavy hat truss is the same as the rigidness of Block C (we can crush that one (up?) later).

So, if I were any good at Ruby and iterations, I'd run two sets of curves (or bar charts): Set A for the expected forces per area (pressure, tension) over the floors, you know: what does it take at least for the structure to keep in a static state. I know we're getting just an average per m³ and no computation of each and every bolt. However, Set B would describe the descent just the same way. With all the calculations for momentum, acceleration, deceleration and change in potential and kinetic energy already done, it shouldn't be that hard to do derive the same values for all variables concerning force per floor like stress, tension, strain energy and maybe even the section modulus.

On a third set of graphs, I would substract these curves and thus denote the magnitude of change (state switches) in these values because that's what we're looking for, isn't it? We still won't know if it was slipshod architecture or Lord voldemort with the Death star to reset the Matrix, but have achieved more than any of the experts in a decade - all within a 1-D model. KISS principle at its best.

What do you think? Have you already done this?

reply to post by IrishWristwatch


I must say I am not really familiar with that syntax. I did make something similar though some time ago, a very simple program that calculates the collapse time taking only in account the inertia. It is written in C#.

double a = 9.8;
double dd = 3.77;
double velocity = 0;
double mass = 15;
double time = 0;
for (int i = 0; i < 95; i++)
[
time += (-velocity + Math.Sqrt(Math.Pow(velocity, 2) - 2 * a * -dd)) / a;
velocity = Math.Sqrt(Math.Pow(velocity, 2) + 2 * a * dd);
velocity = velocity * ((15d + (double)i) / (15d + (double)i + 1d));
]

The result I get here is 11.5s, which is a bit less than your ~12s.

Maybe an analytical approach is also possible using an recurrence relation or differential equation. But since this is not really my field I am afraid I will be reinventing the wheel.

Edit:One more note, wouldn't the best environment to model something like this Matlab (or alternative)? The syntax is really simple all the maths and plots are build in.

That's it. First it's swimming, then it's sinking, so there must be an energy leak somewhere like air going from a balloon. You have done a great job describing what happened: a loss of potential energy. I guess what I'm trying to say is that the paper published on 09/13/01 is more a "simple description" than a "simple analysis". Lots of the potential energy is going into kinetic energy, only some of it into deformation. If actio=reactio, there must be a set of forces - no matter in which direction - of which the vector sum acts on the "spring" downwardly which was not there before. Now we may say gravity, that seems to be self-explanatory. But where has the vector sum of all the upwardly working forces gone then which were supposed to counter-act just that gravity two-fold? There must be a huge torque at work if we assume that up to the point of initiation, the towers were in a state that you could just take Block C off with a big helicopter, put a roof back on it and have them stand there for another 30 years, or even turn off the fire, install a few support beams, repair the damage, mourn the day and keep going with those two ugly grey vitrines spoiling the skyline. That's what's going on in my head right now, if you know what I mean.

Ruby, I'm coming! Please keep that lady warm for me, will you?

Originally posted by IrishWristwatch
I'm not saying it's impossible (in fact all I said was it's difficult)

I'm not saying it's not difficult (in fact all I said was it's possible)

Edit: oh, and I forgot. You'll need an Abaqus (or equivalent) seat and a pretty high-end machine. Even so, prepare to dedicate that machine to run for weeks on end

Watch, I have a few thousand machines I could use, if there is an organization that comes up with proper justification.

All the time, we've been looking up like we ought to do in a good magician's trick. What's below and what's inside? It stood, it was swimming, so it had a volume.

For first, we had a pressure (or tension) of 500,000,000kg * 9.81m/s² / 64m*64m for the first floor,
and a pressure of 4,545,455 kg * 9.81 m/s² / 64m * 64m for the topmost floor, that gives an average of

250,000,000kg*9.81m/s² / 4096m² = 598,755 N/m². At least!

When it "sank", the pressure was only

250,000,000kg* 4,08 m/s² /4096m² = 249,023 N/m².

Of course the strong spring is broken, but its stiffness is reduced thousandfold (“If F=-kx, then, as we observed, the ’spring’ was displaced 400 meters by 31 times the force of block C, so k=-F/x and for F=31*FLoadBlockC: K=-31*58,000,000kg*9.81m/s²/-400m=44,095,950N/m which is 1610 times smaller than 71×109N/m" before an accelerated Block C even touches it) by a force that's just 31x stronger. What does this look like in an iteration, what does this look like in reality, and where's the energy leaking?

buddhasystem, you were there, you say it was like peeling a banana. What else was going on?

//edit: I just found that in hydraulics, E=p*V, that is the pressure on the volume. What is 250,000,000kg*(9,81-4,08)m/s² / 4096m² * 64m*64m*400m?

Originally posted by -PLB-
reply to post by IrishWristwatch

 

The result I get here is 11.5s, which is a bit less than your ~12s.

The difference is our 'split' points; mine was at floor 98 and yours is at 96 (which is what Greening used).

Maybe an analytical approach is also possible using an recurrence relation or differential equation. But since this is not really my field I am afraid I will be reinventing the wheel.

Yes. I like the discrete approach better, much easier to have story-specific values. As an example, the actual mass distribution is quite uneven, what with the mechanical floors and such. Hard to get an analytical representation of something like that.

Edit:One more note, wouldn't the best environment to model something like this Matlab (or alternative)? The syntax is really simple all the maths and plots are build in.

No doubt. I'm prejudiced by all the other stuff it lets me do. Lots of libraries availble, including for more general purposes. Even Javascript will do this just fine.

Originally posted by buddhasystem
Watch, I have a few thousand machines I could use, if there is an organization that comes up with proper justification.

That changes everything. The jusification might be a problem, though, since one camp feels it's unnecessary and the other won't believe the results.

Edit: I don't even know why I said the last part.