Jon and I stuck a extender card into the eurocrate at 1X8 earlier today (~5pm PT), to see if the box was getting +24V DC from the Sorensen or not. Upon sticking the card in, the FAIL LEDs on all the VME cards came on. We immediately removed the extender card. Without any intervention from us, after ~1 minute, the FAIL LEDs went off again. Judging by the main volume pressure (Attachment #1) and the Vacuum MEDM screen (Attachment #2), this did not create any issues and the c1vac1 computer is still responsive.

But Steve can perhaps run a check in the AM to confirm that this activity didn't break anything.

Is there a reason why extender cards shouldn't be stuck into eurocrates?

The vacuum and MC are OK

Steve pointed out that some of the vacuum MEDM screen fields were reporting "NO COMM". Koji confirmed that this is a c1vac1 problem, likely the same as reported here and can be fixed using the same procedure.

However, Steve is worried that the interlock won't kick in in case of a vacuum emergency, so we are leaving the PSL shutter closed over the weekend. The problem will be revisited on Monday.

[steve, gautam]

Following the procedure in this elog, we effected a reset of the vacuum slow machines. Usually, I just turn the key on these crates to do a power cycle, but Steve pointed out that for the vacuum machines, we should only push the "reset" button.

While TP1 was spun down, we took the opportunity to replace the TP1 controller with a spare unit the company has sent us for use while our unit is sent to them for maintenance. The procedure was in principle simple (I only list the additional ones, for the various valve closures, see the slow machine reset procedure elog):

• Turn power off using switch on rear.
• Remove 4 connecting cables on the back.
• Switch controllers.
• Reconnect 4 cables on the back panel.
• Turn power back on using switch on rear.

However, we were foiled by a Philips screw on the DB37 connector labelled "MAG BRG", which had all its head worn out. We had to make a cut in this screw using a saw blade, and use a "-" screwdriver to get this troublesome screw out. Steve suspects this is a metric gauge screw, and will request the company to send us a new one, we will replace it when re-installing the maintaiend controller. 

Attachments #1 and #2 show the Vacuum MEDM screen before and after the reboot respectively - evidently, the fields that were reading "NO COMM" now read numbers. Attachment #3 shows the main volume pressure during this work.

This afternoon I started setting up the Supermicro 5017A-EP that will replace c1vac1/2. Following Johannes's procedure in 13681 I installed Debian 8.11 (jessie). There is a more recent stable release, 9.5, now available since the first acromag machine was assembled, but I stuck to version 8 for consistency. We already know that version to work. The setup is sitting on the left side of the electronics bench for now.

[Koji Suresh]

As part of the general lab clean up we removed many unused BNC cables (long and short) from around the SP table.  We removed one very long BNC cable which was connected on one side to an PEM input and not connected on the other side near the 1X2 rack..   There were several cables from an old SURF phase camera project which were still attached to a couple of RF amps on the SP tables and running towards the 1X6 rack. 

We also removed some unused power cables  plugged into a power distribution strip near Megatron.

Today I found 3 power cables in the orange Pomona cable tray, put in so that the cables were damaged and therefore dangerous.

Please think about what you are doing before doing it. Damaging these things because your are in a hurry or frustrated will just waste our time and damage our interferometer.

For reference, we only use the thick blue Pomona racks for power cables. We use the orange and black ones for thinner cables. Pay attention and keep the cables organized.

Cable Rack Selection

[Koji, Steve, Suresh, Kiwamu]

The following video cables have been newly laid down :

  - MC1F/MC3F (65 ft.)

  - PMCR (100 ft.)

  - PSL spare (100 ft.)

  - PSL1  (100 ft.)

  - PSL2  (100 ft.)

Cable numbered #53 from Accelerometer 4 to 1X7 / DAQ input c26 was squased while removing network card from Sun Fire x4600 today.

This cable has to be tested.

How NOT to:

The janitor can not clean in areas like this. He may only steps on these cables accidentally as he dust wiping our chambers.

 Sorry for the mess. I fixed it.

This is still happening. Specifically: on all of the control room computers, calls to caget display the result immediately, but then hang for five seconds (consistently five). We had also seen a situation where calls hang indefinitely on ottavia/pianosa, but a reboot "fixes" this.

Some observations:

• Front end machines and the FB have proper caget/caput response times.
• Control room machines have some odd ping behavior when targeting frontends/FB; namely the ping times themselves are ok, but each ping line takes quite some time to show up, which made us think that there is odd network routing issue happening with some network switch. 
• Front ends and FB get epics from /opt/rtapps, whereas control room machines get epics from /ligo/apps, which has different contents. (Is this for Gentoo vs. Ubuntu? I don't really get why this is the case...). This means different environment setting scripts to be called, so maybe the control room machines are misconfigured in some way for the new name server?

I poked around the network settings on all of these machines, but everything seemed reasonable. Nothing was changed. Rossa and Pianosa have their network settings done through some Ubuntu GUI, but I don't know where the settings are written. I had expected their settings to be in /etc/network/interfaces; maybe we should change this to be consistent with other machines, and easier to administrate via the terminal. 

Despite all this, ezcaread is fine.

I think I've fixed the caget/caput issue. Rana's observation that pinging the IP directly was faster than pinging the hostname set me on a path of googling which informed making the following changes to the DNS setup on chiara (specifically, informed by this thread: http://www.dslreports.com/forum/r11836974-BIND-slow-to-reply-over-LAN-Solved)

/etc/bind/named.conf.local has these lines:

The first zone command links hostnames like c1lsc to an IP like 192.168.113.62, but apparently in the second, we need to do the inverse. So, for each line in martian.db like

c1lsc           A       192.168.113.62

I added a line in rev.113.168.192.in-addr.arpa like so:

62 IN PTR c1lsc.martian

This seems kind of silly, but now if you do the host command from a workstation, it can find the hostname associated with an IP. 

[At this point, note that we have a bunch of duplicate entries in https://wiki-40m.ligo.caltech.edu/Martian_Host_Table  with these scipe## hostnames. What are these for?]

From calculation, phase fluctuation of reflected beam from length stabilized arm is not disturbing MI lock.

Easy calculation:
  The phase PD at AS port sense is

phi = phi_x - phi_y = 2*l_MICH*omega/c + (phi_X - phi_Y)

  where l_MICH is the Michelson differential length change, omega is laser frequency, phi_X and phi_Y are phase of arm reflected beam. From very complicated calculation,

phi_X ~ F/2 * Phi_X

  at near resonance. Where F is arm finesse, Phi_X is the round trip phase change in X arm. So,

phi = 2*l_MICH*omega/c + F/2 * 2*L_DARM*omega/c

  Our ALS stabilizes arm length in ~ 70 pm(see elogs #6835,  #6858). Finesse for IR is ~450. Considering l_MICH is ~ 1 um, MICH signal at AS port should be larger than stabilized DARM signal by an order of magnitude.

Length sensing matrix of FPMI:
  Calculated length sensing matrix of 40m FPMI is below. Here, I'm just considering 11 MHz modulation. I assumed input power to be 1 W, modulation index 0.1i, Schnupp asymmetry 26.6 mm. PRM/SRM transmissivity is not taken into account.

[W/m]     DARM      CARM      MICH
REFL_I    0         1.69e8    0
REFL_Q    7.09e1    0        -3.61e3
AS_I      0         0         0
AS_Q      1.04e6    0         3.61e3

  Maybe we should use REFL_Q as MICH signal, but since IQ separation is not perfect, we see too much CARM. I tried to lock MI with REFL11_Q yesterday, but failed.

[Kiwamu, Larisa] 

We want to increase gain in the lower frequencies, so a circuit must be designed (a passive low pass filter). 

First, measurements were taken at the X arm for impedance and capacitance, which were 104.5kOhms and 84.7pF respectively. Kiwamu decided to make the circuit resemble a voltage divider for ease of calculation, such that Vout/Vin would be a ratio of some values of the equivalent circuit reactance values. After a few algebra mistakes, this Vout/Vin value was simplified in terms of the R, C measured and the R', C' that would be needed to complete the circuit. 

Since the measured C was very small and the measure R was fairly high, the simplified form allowed us to pick values of R' and C' that would make the critical frequency occur at 0.1Hz: set the R' resistance to 1MOhm and C' capacitance to 10uF, which would yield a gain ~1.

With these values a circuit we can start actually making the circuit.

Locked LO phase to ITMX single bounce beam at the AS port, using the DCPD (A-B) error point and actuating on LO1 POS. For this the gain was tuned from 0.6 to 4.0. A rough Michelson fringe calibration gives a counts to meters conversion of ~0.212 nm/count, and the OLTF looks qualitatively like the one in a previous measurement (~ 20 dB at 1 Hz, UGF = 30 Hz). The displacement was then converted to phase using lambda=1e-6; I'm not sure what the requirement is on the LO phase (G1802014 says 1e-4 rad/rtHz at 1 Hz, but our requirement doc says 1 to 20 nrad/rtHz (rms?)... anyways wit this rough calibration we are still off in either case.

The balancing gain is obvious at DC in the individual DCPD spectra, and the common mode rejection in the (A-B) signal is also appreciable. I'll keep working on refining this, and implementing a different control scheme.

[yuta, paco]

Update; the high frequency ( > 100 Hz) drop is of course not real and comes from a 4th order LP filter in the HPC demod I filter which I haven't accounted for. Furthermore, we have gone through the calibration factors and corrected a factor of 2 in the optical gain. Then, I also added the CLTF to show in loop and out of loop error respectively. The updated plot, though not final, is in Attachment #1.

Repeated the LO phase noise measurement, this time with the LO - ITMY single bounce, and a couple of fixes Koji hinted at including:

1. The DEMOD angle was the missing piece! The previous error point showed lower noise than the individual DCPDs because the demodulation angle had not been checked. I corrected it so that the error point in LO_PHASE control was exactly equal to the LO-ITMY single bounce fringe. With this, the gain on the servo had to be adjusted from 4.00 to 0.12, still using FM4, FM5, and this time also FM8 (BLP600).
2. Turned off 60 Hz harmonics comb notches on DCPDs, they are unecessary.
3. Acquired noise spectra down to 0.1 Hz, with 0.03 Hz bin width to increase resolution and identify resonant SUS noise near 1 Hz.

This time, after alignment the fringe amplitude was 500 counts. Attachment #1 shows the updated plot with the calibrated noise spectra for the individual DCPD signals A and B as well as their rms values. Attachment #2 shows the error point, in loop and the estimated out of loop spectra with their rms as well. The peak at ~ 240 Hz is quite noticeable in the error point time series, and dominates the high frequency rms noise. The estimated rms out of loop noise is ~ 9.2 rad, down to 100 mHz.

Free swing MI differential length is 86 nm RMS and residual length when locked is 0.045 nm RMS(in-loop).
Looks very quiet. Comparison with PRMI is the next step.

Openloop transfer function:
  OLTF of simple MI lock using AS55_Q_ERR as error signal and ITMs as actuators is below.
  UGF ~ 90 Hz, phase margin ~ 40deg
  I added 16 Hz resonant gain to suppress bounce mode.


MI differential length spectra:
  Below. Calibration was done using calibrated AS55_Q_ERR and actuator response(elog #8242)



  Expected free swing is calculated using

x_free = (1+G)/G * A * fb

where G is openloop transfer function, A is actuator response, fb is feedback signal(C1:LSC_ITMX/Y_IN1) spectrum. I used A as simple pendulum with resonant frequency at 1 Hz, Q = 5. Since free swing RMS is dominated by this resonance, RMS depends on this Q assumption.

[Jenne, Yuta]

We did the same calibration for POX. It was 3.8e12 counts/m. See elog #6834 for the details of calibration we did.

According to Kiwamu's calibration, actuator response of ITMX is;

A_ITMX  = 4.913e-09 Hz^2*counts/m / freq^2

Plots below are results from our calibration measurement.

[Jenne, Yuta]

We calibrated POY error signal(C1:LSC-POY11_I_ERR). It was 1.4e12 counts/m.

Modeling of Y arm lock:
  Let's say H is transfer function from Y arm length displacement to POY error signal. This is what we want to measure.
  F is the servo filter (filter module C1:LSC-YARM).
  A is the actuator TF using ITMY. According to Kiwamu's calibration using MICH (see elog #5583),

  A_ITMY  = 4.832e-09 Hz^2*counts/m / freq^2

  We used ITMY to lock Y arm because ITMY is already calibrated.

What we did:
  1. Measured openloop transfer function of Y arm lock using POY error signal using ITMY (G=HFA). We noticed some discrepancy in phase with our model. If we include 1800 usec delay, phase fits well with the measurement. I think this is too big.



  2. Measured a transfer function between actuator to POY error signal during lock. This should give us HA/(1+G).


  4. Calculated H using measurements above. Assuming there's no frequency dependance in H, we got

  H = 1.4e12 counts/m



 For sanity check; Peak to peak of the POY error signal when crossing the IR resonance is about 800 counts. FWHM is about 1 nm, so our measurement is not so crazy.

[Yuta, Jenne]

We have measured the out of loop residual motion of the Yarm while locked with the ALS.  We see ~70pm RMS, as compared to Kiwamu's best of ~24pm RMS.  So we're not yet meeting Kiwamu's best measurement, but we're certainly not in crazy-land.

The Yarm ALS was locked, I took a spectrum of POY11_I_ERR, and used the calibration that we determined earlier this evening.  For reference, I attach a screenshot of our ALS loop filters - we had on all the boosts, and both resonant gain filters (~3Hz and ~16Hz).

A large part of the RMS is coming from the 60Hz power line and the 180Hz harmonic....if we could get rid of these (how were they eliminated from the measurement that Kiwamu used in the paper?? - plotted elog 6780) we would be closer. 

Also, it looks like the hump (in our measurementf ~100Hz, in Kiwamu's ~200Hz) is not quite an order of magnitude higher in amplitude in our measurement vs. Kiwamu's.  We have ~5e-11 m/rtHz, Kiwamu had ~7e-12 m/rtHz.  This increase in noise could be coming from the fact that Yuta and Koji decreased the gain in the Ygreen PDH loop to prevent the PDH box from oscillating. 

While we should still think about why we can't use the same gain that Kiwamu was able to ~6 months ago, we think that we're good enough that we can move on to doing mode scans and residual motion measurements of the Xarm.

Measured free swing PRM-ITMY length was 230 nm RMS.
MI differential length was 85 nm RMS(elog #8248). This tells you that PR2, PR3 are not so noisy compared with usual suspensions.

Openloop transfer function:
  OLTF of PRM-ITMY cavity lock using REFL55_Q_ERR as error signal and PRM as actuator is below.
  UGF ~ 120 Hz, phase margin ~ 50 deg.
  Somehow, phase delay was 460 usec, which is smaller than the empirical value 550 usec.



PRM-ITMY length spectra:
  Below. Calibration was done using calibrated REFL55_Q_ERR and actuator response(elog #8255).

We did online adaptive filtering test with IMC and arms 1 year ago (log 7771). In the 40m presentations I can still see the plot with uncalibrated control spectra that was attached to that log. Now it the time to attach the calibrated one.

Template is in the /users/den/oaf

FSR for X/Y arm are 3.97 +/- 0.03 MHz and 3.96 +/- 0.02 MHz respectively. This means X/Y arm lengths are 37.6 +/- 0.3 m and 37.9 +/- 0.2 m respectively.
I calibrated the mode scan results using 11MHz sideband as frequency reference.
Calibration factor between the phase of the phase tracker and IR frequency is 9.81 +/- 0.05 kHz/deg for X arm, 9.65 +/- 0.02 kHz/deg for Y arm.

Calculation:
  For the mode scan measurements, we swept the phase of the phase tracker linearly with time. Previous calculation was done without calibrating seconds into actual IR frequency. The first order calibration can be done using modulation frequency as reference. Note that I'm still assuming our sweep was linear here.

  Relation between FSR and modulation frequency can be written in

f_mod = n * nu_FSR + nu_f

  where f_mod is the modulation frequency, n is an integer, nu_f = mod(nu_FSR,f_mod).
  nu_FSR and nu_f are measurable values (in seconds) from the mode scan. We know that f_mod = 11065910 Hz (elog #6027). We also know that nu_FSR is designed to be ~3.7 MHz(=c/2L). So, n = 2.
  We can calculate f_mod in seconds, so we can calibrate seconds into IR frequency.


Calibrating X arm mode scan:
  From the 8FSR mode-scan data (see elog #6859), positions of TEM00 and upper/lower 11 MHz sidebands in seconds are;

TEM00    242.00     214.76     187.22     159.27     131.33     102.96     74.61     46.00     17.51
upper    236.70     209.05     181.36     153.42     125.06      96.86     68.43     40.20
lower    220.35     192.96     165.03     136.98     108.92      80.65     52.25     23.90

  So, FSR and nu_f in seconds are;

FSR    27.24     27.54     27.95     27.94     28.37     28.35     28.61     28.49
nu_f   21.80     21.82     22.14     22.19     22.26     22.28     22.40     22.40

  By using formula above, modulation frequency in seconds are;

f_mod    76.28    76.90    78.04    78.07    79.00    78.98    79.62    79.38

  By taking average, FSR and f_mod in seconds are

FSR    28.1 +/- 0.2
f_mod    78.3 +/- 0.4

  We know that f_mod = 11065910 Hz, so conversion constant from seconds to frequency is

k1 = 0.1413 +/- 0.0007 MHz/sec

  We swept the phase by 3600 deg in 250 sec, so conversion constant from degree to frequency is

k2 = 9.81 +/- 0.05 kHz/deg

  Also, using k1, FSR for X arm is

FSR = 3.97 +/- 0.03 MHz

  This means, X arm length is

L = c/(2*FSR) = 37.6 +/- 0.3 m


Calibrating Y arm mode scan:
  From the 8FSR mode-scan data (see elog #6832), positions of TEM00 and upper/lower 11 MHz sidebands in seconds are;

TEM00    246.70     218.15     190.06     161.87     133.26     104.75     76.01     47.19     18.60
upper    240.86     212.78     184.32     155.73     127.23      98.48     69.78     41.26
lower    224.53     195.73     167.31     139.13     110.81      82.27     53.60     24.50

  So, FSR and nu_f in seconds are;

FSR    28.55     28.09     28.19     28.61     28.51     28.74     28.82     28.59
nu_f   22.44     22.57     22.60     22.61     22.47     22.48     22.50     22.68

  By using formula above, modulation frequency in seconds are;

f_mod    79.54    78.75    78.98    79.825    79.485    79.955    80.14    79.855

  By taking average, FSR and f_mod in seconds are

FSR    28.5 +/- 0.1
f_mod    79.6 +/- 0.2

  We know that f_mod = 11065910 Hz, so conversion constant from seconds to frequency is

k1 = 0.1390 +/- 0.0003 MHz/sec

  We swept the phase by 3600 deg in 250 sec, so conversion constant from degree to frequency is

k2 = 9.65 +/- 0.02 kHz/deg

  (k2 of X arm and Y arm is different because delay-line lengths are different)
  Using k1, FSR for X arm is

FSR = 3.96 +/- 0.02 MHz

  This means, X arm length is

L = c/(2*FSR) = 37.9 +/- 0.2 m


Summary of mode scan results:
X arm
  Mode matching    MMR = 91.2 +/- 0.3 % (elog #6859) Note that we had ~2% of 01/10 mode.
  FSR         FSR = 3.97 +/- 0.03 MHz (this elog)
  finesse    F = 416 +/- 6 (elog #6859)
  g-factor    g1*g2 = 0.3737 +/- 0.002 (elog #6922)

  length        L = 37.6 +/- 0.3 m (this elog)
  ETM RoC  R2 = 60.0 +/- 0.5 m (this elog and #6922; assuming ITM is flat)

Y arm
  Mode matching    MMR = 86.7 +/- 0.3 % (elog #6828) Note that we had ~5% of 01/10 mode.
  FSR         FSR = 3.96 +/- 0.02 MHz (this elog)
  finesse    F = 421 +/- 6 (elog #6832)
  g-factor    g1*g2 = 0.3765 +/- 0.003 (elog #6922)

  length       L = 37.9 +/- 0.2 m (this elog)
  ETM RoC R2 = 60.7 +/- 0.3 m (this elog and #6922; assuming ITM is flat)

  I think these are all the important arm parameters we can derive just from mode scan measurement.

  Every errors shown above are statistical error in 1 sigma. We need linearity check to put systematic error. Also, we need more precise calibration after that, too, if the sweep has considerably large non-linearity. To do the linearity check, I think the most straight forward way is to install frequency divider to monitor actual beat frequency during the sweep.

These aren't so bad. (Look at this entry)

And interestingly the ETM curvatures are closer to ATF measurements than Coastline's measurement. (Look at wiki)

[Jenne, Yuta]

We put 0 dBm sine wave to the RF input of the beatbox and linear-sweeped frequency of the sine wave from 0 to 200 MHz using network analyzer (Aligent 4395A).
(We first tried to use 11 MHz EOM marconi)

Whlile the sweep, we recorded the output of the beatbox, C1:ALS-BEATY_(FINE|COARSE)_(I|Q)_IN1_DQ. We made them DQ channels today. Also, we put gain 10 after the beatbox before ADC for temporal whitening filter using SR560s.

We fitted the signals with sine wave using least squares fit(scipy.optimize.leastsq).
Transision time of the frequency from 200 MHz to 0 Hz can be seen from the discontinuity in the time series. We can convert time to frequency using this and supposing linear sweep of the network analyzer is perfect.

Plots below are time series data of each signal(top) and expansion of the fitted region with x axis calibrated in frequency (bottom).





We got

C1:ALS-BEATY_COARSE_I_IN1_DQ = -1400 sin(0.048 freq + 1.17pi) - 410
C1:ALS-BEATY_COARSE_Q_IN1_DQ = 1900 sin(0.045 freq + 0.80pi) - 95

C1:ALS-BEATY_FINE_I_IN1_DQ = 1400 sin(0.89 freq + 0.74pi) + 15
C1:ALS-BEATY_FINE_Q_IN1_DQ = 1400 sin(0.89 freq + 1.24pi) - 3.4

(freq in MHz)

The delay line length calculated from this fitted value (supposing speed of signal in cable is 0.7c) is;

  D_coarse = 0.7c * 0.048/(2*pi*1MHz) =  1.6 m
  D_fine = 0.7c * 0.89/(2*pi*1MHz) = 30 m

So, the measurement look quite reasonable.

FINE signals looks nice because we have similar response with 0.5pi phase difference.
For COARSE, maybe we need to do the measurement again because the frequency discontinuity may affected the shape of the signal.

[Manasa, Yuta]

We measured AC response of PRM actuator using PRM-ITMY cavity.
Result is

PRM:  (19.6 +/- 0.3) x 10^{-9} (Hz/f)^2 m/counts

It is almost the same as in 2011 (elog #5583). We took the same procedure as what Kiwamu did.

What we did:
  1. Aligned PRMI in usual procedure, mis-aligned ITMX and locked PRM-ITMY cavity using REFL55_Q_ERR. POP DC was about 18 when locked.

  2. Made UGF of PRM-ITMY cavity lock at 10 Hz and introduced elliptic LPF at 50 Hz(OLTF below).



  3. Measured transfer function from C1:LSC_ITMY_EXC to C1:LSC_REFL55_Q_ERR. Dividing this by ITMY actuator response(measured in elog #8242) gives calibration of REFL55_Q.

  4. Measured transfer function from C1:LSC_PRM_EXC to C1:LSC_REFL55_Q_ERR to calibrate PRM actuator.

Result:
  Calibration factor for REFL55_Q for PRM-ITMY cavity was (1.37 +/- 0.02) x 10^9 counts/m (plot below). Error is mainly from statistical error of the average.



  Measured AC response (50-200 Hz) of PRM is below.



Next:
  - Measure free-run length spectrum of PRM-ITMY cavity and compare with MICH free-run.

The AC response of the SRM actuator has been calibrated.

 

Motivation

In order to estimate whether we can see acoustic coupling in arms or not, we have to calibrate signals to phase noise.

Method

I used the same method as Yuta and Jenne did (6834).
I switched from ETM locking to ITM locking since only ITM actuators are calibrated (5583), and measured the open loop transfer function and the transfer function from ITM excitation to POX/POY error signal. Then I can estimate the calibration value H [counts/m] from POY/POX error signal to displacement.

Results

Yarm; H = 9.51 x 10¹¹ counts/m
 

Xarm; H = 6.68 x 10¹¹ counts/m

Phase noise in arms:

blue; Xarm, green; Yarm

Next Step

I will calibrate the acoustic signal and see if it is reasonable that we can see the acoustic coupling signal in the arms.
But I guess it is difficult. Actually I have not seen coherence between ETM feedback signals and acoustic sounds yet. (I measured acoustic noise near POX and in PSL table.)

If I find that it is hopeless, I will create some sounds and try to measure transfer function from acoustic sound to arm cavity signals.
I am interested in how the transfer function calculated by wiener filtering is different from the measured transfer function.

Note

I found that we do not have enough phase margin. This is why the arm locking is not so stable.

For the loop diagnosis, its best to use the method of "IN1/IN2", rather than manipulate the close loop gain. In this way, you can directly plot the swept sine measurement from DTT as the open loop gain.

Also, for reporting calibration, we should all try to record the current settings better. Anything that may change the loop gain should be recorded along with the Bode plot and the DATA must be posted to the elog - no more of just posting plots.

We need to know, e.g.

1. what is the power in the arms?
2. are the LSC whitening filters on?
3. are the SUS dewhitening filters on?
4. What normalization is being used in the LSC?
5. What digital filters are on in the X/YARM loop filter bank?

Resistance is feudal.

I uploaded a zip file that contains data files used for the calibration.

OLTF_x/y.txt: the open loop transfer function (measured by IN1/IN2 in arm servo filter bank).
coh_x/y.txt: coherence of OLTF. I used the data where coherence > 0.98.
ext_err_x/y.txt: the transfer function from ITM excitation signal to POX/POY error signal.
coh_x2/y2.txt: coherence of ext_err. I used the data where coherence > 0.98.

The LSC whitening filter was off because the xarm was unlocked when the POX Q whitening filter was turned on. (We have to study what was wrong.)
The SUS whitening filters were on.
The all digital filters except +6dB filter were on.

Cameras must be immediately anchord to avoid a possible collusion with the view port !

 I optimized the TM views with illuminator light on quad1  It actually looks better there.

I'll post a dark-  OSEM light only in jpg tomorrow.  ETMY camera is malfunctioning in dark condition now.

In this evening I found that fb40m has been down, then I restarted fm40m successfully.

However there still is a problem, the reflective memory can not communicate with some front-end CPUs ( such as c1iscey, c1susvme, ...etc.)

Right now I don't have any ideas about this, I am leaving them as they are now .... we can deal with them tomorrow. 

The followers are what I did.

(1) ssh to fb40m then "pkill tpman"

(2) telnet to fb40m then typed "shutdown". ( These procedure are on the 40m wiki)

(3) make sure fb40m gets recovered while watching the medm screen C0DAQ_DETAIL.adl

(4) run the backup script in fb40m

(5) in order to fix the communication problem, physically turn off c1dcuepics and c0daqctrl

(6) keying some front-end CPUs. ---> still some of front ends indicate RED on the medm screen C0DAQ_DETAIL.adl ( figure attached )

What I did: 

1. Followed the same procedure to enable ALS (http://nodus.ligo.caltech.edu:8080/40m/8703)
2. Enabling ALS servo stabilized the arm fluctuation and the beat frequency.
3. Beat frequency sweep was done (with ALS servo enabled) by changing offset C1:ALS-BEATX_FINE_OFFSET_OFFSET in steps.

Discussion:

We can't read minute trends from either Dataviewer or loadLIGOData from before 11am this morning. 

fb:/frames>du -skh minute-trend-frames/
 106G   minute-trend-frames


So the frames are still on the disk.  We just can't get them with our usual tools (NDS).

 Trying to read 60 days of minute trends from C1:PSL-PMC_TRANSPD yields:

Connecting to NDS Server fb40m (TCP port 8088)
Connecting.... done
258.0 minutes of trend displayed
read(); errno=9
read(); errno=9
T0=09-06-06-22-34-02; Length=5184000 (s)
No data output.


Trying to read 3 seconds of full data works.

Second trends are readable after about 4am UTC this morning, which is about 9 pm last night.

 Yesterday Alex started transferring the data records to the new storage unit. That prevented us from accessing the trends for a fe hours.

The process had been completed and now we can read the trends again.

I tried to align and lock Y arm for the first time after pumping.
But I couldn't lock Y arm for more than ~1 sec. Why?


What I did:
  1. Centered IPANG/IPPOS using input TT1/TT2.

  2. Restored ITMY/ETMY slider values when it was aligned before pumping. I saw tiny flashes in TRY PD at this point.

  3. Replaced Ygreen REFL camera with ETMYT camera to see transmitted beam mode.

  4. Used TT1/TT2 and ITMY/ETMY to get ~ 0.4 peak in normalized TRY PD output (C1:LSC_TRY_OUT).

  5. Centered POY beam on POY11 PD.

  6. Changed I/Q mixing angle (C1:LSC-POY11_PHASE_R) from -61 deg to -16 deg to get good PDH signal in I_ERR (attached).

  7. Ran LSCoffsets script (now on LSC_OVERVIEW screen) to adjust PD offsets.

  8. Tried to lock Yarm with different gains, but failed. When lock is acquired, TRY fluctuates ~50 % and unlocks suddenly.


What I found:
  1. There was some OFFSETs left turned on in suspension screens. Don't leave them on!! They change alignment of the optics. I will leave it on until we complete Yarm alignment.

  2. C1:SUS-(ITMY|ETMY)_ASC(PIT|YAW) was kept oscillating the optic since Dec 17, 2013. I think this is from interrupted ASS script. Your script should restore everything when interrupted!


Next:
  - Beamspot on ITMY looks off-centered. Maybe A2L is causing unstable lock?
  - Maybe F2A is causing unstable lock?
  - More alignment?
  - FSS related? crontab related?

I'm not sure that Yuta had found the real Yarm flashes last night.  When I came in today, the Yarm would flash.  However I found that the SRM was aligned, and if I misaligned it, the Yarm flashes would disappear.  So somehow the beam getting into the cavity was related to the reflection off of the SRM.

Later, I moved the TTs, leaving ITMY and ETMY alone, after having misaligned SRM (and ITMX) and I found flashes.  This wasn't ideal though, since the beam was much, much too high on IPANG (beam was half falling off the top of the lens, although yaw was pretty good).  That was also when I changed out the ETMYT camera the first time around.  The flashes on the new camera were visible, but much dimmer than with the Watec.

I tried locking the Yarm in this state, but I could never achieve a lock, even momentarily.  It almost seemed like I wasn't sending actuation signal out to the coils, although signal appeared all the way through the chain until the LSC signal summed with the local damping signal.  I also switched the LSC output matrix to try actuating on the ITM, but I was also not able to lock then.  I have switched it back to have Yarm actuate on ETMY.  I could see a nice PDH signal on POY, and nice flashes on TRY, but no lock at all.  The trigger was triggering, but still no catching of the lock.  I'm not really sure what's up.

After playing with a non-locking, poorly aligned Yarm, I started over by recentering the beam on IPPOS and IPANG using the TTs, but have not been able to get flashing in the cavity again.  After much fitzing around, I put the Watec back at ETMYT, in hopes that we can see flashes again at some point, since it's more sensitive than the old Sony.  Still no flashes though.

I have to leave, but Yuta and Manasa are here, and so I'm leaving the IFO in their custody.

Jenne found that;
  0. If all mirrors are "aligned," Yarm flashes.
  1. If SRM is misaligned, Yarm doesn't flash.
  2. If BS is misaligned, Yarm doesn't flash.
  3. If ITMX is misaligned, Yarm still flashes.

So, my hypothesis from this is that I was playing with " TT1 -> TT2 -> ITMY -> BS -> SRM -> BS -> Yarm "  configuration last night.
This hypothesis can explain;
  1. Why I could not get TRY peak more than 0.5 (additional BS reflection makes incident power to Yarm less).
  2. Why I had to change POY11 I/Q mixing angle by ~ 45 deg (because EOM to Yarm length changed).
  3. Why I couldn't lock Yarm stably (additional reflection by BS and SRM made too much beam jitter?).

We are now trying to get "real" Yarm flash.

[Jenne, Koji, Yuta]

We tried to scan of the Y arm but we couldn't scan for more than 1FSR.
In principle, we can do that because the error signal we are using, C1:ALS-BEATY_COARSE_I_IN1, has the range of ~ 40 MHz, which is about 10FSR (see elog http://nodus.ligo.caltech.edu:8080/40m/6815).

ALS stays for more than 10 min when we don't do the scan. If we put some offset gradually from C1ALS-OFFSETTER2, the lock breaks.
We monitored PZT output of the Y end laser, C1:GCY-SLOW_SERVO1_IN1, but it stayed in the range when scanning. So, there must be something wrong in the ALS loop.

Current in-loop arm length fluctuation is about 0.1 nm RMS (0.5 counts RMS).
Below is the spectrum of the error signal when the ALS is off(green) and on (pink,red). Below ~ 50 Hz, the measurement of the Y arm length is limited by ADC noise (~ 2uV/rtHz).

All of our wikis (except the 40m one which unfortunately got turned into ligo.org mess) use DokuWiki. This now has an auto-upgrade feature through the Admin web interface.

I tried this recently and it fails with this message:

DokuWiki 2018-04-22a "Greebo" is available for download.
 You're currently running DokuWiki Release 2017-02-19e "Frusterick Manners".
 New DokuWiki releases need at least PHP 5.6, but you're running 5.4.16. You should upgrade your PHP version before upgrading!

So we'll have to wait until SL7 (which is what NODUS is running).

I DID do a 'yum upgrade' which updated all the packages. I also installed yum-cron so that the RPM listings get updated daily. But sadly, SL7 only has PHP 5.4.16 (which is a June 2013 release):

> Package php-5.4.16-43.el7_4.1.x86_64 already installed and latest version

I have updated the /opt/rtcds paths to reflect the new specification of the CDS aLIGO code release procedures document.

Path to RTS:  /opt/rtcds/caltech/c1/core/release

This is where the advLigoRTS front-end code generator is checked out.  The "release" directory is a link to the svn branch from which we are currently running ("trunk" by default).

This used to be at /opt/rtcds/caltech/c1/core/advLigoRTS

Path to userapps: /opt/rtcds/caltech/c1/userapps/release

This is where the cds_user_apps code is checked out.  cds_user_apps is where all of the front-end models, medm screen, scripts, etc. will live.  The "release" directory is a link to the svn branch from which we are currently running ("trunk" by default).

This was most recently at /opt/rtcds/cds_user_apps

A small change, but now the carm_up script supports both sides of the CARM offset.  After the arms are locked with ALS it asks for a "+" or a "-", which indicates which sign of digital CARM offset will be added.  In the past, we have been primarily using the "+" sign.