The 9/11 Forum

Einsteen,

Very nice indeed!

As for the WTC7 video you posted:

http://www.youtube.com/watch?v=KfxkjvDPnpo
http://www.megaupload.com/?d=6BGW5NC4

I don't believe I've ever seen this angle with the collapse of the penthouse included. Why would anyone edit out the first few seconds?

Max

Dictator Cheney:

Yes, I was talking about Einsteen's post but I am still interested in the scaling used in the NIST simulations and appreciate your posts on this issue. Sorry if I caused confusion but sometimes I jump from topic to topic...

Einsteen:

I have tried to calibrate your smearograms by placing a grid over the image and using information provide by the image itself such as the width and height of the building or features on the building. The time scale is tricky because I usually wind up using a stop watch on a video as a check and this technique is obviously subject to large errors. It would sure help if the resolution was better, but I don't have access to any fancy video editing software anyway. Nevertheless, I think 10 m/s^2 is simply incorrect and even 9 m/s^2 is too fast, ....... but 7 m/s^2 is probably too slow.

Have you seen Charles Beck's WTC 7 paper from July 2008?

Einsteen and Dr. G,

Perhaps a practical approach might be to plot a family of acceleration curves - say for 7, 8, 9, 10, and 11 m/s^2 - normalized to the height of the smearograms - and simply see which curvature best fits the smearograms by overlaying them.

Max:

Well, you could do that, but the smearogram still needs an accurate time and roofline-drop calibration. However, what I am finding is that the acceleration is NOT really constant but tends to decrease significantly over the first 4 seconds of drop. This could be due to the fact that in a crush-up, the mass of the descending upper block is decreasing with time.

You know it really is too bad that in all the hundreds of pages of the Draft Report on WTC 7, NIST fails to give a table or graph of drop vs. time.

Do you remember that Shagster used his differental equation toolkit to plot x(t), you have to dig deep in the physorg archives, yes the crush-up slows down of course (if someone knows that, it must be you...), mass on top decreases and a constant E1/h is assumed to be the the only resistance. If you look at the smearograms you also see the function switches from convex to concave or vice versa (can't remember what was what)

Einsteen:

Yes, I do recall Shagster doing some smearograms on PhysOrg but I don't remember seeing a x(t) plot... I guess I'll have to go digging!

And how about the estimable OneWhiteEye? ..another smearogrammer!

And Einsteen, you are correct, the plot goes from convex to concave. I have some energy transfer calculations on WTC 7 that show this quite nicely too.

Dr. G,

I had to chuckle at how much information was carried by italicizing could.
Yes, my brainy idea assumes constant acceleration, for which there is no basis.

Max

...(repeat)

Ok, someone has to do the dirty work...

I didn't read in detail how the NIST did it but they say (page 41) that the roofline fell 18 stories in 5.4 seconds with an
error margin of 0.1 second, let's see

I used the last picture and found this:



http://i36.tinypic.com/2efl2mq.gif

Let's call h the distance between two stories.

We have to be fair, I took the rectangle with the bare eyes and if there is a drop of a single dot you can really stretch it. Again for a good method a parabola should be fitted, with least squares for example. But let's use this.

101 x 349 pixels means that the drop is 15h in 101/30 seconds

15h=(1/2)at^2 => a=30h/t^2

The NIST says wtc7 was 186 meter high, ignoring the base etc this implies h=186/47 meter

Hence

a=30h/t^2=30*186/(47*(101/30)^2)=10.47 m/s^2

Therefore, dr. G, your theory that the explosives created a vacuum to absorb the sound waves should be extended to a one in which the building is being sucked down...

Ps. This should be done with error analysis, furthermore if you use the non-NIST value 174 meter then you get 9.80 m/s^2 < g

Interesting.

You are doing a simple calculation for average acceleration.

What is really needed is to just an accurate hand-made (computer made) plot of x(t). You shouldn't even bother fitting the data to a function until you have an accurate physical plot of x(t).

The aim would be to to use it to plot a(t). It is the acceleration which contains the interesting info. Not just the average acceleration over some time interval but the actual instantaneous acceleration a(t) at any moment.

If you actually find peak acceleration moments exceeding gravity you've found something very big.

Calculating average acceleration will water down the peak acceleration. What the peak is and when it happened is the best data we could have.

\i assumed that the whole funtion was a parabola. One should of course have the function y(t) and then a(t)=y''(t), the value I had indeed assumes it is constant over that time

Major_Tom wrote:Interesting.

You are doing a simple calculation for average acceleration.

What is really needed is to just an accurate hand-made (computer made) plot of x(t). You shouldn't even bother fitting the data to a function until you have an accurate physical plot of x(t).

The aim would be to to use it to plot a(t). It is the acceleration which contains the interesting info. Not just the average acceleration over some time interval but the actual instantaneous acceleration a(t) at any moment.

If you actually find peak acceleration moments exceeding gravity you've found something very big.

Calculating average acceleration will water down the peak acceleration. What the peak is and when it happened is the best data we could have.

True, one aim is to have a(t), but it's more elusive than it appears. It's very easy to state the total duration and average acceleration which actually are quite useful, everything else is an eventual necessity but a drudge and not terribly accurate when it comes to peaks.

einsteen has provided a nice plot of x(t) above but not based on numbers. I personally take this as a clever euphemism for

"I don't wan't to do this, at least not right now, would someone else like to?"

Once you have numbers for x(t), trivial calculations of first and second differences give v(t) and a(t). Going from picture to numbers is not that big of a problem for many targets. einsteen, Dr. G and I have all done data extraction in a number of ways, but all have the potential to introduce a variety of errors and none lend themselves immediately to high resolution interpretations of acceleration (can't speak to the Dr's results on that). Typically a fair bit of overhead is associated with any but the most rudimentary digitizations (i.e., the better the quality, the more time on the hands that's required).

My preference is to get data via software implementation as it is per-frame, sub-pixel (sometimes) accuracy and (almost) completely objective. In the best of cases taking data straight from an original DVD the raw data can still be pretty noisy, depending on the target. Calculating acceleration discretely per-frame then leads to some pretty wild oscillatory behavior in acceleration. I've taken some really smooth and accurate position data only to find peak accelerations of +/-25g!!!

Time-averaging is quick and helpful but not a fix. If ~30fps data is taken from a sharp and steady original and there are minimal sources of real noise (smoke, thermal, etc) then a 3 - 6 frame resampling interval for the position data would probably be reaonable and give smooth, accurate plots of position versus time.

In pixels and seconds.

Assuming the scene geometry is known with precision, x(t) in meters can be calculated and used to immediately obtain v and a, except I can almost guarantee you acceleration will still be lumpy after a such a resample. The bottom line is x(t) must be processed in some high level manner first, whether it be a curve fit or something more elaborate like DBB's Bayesian methods, then a(t) would be meaningful. *

For me, the simplest path to pixels(time) is manually via an SVG editor but I don't care for the results, they are far too subjective to claim much accuracy. Get a thousand people to make the same measurement, though, and it might be the best curve you'll ever get. David Chandler uses the Physics Toolkit, I'm not sure what einsteen uses these days, there are many, many ways. Doesn't matter to me, anything other than machine vision and full post-processing is too flawed to get a good a(t). Now, some of us have participated in doing this before, but there's nothing like the first time so the motivation to take the step from total duration to a(t) will be a little slower coming maybe.

Unless you want to do it? <wink>

*although any real transients will be obliterated by the process

einsteen wrote:Hence

a=30h/t^2=30*186/(47*(101/30)^2)=10.47 m/s^2

Therefore, dr. G, your theory that the explosives created a vacuum to absorb the sound waves should be extended to a one in which the building is being sucked down...

haha, good one.

Major_Tom wrote:If you actually find peak acceleration moments exceeding gravity you've found something very big.

In theory, yes. Practically speaking, look no further than einsteen's comment above. Did you mean 'approaching' instead of 'exceeding' g?

Let's assume the hoops have been jumped and there's an available a(t) dataset of arbitrarily good quality. In your opinion, what would be the implications of discovering high peak values?

To clarify a couple of things I said earlier:

"...DBB's Bayesian methods..."

He uses Lagrange interpolation on the raw data to prepare it for subsequent analysis, the Bayesian part has nothing to do with this topic.

"David Chandler uses the Physics Toolkit..."

to get a sample point here and there. Fewer samples means less problem with fluctuations in acceleration values, but this is strictly a result of having little data to work with. A sample for every frame is best, anything else is just throwing information away. I've never had the patience to place 200 points manually and I'm not aware of anyone else doing it but it would be noisy just like an automated routine. Noise is inevitable; software extraction is best, prevents insanity.

"...but all have the potential to introduce a variety of errors..."

Resolution alone is enough to jack up acceleration values. Position data taken from raster images can only assume a discrete set of values. The worst is measurements to the nearest integer pixel. Here's what some real world data looks like in this regard:

Position - http://i27.tinypic.com/jgt7pd.jpg

Pretty smooth.

Velocity - http://i25.tinypic.com/64lz84.png

Concentrated evil. Sorry I don't have a raw acceleration graph on hand, but trust me it's worse, only 3 or 4 values for acceleration and none of them are the real value, except zero for initial. Without proper interpolation or filtering, it's a mess.

" accelerations of +/-25g!!!"

You can see now why negative values and magnitudes greater than g are the norm.

Major_Tom wrote:Not just the average acceleration over some time interval but the actual instantaneous acceleration a(t) at any moment.

If you flex a tad on the definitions of 'actual' and 'instantaneous' then it can be done.

Hi Everyone!

Thanks for all your excellent contributions to this thread. I have been working hard to get that elusive drop vs. time curve we all want to see and I am finally getting some good (reproducible!) results. Here are some preliminary findings:

1. I have looked all the existing data I can find out there including smearograms by Shagster and Einsteen, the new German video posted in the News section of this forum by Dictator Cheney,etc, etc, and I have also done some of my own plots! I use an 8X magnifying lens on screen capture print-outs so I can actually see the ink-jet pixels! I know this sounds pretty crude and is a long way from OneWhiteEye's ideal, but I am an "Old School" kind of guy!

Nevertheless, I get remarkably good agreement between all the plots I have compiled so far, ....... EXCEPT when I use NIST's images from Chapter 5 of NCSTAR 1-9!

HOWEVER:

2. I can get NIST's results to agree with all the other data I have (so far) if I simply apply a shift of about 3/4 second to NIST's collapse initiation time. Thus, in my opinion, NIST take collapse initiation too soon and this adds 3/4 second to their times and makes the collapse slower than everyone else's and, I believe, slower than it really was.

3. Next I take my hand measured data and feed it into an excel spreadsheet and generate a time vs. drop plot for each set of data. I also have an energy transfer calculation for a crush-up of WTC 7 with an E1 value ~ 1 GJ and I generate a time vs. drop plot for this too. I then fit each curve to a polynomial. Now, in order to allow the acceleration to vary with time you must use at least a 3rd order polynomial. So it goes like this:

Drop distance s = At^3 + Bt^2 + Ct + D

Velocity, v = ds/dt = 3At^2 + 2Bt + C

and Acceleration, a = dv/dt = 6At + 2B

For all the data, and for NIST's data (time-shifted by 0.75 seconds) I get an approximately constant acceleration between 8.0 and 9.6 m/s^2, but more precisely I find it decreases slowly with time:

a = (8.0 to 9.6) - (0.2 to 0.5)t

And, interestingly, the energy transfer calculation result is:

a = 9.15 - 0.314t

i.e. my "theoretical" result is pretty much in the middle of all the "observational" results.

So, I am pretty happy with these findings and it is encouraging to see such good agreement with all the WTC 7 collapse data out there.

However, as usual, everything needs more work.......

So B=8.0 to 9.6

A=0.2 to 0.5

fit to the polynomal above.


OneWhiteEye, does this margin of error seem reasonable ("doable") to you?