I'm assuming non-relativistic. It's messy enough as it is! I'm also ignoring radiation terms.
What I'll try to do is find the velocity of the electron as a function of initial conditions and where it is in the E and B fields. If a single electron has an orbit that does not hit a coil or the walls, I've got some good proof the basic idea is sound. If the orbit continues to grow and eventually always hits the walls - then there's a real problem. But with some theory, I might be able to find a solution to the problem.
A model is a good start, but we still need real experiments. Reality is way too complex for a computer!
Edit: Please attack the problem any way you like. The more ideas we try, the better chance we have of figuring a lot of things out! Kind of like the blind guys and the elephant....
Virtual Polywell
Yup, I bet you can. But I've got the 3D solution for the single electron now, and the extension to the electron fluid won't be too hard. Having an analytical solution along with simple models allows us to look at lots of different physical set ups. We should be able to tell right away what _won't_ work.
What I've found in my experience so far is that doing things the hard way allows lots of other people to find an easy way. But until you do things the hard way the first time, you don't really know if the easy way is right or not. And when you try to compare to an experiment, you don't always understand why things can be so different from what you expected (or hoped for anyway).
Once we have a good idea of what the fudge factors are, it will be much easier to simplify things. For now, I haven't a clue what they should be. I'm hoping to get a few clues over the next few months!
I ususally prefer to make the code work before writing things up, but I think I'll write up the math and then crunch on it. I suspect you all will have some really good points to make to keep me out of the worst parts of the swamp!
What I've found in my experience so far is that doing things the hard way allows lots of other people to find an easy way. But until you do things the hard way the first time, you don't really know if the easy way is right or not. And when you try to compare to an experiment, you don't always understand why things can be so different from what you expected (or hoped for anyway).
Once we have a good idea of what the fudge factors are, it will be much easier to simplify things. For now, I haven't a clue what they should be. I'm hoping to get a few clues over the next few months!
I ususally prefer to make the code work before writing things up, but I think I'll write up the math and then crunch on it. I suspect you all will have some really good points to make to keep me out of the worst parts of the swamp!
A boat load!
It really depends on how smart you can be. Computer guys can usually get the same job done in 1/10th the horse power I can simply because they understand the guts of the compilers and how they interface to a real machine. A really crude brute force estimate would be 24*256 teraflops per time step with a million time steps being "reasonable". I bet some smart dudes can reduce that by 8 to 10 orders of magnitude. But that's still in the teraflop range. Computers exist to do that kind of thing, but it would take a large advertising agency budget or oil company geo group to pay for it. Not likely to happen in our basements or garages.
But - if I take a really simple approach and make a lot of assumptions, I think we can get some interesting models checked out with really affordable computers. I want to see what a single particle acts like, then see if the fluid model can be approximated to be similar. The problem is that assumptions need to be based on reality - and most of the time you don't have the experimental data to guide the modeling.
Some where between total brute force and pure analytical assumption crap lies reasonable modeling which will give us some very useful clues on what the right way to build things is. We are stuck with the technology we have at the time we have it. Check out the Apollo guidance system for example. Sometimes, what you have is good enough!
The reason I'm blabering is because there's many ways to skin a problem. I'd love to "do it right" and have massive computing ability to do a good model. But if we think hard and use paper and pencil, a slide rule just might be sufficient. But it wouldn't be as much fun!
It really depends on how smart you can be. Computer guys can usually get the same job done in 1/10th the horse power I can simply because they understand the guts of the compilers and how they interface to a real machine. A really crude brute force estimate would be 24*256 teraflops per time step with a million time steps being "reasonable". I bet some smart dudes can reduce that by 8 to 10 orders of magnitude. But that's still in the teraflop range. Computers exist to do that kind of thing, but it would take a large advertising agency budget or oil company geo group to pay for it. Not likely to happen in our basements or garages.
But - if I take a really simple approach and make a lot of assumptions, I think we can get some interesting models checked out with really affordable computers. I want to see what a single particle acts like, then see if the fluid model can be approximated to be similar. The problem is that assumptions need to be based on reality - and most of the time you don't have the experimental data to guide the modeling.
Some where between total brute force and pure analytical assumption crap lies reasonable modeling which will give us some very useful clues on what the right way to build things is. We are stuck with the technology we have at the time we have it. Check out the Apollo guidance system for example. Sometimes, what you have is good enough!
The reason I'm blabering is because there's many ways to skin a problem. I'd love to "do it right" and have massive computing ability to do a good model. But if we think hard and use paper and pencil, a slide rule just might be sufficient. But it wouldn't be as much fun!
OK, I've put up the newest version of "fusion.pdf" at http://www.eskimo.com/~eresrch/Fusion/fusion.pdf which shows how to solve the single electron orbit. Kinda shows any way. There's not really enough detail. But I'll start writing code so the basic idea can be more easily seen with real calculations.
The one part I'm glossing over is the imaginary exponentials to sine/cosine. While it's "simple" in theory, it's a pain in the butt when dealing with real numbers and computers. It should be interesting to actually follow some orbits though, and I hope I can get some code going over the next few weeks. I'll keep y'all posted!
The one part I'm glossing over is the imaginary exponentials to sine/cosine. While it's "simple" in theory, it's a pain in the butt when dealing with real numbers and computers. It should be interesting to actually follow some orbits though, and I hope I can get some code going over the next few weeks. I'll keep y'all posted!
Computing won't be quite the cost you think...These are for sale now:
http://ati.amd.com/products/streamprocessor/specs.html
500 Gflop single precision, and can do double precision. Nvidia has a similar card (but can't do double precision.. yet) and you can put multiple of these cards in a single computer. Nvidia actally puts four of their cards in a 1u appliance.
http://ati.amd.com/products/streamprocessor/specs.html
500 Gflop single precision, and can do double precision. Nvidia has a similar card (but can't do double precision.. yet) and you can put multiple of these cards in a single computer. Nvidia actally puts four of their cards in a 1u appliance.
I was going to bring that up, so, I'm glad someone else did. Probably should talk to the Folding@Home guys, as they have an ATI port.
Not sure when the NVidia double-precision part would be out, but I expect it'll cost a bunch. Last I knew they were going to charge extra for that feature. Nice thing is that the architecture seems more approachable -- C language, and less in the way of VLIW instruction dependencies, but I do expect that AMD would be a better bet at least in the short term.
If you can design your system so that you can keep 64 different threads all executing the exact same instructions (against possibly different datasets) in lockstep, you can make this work quite well. I don't imagine you'll have much logic branching, not sure how much looping you'll need, though. Asymmetric loop exits would seem the main issue, and I expect, if the protein-folding guys can make it work, a determined programmer could make this work as well.MSimon wrote:Note that it is optimized for stream processing (DSP).
What we want should be optimized for cell processing.
Not sure when the NVidia double-precision part would be out, but I expect it'll cost a bunch. Last I knew they were going to charge extra for that feature. Nice thing is that the architecture seems more approachable -- C language, and less in the way of VLIW instruction dependencies, but I do expect that AMD would be a better bet at least in the short term.
I've been doing assembly on x86, PPC (and 68K) for 12 years. I've looked at GPGPU (using your nVidia or ATI) for calculations but haven't dived in yet.
One thing you have at talk-polywell.org (and the other forums) that the guys with an oil company's budget will never have: you have lots of volunteers. You can send us on a wild goose chase and it won't cost you a penny. You can build three simulators, each with increasing CPU requirements and fewer assumptions. Whichever one produces the best results, you run with. The others were just fun to build.
If you have code you want me to optimize by hand in assembly, I'll do it right away. That's my specialty.
If you want me to build a three-stack forth compiler, I'll get to work. If you want me to design a distributed polywell computing system, I can do that.
One thing you have at talk-polywell.org (and the other forums) that the guys with an oil company's budget will never have: you have lots of volunteers. You can send us on a wild goose chase and it won't cost you a penny. You can build three simulators, each with increasing CPU requirements and fewer assumptions. Whichever one produces the best results, you run with. The others were just fun to build.
If you have code you want me to optimize by hand in assembly, I'll do it right away. That's my specialty.
If you want me to build a three-stack forth compiler, I'll get to work. If you want me to design a distributed polywell computing system, I can do that.