40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
 40m Log, Page 321 of 339 Not logged in
ID Date Author Type Category Subject
14025   Wed Jun 27 19:05:20 2018 ranaUpdateComputersrossa: SL7.3 upgrade continues: DTT is back

UNELOGGED: someone has changed Pianosa from Ubuntu/Dumbian into SL7. Might be hackers.

Donatella is now the only Ubuntu machine in the control room. I propose we keep it this way for another month and then go fully SL7 if we find no bugs with Pianosa/Rossa.

15463   Thu Jul 9 16:16:20 2020 gautamUpdateComputersrossa: graphics driver issues?

I noticed these streaky lines again today (but they were not a problem last night). It is annoying if we have to reboot this machine all the time. I wonder if this has something to do with missing drivers. When I ran sudo apt update && sudo apt upgrade, I got several lines like (this isn't the whole stack trace)

W: Possible missing firmware /lib/firmware/nvidia/gp108/acr/ucode_unload.bin for module nouveau W: Possible missing firmware /lib/firmware/nvidia/gp108/acr/ucode_load.bin for module nouveau W: Possible missing firmware /lib/firmware/nvidia/gp108/acr/unload_bl.bin for module nouveau W: Possible missing firmware /lib/firmware/nvidia/gp108/acr/bl.bin for module nouveau

Is this indicative of the graphics drivers being installed incorrectly? I am hesitant to mess with this because I think in the past, it was always trying to update some graphics driver that crashed the whole machine into some weird state where we have to wipe the drive and do a fresh re-install of the OS.

Should we just follow these instructions? The graphics card is apparently Quadro P400, which is one of the supported ones according to the list of supported devices.

Or just swap donatella and rossa monitors and defer the problem for later?

 Quote: yes, I rebooted yesterday to fix the 'steaking white lines' problem in the video/display
15452   Mon Jul 6 00:37:28 2020 gautamUpdateComputersrossa: lib symlink

This is strange - I was definitely able to launch medm when I was working on this machine remotely on Friday. But now, there does seem to be a problem with this shared library being missing.

First of all, I installed mlocate to find where the shared library files are installed. Then I made the symlink, and now sitemap seems to work again.

Weirdly, my changes to /etc/resolv.conf got overwritten somehow. Was this machine rebooted? Uptime suggests it's only been running for ~6 hours at the time of writing of this elog.

sudo apt install mlocate sudo updatedb sudo ln -s /usr/lib/x86_64-linux-gnu/libreadline.so.7 /usr/lib/x86_64-linux-gnu/libreadline.so.6
 Quote: when I try 'sitemap' on rossa I get: medm: error while loading shared libraries: libreadline.so.6: cannot open shared object file: No such file or directory
15454   Mon Jul 6 12:43:02 2020 ranaUpdateComputersrossa: lib symlink

yes, I rebooted yesterday to fix the 'steaking white lines' problem in the video/display

maybe we're supposed to edit something besides resolv.conf since that gets over-written on boot for some linux OS

15469   Sat Jul 11 00:10:22 2020 gautamUpdateComputersrossa: more developmental work

After some consultation with Erik von Reis at LHO, this workstation is progressing towards being usable for most commissioning tasks. DTT, awggui, foton, and MEDM are all now working well. The main limitation now comes from the fact that many of our python scripts are written for python2, and rossa doesn't have many dependencies installed for python2. I see no reason to build these dependencies on rossa for python2, we should not have to work with an unsupported language. But at the same time, I don't want to completely wipe all our python2 scripts, and make them python3, because this would involve a lot of tedious testing that I'm not prepared to undertake at the moment (the problem is compounded by the fact that pianosa does not have many dependencies installed for python3).

So what I have done in the interim is make python3 versions of the most important scripts I need to get the PRFPMI locking working - they are in the scripts directory and have the same names as their python2 counterparts, but have a 3 appended to their names. So when working on rossa, these are the scripts that are called. Eventually, after a lot more testing, we can depracate the old scripts. Currently, where applicable, the MEDM screens allow for either the python2 or python3 version of the script to be called.

Please, for the time being, do not try and install any new packages on rossa unless you are prepared to debug any problems caused and return the machine to a workable state. If you find some issue with a missing package on rossa, (i) make a note of it on the elog, and (ii) if possible, set up your own conda environment for testing and install dependencies to that environment only.

15473   Mon Jul 13 11:33:18 2020 ranaUpdateComputersrossa: more developmental work

I too, would prefer py3 for everything, but aren't all the cdsutils / gaurdian things still python2?

Is it possible to just make a python2 conda environment on rossa? I would guess that its simple and won't interfere with the regular operation of that machine.

15475   Mon Jul 13 12:37:05 2020 gautamUpdateComputersrossa: more developmental work

In fact, all these utilities are now available in python3. There may be some bugs (e.g. this), but I've checked basic functionality and things look usable enough for development to proceed. While we can have a python2 env on rossa, I think it's unnecessary.

 Quote: I too, would prefer py3 for everything, but aren't all the cdsutils / gaurdian things still python2?
15460   Wed Jul 8 22:50:33 2020 gautamUpdateComputersrossa: more symlinks

I wanted to try using rossa as my locking workstation today. However, a few problems became quickly evident. Basically, any of our scripts that rely on the cdsutils package (there are MANY) will not work on rossa, because of some library error. This machine is running Debian 10, while the cdsutils package is being loaded from a pre-compiled install on the shared drive, so perhaps this isn't surprising?

Digging a little more, I found that actually, a version of cdsutils that actually works with python3 is actually shipped with the standard cds-workstation meta-package. This is great news, and we should try and use this where possible I guess. Deferring further debugging for daytime work.

Anyway, I added a symlink: sudo ln -s /usr/lib/x86_64-linux-gnu/libncurses.so.6 /usr/lib/x86_64-linux-gnu/libncurses.so.5, and installed wmctrl using sudo apt install wmctrl

15451   Sun Jul 5 18:39:57 2020 ranaUpdateComputersrossa: printer

I did

sudo usermod -a -G lpadmin controls

and then was able to add Grazia to the list of printers for Rossa by following the instructions on the 40m Wiki.

I installed color syntax highlighting on Rossa using the internet (https://superuser.com/questions/71588/how-to-syntax-highlight-via-less). Now if you do 'less genius_code.py', it will be highlighting the python syntax.

when I try 'sitemap' on rossa I get:

medm: error while loading shared libraries: libreadline.so.6: cannot open shared object file: No such file or directory

15455   Mon Jul 6 12:51:41 2020 gautamUpdateComputersrossa: resolvconf installed

Indeed, this is now fixed by following instructions from here. I rebooted rossa at ~1250 PDT and confirmed that resolv.conf didn't get overwritten. The resolv.conf file also now has the following useful lines at the head:

~>cat /etc/resolv.conf # Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8) #     DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
 Quote: yes, I rebooted yesterday to fix the 'steaking white lines' problem in the video/display maybe we're supposed to edit something besides resolv.conf since that gets over-written on boot for some linux OS
13044   Mon Jun 5 21:53:55 2017 ranaUpdateComputersrossa: ubuntu 16.04

With the network config, mounting, and symlinks setup, rossa is able to be used as a workstation for dataviewer and MEDM. For DTT, no luck since there is so far no lscsoft support past the Ubuntu14 stage.

6205   Tue Jan 17 03:10:27 2012 kiwamuConfigurationIOOrotated lambda/2 plate

I have slightly rotated the lambda/2 plate, which is used for attenuating the REFL beam's power on the AS table

because the plate had been at an unusual angle for investigation of the glitches since last Thursday.

It means the laser power going to the coating thermal noise setup has also changed. Just keep it in mind.

 Quote from #6198 So today we set up the Jenny RC temperature setup to lock the LWE NPRO to the RC and then set up the beat note with the IFO REFL beam on the AS table. By using the 2 laser beat, we are avoiding the VCO phase noise issue which used to limit the PSL frequency noise at ~0.01 Hz/rHz. To do this we have reworked some of the optics on the PSL and AS tables, but I think its been done without disturbing the beams for the regular locking. Beat note has been found, but the NPRO has still not been locked to the RC - next we setup the lockin amp, dither the PZT, and then use the New Focus lock box to lock it to the RC.

7990   Mon Feb 4 10:45:51 2013 JamieSummaryGeneralrough analysis of aligned PRM-PR2 mode scan

Here's a sort of rough analysis of the aligned PRM-PR2 cavity mode scan.

On Friday we took some mode scan measurements of the PRM-PR2 cavity by pushing PRM (C1:SUS-PRM_LSC_EXT) with a 0.01 Hz, 300 count sine wave.  We looked at the transmitted power on the POP DC PD and the error signal on REFL11_I.

Below is a detail of the scan, chosen because the actuation was in its linear region and there were three relatively ok looking transmission peaks with nice PDH response curves:

The vertical green lines on the bottom plot indicate the rough averaged separation of the 11 MHz side-band resonances from the carrier, at +- 0.0275 s.  If we take this for our calibration, we get roughly 400 MHz / second.

The three peaks in top plot have an average FWHM of 0.00381 s.  Given the calibration above, the average FWHM = ~1.52 MHz.

If we assume a cavity length of 1.91 m, FSR = 78.5 MHz.

Putting this together we get a finesse = ~51.6.

Analysis of misaligned mode scans to follow.

7991   Mon Feb 4 11:10:59 2013 KojiSummaryGeneralrough analysis of aligned PRM-PR2 mode scan

The expected finesse is 100ish. How much can we beleive the measured number of 50?
From the number we need to assume PR2 has ~93% reflectivity.
This does not agree with my feeling that the cavity is overcoupled.
Another way is to reduce the reflectivity of the PRM but that is also unlikely from the data sheet.

The scan passed the peak in 4ms according to the fitting.
How do the analog and digital antialiasing filters affect this number?

7994   Mon Feb 4 19:33:19 2013 yutaSummaryGeneralrough analysis of aligned PRM-PR2 mode scan

[Jenne, Yuta]

We redid PRM-PR2 cavity scan because last one (elog #7990) was taken with the sampling frequency of 2 KHz. We have also done TMS measurement.

Method:
1. Align input TTs and PRM to align PRM-PR2 cavity.
2. Sweep cavity length using C1:SUS-PRM_LSC_EXC.
3. Get data using Jamie's getdata and fitted peaks using /users/jrollins/modescan/prc-pr2_aligned/run.py
4. Calculated cavity parameters

Results:
Below is the figure containing peaks used to do the calculation.

From 11 MHz sidebands, calibration factor is 462 +/- 22 MHz/sec (supposing linear scan around peaks)
FWHM is 1.45 +/- 0.03 MHz.
TMS is 2.64 +/- 0.05 MHz.
Error bars are statistical errors of the average over 3 TEM00 peaks.

If we believe cavity length L to be 1.91 m, FSR is 78.5 MHz.
So, Finesse will be 54 +/- 1 and cavity g-factor will be 0.9944 +/- 0.0002. 0.9889 +/- 0.0004   (Edited by YM; see elog #8056)
If we believe RoC of PRM is exactly +122.1 m, measured g-factor insists RoC of PR2 to be -187 +/- 4.
If we believe RoC of PR2 is exactly -600 m, measured g-factor insists RoC of PRM to be 218 +/- 6.

Discussion:
1. Finesse is too small (expected to be ~100). This time, data was taken 16 KHz. Cut-off frequency of the digital antialiasing filter is ~ 5 kHz (see /opt/rtcds/rtscore/release/src/fe/controller.c). FWHM is about 0.003 sec, so it should not effect much according to my simulation.

2. I don't know why FWHM measurement from the last one is similar to this one. The last one was taken 2 KHz, this means anti-aliasing filter of 600 Hz. This should double FWHM.

3. Oscilloscope measurement may clear anti-aliasing suspicion.

7997   Tue Feb 5 02:04:44 2013 yutaSummaryGeneralrough analysis of aligned PRM-PR2 mode scan

I redid PRM-PR2 cavity scan using oscilloscope to avoid anti-aliasing effect.
Measured Finesse was 104 +/- 1.

Method:
1. Splitted POP DC output into three and plugged two into oscilloscope TDS 3034B. Ch1 and Ch2 was set to 1 V/div and 20 mV/div respectively to take the whole signal and higer resolution one at the same time (Koji's suggestion). Sampling frequency was 50 kHz. Sweeping time through FWHM was about 0.001 sec, which is slow enough.
2. Took mode scan data from the oscilloscope via network.

Preliminary results:
Below is the plot of the data for one TEM00 peak.

The data was taken twice.
Measured FWHM was 0.764 MHz and 0.751 MHz. By taking the average, FWHM = 0.757 +/- 0.005 MHz.
This gives you Finesse = 104 +/- 1, which is OK compared with the expectation.

What I need:
I need better oscilloscope so that we can take longer data (~1 sec) with higher resolution (~0.004 V/count, ~50kHz).
TDS 3034B can take data only for 10 ksamples, one channel by one!  I prefer Yokogawa DL750 or later.

7998   Tue Feb 5 03:16:51 2013 KojiSummaryGeneralrough analysis of aligned PRM-PR2 mode scan

0.764 and 0.751 do not give us the stdev of 0.005.

I have never seen any Yokogawa in vicinity.

 Quote: Measured FWHM was 0.764 MHz and 0.751 MHz. By taking the average, FWHM = 0.757 +/- 0.005 MHz.  This gives you Finesse = 104 +/- 1, which is OK compared with the expectation. What I need  I need better oscilloscope so that we can take longer data (~1 sec) with higher resolution (~0.004 V/count, ~50kHz).  TDS 3034B can take data only for 10 ksamples, one channel by one!  I prefer Yokogawa DL750 or later.

8000   Tue Feb 5 10:09:08 2013 yutaSummaryGeneralrough analysis of aligned PRM-PR2 mode scan

stdev of [0.764, 0.751] is 0.007, but what we need is the error of the averaged number. Statistical error of the averaged number is stdev/sqrt(n).

 Quote: 0.764 and 0.751 do not give us the stdev of 0.005.

8002   Tue Feb 5 11:30:19 2013 KojiSummaryGeneralrough analysis of aligned PRM-PR2 mode scan

Makes sense. I mixed up n and n-1

Probability function: X = (x1 + x2 + ... + xn)/n, where xi = xavg +/- dx

Xavg = xavg*n/n = xavg

dXavg^2 = n*dx^2/n^2
=> dXavg = dx/sqrt(n)

Xavg +/- dXavg = xavg +/- dx/sqrt(n)

8074   Wed Feb 13 01:26:08 2013 yutaSummaryGeneralrough analysis of aligned PRM-PR2 mode scan

Koji was correct.

When you estimate the variance of the population, you have to use unbiased variance (not sample variance). So, the estimate to dx in the equations Koji wrote is

dx = sqrt(sum(xi-xavg)/(n-1))
= stdev*sqrt(n/(n-1))

It is interesting because when n=2, statistical error of the averaged value will be the same as the standard deviation.

dXavg = dx/sqrt(n) = stdev/sqrt(n-1)

In most cases, I think you don't need 10 % precision for statistical error estimation (you should better do correlation analysis if you want to go further). You can simply use dx = stdev if n is sufficiently large (n > 6 from plot below).

 Quote: Makes sense. I mixed up n and n-1 Probability function: X = (x1 + x2 + ... + xn)/n, where xi = xavg +/- dx Xavg = xavg*n/n = xavg dXavg^2 = n*dx^2/n^2 => dXavg = dx/sqrt(n) Xavg +/- dXavg = xavg +/- dx/sqrt(n)

11857   Mon Dec 7 11:11:25 2015 yutaroSummaryLSCround trip loss of X arm

On the day before yesterday and in this morning, I measured loss map of ETMX. I reported the method I used to change the beam spot on ETMX below.

Round trip loss was measured for 5 x 5 points. The result is below.

(unit: ppm)

455.4 +/- 21.1       437.1 +/- 21.8       482.3 +/- 21.8       461.6 +/- 22.5       507.9 +/- 20.1
448.4 +/- 20.7       457.3 +/- 21.2       495.6 +/- 20.2       483.1 +/- 20.8       472.2 +/- 19.8
436.9 +/- 19.3       444.6 +/- 19.7       483.0 +/- 19.5       474.9 +/- 20.9       498.3 +/- 18.7
454.4 +/- 18.7       474.4 +/- 20.6       487.7 +/- 21.4       482.6 +/- 20.7       487.0 +/- 19.9
443.7 +/- 18.6       469.9 +/- 20.2       482.8 +/- 18.7       480.9 +/- 19.5       486.1 +/- 19.2

The correspondence between the loss shown above and the beam spot on ETMX is shown in the attached figure. In the figure, "up" and "right" indicate direction of shift of the beam spot when you watch it via the camera (ex. 455.4 ppm corresponds to the highest and rightest point in the view via the camera).

This result is consistent withe previous result of 561.19 +/- 14.57 ppm ericq got with ASDC and reported in elog 10248 if the discussion I reported in 11819 is taken into account. Elog 11819 says in short that the strange behavior of ASDC could give us 60-70 ppm error.

The reason why the error is larger than that of the measurement for ETMY is that the noise of POX is larger than that of POY. But I am not sure to what extent the statistical error needs to be reduced.

How I shifted the beam spot on ETMX:

Basically, the method was same as one used for Y arm. Different point is: for Y arm we have two steering mirrors TT1&2, but for X arm we have only one steering mirror BS. Then in order to shift incident beam so that the beam spot on ITMX does not change, I ran the dithering of X arm as well as that of Y arm and added offsets to both dither loops that caused same amount of shift on ETMX and ETMX. Thanks to the symmetry between X arm and Y arm, the dithering of Y arm ensured that the beam spot on ITMX was unchanged as well as that of ITMY. The idea of this method is schematically shown in Attachment 2.

The calibration of how much the beam spot shifted is based on the results of elog 11846 . The offset was [-15,-7.5,0,7.5,15]x[-5,-2.5,0,2.5,5] for pitch and yaw, respectively.

Attachment 1: image1-2.JPG
Attachment 2: symmetry.png
11810   Wed Nov 25 16:40:32 2015 yutaroUpdateLSCround trip loss of Y arm

I measured round trip loss of Y arm. The alignment of relevant mirrors was set ideal with dithering (no offset).

Summary:

round trip loss of Y arm: 166.2 +/- 9.3 ppm

(In the error, only statistic error is included.)

How I measured it:

I compared the power of light reflected by Y arm (measured at AS) when the arm was locked (P_L) and when ETMY was misaligned (P_M). P_L and P_M can be described as

$P_M=P_0(1-T_\mathrm{ITM})$

$P_L=P_0\left[1-(1-\alpha)\frac{4T_\mathrm{ITM}}{T_\mathrm{tot}^2}T_\mathrm{loss}\right]$.

The reason why P_L takes this form is: (1-alpha)*4T_ITM/(T_tot)^2 is intracavity power and then product of intracavity power and loss describes the power of light that is not reflected back. Here, alpha is power ratio of light that does not resonate in the arm (power of mismatched mode and modulated sideband), and T_tot is T_ITM+T_loss. Transmissivity of ETM is included in T_loss. I assumed alpha = 7%(mode mismatch) + 2 % (modulation) (elog 11745)

After some calculation we get

$1-P_L/P_M\simeq \frac{4(1-\alpha) T_\mathrm{loss}}{T_\mathrm{ITM}}-T_\mathrm{ITM}$.

Here, higher order terms of T_ITM and (T_loss/T_ITM) are ignored. Then we get

$(1-\alpha) T_\mathrm{loss}=\frac{T_\mathrm{ITM}}{4}(1-P_L/P_M+T_\mathrm{ITM})$.

Using this formula, I calculated T_loss. P_L and P_M were measured 100 times (each measurement consisted of 1.5 sec ave.) each and I took average of them. T_ETM =13.7 ppm is used.

Discussion:

-- This value is not so different from the value ericq reported in July (elog 10248).

-- This method of measuring arm loss is NOT sensitive to T_ITM.  In contrast, the method in which loss is obtained from finesse (for example, elog 11740) is sensitive to T_ITM.

In the method I'm now reporting,

$\Delta T_\mathrm{loss}/T_\mathrm{loss}\simeq\Delta T_\mathrm{ITM}/T_\mathrm{ITM}$,

but in the method with finesse,

$\Delta T_\mathrm{loss}\simeq\Delta T_\mathrm{ITM}$.

In the latter case, if relative error of T_ITM is 10%, error of T_loss would be 1000 ppm.

So it would be better to use power of reflected light when you want to measure arm loss.

11816   Wed Nov 25 23:34:52 2015 yutaroUpdateLSCround trip loss of Y arm

[yutaro, Koji]

Due to the strange behavior (elog 11815) of ASDC level, we checked if it is possible to use POYDC instead of ASDC to measure the power of reflected light of YARM. Attached below is the spectrum of them when the arm is locked. This spectrum shows that it is not bad to use POYDC, in terms of noise. The spectrum of them when ETMY is misaligned looked similar.

So I am going to use POYDC instead of ASDC to measure arm loss of YARM.

Ed by KA:
The spectra of POYDC and ASDC were measured. We foudn that they have coherence at around 1Hz (good).
It told us that POYDC is about 1/50 smaller than ASDC. Therefore in the attached plot, POYDC x50 is shown.
That's the meaning of the vertical axis unit "ASDC".

Attachment 1: 14.png
11818   Fri Nov 27 03:38:23 2015 yutaroSummaryLSCround trip loss of Y arm

Tonight I measured "loss map" of ETMY. The method to calculate round trip loss is same as written in elog 11810, except that I used POYDC instead of ASDC this time.

How I changed beam spot on ETMY is: elog 11779.

I measured round trip loss for 5 x 5 points. The result is below.

(unit: ppm)

494.9 +/- 7.6       356.8 +/- 6.0       253.9 +/- 7.9       250.3 +/- 8.2       290.6 +/- 5.1
215.7 +/- 4.8       225.6 +/- 5.7       235.1 +/- 7.0       284.4 +/- 5.4       294.7 +/- 4.5
205.2 +/- 6.0       227.9 +/- 5.8       229.4 +/- 7.2       280.5 +/- 6.3       320.9 +/- 4.3
227.9 +/- 5.7       230.5 +/- 5.5       262.1 +/- 5.9       315.3 +/- 4.7       346.8 +/- 4.2
239.7 +/- 4.5       260.7 +/- 5.3       281.2 +/- 5.8       333.7 +/- 5.0       373.8 +/- 4.9

The correspondence between the loss shown above and the beam spot on ETMY is shown in the following figure. In the figure, "downward" and "left" indicate direction of shift of the beam spot when you watch it via the camera (ex. 494.9 ppm corresponds to the lowest and rightest point).

Edited below on 28th Nov.

To shift the beam spot on ETMY, I added offset in YARM dither loop. The offset was [-30,-15,0,15,30]x[-10,-5,0,5,10] for pitch and yaw, respectively.  How I calibrated the beam spot is basically based on elog 11779, but I multiplied 5.3922 for vertical direction and 4.6205 for horizontal direction which I had obtained by caliblation of oplev (elog 11785).

Edited above on 28 th Nov.

I will report the detail later.

11819   Fri Nov 27 22:20:24 2015 yutaroUpdateLSCround trip loss of Y arm

Here, I upload data I took last night, including the power of reflected power (locked/misaligned) and transmitted power for each point (attachement 1).

And I would like to write about possible reason why the loss I measured with POYDC and the loss I measured with ASDC are different by about 60 - 70 ppm (elog 11810 and 11818). The conclusion I have reached is:

It could be due to the strange bahavior of ASDC level.

This difference corresponds to the error of ~2% in the value of P_L/P_M. As reported in elog 11815, ASDC level changes when angle of the light reflected by ITMY changes, and 2% change of ASDC level corresponds to 10 urad change of the angle of the light according to my rough estimation with the figure shown in elog 11815 and attachment 2. This means that 2% error in P_L/P_M could occur if the angle of the light incident to YARM and that of resonant light in YARM differ by 10 urad. Since the waist width $w_0$ of the beam is ~3 mm, with the 10 urad difference, the ratio of the power of TEM10 mode is $(10\,\mu \mathrm{rad}/ \theta_0)^2\sim0.01$, where $\theta_0=\lambda/\pi w_0$. This value is reasonable; in elog 11743 Gautam reported that the ratio of the power of TEM10 was ~ 0.03, from the result of cavity scan. Therefore it is possible that the angle of the light incident to YARM and that of resonant light in YARM differ by 10 urad and this difference causes the error of ~2% in P_L/P_M, which could exlain the 60 - 70 ppm difference.

Attachment 1: log.txt.zip
Attachment 2: 17.png
375   Thu Mar 13 12:11:58 2008 aivanovUpdateComputer Scripts / Programsrouting 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
380   Fri Mar 14 15:06:24 2008 robUpdateComputer Scripts / Programsrouting 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.
11161   Mon Mar 23 19:30:36 2015 ranaUpdateComputer Scripts / Programsrsync frames to LDAS cluster

The rsync job to sync our frames over to the cluster has been on a 20 MB/s BW limit for awhile now.

Dan Kozak has now set up a cronjob to do this at 10 min after the hour, every hour. Let's see how this goes.

You can find the script and its logfile name by doing 'crontab -l' on nodus.

11288   Wed May 13 09:17:28 2015 ranaUpdateComputer Scripts / Programsrsync frames to LDAS cluster

Still seems to be running without causing FB issues. One thought is that we could look through the FB status channel trends and see if there is some excess of FB problems at 10 min after the hour to see if its causing problems.

I also looked into our minute trend situation. Looks like the files are comrpessed and have checksum enabled. The size changes sometimes, but its roughly 35 MB per hour. So 840 MB per day.

According to the wiper.pl script, its trying to keep the minute-trend directory to below some fixed fraction of the total /frames disk. The comment in the scripts says 0.005%,

but I'm dubious since that's only 13TB*5e-5 = 600 MB, and that would only keep us for a day. Maybe the comment should read 0.5% instead...

 Quote: The rsync job to sync our frames over to the cluster has been on a 20 MB/s BW limit for awhile now. Dan Kozak has now set up a cronjob to do this at 10 min after the hour, every hour. Let's see how this goes. You can find the script and its logfile name by doing 'crontab -l' on nodus.

11299   Mon May 18 14:22:05 2015 ericqUpdateComputer Scripts / Programsrsync frames to LDAS cluster
 Quote: Still seems to be running without causing FB issues.

I'm not so sure. I just was experiencing some severe network latency / EPICS channel freezes that was alleviated by killing the rsync job on nodus. It started a few minutes after ten past the hour, when the rysnc job started.

Unrelated to this, for some odd reason, there is some weirdness going on with ssh'ing to martian machines from the control room computers. I.e. on pianosa, ssh nodus fails with a failure to resolve hostaname message, but ssh nodus.martian succeeds.

4247   Thu Feb 3 17:25:03 2011 josephbUpdateComputersrsync script was not really backing up /cvs/cds

So today, after an "rm" error while working with the autoburt.pl script and burt restores in general, I asked Dan Kozak how to actually look at the backup data.  He said there's no way to actually look at it at the moment.  You can reverse the rsync command or ask him to grab the data/file if you know what you want.  However, in the course of this, we realized there was no /cvs/cds data backup.

Turns out, the rsync command line in the script had a "-n" option.  This means do a dry run.  Everything *but* the actual final copying.

I have removed the -n from the script and started it on nodus, so we're backing up as of 5:22pm today.

I'm thinking we should have a better way of viewing the backup data, so I may ask Dan and Stewart about a better setup where we can login and actually look at the backed up files.

In addition, tomorrow I'm planning to add cron jobs which will put changes to files in the /chans and /scripts directories into the SVN on a daily basis, since the backup procedure doesn't really provide a history for those, just a 1 day back backup.

6807   Tue Jun 12 17:46:09 2012 JenneUpdateComputersrtcds: command found

Quote:

 Quote: We can't compile any changes to the LSC or the GCV models since Jamie's new script / program isn't found.  I don't know where it is (I can't find it either), so I can't do the compiling by hand, or point explicitly to the script.  The old way of compiling models in the wiki is obsolete, and didn't work :(

Sorry about that.  I had modified the path environment that pointed to the rtcds util.  The rtcds util is now in /opt/rtcds/caltech/c1/scripts/rtcds, which is in the path.  Starting a new shell should make it available again.

Added TRX and TRY and POY11_I_ERR and POX11_I_ERR to the c1lsc.mdl using a new-style DAQ Channels block, recompiled, installed, started the model, all good.  Restarted the daqd on the framebuilder, and everything is green.  I can go back and get recorded data using dataviewer (for the last few minutes since I started fb), so it all looks good.

Note on the new DAQ Channels block:  Put the text block (from CDS_PARTS) at the same level as the channel you want to save, and name it exactly as it is in the model.  The code-generator will add the _DQ for you.  i.e. if you define a channel "TRY_OUT_DQ" in the lsc model, you'll end up with a channel "C1:LSC-TRY_OUT_DQ_DQ".

We can't compile any changes to the LSC or the GCV models since Jamie's new script / program isn't found.  I don't know where it is (I can't find it either), so I can't do the compiling by hand, or point explicitly to the script.  The old way of compiling models in the wiki is obsolete, and didn't work :(

This means we can't (a) record TRY or (b) add the Q quadrature of the beat PD to the real time system tonight.

We're going to try just using Yuta's pynds script to capture data in real time, so we can keep working for tonight.

 Quote: We can't compile any changes to the LSC or the GCV models since Jamie's new script / program isn't found.  I don't know where it is (I can't find it either), so I can't do the compiling by hand, or point explicitly to the script.  The old way of compiling models in the wiki is obsolete, and didn't work :(

Sorry about that.  I had modified the path environment that pointed to the rtcds util.  The rtcds util is now in /opt/rtcds/caltech/c1/scripts/rtcds, which is in the path.  Starting a new shell should make it available again.

6270   Fri Feb 10 15:46:59 2012 steveUpdateSUSruby wire standoff

Finally I found a company who can do Koji's improved  -hard to make-  specification on ruby or sapphire wire standoff.

NOT POLISHED excimer laser cut, wire groove radius R 0.0005" + - 0.0002"

\$250 ea at 50 pieces of order

13039   Mon Jun 5 10:30:45 2017 SteveUpdateSUSruby wire standoff pictures

Atm 1 & 5, showing the ruby R ~10 mm as it is seated on Al SOS test mass

Atm. 2, 3 & 4  chipped long edges with SOS sus wire OD 43 micron as  calibration

 Quote: Ruby wire standoff received from China. I looked one of them with our small USB camera.  They did a good job. The  long edges of the prism are chipped. The v-groove cutter must avoid them. Pictures will follow.

Attachment 1: A087_R.png.bmp
Attachment 2: A097_chipped_edges.png.bmp
Attachment 3: A099_cal_wire.png.bmp
Attachment 4: A101_cal_wire_43_micron.png.bmp
Attachment 5: Al_SOS_R39mm.jpg
13123   Mon Jul 17 16:22:01 2017 SteveUpdateSUSruby wire standoff pictures

Bluebean Optical Tech Limited of Shanghai delivered 50 pieces red ruby prisms with radius.  The first prism pictures were taken at June 5

and it was retaken again as BB#1 later

More samples were selected randomly as one from each bag of 5 and labeled as BB#2.......6

The R10 mm radius can be seen agains the  ruler edge.  The v-groove edge was labeled with blue marker and pictures were taken

from both side of this ridge. The top view is shown as the wire laying across on it.

SOS sus wire of 43 micron OD used as calibration as it was placed close to the side that it was focused on.

The V-groove ridge surface quality was evaluated based on as scale of 1 – 10 with 10 being the most positive.

 BB# Edge quality score 1 4 2 8 3 3 4 9.5 5 2 6 9

Remaining thing to examin, take picture of the contacting ridge to SOS from the side.

Attachment 1: contacting_ridge.bmp
Attachment 2: contacting_ridge.png
12117   Sun May 15 19:48:08 2016 SteveUpdateVACrun out of N2

3-4 hrs ago we run out of nitrogen. We are back to Vacuum Normal

Attachment 1: noN2.png
13903   Thu May 31 15:48:16 2018 KiraUpdatePEMrunning PID script with seismometer

I have attached the result of running the PID script on the seismometer with the can on. The daily fluctuations are no more than 0.07 degrees off from the setpoint of 39 degrees. Not really sure what happened in the past day to cause the strange behavior. It seems to have returned back to normal today.

Attachment 1: can-on-pid.png
280   Mon Jan 28 15:11:38 2008 robHowToDMFrunning compiled matlab DMF tools

I compiled Rana's seisBLRMS monitor, and it's now running on mafalda. To start your own DMF tools, here is a procedure:

1) build your tool in mDV, get it working the way you'd like.
2) Make a new directory /cvs/cds/caltech/apps/DMF/compiled_matlab/{your_new_directory} and copy the *.m file there.
3) Make the *.m in your new directory into a function with no args (just add a function line at the top)
4) compile it (from within a fully mDV-configured matlab) with mcc -m -R -nojvm {yourfile}.m at the matlab command line.
5) add a line corresponding to your new tool to the script /cvs/cds/caltech/apps/DMF/scripts/start_all
6) Run the start_all script referenced in part (5).

NB: Steps (4) and (6) must be carried out on mafalda.
13978   Mon Jun 18 10:34:45 2018 johannesUpdateComputer Scripts / Programsrunning comsol job on optimus

I'm running a comsol job on optimus in a tmux session named cryocavs. Should be done in less than 24 hours, judging by past durations.

11410   Tue Jul 14 13:55:28 2015 jamieUpdateCDSrunning test on daqd, please leave undisturbed

## I'm running a test with daqd right now, so please do not disturb for the moment.

I'm temporarily writing frames into a tempfs, which is a filesystem that exists purely in memory.  There should be ZERO IO contention for this filesystem, so if the daqd failures are due to IO then all problems should disappear.  If they don't, then we're dealing with some other problem.

There will be no data saved during this period.

11413   Tue Jul 14 17:06:00 2015 jamieUpdateCDSrunning test on daqd, please leave undisturbed

I have reverted daqd to the previous configuration, so that it's writing frames to disk.  It's still showing instability.

6201   Sun Jan 15 12:18:00 2012 DenUpdateAdaptive Filteringrunning time

In order to figure out what downsampling ratio we can take, we need to determine the running time of the fxlms_filter() function. If the filter length is equal to 5000, downsampling ratio is equal to 1, number of witness channels is 1 then with ordinary compilation without speed optimization one call runs for 0.054 ms (milli seconds). The test was done on the 3 GHz Intel processor. With speed optimization flags the situation is better

-O1 0.014 ms, -O3 0.012 ms

However, Alex said that speed optimization is not supported at RCG because it produce unstable execution time for some reason. However, by default the kernel should optimize for size -Os. With this flag the running time is also 0.012 ms. We should check if the front-end machine compilers indeed use -Os flag during the compilation and also play with speed optimization flags. Flags -O3 and -Os together might also give some speed improvement.

But for now we have time value = 0.012 ms as running time for 5000 coefficient filter, 1 witness channel and downsample ratio = 1. Now, we need to check how this time is scaled if we change the parameters.

5000 cofficients - 0.012 ms

10000 coefficients - 0.024 ms

15000 coefficients - 0.036 ms

20000 coefficients - 0.048 ms

We can see that filter length scaling is linear. Now we check downsampling ratio

ratio=1 - 0.048 ms

ratio=2 - 0.024 ms

ratio=4 - 0.012 ms

Running time on the dependance of downsample ratio is also linear as well as on the dependence of the number of witness channels and degrees of freedom.

If we want to filter 8 DOF with approximately 10 witness channels for each DOF, then 5000 length filter will make 1 cycle for ~1 ms, that is good enough to make the downsample ratio equal to 4.

Things get a little bit complicated when the code is called for the first time. Some time is taken to initialize variables and check input data. As a result the running time of the first cycle is ~0.1 ms for 1 DOF that is ~10 times more then running time of an ordinary cycle. This effect takes place at this moment when one presses reset button in the c1oaf model - the filter becomes suspended for a while. To solve this problem the initialization should be divided by several (~10) parts.

12608   Wed Nov 9 11:40:44 2016 ericqUpdateCDSsafe.snap BURT files now in svn

This is long overdue, but our burt files for SDF now live in the LIGO userapps SVN, as they should.

The canonical files live in places like /opt/rtcds/userapps/release/cds/c1/burtfiles/c1x01_safe.snap and are symlinked to files like /opt/rtcds/caltech/c1/target/c1x01/c1x01epics/burt/safe.snap

2647   Mon Mar 1 08:49:37 2010 steveBureaucracySAFETYsafety audit

The 40m safety audit will be at Wednesday afternoon, March 3

6329   Tue Feb 28 11:20:51 2012 steveUpdateSAFETYsafety audit 2012

Correction list by visiting safety committee, Haick Issaian is not shown:

1,  update laser, crane operator list and post it

2,  check fire extinguishers monthly, date and initials must be on the tags

3,  move drinking water tower so it does not block fire extinguisher

4,  post updated crane doc at cranes

5,  post present phone lists at IFO room phones

6,  emergency laser shutoff at the south end must be mounted without C-clamp

7,  use heavy cable tie to insure position of  mag-fan on cabinet top

a,  safety glasses to be cleaned

b, let the electrical shop fix Rack-AC power to optical tables at the ends

c, measure transmission of  laser safety glasses

d, update  IFO outside door info signs

e, update laser inventory and post it

f,  schedule annual crane inspection and renew maintenance contract

g, PSL enclosure  inner shelf needs a good clean up so it is earthquake safe

Attachment 1: safety12.JPG
6470   Fri Mar 30 09:37:13 2012 steveUpdateSAFETYsafety audit 2012 CORRECTIONS

 Quote: Correction list by visiting safety committee, Haick Issaian is not shown: 1,  update laser, crane operator list and post it 2,  check fire extinguishers monthly, date and initials must be on the tags 3,  move drinking water tower so it does not block fire extinguisher 4,  post updated crane doc at cranes 5,  post present phone lists at IFO room phones 6,  emergency laser shutoff at the south end must be mounted without C-clamp 7,  use heavy cable tie to insure position of  mag-fan on cabinet top   Additional to do list: a,  safety glasses to be cleaned b, let the electrical shop fix Rack-AC power to optical tables at the ends c, measure transmission of  laser safety glasses d, update  IFO outside door info signs e, update laser inventory and post it f,  schedule annual crane inspection and renew maintenance contract g, PSL enclosure  inner shelf needs a good clean up so it is earthquake safe

Completed with the exception of d and g

8240   Wed Mar 6 11:33:09 2013 steveUpdateSAFETYsafety audit 2013

Recommended correction list:

1,  refill- upgrade first aid boxes

2,  maintain 18" ceiling to bookshelf clearance so the ceiling fire sprinklers are not blocked: room 101

3,  label chilled water supply & return valves in IFO room

4,  calibrate bake room hoods annually

5,  update safety sign at fenced storage

40m still to do list:

1,   clean and measure all safety glasses

2,   annual crane inspection is scheduled for 8am March 19, 1013

3,   make PSL encloser shelf earthquake proof

Do you see something that is not safe? Add it to this list please.

Attachment 1: IMG_0010.JPG
9672   Tue Feb 25 16:54:57 2014 steveUpdatesafetysafety audit 2014

We had our annual safety inspection today.  Our SOPs are outdated. The full list of needed correction will be posted tomorrow.

The most useful found was that the ITMX-ISCT ac power is coming  from 1Y1 rack. This should actually go to 1Y2 LSC rack ?

Please test this so we do not create more ground loops.

ELOG V3.1.3-