Virtual Polywell

[MSimon]

Hello, I'm back after several months and I've finally read the whole thread! Just like to ask a few questions and make a few comments.

Regarding shielding the electron gun in particular from alphas, I don't really understand, isn't an electron gun simply a piece of ordinary metal set to a voltage, why is important that alphas don't hit it? If heat dissipation is an issue there then it will be an issue everywhere the alphas hit, if you ask me the biggest challenge in the magrid idea will be to protect the coils from alpha bombarment since alpha bombardment will make them brittle and increase their resistivity, it might even cause them to short out. I'm not sure even a 2 tesla field will protect you from alpha particles (a 2 Mev alpha has a larmor radius of about 20cm)

Yep - thermal issues are big inside a power reactor. The less stuff to be cooled the better. And yes grid cooling is an issue.

Secondly how much fiddling around in this virtual polywell has been dedicated to coil spacing? If coils are very close together you get bussards 'funny cusp' that causes the electrons to go through a corridor of zero field into the coils, if you increase coil spacing then you get big massive line cusps in between all the coils, (I've got some beautiful pictures of the field lines but I'm not a seasoned blogger so I don't know howe to attach them to posts)

Spacing will be an issue.

You can't stop th fieldlines from touching solid surfaces, all cusplines go radially outward from the polywell directly into solid surface. By charging the magrid to a high potential, however, you might be able to ensure that most of the emerging electrons get turned back by the electric field. Upscattering of electrons from collisions in the well will however cause some net loss of energy. As the density of electrons gets higher and higher however the electron might 'short circuit' the center of the well with the vacuum vessel, this might allow ions to escape through the cusps, although the loss radii for the ions would still be the electron rather than ion larmor radius.

The field lines must conform to (shroud) the surfaces for the best shielding.

[jmc]

The fieldlines can indeed shield the magrid from the electrons. What they can't do is shield the whole vacuum vessel from the electrons.

You must rely on the electrostatic charge of the magrid to suck the energy out of the electrons before they hit the vacuum vessel.

[scareduck]

Some interesting stuff on number theory in computing:

Very interesting indeed. I haven't had time to really absorb all of that, but it might be interesting to see how their calculations would cause failures in some of the extra precision libraries I mentioned upthread. In particular, the qd library represents quad and beyond precision using strings of doubles, and renormalizes them after each operation.

[scareduck]

I actually cracked the documentation for the qd library, and while they say they don't have an exhaustive proof of correctness, from Lemma 12 in appendix A, they claim the error bound is proportional to 2^-211*max(|a|,|b|), where a and b are two 64-bit floating-point numbers. The remainder function seems to have known bugs for large differences between the two operators, but there don't seem to be any insuperable issues.

[drmike]

I've found some interesting ideas to try. One thing I like about the Polywell compared to other problems is that I can actually start from nothing. I think the next code set I try will start from an electron source and I'll follow particles as they leave the electron source balls.

Over the last 20 years there have been a lot of plasma codes written. They all have some success for specific problems, and they all fail on other problems. There are lots of ways to attack a blob of charged particles, so I'll have plenty to keep me busy. Finding ways to be efficient with the book keeping is the biggest trick - a 6D problem gets messy fast!

Certainly fun to think about, that's for sure.

[scareduck]

I started building a specfile so I could build RPMs of the qd library. I haven't built RPMs in almost a decade, so that's lots of fun. There's been a lot of changes, and all of them seem to have been undocumented since the original RPM HOWTOs were released in 1999. I'm pretty close now; the only thing missing is the install step, and I made the mistake of grabbing a Perl library package specfile as a template, rather than a real binary package. Once I get that done, I'm going to see if it correctly calculates the limit for J.M. Muller's recurrence in section 5 of the W. Kahan paper MSimon linked to earlier. If that works, I'll see if I can retool some of drmike's electron_fluid code as C++ so it can use the qd library for the calculations. That could be fun from the standpoint of giving us enough headroom to actually, you know, get some results.

[MSimon]

Dr. Mike et. al.,

Have you considered doing what the aircraft model people do? i.e. scale air velocity etc according to model size?

i.e. how about a 1,000 particle simulation on a reactor 1 inch across?

Forget about speed of light limits etc (rescale as required).

[drmike]

scareduck: I've always been impressed by RPM's, you press a button and a zillion things go off the right places and link in dynamic libs too. I don't know C++, it should not be too hard to put a wrapper around C though and make it look like the correct thing.

Simon: Yes, that's the whole point of doing things dimensionlessly. I can change the scale of the result by changing a few relative parameters. I think the next attack point is individual particles. This is interesting because most people do either PIC codes where they follow blobs in space but not velocity, or Vlasov codes where they follow blobs in velocity but not int space. Nobody follows particles in both velocity and space.

The advantage we have with the Polywell is that we can start with a pure vacuum. Introducing electron particles in phase space from electron sources in fixed positions is a given for the boundary conditions. It _is_ our reality, so the model is not an approximation at that level. The number of particles and number of time steps is limited by the compute engine available, but for getting rough ideas a desktop is plenty good enough.

Adding source ionization and multiple species (H and B at different ionizations), recombination and other lower level effects is pretty straight forward with a brute force approach too. But until a rough idea shows that is worth while, there's no point in it.

Part of the reason nobody has tried this kind of attack on real plasmas is that they don't have such a simple starting point. In a way, BFR's are much simpler than any other fusion device, especially if you use an electron source instead of microwave ionization. What I don't understand yet, is why Bussard put the electron sources at cusps instead of at the face of each coil. Hopefully I can find out with a model!

To start with I'll assume the electron sources are hemispheres and radiate perpendicular to their surface. As long as I'm far enough from the MaGrid, that should be pretty close. Debugging the code for phase space will be interesting, but one of my goals is to track electron losses into the MaGrid as well as the outside wall.

Back of the envelope says I should be able to track 30 milliseconds and 10 million particles with the ram I have on my computer. But it might take a month to do that - so I will definitly start a lot smaller.

It'll be great to get it into an RPM if it works. Then we can try lots of ideas and configurations on different machines and see what makes sense. Should be a lot of fun!

[scareduck]

scareduck: I've always been impressed by RPM's, you press a button and a zillion things go off the right places and link in dynamic libs too. I don't know C++, it should not be too hard to put a wrapper around C though and make it look like the correct thing.

In this case it's actually slightly easier to do things in C++ because of operator overloading. That is, I don't have to say something like (not that these are actual lib calls, mind you, I don't have the API in front of me)

y = qd_add(qd_mul(b,x),c);

With C++'s operator overloading, I can say

y = b*x+c;

Very slick stuff. Plus, also thanks to operator overloading, the I/O knows how to adjust for differing data types.

[Solo]

Well, but using objects probably increases overhead, and with a problem of this size I doubt we'll want that. In our case, it seems like we could probably sacrifice by making the coding a little trickier and save cycles on the cpu.

[scareduck]

Well, but using objects probably increases overhead, and with a problem of this size I doubt we'll want that. In our case, it seems like we could probably sacrifice by making the coding a little trickier and save cycles on the cpu.

Perhaps, but C++ tends to generate its ugliest code when dealing with multiple inheritance, a circumstance that does not apply here. This is one reason (perhaps the main one) why templates are so popular, relatively speaking: they generate an awful lot of code, bloating binary sizes and memory footprint, but they have far less overhead.

[tonybarry]

Tip of the day ... code for clarity, not for speed. What you may perhaps save in nanoseconds of CPU time you will more than lose in days of bug squashing.

Optimising is done late in the dev cycle. Generally with the aid of profiling tools, which point to where the cycles get eaten. And that's almost never where you thought it was.

Sure, if you can spec an architecture that is lean, go for it. But don't add any complexity ... if it's not lean as part of clarity, let the profiler tell you whether it's worth recoding.

Even when programming microcontrollers, where RAM is at an all-time premium, clarity beats leanness hollow. When leanness MUST be adopted, wrap the leanifying method so you can avoid the complexity.

I have learnt this the hard way, and heard it from others who are (in my opinion) vastly better coders than I am.

Your mileage may vary.

Regards,
Tony Barry

[MSimon]

DrMike says:

Simon: Yes, that's the whole point of doing things dimensionlessly. I can change the scale of the result by changing a few relative parameters. I think the next attack point is individual particles. This is interesting because most people do either PIC codes where they follow blobs in space but not velocity, or Vlasov codes where they follow blobs in velocity but not int space. Nobody follows particles in both velocity and space.

I'm gobsmacked. It seemed so obvious to me (I hadn't looked too closely) that you need to follow particles AND velocity. I had assumed that is what PIC codes did.

It seems to me that following a thousand particles or so (replenish as required) would tell you so much. It might even be good enough to tell some about diamagnetism (WB effect).

If you don't know the velocity how can you tell if you have a scattering collision or a fusion collision?

Now I'm starting to see that Plasma models are no better than climate models. They are a mixture of first principles and ad hoc assumptions adjusted to get the results that seem "reasonable".

==

Any way - you get the reaction rate up by making the reactor arbitrarily small, obviously you already know that. No need to worry about arc over or magnet capabilities.

[MSimon]

Tip of the day ... code for clarity, not for speed. What you may perhaps save in nanoseconds of CPU time you will more than lose in days of bug squashing.

Optimising is done late in the dev cycle. Generally with the aid of profiling tools, which point to where the cycles get eaten. And that's almost never where you thought it was.

Sure, if you can spec an architecture that is lean, go for it. But don't add any complexity ... if it's not lean as part of clarity, let the profiler tell you whether it's worth recoding.

Even when programming microcontrollers, where RAM is at an all-time premium, clarity beats leanness hollow. When leanness MUST be adopted, wrap the leanifying method so you can avoid the complexity.

I have learnt this the hard way, and heard it from others who are (in my opinion) vastly better coders than I am.

Your mileage may vary.

Regards,
Tony Barry

Another point that backs the above. Go slower - it will get done quicker.

Another: Five days planning - two days work.

Another: as much as the language you use allows - write the code so it reads as much as possible like English. To do that efficiently you will need a language where calls don't require an extensive memory thrash.

One of the things that makes C code more difficult to read than English is that calls are so expensive. So you get big (often difficult to test) modules instead of small (easy to test) ones.

Why is it so important to read like English? Since we spend so much time with it that is where we are most proficient. Thus code that reads like English will be easier for others to understand and evaluate.

[drmike]

I'm gobsmacked. It seemed so obvious to me (I hadn't looked too closely) that you need to follow particles AND velocity. I had assumed that is what PIC codes did.

Yup, me too. But reading the details is interesting - they all assume a velocity distribution of some kind at each space point, then compute the flow from that assumption.

It seems to me that following a thousand particles or so (replenish as required) would tell you so much. It might even be good enough to tell some about diamagnetism (WB effect).

If you don't know the velocity how can you tell if you have a scattering collision or a fusion collision?

Collisions are a totally different part of the story. you can do a good model with no collisions at all, and add the fusion collisions independently from that. In fact, you could set up one system of computers to follow the plasma, and another system to collect that data and compute fusion processes. The fusion particle energies are so much higher than the rest of the system, they can be followed separately. Scattering collisions add complexity - as density increases they will become important. They can be tracked with the plasma, they don't have to be included with fusion processes.

Now I'm starting to see that Plasma models are no better than climate models. They are a mixture of first principles and ad hoc assumptions adjusted to get the results that seem "reasonable".

That's about it. The nice thing about the Polywell from a modeling perspective is that the boundary conditions are well defined and we can slowly add complexity as each subsection is debugged. You can match experiments to computing as well. For example, run at 10^-8 torr with just an electron source and measure current flows into MaGrid and walls - does it match or not? Add pure H at 10^-4 torr, include ionization, and check again. It is an ideal set up - the theory and experiments can be used to make decisions about what directions to go next and give confidence that each step makes sense.

When experiments help debug theory, it's a good thing!!