More database plotting - 4 dimensions

Well, it appears there's no really good way to do this here. This will contain various bits of code used to support the fusor, which presently includes everything from embedded 8 bit uP code to stuff to run under Linux in some HLL (often perl) to interface-specific stuff for commercial hardware, sysadmin tips and setups, and running on whatever machines I have in the tree here. So any one piece might fit some other category too, but...there's no pigeon-holing even computer science without losing the app-specific stuff and inter-relations of it all in a specific usage.
Forum rules
Code sharing for fusor data aq and control software

More database plotting - 4 dimensions

Postby Doug Coulter » Thu Apr 06, 2017 3:24 pm

Been working on a re-write of the old "eye candy" code and getting somewhere. This does up to 4 dimensional plots - X, Y, Z, and color, and lets you twirl the plot to see it from any angle.
To make this really useful, it need presets and some ability to dynamically map data onto the various plot axes, which this does. I'd have to call this "research grade" code, which perhaps isn't what you'd think - research grade code here means "you run it to get an answer" not "it's production-ready to hand to monkeys with no changes needed henchforth". Not hardly. There is so much possible in gnuplot I doubt that code could even be done. So what I did do is to attempt to write this code so that it'd be easy to change as required to "get that answer" which in my case also means making it clear enough that I can understand what I did later on. I think I might have pulled that off, but you guys will be the judge of course. I kind of understand what Linus T means by "taste" and why this upsets people for whom all things are (or should be...those of little imagination) codifiable in rules - lists of 10 or less of course.

For example, lots of people don't like Perl. I get it, I really do. I don't like a lot of things, but I don't blame bad code I've been brought in to maintain on the language - as someone said, a sufficiently advanced programmer can write horrible code in any language. Or close. I chose to write C in Perl. Here, an example is that there are GUI elements that need a name, a pointer to each, also needing a name, and of course, some variable that would contain what's in the GUI edit box, checkbox, whatever. I *could* have used basically the same name for all of those, hard-coded into some array, and used symbolic references and an obscure map transform to retrieve those names at will - rendering the code utterly opaque (but short) to all but me (eg, some programmers do stunts like that for job security). But I didn't. You can also write good code in almost any language, if you have taste...whatever that means.
Here it is:
The code...put in /home/you/bin
(8.77 KiB) Downloaded 16 times

So, this idea of putting run data into a database for later mining is beginning to pay off a little. Having more than one tool for this is important, as each tool is better at highlighting some aspect another might obscure.
Here are some examples. This program is currently named PlotD (which will change as I version and so on).
GUI for the current toy

PlotD raw plot as scatter plot

PlotD Q plot (arb units for Q)

Yes, the above might lead you to believe we have a breakthrough, as the normal fusor operation shows as "Q=1" here...and we're going up a lot higher than that in this plot. Not confirmed yet - possibly could be an instrumentation issue...working that. For this run, we were part of the time "dithering" the ion grid to cause non-equilibrium behavior, as can be seen in our other plots, the ones we use while running. Of course, if this will keep up in real time, we'll run this too...I'm not out of computer monitors by a long shot.
The GUI for the other plot program. Both use the database on the fusor pi.

Power consumption vs time

Geiger and Neutron counts vs time.

This shows our 2.5 hz dithering as sampled at 10 hz.. which gets pretty hard to see even at full screen in a decent length run. This was a "nothing special" run, it just happened to be the last one in my backup copy of the database I made to do this software on. It is possible that the time constants involved in reporting the volts and milliamps cause a misalignment with the neutron counts, giving a wrong estimate of Q...but then, there's how hot the activation samples are getting, and they're getting hot enough to make me glad I'm doing this it's not all wrong.
We've had to go to indium for that, the silver was both getting "out of hand hot" and due to the fast decay of silver, the time it takes to get over there and move it to the counter was becoming an issue, even though we do have log plots and can extrapolate back. Gold next!

But those who are wondering why I'm not out there with fantastic claims should understand that until this is absolutely hammered down with no doubt whatever, I'd only have to deal with a ton of (deserved) crap from all the other real scientists out no claims yet; besides, this is FAR from the best numbers we've seen...but gotta make really sure before starting that firestorm, like a good boy, eh?.

In later tests, the dithering will be more in the range of 100's kHz, so the other numbers will be more accurate due to averaging it all out. I just have to build some more gear, write the software to remote control it, the usual boring drill...repeat as necessary.

(hitting upload limit for the board, I'll continue in a reply to this)
Posting as just me, not as the forum owner. Everything I say is "in my opinion" and YMMV -- which should go for everyone without saying.
User avatar
Doug Coulter
Posts: 3038
Joined: Wed Jul 14, 2010 7:05 pm
Location: Floyd county, VA, USA

Re: More database plotting - 4 dimensions

Postby Doug Coulter » Thu Apr 06, 2017 3:29 pm

Here's some less-important data from the same run. Note we know our PKR-251 reads around 2x high on deuterium. No biggie if you know this.
I note the previous posts shows neutron counts in the 12k/min range. That equates to something a little over 12 million neutrons/second, and we're really pretty sure about that - the integrated counts and our activation samples agree completely on that. The question not yet answered here is about Q. Did those high counts really happen at near-zero power, or were the time delays between the counting and the power sensing enough to give us a false number? Stay tuned, I'm at least as curious as anyone else...I tried this "dithering" as for the entire time I've been at this game, it has seemed that anything that kicked the fusor off it's "dynamic equilbrium" made it better, so we thought we'd add a deliberate kick. This one is probably not ideal, it was just easy to add in an afternoon.
Pressure vs time
Posting as just me, not as the forum owner. Everything I say is "in my opinion" and YMMV -- which should go for everyone without saying.
User avatar
Doug Coulter
Posts: 3038
Joined: Wed Jul 14, 2010 7:05 pm
Location: Floyd county, VA, USA

Return to Fusor support

Who is online

Users browsing this forum: No registered users and 1 guest