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.