WTC7: NIST Measures Downward Acceleration Incorrectly - World Trade Center Evidence-Based Research

As you can see, the roofline structures are still visible for the first 4 datapoints, and the roofline cannot be determined by automated tracing techniques.

If one performs a trace from the NIST T[sub]0[/sub] pixel location and frame, and scales it relative to the height determined for Region B...

...and compares it to the NIST displacement data...

...it fits well.

It is suggest the datapoint separation graph highlights what NIST did...

The T[sub]0[/sub] pixel is obscured behind foreground buildings around 4.7s after that time...which coincides with the change in datapoint separation seen for the last 5 samples in 12-76, shown below:

It seems NIST started the trace from the T₀ pixel location, then swapped tracking point for those last 5 samples to a location above Region B.

The NIST data suffers from the following (non-exhaustive) series of technical issues, each of which reduce the quality, validity and relevance of the data in various measures...

NIST did not deinterlace their source video. This has two main detrimental effects: 1) Each image they look at is actually a composite of two separate points in time, and 2) Instant halving of the number of frames available...half the available video data information. Tracing features using interlaced video is not a good idea. I have gone into detail on issues related to tracing of features using interlaced video data previously.
NIST did not sample every frame, reducing the sampling rate considerably and reducing available data redundancy for the purposes of noise reduction and derivation of velocity and acceleration profile data.
NIST used an inconsistent inter-sample time-step, skipping roughly every 56 out of 60 available unique images. They ignored over 90% of the available positional data.
NIST likely used a manual (by hand-eye) tracking process using a single pixel column, rather than a tried and tested feature tracking method such as those provided in systems such as SynthEyes. Manual tracking introduces a raft of accuracy issues. Feature tracking systems such as SynthEyes employ an automated region-based system which entails upscaling of the target region, application of LancZos3 filtering and pattern matching (with FOM) to provide a sub-pixel accurate relative location of initial feature pattern in subsequent frames in video.
NIST tracked the *roofline* using a single pixel column, rather than an actual feature of the building. This means that the trace is not actually of a point of the building, as the building does not descend completely vertically. This means the tracked pixel column is actually a rather meaningless point on the roofline which wanders left and right as the building moves East and West.
NIST used the Cam#3 viewpoint which includes significant perspective effects (such as early motion being north-south rather than up-down and yet appearing to be vertical motion). It also means that each horizontal position across the facade requires calculation of a unique scaling metric, which NIST do not appear to have bothered to do.
NIST did not perform perspective correction upon the resultant trace data.
NIST did not appear to recognise that the initial movement at their chosen pixel column was primarily north-south movement resulting from twisting of the building before the release point of the north facade.
NIST did not perform static point extraction(H, V). Even when the camera appears static, there is still (at least) fine movement. Subtraction of static point movement from trace data significantly reduces camera shake noise, and so reduces track data noise.
NIST did not choose a track point which could actually be identified from the beginning to the end of the trace, and so they needed to splice together information from separate points. Without perspective correction the scaling metrics for these two points resulted in data skewing, especially of the early motion.
NIST performed only a linear approximation for acceleration, choosing not to further derive their chosen displacement function.
NISTs displacement function, if derived to obtain acceleration/time contains a ~1s period of over-[i]g[/i] acceleration.
NISTs displacement function, if derived to obtain acceleration/time does not suggest a 2.25s period of roughly gravitational acceleration.
The displacement data appears to have been extracted initially from the T[SUB]0[/SUB] pixel column, but using the scaling factor determined for a point above Region B, further skewing the displacement data.

original post

.........................

Similar general problems with the early acceleration measurements are presented below, originally from this post.

Contents:

On the NIST website "Questions and Answers about the NIST WTC 7 Investigation (Updated 09/17/2010)" you find the following:

http://www.nist.gov/public_affairs/factsheet/wtc_qa_082108.cfm

How did the NIST measure free-fall acceleration?

According to NIST_NCSTAR_1-9_vol2 12.5.3. NIST used the "camera 3".

This is the view NIST used for the measurement:

In the Draft Report NIST states: "The elevation of the top of the parapet wall was +925 ft. 4 in. The lowest point on the north face of WTC7 visible on the camera 3 video (section 5.7.1) prior to any downward movement was the top of windows on floor 29, which had an approximate elevation of +683 ft 6 in."

That information got lost in the final NCSTAR 1A Report.

However, just a small part of the "top of windows on floor 29" is visible. To measure the fall of the building NIST had to measure a vertical path above the visible top of the windows.

Therefore we have to know how NIST defined the "parapet wall".

FIrst problem: Confusing paraphet wall, screenwall and roofline

NIST defined "parapet wall" for the same elevation they defined as "roofline" in the final report.

Hence, we have to measure this path:

The following image shows that NIST was aware of the difficulty in measure the fall down the described path:

The "screenwall" is visible above the roofline and had an elevation of about two additional floors and the lack of contrast allows no direct tracking of the roofline.

So how was NIST able to measure the fall of the perimeter wall?
They answer the question in the FAQ:

"The instant at which vertical motion of the roofline first occurred was determined by tracking the numerical value of the brightness of a pixel (a single element in the video image) at the roofline. This pixel became brighter as the roofline began to descend because the color of the pixel started to change from that of the building façade to the lighter color of the sky."

In other words, NIST did not measure the parapet wall! They measured the fall of the screenwall about 2 floor heights above the parapet wall. They took the time and subsequently calculated a fall speed for the smaller fall distance.

Second problem: Inward flexure of roofline during earliest movement.

The perimeter wall didn't bow downwards as visible from a different vantage.

Instead the perimeter wall stayed vertically straight even during the fall for several floors.
The motion of the perimeter wall as visible from "camera 3" is nothing but the bowing of the perimeter towards the core.

In other words, NIST measured the drop of the "screenwall" + the transition of the falling screenwall into the horizontal bowing of the perimeter wall + the transition into the vertical motion of the perimeter wall.

The red curve shows the motion NIST measured:

The fat bright blue curve is a calculated free fall.
The lower curves are the trackings of several floors in the NIST measure path. The slow onset of motion of these lower curves is the result of bowing away from the camera.

Since NIST gave the real elevations along the path it is possible to calculate the velocity for the entire motion.

That's a pretty different result.

In the Final Report as well as in the FAQ NIST described their result this way:

The NIST "stage 1" includes about the frames 150 ... 202 of my motion tracking measurement.

That NIST "slower than free fall" stage 1 includes the following real events:

- the screenwall on top of the core started to move (frame 150...155)
- the screenwall reached about free fall (frame 156...170)
- the screenwall disappeared behind the parapet wall (frame 170)
- the perimeter wall bows towards the core (frame 170...180)
- the perimeter wall dropped above gravity (frame 180...200)

That's where stage 2 at "gravitational acceleration (free fall)" begins.

That means there is almost no vertical motion slower than freefall but for the very first 0.17 seconds AND that short amount of "slower than free fall" is probably stretched by the symmetrical averaging of the velocity over 9 frames.

So how is it possible that the perimeter dropped faster than free fall?

Simply imagine some dumbbell like object that rotates vertically and fall at the same time.

Core and perimeter were still connected by the floor system. Once the core dropped at gravitational acceleration the core-floor-perimeter acted like a spring system. First, the core pulled the perimeter inwards. Secondly, the perimeter failed at a very low elevation and was shot downwards by the "floor-springs". The falling core was slowed down at the same time until the entire system fell as one unit.
Of course the center of mass of the entire system cannot exceed gravitational acceleration but the perimeter can and it tells a lot about the intact inner structure of the upper and visible building part.

From a different viewpoint: The Dan Rather view

Post reproduced:

This one stabilized:

drop including velocity:

Here are the two elevations NIST used:

I used the very same elevations but the above video.

Looks like the core was slowed down by the perimeter - strained the floors - took down the perimeter and catapulted the outer shell downwards until the floors were unstrained again. Afterwards that whole thing fell at free fall acceleration for about 40 meters and slowed down a tiny little bit.
...and yes, the NW corner of the west penthouse just FELL until it slowed down.

It looks like NIST had a slow motion video without knowing. :shock:

NIST: "The time the roofline took to fall 18 stories was 5.4 seconds..."
...equals 135 frames at 25fps!
The NW corner of the roof reached the 29th floor in frame 397 of my measurement. In other words, the time segment measured by NIST looks like THAT:

Well, NIST started measuring at exactly the moment when the NE corner of remained west penthouse started to move and stopped the time when the NW corner reached the 29th floor.

Traced points marked:
Original post

Resulting drop data:
Original post

Original JREF post

Created on 03/07/2011 08:37 PM by admin
Updated on 05/21/2014 08:19 AM by admin