TITLE: 04/04 Owl Shift: 07:00-15:00 UTC (00:00-08:00 PST), all times posted in UTC
STATE of H1: Observing at 111Mpc
INCOMING OPERATOR: Ed
LOG:

07:01 UTC GRB notification (E328869). Confirmed with LLO.
07:31 UTC Hit diag reset for H1CALCS. Red timing error went away.
11:28 - 11:30 OTC Dropped out of observing by ITMY violin mode 6 gain. Unmonitored and set back to observing.
14:47 UTC Jeff B. to mechanical room

The violin mode guardian has turned off the gain for ITMY mode 6 and ITMX mode 8, and this appears to have caused them to start growing. I don't think I can set them back without taking us out of observing, so I am keeping an eye on them for now.

ITMY mode 6

11:28 - 11:30 UTC Dropped out of observing

I unmonitored it and went back to observing.

Is something putting these back to monitored?

Have remained in observing. No major issues to report.

TITLE: 04/04 Owl Shift: 07:00-15:00 UTC (00:00-08:00 PST), all times posted in UTC
STATE of H1: Observing at 107Mpc
OUTGOING OPERATOR: Cheryl
CURRENT ENVIRONMENT:
    Wind: 6mph Gusts, 4mph 5min avg
    Primary useism: 0.02 μm/s
    Secondary useism: 0.18 μm/s 
QUICK SUMMARY:

07:31 UTC Hit diag reset for H1CALCS. Red timing error went away.

Attached 8 hour trend of state word. Looks like it went into error around 3:22 UTC on 4/4/2019. Hitting diag reset did not take us out of observing.

TITLE: 04/04 Eve Shift: 23:00-07:00 UTC (16:00-00:00 PST), all times posted in UTC
STATE of H1: Observing at 108Mpc
INCOMING OPERATOR: Patrick
SHIFT SUMMARY: locked all shift, in and out of Observe for Pcal, calibrations, and sdf (updated)
LOG:

• 22:54 UTC - Observe
• 23:11 UTC - Commissioning - PCAL-Y
• 23:12 UTC - Observe
• 00:52 UTC - Commissioning - calibration
• 03:25 UTC - Observe
• 03:31 UTC - Commissioning - SDF
• 03:44 UTC - Observe

• 00:52:37 UTC - went out of Observe for calibrations
• completed calibration measurements using JeffK's instructions
• addressed violin modes that rang up using Rahul's instructions
• found one violin mode gain in SDF, cleared
• found 12 CALCS channels in SDF, cleared
• 03:25:38 UTC - put H1 back in Observe
• 03:31:25 UTC - H1 kicked out for a violin mode gain
• stayed out to check all violin mode gains were not monitored
• found some on all 4 optics
• 03:44:38 UTC - put H1 back in Observe, while out of Observe, no H1 changes
  • SDF snapshots attached show everything I accepted or changed to Not Monitored
  • I un-monitored all TRAMP and GAIN channels for violin modes 1 through 20, all optics, (with 99% confidence that I didn't miss one)
  • two trend plots of violins, showing ring up with excitation, and ring down after damping applied
  • dtt plots of fundamental and second harmonic violin modes
    • green is at the max, before I applied damping to the modes that had rung up and/or had damping off
    • red is after the damping had been on for a while

[Jenne, Cheryl, Rick]

I glanced at the spectrum on the wall, and noticed that the PcalY lines weren't on even though we were observing.  This is highly unusual, since the calibration lines should always be on when we are in Observation. 

I opened up the CAL_LINES overview screen (sitemap -> top cal button -> CAL_LINES) and saw that H1:CAL-PCALY_OPTICALFOLLOWERSERVOOSCILLATION was high at about 9.5 (text on the screen says that it should be below 0.01) and had a big red box around it.  I called Rick for advice, and he suggested the ol' level-0 thing to try: turn it off and on again.

Cheryl and I took the IFO out of Observing, I turned off the PcalY optical follower servo (H1:CAL-PCALY_OPTICALFOLLOWERSERVOENABLE, the Loop Enable button on the PcalY overview screen), and then turned it back on.  It seemed happy when it came back on, with the oscillation value back down to nearly zero, and also the H1:CAL-PCALY_OFS_PD_OUTMON wasn't railed flat.  The Pcal lines in the DARM spectrum came back on, so we declared the IFO fixed, and went back to Observing. 

By trending that oscillation channel, it looks like it was oscillating since about 21:48 UTC.  This is about halfway through the time that the CDS team was at EY doing some corrective maintenance on the Beckhoff system down there (alog 48209 and comments).  Daniel thinks that perhaps it could be that this was the time when some cables were unplugged or something?

In the attached screenshot, you can see that the blue trace was bad for a long-ish time, including some time when the red trace (which is the OBSERVE bit) was 1.  The tick down in the red trace is my taking the IFO out of Observe, you can see that the oscillation went away, then we immediately went back to Observe. 

The data during that time should be entirely valid and good for astrophysical searches, but note that the calibration lines were not on, so some diagnostics may report bad / funny values. 

In order to prevent this in the future, I propose that we add a "test" to DIAG_CRIT (and maybe also DIAG_MAIN) that will make a notification of a problem with either Pcal servo.  DIAG_MAIN is useful, since it is what we look at on the wall, but it is on purpose ignored by the Observe bit.  So, it needs to be in DIAG_CRIT so that we *can't* go to Observe without the Pcal lines being on and healthy.  As long as there is enough of an error message in DIAG_CRIT that an operator can find and fix the problem, then maybe it doesn't have to be replicated in DIAG_MAIN.

Rick suggests that if the servo goes into oscillation again (say, if it wasn't caused by the Beckhoff work at EY), we could perhaps try turning the gain (H1:CAL-PCALY_OPTICALFOLLOWERSERVOGAIN) down by 3dB until we get a chance to remeasure the servo loop gain next Tuesday.  Recall from alog 48206 that we measured the loop earlier today and it had a UGF of about 84 kHz with 50 degrees of phase margin, so should be plenty stable, but perhaps things 'settled' after we left? 

We made a measurement of the actuator model installed in CALCS (we have actually done this several times).  (see png attachment).

The second attached plot is a comparison of what we measured to the pyDARM model.  To make the comparison, I multiplied the individual stages by the pyDARM output actProd.calcs2gdsResidActFiltOut_NoDAQDownSample.  This is a filter which contains the corrections to the CALCS model that will be applied in GDS.  There are three versions of the calcs2gds, two versions with _NoDownSample and calcs2gdsResidActFiltOut_NoDAQDownSample_removeCALCSdelay.  

Since the measurement of the total was taken after the delay in CALCS is applied, while the individual stages are measured before the delay, so I applied calcs2gdsResidActFiltOut_NoDAQDownSample_removeCALCSdelay to the total actuation.  

These match up well with the unknown scale factor of 0.95 applied in CALCS, the only remaining thing is a small phase shift in the ESD at around 100 Hz.  

TITLE: 04/03 Eve Shift: 23:00-07:00 UTC (16:00-00:00 PST), all times posted in UTC
STATE of H1: Observing at 102Mpc
OUTGOING OPERATOR: Ed
CURRENT ENVIRONMENT:
    Wind: 24mph Gusts, 18mph 5min avg
    Primary useism: 0.13 μm/s
    Secondary useism: 0.20 μm/s
QUICK SUMMARY: H1 in Observe for a few minutes without PCAL-Y, Jenne caught this, H1 is back in Observe with PCAL-Y

• see Jenne's  alog for detail of PCAL-Y recovery, and Observe without PCAL-Y
• Rick called to check in, and is available if any issues with PCAL-Y resurface
• Observe Mode without PCAL-Y ran from 22:54:11 UTC to 23:11:51 UTC

Kara M., Philippe N., Robert S., Sharan B.

Kara has written a script that will make 6 magnetic injections in a row with the parameters that the PEM investigations so far have indicated are optimal. The script is intended to be run by operators every Tuesday morning at 7:45AM. It is called PEM_weekly_magnetic_injection.py, and it is saved in:

/opt/rtcds/userapps/release/sys/h1/scripts/

It can be run with the command

./PEM_weekly_magnetic_injection.py

The script runs for about 7 minutes, making injections through these channels in the following order:

H1:PEM-CS_GDS_0_EXC

H1:PEM-EX_GDS_1_EXC

H1:PEM-EY_GDS_1_EXC

We request that these channels remain exclusively for PEM magnetic injections for the duration of O3. At the moment, the CS channel sends its excitation to the wall-mounted coil in the LVEA (described in 43406), but the EX and EY channels have not been connected to any injection equipment yet (See 46388 for proposed magnetic injection coil plans).

In its current configuration, the script sends a 10-100Hz broadband excitation through all three channels consecutively, then a 100-1000Hz broadband excitation through all three channels consecutively (similar to Figure 4 of 47881). Upon completion, the script will say "Done with all injections."

The script can be interrupted with "Control+C", which stops any ongoing injection and cancels any remaining injections.

The script logs its injections in .txt files containing the parameters for each of the 6 injections in the following format: channel,start_time,end_time,lower_frequency,higher_frequency,gain.

These logs will be saved to

/ligo/www/www/exports/pem/WeeklyMagneticInjection/logs

TITLE: 04/03 Day Shift: 15:00-23:00 UTC (08:00-16:00 PST), all times posted in UTC
STATE of H1: Observing at 102Mpc
INCOMING OPERATOR: Cheryl
SHIFT SUMMARY:

EY issues to with PCal maintenance and then Beckhoff later in the afternoon. High winds for the past 3 or so hours greatly inhibited getting past find IR. Things finally quieted down enough to get back into the game. 16 CALCS diffs to accept everytime before Observe.
LOG:

15:58 Karen driving her vehicle to the woodshop and also to the OSB shipping area

15:59 Nichole, Elizabeth, Christina, and Betsy out to MX for property search

17:44 Betsy out to LVEA W Bay

18:07 Rick et. al are done and leaving EY

18:08 have been holding at POWER_30W for PCal work and some LVEA incursion - Obs Mods CORRECTIVE MAINTENANCE - just switched to LOCK ACQUISITION for remaider after PCal team reported finished at EY

20:34 winds in excess of 40mph. Settled on USEISM_MOD_WIND to get green arms to settle down, particularly Y-arm.

21:00 Locking is futile. Winds forecast to increase over the next couple of hours. DOWN

21:30 Fil and Marc out to EY to resolve a Beckhoff issue WP#8151.

22:00 FIl and Marc back

22:14 winds are slower and locking is commencing. fingers crossed.

22:54 Back to NLN/Observing

I've just noticed that the corner weather station is not reporting any wind speeds. It stopped reporting at 08:11 PDT Tuesday 26 March (one maintenance period ago).

Sheila, Daniel, Nutsinee

We injected broad band noise into DARM through various point in SQZ system: OPO, CLF, and LO common mode board. All injections were made after the boosts (exc A on the common mode board). Only CLF and LO injections showed up in DARM. We increased OPO error signal by two orders of magnitude and didn't see much (if anything at all). 

Only data points where witnesses (LO, CLF, OPO) and DARM sees a factor of 1.5 increase during injections get plotted. The projected ambient SQZ noise is calculated using:

ambient = witness_ref.* ( sqrt(DARM_exc.^2-DARM_ref.^2)./ sqrt(witness_exc.^2-witness_ref.^2) )

The m/rad of DARM/LO and DARM/CLF ASD ratio are only a factor of 2 different, this could suggest that wherever we inject (CLF or LO), the coupling mechanism is the same. Injecting noise through CLF added noise back to the pump laser as LO tries to suppress it (and inject that noise back to the laser). This results in the final phase difference between the green and the carrier, which is squeeze angle phase noise. On the other hand, injecting directly to LO the injection gets suppressed by the LO loop (UGF ~10kHz). The reason why CLF doesn't have much of a loop shape could be because CLF loop UGF is very low (<1kHz). 

The best suspect for the coupling mechanism is the backscatter of the IFO beam (squeezer backscattered measurement) from the OPO. As CLF noise shows up in LO loop, LO tries to suppress it by sending the noisy control signal to the laser, which then makes the laser noisy, which makes the green pump noisy. The noisy green light gets inside the OPO, induced change in OPO crystal temperature which then induced length noise via dn/dT. When leakage IFO beam sees that, it brought back to OMC DCPD noisy signal which gets mixed in the clean carrier, causing the noise we saw.