Class PileTest

Adds same sized round balls to a pile until performance degrades to the point that the sim is barely keeping up with real time

Adds same sized square blocks to a pile until performance degrades to the point that the sim is barely keeping up with real time

Two blocks are rigidly connected by two double joints, so that the blocks cannot move relative to each other, these fall with a few other blocks into V shaped walls; the connected blocks rotate very quickly after colliding with the wall.

Test that the joints on the connected blocks stay reasonably tight, despite rapid rotation. Turns out that they do slip a bit from rapid rotation. Because we check that energy is constant after the pile settles down, it is important that there are no rocking blocks (because damping is non-zero, rocking results in loss of energy).

The problem is contact forces are not calculated well enough during rapid rotation; taking smaller steps pretty much eliminates the problem.

To do: make a test showing that smaller steps results in tight joints.

History: Dec 2012 changed results due to the slight change in contact force calculation; had to recalculate the results. Also changed the initial conditions slightly so that the result was not a situation where there was a rocking block which loses energy over time

Close to stable resting configuration of blocks derived from a particular run of test/PileTest.PileTest.connected_blocks_pile_setup (just moments before the pile settles down).

Test of close-to-stable resting configuration derived from a particular run of test/PileTest.PileTest.connected_blocks_pile_setup (just moments before the pile settles down). So that we can compare running identical configuration across different browsers and changes to myPhysicsLab software.

TO DO

Figure out why FireFox and Safari have such large SMALL_IMPACTS (like as big as 0.01 or 0.02) in this test. Chrome doesn't have these. What's different between them? Presumably the small-impacts are due to joint slippage. Looks like the small body 8 is getting kicked by those impulses and that is why it is still moving at the time of these test results.

Performance test that runs pile_10_random_blocks; this is a stress test for contact force calculation.

Runs pile_10_random_blocks_setup.

Performance test that runs pile_20_random_blocks; this is a stress test for contact force calculation.

Note that the performance measurement is only valid for comparing different versions of code if the same results are found in each run. Slight changes in collision handling or other algorithms can completely change the resulting positions of the blocks. This can result in different runs having different numbers of contacts which is the factor that most affects performance because the number of contacts determines the size of the matrix that is solve for finding contact forces, and this is currently an O(n^3) process.

Java vs. Javascript: The test results (and setup) are different than in the Java version for a couple of reasons. 1) because Java and Javascript give slightly different results from Math.cos (see DoubleMath_test.js) and because this test is so sensitive with all the collisions, there is no way to match the Java results. 2) The setup was changed so that the blocks are not moving after 7 or 8 seconds.

Runs pile_20_random_blocks_setup.

This configuration caused a 'checkNoneCollide' exception in versions prior to May 12, 2016. Originally found in PileApp after clicking the 'random' button once.

Test of configuration that caused a 'checkNoneCollide' exception in versions prior to May 12, 2016.

Stable resting configuration of blocks derived from a particular run of test/PileTest.PileTest.connected_blocks_pile_setup.

Test of stable resting configuration derived from a particular run of test/PileTest.PileTest.connected_blocks_pile_setup. So that we can compare running identical configuration across different browsers and changes to myPhysicsLab software.