I have yet to hear from Ryan. Whoever contacted him about the simulation, it was not me. I suggest that he contacts me here.
I am quite happy to answer questions.

Again, I have not been in contact with Ryan, and whoever he is conversing with, it is not me.
I am quite happy to discuss the simluation in full here.

There are currently a massive 2 members, so I do not think that a one-on-one discussion is a problem.
If discussion derailment from others is a concern I have no issue locking this forum such that only posts from myself and Ryan are allowed.

Hopefully Ryan will decide to approach me directly, here.

The list of questions posed has been sent over, and I shall repost them here along with appropriate answers.

I am not aware of any conversation other than what I post here, so Ryan, when you do decide to comment here I would appreciate it if you refrain from any 'truther'/'debunker' discourse. I would, of course, be 'branded' with the 'truther' mantle given my very clear and firm viewpoint, but as I am sure you are aware, this simulation is clearly intended to be used as an educational and hypothesis testing medium, rather than any form of 'definitive' 'proof' of either side of the 'argument'.

My intention is to gradually extend the model over time, to incorporate more and more sophisticated mechanisms, including elastic collisions and more specific floor-by-floor parameters. (Such as specific mass loss through identification of ejecta). I will also be including the initial 'top-down' crush process evident for WTC 1 and a cap crush mechanism (although it is clear that in reality the cap itself did not survive the descent in any useful form)

Anyway...

C-O-M energy loss is now enabled for use in subsequent deformation of materials.

No. There is no requirement for uniform destruction of all concrete.

The concrete crush energy sink can be switched off entirely, or either of two distinct selectable methods can be applied:

1) A user specifiable constant energy usage (in joules) for the crushing of concrete. Applied per-floor.
or
2) A user specifiable particle scale range (top to bottom) (in microns) applied on a floor-by-floor linear ramped scale, with a current limit of up to 500 micron (although of course this can be easily extended by the user. It's a linear energy usage scale)

The first method does not relate to concrete volume at all, only energy consumed per floor, and so is a fully specifiable constant allowing the user to use a value equivalent to the crushing of zero concrete thru to all concrete, and using their own external methods for determining the amount of energy required to do so.

Mechanically the second method does apply to the full concrete volume of each impacted floor, but again, the scale of the crush can be changed as described above. Many sources state an 'average' concrete crush scale well below the current maximum of 500 micron, which is why the limit was set as such. It could easily be extended to a maximum of say 1m if the user chose to.

I assume that by 'pile' you mean the descending mass I refer to as the 'cap' ? (As in pile-driving mass)

Further extension of the model will include the ability to specify mass loss on a per-floor basis for each possible material.
This extension will allow per-floor specification of the concrete volume crushed and per-floor max/min crush scale.
Additional energy sinks will also be included for the crushing of other materials, which are currently not included.
At this point, only the crush energy for concrete is included (if non zero). Crush energy required for dry wall, furnishings, fittings and a wealth of other required crush 'bodies' will also be included.

Mass loss can be omitted entirely, or included as described below.

The ejected mass fraction is specified by two separate values:

1) A percentage of the 'Cap' mass, pre-impact.
and/or
2) A percentage of the impacted floor mass. (Storey)

Both of these values are clearly labelled.

Either or both can be set to a user specified percentage, including zero, or switched off entirely (Equating to zero for both, but allowing any percentages entered to be retained in the sheet).

These factors negate the verbose implications you describe.

The model will be extended in the future to include per-floor specifiable mass loss, per material, enabling much more precise control. I'm intending upon identifying specific ejecta from video footage as part of the exercise. Separation of external column structure mass will also be included within the model to account for the probable quantities of external columns which played no part in further descent, and did not form part of the 'pile driving' mass.

I agree that a mechanism relating mass loss to collapse progression is a good idea. I shall have a think about the best way to do so, but first thought would be to relate to impact KE.

The 'energy to fail the steel', termed 'Support Collapse Energy' in the model, can be omitted entirely. or included by two methods.

1) A user specifiable per-floor constant (in joules)
or
2) A per-floor calculated value based on several factors.

The user specifiable value is completely open, allowing any value supplied by the user to be used, for each floor.

The calculated value uses a base figure for the collapse of one floor (the failure floor), which is split between the external columns and the core columns, and then ramped on a scaled multiplier towards the tower base.

The base figure, and each split value can be set by the user.

The ramping formula can be found in the following spreadsheet column: TowerMass:AJ

The ramping formula accounts for the thickening of the steel towards the base, but admittedly it is an estimate (it underestimates the strength increase significantly). If I can get hold of more accurate steel mass and scale source data the model will be updated to use specific steel mass-to-collapse energy conversions.

Future update of the model will include an implementation of inelastic collision, including much more refined steel deformation mechanics, and will include the appropriate time and energy requirements.

I am not trying to match any collapse time. The intention is to model the effect of the various parameters upon collapse time.

This hopefully provides the user with an understanding of how such factors affect the time of collapse, and assists users in making their own conclusions about probable causes.

The measurement is to ground level ONLY (above grade).

Figures are included for mass below grade simply because they are available, and for completeness.

In addition, the post crush-down collapse of the cap is modelled without any energy sinks or resistance, which produces a slightly short full collapse time. This will be addressed in a future update and may also include below grade mechanics.

Official collapse times vary, though it is clear that Dr Shyam Sunder, Lead Investigator for NIST stated the times as 9 and 11 seconds. This clearly cannot be a timing for the descent of all debris though, as both are faster than pure free-fall. We shall of course disagree on the mode of descent, which complicates what is actually meant by the descent time, and I suggest that focus is placed on refining the model rather than specifying what value it is supposed to be 'generating'.

With all parameters set to mutually acceptable values, and the possible inclusion of additional factors and more complex mechanics, the resulting time will, I am sure, be a topic of further, separate, discussion in itself.

The live loads in the spreadsheet are set to the maximum rated loads for all floors, and are also specified separately for the inner core and outside core areas.

(MAXIMUM Live Load as per ASCE 7-02 as applied to original design specification for WTC. NISTNCSTAR1-2A P102)

I feel that without further definite data, that the usage of the maximum design rated load is more than reasonable, however, as the data is housed in a spreadsheet, the loads can easily be changed by the user on a per-floor basis. (Sheet Tower Mass, Columns P thru V)

Again, the intention is to provide a model enabling experimentation with a range of values.

Users are encouraged to modify the data, though of course I'd like to know about any useful sourced and confirmed data so I can incorporate it into the downloadable source model.

I hope my answers to your questions result in rewording of your statement here, or more preferably retraction. It does nothing to progress the model, and expresses a position-based bias which is wholly discouraged within this discussion.

Again, I suggest a rewording or retraction of this statement once you have digested my answers to your questions.

Asking questions, then applying assumed and position biased behavioural predictions before receiving answers, is not a method of discussion I wish to pursue here.

Only through much further discussion could a set of parameters (and final mechanics) be agreed.

Setting of parameters and implementation of mechanical behaviours deliberately to match observed behaviour, rather than natural extension and refinement through identification of relevant factors, is very specifically 'dry labbing', and is something I shall be trying to avoid most fervently here.

I fully agree that more documentation is required, though I would not agree to implications of 'burying' calculations. The calculations are quite necessarily inter-dependant but have been made as clear as possible by sheet separation and the inclusion of the parameters sheet.

I fully intend on documenting each and every calculation used, though until then it is of course simply a matter using the dependancy tools in excel for those curious about such matters.

I thank you for your questions, and acceptance of the model in your challenge, and hope we can progress and clarify it with mutually satisfactory results.

As I hope my answers clarify your questions, I see no immediate need to extend the model mechanics, although I fully agree that more documentation is required.

Explanation relating to how users may change sources values they disagree with would seem to cover most of your concerns, although of course, we may disagree on the values individuals may choose to actually use.

As far as I can see, focussed discussion can only result in improvement to the current model, so that's more than fine by me.

We will obviously have totally different opinions on the cause of the actual events, but I assume you will accept that biased discussion and inference should play no part in discussion of the model here.

I will now gather a list of assumptions made, beginning with those which work in favour of continued collapse, as they are more easily identified. I'm sure you will highlight those which work the other way round if I miss any.

1) The 'Cap' mass is modelled as a single, non-deformable, solid, and the entire mass is applied to subsequent collision calculations.
2) All impacts are currently inelastic, ignoring the significant levels of energy absorbed by the structure in a more accurate elastic collision impact simulation. This will be addressed in a future update.
3) All descent calculations, including the initial drop, are calculated using standard vacuum free-fall equations. The initial drop and every subsequent drop after the impact of each floor, is performed as a free-fall descent. In reality this obviously was not the case, as the descent involved continual deformation of the building structure. Inclusion of inelastic collisions and steel structure deformation mechanics will help address this assumption.
4) The time implications of the deformation of the structure are not included.
5) The energy expenditure for the crushing of all materials other than concrete and steel collapse energy is not included. This includes dry wall, fixtures and fitting such as tables, computers, filing cabinets, and specifically the energy required to collapse each floor truss structure. (An almost endless list 'could' be compiled)
6) The effect of Cap tilting is not included, as this would require a finite element analysis rather than what is intended to be a physics/math model.
7) The initial drop assumes all core and external columns for the failure floor have 'vanished'. This works VERY much in favour of continued descent (Paper)
8) If energy expenditure during any impact exceeds available energy, the simulation is artificially allowed to continue, with the initial cap velocity being zero. The collapse failure floor is recorded and displayed on the Parameters sheet, and deficiencies are included on the videos by the value being highlighted in red. If this situation occurred in reality, collapse would stop. This behaviour is included to enable users to see the effect on energy deficiencies upon collapse time.
9) The maximum rated loads are used on all floors. No inclusion of energy expended in deformation of any of the live or construction dead load materials is included.

I'm sure there are more, which I will add via edits to this entry as I document them.

Our conversation became, how do you say, stalled, on a point of contention, namely the energy loss arising from a conservation of momentum calculation.

It took some additional detail from another user to clarify the source of the contention as I'll explain below.

The positive outcome of the discussion has been the discovery of a fundamental contradiction in the usage of a perfectly rigid Cap (pile-driving mass) used in conjunction with a perfectly inelastic collision. (Which is the fundamental basis of many WTC crush-down models)

In a virtual world 'my' view (that the energy loss was accounted for in the energy exchange in decelerating the impacting mass, and accelerating the impacted mass) made perfect sense, making my viewpoint 'rigid', it was however, wrong. Damn and drat, but hey, it's hard to let go of a personal 'understanding' when it appears to make so much sense, all the numbers add up, and be so much simpler than the alternative...

As time (t) forms no part of the conservation of momentum equation, my usage of it assumed an instantaneous application of the physical behaviours implied, resulting in instant velocity change and instant energy exchange within the 'virtual' model.

Whilst in a virtual model the instantaneous application of these behaviours does appear to explain all energy 'loss' from the system, this is not actually the case, as the implied necessity to include time in some form cannot be excluded, and results in the conservation of momentum calculation energy loss being necessarily consumed by deformation of the impacting bodies.

This situation is compounded further by the use of perfectly rigid bodies, which in a virtual world appears to make perfect sense but again allows incorrect interpretation of conservation of momentum calculations to also seem to make perfect sense.

Again, however, in reality, perfectly rigid bodies cannot exist, so in 'application' of conservation of momentum to a perfectly rigid body, a paradox arises as the body itself cannot deform, and so a perfectly inelastic (and also elastic) collision cannot be applied to a perfectly rigid body.

Given the widespread usage of perfectly rigid bodies in many physics texts, I think it's easy for this misconception to result in such a misinterpretation, and the implications of the time domain being necessary in a conservation of momentum calculation, which itself does not reference time in any way, also compounds interpretation and explanation of the issue.

So, in summary, the energy loss through the conservation of momentum calculation must be made available for deformation of materials within the model being discussed.

This only really forms a half-way-house solution to the problem, as perfectly rigid bodies are still used, and this also must be addressed in some way. (Implementation of non-rigid bodies and elastic collisions involving the time domain could be interesting to try and express in spreadsheet format, but I'll give it a go)

The model has now been updated to allow usage of the c-o-m energy loss in subsequent deformation calculations, and will be available for download shortly. (Numerous other additional features have also been included, such as the ability to specify mass loss on a per-floor basis and usage of specific floor heights rather than an averaged height in floor drop calculations.)

I noticed a few others observing the conversation, who began by agreeing with my 'stance', have now also changed position, which, given that I have now found out that the c-o-m energy loss usage issue has been a point of contention between many others, I think allows me to emerge from a bit of a humble-pie situation with at least a good basis for the apparently common misconception (virtual use of rigid bodies and perfectly inelastic collisions) and the knowledge that others have also benefited from the 'exchange'.

The model is now also more accurate, which is all that really matters. Hey ho...onwards.

http://femr2.ucoz.com/load/1-1-0-4

I am new to this forum and wonder where to find the new spreadsheet (I get a "page not found 404 error"). Also I am very much interested how the story from here proceeds re has proceeded.

I am very impressed about your work especially the neutrality you have put into it.

regards