40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
 40m Log, Page 111 of 344 Not logged in
ID Date Author Type Category Subject
11038   Mon Feb 16 03:10:42 2015 KojiUpdateLSCALS fool measured decoupling TF

Wonkey shape: Looks like a loop supression. Your http://nodus.ligo.caltech.edu:8080/40m/11016 also suggests it too, doesn't it?

11044   Tue Feb 17 16:44:04 2015 KojiUpdateLSCDelay line installed again

For tonight's experiment, I re-installed the delay line cable and changed the attenuation to 10dB for the 55MHz modulation.

I quickly locked the PLL and checked that the modulation is the ratio of the field strength between the worst (19ns) and best
case (28ns) is 31dB, that is ~35 times reduction.

11045   Tue Feb 17 19:49:51 2015 KojiUpdateLSCDelay line un-installed again

The modulation setting was reverted.
Demod phase for REFL11/33/55/165 and AS55 were reverted to the previous numbers too.

11048   Wed Feb 18 19:06:40 2015 KojiUpdateLSCALS Fool impulse response

11059   Mon Feb 23 21:57:13 2015 KojiUpdateLSCDelay line installed again (experiment, round 1)

Last Wednesday we tried PRMI 3f modulation cancellation. Under the 3f modulation cancellation, the PRMI could not be locked
with REFL signals, and the PRCL signal was just barely sufficient to lock PRCL with help of AS55Q MICH.

- The PRCL signal level in REFL33 was reduced by factor of 20 compared with the conventional modulation setting.
=> The 3f modulation cancellation does not chage the level of 11/22MHz sidebands, it is expected that REFL33 signal
has no significant change of the signal level. But it does.  If we change the relative phase between the modulations
at 11 and 55MHz, the signal level is recovered by factor of 5. Therefore something related to 55MHz modulation
(55MHz x 22MHz, or 44MHz x 11MHz) was contributing more than -11MHzx22MHz.

- Under the 3f demodulation cancellation, MICH signal in the REFL ports were extremely weak and there was
no hope to use it for any feedback control.

- WIth the PRMI locking by REFL33->PRCL and AS55Q->MICH, the sensing matrix was measured. All of the REFL
ports however, showed extremely degenerate sensing matrix between MICH and PRCL.

This was enough confusing to us, and we didn't draw any useful information from these. Here are some ideas to
investigate what is happening in out optical and electrical system.

- One approach is to use as simple optical setup as possible to inspect our sensing systems. For example,
we may want to try PRX/PRY/XARM/YARM cavities to check the functions of the REFL diodes and qualitatively characterize
the sensing chain (Optical gain [W/m], noise level, demodulation phase) so that we can compare these with
an interferometer seinsing model.

- Another approach is to change the mdulation setting more freely and empirically try to find the characteristic
of our optical/electrical systems. e.g. change the relative modulation phase and/or 55MHz attenuation, and try to understand
how 11-22, 11-44, 22-55, 0-33 pairs are contributing the signal.

11066   Wed Feb 25 12:16:27 2015 KojiUpdateLSCDelay line re-installed, measurements round 2

## WHAT? WHAT? WHAT? It's obviously opposite.

If the reflectivity of the front mirror is fixed (=PRM reflectivity), the finesse increases when the reflectivity of the end
mirror (=Compond mirror reflectivity) increases. i.e. 11MHz has higher finesse, 55MHz has lower finesse.

$\dpi{150} {\cal F} = \frac{\pi \sqrt{r_{\rm PRM} r_{\rm COM}}}{1-r_{\rm PRM} r_{\rm COM}}$

If the reflectivity of the front mirror is fixed, the amplitude gain of the cavity is higher when the reflectivity of the end mirror increases. i.e. 11MHz has higher gain, 55MHz has lower gain

$\dpi{150} g_{\rm PRM} = \frac{t_{\rm PRM}}{1-r_{\rm PRM} r_{\rm COM}}$

 Quote: Our Schnupp asymmetry is small (3.9cm, IIRC), so the transmission of the 11MHz signal out the dark port is small.  This means that the finesse of the PRC for 11MHz isn't so huge.  On the other hand, since 55MHz is a higher frequency, the transmission out the dark port is larger and is a closer match to the PRM transmission, so the finesse of the PRC for 55MHz is higher.

11074   Thu Feb 26 01:53:35 2015 KojiUpdateLSCModelled effect of relative modulation phase

Ok... This is what I was afraid of, and it seems true.
i.e. the relation ship of the modulations for the 3f cancellation is making the PRCL signals cancel each other.

It agrees with Anamaria's analysis that 11x44 is the strongest component in aLIGO 27MHz signal.
In fact,

00x33 has the order of $\dpi{100} \frac{m_1^2 m_2}{16}+\frac{m_1^3}{48}$

11x22 has the order of $\dpi{100} \frac{m_1^3}{16}$

11x44 has the order of $\dpi{100} \frac{m_1^2 m_2}{8}$

22x55 has the order of $\dpi{100} \frac{m_1^2 m_2}{16}$

Therefore 11x44 is inherently the strongest contribution at 33MHz.
(And then, of couse, the signal amplitudes have additional dependences on the reflectivity
and the gain of the IFO at each freq)

If we believe this result, it may be difficult to exploit the benefit of the signals under the 3f cancellation.
We probably have to go back to the original idea of cancelling the 3f modulation by adding 3f modulation.
(i.e. Produce 33MHz signal by freq tripling, add this signal to Kiwamu's box to elliminate 3f.)

11117   Sun Mar 8 00:05:37 2015 KojiConfigurationLSCCARM and DARM on RF signals!!!!!!!!!!!!!!!!!!!!

Exciting! How long was it?

11129   Tue Mar 10 19:59:13 2015 KojiFrogsCamerasMessage from the IFO

11134   Wed Mar 11 19:15:03 2015 KojiSummaryLSCROUGH calibration of the darm spectrum during the full PRFPMI lock

I made very rough calibration of the DARM spectra before and after the transition for the second lock on Mar 8.

The cavity pole (expected to be 4.3kHz) was not compensated. Also the servo bump was not compensated.

[Error calibration]

While the DARM/CARM were controlled with ALS, the calibration of them are provided by the ALS phase tracker calibration.
i.e 1 degree = 19.23kHz

This means that the calibration factor is

DARM [deg] * 19.23e3 [Hz/deg] / c [m Hz] * lambda [m] * L_arm [m]
= DARM* 19.23e3/299792458*1064e-9*38.5 = 2.6e-9 *DARM [m]

[Feedback calibration]

Then, the feedback signal was calibrated by the suspension response (f=1Hz, Q=5)
so that the error and feedback signals can match at 100Hz.

This gave me the DC factor of 5e-8.

The spectra at 1109832200 (ALS only, even not on the resonance) and 1109832500 (after DARM/CARM transitions) were taken.
Jenne said that the whitening filters for AS55Q was not on.

11135   Wed Mar 11 19:48:25 2015 KojiUpdateGeneralFOL troubleshooting

There is a frequency counter code written by the summer student.
The code needed some cleaning up.
It's still there in /opt/rtcds/caltech/c1/scripts/FOL as armFC.c

This code did not provide unified way to send commands to the FCs.
Therefore I made a code to change the frequency range of the FCs
by removing unused variables and instructions, adding more comments,
adding reasonable help messages and trouble shooting feedbacks.

Obviously these codes only run on domenica (raphsberry Pi host)

/opt/rtcds/caltech/c1/scripts/FOL/change_frange

change_frange : change the freq range of the frequency counter UFC-6000

Usage: ./change_frange DEVICE VALUE     DEVICE: '/dev/hidraw0' for Xarm, '/dev/hidraw1' for Yarm     VALUE: 0 - automatic 1 -    1MHz to   40MHz 2 -   40MHz to  190MHz 3 -  190MHz to 1400MHz 4 - 1400MHz to 6000MHz

11137   Thu Mar 12 11:57:38 2015 KojiUpdateGeneralFOL troubleshooting

BTW, during this trouble shoot, we looked at the IR beatnote spectrum between the Xend and the PSL.
It showed a set of sidebands at ~200kHz, which is the modulation frequency.
There was another eminent component present at ~30kHz.
I'm afraid that there is some feature like large servo bump, a mechanical resonance, or something else, at 30kHz.

We should check it. Probably it is my job.

11151   Fri Mar 20 13:29:33 2015 KojiUpdateIOOWaking up the IFO

If the optics moved such amount, could you check the PD alignment once the optics are aligned?

11171   Wed Mar 25 18:27:34 2015 KojiSummaryGeneralSome maintainance

- I found that the cable for the AS55 LO signal had the shielding 90% broken. It was fixed.

- The Mon5 monitor in the control room was not functional for months. I found a small CRT down the east arm.
It is now set as MON5 showing the picture from cameras. Steve, do we need any safety measure for this CRT?

11173   Wed Mar 25 18:48:11 2015 KojiSummaryLSC55MHz demodulators inspection

[Koji Den EricG]

We inspected the {REFL, AS, POP}55 demodulators.

Short in short, we did the following changes:

- The REFL55 PD RF signal is connected to the POP55 demodulator now.
Thus, the POP55 signals should be used at the input matrix of the LSC screens for PRMI tests.

- The POP55 PD RF signal is connected to the REFL55 demodulator now.

- We jiggled the whitening gains and the whitening triggers. Whitening gains for the AS, REFL, POP PDs are set to be 9, 21, 30dB as before.
However, the signal gain may be changed. The optimal gains should be checked through the locking with the interferometer.

- Test 1

Inject 55.3MHz signal to the demodulators. Check the amplitude in the demodulated signal with DTT.
The peak height in the spectrum was calibrated to counts (i.e. it is not counts/rtHz)
We check the amplitude at the input of the input filters (e.g. C1:LSC-REFL55_I_IN1). The whitening gains are set to 0dB.
And the whitening filters were turned off.

REFL55 f_inj = 55.32961MHz -10dBm REFL55I @999Hz  22.14 [cnt] REFL55Q @999Hz  26.21 [cnt]

f_inj = 55.33051MHz -10dBm REFL55I @ 99Hz  20.26 [cnt]  ~200mVpk at the analog I monitor REFL55Q @ 99Hz  24.03 [cnt]

f_inj = 55.33060MHz -10dBm REFL55I @8.5Hz  22.14 [cnt] REFL55Q @8.5Hz  26.21 [cnt]

----
f_inj = 55.33051MHz -10dBm AS55I   @ 99Hz 585.4 [cnt] AS55Q   @ 99Hz 590.5 [cnt]   ~600mVpk at the analog Q monitor

f_inj = 55.33051MHz -10dBm POP55I  @ 99Hz 613.9 [cnt]   ~600mVpk at the analog I monitor POP55Q  @ 99Hz 602.2 [cnt]

We wondered why the REFL55 has such a small response. The other demodulators seems to have some daughter board. (Sigg amp?)
This maybe causing this difference.

-----

- Test 2

We injected 1kHz 1Vpk AF signal into whitening board. The peak height at 1kHz was measured.
The whitening filters/gains were set to be the same condition above.

f_inj = 1kHz 1Vpk REFL55I 2403 cnt REFL55Q 2374 cnt AS55I   2374 cnt AS55Q   2396 cnt POP55I  2365 cnt POP55Q  2350 cnt

So, they look identical. => The difference between REFL55 and others are in the demodulator.

11174   Wed Mar 25 21:44:20 2015 KojiUpdateLSCIFO recovery / PRFPMI locking activity

[Koji, Den]

- Aligned the arms with ASS. It had alot of offset accumulated. We offloaded it to the suspension.

- We could lock the PRMIsb with the new setup.
PRCL: REFL165I (-14deg, analog +9dB)) -0.1, Locking FM4/5, Triggered FM 2
MICH: REFL165Q (-14deg, analog +9dB) -1.5, Locking FM4/5, Triggered FM2/6/9

- Demod phases at REFL were adjusted such that PRCL in Q signals were minimized :
REFL165 -80deg => -14deg
POP55 -63deg
REFL11 +164 => +7
REFL33 +136 => +133

Note: analog gains: REFL11: +18dB,  REFL33: +30dB, POP55: +12dB, REFL165: +9dB

- Try some transition between REFL signals to check the signal quality.
Measure TFs between the REFL signals

PRCL gain
REFL11I/REFL165I = +58 REFL33I/REFL165I = +8.5 POP55I /REFL165I = -246

MICH gain
REFL11Q/REFL165Q = +11 REFL33Q/REFL165Q = -1.5 POP55Q /REFL165Q = +280

- This resulted us to figure out the relationships of the numbers in the input matrix

REFL55I/Q -4e-3/4e-3
REFL165I/Q 1.0/1.0 (reference) REFL11I/Q  0.02/0.1 REFL33I/Q +0.12/-0.7

Full locking trial

Arm locked -> ALS -> Arm offset locked
PRMI locking
REFL165 phase tuned -110deg
PRCL gain -0.1 / MICH gain -2

We needed script editing.
Previous script saved in: /opt/rtcds/caltech/c1/scripts/PRFPMI/carm_cm_up_BACKUP.sh

Change:
- PRMI gain setting (input matrix & servo gain)
- CARM/DARM transition setting (see below)

The current CARM/DARM transition procedure:

== CARM TRANSITION (PART1) ==
- CM REFL1 gain is set to be -32
- CARM_B is engaged and the gain is ramped from 0 to +2.5
- Turn on FM7 (integrator)
- MC IN2 (AO path) engaged
- MC IN2 gain increased from -32 to -21

== DARM TRANSITION (PART1) ==
- DARM_B is engaged and the gain is ramped from 0 to +0.1
- Turn on FM7 (integrator)

== CARM TRANSITION (PART2) ==
- CM REFL1 Gain is increased from -32 to -18
- Ramp down CARM A gain to 0

== DARM TRANSITION (PART2) ==
- DARM_B gain is incrased to 0.37. At the same time DARM_A gain is reduced to 0

We succeeded to make the transition several times in the new setting.

- But later the transition got hard. We started to see big jump of the arm trans (TRX/Y 50->100) at the CARM transition.

- We tested the PRCL transition from 165MHz to 55MHz. 55MHz (i.e. POP55 which is REFL55PD) looks alot better now.

- ~1:30 The PMC was realigned. This  increased PMC_TRANS about 10%. This let the Y arm trans recover ~1.00 for the single arm locking

- Decided to end around 3:00AM

11179   Fri Mar 27 14:47:57 2015 KojiUpdateLSCals->pdh transition, prcl on 1f, alignment

Jenne and I interviewd Den this afternoon to make the things clear

- His "duty cycle" is not about the lengths of the lock stretch. He saids, the transition success probability is improved.

- For this improvement, the CARM transition procedure was modified to include turning on 1:20 (Z1P20) filter in CARM_A (i.e. ALS) once CARM_B (i.e. RF) dominates the loop in all frequency.

- I think this transition can be summarized like the attachment. At STEP4, the integration of the ALS is reduced. This actually does not change the stability of the servo as the servo stability is determined by the stability of the CARM_B loop. But this does further allow CARM_B to supress the noise. Or in other word, we can remove the noise coming from the CARM_A loop.

- The POP22 issue: Jenne has the trigger signal that is immune to this issue by adding some amount of POPDC for the trigger.
We can avoid the trigger issue by this technique. But if the issue is due to the true optical gain fluctuation, this may mean that the 11MHz optical gain is changing too much. This might be helped by PRC angular feedforward or RF 22MHz QPD at POP.

11180   Fri Mar 27 20:32:17 2015 KojiSummaryLSCLocking activity

- Adjutsed the IMC WFS operating point. The IMC refl is 0.42-0.43.

- The arms are aligned with ASS

- The X arm green was aligned with ASX. PZT offsets slides were adjusted to offload the servo outputs.

- I tried the locking once and the transition was successfull. I even tried the 3f-1f transition but the lock was lost. I wasn't sure what was the real cause.

I need to go now. I leave the IFO at the state that it is waiting for the arms locked with IR for the full locking trial.

11183   Tue Mar 31 03:02:44 2015 KojiUpdateLSCSome locks

Assuming the carrier mode in PRC is stable and the SB is the one moving, can we just use the POP DC QPD to control PRM?

Can we plot the arm power trend for multiple locks to see if it is associated with any thermal phenomenan in the IFO?
They should be able to fit with an exp + DC.

11245   Fri Apr 24 21:31:20 2015 KojiSummaryCDSautomatic mxstream resetting

We were too much annoyed by frequent stall of mxstream. We'll update the RCG when time comes (not too much future).

But for now, we need an automatic mxstream resetting.

I found there is such a script already.

/opt/rtcds/caltech/c1/scripts/cds/autoMX

So this script was registered to crontab on megatron.
It is invoked every 5 minutes.

# Auto MXstream reset when it fails
0,5,10,15,20,25,30,35,40,45,50,55 * * * * /opt/rtcds/caltech/c1/scripts/cds/autoMX >> /opt/rtcds/caltech/c1/scripts/cds/autoMX.log

11248   Sat Apr 25 03:32:45 2015 KojiUpdateASCBroken Xass?

I spent a day to fix the XARM ASS, but no real result. If the input of the 6th DOF servo is turned off, the other error signals are happy
to be squished to around their zeros. So this gives us some sort of alignment control. But obviously a particular combination of the
misalignment is left uncontrolled.

This 6th DOF uses BS to minimize the dither in ITMX yaw. I tired to use the other actuators but failed to have linear coupling between
the actuator and the sensor.

During the investigation, I compared TRX/TRY power spectra. TRX had a bump at 30Hz. Further investigation revealed that the POX/POY
had a big bump in the error signals. The POX/POY error signals between 10-100Hz were coherent. This means that this is coming from
the frequency noise stabilized with the MC. (Is this frequency noise level reasonable?)

The mysterious discovery was that the bump in the transmission exist only in TRX. How did the residual frequency noise cause
the intensity noise of the transmission? One way is the PDH offset.

Anyway, Rana pointed out that IMC WFS QPDs had large spot offsets. Rana went to the AS table and fixed the WFS spot centering.
This actually removed the bump in TRX although we still don't know the mechanism of this coupling.

The bump at 30Hz was removed. However, the ASS issue still remains.

11312   Tue May 19 17:03:34 2015 KojiUpdateCDSMXstream restart script working (beta)

AutoMX is resetting mx_stream every 5 minutes. Basically everytime AutoMX is called,
it resets mx_stream. Is the mx_stream stalling such often? Or the script is detecting false alerms?

> tail -200 /opt/rtcds/caltech/c1/scripts/cds/autoMX.log

Tue May 19 16:43:01 PDT 2015 LSC - FB bad. Runnning restart:  * Stopping mx_stream ...                                                 [ ok ]  * Starting mx_stream ...                                                 [ ok ] Connection to c1sus closed.  * Stopping mx_stream ...                                                 [ ok ]  * Starting mx_stream ...                                                 [ ok ] Connection to c1lsc closed.  * Stopping mx_stream ...                                                 [ ok ]  * Starting mx_stream ...                                                 [ ok ] Connection to c1ioo closed.  * Stopping mx_stream ...                                                 [ ok ]  * Starting mx_stream ...                                                 [ ok ] Connection to c1iscex closed.  * Stopping mx_stream ...                                                 [ ok ]  * Starting mx_stream ...                                                 [ ok ] Connection to c1iscey closed. 0 Tue May 19 16:48:02 PDT 2015 LSC - FB bad. Runnning restart:  * Stopping mx_stream ...                                                 [ ok ]  * Starting mx_stream ...                                                 [ ok ] Connection to c1sus closed.  * Stopping mx_stream ...                                                 [ ok ]  * Starting mx_stream ...                                                 [ ok ] Connection to c1lsc closed. ssh_exchange_identification: read: Connection reset by peer  * Stopping mx_stream ...                                                 [ ok ]  * Starting mx_stream ...                                                 [ ok ] Connection to c1iscex closed.  * Stopping mx_stream ...                                                 [ ok ]  * Starting mx_stream ...                                                 [ ok ] Connection to c1iscey closed. 0 Tue May 19 16:53:01 PDT 2015 LSC - FB bad. Runnning restart:  * Stopping mx_stream ...                                                 [ ok ]  * Starting mx_stream ...                                                 [ ok ] Connection to c1sus closed.  * Stopping mx_stream ...                                                 [ ok ]  * Starting mx_stream ...                                                 [ ok ] Connection to c1lsc closed.  * Stopping mx_stream ...                                                 [ ok ]  * Starting mx_stream ...                                                 [ ok ] Connection to c1ioo closed.  * Stopping mx_stream ...                                                 [ ok ]  * Starting mx_stream ...                                                 [ ok ] Connection to c1iscex closed.  * Stopping mx_stream ...                                                 [ ok ]  * Starting mx_stream ...                                                 [ ok ] Connection to c1iscey closed.

11323   Sun May 24 14:45:02 2015 KojiHowToGeneralHow to launch StripTools at specified locations

## LLO Operator Tips:

koji.arai@cr9:/opt/rtcds/userapps/trunk/asc/l1/scripts/initial_alignmentcat autostart_strips.sh  #!/bin/bash # Baffle window setup 1500x480 StripTool -xrm 'StripTool.StripGraph.geometry:1500x470+0+24' /opt/rtcds/userapps/trunk/asc/l1/scripts/initial_alignment/baffle_pd.stp & sleep 1 # DC signals setup StripTool -xrm 'StripTool.StripGraph.geometry:1500x470+0+470' /opt/rtcds/userapps/trunk/asc/l1/scripts/initial_alignment/dc_signals.stp & sleep 1 # WFS prx mich sry setup StripTool -xrm 'StripTool.StripGraph.geometry:1500x470+0-24' /opt/rtcds/userapps/trunk/asc/l1/scripts/initial_alignment/wfs_prx_mich_sry.stp & sleep 1 exit 11332 Thu May 28 17:00:04 2015 KojiUpdateIOOFSS SLOW not engaged: is this intentional? I found that FSS SLOW servo is not engaged. Is this intentional test to keep the NPRO temp constant? This is making the FSS Fast unhappy (~ -7.5V right now). 11334 Thu May 28 21:10:46 2015 KojiUpdateGreen LockingALS-X noise hunting I have been looking at the X-end ALS setup. I was playing with the control bandwidth to see the effect to the phase tracker output (i.e. ALS err). For this test the arm was locked with the IR and the green beat note was used as the monitor. From the shape of the error signal, the UGF of the green PDH was ~10kHz. When I increased the gain to make the servo peaky, actually the floor level of the ALS err became WORSE. I did not see any improvement anywhere. So, high residual error RMS cause some broadband noise in the ALS??? This should be checked. Then when the UGF was lowered to 3kHz, I could see some bump at 3kHz showed up in the ALS error. I didn't see the change of the PSD below 1kHz. So, more supression of the green PDH does not help to improve the ALS error? Then, I started to play with the phase tracker. It seems that someone already added the LF booster to the phase tracker servo. I checked the phase tracker error and confirmed it is well supressed. Further integrator does not help to reduce the phase tracker error. For the next thing I started to change the offset of the phase tracker. This actually changes the ALS error level! The attached plot shows the dependence of the ALS error PSD on the phase tracker output. At the time of this measurement, the offset of -10 exhibited the best noise level. This was, indeed, factor of 3~5 improvement compared to the zero offset case below 100Hz. I'm afraid that this offset changes the beat frequency as I had the best noise level at the offset of -5 with a different lock streatch. We should look at this more carefully. If the beat freq changes the offset, this give us another reason to fix the beat frequency (i.e. we need the frequency control loop. = Today's ALSX error would have not been the usual low noise state. We should recover the nominal state of the ALS and make the same test = 11337 Fri May 29 12:49:53 2015 KojiUpdateComputer Scripts / ProgramsChiara Backup Hiccup In fact, the file access is supposed to be WAY faster now than in the RAID case. As noted in ELOG 9511, it was SCSI-2(or 3?) that had ~6MB/s thruput. Previously the backup took ~2hours. This was improved to 30min by SATA HDD on llinux1. I am looking at /opt/rtcds/caltech/c1/scripts/backup/rsync.backup.cumlog In fact, this "30-min backup" was true until the end of March. After that the backup is taking 1h~1.5h. This could be related to the recent NFS issue? 11338 Fri May 29 15:12:39 2015 KojiUpdateComputer Scripts / ProgramsChiara Backup Hiccup Actual data 11353 Thu Jun 11 19:40:59 2015 KojiUpdateVACVacuum comp. rebooted The serial connections to the vacuum gauges were recovered by rebooting c1vac1 and c1vac2. Steve claimed that the vacuum screen had showed "NO COMM" at the vacuum pressure values. The epics connection to c1vac was fine. We could logged in to c1vac1 with telnet too although c1vac2 had no response. After some inspection, we decided to reboot the slow machines. Steve manually XXXed YYY valves (to be described) to prepare for any possible unwanted switching. Initially Koji thought only c1vac2 can be rebooted. But it was wrong. If the reset button is pushed, all of the modules on the same crate is reset. So everything was reset. After ~3min we still don't have the connection to c1vac1 restored. We decided to another reboot. This time I pushed c1vac1 reset button. After waiting about two minutes, the ADCs started to show green lights and the switch box started scanning. We recovered the telnet connection to c1vac1 and epics functions. c1vac2 is still note responding to telnet, and the values associated with c1vac2 are still blank. Steve restored the valves and everything was back to normal. 11386 Wed Jul 1 09:33:31 2015 KojiUpdateGeneralShutters closed, watch dogs disabled for the RCG upgrade I closed the PSL/GREEN shutters and shut off the LSC feedback/SUS watch dogs at 9AM PDT, to allow Jamie to start his disruptive work. 11394 Tue Jul 7 23:26:19 2015 KojiUpdateCDSAttempt to list CDS issues As Jamie succeded to realize somewhat workable condition of the 40m CDS, I tried to list the obvious CDS issues so that we can attack them one by one. 1. c1cal is constantly time-outing now (t>60usec). c1sus is close to it (t=56~57us) 2. We should check the trends of the CPU meters ("C1:FEC-**_CPU_METER"). In fact this should be listed in the summary pages in a new CDS tab. 3. Probably this is related to 1): c1lsc is constantly showing IPC error (bit0 = shmem). C1LSC_IPC_STATUS.adl is telling that this is coming from the IPC error between c1lsc and c1cal. ("C1:CAL-LSC_SENSMAT_OSC_****"). This information is found by opning C1LSC_GDS_TP.adl screen and click RT NET STAT button next to the IPC error status. 4. We wonder how the RFM access is accelerated or decelerated by this upgrade. 5. We need tests to see if the time delays of the models/IPCs are still reasonable. 6. LSC Overviw screen has a small digest of the CDS status. Now there are many white boxes that correspond to the channels "C1:FEC-**_DIAG1". 7. All realtime systems have default (0 or 1) epics channel values (i.e. gains, FM switches, matrices, etc). Need burtrestores. 8. I tried to burtrestore the models but burtgooey indicated there are some errors. 9. Detailed check of the snapshot files comparing snapshot files in /opt/rtcds/caltech/c1/burt/autoburt/snapshots/2015/Jul/7/19:07 and /opt/rtcds/caltech/c1/burt/autoburt/snapshots/2015/Jun/1/19:07 : • c1alsepics shows bunch of volatile channels to be snapshot. It seems that all of the static epics channels are missing in the snapshot file. Is this related to the current omission of the slow data acquisition? => No actually this must be the modification of the ALS model to accommodate the ALS in the LSC model for the new ALS setup. • c1lscepics was checked indeed slow channels were properly snapshot. So what was the problem in burting??? • I made a simple csh script to restore the snapshots one by one while collecting the error messages. This script is located as /users/koji/150707/burtrevert.sh •  #!/bin/csh echo 'This script restores all of the snapshot files found in'argv[1] '.' echo 'Are you sure? y/n' set ans = $< set ANS = echo$ans | tr "[:upper:]" "[:lower:]"  if ($ANS == y) then foreach fname ($argv[1]/*epics.snap)     echo ''     echo '#################################'     echo $fname echo '#################################'  burtwb -f$fname     end else     echo "exiting..." endif

•  Now I ran the command
./burtrevert.sh /opt/rtcds/caltech/c1/burt/autoburt/snapshots/2015/Jun/1/19:07 &>burt.log
This lists up the missing channels. The zipped log is attached to this entry.
• Burting old snapshot always crashes the RT process "c1sus" (not the c1sus host). If I use the newly generated snapshot today,
the process does not crash. The process halts at the cycle time of 74us (>60us). I left the process crashed so that we can take a new snapshot with the matrix numbers filled. Once we have the correct snapshot, we don't need to worry about this crash. Let's see.
• c1sus still crashes with the new burt file. Theremust be a trigeer that makes the model frozen. We need to split the burtfile into pieces
to figure out which line causes the halt.
11399   Thu Jul 9 16:39:03 2015 KojiConfigurationGeneralHow to set up your own summary page environment on the LDG cluster

Here is the summary of my investigation how to set up my own "summary page" environment on the LDG (LIGO Data Grid) cluster.

Here all albert.einstein must be replaced with your own LIGO.ORG user name.

1. Obtain LDAS cluster account

Run the following from any of the terminal and use your LIGO.ORG credential
ssh albert.einstein@ssh.ligo.org
You will be suggested to visit a particular web site. Fill the form on the web site and wait for the approval e-mails.

2. Use LDG SSH login portal

Once you received the approval of the account, you should be able to log in to the system. Type the following command again from your local terminal
ssh albert.einstein@ssh.ligo.org
You are asked to select the site and machines. Select 2- CIT and b. ldas-pcdev1, c. ldas-pcdev2, or d. ldas-pcdev3.

3. Setup bash environment

Setting up the python library path is very important for the proper processing.

Here is my setup for .bash_profile

 # .bash_profile # Get the aliases and functions if [ -f ~/.bashrc ]; then     . ~/.bashrc fi if [ -f ~/.profile ]; then         . ~/.profile fi # User specific environment and startup programs PATH=$PATH:$HOME/bin export PATH # So that ssh will work, take care with X logins - see .xsession [[ -z $SSH_AGENT_PID && -z$DISPLAY ]] &&   exec -l ssh-agent $SHELL -c "bash --login" and .bashrc  # .bashrc # Source global definitions if [ -f /etc/bashrc ]; then . /etc/bashrc fi # Set Python environment (based on gpwy-env script) # clean path environment variable of duplicate entries cleanpath() { if [[ -z "$1" ]]; then        $1=PATH fi # map to local variable local badpath=$(eval echo \1)     badpath=${badpath%%:} # remove duplicates badpath="$(echo "${badpath}" | awk -v RS=':' -v ORS=":" '!a[$1]++')"     # remove trailing colon     badpath=${badpath%%:} # reset variable and export eval$1=${badpath} eval export$1 } # set PATH cleanpath PATH cleanpath PYTHONPATH PATH=${HOME}/.local/bin:${PATH} PYTHONPATH=${HOME}/.local/lib/python2.6/site-packages:${PYTHONPATH}

The order of cleanpath and PYTHONPATH= is important as we want to use the local library installation before anything kicks in.

4. Install required Python libraries

Run the following lines with this order so that they are installed in your "~/local"

 # PIP installation wget https://bootstrap.pypa.io/get-pip.py python get-pip.py --user # numpy, scipy, distribute, matplotlib, astropy, importlib installation pip install numpy --upgrade --user pip install scipy --upgrade --user pip install distribute --upgrade --user pip install matplotlib --user --upgrade pip install astropy --upgrade --user pip install importlib --user --upgrade # We need to use dev branch of gwpy to run gwsumm propery cp -r /home/detchar/opt/gwpysoft/lib/python2.6/site-packages/gwpy* ~/.local/lib/python2.6/site-packages/ # gwsumm installation pip install --user git+https://github.com/gwpy/gwsumm

5. Setup summary pages for the 40m

Copy summary page setting from Max's directory.

cp -r ~max.isi/summary ~/

And make temporary directory for the summary pages.

mkdir /usr1/albert.einstein/summary

6. Modify typos in gw_summary_custon

Use your own editor to fix typos

emacs ~/summary/bin/gw_daily_summary_custom

replace max.isi to albert.einstein
change summary40m -> summary

Now the installation is done. From here, the description is for the routine procedure.

7. Run your summary page code

Run Kerberos authentication
kinit albert.einstein@LIGO.ORG

Run a summary page code for a specific date (e.g. for Jul 1st, 2015)
bash ${HOME}/summary/bin/gw_daily_summary_custom --day 20150701 The result can be checked under https://ldas-jobs.ligo.caltech.edu/~albert.einstein/summary/ https://ldas-jobs.ligo.caltech.edu/~albert.einstein/summary/day/20150701/ Rerun a code for a specific page. This requires the page structure already exists. The red texts should be modified depending on what ini file you want to run for what day. /home/albert.einstein/.local/bin/gw_summary day --on-segdb-error warn --verbose --output-dir . --multi-process 20 --no-html --ifo C1 --archive C1EVE 20150630 --config-file /mnt/qfs2/albert.einstein/public_html/summary/etc/defaults.ini,/mnt/qfs2/albert.einstein/public_html/summary/etc/c1eve.ini This command can actually be found in https://ldas-jobs.ligo.caltech.edu/~albert.einstein/summary/gw_summary_pipe.sh 8. Some useful command To check which python library is used python -c 'import gwpy; print gwpy.__file__' To list installed python libraries and versions pip list This should return the list like the following. ... astropy (1.0.3) ... gwpy (0.1b1.dev121) gwsumm (0.0.0.dev854) ... matplotlib (1.4.3) ... numpy (1.9.2) ... scipy (0.15.1) ... 11461 Wed Jul 29 21:40:39 2015 KojiSummaryCDSStatus of the frame data syncing The trend data hasn't been synced with LDAS since Jul 27 5AM local. 40m: controls@nodus|minute > pwd /frames/trend/minute controls@nodus|minute > ls -l 11222 | tail total 590432 -rw-r--r-- 1 controls controls 35758781 Jul 29 11:59 C-M-1122228000-3600.gwf -rw-r--r-- 1 controls controls 35501472 Jul 29 12:59 C-M-1122231600-3600.gwf -rw-r--r-- 1 controls controls 35296271 Jul 29 13:59 C-M-1122235200-3600.gwf -rw-r--r-- 1 controls controls 35459901 Jul 29 14:59 C-M-1122238800-3600.gwf -rw-r--r-- 1 controls controls 35550346 Jul 29 15:59 C-M-1122242400-3600.gwf -rw-r--r-- 1 controls controls 35699944 Jul 29 16:59 C-M-1122246000-3600.gwf -rw-r--r-- 1 controls controls 35549480 Jul 29 17:59 C-M-1122249600-3600.gwf -rw-r--r-- 1 controls controls 35481070 Jul 29 18:59 C-M-1122253200-3600.gwf -rw-r--r-- 1 controls controls 35518238 Jul 29 19:59 C-M-1122256800-3600.gwf -rw-r--r-- 1 controls controls 35514930 Jul 29 20:59 C-M-1122260400-3600.gwf LDAS Minute trend: [koji.arai@ldas-pcdev3 C-M-11]$ pwd /archive/frames/trend/minute-trend/40m/C-M-11 [koji.arai@ldas-pcdev3 C-M-11]$ls -l | tail -rw-r--r-- 1 1001 1001 35488497 Jul 26 19:59 C-M-1121997600-3600.gwf -rw-r--r-- 1 1001 1001 35477333 Jul 26 21:00 C-M-1122001200-3600.gwf -rw-r--r-- 1 1001 1001 35498259 Jul 26 21:59 C-M-1122004800-3600.gwf -rw-r--r-- 1 1001 1001 35509729 Jul 26 22:59 C-M-1122008400-3600.gwf -rw-r--r-- 1 1001 1001 35472432 Jul 26 23:59 C-M-1122012000-3600.gwf -rw-r--r-- 1 1001 1001 35472230 Jul 27 00:59 C-M-1122015600-3600.gwf -rw-r--r-- 1 1001 1001 35468199 Jul 27 01:59 C-M-1122019200-3600.gwf -rw-r--r-- 1 1001 1001 35461729 Jul 27 02:59 C-M-1122022800-3600.gwf -rw-r--r-- 1 1001 1001 35486755 Jul 27 03:59 C-M-1122026400-3600.gwf -rw-r--r-- 1 1001 1001 35467084 Jul 27 04:59 C-M-1122030000-3600.gwf 11465 Thu Jul 30 11:47:54 2015 KojiSummaryCDSStatus of the frame data syncing Today it was synced at 5AM but that was all. 40m: controls@nodus|minute > pwd /frames/trend/minute controls@nodus|minute > ls -l 11222|tail -rw-r--r-- 1 controls controls 35521183 Jul 29 21:59 C-M-1122264000-3600.gwf -rw-r--r-- 1 controls controls 35509281 Jul 29 22:59 C-M-1122267600-3600.gwf -rw-r--r-- 1 controls controls 35511705 Jul 29 23:59 C-M-1122271200-3600.gwf -rw-r--r-- 1 controls controls 35809690 Jul 30 00:59 C-M-1122274800-3600.gwf -rw-r--r-- 1 controls controls 35752082 Jul 30 01:59 C-M-1122278400-3600.gwf -rw-r--r-- 1 controls controls 35927246 Jul 30 02:59 C-M-1122282000-3600.gwf -rw-r--r-- 1 controls controls 35775843 Jul 30 03:59 C-M-1122285600-3600.gwf -rw-r--r-- 1 controls controls 35648583 Jul 30 04:59 C-M-1122289200-3600.gwf -rw-r--r-- 1 controls controls 35643898 Jul 30 05:59 C-M-1122292800-3600.gwf -rw-r--r-- 1 controls controls 35704049 Jul 30 06:59 C-M-1122296400-3600.gwf controls@nodus|minute > ls -l 11223|tail total 139616 -rw-r--r-- 1 controls controls 35696854 Jul 30 08:02 C-M-1122300000-3600.gwf -rw-r--r-- 1 controls controls 35675136 Jul 30 08:59 C-M-1122303600-3600.gwf -rw-r--r-- 1 controls controls 35701754 Jul 30 09:59 C-M-1122307200-3600.gwf -rw-r--r-- 1 controls controls 35718038 Jul 30 10:59 C-M-1122310800-3600.gwf LDAS Minute trend: [koji.arai@ldas-pcdev3 C-M-11]$ pwd /archive/frames/trend/minute-trend/40m/C-M-11 [koji.arai@ldas-pcdev3 C-M-11]\$ ls -l |tail -rw-r--r-- 1 1001 1001 35518238 Jul 29 19:59 C-M-1122256800-3600.gwf -rw-r--r-- 1 1001 1001 35514930 Jul 29 20:59 C-M-1122260400-3600.gwf -rw-r--r-- 1 1001 1001 35521183 Jul 29 21:59 C-M-1122264000-3600.gwf -rw-r--r-- 1 1001 1001 35509281 Jul 29 22:59 C-M-1122267600-3600.gwf -rw-r--r-- 1 1001 1001 35511705 Jul 29 23:59 C-M-1122271200-3600.gwf -rw-r--r-- 1 1001 1001 35809690 Jul 30 00:59 C-M-1122274800-3600.gwf -rw-r--r-- 1 1001 1001 35752082 Jul 30 01:59 C-M-1122278400-3600.gwf -rw-r--r-- 1 1001 1001 35927246 Jul 30 02:59 C-M-1122282000-3600.gwf -rw-r--r-- 1 1001 1001 35775843 Jul 30 03:59 C-M-1122285600-3600.gwf -rw-r--r-- 1 1001 1001 35648583 Jul 30 04:59 C-M-1122289200-3600.gwf

11466   Thu Jul 30 13:34:52 2015 KojiUpdatePEMY sesimostation is back on

Please check the spectra. If something is wrong, please swap the cables between X and Y in order to see if the cable is still the issue. I believe the cable was nicely made as I carefully checked the connection twice or more during and after the soldering work.

11475   Sat Aug 1 20:46:29 2015 KojiUpdatePEMX seismo station short cable removed

## OMG

11506   Fri Aug 14 12:10:08 2015 KojiUpdatePEMGur interface box is wonky

Let's dismantle the I/F unit from the rack and connect the cable with the lid open.
We need to trace the signal.

11509   Fri Aug 14 23:49:34 2015 KojiSummaryGeneralB&K Shaker fixed

I fixed a shaker that was claimed to be broken. I had to cut the rubber membrane to open the head.

Once it was opened, the cause of the trouble was obvious. The soldering joint could not put up with the motion of the head.

It is interesting to see that the spring has the damping layer between the metal sheets.

After the repair the DC resistance was measured. It was 1.9Ohm. The side of the shaker chassis said "3.5Ohm, Max 15VA". So it can take more than 4A (wow).

I gave 2A DC from the bench top supply and turn the current on and off. I could confirm the head was moving.

I'll claim the use of this shaker for the seismometer development.

11512   Mon Aug 17 17:48:12 2015 KojiUpdatePEMWasps obliterated maybe...

We found the same wasp in the 40m. Megan found it walking behind Steve desk!

11520   Thu Aug 20 11:31:55 2015 KojiUpdatePEMGur interface box

As reported previously, the transfer functions of the channels look fine. (i.e. All channels almost identical.)
I checked the chain from the unit input to the DAQ BNC connectors. They were all OK.

Today I have been checking the signals on the unit with the long DB37 cables connected.
I could not see anything on the Gur2 channels on the board. I looked at the DB37 for Gur2 and felt something is wrong.

I opened the housing of the cable and realized that all the pins are not fully inserted.
The wires were crimped improperly and prevents them to be fully inserted.

=> We need to redo the crimping to insert them.
=> We need to check the other side too.

11524   Sat Aug 22 15:48:32 2015 KojiSummaryLSCArm locking recovery

As per Ignacio's request, I restored the arm locking.

- MC WFS relief

- Slow DC restored to ~0V

- Turned off DARM/CARM

- XARM/YARM turned on

- XARM/YARM ASS& Offset offloading

11551   Tue Sep 1 02:44:44 2015 KojiSummaryCDSc1oaf, c1mcs modified for the IMC angular FF

[Koji, Ignacio]

In order to allow us to work on the IMC angular FF, we made the signal paths from PEM to MC SUSs.
In fact, there already were the paths from c1pem to c1oaf. So, the new paths were made from c1oaf to c1mcs. (Attachment 1~3)

After some debugging those two models started running. The additional cost of the processing time is insignificant.
FB was restarted to accomodate the change.

Once the modification of the models was completed, the OAF screens were modified. It seemed that the Kissel button
for the output matrix haven't been updated for the PRM ASC implementation. This was fixed as the button was updated this time.
In addition, the button for the FM matrix was also made and pasted.

11604   Wed Sep 16 03:37:06 2015 KojiSummaryGreen LockingWorkable delay line setup prepared

[Koji Gautam]

The variable delay line has been setup for practical use. The hardware and basic software are ready.

The delay time is given by [512-1-mod(C1:LSC-BO_1_0_SET, 512)]*(1/16) ns

Giving 511 (LLLL LLLH HHHH HHHH) to C1:LSC-BO_1_0_SET makes the delayline shortest (+0ns).
Giving 0 (LLLL LLLL LLLL LLLL) to C1:LSC-BO_1_0_SET makes the delayline longest (~32ns).

The SR785 was removed from the rack for our access >> Eric

DO setup

- Three CONTEC DO-32L-PE cards are found in the Yarm digital cabinet. (I brought a card from WB, but will bring it back).
- The card was installed in the C1LSC chassis.

- The models for c1x04 and c1lsc were modified to include the card. Once they are restarted, the card was recognized without problem.
The frame builder also needed to be restarted (Attachment 1&2). The changes were committed to the repository.

- MEDM screen "CDS_BO_STATUS.adl" has been modified to include the bit monitors for the new DO card. (Attachment 3)

Epics values "C1:LSC-BO_1_0_SET" and "C1:LSC-BO_1_1_SET" are hooked up to the DO block.

Cables

- The DO board has DB37(F). I made a I/F cable with a DB37(M) crimp connector, DB25 breakout board, and a ribbon cable.
Pin 1 is connected to pin 14 of the DB25 (GND of the delayline circuit).
Pin 2~10 are connected to pin 1~9 of the DB25 (Switch 1~9 of the delayline circuit)
Pin 18 is connected to X01 (external = spare) (Attachment 4)

- [CONFESSION] A bench +15V power supply was prepared to power the transisters of the DO (Attachment 6). The hot side is connected to X01 (not connected to the DB25),
and the cold side is connected to pin 14 of the DB25. Once we find this is a useful setup we need to make a dedicated interface unit to convert DB37
into DB25 (and provide more connectivities).

- A DB25 M-F cable was installed on the cable tray above the LSC racks.

Delay line unit

- The delay line box was mounted on 34H of the LSC analog rack (Attachment 5).

- The side cross connect power supply was not available (to be described later). Therefore we decided to use the same +15V supply as the one for the DO card.

- Checked the functionarity of the local switches using a function generator @30MHz and the front panel switches. The maximum (~32ns) delay was confirmed.
(Just not enough to have 360 deg shift).

- Now the delay line function was tested with the front panel swicth at "ext". We confirmed that the delay time changes with the number given to C1:LSC-BO_1_0_SET.

What we need further

- Implement delay time slider control (511 = 0ns, 0 = 31.94ns). The delay time is given by
[512-1-mod(C1:LSC-BO_1_0_SET, 512)]*(1/16) ns

- Some independent RF issues I found. (Next entry)

11605   Wed Sep 16 03:44:18 2015 KojiUpdateLSCRF micky mouse

1. POP110 RF amps are powered from the cross connect. But that +15V block has GND connections that are not connected to the ground.
i.e. The ground potential is given by the signal ground. (Attachment 1)

This is caused by the misuse of the DIN connector  blocks. The hod side uses an isolated block assuming a fuse is inserted.
However, the ground sides also have the isolated blocks

2. One of the POP110 RF cable has a suspicious shiled. The rigidity of the cable is low, suggesting the broken shield. (Attachment 2)

11614   Thu Sep 17 19:42:43 2015 KojiUpdateLSCRF micky mouse - dodgy DIN connector blocks fixed

1. The delay-line box is now hooked up to the cross connect +15V supply.

2. The broken RF cable was fixed.

## It is actually the POP22 cable. Therefore, we might see significant change of the signal size for POP22. Be aware.

RG405 + SMA connector rule

- Don't bend the cable at the connector.

- Always use a cap on the connector. It is a part of the impedance matching.

- Use transparent shrink tube for strain relieving and isolation. This allow us to check the condition of the shield without removing the cover.

11672   Thu Oct 8 13:13:20 2015 KojiUpdateLSCDRFPMI Progress

Please clarify: I wonder if you were at the zero offset for CARM and DARM or not. I am 25% excited right now.

11674   Thu Oct 8 16:48:23 2015 KojiUpdateLSCDRFPMI Progress

Awesome

11680   Fri Oct 9 14:50:18 2015 KojiUpdateLSCALS plant shape

ALS is the comparison of the PSL laser freq vs the end laser freq that is locked to the arm cavity resonant freq

On the other hand, the AS55 PDH is the comparison of the PSL laser freq after the IMC vs the arm cavity resonant freq. Here the PDH signal involves the arm cavity pole.

In total you observe the difference by the IMC cav pole + the arm cav pole.

11689   Wed Oct 14 16:53:22 2015 KojiUpdateGeneralNon inverting buffer for SR560

Eric needed a buffer to drive low input impedance (~130Ohm) of his pomona box, I quickly made a non-iverting buffer with G=+10. The DC power is obtained from the back of SR560. It uses 1.02K and 9.09K
to have the gain of ~10. The chip is OP27. In fact this limits the output swing to be +/-5V for the load resistance of 130Ohm. Eric thinks this is enough. If we need more, we need to swap the chip.

As SR560s tend to saturate too quickly, it would be very useful to have this kind of kit in all the labs
once it is packed in a box.

11693   Thu Oct 15 10:59:12 2015 KojiUpdateLSCDRFPMI Locked for 20 sec

## Great job! Many thanks Eric, Gautam, and all the current and past colleagues for your tremendous contributions to bring the 40m to this achievement.

11710   Fri Oct 23 19:27:19 2015 KojiUpdateCDSFrequency counting - workable setup prepared

It is a nice scan. I'm still thinking about the equivalence of the moving average and the FIR low pass that I have mentioned in the meeting.

Anyways:

I'm confused by the plot. The bottom axis says "green beat frequency".
If you scan the IR laser frequency by df, you get 2*df shift of the green beatnote. You need to have this factor of two somewhere.
If you are looking at the IR beat freq, just the label is not correct. (I believe this is the case.)

Accepting the rather-too-low finesse of 363 (nominally 450), the total round trip loss is said to be 0.0173.
If we subtract the front transmission of 1.38% (and ignoring the transmission loss from the ETM),
the round trip loss is 3500ppm. Is this compatible with the following elog?
http://nodus.ligo.caltech.edu:8080/40m/11111
In fact, I'm afraid that the loss number in the above elog 11111 was not correct by a factor of 10.
Then, if so, can we believe this high loss number? (Nominally we expect ~100ppm loss per round trip...)

ELOG V3.1.3-