Saturday Morning

Last night, I ran across a sign error in one of the force equations. Once I fixed it, I still had issues with the ribbon. There was also a velocity dampening equation used when time is less than zero that I added.

One of the differences between my implementation and its source was the number of points used to represent the ribbon. I had increased the size by a factor of ten, and had modified the constant used to control all of the ribbon loops by the same amount. I decreased the number, all the way back to its original value, and the ribbon held, with sane numbers and without breaks.

I played with the number of points, and can induce the ribbon to start breaking once I exceed a certain size. I increased the quell time to see if that would help the problem, but it did not seem to, even when I increased the quell time to forty hours. I don't know if I am hitting a memory problem, or whether I still have a bug in the equations.

I need to repeatedly run the model under the same conditions, to verify that the ribbon is breaking in the exact same point at the exact same time. If it isn't, then there is some factor that is being intruduced that is affecting the math run to run.

Phantom Quelling

I thought that allowing the elevator a period of unchecked dynamics was allowing it to sort out the forces on the ribbon. It turns out that it was allowing the double precision floating point numbers overflow, and become NaN (not a number) in Java.

I need to review the equations again, to figure out what I introduced into the model when I converted it to Java. One of the changes was to use the vecmath library, where I may have swapped some of the parameters when I converted to the new routines. Again, I need to walk the code to determine if this is the cause of an issue.

First Weekend Task List

In Eclipse, I ran SEsimOne for eleven hours of simulation time at quarter second time increments (only an hour of which was for quelling the simulated ribbon). There is dynamic allocation for temporary classes in the ribbonDynamics and pointDynamics methods, which I should be able to clean up. ribbonDynamics is called over one hundred and sixty thousand times (the current length of the simulation), and pointDynamics is currently called a thousand times more than that (the ribbon currently being represented by a thousand segment points). I want to be able to increase the number of segment points in the ribbon, especially the parts closer to the ground that are in higher gravity. I am also impatient, so I need to start thinking about performance improvements.

Task List for this weekend:

in ribbonDynamics, stop propagation across ribbon breaks (skip over the gaps)

walk the code to verify that timeStep is correctly included in all equations.

add climbers back onto to the ribbon.

restructure to create a ribbon class. The ribbon behavior is spread over the SimRibPoint class and methods within the main class. may want to subclass the anchor and counterweight points.

performance improvements

start reading Java3d documentation and tutorials

Quelling the Ribbon

The simulation has a variable called currTime, which is incremented by the TimeStep each iteration through the simulation main loop. The value of currTime is initialized to -3600 * 0, which evaluates to zero.

There are places in the simulation where the code checks to see if the value of currTime is greater than zero, including the determination on whether the a ribbon segment breaks.

I thought about the initialization value of currTime, and realized that its purpose is to allow the programmer to change that zero to a one, which would allow a quick way to change between two specific values for the start of the simulation, -3600 or zero.

I changed the start value of currTime to -3600 * 1, and did not see any ribbon breaks. I was elated for a minute, until I realized that if currTime was set to -3600, that the number of time steps (numTimeSteps) that the simulation was running, times the TimeStep would never allow currTime to be a positive number. I fixed that problem, and now have the simulation running for sixteen hundred iterations past the zero point without any ribbon breaks. I did this without including any artificial dampening on the ribbon when time is less than zero (which I may want to add).

Because of the way the ribbon is initialized in the simulation, there is a period of time that needs to pass once forces are applied to the ribbon for it to settle down before it can be played with. In the real world, this won't be a problems, since no one is planning to put the ribbon in place, and then magically switch on gravity, centripetal acceleration, and Coriolis.

I should be able to apply more of the equations from the pointDynamics and ribbonDynamics to create a better approximation of the stable ribbon in the initRibbon method. I can also determine how long it takes for the ribbon to stabilize once forces are applied.