Merged Discussion of femr's video data analysis

..... Note that "tiny bit" is not a quantification, it doesn't give an idea of the extent of the shake compared to the rest.

Not so. It does give an idea of the extent of the shake compared to the others.
As comparatives, “big time” is larger than “a tiny bit” which in turn is larger than “doesn’t shake.” No need for quantification and sufficient for proofs as shown in the following posts.
 
Originally Posted by femr2 Okay, time to chuck a *claim* or two in the pot then...

onset-of-wtc1-movement-and-sauret-shake

Feature tracing of the Sauret footage indicates that movement of WTC 1 began in close correlation to the camera shake, ~9.5s in advance of *release* of the upper section.

There are also numerous visual events which occur on the building itself at that time.

I suggest the camera shake and the tower events are related.

Comments ?

New And Improved -
Did the camera shake because of powerful energy released by WTC1 or was the camera disturbed while recording.

http://www.youtube.com/watch?v=G06_JRSrJno
1. At or about 19 sec either a "powerful event" in WTC1 shakes camera a whole lot or “trivial event” shakes camera a whole lot.
2. At or about 31 sec as WTC1 collapses, camera doesn't shake at all.
3. At or about 47 sec as WTC1 is hitting the ground , camera at most shakes tiny bit.

Comments?
 
New And Improved -
Did the camera shake because of powerful energy released by WTC1 or was the camera disturbed while recording.

http://www.youtube.com/watch?v=G06_JRSrJno
1. At or about 19 sec either a "powerful event" in WTC1 shakes camera a whole lot or “trivial event” shakes camera a whole lot.
2. At or about 31 sec as WTC1 collapses, camera doesn't shake at all.
3. At or about 47 sec as WTC1 is hitting the ground , camera at most shakes tiny bit.

Comments?

Why yes, I do have a comment.
(So much for the Socratic method … )

1. If the energy released by WTC1 during the collapse did not shake the camera and:
2. If the energy released while the entire WTC1 is hitting the ground generated at most tiny shaking of the camera, then:
3. The energy released that caused the camera to shake a whole lot before the collapse, should have been substantially greater than the energy released during the collapse and ground impact of WTC1.

Therefore, a trivial event shook the camera before the collapse of WTC1.
 
I don't think your matching is correct.
Just to check...you're aware that the graph is for the second aircraft impact, yes ?

My expectation is that the seismic peak matches approximately the peak in the first shake
The timescales between each dataset are very accurately matched.

Bear in mind that I have the video to hand to assist in synchronising trace data to physical events.

and that the second shake has a different cause (accoustic? different type of wave?).
Bear in mind that the video source is Sauret. Same location (almost) and camera as the well known WTC1 footage...
878183310.png



I think your match is quite speculative here.
I'm not claiming it's exact, but I think it's a reasonable match.

I may consider creating video for these things showing trace data progress synchronised to the source video. That should address your doubts considerably I imagine.

Well, my suggestion is too, but it has about the same basis as yours.
I don't agree.

I've just realized that the frequency of the ground vibration can obviously have a strong influence in the amplitude of the shake, depending on the resonance frequency of the tripod or whatever holds the camera [ETA: and even that of the building]. That makes it even harder to correlate seismic data with camera shake.
An exact match is not expected at all. Yes, the natural frequency response of numerous bodies will effect frequency content of both video trace and seismic data. Also to be borne in mind is that the seismic data is processed. The overlay is the LDEO released image, not the raw data I have. You are aware of their stated frequency processing, which at the moment we are both limited to understanding as 0.5hz high pass and 5hz low pass filters.
 
It does give an idea of the extent of the shake compared to the others.
Here's the graph...
545777892.png


As comparatives, “big time” is larger than “a tiny bit” which in turn is larger than “doesn’t shake.” No need for quantification
Poor.

It is clear from the graph the the peak amplitude of the second period of shaking is roughly half that of the first...

+/- 0.4 -vs- +/- 0.8
 
Here's the graph...
http://femr2.ucoz.com/_ph/7/545777892.png[img]


Poor.

It is clear from the graph the the peak amplitude of the second period of shaking is roughly half that of the first...

+/- 0.4 -vs- +/- 0.8[/QUOTE]

Who are you going to believe,
Your eyes and evidence
or femr2's squiggly lines.
 
My expectation is that the seismic peak matches approximately the peak in the first shake, and that the second shake has a different cause (accoustic? different type of wave?).
I'll do an overlay to the first peak anyway...
870149494.png

Hmm. Not great. And doesn't really allow any transmission time from source to camera.

Will perhaps see what comes out of suing the raw seismic data, rather than the low resolution image releases.
 
Last edited:
The previous impact alignment image for comparison...
303504488.png


Hmm. Need to do that video sync. May be that you are correct and the first shake is what the seismic data matches.

Would need to determine what the subsequent camera shake is caused by, and also why the seismic data doesn't include it.
 
Just to check...you're aware that the graph is for the second aircraft impact, yes ?


The timescales between each dataset are very accurately matched.

Bear in mind that the video source is Sauret. Same location (almost) and camera as the well known WTC1 footage...
Yes I am aware of all that, and I have no objection to the timescales.

Well, my suggestion is too, but it has about the same basis as yours.
I don't agree.
I have no problem with not agreeing with you, though a reasoning would be welcome.

I'll do an overlay to the first peak anyway...
[qimg]http://femr2.ucoz.com/_ph/2/870149494.png[/qimg]
Hmm. Not great. And doesn't really allow any transmission time from source to camera.
I like that better. Does the first sign of shake (I mean the one after the 499.7 mark) precede the plane crash?

Note for the overlays: since the images you overlay are B/W, you can add a layer mask as a grayscale copy of the layer, invert it and apply a levels correction to it, so that the white areas become transparent while the black areas are visible.
 
Last edited:
Does the first sign of shake (I mean the one after the 499.7 mark) precede the plane crash?
I need to do additional video sync to state a definitive answer there. The viewpoint is...
519112414.png

...so I need to match to additional video based on fireball position and behaviour. The frame shown is not at that time, but chosen to illustrate only.

Note for the overlays: since the images you overlay are B/W, you can add a layer mask as a grayscale copy of the layer, invert it and apply a levels correction to it, so that the white areas become transparent while the black areas are visible.
My preference will be to use the numerical seismic data, negating the need to perform any image overlays at all.
 
Numeric Seismic Data processing...
262185824.gif

Comparison between LDEO released image and filtered numerical seismic data in excel. (WTC 1 Descent)

Looks pretty much spot on to me.

The problem is that the raw seismic data, which includes a timestamp for each sample, is clearly at 80Hz, whereas the LDEO docs state 40Hz.

The image LDEO image above has therefore been scaled *0.5 relative to the time axis.

10s on the LDEO image is 20s on the raw data image.

As the graphs clearly match, this raises a significant question...

Why is the raw data sample rate, and specific timestamps, double that of the released seismic data images and verbal discussions ?

This has the implication that similar timescale multipliers must be performed for other comparisons.

Will have to see what they look like.
 
Last edited:
Comparison between LDEO released image and filtered numerical seismic data in excel. (WTC 1 Descent)

Looks pretty much spot on to me.
Yes, the differences seem to be just related to different filtering methods, i.e. different responses to individual frequencies.

The problem is that the raw seismic data, which includes a timestamp for each sample, is clearly at 80Hz, whereas the LDEO docs state 40Hz.
Maybe they used a lower resolution data set? No point in using a bigger one if they planned to filter frequencies above 10 Hz.

An alternative explanation is that the 40 Hz referred to the Nyquist maximum frequency response, not to the sampling frequency. But I don't think that's it.

Clearly their 3 hour graph shows a correct timeline.
 
Maybe they used a lower resolution data set?
That doesn't change the fact that the raw data has physical timestamps for each sample...

...and that 10s in the LDEO image equates to 20s of the raw data. (For graph fit, as above)

Either:

a) The per-sample timestamps are wrong.

or

b) The timebase for the LDEO image is wrong.

Here's a sample of raw data...
Code:
 30.994701	-2484.000000
 31.007202	-2514.000000
 31.019703	-2491.000000
 31.032204	-2496.000000
 31.044704	-2508.000000
 31.057205	-2499.000000
 31.069706	-2521.000000
 31.082207	-2505.000000
 31.094707	-2492.000000
 31.107208	-2526.000000
 31.119709	-2534.000000
 31.132210	-2521.000000
 31.144711	-2520.000000
 31.157211	-2522.000000
 31.169712	-2534.000000
 31.182213	-2549.000000

Clearly their 3 hour graph shows a correct timeline.
Do you have a URL ?
 
Last edited:
Well...

Looking at the images presented in the *KIM* PDF...

488942347.png


The data used for the above graph is the vertical component, rather than E-W, but I've got all three datasets for PAL and the durations match.

There is a single reference to data rate in the PDF...
Data were sampled at 40 times/s and passband filtered from 0.6 to 5Hz

I suggest this refers to the author discarding every other sample in the dataset to remove jitter. There is a clear alternate sample jitter in the data, which for my graph I applied a 2 sample running average to treat.

I'll generate a comparison for PAL vertical component from the raw data to confirm.

Then another to timespan of camera shake with similar filtering.
 
Last edited:
Overlay of above image to raw data...
871571.png


AGAIN the timebases don't match.

hopefully the filtered camera shake data will help clarify.
 
femr2 / Major_Tom,

Go look at one of the bigfoot threads and tell me why this is different. I'm being serious.
 
Splendid. As I'm sure you're aware, I've been looking for all possible signs of early *creep* for quite a while, given the numerous (incorrect) assertions that *progressive tilt* was not simply present, but visually observable, and for a period of 20 minutes or so.

Needless to say that even with high resolution digital photographs, allowing very small angular changes to be identified (far smaller than any visual inspection could possibly resolve), no progressive tilt was found.

Through application of tracing methods it has become possible to determine movement 9.5s before release, and also the point in time at which movement began or it's rate severely increased, that being, perhaps coincident to, the period of camera shake.

Again, before that point - no observable movement.
After that point - significant rates of movement.


Before that point - some movement (observable in some cases as cumulative displacement over time, not observable using available methods in other cases)
After that point - more/faster movement


Incorrect. I acknowledge that definition of t=0 must be parameterised, which is one reason why I use the word *release*, that being the point in time at which vertical velocity rapidly changes from effectively zero to full descent.


Once again, self-contradictory. A period of time over which the vertical velocity changes cannot be a point in time. There are no infinite accelerations.

You only get a point in time by assigning some specific value of velocity as a threshold value. You can then identify the point in time when the observed velocity reaches the threshold value. (ETA: Or you can similarly use a threshold value of displacement or acceleration.) But that is not t=0 in any physically meaningful sense. Some movement must have occurred before that time.

And the value you assign is arbitrary in any case. "Rapidly," "effectively zero," and "full descent" are not numbers.


Simultanaety is a physical impossibility, so there must be an order of sequence. Careful not to limit your viewpoint to a rigid body eh.

Yes, one definition of an event can overlap with any other, but...

Did failure of perimeter columns result in load transfer to core columns, or the other way around ?

The *failure* event did not occur on both* simultaneously.

*and of course *both* actually refers to many separate interconnected elements, all of which have their own separate behavioural timespans.


Simultaneity is certainly not a physical impossibility. As you yourself state, you are dealing with many separate elements connected in a not fully (and decreasingly) rigid structure, and many stages of actual failure of any single element. Is anyone claiming that every column of the south face reached, say fracture and/or buckling at least 30 degrees from vertical before any column of the core began distorting plastically, or anything of that nature? That's not what "failure began at the south face..." means.

In the real world, each increment of physical state change (elastic compression, elastic buckling, plastic compression or buckling, fracture) of each exterior column affected the load on every core column (and other exterior column) that remained connected, and each increment of physical state change of each core column affected the load on every exterior column (and other core column) that remained connected. So the correct answer to the question "Did failure of perimeter columns result in load transfer to core columns, or the other way around ?" is "definitely."

(If only there were some kind of rigorous quantitative analysis that could be done, to calculate the complex interactions of all those many elements. Perhaps using finite numerical methods to deal with the otherwise intractably complex differential equations involved.)

Sure, you can define some arbitrary velocity of some arbitrary point as "the *failure* event" and sweep all that real-world complexity under the rug. But when you do that, you no longer have any basis to for instance declare it physically impossible for those *failure* events to occur simultaneously, or use them to establish causality. "Hey look, the antenna moved before the *failure* event of the south wall" becomes a big "so what?"

Respectfully,
Myriad
 
Last edited:
I see what you did there

(If only there were some kind of rigorous quantitative analysis that could be done, to calculate the complex interactions of all those many elements. Perhaps using finite numerical methods to deal with the otherwise intractably complex differential equations involved.)

Good post Myriad. Especially this part:
Myriad said:
In the real world
 
Before that point - some movement (observable in some cases
Can you confirm that assertion ?

A period of time over which the vertical velocity changes cannot be a point in time. There are no infinite accelerations.
A bit pedantic. You know exactly what I mean, and that's why I use the word *release*.

To use an example, as you are wont...gradual movement took 1000 years to descend 1 inch, at a constant rate, then within one second the descent transitioned to freefall...I'd say the *release point* was at the start of that 1 second.

Simultaneity is certainly not a physical impossibility.
In the context of the south face *failing* at exactly the same time as the core...yes, it is.

Leading us handily back to the convenient construct of sequence.

So the correct answer to the question "Did failure of perimeter columns result in load transfer to core columns, or the other way around ?" is "definitely."
Suggest you repost over on the OOS thread, where this subject is more appropriate.

(If only there were some kind of rigorous quantitative analysis that could be done, to calculate the complex interactions of all those many elements. Perhaps using finite numerical methods to deal with the otherwise intractably complex differential equations involved.)
Makes you wonder why anyone would then write...

NIST said:
With continuously increased bowing, as more columns buckled, the entire width of the south wall buckled inward. Instability started at the center of the south wall and rapidly progressed horizontally toward the sides. As a result of the buckling of the south wall, the south wall significantly unloaded (Fig. 5–3), redistributing its load to the softened core through the hat truss and to the south side of the east and west walls through the spandrels. The onset of this load redistribution can be found in the total column loads in the WTC 1 global model at 100 min in the bottom line of Table 5–3. At 100 min, the north, east, and west walls at Floor 98 carried about 7 percent, 35 percent, and 30 percent more gravity loads than the state after impact, and the south wall and the core carried about 7 percent and 20 percent less loads, respectively. The section of the building above the impact zone tilted to the south (observed at about 8°, Table 5–2) as column instability progressed rapidly from the south wall along the adjacent east and west walls (see Fig. 5–8), resulting in increased gravity load on the core columns. The release of potential energy due to downward movement of building mass above the buckled columns exceeded the strain energy that could be absorbed by the structure. Global collapse ensued.

But again, I suggest you pick the subject up over on t'other thread.


I assume you are prepared to at least accept that rate of movement of numerous tower elements increased significantly ~9.5s in advance of *release* ?
 

Back
Top Bottom