• Quick note - the problem with Youtube videos not embedding on the forum appears to have been fixed, thanks to ZiprHead. If you do still see problems let me know.

The physics toolkit

So let me get this straight.
Straighter than I've already made it ? If you need I suppose.

The NIST conclusion, is still acceptable?
Who knows ? What point did they use ? Was it the earliest t=0, or the latest ? Does the method actually come out with the same timing a better method would ? Did they even realise the problems and variable nature of stating t=0 ?

I've already explained reasons for these uncertainties.

Just not what you would have done to reach it?
Not *just not*, no. It's a poor method, with uncertain results, with factors associated that either those at NIST did not bother to describe (and so take account of) or did not understand.
 
From looking at the filtered data below, two things are pretty clear:

1. the initial value for the vertical position (y) is not equal to 0, but approximately 0.6.

2. The previous t0 I picked is therefore too late. The slope is not zero at this t0. A reasonable t0 in femr's data should be around the {4.3, 0.56} point that I've indicated.
Still don't see the images I'm afraid. Odd.

Could you let me know what dataset you used ?

I'll see how the vertical/horizontal inflexion method stacks up against your suggested value.
 
Physics vs. engineering...

I'll be discussing only the vertical component of position (y), velocity (vy) and acceleration (ay). Not the horizontal components.

In this data, there is no such thing as "t0".

The definition of t0 is the last time value where y = y0 (the initial height) & vy = 0.

The data shows that there existed no such well defined point near the beginning of the collapse.

First, there is noise, which can be filtered. But the value of t0 that you get after filtering directly depends upon the filtering that you choose to use. Which is the "right" filtering? There is no "right" one. Some are better than others, but there is no objectively right one.

Still, noise alone would not prevent one from getting a "reasonable" answer (with error margin), if it weren't for the next problem.

More important, the roofline did not know about people's desire for it to fall in a clean, mathematically-simple fashion. So it fell, instead, in the way that structures really do when they break: messy & complex. **

And, unsurprisingly, there were a couple of lurches just at the beginning, as the buildings was tearing itself apart.

So, the start of your "free fall" is buried in a bunch of "building tearing itself apart" noise. And you ain't gonna be able to pick it out with any objectivity or reliability.

You're welcome to continue trying, of course.

My intent is to do the following:

Use a technique that does not depend on either t0 or y0 for its results.

Use a "smooth, noise-robust differentiator" on the raw data.
See http://www.holoborodko.com/pavel/?page_id=245

Since none of the models that I've tried will follow the data adequately over the whole range, I'm going to break up the data set into small sections (~ 1 second long each).

And I'll look at velocity changes within each section, which don't depend on height or collapse starting time.

And, now, a prediction:

When I get done, I'll have an acceleration PROFILE over the whole data set. And I predict that this profile will look nothing like a free fall acceleration profile in either a vacuum or in air.

And this whole thing will have turned into "a tale, told by an idiot, full of sound and fury,
signifying nothing."

Sorry, femr. "Idiot" was ole William's turn of a phrase.

And since I know exactly where this little clusterjerk will all end up, for wasting several hours on this nonsense, the term applies more to me than to anyone else.


Tom

PS:
** BTW, when buildings are demolished with explosives, they do go from stationary to free fall much more abruptly. Explosives "kick the legs out from under the building" by destroying low supports. The initial acceleration profile is close to a true free fall's step function from 0 to 32.2 ft/sec^2.

And nothing like the North Wall's slow, gradual increase in acceleration.

And absolutely nothing like WTC7's "13 seconds from start of collapse to start of north wall collapse".

Just thought I'd point that out.
 
Last edited:
I'll be discussing only...

Again, could you let me know what data-set you used ?

ETA: There's not going to be drastic difference from results already presented without changes to the base scaling metrics, but by all means look at alternate noise reduction methods. Quite what point you're trying to prove with your bad attitude is rather baffling, but I think most folk are used to your whining ways. Be aware that I've not supplied scaling metrics for the latest data yet. Am not really interested in the interrim cam#3 data any more. Dan Rather base data is still fine, but may require slight scaling metric changes. Don't say you weren't warned ;)
 
Last edited:
Who knows ?

Not you apparently. I asked a very straight forward question. I'll try one last time.
Does your way, change the final conclusion, assessed by NIST? Yes, or no.
If you still refuse to answer in a direct manner, I understand!

Good day.
 
Again, could you let me know what data-set you used ?

The data from camera 3 that you provided HERE.

Which matches the graph & time base plotted in your graph HERE.

The graph below (in a different format) shows the raw data & a 13 point averaging filter, to match the value that you said you used.

picture.php


As I said, one condition for t0 is that the vertical velocity be zero. That is, the slope of the red curve be zero. The old initial point doesn't meet that requirement. It has a significant downward velocity.

ETA: There's not going to be drastic difference from results already presented without changes to the base scaling metrics, but by all means look at alternate noise reduction methods.

There is not going to be changes to the position vs time data.

But filtering has huge impacts on the calculated velocities & especially - the principle topic of this whole furball - the accelerations. That is the whole point of this.

This was the cornerstone of Chandler's "analysis": deriving accelerations from position data.

Quite what point you're trying to prove with your bad attitude is rather baffling,

You think that the fact that a truther considers that I have "a bad attitude" is a problem for me..?!

You REALLY don't get it, do you?

... but I think most folk are used to your whining ways.

LoL. I can understand why you think (hope) my comments are "whining".

Folks who claim to speak for the masses seldom have other compelling arguments.

I do, however, confess a preference for blunt honesty, the willingness to take a stand on things, to speak your mind. And even to take a few intellectual risks.

I'll leave to you the convenient bashfulness of "I'm not going to speculate on any implications of any data" and the evasiveness of "my truther status is irrelevant".

Refusing to participate in thoughtful, competent "If ..., then ..." discussion is precisely how truthers barricade themselves against reason.

Oh yeah, that, and "just asking question." The "Sorry, not interested in the answers" usually goes unstated. But not unnoticed.

Your truther status would be irrelevant if it truly did not impact your "nonconclusions". But it does. Massively.

You put out reams & reams of data, full of innuendo. Until someone asks you to state your opinion simply & honestly. Only then does the disclaiming & backpeddling begin.

Those who don't have the time or background to probe your data & methods, and to see its flaws, are taken in by piles & piles & piles of ... fluff. That supports, when you get to the details, nothing.

And even though you have stated your status ("openly MIHOP") publicly, why is it that you'll do that only "amongst friends"?
 
Not you apparently. I asked a very straight forward question. I'll try one last time.
Does your way, change the final conclusion, assessed by NIST? Yes, or no.
If you still refuse to answer in a direct manner, I understand!

Good day.

As I've highlighted, there is no way to know whether the NIST suggested t=0 time is accurate, or indeed which t=0 it relates to, as they have not stated the actual location.

I've answered you very directly, and suggesting refusal in any form whatsoever is simply ludicrous.

The graph included in the post you were responding to included an earlier t=0 point than that suggested by NIST.

If the intention of NIST was to actually state the time of the first moment of vertical drop, then yes, they came to the wrong conclusion. It's a wee bit earlier.

Doesn't make a huge difference on the scale of things, though does affect their *40% of freefall* metric somewhat, especially as various parts of the building have differing t=0 metrics.

A reason for mentioning their poor method is the analysis of over-G acceleration being performed during this thread, which requires understanding of the t=0 problem to fully get to grips with.

The process NIST utilised strikes me as a very poor method to determine t0.

And Good Day also unto your good self sir.
 
The data from camera 3 that you provided HERE.
Thanks, though that is the Dan Rather 59.94fps data, not the NIST camera #3 data. Graphs are clearly titled with Dan Rather.

The graph below (in a different format) shows the raw data & a 13 point averaging filter, to match the value that you said you used.
Still don't see your images I'm afraid. Could you clarify *to match the value that you said you used* ? Not sure what you mean.

As I said, one condition for t0 is that the vertical velocity be zero. That is, the slope of the red curve be zero.
That's not going to work. Would be handy if it did, but flex data is mixed with vertical drop data. Unless you somehow *unmix* the sources...

But filtering has huge impacts on the calculated velocities & especially - the principle topic of this whole furball - the accelerations. That is the whole point of this.
The actual underlying velocities and accelerations are not going to change. Perhaps your noise-treatment method will provide a clearer view, but as I said I doubt there will be any great difference. Over-G appears to be in the data, regardless of noise treatment method.

You put out reams & reams of data, full of innuendo.
Not at all. As I've indicated to you before, it's your pre-disposition that's a problem there. I'll certainly be drawing some conclusions from the data at some point, but I'm certainly not going to be doing so without ensuring that the scaling metrics are as good as I can get them. That's going off half-cocked. Not a pretty sight ;)

Those who don't have the time or background to probe your data & methods, and to see its flaws, are taken in by piles & piles & piles of ... fluff.
Wow. I couldn't be clearer or more open about the methods, and the data has been provided in it's entirely raw form. I find it hilarious that you have spent the last couple of weeks criticising these datasets, have been continually and repeatedly corrected by multiple members, and yet have produced zero data, nor found any errors within any of the data. And you're USING the data. Wow. You will also note that I have not yet made any conclusions, as I'm still getting the data together. We all know where the fluff is coming from though, don't we, Tom.

Would be much more productive if you could have stopped at the point where you let me know what set of my data you were using. Pity you got it wrong.
 
The previous t0 I picked is therefore too late. The slope is not zero at this t0. A reasonable t0 in femr's data should be around the {4.3, 0.56} point

As I can't see your graphs, am assuming you mean this point...
382403941.png


Have included the horizontal data (unscaled) so you can see how they correlate.

I'd place t=0 slightly earlier.
 
As I've highlighted, there is no way to know whether the NIST suggested t=0 time is accurate, or indeed which t=0 it relates to, as they have not stated the actual location.

So you're not sure. Got it!

I've answered you very directly, and suggesting refusal in any form whatsoever is simply ludicrous.
No you had not, and you're still trying very hard not to. Talk about ludicrous!
Doesn't make a huge difference on the scale of things,
Oh' you came so close. I'll take it though.
The process NIST utilised strikes me as a very poor method to determine t0
So in your opinion NIST used a poor method, but you're still not sure. Got it!
Sheesh, you sure like to dance.

Good day.
 
Last edited:
So you're not sure.
Yet again...as NIST do not specify the location of the pixel they used, it is not possible to determine if their t=0 value is correct for that location. In addition, by tracing of other features, it is clear that the t=0 time for other building features preceeds their single t=0 value. As they only specify a single t=0 value, and state it as *the exact instant that the north wall began to collapse*, they are wrong.

I do hope so. Having to repeatedly make such simple points clear is tiresome.
 
Last tango...

I do hope so. Having to repeatedly make such simple points clear is tiresome.
Next time just answer the question, without dancing all over the place.Kay?


PS
You still never gave a straight answer, but I'll take what I can get.
All of your bluster, does not change the conclusions.A simple no,to my question, would have sufficed.


Good Day.
 
Is anyone else having trouble seeing the graphs that I've posted?


tom
 
Next time just answer the question, without dancing all over the place.Kay?


PS
You still never gave a straight answer, but I'll take what I can get.
All of your bluster, does not change the conclusions.A simple no,to my question, would have sufficed.


Good Day.


LOL..another beautiful evening, and yet the same thing occurs...FEMR is once again floundering here trying to support his nonsense while getting his uneducated posterior handed to him.

Psssst..FEMR...take a physics class.

Don't you ever learn?
 
Someone correct me if I'm wrong....

But in skimming this thread there seems to be several issues to consider when trying to draw conclusions from the "video" data...

1. "External" errors introduced by something like the camera shaking.
2. "Internal" errors introduced by the quality of the video...things like distance from the building, frame rate, etc.

These two would combine to make the video "noisy" which could be dealt with, at least to an extent, with processing algorithms designed to filter out noise.

3. Choice of "starting" point.

I'm sure there are more, but in skimming this thread so far instead of taking the time to carefully read it this is what I'm getting.

Each choice of how one calculates things like velocity, acceleration, etc and what methods are used to attempt to eliminate noise will affect the "end of the day" calculations.

And since we have already discussed how even IF there is some "faster than free fall" or "equal to free fall" speed, this can be explained by other things besides explosives.....

Wouldn't the reasonable thing to say is that none of this data conclusively proves explosives or even implies it strongly and so we must go with the more likely conclusion that even if we are seeing a real acceleration then the cause is probably something much more mundane than explosives?

Am I way off base here?
 
Wouldn't the reasonable thing to say is that none of this data conclusively proves explosives or even implies it strongly and so we must go with the more likely conclusion that even if we are seeing a real acceleration then the cause is probably something much more mundane than explosives?
Yes.

Am I way off base here?
No.
 
Is anyone else having trouble seeing the graphs that I've posted?


tom
I can see them. It seems i's not a problem of the graphics format, but rather of the fact that they're attachments. (ETA: Probably an incompatibility with femr2's web browser or settings or ad-block or antivirus.)

If you give me your permission, I can temporarily host them at my site so that femr2 can see them.
 
Last edited:

Back
Top Bottom