Below is a table summarizing the results of recent thermal defocus experiments. The values are the calculated change in measured defocus per unit temperature change of the sensor:
Experiment |
72710a |
72710b |
72810a |
72910a |
DeltaS/DeltaT (x) [m^-1/K] |
-1.31E-4 |
-1.46E-4 |
-1.40E-4 |
-1.52E-4 |
DeltaS/DeltaT (y) [m^-1/K] |
-1.63E-4 |
-1.53E-4 |
-1.56E-4 |
-1.70E-4 |
More detail on these experiments will be available in my second progress report, which will be uploaded to the LIGO DCC by next Monday.
The main purpose of this particular eLog is to summarize what functions I wrote and used to do this data analysis, and how I used them. All relevant code which is referenced here can be found on the SVN; I uploaded my most recent versions earlier today.
Here is a flowchart summarizing the three master functions which were specifically addressed for each experiment:

py4plot.m is probably the most complicated of these three functions, in terms of the amount of data analysis done, so here's a flowchart which shows how the function works and the main subfunctions that it addresses:

Also, here is a step-by-step example of how these functions might be used during a particular experiment:
(1)Suppose that I have an experiment which I have named "73010a", in which I wish to take 40 images of 200 sums. I would open the code for framesumexport2.py and change lines 7, 8 and 17 to read:
7 LoopN=40
8 SumN=200
17 mainoutbase="73010a"
And I would then save the changes. I would double-check that the output basename had indeed been changed to 73010a (it will overwrite existing data files, if you forget to change the basename before running it). I would then let the script run (changing the set temperature of the lab after the first summed image was taken). Note that the total duration of the measurement is a function of how many images are summed and how many summed images are taken (in this example, if I was taking each single image at a rate of 11Hz, data collection would take ~20 seconds and data processing (summing the images) would take ~4 minutes (on the order of ~1 second per image in the sum) (the script isn't very quick at summing images, obviously).
EDIT(7/30 3:40pm): I just updated framesumexport2.py so that the program prompts you for this information. I also changed enabled execute permissions on the copy of the code on the Hartmann machine located in /users/jkunert/, so going to that directory and typing ./framesumexport2.py then inputting the information when prompted is all you need to do now. No need to go change around the actual code every time, any more.
(2)Once data collection had ceased entirely, I would open MATLAB and enter the following:
[x,y,dx,dy,time,M,centroids]=pyanalyze_uni('73010a',40);
The function would then look for 73010a.raw and 73010a.txt in ./opt/EDTpdv/ and import the 40 images individually and centroid them. The x and y outputs are the centroid locations. If, for example, 952 centroids were located, x and y would be 952x1x40 arrays. M would be a 40x4 array of the form:
[time_before_img_taken time_after_img_taken digitizer_temp sensor_temp]
(3)Once MATLAB had finished the previous function, I would input:
tG=struct;
py4plot('73010a',0,39,x,y,'73010a','200',[1 952],2,tG)
The inputs are, respectively:
(1)python output basename,
(2)first image to analyze (where the first image is image 0),
(3)last image to analyze,
(4)x data (or, rather, data to analyze. to analyze y instead, just flip around "x" and "y" in the input),
(5)y data (or, if you want to analyze the y-direction, "x" would be the entry here),
(6)experiment name,
(7)number of sums in each image (as a string),
(8)range of centroids to include in analysis (if you have 952 centroids, for example, and no ridiculous noise at the edges of the CCD, then [1 952] would be the best entry here),
(9)outlier tolerance (number of standard deviations from initial fit line that a datapoint must be within to be included in the second line fitting, in the dx vs x plot),
(10)exponential fitting structure (input an empty structure unless the temperature/time exponential fit turns out poorly, in which case a better fit parameter guess can be inputted as field tG.guess) |