The 9/11 Forum

femr2 · by **femr2** on Sat May 16, 2009 4:27 pm

Hambone wrote:Great work femr!
Doesn't this scenario include conservation of momentum? It matches my "conservation of momentum only" scenario almost exactly. That would explain the difference between the free-falling ejecta and the model.

Thanks. The 'free-fall' scenario does indeed include the velocity changes due to conservation of momentum, but as there is zero resistance, and the mass must be accelerated during the descent, it is still the minimum 'free-fall' descent for the tower.

I am not highlighting the free-falling ejecta, I am highlighting the ejecta from the right hand side of the tower. If you are having trouble seeing the ejecta, let me know and I'll upload another image highlighting it.

Photographical evidence indicates that most the core columns buckled over three floors and the exterior broke in huge sections. This would be one reason why the model is slightly slower.

No. There are no columns in the simulated descent...zero resistance. Only conservation of momentum due to the impacting masses. I'm aware that this is an inherently paradoxical process (perfectly rigid bodies cannot exist. perfectly inelastic collisions cannot exist) but it is a virtual model, so as long as we are all aware of the 'limitations' it's still useful.

I assume you are using an inelastic collision iteratively with the mass of each impacted floor. Another interesting factor is that the collisions are not really completely inelastic.

Yes. I assume you have downloaded the calculation spreadsheet ? (Link on OP). All the calcs are there:
http://femr2.ucoz.com/load/1-1-0-9

It might complicate the model too much, but including the coefficient of restitution would allow us to examine different possibilities within the realm of partially elastic collisions. The effect would essentially be less energy loss, which is more realistic. The big question is...how much?

I'm open to suggestion. If you have calcs that would work in step-wise fashion, and not result in asynchronous collisions, I'd be very interested if you could post them. (Just noticed your spreadsheet link. Will see if they are in there...)

A comment on realism. It is necessary to choose between concrete crushing and conservation of momentum. Concrete crushing is inherently included in conservation of momentum.

I don't agree. I'm aware that the energy loss through the conservation of momentum calculation must be made available for deformation of materials, but it is not limited nor directly related to concrete crushing at all. The model makes the energy available for any of the subsequent material deformations. Also, there cannot be a 'choice' between the two factors you mention as the primary effect of the conservation of momentum calculation is in the velocity change of the descending mass, through the requirement to accelerate the impacted mass from rest upon impact.

Here's my spreadsheet if anyone wants to check the calculations:
http://www.cool-places.0catch.com/911/calcCollapse_v3.xls

Thanks. I'll dig in.

femr2 · by **femr2** on Sun May 17, 2009 1:51 am

I've updated the spreadsheet.

Just clean-up and a couple of minor additions:

1) Ability to specify the percentage of max rated live loads for inside and outside core. (Can be overridden by specifying floor-by-floor values)
2) Front sheet modifier to specify the percentage of concrete crushed (can be overridden by specifying floor-by-floor values)
3) Switch to 'shed' external column mass on each impact (To reflect the 'peeling' behaviours discussed elsewhere)

http://femr2.ucoz.com/load/3

femr2 · by **femr2** on Sun Jun 07, 2009 4:13 pm

femr2 wrote:
http://www.youtube.com/watch?v=2hNGHGuYC-w&feature=PlayList&p=22FAFC72D202A6D7&index=2

Anyone fancy explaining how the debris ejecta on the right hand side of the Tower is so far ahead of the simulated free-fall descent ?

I didn't really get any response to this question.
I recently opened another thread which will be looking at the ejecta in more detail, so I thought it would be useful to re-post the question.

Heiwa · by **Heiwa** on Sun Jun 07, 2009 4:39 pm

femr2 wrote: I'm aware that this is an inherently paradoxical process (perfectly rigid bodies cannot exist. perfectly inelastic collisions cannot exist) but it is a virtual model, so as long as we are all aware of the 'limitations' it's still useful.

Is it? Why not make your upper part an assembly of material points connected by elastic links and treat the first and following collisions as elastic/plastic/failure?

OneWhiteEye · by **OneWhiteEye** on Sun Jun 07, 2009 5:06 pm

femr2 wrote:Anyone fancy explaining how the debris ejecta on the right hand side of the Tower is so far ahead of the simulated free-fall descent ?

Zone B thickness?

Edit: not trying to be flippant, the real collapse is a heterogeneous 3D affair, I don't expect strong conformance to 1D simplifications. Of course, the differences are worth exploring, with each step being more complicated. It is a good question, but one that should be examined carefully and in detail without rush to judgement. All I'm saying is, while you're on a 1D model and looking at direct comparisons, a more accurate comparison might include greater thickness in the crush layer.

Edit2: at 5 seconds, crush down only, the thickness is only about a third of an upper block, so my earlier comments have limited applicability.

femr2 · by **femr2** on Sun Jun 07, 2009 6:02 pm

Heiwa wrote:
femr2 wrote: I'm aware that this is an inherently paradoxical process (perfectly rigid bodies cannot exist. perfectly inelastic collisions cannot exist) but it is a virtual model, so as long as we are all aware of the 'limitations' it's still useful.

Is it? Why not make your upper part an assembly of material points connected by elastic links and treat the first and following collisions as elastic/plastic/failure?

Yes. If I move to a code based model that becomes possible, but the primary limitation of containment within a spreadsheet is the difficulty in modelling asynchronous collisions.

If you can think of a way to implement asynchronous collisions in a step-wise format, please let me know how you'd go about it.

If you have equations for elastic behaviour which can be applied in step-wise manner, I'd be very interested...

femr2 · by **femr2** on Sun Jun 07, 2009 6:21 pm

OneWhiteEye wrote:
femr2 wrote:Anyone fancy explaining how the debris ejecta on the right hand side of the Tower is so far ahead of the simulated free-fall descent ?

Zone B thickness?

Edit: not trying to be flippant, the real collapse is a heterogeneous 3D affair, I don't expect strong conformance to 1D simplifications. Of course, the differences are worth exploring, with each step being more complicated. It is a good question, but one that should be examined carefully and in detail without rush to judgement. All I'm saying is, while you're on a 1D model and looking at direct comparisons, a more accurate comparison might include greater thickness in the crush layer.

Edit2: at 5 seconds, crush down only, the thickness is only about a third of an upper block, so my earlier comments have limited applicability.

For your clarity, the bottom of the red block is the bottom of the 'crushing front'. Ignore anything above that. (There is a partial rendering of the resultant crush layer , but it's not intended to be precise, as the underlying mathematical model does not produce such data at this point)

Please remember that the 3d view is simply a visualisation of the timing data.

Even though the model is 1D, it is a resistance free simulation of the correct masses impacting.
Could you explain your perspective on how destruction within the tower resulting in the highlighted ejecta could occur faster than a simulated free-fall ?

Heiwa · by **Heiwa** on Sun Jun 07, 2009 6:56 pm

femr2 wrote:
If you can think of a way to implement asynchronous collisions in a step-wise format, please let me know how you'd go about it.

If you have equations for elastic behaviour which can be applied in step-wise manner, I'd be very interested...

You have to treat the first and every subsequent collision with an Euler-Lagrange equation of motion including all masses (material points) involved and include a Newtonian frictional viscosity term representing damping.

It seems your model consider upper red part rigid, undestructible, and it will evidently destroy anything in its way, including the ground at the end of the run.

Start improving your model making upper part elastic, non-rigid!

OneWhiteEye · by **OneWhiteEye** on Sun Jun 07, 2009 7:00 pm

femr2 wrote:For your clarity, the bottom of the red block is the bottom of the 'crushing front'. Ignore anything above that. (There is a partial rendering of the resultant crush layer , but it's not intended to be precise, as the underlying mathematical model does not produce such data at this point)

I assumed it to be the case, I'm just saying the compacted stories take up some space, while the upper block is assumed to have a constant vertical height. Until you do have compaction / stretch/ slab thickness incorporated, expect the actual location of the crush front to be lower than the bottom of the upper block by a distance roughly equal to a third the upper block's height. (edit: at the five second mark in 1D mv-only with fixed 0.2 stretch)

Please remember that the 3d view is simply a visualisation of the timing data.

Yeah, got that. Nice debris fountain in the rendering, by the way. Very cool.

Even though the model is 1D, it is a resistance free simulation of the correct masses impacting.
Could you explain your perspective on how destruction within the tower resulting in the highlighted ejecta could occur faster than a simulated free-fall ?

Taking note that you're asking me one of the real 64,000 euro questions, I'll take care in how I answer. Excluding speculation, the answer is I don't know. With that out of the way, let the speculation run rampant.

Starting with the basics... I haven't taken time to analyze, in detail, how the 1D simulation has been synced to the actual fall. I'd expect significant mismatch right out of the gate. You can match a portion, maybe, but not the whole thing. So that leads to the question of why the mismatch is evidenced as outpacing the momentum-only model?

Good question, and here's the speculation: The real collapse bore only the slightest similarity to an inelastic step-wise simulation. There was little buckling, most resisting force due to structural 'capacity' was rendered moot by the collapsing material geometry, significant amounts of structural material was bypassed and/or shoved aside. Much of the perimeter facing the camera is still standing at this point. The actual crush zone was not uniform laterally, not all the collisions were inelastic, and much more than 'harmless elastic waves' may have been propagated into the lower structure. In light of that, I'm not willing to brush the synchronization issue aside, there's the potential for local catastrophic failure on the south side preceding global failure by as much as 3 seconds, and encountering much less resistance per driving mass than the structure as a whole, as considered in a 1D model.

I'm not a proponent of the standard models, though I use them. My speculations should not be construed as endorsement or defense of them, rather speculation means I'm not pigeonholed by them. Ha, for all I know, ("disgraced") Cherapanov is the most correct of all, though maybe via flawed mechanics or reasoning. I would not immediately rule out propagation of failure ahead of descending mass. The arguments in B&L are not sufficiently compelling against the context of the real collapse environment to conclude that failure is limited to the Zone B lower edge. Personally, I'm quite convinced it isn't, but I could be wrong and I'm no one to listen to on the subject.

It could be a series of charges. But isn't there a lot of ground to cover before reaching that conclusion?

femr2 · by **femr2** on Sun Jun 07, 2009 7:44 pm

OneWhiteEye wrote:I assumed it to be the case, I'm just saying the compacted stories take up some space, while the upper block is assumed to have a constant vertical height. Until you do have compaction / stretch/ slab thickness incorporated, expect the actual location of the crush front to be lower than the bottom of the upper block by a distance roughly equal to a third the upper block's height.

Hm. At the moment, I use the full height of each storey during each inter-floor-impact free-fall descent. It would be a fairly simple exercise to reduce the inter-floor drop height to account for the floor structure thickness (though I'd suggest a slightly reduced height to account for floor truss compaction, even though the mechanics do not include it's collapse, yet).
Would that satisfy this factor to a reasonable extent ?

Taking note that you're asking me one of the real 64,000 euro questions, I'll take care in how I answer. Excluding speculation, the answer is I don't know. With that out of the way, let the speculation run rampant.

Thanks. Nothing wrong with speculation. It provokes questions, and answers :wink:

Starting with the basics... I haven't taken time to analyze, in detail, how the 1D simulation has been synced to the actual fall. I'd expect significant mismatch right out of the gate. You can match a portion, maybe, but not the whole thing. So that leads to the question of why the mismatch is evidenced as outpacing the momentum-only model?

The basic synchronisation method is that the underlaid video is started at the exact same time as the descent simulation. The video is 'trimmed' such that the start frame of the video is the start of 'collapse'. I thought this would be the cleanest method as it allows you to choose a video with a start point defined by the start of the video. If you want to provide a video with the start frame set to your required collapse simulation start point...no problem.
Video display and synchronisation is part of the visualisation app itself. It's not a separate process.
The update interval of the simulation is arbitrary (any time to at least 8dp in seconds) but is based on floor impact timings, so at this time it's only guaranteed to match the spreadsheet data at the point of each floor impact. (That's why the textual data only updates at each impact point)
The update interval of video is simply framerate based, but directly associated with the simulation 'time'. (Scrub back and forth from the start of simulation to the end, and back again...and the video follows)

Add: Fitting the actual rendered tower is a user driven process. The position of the tower is fully free-form in all axes. I personally use building edge features to ensure as accurate match as possible. Specifically roofline and mechanical floor regions. Foreshortening is also part of the process I try to match against. I'm working on including some form of absolute viewer positioning, but the intricacies of the effects that the video camera that filmed any piece of video footage introduces makes it a bit redundant (video camera lens effects for instance)

Good question, and here's the speculation: The real collapse bore only the slightest similarity to an inelastic step-wise simulation.

Agreed.

There was little buckling, most resisting force due to structural 'capacity' was rendered moot by the collapsing material geometry, significant amounts of structural material was bypassed and/or shoved aside.

I'm a little unclear here. Why was structural capacity rendered moot, and how do you view the collapsing material geometry ?
From MT's peeling perimeter studies (and study of GZ photos), there does not appear to be any significant material still attached to them...no floor segments... When you say material bypassed or shoved aside, would that not imply there would have been segments of floor still attached to the peeling external panels ?

Much of the perimeter facing the camera is still standing at this point. The actual crush zone was not uniform laterally, not all the collisions were inelastic, and much more than 'harmless elastic waves' may have been propagated into the lower structure. In light of that, I'm not willing to brush the synchronization issue aside, there's the potential for local catastrophic failure on the south side preceding global failure by as much as 3 seconds, and encountering much less resistance per driving mass than the structure as a whole, as considered in a 1D model.

Would you like to see a similar freefall simulation with very much reduced masses ? (I can drop the floor mass effectively to zero. Say 1000 kg ? 10000 ?) There's still zero resistance in the modelled descent shown.

It could be a series of charges. But isn't there a lot of ground to cover before reaching that conclusion?

I very rarely mention the "d" word. I prefer to approach the problem from the other side of the fence by asking the kind of question you're eloquently responding to.

OneWhiteEye · by **OneWhiteEye** on Sun Jun 07, 2009 8:51 pm

femr2 wrote:Would that satisfy this factor to a reasonable extent ?

Wholly, I believe.

The basic synchronisation method is that the underlaid video is started at the exact same time as the descent simulation.

OK, that makes sense. The 1D discrete approximation with no resistance is going to start at (near) g but rapidly approaches about g/3. After initiation, which is quite a smeared-out interval of time, the real collapse fits ~2g/3 over the majority of the five seconds, then starts dropping to zero acceleration, terminal velocity, also quite rapidly. Which wins at the five second mark? Don't know, haven't worked it out. In any case, it would be working to an idealization, OK in itself but not necessarily reflective of real characteristics. Synchronization is paramount, starting a half or even a full second later than stuff starts moving down on the inside south side could make a big difference.

I'm a little unclear here. Why was structural capacity rendered moot, and how do you view the collapsing material geometry ?

I think the driving mass we're talking about is mostly rubble, the rubble falls inside the area between perimeter and core, the core is eroded and the perimeters pushed aside. Except for perhaps where the (remains of) cap is ripping down the south wall at very near g. Speculation, remember.

Here are some GIFs I trot out at the slightest provocation, but I like what they show. I think there's something that helps explain the gist of what I'm saying:

http://i32.tinypic.com/hra1cx.gif

http://i33.tinypic.com/10cq0qc.gif

http://i36.tinypic.com/33a9ms7.gif

Also, here is a nice illustration from Major_Tom; think of it as mood music:

http://the911forum.freeforums.org/crush-down-models-t145-90.html#p2493

From MT's peeling perimeter studies (and study of GZ photos), there does not appear to be any significant material still attached to them...no floor segments... When you say material bypassed or shoved aside, would that not imply there would have been segments of floor still attached to the peeling external panels ?

Don't know. Supposedly the majority of of floor connections in the lower part were sheared vertically. If so, it doesn't fit very well with my speculation that there would be a mix of tension and rotation (hinge) failure.

Would you like to see a similar freefall simulation with very much reduced masses ? (I can drop the floor mass effectively to zero. Say 1000 kg ? 10000 ?)

I always encourage careful playing around, so sure, if you do it and want to post it, I'll look at it! That said, there is only so much time, so I fully understand not doing it or not posting it if you do. Not sure how much will be learned, must claim ignorance here, too. I'm pretty well convinced that the current technical perception of the collapses is a self-inconsistent hodge-podge of models, most of which I only partially understand! Then, I have my own whacked-out ideas...

I very rarely mention the "d" word. I prefer to approach the problem from the other side of the fence by asking the kind of question you're eloquently responding to.

Well, I don't mention it much either, and the above should not be taken to mean I believe there's going to be a pot of CD at the end of this very long and arduous rainbow. If there were, I doubt it would be discovered by this sort of analysis. On the other hand, I think it's a fascinating area of research simply because much seems to defy conventional intuition and even expert intuitions. On that basis, I can't say I'm surprised by anything in a so-called natural collapse unless or until I understand what that's supposed to look like. Not bloody likely, from my current vantage.

I raise the question because it's natural in this forum, it may not apply to you. It is the raging tyrannosaurus in the corner of the room. If it's not your thought, then disregard it, no offense meant. If it does apply, then it's a reasonable question to ask, but I wish I hadn't. Please disregard it, anyway.

femr2 · by **femr2** on Mon Jun 08, 2009 10:18 pm

Until you do have compaction / stretch/ slab thickness incorporated, expect the actual location of the crush front to be lower than the bottom of the upper block by a distance roughly equal to a third the upper block's height.

I've traced the implications through and updated my local model.
I've not quite finished the rendering changes, but thought I'd confirm the behavioural differences:

a) The 'bottom' of the rendered upper block does not change, as the 'compacted' floors are actually above that level. (Because I was previously using the full floor height). The inclusion of floor thickness results in the stack of compacted floors but the actual end result is that the roofline does not descend as far, rather than the 'actual location of the crush front to be lower than the bottom of the upper block by a distance roughly equal to a third the upper block's height'. Hope that makes sense.

b) The effect of the reduced drop height does result in a slightly shorter collapse time for a free-fall scenario. However...

c) For other scenarios that include 'energy sinks' such as structure failure, crush energy, mass loss, ...the reduced drop height results in a longer collapse time.

For the view being discussed within the prior images the end result is that the bottom edge of the descending mass block is only very slightly different, due to minor collapse time change (Though the roofline is a fair bit higher)

I'll get supporting spreadsheet and video up shortly, but essentially, no significant change to the lowest point.

For reduced mass descents (to look at the implications of a split north/south collapse scenario) there is little difference in collapse time for a half mass descent (~0.25s). For a quarter mass descent, same again, another ~0.25s reduction. I'll get around to rendering these views soon.

femr2 · by **femr2** on Tue Jun 09, 2009 2:23 am

The model has been updated to take account of the floor thickness.
The resultant post impact floor 'thickness' is a normal variable parameter.
I'll get the spreadsheet download updated shortly, but the following video illustrates the new behaviour:

http://www.youtube.com/watch?v=xJSjbxFoJ8M

http://femr2.ucoz.com/photo/1-0-57

Energy requirement to actually collapse/compact the floor materials has not yet been included.
The referenced view is free-fall. Zero resistance, zero mass loss...
The resultant compacted floor thickness is set to 0.55m

(The actual floor assembly thickness is 0.7492m. The selected 0.55m value is 'very' reasonable IMO as the contents of each floor also have to fit in the vertical space...furniture, computers, filing cabinets, lift shafts, stairs...)

The following visual updates have been included:
* Floor thickness
* Specific floor heights
* Floor number label scaling

OneWhiteEye · by **OneWhiteEye** on Tue Jun 09, 2009 9:50 am

You're quite handy with OpenGL; very attractive!

femr2 wrote:a) The 'bottom' of the rendered upper block does not change, as the 'compacted' floors are actually above that level.

I learned something here, should've been more careful before I spoke. It doesn't all get added to the bottom, for sure. But neither does it all get added to the top. Had to stop and think about this a while.

In a zero thickness model, the upper block drops a distance of h in freefall before making contact with the next floor, at which point the inelastic collision takes place and velocity of the N+1 slabs is recalculated. It takes sqrt(2h/g) seconds to reach displacement h. Pre-collision velocity is v = g.sqrt(2h/g) and post-collision is N/(N+1) times that amount. If N is 12, it's a small reduction, less than 8%.

With stretch s, the upper block drops a distance of (1-s)h in freefall before making contact. It takes sqrt(2(1-s)h/g) seconds to reach displacement h! That's where the bottom is now, it got there quicker than the zero thickness model, about 11% quicker for s=0.2. The displacement of the zero thickness model is, by definition, only (1-s)h. The upper block is not going as fast when it hits, but it is robbed of the same fraction of velocity and then proceeds to freefall again and repeat the cycle. All we really need to determine is which gets to the next floor first. Pre-collision velocity is v' = g.sqrt(2(1-s)h/g) and post-collision is likewise N/(N+1)v'. Etc. Time to turn to code, so I whipped out this...

Code: Select all: class Collapse attr_accessor :height, :stretch, :block, :stories def initialize(height, stretch, block, stories) @height = height; @stretch = stretch; @block = block; @stories = stories; @distance = dropDistance(height, stretch); @compacted = @stretch * @height; @block_height = @block * @height; puts("nFloors,t,crush_y,v,B_thickness,roofline"); step(0.0, (@stories - @block)*@height, 0.0, @block); end def step(t, y, v, nFloors) b_thickness = (nFloors - @block) * @compacted; roofline = y + b_thickness + @block_height y = 0.0 if y < 0.01; puts([nFloors, t, y, v, b_thickness, roofline].join(",")); td = timeToDisplace_freefall(v, @distance); preVelocity = v + velocityGain_freefall(td); postVelocity = postCollisionVelocity(preVelocity, nFloors); return if nFloors >= @stories; step(t + td, y - @height, postVelocity, nFloors + 1); end def g 9.81 end def dropDistance(height, stretch) (1.0 - stretch)*height end def timeToDisplace_freefall(v0, y) (-v0 + Math.sqrt(v0*v0 + 2.0*g*y))/g end def velocityGain_freefall(t) g*t end def postCollisionVelocity(v, nFloors) v*(nFloors.to_f/(nFloors.to_f + 1.0)) end end stretch = 0.2; #or zero height = 3.7; block = 12; stories = 110; Collapse.new(height, stretch, block, stories);

which produces this for Zone B bottom (blue is 0.2 stretch, red is 0):

and this for the roofline:

This is in good agreement with simulations in a physics engine I've done, which indicates most of the extra thickness goes down.

The standard run for me is 0.2 stretch (0.74m, larger than your default) and equal masses. Just to explain the lenses I've been looking through, mostly. When I do a comparison of stretch 0.2 with 0.02, the roofline displacement isn't that much different at 5 seconds, but the lower edge of the crush layer is quite a bit lower.

Recognizing that equal floor masses is not too realistic, the masses were scaled linearly from the bottom up, with the bottommost roughly 10x heavier than the topmost. That should about do it. The strength of the connections (I don't really have a freefall scenario) had to be adjusted up to accommodate the extra weight, in all cases there was a substantial margin of capacity over static load. The top also rode higher in these trials, even more so than with equal masses, but there was still a greater accumulation at the bottom.

This graph is quite a mess, but there is some method. There are eight curves. Top and bottom, stretch 0.02 and 0.2, equal mass and scaled mass. Stretch 0.2 is shades of green, 0.02 shades of red. The heavier structures are the darker colors, equal mass is lighter. Finally, top and bottom of each trial are matching colors.

These show greater accumulation at the bottom (compare dark vs dark and light vs light), though the top does ride higher. I should probably mention that I'm using a unit mass of 1kg, and I'm shy two stories plus some height on these structures, but doubt that matters much in regards to this qualitative issue.

Then again, I could be wrong...

Heiwa · by **Heiwa** on Tue Jun 09, 2009 4:14 pm

[quote="femr2"]The model has been updated ... the following video illustrates the new behaviour:

http://www.youtube.com/watch?v=xJSjbxFoJ8M

/quote]

3 seconds to crush 13 floors and 10.52 seconds to crush 98! All nicely piled up - pancakes? - while upper part is 100% intact all the time! It doesn't look real. Are you working for Hollywood?

Consider the upper and lower parts as assemblies of material points linked together in structures with 95% air volume wise. The upper part is floating, the lower one is fixed on ground.

The material points can be your floors and the links can be the columns. Then remove the links between floors 99/98 and allow floor 98 to hit floor 98 due to a gravity drop. What happens?

Forces develop and are transmitted via the links to all material points and ground at high speed, say 5000 m/s. This means all material points/links are affected at first contact. The material points move!

Assuming then, as you do, that links between floor 98/97 fail and floor 98 drops on floor 97, the same thing is repeated again. New forces are developing and are interfering with the first set of forces.

I would suggest that all these forces affect the upper part to some extent.

The 9/11 Forum

WTCCS Spreadsheet Crush-Down Model

Re: WTCCS Spreadsheet Crush-Down Model

Re: WTCCS Spreadsheet Crush-Down Model

Re: WTCCS Spreadsheet Crush-Down Model

Re: WTCCS Spreadsheet Crush-Down Model

Re: WTCCS Spreadsheet Crush-Down Model

Re: WTCCS Spreadsheet Crush-Down Model

Re: WTCCS Spreadsheet Crush-Down Model

Re: WTCCS Spreadsheet Crush-Down Model

Re: WTCCS Spreadsheet Crush-Down Model

Re: WTCCS Spreadsheet Crush-Down Model

Re: WTCCS Spreadsheet Crush-Down Model

Re: WTCCS Spreadsheet Crush-Down Model

WTCCS Spreadsheet Crush-Down Model

Re: WTCCS Spreadsheet Crush-Down Model

Re: WTCCS Spreadsheet Crush-Down Model

Who is online