videos of polywell phase space

[happyjack27]

1.5cm axial-radial-radius.

this one chronologically precedes the one just above.

here the ions are still making their first pass through the center.

http://www.youtube.com/watch?v=FRUtLE5LgMk

[D Tibbets]

...and the mass of an electron. altering the gyroradii for a given mag field strength would be equivalent to altering the charge-to-mass ratio of the particle. .....

Yes, that would change the charge to mass ratio. But, if you can change the number by deviding by some constant, the relationships would be unchanged, just the scale would be different. If you can multiply by this constant at the end of a string of calculations or simulation there might be processing time advantages if it allows you to shrink the machine without the magnitude of the gyroradii becoming a problem. This assumes that you could convert the numbers back at the end of the calculation, if you had to do it at every step I doubt there would be any advantage, although with shrinking the size, the numbers of particles decreases by a factor of 1/r^3 (?).
I am talking about a pure electron plasma. Once ions were introduced it would become more complicated.

Also, if you are you using Mean Free Paths, that might need to be manipulated also.

Dan Tibbets

[happyjack27]

...and the mass of an electron. altering the gyroradii for a given mag field strength would be equivalent to altering the charge-to-mass ratio of the particle. .....

Yes, that would change the charge to mass ratio. But, if you can change the number by deviding by some constant, the relationships would be unchanged, just the scale would be different. If you can multiply by this constant at the end of a string of calculations or simulation there might be processing time advantages if it allows you to shrink the machine without the magnitude of the gyroradii becoming a problem. This assumes that you could convert the numbers back at the end of the calculation, if you had to do it at every step I doubt there would be any advantage, although with shrinking the size, the numbers of particles decreases by a factor of 1/r^3 (?).
I am talking about a pure electron plasma. Once ions were introduced it would become more complicated.

Also, if you are you using Mean Free Paths, that might need to be manipulated also.

Dan Tibbets

it's lagrangian. i'm just simulating particle motion.
that mean's certain variables are inextricable. lowering the gyroradius means lowering the curvature created by the lorentz force for electron in _all_ situations. i can't pick and choose. it's equivalent to increasing the mass of the particle, decreasing it's charge, or decreasing the magnetic field. it's _exactly_ the same in every way, and there's no way to make if different. and i'd just as well change one of those three things instead. and i'm not going to change the charge or mass so that leaves only the mag field. there's no way to do what you're asking. i can't separate the mag field from the mag field.

Code: Select all

force_vector = lorentz_force_vector + coloumb_force_vector.
acceleration_vector = force_vector * charge_to_mass_ratio.
position_vector = position_vector + velocity_vector * time_step.
velocity_vector = velocity_vector + acceleration_vector * time_step.

[happyjack27]

k, this one is long. well, relatively speaking. it took an hour to upload. this is the first pass of the ions through the center. i really pushed the time step so you could see it all in a reasonable time span, but i increased the ion to electron timescale ratio so that the electrons' gyrations wouldn't suffer so much in precision.

i think at this point the only real useful simulation i need to get it to have it calculate confinement time, losses, and loss energy. ultimately well depth per energy input.

http://www.youtube.com/watch?v=CzbmGSJcr38

[rcain]

... i increased the ion to electron timescale ratio so that the electrons' gyrations wouldn't suffer so much in precision....

by {differential} 'time scale' i'm assuming you mean 'sampling rate' rather than 'actual' timescale - ie. velocity. is that right?

ps. just watched the vid - wonderful evolution going on. going to have to watch this several times to try and work out whats happening.

[happyjack27]

by {differential} 'time scale' i'm assuming you mean 'sampling rate' rather than 'actual' timescale - ie. velocity. is that right?

yes. thank you. that's been gnawing at me. "sampling rate" is the correct term.

and the thing with different "timescales" for ions or electrons, it's like this:

Code: Select all

if(particle_is_electron) time_step *= time_scale_ratio.

force_vector = lorentz_force_vector + coloumb_force_vector.
acceleration_vector = force_vector * charge_to_mass_ratio.
position_vector = position_vector + velocity_vector * time_step.
velocity_vector = velocity_vector + acceleration_vector * time_step. 

notice velocity is stored as its own variable. velocity is NOT the change in position between time steps. it is the cumulative total of acceleration integrated over its trajectory. (i.e. "path integral") time step is just the precision with which this path is sampled in that integration.

particles do not "see" how much other particles change their position between time step (samples). they see what their current position is and what their current velocity is (velocity vector).

since electrons travel much faster than ions, keeping them at the same temporal sampling rate means having them at a lower spatial sampling rate. which means, especially where the mag and/or electric fields vary sharply, the spatial sampling could be too large to pick up on the sharp changes. causing, for instance, a particle to go straight when it should have turned. this is why i need to keep my temporal sampling rate high.

so to compensate for this at temporal sampling rate otherwise too low to accurately model these sharp corners, i boost the electron temporal sampling rate a little so that it's spatial sampling rate more closes matches the ions.

though this has the side effect that local fluctuations in the e-field that are usually quickly filled up by electrons will not be so quickly filled up by them, and the ions will see them longer and play a larger role in filling them up. so one thing you'll see is a little more ion thermalization than one would in real life. so it's a trade-off.

[rcain]

Thanks HJ. Good clarrification. I was going to ask whether it would be possible to 'baseline' the effect of that (differential temporal sampling rate), so we could infer how it might affect our actual sim behaviours.

as you rightly say i think, it shouldnt affect things too much so long as the electrons (at least) have fallen into some moderately steady (continuous harmonic) state already; but if things are changing rapidly (eg. discontuinuously as at impulse startup for example), then we might see some slightly strange (though hopefully not too large) side effects, as the two different sampling frequencies mix and that phase (error) propagates and evolves through the system timeline.

anyway, vids looking fab so far.

[happyjack27]

second pass (continuation of prior video)

http://www.youtube.com/watch?v=u6aLPvxlX8M

[happyjack27]

i'm doing the first pass again, same everything except a fraction of the time step (100 picoseconds per second) and an ion-electron timescale ratio of 1.

it will probably take all day to run, but i'm at work so no matter. then i'll have to transfer it over to my laptop to time lapse it.

[happyjack27]

ended up recording a full 2 passes. it looks pretty much the same as the faster version, with a few subtle differences. for one it's a little "smoother" around the edges; you don't see the stratification on the outside as you do near the end of the first pass.

secondly, deutrium and tritium separation is more distinct and as expected there looks to be a little less thermalization.

in the center of the phase view - that's lower radius in the x direction and lower momentum in the y direction - you[ll see it's the predominanetly the deutrium that has filled up that energy gap. perhaps they learned a little quicker to stay in the center to cancel out the electrons, while the tritrium were still accelerating towards the center, causing the outward deutrium to slow down due to repulsion. and being lighter they would slow down quicker than the tritium would. this all just interpretation / speculation though. in any case that lower energy zone in the center is clearly dominated by deutrium.

that's what i see anyways. perhaps sometime tommorow i'll have it time-lapsed and uploaded so you can form your own intepretations.

[happyjack27]

...which is kind of interesting. i thought they were expecting in a pb11 mix for the b11 to be cold relative to the p. perhaps that's true for their ke, but for the momentum it seems the lighter ones find the lower energy states quicker. one can thing of a jar with marbles of the same size, but 2 different weights. you shake it up and the heavier ones find the bottom. but that's not what's happening. apparently that analogy doesn't work in an n-body situation of mutual repulsion with an attractive center.

perhaps a better analogy would be marbles of same density but different sizes. their sizes reflect how many collisions with other marbles it averages over to determine its momentum. i.e. its size is its "moment of inertia" so to speak. then shake that up and see what happens. the smaller ones find the bottom quicker. that seems more like what i'm seeing, and seems a more fitting analogy, as well. the smaller (higher charge-to-mass ratio) ones respond quicker to changes in their environment and thus "compute" faster, and thus find the lower energy states faster.

[happyjack27]

on further investigation, the center population is pretty mixed. must have been the reduced color range when viewing it over VNC.

here's a brief time slice from the middle of the third pass:

i call this one "lotus flower". bwoong!!

http://www.youtube.com/watch?v=1iu-9jSYg0k

[ladajo]

Is there a way to determine Ion population velocity distributions? Like a speed vs. particle count? Hard to tell from the video what percentages are at fusion speeds vs below down to thermalized.

[happyjack27]

Is there a way to determine Ion population velocity distributions? Like a speed vs. particle count? Hard to tell from the video what percentages are at fusion speeds vs below down to thermalized.

currently no way for the program to churn out densities. easiest way i can think of is sorting all the points by their distance from the center. in any case a lot of programming esp. considering a data-parrellel sort merged with the n-body kernel, or even run periodically as a separate kernel. so you just have to eye it for now.

indeed, any graph that includes any variable and particle count / and or density would have to first sort the particles by that variable. not implemented.

a higher priority for me right now is modelling the loss energies, which will be easier anyways. then i could theoretically graph mag strength vs loss energy to find an optimum and that would presumably be a wb.

but if its any consolation, i can assure you that none of the particles are at fusion energy. i'd show you the fusion cross-section view, but it's really really boring. just picture for a moment a perfectly flat surface. now you know what the fusion cross section view looks like. it's 1.5cm radius at 1E3.6 amp turns and net plasma charge of -1E-10. well below fusion levels. i just don't have the computational power, at the rate this algorithm grows, to do a wiffleball at fusion levels. i can do one or the other, but not both. fusion levels requires high mag field strength, wiffleball requries high particle count per mag strength, and since my particle count is limited that means low field strengths. so mutually exclusive. the thing to do then is do the wiffleball at low field strength, then muplitly the velocity linearly to get a model of cross section if you scale it up. i plan on adding a velocity pre-multiplier to the cross-section calc, actually. let this be a little reminder to myself.

[ladajo]

I am not talking net power.
You will get fusions at lower system energy levels, as already demonstrated by multiple live test articles.
I was thinking a simple data push out.
When you run the particle routine, maybe add a small amount of code that pushes the data point of the velocity vector, and if the sophistication allows, whether the particle is inbound on a track within say 15% of center of the device.
This data could be memory mapped into a set block of conventional memory, outside of the allocated GPU memory, and have in effect a running graph that could be sampled at determined run points, or on cue by the system processor. So in effect a running memory block image of the data (two dimensional), that can then be captured periodically by a system event for a snapshot. Most of the work would be done away from the GPU. All the GPU needs to do is set the velocity data point when it runs each particle routine (or tenth, or hundredth, or whatever is efficient.
One variable would be the ion count (never to exceed total injects), the other is velocity, (again never to exceed some value based on mass, radial diameter and well potential). So, you could set the ion particle count dimension to whatever you want to run for particles, then keep writing the velocity to a successive (and eventually repeating) address in the designated memory block, at whatever sample increment you determine is representative.
The "snapshot" could then be captured by a routine run by the system processor, vice the GPU for data sample recording. A living data set if you will.
I used a similar trick years ago to have a central PLC (and share with a LAN based app) keep a running track on the current alignment of a complex material distribution system that existed over about a mile of factory real-estate. In effect a living bit map of system status that created very minimal load to the processors involved (as they all shared the map in the same section of memory).
Am I on crack? Fair enough if so. Just thinking out loud.