Still grinding on code. Found some interesting things - the mag field generated by the particles depends on the dimensionless parameter I found before times (v/c)^2 - still dimensionless but quite meaningful.
The only major problem is interpolation. Since doing it right will be computationally too intensive, I'm going to do a much simpler approximation. Eventually this can be fixed, but I think for the moment it'll be good enough to get a clue.
Virtual Polywell
I've been thinking more about my approach to computing the fields, and I realized the way I was doing it would allow all particles to affect themselves. Double plus ungood!! So long as the number of particles is less than the number of grid points, it makes more sense to compute the forces between particles directly. But once the density gets high enough, I will have to be more careful.
There are correct ways to deal with this when including electromagnetic radiation along with particle-electrostatic and magnetostatic forces. I just don't want to get to that level of detail yet.
And this is just simple stuff....!!!
There are correct ways to deal with this when including electromagnetic radiation along with particle-electrostatic and magnetostatic forces. I just don't want to get to that level of detail yet.
And this is just simple stuff....!!!
I have been, intentionally-unintentionally, taking a break from this. To give myself some small success in an area that I'll need anyway, I decided to start looking into converting the qd library Legendre polynomial root finder to the GMP library. Turns out GMP doesn't support transcendental functions (including trig stuff), but the MPFR lib built on top of it does. I'll still have to build a library capable of handling matrix calculations, though.
Had never heard of port3 before. Definitely worth looking at.
Nothing wrong with taking breaks!! Even the folks on ISS are on break today and they have been working for 8 days straight including sleeping in air locks.
I've been going kinda slow the last week or so just to think about how complicated all the details are. Being able to change the coding method based on the conceptualization of the problem is fun.
I think we're all just holding our breath and hoping something good comes out of Santa Fe "real soon now".
Nothing wrong with taking breaks!! Even the folks on ISS are on break today and they have been working for 8 days straight including sleeping in air locks.
I've been going kinda slow the last week or so just to think about how complicated all the details are. Being able to change the coding method based on the conceptualization of the problem is fun.
I think we're all just holding our breath and hoping something good comes out of Santa Fe "real soon now".
Now I've got way more ideas on how to do things than time to code them all. I think I'll go for slow brute force for the moment, but I may revisit the previous models with some further analysis. There are a bunch of tricks from stat-thermo that might be applicable to remove the exponentials and make computation reasonable.
Way too much fun!
Way too much fun!
It will be interesting to see how slow my code runs - it really will need a lot of parallel processing to be even close to reasonable. There were lots of subtle problems I had not thought about when I started, so I've ended up with a pretty hard core brute force method (meaning lots and lots of computation).
I'm also having fun watching NASATV and the space station along with the folks doing space walks. Kind of amazing how much bureacracy they deal with to unplug a connector, but it really is hard work getting into a space suit!
I'm also having fun watching NASATV and the space station along with the folks doing space walks. Kind of amazing how much bureacracy they deal with to unplug a connector, but it really is hard work getting into a space suit!
I just ran a few quick numbers and for a 50kV MaGrid I get an electron velocity of 1/3 light speed. Since an electron rest mass is 511 keV this actually seems about right. But what it says is that relativistic effects on electron mass will need to be taken into account. Yikes!
Yet another reason to keep the electrons cold I guess, but I'm not so sure that's possible. I hope to find out soon enough.
Yet another reason to keep the electrons cold I guess, but I'm not so sure that's possible. I hope to find out soon enough.
I get 132,525,912 m/s - about 1/3 light speed. However, only about 1E-6 electrons (max) should be at that speed. The rest should follow the heavier mass particles. Or is that an unwarranted assumption?drmike wrote:I just ran a few quick numbers and for a 50kV MaGrid I get an electron velocity of 1/3 light speed. Since an electron rest mass is 511 keV this actually seems about right. But what it says is that relativistic effects on electron mass will need to be taken into account. Yikes!
Yet another reason to keep the electrons cold I guess, but I'm not so sure that's possible. I hope to find out soon enough.
===
Let me add that the above calculation is non-relativistic. 1/2 mV^2.
Last edited by MSimon on Sun Mar 23, 2008 4:51 am, edited 1 time in total.
Engineering is the art of making what you want from what you can get at a profit.
I'll be doing a 100% NON-relativistic model, so we shall see. I've got the code typed in, now I gotta debug the mess....
I'm hoping that not much gets to that speed. It turns out to be only 10% effect - at 1/3 light speed gamma is about 1.1, so it's not that big a deal. Still, I've seen 4% effects screw me up with particle beam steering, so I want to know.
I'm hoping that not much gets to that speed. It turns out to be only 10% effect - at 1/3 light speed gamma is about 1.1, so it's not that big a deal. Still, I've seen 4% effects screw me up with particle beam steering, so I want to know.
Integration and O2scl
Since you mentioned O2scl, thought I'd stop by. I believe it's the integration you're interested in, in which case I should point out that O2scl uses essentially the same basic code as in GSL, which is itself a C-implementation of QUADPACK at netlib.org. Most of the work on integration in O2scl is relatively well-settled. I recently used it to compute a rather nasty 6-dimensional integral (complete with nasty poles from quasiparticle propagators and all).scareduck wrote:Turns out some folks have been writing a fully C++-ized scientific library called O2scl. Haven't looked at it closely yet, but it could come in handy.
Take care,
Andrew
Thanks for the tips awsteiner.
I started debugging, and found a basic "oh crap" with nan's. My theory was slightly wrong, so I fixed it and uploaded a new version of Virtual Polwell take 3. Off by 1 and division by zero for something as simple as uniform area on a sphere should have been obvious - but sometimes you just gotta do the work to find it.
Hopefully I'll have something to work in a week or so.
Edit: fix url
I started debugging, and found a basic "oh crap" with nan's. My theory was slightly wrong, so I fixed it and uploaded a new version of Virtual Polwell take 3. Off by 1 and division by zero for something as simple as uniform area on a sphere should have been obvious - but sometimes you just gotta do the work to find it.
Hopefully I'll have something to work in a week or so.
Edit: fix url
In the interest of open source, I've uploaded the "version 0.0.0" which runs to completion:
electron_phase.c
It exits all the code (I put in a printf("done!\n") just to make sure) but still gives a seg fault.
So I must be screwing up pointers someplace. Printing out a few points looks ok in terms of numbers, but I need to think of a way to visualize the data. For the moment every time step is saved, but I suspect that would be way too much data for a long run.
I'll be trying to deal with plotting the data next - but any ideas are welcome.
electron_phase.c
It exits all the code (I put in a printf("done!\n") just to make sure) but still gives a seg fault.
So I must be screwing up pointers someplace. Printing out a few points looks ok in terms of numbers, but I need to think of a way to visualize the data. For the moment every time step is saved, but I suspect that would be way too much data for a long run.
I'll be trying to deal with plotting the data next - but any ideas are welcome.
I finally settled on using the GMP library as a jumping-off point for rebuilding Gauss-Kronrod, but it turns out this requires the MPFR library to do any kind of transcendentals. That, however, complicates matters by providing only a C interface, and no operator overloading. As a result, there are several add-on packages out there that provide the necessary wrapper library but they each have their flaws. The least flawed that I can tell of so far is Alexei Beshenov's MPFRCPP library, but unfortunately C++ has changed so dramatically in the ensuing years since I last picked it up (I've been working mostly in C, Perl, and PHP in the ensuing time) that I can't quite make heads or tails of it, and the books I do have appear to be woefully out of date. I put in more orders to Amazon... sheesh.
Re: Integration and O2scl
Yeah, the big problem is if you want to do anything but double precision calculations, you're screwed because the abscissas and weights for the underlying Gauss-Kronrod integrations are calculated only to double precision. So if you want to use the qd library (for instance) or the GMP library to a specified precision, you're hosed unless you recalculate those constants yourself. Which is what I'm trying to do.awsteiner wrote:Since you mentioned O2scl, thought I'd stop by. I believe it's the integration you're interested in, in which case I should point out that O2scl uses essentially the same basic code as in GSL, which is itself a C-implementation of QUADPACK at netlib.org. Most of the work on integration in O2scl is relatively well-settled. I recently used it to compute a rather nasty 6-dimensional integral (complete with nasty poles from quasiparticle propagators and all).