| ID |
Date |
Author |
Type |
Category |
Subject |
|
311
|
Tue Feb 12 16:18:29 2008 |
rob | Configuration | Computer Scripts / Programs | 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 |
Andrey | Summary | Computer Scripts / Programs | 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 |
Andrey | Bureaucracy | Computer Scripts / Programs | 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 |
rob | Bureaucracy | Computer Scripts / Programs | MDV library does not work at "LINUX 2" |
| Quote: |
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. |
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 | Summary | Computer Scripts / Programs | 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 | Update | Computer Scripts / Programs | 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 | Update | Computer Scripts / Programs | 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 |
rob | Update | Computer Scripts / Programs | routing PEM -> ASS -> SUS_MCL |
| Quote: |
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 |
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 |
rana | Update | Computer Scripts / Programs | 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 |
rob | Update | Computer Scripts / Programs | tdsread bugs |
| Quote: | 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> |
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: | 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. |
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 |
Andrey | DAQ | Computer Scripts / Programs | 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 | Summary | Computer Scripts / Programs | 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 |
Andrey | Update | Computer Scripts / Programs | 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 |
rana | Summary | Computer Scripts / Programs | 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 |
rob | Update | Computer Scripts / Programs | 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 |
tobin | Configuration | Computer Scripts / Programs | 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 |
Max Jones | Update | Computer Scripts / Programs | 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 |
Max Jones | Update | Computer Scripts / Programs | 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 |
Max Jones | Update | Computer Scripts / Programs | 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 |
rana | Update | Computer Scripts / Programs | 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 |
rana | Update | Computer Scripts / Programs | Alarm Handler |
| Please do not turn off the Alarm Handler on op540m. |
|
615
|
Tue Jul 1 14:24:58 2008 |
rob | HowTo | Computer Scripts / Programs | 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 |
rob | HowTo | Computer Scripts / Programs | 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 | Update | Computer Scripts / Programs | 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 |
Max Jones | Update | Computer Scripts / Programs | 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 |
rana | Configuration | Computer Scripts / Programs | 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 |
rana | Configuration | Computer Scripts / Programs | 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 | Update | Computer Scripts / Programs | 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 | Update | Computer Scripts / Programs | burtwb missing on Solaris but installed on linux64 |
| Quote: | 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. |
The automatic backup of /cvs/cds (and /frames/minute-trends ) to the LIGO archive in Powell-Booth,
which runs from fb40m using the scripts in /cvs/cds/caltech/scripts/backup ,
stopped when fb40m was rebooted on June 28, 2008,
and the check_backup script I run to send an email when this happens also failed due to a scripting error.
But we still have a backup of /cvs/cds from June 27.
The backup of /cvs/cds (excluding /cvs/cds/caltech and /cvs/cds/tmp)
circa June 27, 2008
has been restored to
/cvs/cds/recover_20081020 .
Please check to see that it has what we need.
Before moving it over to where it belongs,
it would be really nice to figure out what happened...
Meanwhile, I have fixed the check_backup script and restarted the backup, which will run this evening...
but maybe I should wait till the dust settles?
Now is also a good time to think about whether there is anything else besides for
/cvs/cds and /frames/minute-trends that should be backed up regularly.
- Alan |
|
1075
|
Thu Oct 23 18:45:18 2008 |
Alberto | Omnistructure | Computer Scripts / Programs | Python code for GPIB devices developed for the Absl length experiment |
I wrote two Python scripts for my measurement that can be also used/imitated by others: sweepfrequency. py and HP8590.py. The first is is the one that we run by a Python interpreter (just typing "python <name script> <parameters>"from the terminal). It manages the parameters that we have to pass it for the measurement and calls the second one, HP8590.py which actually does most of the job.
Here what it does. It scans the frequency of the Marconi and, for each step, searches the highest peak in the Spectrum Analyzer (which is centered 50 KHz around the frequency of the Marconi). It then associates the amplitude of the peak to the frequency of the Marconi and write the two number in two columns of a file.
The file name, the GPIB-to/LAN interface IP address, the frequency range, the frequency step amplitude and the number of measures we want it to average for each step, are all set by the parameters when we call sweepfrequency.py.
More details are in the help of the function or just looking at the header of the code.
I guess that one can perform other similar measurement just with little changes in the code so I think it could turn out useful to anyone else. |
| Attachment 1: HP8590.py
|
# This function provides the measuremeent of the peak amplitude on the spectrum analyzer
# HP8590 analyzer while sweeping the excitation frequency on the function generator.
#
# Alberto Stochino 2008
import re
import sys
import math
from optparse import OptionParser
from socket import *
... 55 more lines ...
|
| Attachment 2: sweepfrequency.py
|
## sweepfrequency.py [-f filename] [-i ip_address] [-a startFreq] [-z endFreq] [-s stepFreq] [-m numAvg]
#
## This script sweeps the frequency of a Marconi local oscillator, within the range
## delimited by startFreq and endFreq, with a step set by stepFreq. An arbitary
## signal is monitored on a HP8590 spectrum analyzer and the scripts records the
## amplitude of the spectrum at the frequency injected by the Marconi at the moment.
## The GPIB address of the Marconi is assumed to be 17, that of the HP Spectrum Analyzer to be 18
## Alberto Stochino, October 2008
... 51 more lines ...
|
|
1091
|
Sun Oct 26 21:02:18 2008 |
rana | Update | Computer Scripts / Programs | SVN medm problem |
As we've seen in the past a few times, there's something wrong with the files in the trunk/medm area.
I get the following error message when doing a fresh checkout:A c1/lsc/help/C1LSC_LA_SET.txt
svn: In directory 'c1/lsc/help'
svn: Can't copy 'c1/lsc/help/.svn/tmp/text-base/C1LSC_RFadjust.txt.svn-base' to 'c1/lsc/help/.svn/tmp/C1LSC_RFadjust.txt.tmp.tmp': No such file or directory It looks like that there are some .svn files which have been checked in as if they're some kind of source code instead of just maintenance files.
We probably have to go through and clean this out and then remove these excess files somehow. |
|
1092
|
Mon Oct 27 10:02:16 2008 |
Yoichi | Update | Computer Scripts / Programs | SVN medm problem |
I tried to check out medm directory both from my laptop and nodus.
I did not get the error.
Have you already fixed it ? Or maybe it is to do with the version of the svn used to checkout ?
| Quote: | As we've seen in the past a few times, there's something wrong with the files in the trunk/medm area.
I get the following error message when doing a fresh checkout:A c1/lsc/help/C1LSC_LA_SET.txt
svn: In directory 'c1/lsc/help'
svn: Can't copy 'c1/lsc/help/.svn/tmp/text-base/C1LSC_RFadjust.txt.svn-base' to 'c1/lsc/help/.svn/tmp/C1LSC_RFadjust.txt.tmp.tmp': No such file or directory It looks like that there are some .svn files which have been checked in as if they're some kind of source code instead of just maintenance files.
We probably have to go through and clean this out and then remove these excess files somehow. |
|
|
1213
|
Fri Jan 2 17:20:44 2009 |
rana | Summary | Computer Scripts / Programs | 40m GWINC |
I have made a '40m' directory in the iscmodeling CVS tree which allows one to run a 40m version of GWINC.
As does the previous one, it takes the default advLIGO config file and modifies some of the struct parameters
to make it appropriate for the 40m.
To make it run, I have added susp1.m to the GWINC directory. This calculates suspension thermal noise using
the Gonzalez-Saulson method that was later extended to
mirrors by Y. Levin. This is also the code used in the LIGO Noise Budget at the sites.
The previous code was giving a much larger value for thermal noise (probably because I didn't understand how
to use it right). It was based on a SURF report from '99.
Since we will have a mixture of MOSs and SOSs in the arms, I have just used SOSs in the model. So the suspension
thermal noise is overestimated by ~sqrt(2) (and realistically its uncertain by a much larger factor).
Since the new code now uses GWINC, the mirror and coating thermal noise are now more correct and use the
coherent therm-optic noise picture.
The 2 page PDF file shows the noise for 0 deg and 90 deg tuning of the SRC.
Although it looks like, from this plot, that we could measure coating thermal noise at the 40m, in reality we would have
to fix all of the technical noise sources first. Just the coil driver noise is probably at the level of 3 x 10^-17 m/rHz
at 100 Hz. |
| Attachment 1: bench40.pdf
|
|
|
1215
|
Sun Jan 4 13:17:23 2009 |
Alan | Omnistructure | Computer Scripts / Programs | New 40mWebStatus |
I have set up some code in /cvs/cds/caltech/scripts/webStatus along with a cronjob on controls@nodus to generate a webStatus every half hour, at 40mWebStatus
you are welcome to add/delete lines corresponding to interesting EPICS channels, in the template /cvs/cds/caltech/scripts/webStatus/webStatus_template.html . The 2nd number is the "golden" value of the EPICS channel; it can be edited by hand, or one could copy a "golden" webStatus.html to webStatus_template.html . I think it's probably premature to automate this...
I noticed that Yoichi also has a cron job posting 40m medm screen snapshots. Very nice.
controls@nodus also runs a third cronjob, which checks if the nightly backup fails, and if so, sends an email to me.
I guess we need some kind of "official" crontab file for controls@nodus so that we know how/where to add things. So, I put one in /cvs/cds/caltech/crontab/controls@nodus.crontab |
|
1216
|
Mon Jan 5 11:21:05 2009 |
Alan | Omnistructure | Computer Scripts / Programs | New 40mWebStatus |
| Quote: |
I guess we need some kind of "official" crontab file for controls@nodus so that we know how/where to add things. So, I put one in /cvs/cds/caltech/crontab/controls@nodus.crontab |
Alan and I agreed that we should edit the crontab by "crontab -e" command rather than editing the "official" crontab in /cvs/cds/caltech/crontab/.
After confirming that the new crontab works as expected, you are encouraged to make a copy of the new crontab into /cvs/cds/caltech/crontab/ as a backup.
Then do "svn ci" in the directory. |
|
1328
|
Fri Feb 20 01:54:18 2009 |
Kakeru | Update | Computer Scripts / Programs | tdsdata might have a bug |
I found a strange jump of value in my data taken with tdsdata.
I couldn't find same jump in a playback of DataViewer, so I think this is a problem of tdsdata.
Be careful when you use tdsdata!
The attached file is an example of jumped data.
I try to get data with allegra and op440m, and both has same kind of jump.
(A downsampling or interpolation may be wrong.)
Rana said there is a fixed version of tdsdata in some PC, but 64bit linux may not have.
I try it tomorrow. |
| Attachment 1: jumped_data.png
|
|
|
1354
|
Wed Mar 4 12:38:07 2009 |
Alberto | Update | Computer Scripts / Programs | 3f locking simulations |
I simulated the REFL signals demodulated at the differential frequencies of the sidebands (f2-f1), at their summed frequencies (f2+f1). I also simulated their combination as in the Double Demodulation.
I repeated the simulation for:
- Old (current) 40m
- 40m Upgrade
- AdvLIGO
I'm attaching the results to this elog entry.
The plots show how the signal varies exploring the two-dimensional space of the demodulation frequencies (differential and sum).
Both the Upgrade and the Old40m's signals look anomalous since the zero-crossing point does not change with the demodulation phases.
I suspect there's is a problem with the optickle model of the 40m. |
| Attachment 1: 23_3f_40mOld_DDplots.pdf
|
|
| Attachment 2: 59_3f40m_Upgrade_DDplots.pdf
|
|
| Attachment 3: 20_3f_AdvL_DDplots.pdf
|
|
|
1371
|
Sun Mar 8 23:14:52 2009 |
rana | Update | Computer Scripts / Programs | tdsdata doesn't work |
Matt logged in and rebuilt the TDS stuff for us on Mafalda in /cvs/cds/caltech/apps/linux/tds_090304.
He says that he can't build his stuff on 64-bit because there's not a sanctioned 64-bit build of GDS yet.
This should have all the latest fixes in it. I tried using both the old and new code from allegra and they both are fine:
./tdsdata 16384 2 C1:IOO-MC_F > /users/rana/test.txt
I loaded the data I got with the above command and there were no data dropouts. Possibly the dropout problem is only
associated with testpoints and so we have to wait for the TP fix. |
|
1375
|
Mon Mar 9 14:57:30 2009 |
Kakeru | Update | Computer Scripts / Programs | tdsdata doesn't work |
I tested new tdsdata and found it was working well.
I excited C1:SUS-ITMY_SUSPIT_EXC with tdssine, and get data from C1:LSC-TRY_OUT (testpoint) and C1:SUS- ITMY_OPLEV_PERROR (recorded point) with new and old tdsdata.
With old tdsdata (/cvs/cds/caltech/apps/linux/tds/bin/tdsdata), I found some jumps of datapoint, which is a same problem with before (Attachment 1).
With new tdsdata (/cvs/cds/caltech/apps/linux/tds_090304/bin/tdsdata), there looks to be no jumps (Attachment 2; taken about 10 minutes after Attachment 1).
The problem of old tdsdata looks to be remaining even for recordedpoints.
You should use /cvs/cds/caltech/apps/linux/tds_090304/bin/tdsdata.
|
Quote:
|
|
Matt logged in and rebuilt the TDS stuff for us on Mafalda in /cvs/cds/caltech/apps/linux/tds_090304.
He says that he can't build his stuff on 64-bit because there's not a sanctioned 64-bit build of GDS yet.
This should have all the latest fixes in it. I tried using both the old and new code from allegra and they both are fine:
./tdsdata 16384 2 C1:IOO-MC_F > /users/rana/test.txt
I loaded the data I got with the above command and there were no data dropouts. Possibly the dropout problem is only
associated with testpoints and so we have to wait for the TP fix.
|
|
| Attachment 1: oldtds.png
|
|
| Attachment 2: newtds.png
|
|
|
1376
|
Mon Mar 9 16:54:52 2009 |
Kakeru, Rana | Update | Computer Scripts / Programs | tdsdata doesn't work |
We confirmed that new tds(/cvs/cds/caltech/apps/linux/tds_090304/) works well on linux 64, and replaced it to /cvs/cds/caltech/apps/linux/tds/
The old /cvs/cds/caltech/apps/linux/tds is put in /cvs/cds/caltech/apps/linux/tds.bak |
|
1380
|
Mon Mar 9 23:13:22 2009 |
Yoichi | Update | Computer Scripts / Programs | tdsdata doesn't work |
| Quote: |
|
We confirmed that new tds(/cvs/cds/caltech/apps/linux/tds_090304/) works well on linux 64, and replaced it to /cvs/cds/caltech/apps/linux/tds/
The old /cvs/cds/caltech/apps/linux/tds is put in /cvs/cds/caltech/apps/linux/tds.bak
|
The tdscntr.pl in the new tds was probably the one from LLO, which is actually the version I sent to Tobin. It had paths and channel names defined for the LLO. So I copied back my original 40m version. |
|
1384
|
Wed Mar 11 04:33:57 2009 |
rana | Configuration | Computer Scripts / Programs | wild ndsproxy tclshexe |
The ndsproxy tcl task on nodus was eating up all the CPU and making the elog slow. I killed it and restarted it.
It looks like it hasn't been making a log file since January. Someone who has some skill in decoding the cryptic csh stdout redirection
syntax should look into this (its in target/ndsproxy/) |
|
1417
|
Sun Mar 22 23:16:41 2009 |
rana | DAQ | Computer Scripts / Programs | tpman restart |
Could get testpoints but couldn't start excitations. Restarted tpman on daqawg. Works now.
Still no log file.  |
|
1482
|
Tue Apr 14 17:20:36 2009 |
Yoichi | Update | Computer Scripts / Programs | Parallel Optickle |
I wrote a parallel version of tickle() function for Optickle.
The attached ptickle.m, which provides ptickle() command, can be used as a drop-in replacement of tickle() command.
Just download it and place it in the @Optickle directory.
This command will run multiple instances of Matlab to calculate the frequency responses in parallel.
The speed gain is roughly proportional to the number of CPU cores you use.
To use multiple cores, you have to run matlabpool() command first. See the comment at the beginning of ptickle.m for more detail.
The progress bar is disabled at this moment because it is not clear for me how to make a single progress bar from multiple instances of Matlab.
I sent the code to Matt, so this may be included in the next release of Optickle. |
| Attachment 1: ptickle.m
|
% Compute DC fields, and DC signals, and AC transfer functions
%
% This is a parallelized version of tickle. You have to run matlabpool(n)
% command before using this command. matlabpool(n) will invoke n instances
% of matlab workers in your computer. Once you have started those workers,
% you can reuse them many times (i.e. you don't have to run matlabpoo(n)
% every time you use ptickle). Usually n should be equal to the number of
% CPU cores in your computer, but the Matlab parallel computing toolbox has
% the limit of maximum 4 workers for a local computer. If you use a cluster
% of computers across a network, this limit does not apply. But I haven't
... 393 more lines ...
|
|
1492
|
Thu Apr 16 17:48:00 2009 |
Yoichi | Configuration | Computer Scripts / Programs | AutoDTT |
As Peter mentioned in his entry on the last night's locking, I imported AutoDTT from Hanford.
It resides in /cvs/cds/caltech/scripts/AutoDTT/.
The main script is restoreRunSave, which takes three arguments, templete_file_name, result_file_name and log_file_name.
This script opens a template xml file and execute it. Then saves the result in the result file.
You can open the result file in a normal DTT.
You can call restoreRunSave from watch scripts, such as c1_watch_dr_bang.
watchLockLoss is a standalone watch script to detect a lock loss and call restoreRunSave.
It runs both on Linux and Solaris. However on Linux, diag fails 50% of the time with some glibc error.
So it is probably better to run it on op440m. |
|
1494
|
Fri Apr 17 11:37:32 2009 |
Yoichi | Configuration | Computer Scripts / Programs | AutoDTT |
In order to get test point data with AutoDTT, you have to pre-trigger test points you want to use.
This is done by starting a DTT measurement with necessary test points for a few second, then stop it but keep the DTT opened.
I made prepTP script which does this job.
It takes a file name of an XML file, which should include a DTT measurement setup with test point channels you want to open and the trigger time set to "now".
The script will open an xterm and run diag with the XML file. Unlike restoreRunSave script, it does not save the result nor quit diag. Therefore, you can keep the test points as long as you keep the xterm opened. You can manually exit the diag (Ctrl-D) when you no longer need the test points.
watchLockLoss script now calls prepTP at the beginning. Therefore, you have to be able to open an xterm. If you run the script through SSH, make sure that you give -X option to ssh. |
|
1510
|
Thu Apr 23 16:35:23 2009 |
Yoichi | Summary | Computer Scripts / Programs | restoreWatchdog script |
When the IFO loses lock during the lock acquisition steps, it often kicks the MC2 (through the CM servo) and trips the watchdog.
I wrote a script to restore the tripped watchdog (/cvs/cds/caltech/scripts/SUS/restoreWatchdog).
The script takes the name of a mirror (such as MC2) as an argument.
It will enable the coils and temporarily increase the watchdog threshold to a value higher than the current OSEM RMS signals.
Then it will bring the watchdog back to the normal state and wait for the mirror to be damped. After the mirror is damped enough, the
watchdog threshold will be restored to the original value.
The script will do nothing if the watchdog is not tripped.
I put this script in the drdown_bang so that the MC2 watchdog will be automatically restored when a lock loss kicks out the MC2. |
|
1562
|
Fri May 8 04:31:35 2009 |
rana | Update | Computer Scripts / Programs | elog and NDS |
In the middle of searching through the elog, its stopped responding. So I followed the Wiki instructions
and restarted it (BTW, don't use the start-elog-nodus script that's in that directory). Seems OK now,
but I am suspicious of how it sometimes does the PDF preview correctly and sometimes not. I found a
'gs' process on there running and taking up > 85% of the CPU.
I also got an email from Chris Wipf at MIT to try out this trick from LASTI to maybe fix the
problems I've been having with the DMF processes failing after a couple hours. I had compiled but
not tested the stuff a couple weeks ago.
Today after it failed, I tried running other stuff in matlab and got some "too many files open" error messages.
So I have now copied the 32-bit linux NDS mex files into the mDV/nds_mexs/ directory. Restarted the
seisBLRMS.m about an hour ago. |
|
1567
|
Fri May 8 16:29:53 2009 |
rana | Update | Computer Scripts / Programs | elog and NDS |
| Looks like the new NDS client worked. Attached is 12 hours of BLRMS. |
| Attachment 1: Untitled.png
|
|
|
1619
|
Fri May 22 00:43:24 2009 |
rob | Configuration | Computer Scripts / Programs | IFO configure scripts for XARM and YARM |
I edited the configure scripts (those called from the C1IFO_CONFIGURE screen) for restore XARM and YARM. These used to misalign the ITM of the unused arm, which is totally unnecessary here, as we have both POX and POY. They also used to turn off the drive to the unused ETM. I've commented out these lines, so now running the two restores in series will leave a state where both arms can be locked. This also means that the ITMs will never be deliberately mis-aligned by the restore scripts. |