The attachment shows a new DARM spectrum after EOM driver replacement, IMC WFS offset retuning, OMC whitening, and ASC work. Compared to the previous best, the noise performance between 20 and 30 Hz is slightly worse, but elsewhere is the same or better.

Once we recover 24 W out of the PSL, we should see a bit more improvement at high frequencies.

ALL TIMES IN UTC

Arrived to find IFO beginning lock sequence after TJ did some PRMI alignment to help DRMI. It seems previous lock segments were on the average of about half a hour

• 23:09 DRMI locked.

• 23:10 Robert in the LVEA

• 23:15 Guardian hung on an OMC error. (no light on QPD)

• 23:37 noticed HEPI L4 WD SATURATION MONITOR for ITMX is at 43820cts. WD limit is set to 30000(safe)(max is 122880). WIll reset at next opportunity.

• 23:29 Dick and Wayne in the optics lab

• 23:30 Robert out of the LVEA

• 23:48 reset ITMX HEPI WD accumulator.

• 00:10 DRMI taking in excess of 16 minutes. No environmental noise observed. Tried PRMI lost lock. restored slider values back 1 hour. Re-Aligned SRM DRMI locked 1 minute later.

• 00:29 Wayne out of optics lab.

• 01:02 Stefan out to CER

• 01:16 Dick out

• -1:20 Guardian ISC_LOCK in Error at Engage ASC Part 2. Stefan cleared error

LOCK LOG:

• 23:23 Locked at NLN

  • 23:47 Lockloss at ENGAGE_ISS_SECOND_LOOP

    • DRMI ~ 13 minutes to lock

• 23:49 Began sequence

  • DRMI taking over 16 minutes.

  • 00:20 PRMI align

• 00:48 Locked at NOMINAL_LOW_NOISE

  • 0:48 Lockloss . Gabriele trying to fine tune OMC

• 00:49 Began Sequence

  • 01:07 Lockloss @ ENGAGE_ASC_PART3

• 01:08 Began Sequence

• 01:29 Locked at NOMINAL_LOW_NOISE

• 00:00 IFO still locked. 70mpc

Evening Summary:

• IFO locking in half hour segments. DRMI was taking a rather long time locking. Visiting PRMI may have improved it slightly.

• Stefan and Evan have been taking measurements and tuning for the last 5.5 hour lock.

• IFO still locked at shift change @ ~70mpc.

I made the suggestion before, but today I actually tried it:

By driving both L2 and L3 at a fixed frequency, but with a gain and phase such that their contribution cancelers in DARM, we can easily monitor (and servo, if we want) the ESD drive strength, which is expected to vary with charging.

This method has the big advantage that there are NO LARGE cal line resulting in DARM.

Here are the settings I tried:
- H1:SUS-ETMY_L2_TEST_L_EXC: drive with 300 cts at 20Hz, phase   0  deg
- H1:SUS-ETMY_L3_TEST_L_EXC: drive with 51.7cts at 20Hz, phase 134.2deg

The resulting line in DARM is only ~0.016 times the size of the line with only 1 drive. I also used the H1:SUS-ETMY_L2_DAMP_MODE7_BL filter bank to monitor the line strength. This suggests we should get on the order of 1% monitoring precision on a few second time scale - all while only producing the tiniest peak in DARM - with no up-conversion feet.

Also - since the biggest variation we see is on the microseism time scale - we should try the ESD linearization..

Using the EOM driver excitation cable that was installed yesterday we measured a driven transfer function from the 45MHz oscillator amplitude RIN to the OMC_DCPD_SUM.

Bottom line: We have a coupling of about 9e-2mA/RIN (9e-5A/RIN) coupling at 1kHz (flatish), measured at max power = 22W. (plot 1) Around 50Hz it is about 2x higher.
This coupling is the same as the (not driven) estimate from alog 20182. We also (accidentally) measured the coupling at 17W input power, and found 6e-2mA/RIN. (plot 2)

Remarks:
- This is the coupling into both DCPD's.
At 22 W, we have:
- Without injection the DCPD_NULL currently has 7.8e-8mA/rtHz, while DCPD_SUM is at 8.63e-8mA/rtHz. This suggests the extra noise is at 3.7e-8mA/rtHz.
- The coherence between DCPD_SUM and the (pre-EOM dirver) RIN read-back is 0.17, suggesting a noise floor of about 3.2e-8mA/rtHz in DCPD_SUM - close enough.
- Using the measured 9e-2mA/RIN we would need a RIN of about 4.1e-7/rtHz.

The same numbers at 17 W are:
- Without injection the DCPD_NULL currently has 7.8e-8mA/rtHz, while DCPD_SUM is at 8.25e-8mA/rtHz. This suggests the extra noise is at 2.7e-8mA/rtHz.
- The coherence between DCPD_SUM and the (pre-EOM dirver) RIN read-back is 0.1, suggesting a noise floor of about 2.5e-8mA/rtHz in DCPD_SUM - close enough.
- Using the measured 6e-2mA/RIN we would need a RIN of about 4.5e-7/rtHz.

The full template is available on the DCC: T1500441
https://dcc.ligo.org/T1500441


Related alogs: 20539, 20182, 19856

We had four lock losses from nominal low noise state this afternoon. At least three of them seem to be caused by a suddend excursion in DARM correction, which leads to a saturation of the ESD. The reason is yet unclear.

I alrady noticed yesterday that the DARM noise at the periscope peaks (200-400 Hz) was high at the beginning of the lock and then reduced over time.

The first attached plot shows a BLRMS of DARM around those peaks, starting right after reaching the low noise state. There is a clear reduction of the noise over time. The second plot shows that on a similar time scale, the OMC alignment output signal changed, mostly ANG_Y.

This seems to confirm the idea that input beam jitter at the periscope peaks is converted into intensity noise by an OMC misalignment, which changes over time.

To confirm this, I move the OMC angular loops during full lock, adding offsets of few tens of counts to the POS and ANG loops. The third plot shows the steps in the control signals. I was able to reduce the BLRMS by adding an offset of -40 to the ANG_Y loop. The fourth plot compares the DARM spectrum with (red) and without (blue) the ANG_Y offset. I should have increased the offset more. Unfortunately, I noticed that the output was hitting the limit of 300 and I stupidly increased it to 1000: but since the loop was integrating, I broke the lock since I suddenly increased the output from -300 to -1000.

However, the experiment confirms that the noise at the periscope peaks changes in amplitude with the OMC alignment, which is not optimal.

Why do I get a No Data report from DTT and dataviewer when I ask for H1:ODC-MASTER_CHANNEL_OUT_DQ ?
(dataviewer knows about second trend, but not full data...)

Log:

Times in UTC (PST)

1743 (1043) Nominal Low Noise

1752 (1052) Robert heading to Yarm  injecting dust

1810 (1110) Lockloss (A bit of seismic activity maybe?)

1828 (1128) Robert baack

1922 (1222) Nominal Low Noise

1925 (1225) Robert off to inject again

1929 (1229) Lockloss (Nothing obvious from the lockloss tool, seismic was low, wind is low, I'm not sure what caused it)

1958 (1258) Nominal Low Noise

2029 (1329) Lockloss (Terramon predicted an earthquake to arrive at 1335 PST, maybe it was off a bit)

2208 (1508) Nominal Low Noise

2214 (1514) Robert to Y arm for dust injections

2244 (1544) Lockloss

When I got here this morning, Nutsinee was reporting that the ISC_LOCK Guardian would get stuck in a few places. Here is what I found and my solutions to them:

ENGAGE_ASC_PART2

Issue: If this state is requested it would get stuck due to self.skipflag returning True. The next time that the run() method would execute, it would jump to the next condition, which would not allow for further movement in the state path when requested.

Solution: I added an extra condition to check if the self.skipflag is True, then return True. This allows for foward movement after a request is put in, while still looking for what it needs to.

ENGAGE_ASC_PART3

Issue: Not all of the logic would run from the run() method, and would get stuck in this state. There are several steps in this method that wait for a timer, do something, then set another timer and wait, before doing more. Problem was that while it would wait for the timer to run out, it would still run through the first step of the logic which included setting the timer. So the timer was set again and again.

Solution: Added a checkpoint flag (self.cp1) so the timer is not set and reset.

ENGAGE_ASC_PART(all)

Issue: No lockloss check decorator in its run() methods!!! Very dangerous, especially since these are requestable states.

Solution: Added the decorator

I hope we are not pushing the commissioners too hard and they are getting sleep...

I have tested this and it has gone through a few times, but now I'm losing lock when it get to DC_READOUT. On to the next mystery!

All time in UTC

07:00 IFO locking. Wind below 20 mph.

07:23 Dale came to notify that the Star Party is over.

08:04 Lock loss. 6.6M earthquake in Solomon Islands.

10:21 Another 5.0M earthquake in Indonesia.

11:00 Started relocking. DRMI won't lock after 10 minutes. I did the SRM misalignment and adjust the beam splitter. Everything went smoothly.

         Trouble with ENGAGE_ASC_PART3 for the rest of the night. Please refer to alog20548.

15:00 TJ arrived and tried to lock. He ran into the same problem with ENGAGE_ASC_PART3 and lost lock at REFL_IN_VACUO.

Guardian just spent 40+ minutes in ENGAGE_ASC_PART3 state. DSOFT and CSOFT kept switiching back and forth between "ON:INPUT" and "OFF:FM2". I set the ISC_LOCK to manual and skipped to the next step, lost lock shortly of course. Now I'm stuck at ENGAGE_ASC_PART2 with Guardian message "POP A has a large offset. Align by hand." but abs(ASC-POP_A_PIT_IN1) and abs(ASC-POP_A_YAW_IN1) is already less than 1 (conditions for the Guardian to move on to the next state). Still trying to figure out what to do.

The low frequency sensitivity (below 50 Hz) was coherent with CHARD PIT and YAW. I tried to retune the A2L, first using Hang's script: I had to fix a bug in the function call (number of steps passed as double instead of integer). The script ran, but made the coupling much worse. So I tried to measure by hand the couplings, injecting lines at 21 Hz. A the end of the day I got a performance similar to what I could get reverting to the A2L coefficients of one day ago. So I reverted to the old coefficients.

At 0:53 LT I reduced CHARD PIT and YAW gains by 20 dB, and as expecetd the noise got better. However, the low frequency is non stationary.

The first plot shows the situation at the beginning of a full power, low noise lock. The ISS second loop is closed. After the re-tuningof the IMC offsets, the periscope peaks are no more visible in either the in-loop or out-of-loop ISS second loop signals.  This is very good.

However, the first plot shows that the peaks were, at that time, still visible in the DARM spectrum, together with some coherence with the periscope accelerometer. So, there is residual beam jitter that does not generate intensity noise anymore, but that is transmitted to the IFO input and couples to the OMC transmitted power.

The second plot shows the situation after a while we were locked in low noise. The peaks are no more visible in DARM: so something in the IFO drifted in the right direction (probably some thermally induced drift) and now jitter is no more converted by an IFO misalignment into intensity noise. This is something interesting to investigate in the future over long lock stretches.

ALL TIMES IN UTC

• 22:01 Kiwamu out to LVEA to measure ALS Diff PLL electronics next to the PSL enclosure.

• 22:03 Gabriele has taken the mode cleaner for measurements.

• 22:35 Kiwamu out of LVEA

• 23:33 Sigg, Stefan and Robert out to the PSL to connect a cable for RIN strain measurements WP#5434. Robert will be monitoring the environmental entry procedure from outside the enclosure.

• 23:45 Kiwamu back out to the floor to measure next to the PSL again

• 01:00 Sigg, Stefan and Robert back from PSL. temps monitored by me in dataviewer. Temp dropped by a few degrees as expected 73F to 69F. Everything remains normal.

• 01:40  we’ll try locking now. Winds around 35mph

• 02:15 TCAC members start arriving for tonight’s outreach event

• 03:39 IFO fully locked at NOMINAL_LOW_NOISE

• 03:40 Lockloss. Will attempt relock at DC_READOUT

• Dale called to inform me that the Star Party is over and that some late comers may show up.

Summary:

• The beginning of the night was slow with high winds. IFO hadn’t been locked all day because of the high winds.After a couple of hours I began locking and had to contend with a troublesome Y-Arm.

• Input_Align gave me trouble so Sheila and I tried increasing gains and decreasing trigger times to no avail. So we moved on with the other alignments.

• The IFO came into full Nominal_Low_Noise lock for a few minutes. Lockloss most likely due to poor initial alignment done while the wind was still about 30mph.

• We re-did Initial Alignment.

• subsequent attempts to lock resulted in loss, mostly at Engage_ASC. Sheila edited guardian in a way that I believe breaks up the engaging of the ASC loops into different times rather than all at once.

• Shift ends in about 30 minutes. IFO locked at Nominal_Low_Noise/22.1W for about 45 minutes now @ 60mpc. Wind has calmed to about 20mph.

J. Kissel

I always forget where the StripTool templates for the wall displays live, and my first instinct is to search the aLOG for ".stp". For future me, here're there locations:
/ligo/home/ops/Templates/StripTool/
ASC_Pitch.stp
ASC_WFS_Central_1.stp
ASC_WFS_Central_2.stp
ASC_Yaw.stp
BOUNCE_ROLL_DAMP.stp
bounceroll.stp
DAMP_ROLL.stp
ETMs.stp
IFO_LOCKING.stp
IfoLock.stp
initial_alignment.stp
oldPRMIsb.stp
oplevsPIT.stp
oplevsYAW.stp
PITCH_ASC_CONTROL_SIGNALS.stp
PRC-SRC.stp
PRMIsb.stp      <<< This is what usually is displayed to show the lock acquisition process
RM-OM.stp
X-Arm.stp
Y-Arm.stp
YAW_ASC_CONTROL_SIGNALS.stp