Page 1 of 2

I'm considering my own 2D Polywell simulator

Posted: Wed Dec 16, 2009 12:36 pm
by JoeOh
I own a program called DarkBasic Professional and it allows me to write graphical programs with relative ease. So far just for testing purposes I am seeing how "fast" my program can randomly move "particles" around the screen.

The setup is a 2D top-down view of the particle swarm being viewed in a 800x600 resolution window. Each particle is just a pixel rendered to the screen. So far I am displaying 5,000 blue "electron" and 5,000 "ion" particles total. Right now I am getting about 80 fps with all of the particles running randomly around on the screen.

I am guessing that the calculations needed to make a decent simulation of a 2D slice of the Polywell reactor will take up considerable CPU power. Does the ten-thousand particles on the screen @ 80 fps seem fast enough?

My computer system specs are AMD Phenom Quad-Core, 1 GB of ram, and a Nvidia Geforce 9800 GT 512MB Ram. If more info on my system is needed for an accurate assessment let me know.

I think it's a pretty good system but I know better ones are out there. But considering my system specs. Does 10,000 Particles on screen moving randomly going at 80 fps good enough to start the "real work" as far as implementing calculations and the like?

Posted: Wed Dec 16, 2009 1:22 pm
by alexjrgreen
Are you compiling your program?

Each dot on the screen needs to represent a minimum of a thousand million individual particles. A million times that would be better.

The calculations you need to do will slow you down a bit.

Posted: Wed Dec 16, 2009 1:38 pm
by JoeOh
Yea, I'm compiling the program to a stand-alone .exe file.

As far as each visible pixel "particle" representing millions of unseen particles, gonna have to see how to go about doing that.

Posted: Wed Dec 16, 2009 4:26 pm
by alexjrgreen
The Lorentz force F acting on a point charge q moving at velocity v and subject to an electric field E and a magnetic field B is given by:
  • F = q(E + v x B)
where q is a scalar, F, v, E and B are vectors, and x is the vector cross product.

In Cartesian coordinates, if a = (a1, a2, a3) and b = (b1, b2, b3), then
  • a x b = (a2b3 - a3b2, a3b1 - a1b3, a1b2 - a2b1)

Posted: Thu Dec 17, 2009 3:52 am
by JoeOh
I was also thinking about pre-rendering a "magnetic map" lets say in GIMP and black represents magnetic south and white is north. The gradients in between the black and white will represent the flux direction. And perfect "middle" grey color represents no magnetic field.

After the magnetic map is rendered, the grey-map data is loaded into an array. The values will be -128 to 0 to +128. -128 is south and +128 is north. The other numbers will represent the varying strength and flux direction based on data next to that particle.

Maybe I have it all wrong.

But the idea is to use field maps to determine the particle flow instead of raw mathematical and distance equations. Is this a good idea? Has someone already attempted this?

Posted: Thu Dec 17, 2009 9:46 am
by alexjrgreen
Check out 2D Polywell SIM.

Posted: Sat Dec 19, 2009 10:08 am
by JoeOh
Here is the start of the program I'm working on. Let me know if the link works and if it is able to be downloaded by the public.

http://www.4shared.com/file/176507538/4 ... nline.html

The filename is pw.zip and has 2 files (the exe file and the magnetic map image) totaling in size about 1.8 megabytes.

I get about 130 fps with 10,000 "electrons" on the 800x600 screen. Each electron is represented by a blue pixel. And one electron (number 1) is tracked as a larger yellow pixel to show the particles really are being effected by the magnetic map image.

If anyone wants to see the code just let me know. The code is written in DarkBasic Professional. The DBPro program is not free, though a demo is available at DarkBasic.com

Let me know what kind of results with the framerate you all are getting. I ran this program with 75,000 on-screen particles moving about and got about 27 fps.

Posted: Sat Dec 19, 2009 9:38 pm
by alexjrgreen
40 to 50 fps on an old 1.5GHz PC with 512MB

Posted: Sun Dec 20, 2009 3:30 am
by TallDave
240fps here.

My kittens are attacking the ions.

Posted: Sun Dec 20, 2009 3:36 am
by JoeOh
I know the electrons flying around make no usable sense but it can look pretty sometimes :)

Posted: Sun Dec 20, 2009 11:32 am
by Betruger
200 fps, and seems to asymptote twd ~160fps or so after a couple of minutes once everything's gained some speed.

I think I'm seeing a pattern of even vertical bands.

Posted: Sun Dec 20, 2009 9:27 pm
by Stoney3K
Betruger wrote:200 fps, and seems to asymptote twd ~160fps or so after a couple of minutes once everything's gained some speed.
I don't see a lot of purpose in this anyway (other than the programming challenge to understand the physics). In steady state, the whole image is supposed to be the same all the time, right?

It does make for some pretty pictures, though, but I think those would render a lot cooler in a 3DS MAX particle model. But I won't be simulating every single particle's trajectory when I'm doing cool movies!

Posted: Tue Dec 22, 2009 12:48 pm
by JoeOh
I'm glad to see that some other systems do a lot better than my own with my test program. But I'm still pleased with what my rig can do. It would be great if I could use the power of my Nvidia GPU in tandem with what I'm working on.

I suppose I should be happy for now considering that each electron particle is it's own "entity" and represented by a single blue pixel. I ran the program with 100,000 on-screen electrons and got about 10 fps.

As far as the "magnetic map" image works is the image is loaded into the program and is temporarily on the screen. A special function is used to extract the "red" intensity level and load that data into an array. I know it's not simple, but it's an easy way to "draw" a magnetic map in an art program like GIMP and play around that way.

Now it's just a matter of creating the magnetic flux direction map and the electric field map.

I suppose it is a neat way to create simulated "fields" and having particles interacting with those field maps to produce an accurate but "cpu-cheap" way of trying out experimental configurations.

Posted: Tue Dec 22, 2009 1:31 pm
by ladajo
So how would you account for changes in the field as e- density goes up, and ions (fuel) and introduced and the plasma forms?
It wold almost seem a long drawn out iterative process where you made best guesses in progression to Beta=1.
This is one of the key points of understanding, what happens during startup to equilibrium. ("In search of the wiffleball")
This goes back to why I would love to see the pressure cooker approach played with more. A cheap way to potentially visualize the plasma formation process. Recombinations just look so cool...

Posted: Tue Dec 22, 2009 1:49 pm
by JoeOh
ladajo wrote:So how would you account for changes in the field as e- density goes up, and ions (fuel) and introduced and the plasma forms?
It wold almost seem a long drawn out iterative process where you made best guesses in progression to Beta=1.
This is one of the key points of understanding, what happens during startup to equilibrium. ("In search of the wiffleball")
This goes back to why I would love to see the pressure cooker approach played with more. A cheap way to potentially visualize the plasma formation process. Recombinations just look so cool...
I see what you are saying as far as the e-density. I can make an "active" map array that can be an additive to the base-line electric field. The same can be done for the electron cloud becoming dense enough to create their own diamagnetic field acting against the solid-state magnets and their fields.