Eradicating Bugs Since 1978

Spent some time this evening debugging the climber logic. The climbers are represented by an array of class objects, and I hard coded access to the first and only item in the array. Since it was late at night, I coded indexed position one instead of position zero, so was throwing an exception. It took about five minutes to track down. I now have the model running with a climber for the first time. The model is running significantly slower now, partially because I restructured some of the larger methods into smaller, crispier pieces. I need to look into some performance improvements (besides just re-writing the model in another language.).

I have a class tomorrow afternoon, but will work on the model in the evening or a few hours on Sunday.

Thowing Exceptions

I had a hard time sleeping last night, and have had a rough day, and am wrapping things up for the evening.

On my daily walk around the tech campus where I work, I puzzled through the last of the complex climber dynamics routine. I convinced myself that what I was working on was valid physics (which doesn't mean that it is correct, only that I am currently convinced that it is correct). The forces on the climber are based on point dynamics (which handles gravity, centripetal force, and centrifugal force) and those that come from being spliced into the ribbon. The complex ribbon dynamics routine changes the amount of tension 'above' and 'below' the climber over time, which is what causes the ribbon to move the climber.

I finished my first cut at the climber algorithms. The initial coding is for a single climber, and the climber can only ascend right now (mainly due to how I handled edge conditions when transitioning between segments). I'm also concerned about how the climber brakes when past GEO, that what I have won't be up to snuff for that.

The first few tests are throwing exceptions right now, so I need to pull up the debugger and determine what I've missed tomorrow evening.

Climber Work

Worked on the climber algorithms tonight.

For a ribbon segment without a climber or other ribbon furniture, the forces on the ribbon follow Hook's law, where the distance between the start point of two ribbon segments is compared against the initial segment length to compute the forces exhibited by the two segments on each other.

For a segment with a climber, I break the ribbon segment into two pieces, one 'below' the climber and the other 'above' the climber. If I can accurately state what the initial length of each of the pieces of the resulting ribbon is, then I can compute the forces on the ribbon segments and climber by calling the simple ribbon segment dynamics. I've already developed the method that checks when a climber has transitioned from one segment to the next. The missing pieces are computing the force that the climber applies to the ribbon, computing the amount of 'initial length' of the ribbon that the climber will cross in a simulation time increment, and to modify the old climber dynamics routine to the use the new methods.

Climber Progress

Working on the complexRibbonDynamics, the method that I am having the ribbon and climbers come together. While working on it, I decided that I didn't understand the ribbon dynamics velocity dampening equations well enough, so I detoured back into my college undergraduate physics book and Googling to track down explanations of the equations, as well as looking at the space elevator simulation written by Jim McBeath from CalTech.

Repeat After Me

Max Resistance is Tensile Strength
Friction is Damping

Climbers and Other Furniture

Today I plan to work on the climbers. This is the one month anniversary of this blog and my space elevator simulation project.

I started to restructure the model to make this easier. The ribbonDynamics method computed the influence of one ribbon segment on the next, checked if the load on the segment caused it to break, and cleaned up the forces on the ribbon segment in preparation for the next iteration.

ribbonDynamics is being broken into several methods. The first is simpleSegDynamics, which can compute the influence of one ribbon segment on the next, presuming that nothing is attached to that ribbon segment. The logic to determine whether the segment has broken has also become a new method, and needs to be moved from the ribbon class to the ribbon segment class. A new method will be created to handle the case where there is a climber or something else attached to the ribbon. "Something else" can include things like a mass in geosynchronous orbit representing a station.

In the cell phone infrastructure business, the hardware out in the field, like the base stations associated with each tower, the base site controllers that coordinate multiple towers, and everything else required to connect with the publically switched telephone networks are referred to as "furniture". For the space elevator simulation, I will call anything hooked to the ribbon furniture as well.

Paths Ahead - Wants vs. Needs

Happy Fourth.

The ten thousand segment simulation ran to completion, but I couldn't tell what the results were. I had been displaying all of the ribbon points to the console, and then copying them into a txt file so I could import them into Excel, but overflowed the console. I should have anticipated that, but wasn't thinking ahead. I added a method to directly dump the ribbon to a file, and now only display the first twenty and last twenty ribbon points.

I re-ran the model last night for ten thousand segments, simulating eight days of time. It takes about two minutes wall clock for every hour of simulated time on my laptop with that number of segments (the model is a O(N)). It finished at about 12:35 this morning. I had Julie wake me up at 12:30, so I could fire off another simulation before I went back to sleep. I am currently running a two thousand segment ribbon for eighty days time.

There are a couple of improvements that I can make to the simulation to make running it a little easier. One will be to be able to read in a ribbon from a file, so I can extend the duration of the simulations by picking up where I left off. This would also allow me to interrupt a simulation. My goal is to run some really big simulations over night.

Another improvement will be to add a scheduler, so I can queue up simulations, and run the next one as soon as the first one completes.

I still need to add the climbers back into the model, as well as add a display capability that I can turn on and off. My daughter Stephanie wants to see the graphics first.

Breakthrough (Finally)

I believe that I have fixed the problem with the simulated ribbon.

I had gone into the model and was adding data to each ribbon segment and point to record some of the local variables computed when performing point dynamics (effects of gravity and centripetal acceleration) and ribbon dynamics (elasticity, friction coefficient, relative endpoint velocities), and eliminating the local instances of the variables that I had been using across the model.

Once I debugged these changes, I re-ran with four hundred and ninety points representing the ribbon, and appeared to have stability. I ran at six hundred and a thousand, and it looked good as well.

One of the local variables that I had been using must have had an issue, like it was incorrectly accumulating value across the entire duration of the simulation. I have a listing of the entire model that I printed before I started working on the model this evening, and will spend a little time seeing if I can determine exactly what the cause of the issue was.

I have a run going right now with ten thousand ribbon points. If it looks okay, I can start changing the ribbon segment lengths, and have shorter lengths closer to the Earth's surface, and longer lengths past geosynchronous orbit.

More of What We Know

The problem seems to start when the number of segments changes from four hundred and eighty-nine to four hundred ninety, and segment length changes from 186,475 meters to 186,094 meters. Having segments that are over one hundred and eighty six kilometers log are why I want to increase the number of segments in the model.

Running the model with four hundred and eighty-nine segments but a segment length corresponding with four hundred and ninety segments seems to induce the problem. This implies I can't simply re-distribute segments to allocate shorter segments in the high gee regions near the anchor.

The problem occurs in the first twenty or so segments, near the anchor.

The boundary code for when a segment falls below the Earth's radius is never invoked at 489 or 490 segments, so is not the source of the problem.

The boundary code for when elasticity goes negative is never invoked in ribbon dynamics is never invoked.

The Crazy Zoo That Dudley Drew

Back from a week in Virginia beach. Had a great time, discounting the smoke from the Dismal Swamp.

I proved to myself that the calculations of the model were repeatable, so I don't have a random source of error.

I started to dump the position and velocity of every segment of the ribbon at the end of the simulation. I changed the output format so I could copy them from the console to a text file, and then import the data into Excel, where I can chart the data to my heart's content.

Something mysterious is happening to the segment velocities at the base of the ribbon when I go from four hundred eighty-five segments to four hundred and ninety segments.

I'll need to verify that all of the equations that transform forces into velocities, and velocities into changes in position, have the correct time delta applied. I also need to look for discontinuities in how I am handling the boundary conditions near the base of the ribbon (for both the anchor point, and the surface of the Earth check).

One of my thoughts is that between changing the position of a ribbon segment and checking for whether the segment position is below the Earth's surface, that there is a calculation of ribbon forces based position and velocities of adjoining segments. I may try to do the surface check immediately after recalculating position, to eliminate a source of error.

I plan to re-run the model to collect the intermediate data to try and pinpoint when the error starts to occur, to see if that provides additional insight into why the model is acting up.

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.

Restructuring the Model

The ribbon in the original C code was represented by an array of ribbon segments, which act like a set of masses connected with springs. The simulation typically works sequentially through the list, with a couple of places where pairs of adjacent points are processed.

In the model, the climbers are held in a separate data structure. There is a little book keeping to determine which ribbon segment the climber is attached to, and then the climber forces on the ribbon due to acceleration are computed and applied. The ribbon forces on the climber are approximated, with a tendency to move the climber towards the ribbon if it starts drifting away.

If the representation of the ribbon was moved from an array to a linked list, then the climbers could be added into the list between ribbon segments. The climbers would become very short ribbon segments with a higher mass, and the length and tension of the segments above and below each climber would be adjusted to represent the climber moving along the ribbon. The existing ribbon and point dynamics routines would then be used to compute the ribbon effects on the climber.

Java has a LinkedList class that is part of the AbstractCollection class, so it should be fairly quick.

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.

Partial Progress

I discovered a typo in the pointDynamics code during lunch today, where I had multiplied a value by the mass of a segment instead of dividing, which was messing up all of the velocity vectors for the ribbon segments. This was what was popping the last segments off of the elevator during each iteration.

The ribbon starts breaking now on the eleventh iteration through the ribbon dynamics code, near the base, at the second segment above the anchor. Just need to track down the bug I induced that is causing the problem.

Debugging the Sim

I'm working at debugging the simulation.

I discovered that I had neglected to increment the current time variable, and once I did, the ribbon started fragmenting. It turned out that I had made a typo in the equation to compute the loading on a ribbon segment as the forces are propagated. This caused the computed loading on every segment to be too high, and tripped the ribbon break code.

With that bug fixed, the next problem is that the next-to-last segment of the ribbon breaks in the first iteration. The last segment remaining on the cable snaps for the next four iterations, the loads building, and then the ribbon snaps off near the ground and starts to disintegrate. I need to check the boundary conditions on the ribbon (what happens as the sim approaches the end of the ribbon) to solve the first problem, and then walk through the original code versus my implementation to see what I missed or messed up to cause the subsequent problem.

For now, I have disabled the climbers and code to compute the effects of the climbers to simplify the debug of the ribbon. One of the equations that I need to look at is computing the motion of the elevator along individual ribbon segments, and how it transitions to other segments.

My First Java Simulation

About three and a half years ago, I ran across the simulations of a ribbon break in the space elevator that Blaise Gassend had posted on his website. He was generous enough to include the C source code.

At the time, I had planned on re-writing his simulation in Java, both to learn how the simulation was put together, as well as to polish my programming skills in that language. My plans had been to write a simulation that would be accessible from a web page, exposing enough knobs and levers into the simulation to allow users to play with it. I was also interested in simulating a 'space hoist', a variant of the space elevator discussed on the Liftprt discussion boards which uses a looping, untapered ribbon that is moving.

I stopped working on the project at some point, and it sat in a folder on my bookshelf ever since.

Last week, I ran across all the notes, and decided to give rewriting the simulation another go. I downloaded Eclipse as my development environment, and used the javax.vecmath package from java3d as a vector math library. I'm only able to work on the project late in the evenings after dinner, and typically after my daughter goes to bed. I got the 'math engine' parts of the simulation up and running last night in Java, and am working at doing a little more class restructuring to make it look less like C. Once that is done, I need to build and code the graphics portions of the simulation, as well as whatever user controls that I want to put in place.

I want to get a working version equivalent to the one Blaise had running first, and then start playing with variants. Two variants that I would like to do are the aforementioned 'space hoist', as well as a simulation of a space elevator on Saturn's moon Titan (where Saturn's gravity needs to be accounted for as well as Titan's gravity, and perhaps some of the other moons as well).

Premier Post - Whoso and Whatzat?

Welcome to my new blog, Dornick n' Gleipner, where I plan to document my thoughts on the space elevator, with occasional diversions to other hobbies.

I'd read Clarke's Fountains of Paradise in the early eighties, and became a fan of the current studies shortly before the 3rd Annual International Space Elevator Conference in 2004. I attended the conference in Washington, D.C., and my wife and I provided some of the promotional materials given to attendees and presenters.

Dornick n' Gleipner sounds like the name of a pub. They are two words that rattled around my head the first time that I read the first space elevator book.

A dornick is a stone of throwable size, from when farmers were clearing their fields. Getting rid of a dornick was easier than something larger that needed to be carried away. The climber payloads for a space elevator are like dornicks, since they are designed to fit within the lifting capacity of a elevator ribbon.

In Norse mythology, the gods repeatedly failed to bind the Fenrir wolf with heavy chains, until the dwarves crafter the magic ribbon Gleipner. It is stronger than any chain, and binds him until Ragnarök. The carbon nanotube ribbon for the elevator reminds me of gleipner.

If a space elevator is ever built, and proves successful, then I hope that space exploration and travel will become more commonplace than its been in the last fifty years. If it does, then perhaps a large space station can be built at geosynchronous orbit, serviced by a ribbon, as a way station for travelers coming and going from the Earth. If you get a chance to go there, maybe you can stop on by the Dornick n' Gleipner, and we'll all hoist a few pints to the path that got us there.