ELOG 40m

DAQ

linemon

I turned up my nose at Matlab's special tools. I modified the linetracker to use the
relationship phase = 2*pi*f*t to estimate the frequency each minute. The
code uses 'polyfit' to get the mean and trend of the unwrapped phase and then determines
how far the initial frequency estimate was off. It then uses the updated number as the
initial guess for the next minute.

I looked at a couple hours of data before letting it run. It looks like the phase of the
'60 Hz' peak varies at 20 second time scales but not much faster or rather anything faster
would be a glitch and not a monotonic frequency drift.

From the attached snapshot you can see that the amplitude (PZT1_PIT) varies by ~10 %
and the frequency by ~40 mHz in a couple hour span.

Attachment 1: spd64d1.jpg

166

Wed Dec 5 16:57:36 2007

SR785 data converter on linux

I was pleased to find that the SR785 Data Viewer (including the command line conversion utility) installs and works in linux using WINE (on my laptop at least). There are some quirks, of course, but I was able to extract my data.

175

Thu Dec 6 18:11:15 2007

Making DMF monitors

I was able to use the matlab compiler to compile a version of the linetracker written by Rana, and run the compiled version on mafalda.

I believe I made the necessary edits to our mDV config file so that it should be easy for others to follow these steps:

1) Write the DMF routine you want, as a matlab function (not a script).

2) If it runs correctly in matlab, then from the matlab command line compile
it using the -m flag (i.e., mcc -m myfun.m). You should run the
compiler from the directory where you want the executable to end up (don't use the mDV/extra
directory so it doesn't get all cluttered).

3) prior to running the resulting executable (which should be called simply myfun),
prepend the directories
/cvs/cds/caltech/apps/linux/matlab/bin/glnx86
/cvs/cds/caltech/apps/linux/matlab/sys/os/glnx86/
to the LD_LIBRARY_PATH enviroment variable. These directories must be prepended as the
versions that already exist in /usr/lib don't work; I'm loathe to do this in the cshrc.40m
for fear of later conflicts, so it will need to be done in some sort of shell script which
calls the matlab executable.

180

Fri Dec 7 14:14:48 2007

Metaphysics

tdsread problems on Solaris

tdsread has developed a strange new illness, whereby it cannot read EPICS values from two subsystems at once (e.g., getting an LSC and SUS value simultaneously). I thought this might have something to with the fact that both losepics and iscepics are running on the same box,
but the same thing happens with IOO EPICS records, so that's not the culprit.

This is new behaviour, and it's only happening on the solaris machines. I suspect some ENV/cshrc juju has caused it, as the tdsread executable is the same one from April, and I don't think our EPICS infrastructure has changed otherwise. In the near term we can either try running the scripts on linux, or modify the IFO scripts to not do these types of calls.

181

Fri Dec 7 18:28:30 2007

compiled matlab hoses itself

Andrey pointed out to me that some matlab functions in the Signal Processing Toolbox were dying with errors. Looking into the .m file (identified using the "which" command), I was surprised to see binary garbage rather than glistening, clear Matlab prose. Then I noticed the directory in which it was finding the .m file:

>> which decimate
/cvs/cds/caltech/apps/mDV/extra/linetrack_c_mcr/toolbox/signal/signal/decimate.m

See that "linetrack_c_mcr" directory? This is what is generated when a "compiled" (grumble) Matlab program is run--it decompresses itself into a subdirectory containing weird semi-compiled binary .m files. Unfortunately this is somehow getting incorporated into the matlab path. (I assume there is something in mDV that says "put all subdirectories into the path.")

I hate the Matlab compiler.

182

Fri Dec 7 18:31:30 2007

compiled matlab hoses itself

Addendnum. The reason the linemon_mcr command was in the path was because of the user issuing the command "addpath(genpath(pwd))" where genpath(D) "returns a path string starting in D, plus, recursively, all the subdirectories of D."

The Matlab compiler is still bad, however.

184

Mon Dec 10 13:54:26 2007

Don't blame the Matlab compiler

For human error. We should be careful to only run the compiler outside the mDV directory (thus placing the _mcr outside of the range the addpath command in the mdv_config files). Or maybe there's a smarter solution...

187

Mon Dec 10 20:35:59 2007

autolocking scripts

I added this tidbit of csh code to the MZ autolocker to prevent multiple copies from running (on one computer):

if (`pgrep lockMZ | wc -l` > 1) then
   echo lockMZ is already running! 
   exit
endif

Similarly, here's some bash code that does something similar; I'll add it to the other autolocker scripts:

if                                                                                                                       
  pgrep `basename $0` | grep -v $$ > /dev/null                                                                           
then                                                                                                                     
  echo Another copy of this program is already running.  Exiting!                                                        
  exit 1                                                                                                                 
fi

This code searches for all processes with the same name as this script ($0) and then use grep to exclude (-v) the current process ID ($$).

191

Thu Dec 13 23:56:02 2007

Overnight measurements

After my disease (fever, vomitting, nose problem, overall weakness) I returned to LIGO today for the first time after the weekend, and I am running the script for the XARM-measurements over this night.

So, suspension dumping gains should undergo changes in the interval from 1 to 10 in both ITMX and ETMX.

XARM has been of course locked.

I started running the script for the first time at about 10PM, but I realized after an hour and a half that my step of gain increase 0.2 was too shallow, too small to execute my program during one night. Therefore, I needed to terminate the program, change my program so that it increases the gain with increment 0.5, not 0.2, and started it again around midnight.

Going home.

P.S. The red pump that I borrowed from the lab (Steve's pump?) is back at its previous place. The tire-worker tells me that I absolutely need to change all four tires for almost 500 dollars. I regret a lot about that huge money loss.

194

Mon Dec 17 23:42:08 2007

Overnight measurements in X-arm

I am making overnight measurements this night (from Monday to Tuesday) in XARM.

The X-arm is now locked, and the values for suspension damping gain will be changed in the interval from 1 to 7 with the step 0.5 in both ITMX and ETMX.

This is the second, repeated measurement. The results of the first measurement from Saturday to Sunday night will be reported in the separate ELOG entry (sorry, I did not make an ELOG entry on Saturday evening about running the program overnight).

The very first attempt to run the script in the night from Thursday to Friday was not successful.

195

Tue Dec 18 00:51:39 2007

Results of Saturday overnight measurements

As I indicated in the previous e-log entry (#194), I made overnight measurements in XARM in the night from Saturday to Sunday.

Root-mean-square values of the peaks in calibrated spectra were calculated, and I plotted them as functions of suspension gains in ITMX and ETMX "position" degrees of freedom.
More specifically, Q_ITMX means the value in the channel "C1:SUS-ITMX_SUSPOS_GAIN", while Q_ETMX means the value in the channel "C1:SUS-ETMX_SUSPOS_GAIN".

Root-mean-square values (RMS) were calculated during that night in three intervals:

1) around 0.8 HZ in the interval (0.6 Hz <-> 1.0 Hz);

2) around 3.0 Hz in the interval (2.0 Hz <-> 3.6 Hz);

3) in the broad interval from 0.6Hz to 3.6Hz.

I plotted three results for RMS in the abovementioned three intervals in three different ways:

1) view from the top in the axes (Q_{ITMX}+Q_{ETMX})/2 and (Q_{ITMX}-Q_{ETMX}) -> first three graphs (attachments 1 -3);

2) view from the side in the same sum- and difference-axes -> next three graphs (attachments 4-6);

3) view from the side in Q_{ITMX} and Q_{ETMX} axes -> next three graphs (attachments 7-9), above accelerometer spectra (attachments 10-11).

Also, I compared the ground noise level by comparing spectra of accelerometer signals at different times during that night. As a reminder, before my disease I installed one accelerometer near ITMX and another accelerometer near ETMX (see entries 161 and 172 in ELOG). The plots of ratios of accelerometer signals at different times (pairs of times that were used: 12AM and 3AM, 12AM and 6AM, 12AM and 9AM) are given below, see attachments 10-11.

Tomorrow I will try to compare the results with the second measurements that are being taken tonight.

Attachment 1: RMS_08Hz_top_view.png

Attachment 2: RMS_3Hz_top_view.png

Attachment 3: RMS_broad_top_view.png

Attachment 4: RMS_08Hz_Qsum-Qdiff-axes.png

Attachment 5: RMS_3Hz_Qsum-Qdiff-axes.png

Attachment 6: RMS_broad_Qsum-Qdiff-axes.png

Attachment 7: RMS_08Hz_Qaxes.png

Attachment 8: RMS_3Hz_Qaxes.png

Attachment 9: RMS_broad_Qaxes.png

Attachment 10: Accel_ITMX.png

Attachment 11: Accel_ETMX.png

198

Tue Dec 18 23:27:36 2007

New overnight measurements (this night from Tue to Wed)

I am making overnight measurements in XARM tonight.

This is the third night of measurements in XARM, but tonight I am scanning the narrower region between values of damping gain 1.00 and 4.50 with the smaller step 0.25. (for comparison, during two previous measurements the region was between 1.0 and 7.0 with the step 0.5).

I have relocked the XARM before the start of the measurements.

I started running the program at 9.30PM, and it should collect all the data by 9.00AM wednesday morning.

Below are explanations why I chose these different parameters for the interval and step:

I am going to put the results of previous night measurements into the next ELOG entry, and it we be pretty obvious from those graphs that results in XARM from the two previous (different) nights agree well with each other, and the approximate positions of minima and areas of "big growth" of the surfaces are pretty obvious from those graphs. It is clear that RMS are too big for the values of the damping gain bigger than 4.0, and that minima are somewhere near the values of 2.0. But those graphs were too rough to locate a somewhat precise value for the minima. Therefore, I am studying tonight the interval of gains between 1.00 and 4.50 with a smaller step.

A short note how I estimate time that is necessary to collect the experimental data.

there are 15 experimental points for each ETMX and ITMX suspension gains in the interval between 1.00 and 4.50 with the step 0.25. They are: 1.00, 1.25, 1.50, 1.75, 2.00, ..., 3.75, 4.00, 4.25, 4.50. As I am changing both ETMX and ITMX gains, I have an array of 15*15=225 elements.
It takes 3 minutes for each point to collect the data (I wrote the program that way). Therefore, the total time it takes to run the program is: 225*3=675 minutes, or 675/60=11.25 hours, almost 11 and a half hours.

199

Tue Dec 18 23:41:00 2007

Results of Mon/Tue overnight measurements (entry #194)

Here I inform our community about the results of the measurements of RMS values in XARM during the previous night from Monday to Tuesday (I announced those measurements in ELOG entry #194).

All the plots in today's report seem to agree well with the analogous plots from the night from Saturday to Sunday (those results are given in ELOG entry # 195).

All the intervals in which RMS have been calculated are the same as in yesterday's ELOG entry #195.

I plotted three results for RMS in the abovementioned three intervals in three different ways:

1) view from the top in the axes (Q_{ITMX}+Q_{ETMX})/2 and (Q_{ITMX}-Q_{ETMX}) -> first three graphs (attachments 1 -3);

2) view from the side in the same sum- and difference-axes -> next three graphs (attachments 4-6);

3) view from the side in Q_{ITMX} and Q_{ETMX} axes -> next three graphs (attachments 7-9, also attch. 12), above accelerometer spectra (attachments 10-11).

Also, I compared the ground noise level by comparing spectra of accelerometer signals at different times during that night. As a reminder, before my disease I installed one accelerometer near ITMX and another accelerometer near ETMX (see entries 161 and 172 in ELOG). The plots of ratios of accelerometer signals at different times (pairs of times that were used: 11PM and 2AM, 11PM and 5AM, 11PM and 8AM) are given below, see attachments 10-11. The program was running from 11PM on Monday till 9AM on Tuesday.

As I explained in the previous ELOG entry # 198, tonight I am taking experimental data in the narrowere interval from 1.00 to 4.50 with a smaller step 0.25.

Attachment 1: RMS_08HZ_Top_View.png

Attachment 2: RMS_3HZ_Top_View.png

Attachment 3: RMS_broad_Top_View.png

Attachment 4: RMS_08HZ_Side_View.png

Attachment 5: RMS_3HZ_Side_View.png

Attachment 6: RMS_broad_Side_View.png

Attachment 7: RMS_08HZ_Q_E_Q_I_Axes.png

Attachment 8: RMS_3HZ_Q_E_Q_I_Axes.png

Attachment 9: RMS_broad_Q_E_Q_I_Axes.png

Attachment 10: Accelerometer_ITMX.png

Attachment 11: Accelerometer_ETMX.png

Attachment 12: RMS_broad_Q_E_Q_I_Axes.png

201

Wed Dec 19 15:51:00 2007

Daytime measurements in XARM and their results

I was making measurements in XARM for three different nights. All the results agree with each other (I will put the results from the last night soon).

Steve Vass recommended to me to compare those results with the daytime data, in order to see if there is a real necessity to run the scripts overnight or if daytime results will yield similar results.

XARM has been locked, and I am taking measurements today from 3.30PM till 11.30PM.

I will be changing the suspension damping gains in ETMX and ITMX "position" degrees of freedom in the interval from 1.0 to 3.75 with the step 0.25.

BELOW: RESULTS OF MEASUREMENTS WERE ADDED ON THURSDAY, DEC. 20.

All the meaning of the attachments 1-3, 4-6, 7-9, 10-11 is the same as in previous ELOG entries # 195, # 199, # 202, see in those entries which graph corresponds to which coordinate axes orientation.

Attachment 1: RMS-08Hz-Top_View.png

Attachment 2: RMS-3Hz-Top_View.png

Attachment 3: RMS-broadband-Top_View.png

Attachment 4: RMS-08Hz-Side-View.png

Attachment 5: RMS-3Hz-Side_View.png

Attachment 6: RMS-broadband-Side_View.png

Attachment 7: RMS-08Hz-Q_I-Q_E-Axes.png

Attachment 8: RMS-3Hz-Side_View.png

Attachment 9: RMS-broadband-Side_View.png

Attachment 10: Accelerometer_ETMX.png

Attachment 11: Accelerometer_ITMX.png

202

Wed Dec 19 16:07:37 2007

Results of overnight measurements Tue/Wed night (entry #198)

As indicated in ELOG entry 198, I was making overnight measurements during last night from Tuesday to Wednesday.

I was changing the suspension damping gain in ETMX and ITMX in "position" degree of freedom between values of 1.00 and 4.50 with the step 0.25.

Results for RMS of peaks (A) at 0.8Hz, (B) at about 3.0Hz and (C) in the range from 0.6Hz to 3.7Hz ("RMS in a broad interval") are given below:

I plotted three results for RMS in the abovementioned three intervals in three different ways:

1) view from the top in the axes (Q_{ITMX}+Q_{ETMX})/2 and (Q_{ITMX}-Q_{ETMX}) -> first three graphs (attachments 1 -3);

2) view from the side in the same sum- and difference-axes -> next three graphs (attachments 4-6);

3) view from the side in Q_{ITMX} and Q_{ETMX} axes -> next three graphs (attachments 7-9)

Attachments 10 and 11 show ratios of accelerometer signals at different times of the night/morning.

A little discussion about these graphs:

1) The areas of minima and of rapid growth are the same for all the measurements during all three nights.

2) Tonight there was a strange spike for the values of Q_{ETMX}=2.5 and Q_{ITMX}=4.0. I interpret that as an error of experiment.

3) On all the plots from all three nights there is a wide area of minimum on the plots for RMS at 0.8Hz and for "RMS in the broad interval",
and the graph for "RMS at 3Hz" indicates a clearer minimum in a localized area for Q_{ITMX}=2+-1, Q_{ETMX}=2+-1. Note that this area 2+-1
is included into the wide region of minimum for "RMS at 0.8Hz" and "RMS in a broad range".

Therefore, my guess at this stage is that we can choose the optimized value of suspension damping gains for both Q_{ITMX} and Q_{ETMX} somewhere
around 2+-1. I would like to make another overnight measurement (tonight) in that narrowed region with a small step to have more certainty.

By the way, I realized that I was a little bit careless and at some plots Q_I stands for {Q_ITMX}, and Q_E stands for Q_{ETMX}.

Attachment 1: RMS_08Hz_Top_view.png

Attachment 2: RMS_3Hz_Top_view.png

Attachment 3: RMS_broad_Top_view.png

Attachment 4: RMS_08Hz_Side_view.png

Attachment 5: RMS_3Hz_Side_view.png

Attachment 6: RMS_broadband_Side_view.png

Attachment 7: RMS_08Hz_Q_I-Q_E-axes.png

Attachment 8: RMS_3Hz_Q_I-Q_E-axes.png

Attachment 9: RMS_broadband_Q_I-Q_E-axes.png

Attachment 10: Accelerom_ETMX.png

Attachment 11: Accelerom_ITMX.png

205

Thu Dec 20 02:04:09 2007

New overnight measurements in XARM and their results

I ran in the daytime/evening time my program, changing the damping gains in suspension "position" degree of freedom for ETMX and ITMX
in the interval from 1.00 to 3.75 with the step 0.25 (see entry # 201).

Now I am running overnight (from 2AM till 9AM) the program changing the gains in the interval from 1.3 to 3.5 with the step 0.20,
12 X 12 = 144 experimental points. I started so late because I fell asleep after my Wednesday evening dinner, then woke up half an hour ago and hurried to the lab.

BELOW: RESULTS OF MEASUREMENTS WERE ADDED ON THURSDAY EVENING, DEC. 20.

All the meaning of the attachments 1-3, 4-6, 7-9, 10-11 is the same as in previous ELOG entries # 195, # 199, # 202, see in those entries which graph corresponds to which coordinate axes orientation.

Attachment 1: RMS-08Hz-Top-View.png

Attachment 2: RMS-3Hz-Top-View.png

Attachment 3: RMS-broadband-Top-View.png

Attachment 4: RMS-08Hz-Side_View.png

Attachment 5: RMS-3Hz-Side_View.png

Attachment 6: RMS-broadband-Side_View.png

Attachment 7: RMS-08Hz-Q_I-Q_E-Axes.png

Attachment 8: RMS-3Hz-Q_I-Q_E-Axes.png

Attachment 9: RMS-broadband-Q_I-Q_E-Axes.png

Attachment 10: Accelerometer-ETMX.png

Attachment 11: Accelerometer-ITMX.png

208

Thu Dec 20 21:57:34 2007

Measurements in XARM today

Today at 2PM I started a program, it should change the suspension gains in the interval from 1.0 to 3.8 with the step 0.2. Estimated running time is till 3.30AM coming night.

Results will be reported on Friday.

BELOW: ADDITION MADE ON FRIDAY EVENING.

Due to some unforeseen circumstances, I was unable to add results on Friday. I have so far accelerometer spectra only, which I add to this ELOG entry.

I have files with the measurement results, and I will process them after Christmas and add to this ELOG entry. I might not be in the lab on Dec. 24 and 25.

Attachment 1: Accelerom_ETMX.png

Attachment 2: Accelerom_ITMX.png

209

Thu Dec 20 21:58:28 2007

Results for 2 previous XARM measurements have been added

I attached results (plots) of yesterday's daytime and overnight measurements to the initial reports about those measurements.

These are ELOG entries # 201 and # 205.

251

Mon Jan 21 23:30:03 2008

Matlab Program for Q-factor measurements (XARM -> ITMX and ETMX)

Finally I overcame difficulties with adapting Sonia's Matlab programs for XARM (Sonia's program was for MC),

and now there exists a Matlab program that makes a fit of a ringdown curve and calculates Q-factor for a mirror ITMX.

Specifically, this program allows to measure ringdown, fit it and calculate Q-factor for the ITMX-mirror for a specific value of
"C1:SUS-ITMX_SUSPOS_GAIN".

Attached is a plot of a ringdown curve and its fit for the value 4.0 in channel "C1:SUS-ITMX_SUSPOS_GAIN".

Calculations yield the result Q=3.7+-0.2 for the value 4.0 in channel "C1:SUS-ITMX_SUSPOS_GAIN".

As Robert started 10 minutes ago the long procedure of the whole interferometer locking,
I cannot disturb the interferometer now, so I will measure Q-factors for various combinations of suspension damping gain on Tuesday.

I will also easily modify the program for measuring Q-factors of ETMX-mirror and make measurements with ETMX on Tuesday.

The Matlab scripts are in directory /cvs/cds/caltech/users/rodionov/Q-Factors/

Attachment 1: Example-ITMX_POS_40.png

261

Thu Jan 24 22:10:49 2008

Problem with channels - help of Rana, Robert or Steve is needed

I definitely spoiled something (changes some settings) by chaotically clicking those blue buttons (see my previous entry # 260).

Unfortunately, I cannot use standard library of functions for reading from channels from mDV directory.

Although I see the curve of a noise in the Dataviewer from the channel "Ch1:SUS_ETMX_POS", when I try to read data from the channel using the program "get_data" from MDV directory, I get the error message
"Warning: No data available for [numbers representing "gps_start_time" and "gps_end_time"].
In new_readframedata at 136
In new_fetch_shourov at 71
In get_data at 98"

I checked, both gps-times are in the past from now, so as far I understand, nothing is recorded into the channels.
Of course, I added two hours ago to the directory "mDV", that is I used addpath(pwd) in that directory.

And I also cannot run the program that I used on Tuesday evening which takes data from "C1:SUS_ITMX_POS" (no data from that channel), which worked perfectly on Tuesday.

I again apologize for clicking the wrong blue button (see my explanation in my previous message #260). I ask someone who knows how to return normal working of channels (normal interaction of computer and channel memory) to do that.

Before that I cannot take data. I do not know how to restore the initial settings which existed before I started adding the channel to Dataviewer.

Andrey.

273

Sat Jan 26 02:34:34 2008

Overnight Measuremts in XARM

I am running the program for measuring RMS of peaks in XARM tonight. I just started it, and it will run for about 9 hours until noon on Saturday. Please do not disturb the interferometer. Now the XARM is locked, it should stay locked over the night.

Andrey.

311

Tue Feb 12 16:18:29 2008

autoburt cron moved to op340m

I moved the autoburt cron job from op440m to op340m. For some reason, burtrb requires gcc to run (I gather it uses the C-preprocessor to parse input files), so I had to install that on op340m to get it to work properly.

There are no more cron jobs running on op440m now.

338

Fri Feb 22 20:42:44 2008

It seems I succeeded in theoretical simulations

I am pretty happy at this moment.

I definitely feel that it took me too much time to understand how to do the Matlab program and how to overcome difficulties,

but eventually at last my Matlab program seems to start working.

Briefly: What the program does?
--> take time-domain signal from two accelerometers near ITMX and ETMX (use 'get_data');
--> calculate the time-evolution of those two signals through the system "stack + pendulum" to the test-masses ITMX and ETMS (use 'lsim' in Matlab),
which gives us the time-domain evolution of the deviation of the position of individual test-mass from its average position.
--> Subtract the two results from each other in time-domain, this gives us the deviation of the length of the XARM-cavity from its average value
(roughly speaking, deviation of the length of the cavity from exactly 40 meters, although I am aware that the exact average length of XARM is less than 40 meters).
--> Take the amplitude spectrum of the result, using Sqrt(pwelch) and calibrate it from "counts" to "meters".
--> Calculate root-mean-square of peaks at different frequency intervals, for example near 0.8Hz,
and plot the three-dimensional surface showing the dependence of RMS on Q-factors Q_{ETMX} and Q_{ITMX}.

Eventually I am able to create these dependences of RMS.

I see that the minimum of the dependence is close to the diagonal corresponding to exact equality of Q_ETMX} and Q_{ITMX}, but not exactly along the diagonal. The plot allows to say
which of two conditions "Q_I > Q_E" or "Q_E < Q_I" should be fullfilled for optimization reasons. My plot is raw, I might have made a mistake in axis-label, I do not garantee now that the axis label "Q_ITMX - Q_ETMX" is correct,
maybe I need to change it for "Q_ETMX - Q_ITMX". I need some more time to determine this on Monday, but clearly there is asymmetry between Q_I and Q_E.

The peak at 0.8 Hz is pretty stable, while the peak at around 3Hz is not very repeatable, therefore in both experimental measurements and these simulations the amplitude of RMS of peak at 3Hz) is several orders of magnitude smaller than for RMS of peak at 0.8Hz, and I do not see minimum somewhere in the RMS-dependence, I see now only steady growth of RMS as Q_factors increase.

I will need to spend some time on Monday trying to understand how the sampling frequency and number of fft-points influence my results when I take amplitude spectrum using pwelch-command, as well I will need to double-check the correctness of normalization from counts to meters (I am not confident right now that amplitude of order of 10^(-12) meters is correct).

So, I need some time after the weekend to analyze my results and maybe make some slight changes, but I am glad that my Matlab model started to work in principle. I wanted to let others know about the status of the progress in my work. The fact that Matlab program works now is a good ending of a week.

Andrey.

Attachment 1: RMS_peak_08Hz-Theoretical.png

Attachment 2: RMS_peak_08Hz-QI-QE.png

Attachment 3: RMS_peak_3Hz-Theoretical.png

Attachment 4: RMS_peak_broad-interv-Theoretical.png

339

Fri Feb 22 21:19:38 2008

Bureaucracy

MDV library does not work at "LINUX 2"

While working on Thursday evening with Matlab scripts "dttfft2" and "get_data", I noticed that mDV library does not work at computer "LINUX 2" (the third computer in the control-room if you enter it from the restroom). There are multiple error messages if we try to run "hello_world", "dttfft2" or "get_data". In order to take data from accelerometers, I changed the computer - I was working from "LINUX 3" computer, the most right computer in the control room, but for the future someone should resolve the issue at "LINUX 2". I am not experienced enough to revive the correct work of mDV directory at "LINUX 2".

Andrey.

343

Thu Feb 28 12:31:33 2008

Bureaucracy

MDV library does not work at "LINUX 2"

Quote:

This turned out to be due to /frames not being mounted on linux2, as a result of a reboot. The issue is discussed in entry 270. I remounted the /frames, and added a line to mdv_config.m to check whether the frames are mounted.

359

Wed Mar 5 12:35:09 2008

John

Plot photodiode responses in MatLab

A matlab function to plot the responses of photodiodes. There's still plenty of room for improvement but it should work for all our diodes without any changes. You may want to adjust which points are used in the fit to remove time delay.

% Plot data from diode response measurements
function out = diodeplot(f_Hz,mag_dB,phase_deg,f_beat_MHz)

% $$$ clear all
% $$$ close all
% $$$ clc
% $$$
% $$$
% $$$ mag = dlmread('D:\40m\PD6\M7.txt','\t', 15, 0);
% $$$ phase = dlmread('D:\40m\PD6\P7.txt','\t', 15, 0);
% $$$
% $$$ % Frequency i.e. x-axis
% $$$ f = mag(:,1);
% $$$
% $$$ % Magnitude in dB
% $$$ mag_dB = mag(:,2);
% $$$
% $$$ % Phase in degrees
% $$$ phase_deg = phase(:,2);
% $$$
% $$$ % Frequencies of interest
% $$$ f_beat_MHz = [33 133 166 199]*1e6;
% $$$
% $$$ diodeplot(f, mag_dB, phase_deg, f_beat_MHz)

% x axis limits
xmin = 10e6;
xmax = 500e6;

% Unwrap phase
phase_deg = (180/pi)*unwrap((pi/180)*phase_deg);

%Find values at our freqeuncies of interest
Mag_f_beat = interp1(f_Hz,mag_dB,f_beat_MHz);

% Remove the time delay from the phase data
% (May want to adjust which points are selected here)

straight = @(a, x) a(1) * x + a(2);

xdata = f_Hz;
ydata = phase_deg;

aguess = [10 0.1];
a = lsqcurvefit(straight,aguess,xdata,ydata);
fit = straight(a,xdata);

phase_deg = phase_deg-fit;

figure(1)
ha = axes('units','normalized','position',[0 0 1 1]);
uistack(ha,'bottom');
I=imread('PDbw.jpg');
hi = imagesc(I);
colormap gray
set(ha,'handlevisibility','off', ...
'visible','off')
plot(xdata,ydata,'r')
hold on
plot(xdata,fit,'k')
plot(xdata,phase_deg,'b')
hold off
ylabel('Phase/ degrees', 'FontSize',12)
xlabel('Frequency/ Hz', 'FontSize',12)
title('Removing the time delay','FontSize',16)
legend('data','fit','data-fit',0)
set(hi,'alphadata',.35)
set(gca,'Color','None')
box off

figure(2)
set(gcf,'Color', [1 1 1])
subplot(4,1,[1 3])

semilogx(f_Hz,mag_dB,'k','LineWidth',2.5)
title('Response of PD6','FontSize',16)
ylabel('Magnitude/ dB', 'FontSize',12)
xlim([xmin xmax])
grid

MagLayout = get(gca, 'Position');
YLimits = get(gca, 'YLim') ;
LabelExt = [];

for ivar = 1:length(f_beat_MHz);

a = text(f_beat_MHz(ivar),1.05 * min(Mag_f_beat),...
sprintf('%2.1fdB @ %dMHz', Mag_f_beat(ivar),f_beat_MHz(ivar)/1e6),...
'FontSize',10,'FontWeight','Bold','HorizontalAlignment','right',...
'VerticalAlignment','top','BackgroundColor',[.7 .9 .7],...
'Margin',0.5, 'Rotation',90);
LabelExt = [LabelExt; get(a,'Extent')];
LabelPos = get(a,'Position');

end

% Change YLim so that it is around the bottom of the labels
% There must be a better way
set(gca, 'YLim', [min(LabelExt(:,2)) YLimits(2)])

% Remove the last tick mark so that it doesn't overlap with the
% +180 of the phase plot
YTickLabelNew = str2num(get(gca, 'YTickLabel'));
YTickNew =[[] YTickLabelNew(2:end) ];
set(gca,'XTickLabel', [], 'YTick', YTickNew)

% Add lines now we know what the YLims are
for ivar = 1:length(f_beat_MHz);
line([f_beat_MHz(ivar) f_beat_MHz(ivar)], get(gca, 'YLim'))
end

subplot(4,1,4)
semilogx(f_Hz,phase_deg,'r','LineWidth',2.5)
xlim([xmin xmax])
ylabel('Phase/ degrees', 'FontSize',12)
xlabel('Frequency/ Hz', 'FontSize',16)
grid
PhaseLayout = get(gca, 'Position');
PhaseLayout(4) = MagLayout(2)-PhaseLayout(2);

% Make the top of the phase plot align to the bottom of the
% magnitude plot
set(gca, 'Color', 'None', 'Position',PhaseLayout, 'YTick',[-180:45: ...
180])
set(gcf,'units','normalized','outerposition',[0 0 1 1]);

Attachment 3: PDbw.jpg

375

Thu Mar 13 12:11:58 2008

aivanov

routing PEM -> ASS -> SUS_MCL

on ASS RFM 1 has PEM signals at

float at 0x100000 has c0dcu1 first ICS110B chan 1
float at 0x100004 has chan 2
etc.

ASS sends to RFM 0

float at 0x100000 goes to PRM MCL
0x100004 to BS MCL
0x100008 to IMTX MCL
0x10000c to ITMY MCL
0x100010 to SRM MCL
0x100018 to MC1 MCL
0x10001c to MC3 MCL
0x100020 to ETMX MCL
0x100024 to ETMY MCL

376

Thu Mar 13 13:15:09 2008

aivanov

new sfotware intall, backup files

New:
op440m:40m>ls -alt /cvs/cds/caltech/target/c1susvme[12]/*.o
-rw-r--r-- 1 controls staff 57920 2008-03-13 13:11 /cvs/cds/caltech/target/c1susvme2/losLinux2.o
-rw-r--r-- 1 controls staff 57976 2008-03-13 13:11 /cvs/cds/caltech/target/c1susvme1/losLinux1.o
op440m:40m>ls -alt /cvs/cds/caltech/target/c1isce[xy]/*.o
-rw-r--r-- 1 controls staff 246861 2008-03-13 13:12 /cvs/cds/caltech/target/c1iscey/losEtmy.o
-rw-r--r-- 1 controls staff 246861 2008-03-13 13:12 /cvs/cds/caltech/target/c1iscex/losEtmx.o
op440m:40m>ls -alt /cvs/cds/caltech/target/c0dcu1/*.o
-rw-r--r-- 1 controls staff 63547 2008-03-12 14:57 /cvs/cds/caltech/target/c0dcu1/dcuDma.o

Backups:
op440m:40m>ls -alt /cvs/cds/caltech/target/c1susvme[12]/*.o.13mar08
-rw-r--r-- 1 controls staff 55960 2005-06-21 13:30 /cvs/cds/caltech/target/c1susvme2/losLinux2.o.13mar08
-rw-r--r-- 1 controls staff 55960 2005-06-21 13:30 /cvs/cds/caltech/target/c1susvme1/losLinux1.o.13mar08
op440m:40m>ls -alt /cvs/cds/caltech/target/c1isce[xy]/*.o.13mar08
-rw-r--r-- 1 controls staff 229793 2007-03-08 11:09 /cvs/cds/caltech/target/c1iscex/losEtmx.o.13mar08
-rw-r--r-- 1 controls staff 229793 2007-03-08 11:09 /cvs/cds/caltech/target/c1iscey/losEtmy.o.13mar08
op440m:40m>ls -alt /cvs/cds/caltech/target/c0dcu1/*.o.12mar08
-rw-r--r-- 1 controls staff 60810 2004-09-08 08:47 /cvs/cds/caltech/target/c0dcu1/dcuDma.o.12mar08

380

Fri Mar 14 15:06:24 2008

routing PEM -> ASS -> SUS_MCL

Quote:

You can differentiate between RFM 0 and RFM 1 in the simulink model by adding 0x4000000 to the offsets for RFM 1.

430

Sun Apr 20 20:29:46 2008

tdsread bugs

There seems to be a problem with reading the C1:IOO-MASTER_OVERFLOW field
when it is read in as part of an array. The only way for me to describe it
is to just attach the terminal output in this entry...this is mainly for
Matt and Rob.

I first noticed that the output of the MC-WFS sensing matrix was different than
the outputs from a year ago, namely that the excitation channel was not being
processed and outputted to the file. This made the output matrix diagonalization
scripts fail.

I noticed that there are several different copies of tdsread.cc sitting around.
Looks like they have been hacked in the last year but I am not sure if this
excitation channel readback is an intentional change; email has been sent to the
authors to find out -- they will probably post some kind of response in the log
to resolve what's up.

My guess is that the problem with the IOO channel is not related, but I'm not sure:

op440m:WFS>set ioo_head = "${ifo}:IOO-"
op440m:WFS>set sus_head = "${ifo}:SUS-"
op440m:WFS>set oflows = `tdsread ${sus_head}MC1_MASTER_OVERFLOW ${sus_head}MC2_MASTER_OVERFLOW ${sus_head}MC3
_MASTER_OVERFLOW ${ioo_head}MASTER_OVERFLOW`
ERROR: C1:IOO-MASTER_OVERFLOW value not read
op440m:WFS>set oflows = `tdsread ${sus_head}MC1_MASTER_OVERFLOW ${sus_head}MC2_MASTER_OVERFLOW ${ioo_head}MAS
TER_OVERFLOW`
ERROR: C1:IOO-MASTER_OVERFLOW value not read
op440m:WFS>set oflows = `tdsread ${ioo_head}MASTER_OVERFLOW`
op440m:WFS>set oflows = `tdsread ${sus_head}MC1_MASTER_OVERFLOW ${ioo_head}MASTER_OVERFLOW`
ERROR: C1:IOO-MASTER_OVERFLOW value not read
op440m:WFS>set oflows = `tdsread ${sus_head}MC1_MASTER_OVERFLOW ${ioo_head}MASTER_OVERFLOW ${sus_head}MC2_MASTER_OVERFLOW`
ERROR: C1:IOO-MASTER_OVERFLOW value not read
op440m:WFS>echo $oflows
0
op440m:WFS>set oflows = `tdsread ${ioo_head}MASTER_OVERFLOW`
op440m:WFS>echo $oflows
0
op440m:WFS>set oflows = `tdsread ${sus_head}MC1_MASTER_OVERFLOW ${sus_head}MC2_MASTER_OVERFLOW ${sus_head}MC3_MASTER_OVERFLOW`
op440m:WFS>echo $oflows
0 0 0
op440m:WFS>echo `tdsread ${sus_head}MC1_MASTER_OVERFLOW ${ioo_head}MASTER_OVERFLOW ${sus_head}MC2_MASTER_OVERFLOW`
ERROR: C1:IOO-MASTER_OVERFLOW value not read
0
op440m:WFS>echo "tdsread ${sus_head}MC1_MASTER_OVERFLOW ${ioo_head}MASTER_OVERFLOW ${sus_head}MC2_MASTER_OVERFLOW"
tdsread C1:SUS-MC1_MASTER_OVERFLOW C1:IOO-MASTER_OVERFLOW C1:SUS-MC2_MASTER_OVERFLOW
op440m:WFS>

433

Mon Apr 21 13:12:21 2008

tdsread bugs

Quote:

op440m:WFS>set ioo_head = "${ifo}:IOO-"
op440m:WFS>set sus_head = "${ifo}:SUS-"
op440m:WFS>set oflows = `tdsread ${sus_head}MC1_MASTER_OVERFLOW ${sus_head}MC2_MASTER_OVERFLOW ${sus_head}MC3
_MASTER_OVERFLOW ${ioo_head}MASTER_OVERFLOW`
ERROR: C1:IOO-MASTER_OVERFLOW value not read
op440m:WFS>set oflows = `tdsread ${sus_head}MC1_MASTER_OVERFLOW ${sus_head}MC2_MASTER_OVERFLOW ${ioo_head}MAS
TER_OVERFLOW`
ERROR: C1:IOO-MASTER_OVERFLOW value not read
op440m:WFS>set oflows = `tdsread ${ioo_head}MASTER_OVERFLOW`
op440m:WFS>set oflows = `tdsread ${sus_head}MC1_MASTER_OVERFLOW ${ioo_head}MASTER_OVERFLOW`
ERROR: C1:IOO-MASTER_OVERFLOW value not read
op440m:WFS>set oflows = `tdsread ${sus_head}MC1_MASTER_OVERFLOW ${ioo_head}MASTER_OVERFLOW ${sus_head}MC2_MASTER_OVERFLOW`
ERROR: C1:IOO-MASTER_OVERFLOW value not read
op440m:WFS>echo $oflows
0
op440m:WFS>set oflows = `tdsread ${ioo_head}MASTER_OVERFLOW`
op440m:WFS>echo $oflows
0
op440m:WFS>set oflows = `tdsread ${sus_head}MC1_MASTER_OVERFLOW ${sus_head}MC2_MASTER_OVERFLOW ${sus_head}MC3_MASTER_OVERFLOW`
op440m:WFS>echo $oflows
0 0 0
op440m:WFS>echo `tdsread ${sus_head}MC1_MASTER_OVERFLOW ${ioo_head}MASTER_OVERFLOW ${sus_head}MC2_MASTER_OVERFLOW`
ERROR: C1:IOO-MASTER_OVERFLOW value not read
0
op440m:WFS>echo "tdsread ${sus_head}MC1_MASTER_OVERFLOW ${ioo_head}MASTER_OVERFLOW ${sus_head}MC2_MASTER_OVERFLOW"
tdsread C1:SUS-MC1_MASTER_OVERFLOW C1:IOO-MASTER_OVERFLOW C1:SUS-MC2_MASTER_OVERFLOW
op440m:WFS>

This is the same bug described in entry 180. I believe it has nothing to do with tdsread, which did not change in the time period before the bug appeared, but perhaps has something to do with other EPICS libraries somewhere (tdsread relies on these epics libraries to do its dirty work). Here is entry 180 for reference:

Quote:

The solution that's been in effect for the past few months has just been to modify the scripts to not make these kinds of calls.

440

Wed Apr 23 22:39:54 2008

DAQ

Problem with "get_data" and slow PEM channels

It turns out that I cannot read minute trends for the slow weather channels for more than 1000 seconds back (roughly more than 15 minutes ago) using "get_data" script.

For comparison, I tried MC1 slow channels, and similar problem did not arise there. Probably, something is wrong with the memory of slow weather channels. At the same time, I can see minute-trends in Dataviewer as long ago as I want.

In response to
>>get_data('C1: PEM-weather_outsideTemp', 'minute', gps('now') - 3690, 3600);
I get the error message:
"Warning: Missong C1: PEM-weather_outsideTemp M data at 893045156".

441

Thu Apr 24 11:50:10 2008

josephb

Useful tidbits learned while tracking the network setup

In process of understanding the network setup I've learned several things:

1) The status lights on C0DAQ_RFMNETWORK.adl are controlled by the fiber network, as opposed to the ethernet network. However, even if everything is working properly on the VME end, you may still need to reboot it in order to be able to contact it via the ethernet (ssh or telnet).

2) After disconnecting the hub out by 1Y9, I was able to telnet into c1vac1, but not c1vac2. I was told that the Turbo pump and Ion pump readbacks on C0VACMONITOR.adl had not been working for awhile (years?). So I went out and rebooted the c1vac2 card. This seemed to restore the epic channels and we now have correct readbacks on the turbo pumps. The ion pumps all are reading no voltage, which is good because they're turned off. However C1:Vac-IPSE_mon is reading "On", although Steve assures me the actual unit is currently off, so there may be a minor channel issue there.

458

Mon Apr 28 23:44:33 2008

Weather.db

I was trying to figure out how to modify the file "Weather.db" so that the atm.pressure would be recalculated from Pa to bar before appearing in the EPICS screen, but so far I did not succeed. I restarted processor "c1pem1" several times. I will continue this tomorrow, and also I will modify the nmaes of the weather channels.

484

Sun May 18 18:14:30 2008

autlockers and cron

Today I noticed that the MC was unlocked, the MC autolocker was off, the PSL autolocker was off,
and the PSL Slow loop was off.

Reading through .log files and our elog it seems like things have been this way since Tuesday
when Andrey went around rebooting computers to bring things back.

And it looks like the ETMY optical lever is dead.

I restarted the PSL & MC scripts on op340m. I also locked and aligned the X arm to verify that
not everything is broken. The Y Arm is unalignable until we replace the HeNe.

490

Wed May 21 15:21:33 2008

autolockers and cron

I added hourly cron jobs to op340m to ensure that

MC autolocker
FSS Slow Servo
PSL watch

are running. I've also edited the wiki procedure to reflect the fact that these no longer need to be restarted by hand.

500

Tue May 27 16:24:54 2008

ndsproxy

The NDS Proxy is a program that accepts NDS (LIGO Network Data Server) connections from the internet and relays them to
our internal frame-builder, so that you can get DAQ and test-point channel data from off-site.

I stopped the ndsproxy that was running on rana and started it on nodus, its new home. This will be
documented in the wiki.

So far I haven't found a mechanism by which the ndsproxy was restarted automatically on rana. Has it just been
restarted by hand?

The ndsproxy stuff lives in target/ndsproxy. Restarting it seems to be just a matter of running "start_ndsproxy" in
that directory.

535

Mon Jun 16 18:26:01 2008

Noise Budget Changes

In the directory cvs/cds/caltech/NB the following changes were made:

I created temporary files in ReferenceData for the C1 by copying and renaming the corresponding H1 files.
- C1_SRD_Disp.txt
- C1IFOparams.m
- C1_NoiseParams.m

In getmultichan.m I added a C1 case.

In NoiseBudget.m I added a C1 case with modified sources array to include only DARM and Seismic

I appreciate and suggestions. Max.

542

Wed Jun 18 18:32:09 2008

NB Update

I am reconfiguring the the noisebudget code currently in use at the sights. To that end, I have done the following things (in addition to the elog I posted earlier)

In get_dtt_dataset.m - I added C1 specific cases for DARM_CTRL, SEIS, and ITMTRX changing the specific channels to make those in use at caltech

In LocalizeSite.m - I changed the NDS_PATH to match caltechs. I left NDS_HOST untouched.

Since I am trying to get SEIS and DARM to work initially I added C1 specific cases to both of these.

Better documentation may be found in /users/mjones/DailyProgressReport/06_18_08. Suggestions are appreciated. Max.

565

Wed Jun 25 11:36:14 2008

First Week Update

For the first week I have been modifying the noise budget script in caltech/NB to run with 40 m parameters and data. As per Rana's instructions, I have tried to run the script with only seismic and Darm sources. This involves identifying and changing channel names and altering paramter files (such as NB/ReferenceData/C1IFOparams.m). To supply the parameter files, I have copied the H1 files with (as yet only) slight modification. The channel name changes have been made to mirror the sites for the most part. Two figures are attached which show the current noise budget. The Day plot was taken 6/23/08 at ~10:30 am. The night plot was taken 6/22/08 at ~11:00 pm . Note that the SRD curve is for the sites and not for the 40 m (I hope to change that soon). Also in one of the plots the DARM noise signal is visible. Obviously this needs work. A list of current concerns is

1) I am using a seismic transfer function made by previous SURF student Ryan Kinney to operate with channels of the form C1:PEM_ACC-ETMY_Y (should I be using C1:DMF-IX_ACCY?) and the channels I am currently using are the acceleraometers for the mode cleaner with names of the form C1:PEM_ACC-MC1_X. Rana said that he thinks these may be the same but I need to be sure.

2) We don't have a DARM_CTRL channel but the code requires it, currently I am using DARM_ERR as a substitute which is probably partly responsible for the obvious error in DARM noise.

Any suggestions are appreciated. Max.

Attachment 1: C1_NoiseBudgetPlot_Day.eps

Attachment 2: C1_NoiseBudgetPlot_Night.eps

576

Thu Jun 26 18:27:04 2008

No Dataviewer No Cry

Dataviewer was hanging. It would open the Grace window but then not plot anything. Since DTT was working
fine we diagnosed this as a DV only problem. It turned out that there was a boatload of messages in the
dataviewer queue. You can check for extra messaages using the command 'ipcs -q' and then use 'rmq' to remove them.

Dataviewer is working now.

Here's the screen dump from op440m:

op440m:~>ipcs -q
IPC status from <running system> as of Thu Jun 26 18:19:32 PDT 2008
T         ID      KEY        MODE        OWNER    GROUP
Message Queues:
q        400   0x1a51     -Rrw-rw-rw- controls    staff
q          1   0x501      -Rrw-rw-rw- controls    staff
q          2   0x512      -Rrw-rw-rw- controls    staff
q        103   0x553      -Rrw-rw-rw- controls    staff
q          4   0x574      -Rrw-rw-rw- controls    staff
q          5   0x18be     --rw-rw-rw- controls    staff
q         56   0x1d9f     -Rrw-rw-rw- controls    staff
q          7   0x1e56     -Rrw-rw-rw- controls    staff
q          8   0x1efd     -Rrw-rw-rw- controls    staff
q        109   0x2044     -Rrw-rw-rw- controls    staff
q         10   0x207a     -Rrw-rw-rw- controls    staff
q         11   0x24c4     -Rrw-rw-rw- controls    staff
q         12   0x24d7     -Rrw-rw-rw- controls    staff
q         13   0x251b     -Rrw-rw-rw- controls    staff
q         14   0x2fe8     -Rrw-rw-rw- controls    staff
q        115   0x3a65     -Rrw-rw-rw- controls    staff
q        116   0x967      -Rrw-rw-rw- controls    staff
q         17   0x98e      -Rrw-rw-rw- controls    staff
q        118   0x456c     -Rrw-rw-rw- controls    staff
q        669   0x194      -Rrw-rw-rw- controls    staff
q        620   0xe70      -Rrw-rw-rw- controls    staff
q         71   0x15d0     -Rrw-rw-rw- controls    staff
q        222   0x3586     -Rrw-rw-rw- controls    staff
q        173   0x5e37     -Rrw-rw-rw- controls    staff
q        624   0x5e4d     -Rrw-rw-rw- controls    staff
q        475   0x10d7     -Rrw-rw-rw- controls    staff
q        176   0x5ee3     -Rrw-rw-rw- controls    staff
q        277   0x4e22     -Rrw-rw-rw- controls    staff
q        428   0x25f3     -Rrw-rw-rw- controls    staff
q         29   0x3354     -Rrw-rw-rw- controls    staff
q        180   0x368f     -Rrw-rw-rw- controls    staff
q        131   0xb0f      -Rrw-rw-rw- controls    staff
q         82   0x47a5     --rw-rw-rw- controls    staff
q         83   0x4b83     -Rrw-rw-rw- controls    staff
q         34   0x4f6d     -Rrw-rw-rw- controls    staff
q         85   0x4539     -Rrw-rw-rw- controls    staff
q         86   0x67a1     --rw-rw-rw- controls    staff
q         37   0x4b7      -Rrw-rw-rw- controls    staff
q         38   0xd37      -Rrw-rw-rw- controls    staff
q         39   0x156c     -Rrw-rw-rw- controls    staff
q         40   0x2b62     -Rrw-rw-rw- controls    staff
op440m:~>rmq
---------------------------------------------------------------
Deleting message queues which are owned by user: controls ....
---------------------------------------------------------------
      Deleted message queue: 400
      Deleted message queue: 1
      Deleted message queue: 2
      Deleted message queue: 103
      Deleted message queue: 4
      Deleted message queue: 5
      Deleted message queue: 56
      Deleted message queue: 7
      Deleted message queue: 8
      Deleted message queue: 109
      Deleted message queue: 10
      Deleted message queue: 11
      Deleted message queue: 12
      Deleted message queue: 13
      Deleted message queue: 14
      Deleted message queue: 115
      Deleted message queue: 116
      Deleted message queue: 17
      Deleted message queue: 118
      Deleted message queue: 669
      Deleted message queue: 620
      Deleted message queue: 71
      Deleted message queue: 222
      Deleted message queue: 173
      Deleted message queue: 624
      Deleted message queue: 475
      Deleted message queue: 176
      Deleted message queue: 277
      Deleted message queue: 428
      Deleted message queue: 29
      Deleted message queue: 180
      Deleted message queue: 131
      Deleted message queue: 82
      Deleted message queue: 83
      Deleted message queue: 34
      Deleted message queue: 85
      Deleted message queue: 86
      Deleted message queue: 37
      Deleted message queue: 38
      Deleted message queue: 39
      Deleted message queue: 40
---------------------------------------------------------------
op440m:~>

578

Thu Jun 26 20:59:22 2008

Alarm Handler

Please do not turn off the Alarm Handler on op540m.

615

Tue Jul 1 14:24:58 2008

conlog time machine

I've written a perl script (now in the $SCRIPTS/general directory) which implements a "conlog restore" command, restoring channels matching a regexp to a given time using the conlog records and the EpicsTools.pm perl module. The script is called time_machine_conlog:

Quote:

op440m:~>time_machine_conlog

time_machine_conlog restores EPICS control settings using a conlog time
usage: time_machine_conlog [<--dryrun>] <date=yyyy/mm/dd,hh:mm:ss> <timezone> <regexp>

Can also accept a gps time, in which case timezone=gps.
Use the option <--dryrun> to see conlog output without restoring any settings.

EXAMPLE: time_machine_conlog 2008/05/30,12:00:00 PDT "C1:SUS-MC.*_(PIT|YAW)_COMM"

It sometimes returns an error message even when the command is successful--this is because conlog stores EPICS settings to an absurd level of precision, but ezcawrite will not write EPICS values to this level (or at least won't indicate if it did). I consider this a bug in ezcawrite so I'm not touching it.

The script is untested with regards to switch settings (such as ENABLE/DISABLE). It's mainly intended for numerical values.

617

Tue Jul 1 21:27:27 2008

slider twiddling after reboot

Sometimes after we reboot the front-end machines, some of the hardware gets stuck in an unknown state. We generally fix this by twiddling EPICS settings, which refresh the hardware somehow and put it into a known state. I've started a script (slider_twiddle) which we can just run after reboots to do this for us. Right now it just has the QPD whitening gain settings. As we find more stuff, we can add to it. It's in $SCRIPTS/Admin/.

721

Wed Jul 23 10:49:37 2008

Max

Weekly Progress Report

This week I installed the magnetometer. The channels seem to be reading correctly. I'm back to working on noise budget and have added the MICH and will soon add the PRC source. The various source-specific scripts still need to be adjusted and the transfer functions remeasured since they do not match in any reasonable manner the SRD Rana put out in the e-log yesterday.

766

Wed Jul 30 13:08:44 2008

Weekly Summary

This week I've been working on the noise budget script. The goal is to add Siesmic, Darm, Mich, Prc and magnetometer noise. I believe I've added Seismic noise in a reasonable and 40m specific manner (please see the attached graph). The seismic noise in the noise budget at 100 Hz was 10 times higher than that predicted by Rana in elog #718. This could be due to the fact that graph is taken from data today when the device is unlocked and construction workers are busy next door. I am currently trying to fix the getDarm.m file to add the DARM source to the noise budget. I have run into several problems, the most pressing of which was that the C1:LSC-DARM_ERR channel is zero except with the interferometer is being locked. According to Rob, we only save data for approximately a day (we save trends for much longer but this is insufficient for the noise budget script) and sometimes we are not locked the night before. Rob showed me how I may introduce an artificial noise in the DARM_ERR signal but I'm having trouble making the script output a graphic. I'm still unsure how to make the getDarm function 40m specific.

Today I will start working on my second progress report and abstract.

Attachment 1: C1_NoiseBudgetPlot.pdf

784

Sat Aug 2 16:05:38 2008

mDV update

I did an svn update on our mDV directory. Justin has improved it so that the NDS client binaries
are included for solaris, mac, linux32, and linux64. Now you can just use this version without
having to worry about any path definitions.

988

Wed Sep 24 19:13:06 2008

updatedb & locate: megatron & rosalba

I ran updatedb as root today on megatron and rosalba just before the meeting.
It finished at ~14:10 on both machines so that's ~20 minutes total.

The default updatedb.conf for these guys also seems to be set up right so that
it is indexing the NFS mount (/cvs/cds/) so that's good. Next, someone needs to
add the updatedb command to the daily cron for each of these guys (5 AM) and
add this to the wiki page on how we set up new computers.

I also found that the root passwd on Megatron was different from all of the other
machines, indicating that perhaps megatron was trying to free himself. I have put
down that rebellion viciously:D and he's now toeing the line.

1056

Fri Oct 17 21:41:09 2008

Yoichi

burtwb missing on Solaris but installed on linux64

c1lsc stalled this evening, so I powercycled it.
After that, I tried to lock arms to confirm the computer is working.
Then I realized that the restore alignment buttons do not work from any control room computer.
I found that it was because burtwb command was missing. For Solaris, looks like there used to be /cvs/cds/epics/extensions/burtwb but now
there is no /cvs/cds/epics directory. I thought there were directories other than "caltech" in /cvs/cds/, weren't there ?
Right now, there is only /cvs/cds/caltech.
Anyway, I installed burt for 64bit linux computer (under /cvs/cds/caltech/apps/linux64/epics/extensions/).
At this moment the alignment save/restore works on allegra (and probably on rosalba), but not on op440m yet.

1058

Mon Oct 20 12:18:38 2008

Alan