forming a good wiffleball

[hanelyp]

I see two basic potential well morphologies. One is a thermalized bag of electrons . Any ions outside this bag willl be accelerated towards the center....

I'm thinking that a bag of thermalized electrons would produce a parabolic well. Ions inside the bag will still be attracted by electrons closer to the center. A bag of cold electrons collected on the bag and none in the center would produce a square well profile.

This would be one of the simulations I'd like to see.

[D Tibbets]

Perhaps. I (in my infinite wisdom) certainly thought so, mostly because of Gauss Law again. You could consider the cloud of electrons like a large number of shells. As the ion passes deeper through these shells the outer shells do not impeed the ion because they are outside the ions position and they have no net effect. I could not figure out Art Carlson's insistence that the potential well would be square. But, listening to Bussard's Google talk again. He mentioned that the pure electron potential well was square, and it only became parabolic once ions were introduced, as there was a tendency for some of the electrons to be tugged along with the ions towards the center. This weak coupling towards the center in not balanced by an equal outward tugging of the ions by the electrons (as they find and exit a cusp), partially due to momentum differences between the electrons and ions (?), but mostly because of the excess negative space charge from the excess internal electrons. I use this as an argument of why the cusps are not ambipolar as Art Carlson insisted. If you did not have some dominate space charge effects, I do not see how you could separate electrons and ions, such as in an ion engine.

Dan Tibbets

[TallDave]

That's an interesting notion, Dan. I would have thought it worked the way hanelyp suggested. Nice catch from the video. I wonder if a full transcript exists somewhere?

I think Art was used to thinking in LTE. He seemed to think the electrons would collapse into a Debye sheath. I believe Rick pointed out this would only be true if the system weren't driven.

[happyjack27]

ok, i decided i'm going to add a global accumulator, or two, rather. one to sum up total electron losses per second, one to sum up total electron loss energy per second.

then i will run at a fixed electron and ion population and slowly sweep the b-field strength from low to high, to try to find where the electron loss energy is minimized. presumably, that represents beta=1 conditions.

[Will]

The actual picture is probably somewhere in the middle.

you say this as i'm watching the actual picture on my computer screen.

(i'll make a video for you guys. i've got to find software to speed it up.)

Happyjack couldn't you get the simulation to directly output images / video? You're generating an image for the screen, so surely you have the image in a buffer somewhere? At the very least this would let you make a filmstrip which could be compressed later.

[happyjack27]

Happyjack couldn't you get the simulation to directly output images / video? You're generating an image for the screen, so surely you have the image in a buffer somewhere? At the very least this would let you make a filmstrip which could be compressed later.

not about to write a program that does video compression. and not about to upload a series of bitmaps, either.

[Will]

Happyjack couldn't you get the simulation to directly output images / video? You're generating an image for the screen, so surely you have the image in a buffer somewhere? At the very least this would let you make a filmstrip which could be compressed later.

not about to write a program that does video compression. and not about to upload a series of bitmaps, either.

It's easy enough to compress the images into a single video once you're done with either ffmpeg or mplayer (I've used both to accomplish this - these days I'd favor ffmpeg).

A brief google suggests the process for OpenGL is just:

Render it, do a glReadPixels(x, y, w, h, GL_RGB, GL_UNSIGNED_BYTE, ptr) to a memory area, add a suitable (uncompressed, 24 bit) BITMAPINFO header and save it as a BMP file.

You'll still end up with gigs of data from runs, but it'll be generated innately.

EDIT: This StackOverflow article seems to specifically address the specifics of this problem, by using libpng. Certainly you don't have to do anything, but doing a straight up filmstrip output sounds like it would help you a lot.

[krenshala]

Happyjack couldn't you get the simulation to directly output images / video? You're generating an image for the screen, so surely you have the image in a buffer somewhere? At the very least this would let you make a filmstrip which could be compressed later.

not about to write a program that does video compression. and not about to upload a series of bitmaps, either.

It's easy enough to compress the images into a single video once you're done with either ffmpeg or mplayer (I've used both to accomplish this - these days I'd favor ffmpeg).

A brief google suggests the process for OpenGL is just:

Render it, do a glReadPixels(x, y, w, h, GL_RGB, GL_UNSIGNED_BYTE, ptr) to a memory area, add a suitable (uncompressed, 24 bit) BITMAPINFO header and save it as a BMP file.

You'll still end up with gigs of data from runs, but it'll be generated innately.

EDIT: This StackOverflow article seems to specifically address the specifics of this problem, by using libpng. Certainly you don't have to do anything, but doing a straight up filmstrip output sounds like it would help you a lot.

Instead of doing all that, it looks like he is using FRAPS (or somethign similar) to just "record" the video as it is displayed by his program, and them manipulate that video (for timelapse) and/or just uploading it to YouTube. What you are suggesting would actually increase the amount of software he would have to create himself.

In short, there is no good reason to recreate the wheel when someone else has already handed you the one you need for the job.

[Will]

He's been complaining the process is too slow however.

Doing it from the program means it can occur at a logical point in the code execution, rather then being time-sliced with the operating system. It also means you could add an easily selectable counter for the time-compression factor.

Anyway, not the topic of the thread. Though I have been inspired to start looking into OpenCL for my ATI-based graphics card.

[quixote]

Anyway, not the topic of the thread. Though I have been inspired to start looking into OpenCL for my ATI-based graphics card.

Me, too! I have a radeon 57xx, and I'd love to see the sim running. Unfortunately, because the gpu code is cuda, it's nvidia specific. To run it you have to use either the cpu mode (which takes some tweaking), or the emulation mode provided by the older cuda sdk, namely, version 3.0. I've been doing that, but though I can get everything compiling, and the app runs and renders the magrid, I don't seem to get any particles, no matter how I adjust things (plus the sliders do wacky things). I'm going to buy a cheap nvidia card and stick it one of the computers I have lying around and see if it works that way.

As to opencl, from what I've seen of the api, translation looks relatively simple (knock on wood), and there are some decent guides available. There's also the Ocelot project, which is a binary translator. It doesn't yet run on windows, however, and requires some effort.

Back to lurking!

[happyjack27]

He's been complaining the process is too slow however.

it's as slow as it needs to be. it takes a little under a tenth of a second to calculate the lorentz and coloumb forces from every 14k*14k pair of particles. at that rate, that's about 3,082,813,440 (3 trillion) lorentz+coloumb force calculations per second. at that rate, by the time it completes a full particle pair calculation, adjusting for relativistic effects and what not, with all the memory transfers included, a top of the line cpu would have barely finished doing a single bitwise OR operation (assuming a bitwise Or takes only 1 clock cycle), and that's not even considering memory transfers.

EDIT: I just counted it up, there's 82 floating point operations in each pairwise calculation (counting reciprocal square root as 2). so that comes out to 252,790,702,080 flops, or about 253 gigaflops. at 900Mhz (its current core clock rate) my gpu is capable of a little over a teraflop, so that's about 1/4 of it's theoretical peak performance. not bad. but it means i'm either not at full occupancy, i/o limited, or both. considering the code, i'm probably using too many registers. that it would be difficult to cut back. which is bad news for earlier gpus which have fewer registers per thread. (the newer ones are balanced better, imho.)

EDIT: without per-particle-pair lorentz force and its relativistic correction that comes out to only 26 flops per pair. so presumably (assuming it's compute-limited) that would go about 3 times as fast.

[hanelyp]

Assuming peak electron energy of 100keV, vs. a rest mass of 500keV, it could easily be worth dropping the relativistic correction.