MFMP: Automated experiment with Ni-LiAlH

BobHiggins

I was looking to doing it in a more general way, applicable to other data and setups as well. The process I'm doing is very similar to what you just described, except that I'm looking for the data points where input power changes the most, then back off a little from there to find settled temperatures and power.

It seems that the tube is requiring a bit less heating power for the same temperatures compared to the previous calibration. Here I'm using the same scale you used for your calibration graph.

can,

I went to a good deal of trouble to document the position of the control thermocouple junction coming out of the last experiment and then put it back in the same measured position for this calibration.

BobHiggins

Here are the settled temperature and power data points I have for the ongoing run, if you're interested checking/verifying them out in detail:

0 20.269128 0.000000
1 99.985764 7.839422
2 150.119477 12.898864

3 200.026566 18.259071

4 249.971209 24.112105

5 300.061297 30.244218

6 350.028534 36.811278

7 400.018285 43.482862

8 449.942648 50.382975

9 500.124163 57.344809

10 549.994370 64.812710

11 599.680412 72.817857

12 649.987899 80.373628

13 700.433194 89.006773

14 750.010100 97.307769

15 799.985766 106.204750

16 850.001880 114.910574

17 899.999560 124.606630

18 950.023008 134.319156

I wonder whether you could use a rudimentary machine learning model, e.g., from scikit-learn, and train it to identify the step boundaries with labeled data. It would take as input the power-in and the temperature-out.

Eric Walker

For what it's worth, yesterday I tried searching for peak finding functions or functions looking for local minima, but it does not seem to be an easy problem to solve efficiently, at least from a cursory search and for my capabilities. In the end I opted for something simple that could be applicable to these experiments. I didn't investigate whether scikit-learn could be useful, and as of yet I do not have any experience with machine learning. I'll try looking into it.

BobHiggins

Here's a comparison of the old calibration with the new one:

Two difficulties with using a scikit-learn model would be (1) you'd need enough labeled data for input to the model (e.g., taking real data sets and manually annotating step boundaries) and (2) the trained model itself is a binary that is not something you can include in a code printout. But with enough training data my guess is that you will obtain a fairly accurate function, provided there are few pathological corner cases in the training data to mess things up. This is not to say that it would be straightforward to attempt to train such a model without prior exposure to simple machine learning tasks.

EDIT: the calibration procedure is now complete.

The polynomial coefficients for this calibration curve are:

5.90037299e-05, 8.76003394e-02, -1.42850249e+00

The actual data is:

In the end since I wasn't 100% sure that I was sampling the correct data points I chose to very simply sample a row of (averaged) data every hour since the start of the experiment. Since every step is exactly one hour long this makes it pretty easy to obtain a calibration curve. It's not a "smart" method like the one I was previously using, but it worked pretty well for this calibration run.

In case you're curious, here is the code used to compute this:

https://github.com/can2can/LEN…mshell_round02_postcal.py

https://github.com/can2can/LEN…master/clamshell_utils.py (used for reading csv files and computing power data; if there is a related problem, it's probably here)

Below is also attached a zip file containing:

- Raw .csv data with proper timestamps and computed columns

- 30 seconds averaged data

- Only the calibration datapoints (as pasted above)

can

Thanks. I am grateful for all of your work! I am going to confirm this morning. What concerns me is doing the 30s averaging. If it is done as a blanket running average of the waveform, it will average in the step to the new power/temperature into the most settled points at the end of each soak. I think what needs to be done is identification of the the last 2 minutes of the soak, for example before the step in the raw data, and average only those data points together to get a settled data point. The difference is likely small.

BobHiggins

I understand your concern given that I started iterating from the very first sample and assumed that the next one would always be after exactly 60 minutes. Here's power data as used by the calibration above together with the same data shifted back by 5 samples (= 150 seconds) so that the average will certainly not include data from the next step. Due to this shift the first datapoint is not available (NaN):

In this case there doesn't seem to be much difference overall. In some cases input power is slightly higher, in others slightly lower, but there's one anomalous exception. Perhaps, for added safety margin next time using the same method, it would be better to include a longer period at zero input power at the beginning of the run so that I can iterate in 1-hour steps a bit earlier from the beginning.

can,

You can presume that at zero power, the temperature is ambient.

BobHiggins

I found that apparently the rolling mean used by that resampling function here is right-aligned by default (an option must be set to make it centered, but incidentally it doesn't work on time-series), so it shouldn't take into account new temperature and power values.

So, here's a calibration curve computed using a 60 second rolling mean of the original data, shifting all values by 1 sample and manually setting for the first data point (which otherwise becomes indefinite) input power to zero and temperature to ambient:

It looks essentially the same as the other calibration.

can,

Ok, just as a check (not any kind of competition), I did the calibration in a likewise fashion in Matlab. I averaged 70 points that were 10 points inward from the temperature change step. In general I got the same numbers as you did. The important numbers were different by less than 0.1%. However, my 200C number was lower by 2% because it appears I took it closer to the edge. In the low temperatures, it takes longer to settle because the temperature difference to ambient is smaller and the state was not settled until close to the step. Overall, our coefficients were very close:

Regardless, your numbers are close enough and by far close enough where there would be any XH (going forward).

Now to begin getting ready for the next experiment. Likely the next one will begin a week from Tuesday (don't want the monitoring across Easter).

Good to know that the values I previously found were indeed more or less accurate, less so that the calibration indeed changed by more than 10% at high temperatures.

Ultimately, the point of this exercise was also showing that it's useful when the data allows to compute calibration values in automated manner, just like this experiment series is supposed to be performed.

can,

Yes, this is consistent with the analysis you did before of the experimental data as it was coming in - when you added the computed COP showing a nearly constant 1.1.

On an unrelated note, I probably found in the disassembled USX program (using Java Decompiler) where the numbered filename of the saved spectra is composed during a run with the UCS-20 spectrometer.

It's in mca_stand_alone > MultiRunThread.class > saveRun(int number)

The saveRun function has a line that goes like this:

f = new File(this.directory + "//" + this.file_name + "_" + number + ".spu");

In order to make the filename number zero-padded (i.e. 00001, 00010, 00341, etc) this should be:

f = new File(this.directory + "//" + this.file_name + "_" + String.format("%05d", number) + ".spu");

However, I'm not capable of editing the class java bytecode directly to add this, and previously I haven't had success rebuilding it from the extracted source code either.

can,

I am going to try hacking the USX app this afternoon. I will see if I can make this work and will test it on the spectrometer. Thanks! I will let you know if it works.

I have heard back from Spectrum Techniques regarding a fix for the time stamp issue:

We have tracked down the time stamp issue that you reported and are sending you a new executable jar file. This new jar file fixes the problem by using a 24 hour time stamp. Find this new jar file attached to this e-mail.

To install this new file on your local computer, make sure the USX application is not currently running. Next, you will need to find the existing MCA_Stand_Alone.jar file on your computer. Rename this file to something like 'MCA_Stand_Alone_Original.jar'. This step is necessary so you may restore the old MCA_Stand_Alone.jar file in case something goes wrong and to differentiate the old file from the new one that uses a 24 hour clock format.

To locate the existing jar file right click on the USX software icon (on the desktop), select 'Properties', and click the 'Find Target' button. Your existing MCA_Stand_Alone.jar file is located in the Windows Explorer window that appears. Rename this 'MCA_Stand_Alone.jar' file to 'MCA_Stand_Alone_Original.jar'. Paste the new jar file (which is attached to this e-mail) exactly as it is currently named into the Windows Explorer window. Re-launch the USX application. Click Spectrum > Multiple Runs as you normally do and run the experiments. When you load the resulting .spu files the start and end times they contain will be in a 24-hour clock format.

Unfortunately, owing to the fact that you are running our software on a Windows XP computer, we are unable to offer you a solution to the file naming and sequencing issue. It will be necessary for you to upgrade your OS to Windows 7 or later for us to be able to fix this problem for you. Please advise concerning how you want to proceed with this matter.

I am going to install their code. Then maybe I will try the hack to fix the sequencing afterward. I am putting their new MCA_Stand_Alone.jar file here:

https://drive.google.com/file/…NNDI4RVE/view?usp=sharing

Quote from BobHiggins

I have heard back from Spectrum Techniques regarding a fix for the time stamp issue:

Interesting that they changed one instance of the format string to "HH:mm" but not the second (only two appear in this binary). The version string is "1.2.00 USB" and "Released: June 14th, 2013"

I haven't tried running it yet, my UCS30 is on a different computer.

Why wouldn't they provide new executables on their website (which got recently redesigned) ?

http://www.spectrumtechniques.com/products/components/

Anyway, if they went though the trouble of correcting this bug, perhaps they could also fix the filename "issue", which would make archiving more convenient.

can,

Regarding the string formation for the multi-run file naming, can you identify the binary difference for the two lines you showed?