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.
Friday, July 11, 2008
Wednesday, July 9, 2008
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.
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.
Tuesday, July 8, 2008
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.
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.
Sunday, July 6, 2008
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.
Saturday, July 5, 2008
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.
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.
Friday, July 4, 2008
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.
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.
Wednesday, July 2, 2008
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.
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.
Tuesday, July 1, 2008
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.
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.
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.
Subscribe to:
Posts (Atom)
