Starting CP3 fill. LLCV enabled. LLCV set to manual control. LLCV set to 50% open. Fill completed in 2460 seconds. TC B did not register fill. LLCV set back to 16.0% open.
Starting CP4 fill. LLCV enabled. LLCV set to manual control. LLCV set to 70% open. Fill completed in 654 seconds. TC A did not register fill. LLCV set back to 41.0% open.

I was looking at the time series for OpLevs, when I came across the curious case of ITMX glitching every 6 seconds (see attached figure). Not sure why it would be doing this, but certainly should be investigated/fixed. As far as I can tell, it is the only one of the OpLevs doing this. I went backwards in time to see when this started; it's been around since at least the start of ER10.

The new FMCS IOC (BacNET interface) was down for about 30 minutes while we investigated a routing issue. It will be quickly restarted later this morning to run it within a screen session.

Evan G., Sheila D.

After disconnecting the EY OpLev fiber so that no light enters the vacuum, see LHO aLOG 35774, we have not observed any glitching around the 30 Hz region as compared to previous days. The attached Omicron spectrogram shows no indication of these glitches compared to previous days (for comparison, see the previous day here).

Our speculation is that the coupling to h(t) is caused by the changing radiation pressure as the OpLev mode hops, but the best way to confirm this is to put the OpLev light on a PD so that we can monitor the OpLev laser glitches and also see no corresponding glitch in h(t). This would eliminate some other electromagnetic coupling as a possible mechanism for this glitch pathway.

We are starting with some ASC measurements and OMC jitter. 

TITLE: 04/26 Owl Shift: 07:00-15:00 UTC (00:00-08:00 PST), all times posted in UTC
STATE of H1: Observing at 65Mpc
INCOMING OPERATOR: Jim
SHIFT SUMMARY:

Nice quiet shift with H1 locked for 12.5+hrs with decent range hovering around 66Mpc.
LOG:

• 13:43-14:43 GRB Stand Down (confirmed between sites)

H1 locked for almost 9hrs with steady range hovering around 66Mpc.  Low winds & otherwise quiet seismically.

TITLE: 04/26 Owl Shift: 07:00-15:00 UTC (00:00-08:00 PST), all times posted in UTC
STATE of H1: Observing at 67Mpc
OUTGOING OPERATOR: Patrick
CURRENT ENVIRONMENT:
    Wind: 12mph (& dropping?)
    Primary useism: 0.02 μm/s
    Secondary useism: 0.08 μm/s (below 50 percentile)
QUICK SUMMARY:

Sounded like an extensive Maintenance Day today, and Patrick gave me a rundown of how it went and a few lingering items to watch for.

H1 currently locked for over 5hrs with a nice range of 67Mpc which is better than last night.  L1 was down but now we are double-coincident again.  

• Request to reboot nucs from Carlos
• Ignore oplev DIAG messages since we are not using them due to glitching
• LVEA might not have been swept (lights off, and Patrick checked wifi points)

TITLE: 04/26 Eve Shift: 23:00-07:00 UTC (16:00-00:00 PST), all times posted in UTC
STATE of H1: Observing at 68Mpc
INCOMING OPERATOR: Corey
SHIFT SUMMARY:

Nutsinee covered the first hour or so of my shift while I finished up work on the FMCS IOC changes.

I'm afraid I am not certain if the LVEA has been swept. I do know that the WAP and FLIR cameras are off.

I spent a considerable amount of time damping the ITMY bounce and roll modes with Sheila's help.

Greg helped me verify that the calibration code was running after I went into observing.

At one point while attempting to lock the ETMX RMS WD tripped. I reset it.

The verbal alarms script crashed when I set the intention bit to observing. I restarted it.

I had to accept some minor SDF differences to go into observing. A screenshot of these is attached to the mid shift summary.

The ops_auto_alog.py script does not return from attempting to get data when run for the shift transition log. I suspect an NDS issue.

LOG:

00:28 UTC Kiwamu to CER to turn off LVEA WAP
00:31 UTC Kiwamu back
00:41 UTC Kyle back from mid stations
00:53 UTC ETMX RMS WD tripped
Stopped at ENGAGE_REFL_POP_WFS to damp ITMY bounce and roll modes.
01:59 UTC Moving on
02:20 UTC NLN. Accepted SDF differences.
02:24 UTC Running a2l.
02:33 UTC a2l done. Set intent bit to observing. Verbal alarms script crashed. Restarted it.
02:42 UTC Damped PI mode 28 by changing phase
02:54 UTC Damped PI mode 27 by changing phase

WP 6577

Dave B., Carlos P., Bubba G., John W., Patrick T.

I have migrated a subset of the EPICS channels provided by the FMCS IOC on h0epics to an IOC I created on fmcs-epics-cds. The IOC on fmcs-epics-cds connects to the BACNet server that Apollo has installed as part of the FMCS upgrade. The channels that I migrated have been taken over by this upgrade and can no longer be read out by the server that the IOC on h0epics reads from. The fmcs-epics-cds computer connects to the slow controls network (10.105.0.1) on eth0 and the BACNet network (10.2.0.1) on eth1. It is running Debian 8.

The IOC on h0epics is started from the target directory /ligo/lho/h0/target/h0fmcs (https://cdswiki.ligo-wa.caltech.edu/wiki/h0fmcs). I commented out the appropriate channels from the fmcs.db and chiller.db files in the db directory of this path and restarted this IOC. I made no changes to the files in svn.

The IOC on fmcs-epics-cds uses code from SNS: http://ics-web.sns.ornl.gov/webb/BACnet/ and resides in /home/cdsadmin/BACnet_R0-8. This is a local directory on fmcs-epics-cds. This IOC is started as cdsadmin:

> ssh cdsadmin@10.105.0.112
cdsadmin@fmcs-epics-cds: screen
Hit Enter
cdsadmin@fmcs-epics-cds: cd /home/cdsadmin/BACnet_R0-8/iocBoot/e2b-ioc/
cdsadmin@fmcs-epics-cds: ../../bin/linux-x86_64/epics2bacnet st.cmd
Hit CTRL-a then 'd'

Issues:

I came to realize during this migration that the logic behind the binary input channels is different in BACNet. In BACNet a value of 0 corresponds to 'inactive' and a value of 1 corresponds to 'active'. In the server being migrated from a value of 0 corresponds to 'invalid'. This was verified for the reverse osmosis alarm: H0:FMC-CS_WS_RO_ALARM. In the BACNet server it reads as 0 or 'inactive' when not in alarm. When John W. forced it into alarm it read as 1 or 'active'. I believe Dave has updated his cell phone alarm notifier to match this.

A similar situation exists for the state of the chiller pumps. In the server being migrated from a value of 1 appears to correspond to 'OFF' and a value of 2 appears to correspond to 'ON'. It has not been verified, but I believe in the BACNet server a value of 0 corresponds to 'OFF' and a value of 1 corresponds to 'ON'. The pump status for each building is calculated by looking at the state of the pumps. The calculation in the database for the IOC being migrated from appears to be such that as long as one pump is running the status is 'OPERATIONAL'. If no pump is running the status is 'FAILED'. I need to double check this with John or Bubba. I updated the corresponding calc records in the database for the BACNet IOC to match this.

In the server being migrated from, channels that are read by BACNet as binary inputs and binary outputs are read as analog inputs. I changed these in the database for the BACNet IOC to binary inputs and set the ONAM to 'active' and the ZNAM to 'inactive'. The alarm levels also need to be updated. They are currently set through the autoburt snapshot files that contain a separate channel for each alarm field. The autoburt request file has to be updated for the binary channels to have channels for .ZSV and .OSV instead of .HSV, .LSV, etc. So currently there is no control room alarm set for the binary channels, including the reverse osmosis alarm.

I also need to update the medm screens to take account of this change.

Also, there is an invalid alarm on the control room alarm station computer for the mid X air handler reheat temperature. Looking on the BACNet FMCS server this channel actually does appear to be genuinely invalid.

It should be noted that this BACNet IOC is a temporary install until an OPC server is installed on the BACNet server.

I would like to leave the permit for this work open until the FMCS upgrade is complete and all the channels have been migrated to the BACNet IOC.

Back to observing. Accepted attached SDF differences.

Spent a significant amount of time damping ITMY roll and bounce modes with Sheila's help. Confirmed that the calibration code is running with Greg's help.

Nutsinee covered the first hour or so of my shift while I finished migrating the BacNET FMCS channels to EPICS.

Commissioning appears to be complete. Attempting to relock.

Note: The ops_auto_alog.py script hangs while trying to get data. NDS issue?

TITLE: 04/25 Day Shift: 15:00-23:00 UTC (08:00-16:00 PST), all times posted in UTC
STATE of H1: Preventive Maintenance
INCOMING OPERATOR: Patrick
SHIFT SUMMARY:
LOG:

15:00 Chris, Bubba, Christina, Gerardo to LVEA, LVEA to laser safe
15:15 Fil to HAM3 for temp sensor work
15:30 Fred, Mike & guests out to LVEA, out 16:45
15:30 JimW, Krishna to LVEA to move cBRS
16:15 Nutsinee to EY, transitioning VEA to laser hazard
16:15 Jason to LVEA, ITMY oplev power tweak
16:30 Gerardo & Chandra to LVEA
16:30 Jason to EY
16:45 Fred, Mike & guests to EY

17:30 JeffK doing charge measurements

19:00 Krishna, Hugh to EY to recenter T240 on BRS table
19:30 LVEA to laser hazard, Nutsinee to HWSX, Jenne looking at ISCT1, out 20:00
21:30 Richard out of LVEA
21:45 JeffK starting rubbing measurement on ITMY
22:45 Gerado to both ends
22:45 Nutsinee to EX

Today I mounted the CP1 ion pump (described as "auxiliary ion pump" in ECR?) to the floor beneath CP1.  I did not make the vacuum connection at this time - TBC.  In the process, I managed to dislodge the accelerometer that is mounted on the floor with douple-sided tape.  I set it back on the tape but have no idea 1. if I damaged the unit and 2. if my re-attachment attempt is adequate.  

The LVEA crane is not in the regular parking spot. It is located above the clean room just west of the bier garden that was slated to be moved into the bier garden. We ran into some electrical issues with some of the FFUs which were resolved with the help of Richard and Fil however, we ran out of time before we were able to place the clean room in the bier garden. We will relocate the clean room at the next most opportune time. 

Gerardo, Chandra

Soft closed GV 5,7 this morning in preparation for craning over large cleanroom. Unfortunately there were some issues with the cleanroom so it didn't get moved today. We opened valves at 2:30 pm local.

Sheila, Jason, Evan G, Krishna

Mode hoping of the ETMY oplev has been showing up in hveto since April 19th, although the oplev damping is off.  The glitches that show up are definitely glitches in the sum, and the oplev is well centered, so the issue is not that the optic is moving. There is a population of DARM glitches around 30 Hz that is present on days when the oplev is glitching but not on other days.  We are curious about the coupling mechanism for these glitches and wonder if this coupling could be causing problems even when the oplev is not glitching loudly . 

Evan, Jason and I connected the monitor on the oplev laser diode power to one of the PEM ADC channels used to monitor sus rack power (we used H1:PEM-EY_ADC0_14_OUT_DQ, which was monitoring the +24V power and is channel 7 on the field rack patch pannel.  Jason can make the laser glitch by tapping it, with this test we saw clear glitches in the sum but no sign of anything in the monitor so this monitor might not be very useful.  Plugging this in means that the lid of the cooler is slightly open.

We also unplugged the fiber, so that for the time being there is no light going into the chamber from the oplev. If these glitches are coupling to DARM electromagnetically, we expect to keep seeing them in DARM.  If they were somehow coupling through the light (radiation pressure, something else), we would expect them to go away now.  One glitch that we looked at is about a 75 uW drop in the laser power on the optic.  (A=2P/(c*m*omega^2)= 3e-19 meters if all the power were at 20 Hz).  We don't really know how centered the beam is on the optic, or what the reflectivity is for the oplev laser, but it seems like radiation pressure could be at the right level to explain this.   

Using an ASD of the oplev sum during a time when the oplev is quiet, this noise is more than 3 orders of magnitude below DARM at 30 Hz.

[Vaishali, Jenne]

We used the last few minutes of commissioning time today to measure the ASC sensing matrix.  This is the first time that we have made this measurement since POPX was installed.  Per JeffK's suggestion, we turned off the 7.9Hz calibration line to avoid confusion with our 8.125Hz measurement frequency (we used his new guardian state that actually turns off all the Pcal lines, then turns them back on before we go to NLN).  

Vaishali is looking at this data to compare with previous measurements, and her Finesse model.

Recall that in the table below, elements that are grayed out have lower coherence.

Sensing Matrix, [W/rad]