They're not oscillating wildly, for god's sakes, they're oscillating exactly at the frequency and magnitude of two 1kg mass coupled to each other via a force constraint which has reached full compaction; that is, rehardening of the squashed "columns" to an elastic response with MUCH higher stiffness than the intact column and shorter length (typically 20% original length or about 3/4ths meter).
A few words of explanation for anyone following this.
In this model, the lowest part of the upper section (plus "debris") impacts the highest part of the remaining intact lower structure in an
inelastic collision. Inelastic collisions conserve momentum but do not conserve KINETIC energy. The law of conservation of energy dictates that, while energy can assume different forms (mechanical, thermal, electrical potential, gravitational potential) and change forms within a closed system, the total energy in all forms remains constant.
Typically, in physics, the issue of what happens to the lost kinetic energy of an inelastic collision is quickly dispensed with by noting that real bodies have internal degrees of freedom, and the translational kinetic energy goes into deformation, heat and
vibration.
Big surprise then, that colliding masses should vibrate!
Then, the notion of where the kinetic energy goes in an inelastic collision is never discussed again. Who cares? If a collision is inelastic, a computable fraction of kinetic energy is lost, period - by definition. That's how the problem is treated in an
analytical fashion.
When it comes to simulation, though, it's an entirely different thing. Any dynamics simulator must first and foremost conserve energy! This is a primary validation technique for my simulations. Is energy of all types conserved throughout the simulation? The first clue that a computational error has occurred is failure to conserve energy.
If the accretion is inelastic, where the hell does that energy go? Same answer as in physics class - vibration, heat, etc.
Some environments, like physics engines, provide a parameter called
restitution which specifies the elasticity of a body in collision as a number between 0 and 1, with 0 being perfectly inelastic and 1 being perfectly elastic. This allows direct control of kinetic energy lost in collision by invoking momentum conservation equations as part of a collision transaction, and are handled separately from continuous forces acting on the body. I've used these and this method of "throwing away" kinetic energy obeys the laws of physics just fine. Some of the graphs are above.
If an environment DOESN'T have a restitution property, as is the case with the program which produced the graph with oscillations, where does the kinetic energy go when two bodies collide? The program does have damping capability, so that's a legitimate sink like restitution, but it will only act on
vibrational energy. Well, what happens when a column crushes (aka two bodies collide)? In the program, the stiffness at full compaction is jacked way up, and the force become elastic. That keeps it from compacting any further; that's what FULL COMPACTION means. But ELASTIC means like an ideal spring, and the energy of motion didn't just disappear on impact. It went into vibration.
-------
In fact, psikeyhackr's prior
objections to the presence of vibration is what's absurd, not the vibration itself. This is a physics-based, F=ma step solver. It iterates over all bodies in the system, evaluates the forces acting on it and computes resulting acceleration for a very small time-slice, using either Euler or Runge-Kutta approximations to the function value, then integrates over the time for the change in position. It conserves energy unless there's an appropriate sink. The ONLY appropriate sink to mimic inelastic collision is
translational KE -> vibrational KE
From there, it can be damped or not. He's been squawking about the undamped graph. Doesn't matter to the
collapse mechanics; the energy has been moved from translational kinetic to vibrational, it no longer affects the translational dynamics.
