Virtual Polywell
No, the "TOOSMALL" parameter was to avoid division by zero or almost zero when you get close to the MaGrid. The potential from a charge can't include itself, so that's a way to check without really knowing where you are in the integral. You can probably change the size of TOOSMALL to be 6 orders of magnitude smaller without much problem.
I can create double precison data - in fact I have - but you need quad precision. I guess you can just append zeros - we'll stick with "crude" initialization just to get things up.
The electric potential is in file electron_potential_pass2.dat and the magnetic potential is in file
magnetic_potential.dat.
I ended up bypassing GSL for my final attempts. I just couldn't pass the 1/48 symmetry to it sensibly.
I can create double precison data - in fact I have - but you need quad precision. I guess you can just append zeros - we'll stick with "crude" initialization just to get things up.
The electric potential is in file electron_potential_pass2.dat and the magnetic potential is in file
magnetic_potential.dat.
I ended up bypassing GSL for my final attempts. I just couldn't pass the 1/48 symmetry to it sensibly.
Kinda off topic, but while trying to write up the math last night using my old version of TeXmacs I wanted to draw a simple picture. I tried downloading a newer version, but it still can't do any drawings. It can import drawings though, but all the software I can find is either very fancy and way too complicated, or it uses lots of packages I don't have on my Linux box and I'd rather not add - or both.
I can write code to create PNG files, but it seems like over kill. I can also just use words and hope people understand what I'm talking about.
So I'm wondering about other Linux users - is there a really simple to use drawing program that do circles and lines with some text labels that can save as postscript (or something texmacs can deal with)? Seems like computer people who like linux don't like "simple".
I can write code to create PNG files, but it seems like over kill. I can also just use words and hope people understand what I'm talking about.
So I'm wondering about other Linux users - is there a really simple to use drawing program that do circles and lines with some text labels that can save as postscript (or something texmacs can deal with)? Seems like computer people who like linux don't like "simple".
I was looking at the GSL integration code in depth this morning, and it turns out there are a number of numerical constants that are derived from calculations done by one L.W. Fullerton at Bell Labs in Nov. 1981. These are stored internally as double strings, but if I could get the originals -- calculated out to 80 decimal places -- I could convert the library to use the qd library and we might be able to get somewhere with this. I have also found some papers online describing methods to calculate these, so we'll see where those go, too.
I ran across Xfig this morning too, but I wasn't sure it would be "simple". I guess it is worth a try!
You might as well do the calculation with the quad precision library from scratch. That way everything will be compatable. I would think that the process would then be an open source suite useful for a lot of people, so I expect the GSL guys to be appreciative. Might be worth asking on the GSL list serve (help-gsl@gnu.org) and see if anyone else has tried it.
You might as well do the calculation with the quad precision library from scratch. That way everything will be compatable. I would think that the process would then be an open source suite useful for a lot of people, so I expect the GSL guys to be appreciative. Might be worth asking on the GSL list serve (help-gsl@gnu.org) and see if anyone else has tried it.
I was going to start with the GIMP and go from there, because I have used it for that in the past, but found its UI to be horribly obtuse for drawing applications, not to mention generally underpowered. Apparently I'm not the only one, because the author of Xfig had the same experience. Luckily for you, he decided to do something about scratching that particular itch.drmike wrote:I ran across Xfig this morning too, but I wasn't sure it would be "simple". I guess it is worth a try!

I was also going to see if I could get a response out of the qd library developers to see if they knew where I could find the specific paper listing those 80-digit precision constants. To be honest, I'm not quite sure how many decimal digits of precision we're supposed to be getting; 15.5 decimal digits per double seems about right (actually 15 plus a bit or two). Either way, it should be interesting!You might as well do the calculation with the quad precision library from scratch. That way everything will be compatable. I would think that the process would then be an open source suite useful for a lot of people, so I expect the GSL guys to be appreciative. Might be worth asking on the GSL list serve (help-gsl@gnu.org) and see if anyone else has tried it.
The constants appear in the integration/qk*.c files of the gsl package. Here's one example from qk31.c:drmike wrote:What are the constants? I have a book that lists many across the page, might be at least 40 digits. It's called "Computer Approximations", was written in the 1960's, and hasn't really been bested.
Code: Select all
/* Gauss quadrature weights and kronrod quadrature abscissae and
weights as evaluated with 80 decimal digit arithmetic by
L. W. Fullerton, Bell Labs, Nov. 1981. */
static const double xgk[16] = /* abscissae of the 31-point kronrod rule */
{
0.998002298693397060285172840152271,
0.987992518020485428489565718586613,
0.967739075679139134257347978784337,
0.937273392400705904307758947710209,
0.897264532344081900882509656454496,
0.848206583410427216200648320774217,
0.790418501442465932967649294817947,
0.724417731360170047416186054613938,
0.650996741297416970533735895313275,
0.570972172608538847537226737253911,
0.485081863640239680693655740232351,
0.394151347077563369897207370981045,
0.299180007153168812166780024266389,
0.201194093997434522300628303394596,
0.101142066918717499027074231447392,
0.000000000000000000000000000000000
};
Incidentally, the coefficients are from the Gauss-Kronrod quadrature method, developed by the Russian mathematician Alexander Kronrod. Its principle benefit is that you can calculate error bands and integral approximations using the same data points. The references section off the first link contains a number of books that may have the data I'm looking for.
I got xfig to run, but as soon as I hit any of the menu buttons, it chokes and dies. I couldn't figure out how to draw straight lines either, although it could do tangets and that might have been good enough. But I can't save, so there's no point in it. Linux is ok, but for fancy stuff like graphics it does seem like you have to be on the same platform as the developer.
I'll skip pictures for now - I think getting the code to work is more important.
I'll skip pictures for now - I think getting the code to work is more important.
Which is why I run a mixed Linux-Mac household: if there is something I can't do on Linux I can usually find a way to make it happen under MacOS. But I'll be damned if I give a nickel to Redmond. My wife has had to do this, but she's a TV/film composer, and the hardware she uses isn't connected to the network; there's also some fitness stuff she does that requires Internet access under Windows, of all the stupid things, but she runs Windows in an emulation mode under OS X. I suspect it's more stable that way anyhow!drmike wrote:I got xfig to run, but as soon as I hit any of the menu buttons, it chokes and dies. I couldn't figure out how to draw straight lines either, although it could do tangets and that might have been good enough. But I can't save, so there's no point in it. Linux is ok, but for fancy stuff like graphics it does seem like you have to be on the same platform as the developer.
I'll skip pictures for now - I think getting the code to work is more important.
Well of course I ran down to my local university library to do some research on this subject. It turns out to have been of a fair amount of interest, because I was able to siphon off a half dozen papers on the calculation of Gauss-Kronrod abscissae matrices, including one by T.N.L Patterson (Mathematics of Computation, vol. 22, p. 847), Dirk P. Laurie (ibid., vol. 66, p. 1133), and an improved version of the latter by Calvetti, Golub, Bragg, and Reichel (ibid., vol. 69, p. 1035). And, I picked up four other papers and errata on Gauss-Kronrod integration published in that same journal, so there's a lot of reading ahead.
Kronrod himself, according to Patterson, did his calculations to 65 decimal digits to get 40 digits of accuracy. This may or may not have some implications for how to generate the higher-precision abscissae; Patterson claims his method is numerically stable because it's based on Legendre polynomials.
Of course, after I got home, it occurred to me to look in my copy of Numerical Recipes. Bingo! Turns out they have an algorithm to calculate the abscissa, too, but the advantage is that they've got theirs already written in C. I also have the code in machine-readable form at the office ... on a floppy disk... I think my wife may have a USB floppy drive floating around somewhere. I can only chuckle about the transience of digital media.
Edit: One more note: Kronrod originally published his method in 1965, and it generated quite a lot of interest, because the earliest papers modifying his method I have thus far seen were published three years later. It's kind of shocking because he was running a prestigious Soviet physics lab, ITEP, at the time, and the amount of actual publishable material exiting the USSR had to be vanishingly small.
Also, Numerical Recipes explicitly mentions Patterson as a reference here, so I feel pretty good about using his paper as a basis for these calculations. On the other hand, maybe it would be prudent to use an arbitrary precision math library with some number of guard digits, just to be safe.
Kronrod himself, according to Patterson, did his calculations to 65 decimal digits to get 40 digits of accuracy. This may or may not have some implications for how to generate the higher-precision abscissae; Patterson claims his method is numerically stable because it's based on Legendre polynomials.
Of course, after I got home, it occurred to me to look in my copy of Numerical Recipes. Bingo! Turns out they have an algorithm to calculate the abscissa, too, but the advantage is that they've got theirs already written in C. I also have the code in machine-readable form at the office ... on a floppy disk... I think my wife may have a USB floppy drive floating around somewhere. I can only chuckle about the transience of digital media.
Edit: One more note: Kronrod originally published his method in 1965, and it generated quite a lot of interest, because the earliest papers modifying his method I have thus far seen were published three years later. It's kind of shocking because he was running a prestigious Soviet physics lab, ITEP, at the time, and the amount of actual publishable material exiting the USSR had to be vanishingly small.
Also, Numerical Recipes explicitly mentions Patterson as a reference here, so I feel pretty good about using his paper as a basis for these calculations. On the other hand, maybe it would be prudent to use an arbitrary precision math library with some number of guard digits, just to be safe.
Last edited by scareduck on Wed Mar 05, 2008 4:30 pm, edited 1 time in total.
Sounds like way too much fun! Always double check Numerical Recipes, I've run into lots of bugs in their code. But the theory is always right.
PARI/GP is a really good symbolic/infinite precision package. And I've got a home brew floating point package which has 32 bit exponent and 256 bit mantissa. Hmmm, I guess I never ran that on a 64 bit processor, no reason I can't double that if I want to. Makes more sense to go with PARI though, lots of mathematicians use that and it is well debugged.
PARI/GP is a really good symbolic/infinite precision package. And I've got a home brew floating point package which has 32 bit exponent and 256 bit mantissa. Hmmm, I guess I never ran that on a 64 bit processor, no reason I can't double that if I want to. Makes more sense to go with PARI though, lots of mathematicians use that and it is well debugged.
Dont't use old and ugly Xfig, there is _much_ better (and actively developed) vector drawing application: Inkscape. I use Inkscape and it is IMHO even better than Corel Draw or similar commercial applications. Just try it, Inkscape is really great!drmike wrote:I got xfig to run, but as soon as I hit any of the menu buttons, it chokes and dies. I couldn't figure out how to draw straight lines either, although it could do tangets and that might have been good enough. But I can't save, so there's no point in it. Linux is ok, but for fancy stuff like graphics it does seem like you have to be on the same platform as the developer.
I'll skip pictures for now - I think getting the code to work is more important.
"Those who would give up Essential Liberty to purchase a little Temporary Safety, deserve neither Liberty nor Safety."
-- Benjamin Franklin
-- Benjamin Franklin