The 9/11 Forum

smearogram is a great word, sorry if I said it wrong, but I mean the method is child's play compared with your stuff!

Crap....that was really scary, like a combination of Dracula, Frankenstein, Jason Voorhees, Freddy Krueger, Predator and Alien!!!

Not being prepared to give up on this t(0) problem yet, I have tried a new approach: I have used all the available single frame shots from Camera 3 as shown in the NIST Draft Report (See Chapter 5 of NCSTAR 1-9, pages 273 - 287), and estimated the drop between two NIST times. I have found that the frames from Camera 6 are actually also quite useful because you can use the roofline of 101 Barclay - the white stepped building in front and to the right of WTC 7 - as a height reference marker.

Because many of the time intervals used by NIST are 0.5 or 1 second, it is a simple matter to get a drop height per second and call this the average velocity between the two times. In this way I have been able to estimate 7 descent velocities between collapse frames from 8 seconds to 12 seconds on NIST's time scale. I then plot these velocities vs. NIST's times. I get a line with a very slight curvature indicating some drop-off in the acceleration later into the collapse but a simple straight-line fit is also very good. The straight line fit is:

Velocity = 8.769t - 68.44

So all you have to do is set the velocity to zero to find t(0). This gives a t(0) of 7.8 seconds which is very close to the value I estimated previously and a full 0.9 seconds later than NIST's t(0).

Fascinating. You've come at it from an entirely different angle and gotten a consistent result. And it all makes sense, given the curves einsteen has posted and the fits you've obtained. Both show position as very near parabolic, there's no reason to expect significant fluctuations in this gravity-driven system with a high inertia body, and none of note are seen - constant acceleration is a fine approximation.

What does NIST say is their criteria for setting t0 of global collapse? Is it possible that they start when the interior of the roofline is moving (bowing) but the NW corner is still stationary? All of the motion is deformation for a time, they really shouldn't include it in average acceleration calculations, I don't think. What if it bowed for period of hours (some say it did!) then came down suddenly, would they calculate the avg accel to be 0.0001g? That wouldn't be too meaningful.

I admit I don't know, and I'm lazy (or busy depending on how you look at it), so that's why I ask you, Dr. G. What I'm getting from this is their own pictures show a questionable choice of t0, independent of any other results - is that the case? It must be resolved. Their timeline is now related (not formally, with a precise number) to the videos. The total roofline initial motion will be mapped at some point, and then state of the structure at their t0 will be known. The decision to choose that point, rather than a later time, should be evident if there is sound reasoning behind it.

CAUTION: this post should only be read by those with a deep and abiding interest in the minutiae of obtaining data, which may only be me. Most of it is common sense delivered in an unnecessarily verbose manner. You have been warned.

I want to describe a failed effort because it illustrates a particular sort of error that has come up before in this thread and elsewhere. While I'm using one of my methods as an example, some of the points apply equally well to smearograms.

This was my second and recent attempt to get vertical-only data from the NW roofline using a method that is not best suited for this task. The first attempt failed because the chosen threshold values didn't correspond well once descent began so the acquired point drifted a couple of pixels from the roofline into the sky. It worked very well for the horizontal data, which matched the NIST data more closely than I would have guessed. There are specific reasons why the horizontal was good and these verticals were bad. Knowing why helps instill confidence that this process is not some mumbo-jumbo that is randomly correct from time to time, and leads to correct data in the future.

In this last run, the problem is horizontal motion affecting the vertical measurement on the roofline edge. The problem occurs when a measurement is being made in one dimension and motion in the other dimension bleeds over. Generally, the (x,y) coordinates of an image don't correspond to real (x,y, or z) coordinates and orthogonality in real 3-space is not preserved in the image plane. There will be at most one image axis that can be aligned with a real axis, and apparent motion in the other image axis will be a combination of motion in two or even all three real axes. In a more technical sense, an image represents the output of a many-to-one mapping from R3 to I2 such that orthogonal vectors in the real scene correspond to non-orthogonal vectors in the image plane. There's a simple name for this type of mapping, but it eludes me. Well, it's a projection, in any case.

In the WTC7 videos, true vertical aligns very well with image vertical, a fortunate condition when combined with a relatively small optical axis elevation angle. It means that, at least for moderate displacements, approximate vertical motion can be derived from pixel motion by application of a multiplicative scale factor. At the NW corner roofline, true horizontal comes through in the image as a small but not insignificant angle:



Below, I've exaggerated the vertical by 5x and drawn a straight green line to represent the average apparent slope of the roofline. Yellow lines are drawn vertically to indicate where a couple of one-pixel smearograms or a 2D range of pixels could slice through this area:



The magenta points of intersection represent vertical locations obtained via smearogram and they're obviously at different pixel y values for the intact, static building. Since only differences are used this is OK and, if the motion is strictly vertical, it will be OK all the way. However, if there's any horizontal motion, the points of intersection will change, registering higher or lower values depending on whether the motion is to the left (shown below) or right. Yes, I cheated and moved the lines instead of the image:



The error can be of the order of the signal if there's more horizontal motion than vertical, and all error if only horizontal. A horizontal measurement, however, is not affected if the building drops a little:


(A slightly different presentation to avoid collinearity)

This is why the horizontal data would've been good even if the building dropped or sagged a little (it did in the first milliseconds of descent but I haven't validated that data - it doesn't match NIST - and there are other reasons it could be bad). Not to mention the corner edge is a nice dark line and the roofline edge is ragged and riddled with compression artifact.

A 2D method is likewise affected by this no matter if it's tracking an edge which cuts through the region or a fully enclosed feature. The edge gets shifted up and down as the feature moves side to side, but it's also exacerbated by any non-uniformities in the edge, something that wouldn't affect an enclosed feature. This is what bit me on this last run.

To get verification, I always output an animation from the extraction showing the placement of the point on the feature through the frames examined. If my eyes don't agree, the data is discarded. If I can't do any better visually than the output, I accept it to within the accuracy of eyes - a couple of pixels. So, if I state an error of +/-2 pixels, it's safe but the data could be accurate to +/- 0.1 pixels in actuality. Failures always have a reason, whether I can be bothered to trace it depends on whether it will be informative to find out why. Sometimes it's obvious as it is here, the first 30 frames:



The horizontal wandering causes artifical vertical motion to be registered. Real horizontal motion isn't the primary source of error here but undoubtedly does contribute. Here, virtual horizontal motion is induced by fluctuations in the video image, making different locations of the roofline more strongly associated with the threshold criteria, so the point wanders horizontally along the roofline. Observe that the point traverses a path largely confined to the apparent slope of the roofline. The first second of vertical data looks like this:



The peak to peak motion is 0.6px ~ 4 inches, but I know some of it is bad and I don't know how much. Astute readers will likely also observe that a snap upward of 4 inches in two frames is mighty unlikely. The remedy is the subject of another rambling post.

Attempts to obtain vertical data, though few, have been unsuccessful. Seems the 2D method is not as suitable using the roofline edge as it was using the corner edge for horizontal. There's very little in the way of peak or trough in intensity to work with, and a monotonic edge gradient suffers hard with high level of noise and compression artifact.

The other big problem is variation in the color values over time make it difficult to specify applicable threshold ranges. I can specify keyframe values, technically every frame could have its own threshold, but I don't have time or patience for that. The whole point of automation is to minimize the manual intervention.

So, the solution is two-fold: 1) finish code to calculate the center location of an edge in a 1D slice, and 2) add in adaptivity so the routine finds its own thresholds on a per-frame basis. Each slice can be partitioned into a pair of disjoint sets (sky-smoke, building) by k-means clustering on intensity and position, then the intensity outliers which are clustered together spatially (i.e., the edge) from each set identified and put into a separate group, threshold range determined by their actual intensities. Finally, the position can be calculated from a weighted sum of the pixels' position, with the weights based on the pixel distance from the centroid in both color space and position space.

Easy to say, not so easy to do. I find the thought of it interesting, the follow-through less so. Nevertheless, it will happen.

I doubt there's any rush for centimeter-accurate displacement data, hope not. What einsteen and Dr. G have extracted is pretty fine resolution and accuracy. It may not be too useful to get much more detailed except with early motion at various points on the roofline. To get even that is to conquer all the problems associated with doing the whole travel and with doing rooflines and tip angles on WTC1 and 2, so it's all really the same thing.

The delay in preparing new code is partly due to time crunch, partly the amount of work, and the rest (code) writer's block. This is a place to enumerate techniques and discuss details of solving certain problems so I intend to document some of the obstacles and methods to overcome them as I work out the associated implementation. I'm considering a quick manual job on the roofline, though, just to put something out that describes the displacement at several horizontal positions.

OneWhiteEye:

I have determined a new, and relatively precise (I hope), collapse equation based on an average of four vertical drop measurements at different roofline locations taken from E to W across enlargements of NIST’s Camera 3 stills (available in Chapter 5 of NCSTAR 1-9). In compiling this data I have shifted NIST’s time scale by taking a t(0) at 7.2 seconds. My earliest data point is actually at NIST's "5 second" mark and the first detectable drop is measured at 0.3 seconds after this t(0), (NIST "7.5 second" image); my latest point is at 3.8 seconds, (NIST's "11 second" image), when the vertical drop was 13 floors or about 52 meters.

I have determined two least squares fits from the resulting drop vs. time plots:

Drop = 0.017t^3 + 4.244t^2 - 3.1686t + 1.2662

And,

Drop = 4.3492t^2 - 3.3409t + 1.3256

As you can see these fits give an acceleration of about 8.5 – 8.7 m/s^2.

However, what is more interesting is that both fits show a vertical offset of about 1.3 meters at t(0). And, as expected, if you plot these curves you will find they simply do not pass through zero drop height unless you artificially “force-fit” this trend by adding a zero drop data point at t(0).

What is even more intriguing is that the first derivatives of the drop equations given above shows both fits have a net velocity at t(0) of minus about 3.2 – 3.3 m/s. Now since we are taking downward motion as positive, a negative velocity means the roofline of WTC 7 was moving upwards at my “7.2 second” t(0)!

Now how could this be possible?!?!

Well I think, OneWhiteEye, you provided us with the answer to this question when you posted (a little while ago) those vertical motion curves for the 7-second period just prior to global collapse. Those curves showed that the WTC 7 roofline was in fact moving up and down with deflections of more than a meter in this pre-collapse period. To be more precise we see in OWE’s data a maximum, pre-global, downward motion of a meter or more at NIST’s 3.7-second mark. And, in the period from 3.7 to 5.5 seconds, we see the building recovering somewhat from this downward slumping by the roofline moving upwards!

It is interesting that I (arbitrarily) based my “initial condition” for my collapse measurements on NCSTAR 1-9, Figure 5-199, taken at NIST’s “5-second” mark. OWE’s vertical motion curve shows that the roofline was actually “bouncing” back near this 5-second mark and thus had a net upward motion for at least 2 seconds.

One other observation is that these offsets in velocity and drop height add to the previously discussed problems in defining the moment of collapse initiation because we are trying to hit a moving target – indeed, it looks like building 7 was already moving well before it really started to move!

I get sick and things get interesting. Sorry I'm in a cough syrup haze right now so I'll do my best to make sense, a little at a time, short replies until I've had time to contemplate (and post some pictures I've been collecting).

Dr. G:

This is progress. Those pesky upward initial velocities, I was trying to figure out what to do with them, never occurred to me to believe them! The top is in complicated motion for some time prior to drop. I think the need for precision data is as great as ever (yay).

Major Tom:

In a word, yes. You're absolutely right.

Major Tom:

In GoldenBear's NIST critique thread, I'd mentioned trying piecewise fits. This endeavor presents some interesting problems of its own, quite fun to work through.

An illustration of the problem of fitting a piecewise generated polynomial with a single polynominal. I made a continuous curve out of two polynomials, the first spanning 0.0 - 0.5 and the second 0.5 - 1.0. I matched the common end values and first derivatives (honestly I did this before your posts, Major Tom, we're on the same wavelength here) which looks like this:


http://i38.tinypic.com/fpblp4.jpg

Then I generated a point series from that composite curve and did a curve fit on it:


http://i34.tinypic.com/315xstz.png

The fit doesn't match well at all, of course, because the first half of the curve has a coefficient of 1 for the second degree term and the last half a coefficient of 4. The fit puts it at 2.5, which is an interesting compromise. It corresponds to a situation where there is a step change between two constant accelerations. Now, if you look at the composite curve , it's quite smooth and it's not so obvious where the split occurs if you're not told. Look at the curve and the fit together in a different view:


http://i37.tinypic.com/2rhbss3.png

They're much harder to tell apart. One is a simple parabola and the other not. This is problem #1, where to do the split.

The haze is lifting somewhat. Like I say, I'm going to address these recent posts in a piecemeal fashion and go back to bed when I have to.

Dr. G wrote:What is even more intriguing is that the first derivatives of the drop equations given above shows both fits have a net velocity at t(0) of minus about 3.2 – 3.3 m/s. Now since we are taking downward motion as positive, a negative velocity means the roofline of WTC 7 was moving upwards at my “7.2 second” t(0)!

I kept getting things like that, too. Even Chandler's graph showed a velocity intercept of 6m/s (where positive is upward in his case). Going back to the trend of coefficients as time is trimmed off the front of one einsteen's datasets:



One can almost guess the time Chandler's dataset begins by noting where the velocity (magenta) coefficient nears -6, the approximate intercept shown for his velocity graph. Almost, I say, because for these runs I didn't offset the independent time variable by the amount trimmed. Speaking of which, the coefficients after a time translation of a are:

f(t + a) = A0 + A1(t + a) + A2(t + a)^2
f(t + a) = A0 + A1t + A1a + A2t^2 + A2a^2 + 2A2at
f(t + a) = (A0 + A1a + A2a^2) + (A1 + 2A2a)t + A2t^2

If there is a function g such that

g(t) = B0 + B1t + B2t^2

and

f(t + a) = g(t)

then the coefficients are related by:

B0 = A0 + A1a + A2a^2
B1 = (A1 + 2A2a)
B2 = A2

This suggests treating the coefficients B as a vector function of a and the coefficients A:

B(A0, A1, A2; a) = [A0 + A1a + A2a^2, A1 + 2A2a, A2]

and, using a polynomial basis vector for time:

T(t) = [1, t, t^2]

g(t) can be expressed as a dot product of the two vectors

g(t) = B.T

giving a simple relation for obtaining coefficents at an arbitrary time offset once they're calculated for a given time. Not coincidentally, the equation for the constant coefficient is a quadratic - there's a certain inside-out nature to the whole thing when treating the constants as the variables. This is also a simple way of seeing - without calculus - how the 2nd degree coefficient doesn't change by translation of time like the others do. Finally, for interest's sake:

g'(t) = B1 + 2B2t = A1 + 2A2a + 2B2t
g"(t) = 2B2 = 2A2

dB/da = [A1 + 2A2a, 2A2, 0]

we can see the rate of change of coefficents with respect to a, which is in fact the independent variable, the same as t.

Damn cough syrup, where was I?

It is interesting that I (arbitrarily) based my “initial condition” for my collapse measurements on NCSTAR 1-9, Figure 5-199, taken at NIST’s “5-second” mark. OWE’s vertical motion curve shows that the roofline was actually “bouncing” back near this 5-second mark and thus had a net upward motion for at least 2 seconds.

What concerns me here is the duration of the bounceback... if it's going up for 2 seconds, it can't be going very fast. Yet, the initial velocities both of us have been getting typically have magnitudes of > 2 m/s, with the notable exception of the forced g fit. I know, I know, I'm still operating in the second degree realm, but it's going to be an issue no matter the function used. Both degrees you used came to similar initial velocities.

Also, what to make of this bounce? I believe I did discern it visually, it's not just something in the data, though einsteen's data had a bit of vertical oscillation apparent as well. I can look right at it and I still don't know what I'm seeing. The penthouse takes a dive, the exterior (?) sags and rebounds (or teeters away from then towards the camera?)... how much mass snapping back up how fast? This building, while seeming to have a pretty rickety backbone, has this most amazing facade.

One other observation is that these offsets in velocity and drop height add to the previously discussed problems in defining the moment of collapse initiation because we are trying to hit a moving target – indeed, it looks like building 7 was already moving well before it really started to move!

Yes. The situation is quite complicated for t0 definition. I am all the more intrigued with exploring and quantifying the early motion across all the visible regions.

Ahh, I think I have to go back to bed now. There are things on my mind, about different forms to try, some with physical motivation, some not. The manual data I took last year has the tail-off: terminal velocity followed by reduction in velocity. I keep coming back to sigmoids, the logistic function and so on. I got an incredible fit on a Gompertz function (http://en.wikipedia.org/wiki/Gompertz_curve) but that one is difficult to justify physically.

A general sigmoid shape is NOT difficult to justify, but the form is another matter. The initial portion of the curve forms from an exponentially increasing event rate, failure in this case. A population composed of structural members experiences failure at ever increasing rate as the constant load is redistributed amongst dwindling remaining members. The last members go, then the acceleration enters a constant phase briefly until the velocity-dependent dissipative effects begin to merge and a terminal velocity is reached. Last, the diminishing upper block mass in motion begins to yield to the 'constant ' resistance and the velocity begins to decrease.

A few scattered observations about the above: The typical function in this class does not have provision for a different 'population' for the beginning and the ending portions of the slope. Whereas, in the collapse, the front and back portions are completely decoupled as I see it. While it makes the sigmoid seem better for the beginning, technically, they start moving at negative infinity so a very sharp function is needed and these tend to rise too quickly. In fact, it seems to work better for the end, where the tail off starts to point at the end asymptote - the final height of the pile.

The generalized logistic function has a quite a few parameters to play with and I'm going to be looking at it harder. While this seems a very unmechanical approach, I remember being told more than once that guessing a solution to a differential equation was every bit as good as toughing it out, so long as you're correct.

Here's a picture of what I've been playing with. einsteen's data is the shorter red curve, mine the longer s-shaped curve. A sigmoid fit in green is shown with its first and second derivatives as dashed lines:


http://i34.tinypic.com/smvbs9.png

I'll explain more later, like why the two datasets don't seem to match and more, must nod out now.

Major_Tom & OneWhiteEye:

Thanks for the helpful comments!

Yes, I agree there is some physical basis for using two functions/curve-fits to model the collapse: one for collapse initiation and one for collapse propagation. But this adds the additional problem of choosing the time of the switch-over, (as OWE has already pointed out!). Intuitively I would expect the switch-over to be very early on, say 1 - 2 seconds after t(0), but this then becomes coupled to the problem of choosing t(0).

Thinking a bit more about my previous post makes me wonder if there really is something we could call t(0) anyway! I mean it looks like the roof was swaying east to west, and oscillating up and down. The swaying I can accept as physically possible, but the up and down motion is very strange indeed. And, yes OWE, I agree that the pre-collapse vertical velocity I get from my curve fitting exercise of about 3 m/s is much larger than what we see in your vertical motion curve which suggests it was no more than 1 m/s. However, I would like to get a better handle on the pre-collapse range of vertical motion to estimate a dh/dt, i.e. the max vertical velocity. My rough estimate is that the vertical motion spans about 2.5 meters or half a floor height. Can anyone confirm this number?

Anyway, on the question of the physical reality of a "collapse initiation" time = t(0): if the roofline of the building was moving up and down and swaying from side to side, perhaps its behavior was more like the Tacoma Narrows Suspension Bridge. In that case there really wasn't a moment in time we could call t(0); there was just a steadily increasing oscillation. In the case of WTC 7 the oscillations were of course much more subtle and were compressed into say 10 seconds. But the point is: how do you define a t(0) for such a system? Perhaps the best we can do is take some arbitrary time, where the drop exceeds say 1 meter, and continues to increase monotonically thereafter, and make this our t(0). Another way to go would be to consider the Building 7 oscillations as the collapse initiation phase, and the monotonic descent as the collapse propagation phase!