magrid configuration brainstorming

Discuss how polywell fusion works; share theoretical questions and answers.

Moderators: tonybarry, MSimon

KitemanSA
Posts: 6114
Joined: Sun Sep 28, 2008 3:05 pm
Location: OlyPen WA
rjaypeters wrote:A solution in search of a problem? I call this a cross-over. For this example I used a square planform WB 7. Imagine what you see as one-third of the needed coils:
In general, AFAIK, the squares all need to have the same polarity. These have opposite. Doesn't seem that it would work. Anyone?

hanelyp
Posts: 2252
Joined: Fri Oct 26, 2007 8:50 pm
KitemanSA wrote:
rjaypeters wrote:A solution in search of a problem? I call this a cross-over. For this example I used a square planform WB 7. Imagine what you see as one-third of the needed coils:
In general, AFAIK, the squares all need to have the same polarity. These have opposite. Doesn't seem that it would work. Anyone?

good catch.

rjaypeters
Posts: 869
Joined: Fri Aug 20, 2010 2:04 pm
Location: Summerville SC, USA
Well... Never mind, then.
"Aqaba! By Land!" T. E. Lawrence

R. Peters

icarus
Posts: 819
Joined: Mon Jul 07, 2008 12:48 am
A solution in search of a problem? I call this a cross-over. For this example I used a square planform WB 7. Imagine what you see as one-third of the needed coils:

Kiteman and hanleyp are correct the polarities would be incorrect. This could be simply corrected though by having instead of the cross-over a "switchback" (leaving aside a separate question of tightness of radius of the coil here for now). Kind of hard to describe, but instead of figure-eight the two coils would look like a pair of spectacles bent onto the surface of the sphere.

rjaypeters
Posts: 869
Joined: Fri Aug 20, 2010 2:04 pm
Location: Summerville SC, USA
When KitemanSA and hanelyp mentioned the polarity problem, I thought of the "spectacle." And rejected it because of
icarus wrote:...leaving aside a separate question of tightness of radius of the coil...

OTOH, I might model it anyway. Might make a nice Friday night folly.

From a metal bashing perspective, I don't really think a tight radius is a problem until we attempt to make the metal turn back upon itself. For example, my software last night allowed me to "pipe" a curve with a narrow pipe (51mm dia IIRC), but refused the same curve when I tried to increase the diameter (to the current standard of 0.2m).

Is arcing a problem if the radius is tight on the inside of the curve and away from another coil?

Are there limits to how tightly one may lay SC?
Last edited by rjaypeters on Sat Nov 13, 2010 1:59 pm, edited 1 time in total.
"Aqaba! By Land!" T. E. Lawrence

R. Peters

rjaypeters
Posts: 869
Joined: Fri Aug 20, 2010 2:04 pm
Location: Summerville SC, USA
Dodecahedron circumscribed on a 3m sphere with 6mm coil spacing:

"Aqaba! By Land!" T. E. Lawrence

R. Peters

D Tibbets
Posts: 2775
Joined: Thu Jun 26, 2008 6:52 am
Arcing likelihood increases as the radius of curvature decreases. That is why ionizers have needles and Tesla coils have big globes. I'm not sure how that applies to inside curves. Aside from the arcing considerations, the angle at which wires can be bent is possibly the other limiting factor. Some (all?) superconducting wires or ribbons may not tolerate too much bending.

Dan Tibbets
To error is human... and I'm very human.

rjaypeters
Posts: 869
Joined: Fri Aug 20, 2010 2:04 pm
Location: Summerville SC, USA
I'm using 0.25m radius for my realistic models. The Friday follies, well, I have more license, no?
"Aqaba! By Land!" T. E. Lawrence

R. Peters

Randy
Posts: 82
Joined: Mon Sep 20, 2010 5:40 am
Location: Texas
Wednesday, November 17, 2010

Sorry to write an entire story here but,

It’s been a while since I last posted and I wanted to bring you guys up to date on my effort to develop a user friendly platform from which the group members here could fairly easily develop, view (in 3D) and use the electric and magnetic field lines/densities of different magrid coil configurations quantitatively.

I first thought that using math programs such as Mathematica, Octave or Maple would be the best platform choice. But after experimenting with Mathematica, I now see that, in my opinion, these math type programs lack a critical conceptual capability necessary for clear 3D understanding by most users. i.e., the ability by the user to rotate, scale and translate 3D output objects on their computer monitor screen in real-time.

Please, let me explain some basic 3D stuff:

[ BASIC 3D COMPUTER GRAPHICS ] Found on the internet (a long time ago).

Create a set of 3D points/vectors (x,y,z). Using this you can create all sorts of 3D shapes, but then you reach the problem. How do I put it on my 2D screen? This is actually very easy to do. All you do is use the following two formulas:
X2D=X3D/Z3D
Y2D=Y3D/Z3D
…Where X2D and Y2D represent the X and Y components of the pixels on your 2D computer monitor.
After this you will have to multiply the two results by the width(X) and height(Y) of your screen respectively because this assumes that the width and height of your screen are both one. Otherwise your shapes will seem stretched or contracted.

Of course it isn't as simple as that because you will not be able to move at all and you will have points behind you shown as well. To handle this you create a camera.

The camera will just be the point that you are looking from. You make the camera from a single 3D point/vector. To apply the camera to the 3D points in your model you simply subtract the camera's coordinates from each 3D point’s coordinates.
X3D = P3D.x - Cam.x
Y3D = P3D.y - Cam.y
Z3D = P3D.z - Cam.z
Now we need to remove anything behind the camera that you can't see. If a point’s Z coordinate is less than 0 then we don't draw the point. This is best done when you are actually transferring the point(s) from the 3D model onto the 2D screen because you can simply not draw it.

One uses vector matrix math to rotate, scale and translate sets of 3D points so that they will move about as viewed within the 2D camera’s screen. or vice-versa.

That’s a brief overview of 3D computer graphics.

I have discovered the publicly available source code to a simple yet powerful 3D-Engine (program) written in Microsoft Visual Basic by a man named Jerry Chen called Dex3D. He wrote and published it back in 1999. The Visual Basic source code for Dex3D is freely available to download at both the ‘Planet Source Code’ and ‘CodeGuru’ web sites. This program does not use OpenGL, it is a compact and simple, self-contained, real-time 3D engine written entirely in Visual Basic.

Note: the download version of the Dex3D program contains a HUGE cpu-hog programming error (Mr. Chen included an infinite Do-Loop to perform screen rendering updates – whether the screen needed rendering or NOT). Except for the infinite Do-Loop error, the program is an absolute 3D gem!
I quickly made the necessary changes to convert it into a purely event-driven program as it should be. In my modified version the program is now an efficient and relatively simple 3D jewel!

Unfortunately the source code is undocumented. But its programming statements are so well written that a good programmer (who understands basic 3D) can quickly determine what Mr. Chen is doing.
On the high-level, it took me a while to determine that all you have to do is keep track of the sequential integer values returned for each 3D-mesh (independent 3D-Object) created (returned) from his mesh drawing commands. You can then simply apply his matrix mesh-transformations to these integer-referenced drawing meshes to rotate, scale and translate them independently as you wish.

With the Dex3D program the user can (in real-time) spin any 3D object(s) just by clicking and dragging the mouse pointer about the program’s 3D view.

I have modified the program to create several magrid coil configurations and to both load and save ascii text formatted user-definable magrid files. This file input capability will allow users here to generate their own magrid configurations, load them and view the electric and magnetic fields generated by them in 3D.
Each line in a magrid file represents the sequential 3D points of the magrid’s individual coils (see below), where R,G,B represents the red, green and blue color components of a given 3D point.

ASCII text file format:
X,Y,Z,CoilNum,R,G,B

Example sequential 3D point definition lines in a magrid file:
-1,.9801725,.1981461,1,255,0,0
-1,.9555728,.2947552,1,255,0,0
-1,.9214762,.3884348,1,255,0,0
...

Shown below is a spherized single coil octahedron magrid (loaded from an ASCII text file) that I can spin around in real time with the mouse and perform Biot-Savart summations upon its coil-segments within the program.

Single coil, Spherized Octahedron Magrid

For the last two weeks, I’ve been very busy modifying this program to work with magrid analysis.

Currently, I’m adding the ability to draw selective sets of the 3D magnetic field lines generated around the magrid’s coil segments (transferring from a 2D version). The program is too crude to release now – I’m working the bugs out. But, so far, it’s a super cool 3D program to play with!

I’ll figure out a way for you guys to download it (source code included) when I get the first workable ‘magrided’ version ready.

~Randy

Randy
Posts: 82
Joined: Mon Sep 20, 2010 5:40 am
Location: Texas
from above:

Example sequential 3D point definition lines in a magrid file:
-1,.9801725,.1981461,1,255,0,0
-1,.9555728,.2947552,1,255,0,0
-1,.9214762,.3884348,1,255,0,0
...

This format is understood to represent the endpoints of sequential line segments to be drawn for a given coil in the magrid.

~Randy

rjaypeters
Posts: 869
Joined: Fri Aug 20, 2010 2:04 pm
Location: Summerville SC, USA
It looks good to me.
"Aqaba! By Land!" T. E. Lawrence

R. Peters

BenTC
Posts: 410
Joined: Tue Jun 09, 2009 4:54 am
Randy wrote:I’ll figure out a way for you guys to download it (source code included) when I get the first workable ‘magrided’ version ready.

You could try http://sourceforge.net/register-project/features.php with one of their Distributed Version Control Systems. Mercurial seems to have better Windows support.
(Disclaimer, I haven't hosted anything there myself, but use a lot of good software from there.)
In theory there is no difference between theory and practice, but in practice there is.

happyjack27
Posts: 1435
Joined: Wed Jul 14, 2010 5:27 pm
BenTC wrote:You could try http://sourceforge.net/register-project/features.php with one of their Distributed Version Control Systems. Mercurial seems to have better Windows support.
(Disclaimer, I haven't hosted anything there myself, but use a lot of good software from there.)

Agreed. probably best way to do it. and it's totally free. I use TortioseSVN w/sourceforge. my repository is here and you can browse my code here. or, ofcourse, get it via an svn client such as tortoiseSVN. or somethig built in to your IDE. if you use svn w/sourceforge you'll have the same features.

on that note, i'm much further along in implementing the static fields through configuration files. just got to move the memory over to the gpu and i can start testing.

Randy
Posts: 82
Joined: Mon Sep 20, 2010 5:40 am
Location: Texas
BenTC and happyjack27,

Thanks guys for the ‘version control’ software team-development pointers. I used a similar system for version control of PLC (Programmable Logic Controller) software used by my former employer – I’m retired now.

happyjack27,
Looks like you are actually creating a Linux-CUDA GPU based magrid test platform. Dude, that’s super-way-cool! How many Nvidia cards/cores are you developing with?

I think parallel processing is the only way to go for simple simulation of charged-particle motion experiments in magrids… But I’ve never had the guts to attempt a CUDA based system.

Kudos to you, happyjack.

~Randy

happyjack27
Posts: 1435
Joined: Wed Jul 14, 2010 5:27 pm
Randy wrote:BenTC and happyjack27,

Thanks guys for the ‘version control’ software team-development pointers. I used a similar system for version control of PLC (Programmable Logic Controller) software used by my former employer – I’m retired now.

happyjack27,
Looks like you are actually creating a Linux-CUDA GPU based magrid test platform. Dude, that’s super-way-cool! How many Nvidia cards/cores are you developing with?

I think parallel processing is the only way to go for simple simulation of charged-particle motion experiments in magrids… But I’ve never had the guts to attempt a CUDA based system.

Kudos to you, happyjack.

~Randy

Thanks!

If you can believe it, what you're seeing is only 1 card. In particular, an MSI Cyclone 460GTX 1GB, overclocked to 900Mhz. If I remember right it's 7 symmetric multiprocessors with 48 cores each.

I'm "just" modifying the Nvidia SDK's "nbody" example. So the nvidia team actually did most of the work, including the cool graphics (though i picked the colors). And also, like the original code samples, it's cross-platform; you can run it on windows or linux. i'm actually running on windows.

It would be nice to see a "fast" nbody implementation (better than O(N^2)) for multiple cards, but i don't have the motivation for it, and in any case, first things first.