Jeff K, Dave:
For each IOP model:
1) if safe.snap and OBSERVE.snap were links to separate but equal files, changed OBSERVE link to point to safe.snap file
2) if safe.snap and OBSERVE.snap were links to separate and different files, made safe.snap = OBSERVE.snap and changes OBSERVE link to point to safe.snap file
only h1iopoaf1 needed no changes. 13 IOP models matched 1) and 16 IOP models matched 2) making 30 total IOPs.
Following my discovery that h1iopiscey was not setting its DACDT to On until last week, today Jeff and I turned on h1iopiscex's DACDT.
So far its looking promising following the replacement of sw-ex-h1daq Netgear by Brocade. 24+ hours and no further CRC errors. We should know more definitely by the end of the week.
BTW: we were able to see corresponding switch port errors on the Netgear using LibreNMS plots, details in the CRC wiki page This gives us confidence that replacing the switch will fix this error.
[Georgia, Jenne]
Per WP 8256, took SEI systems down at the Corner and independently at Endy, to check the fluid accumulators' gas charge. Not one accumulator needed charging in the corner station nor at EndY. Did not attempt EndX as Pcal work was going on.
Then EndX will not take very long, maybe 1 hour and we'll do that as soon as tolerable. I'll venture that the 7 accumlators at EndX will be fine but that venture will likely be all it takes to insure that at least one will need charging so better plan on checking.
Did EndX Accumulators today. Were it not for the gas loss when I got the gauge stuck on the valve on one unit on the Pump Station, no accumulator on the site needed charging this quarter.
Closing WP 8256
TITLE: 06/26 Day Shift: 15:00-23:00 UTC (08:00-16:00 PST), all times posted in UTC
STATE of H1: Observing at 115Mpc
OUTGOING OPERATOR: Ed
CURRENT ENVIRONMENT:
Wind: 10mph Gusts, 6mph 5min avg
Primary useism: 0.02 μm/s
Secondary useism: 0.06 μm/s
QUICK SUMMARY: No immediate issues.
TITLE: 06/26 Owl Shift: 07:00-15:00 UTC (00:00-08:00 PST), all times posted in UTC
STATE of H1: Observing at 117Mpc
INCOMING OPERATOR: Patrick
SHIFT SUMMARY:
LOG:
THe 48Hz peak is "breathing" rather prominently in DARM.
12:36 UTC Latency is 7.06 secs and Trig Dur is .512 - It's a keeper.
H1 has been observing for ~ 7 hrs prior
12:54UTC15 minute stand down expired - re-enabling injections
7:45UTC After the SC outputs on Y Arm settled back down I made the swit5ch back to nominal windy
TITLE: 06/25 Eve Shift: 23:00-07:00 UTC (16:00-00:00 PST), all times posted in UTC
STATE of H1: Preventive Maintenance
INCOMING OPERATOR: Ed
SHIFT SUMMARY:
Just posted an alog summarizing post-LONG maintenance Day recovery, locking, and......MORE EARTHQUAKES! (so please see alog 50198)
LOG:
TITLE: 06/26 Owl Shift: 07:00-15:00 UTC (00:00-08:00 PST), all times posted in UTC
STATE of H1: Observing at 115Mpc
OUTGOING OPERATOR: Corey
CURRENT ENVIRONMENT:
Wind: 10mph Gusts, 7mph 5min avg
Primary useism: 0.08 μm/s
Secondary useism: 0.07 μm/s
QUICK SUMMARY:
5:47UTC (10:47pmPDT): Finally back to OBSERVING!!!
Most of tonight's shift H1 has been down (first two hours was due to today's Long Maintenance Day & after that it has been trying to lock while battling a shaking earth!).
Attempt #1:
Once we were given the keys to H1, worked on getting H1 back to OBSERVING. From 0:30-2:10utc there was an a quick alignment and then running through locking. Unfortunately, as we were going through SDF Diffs, received notification of an incoming EQ from Russia (Verbal said it was from Japan). Either way, the S&P waves were big and fast and they took us down after being at NLN for only a few dozen minutes (no observing!!). Attempted to transition to EARTHQUAKE, eventhough EQ Plot recommended LARGE_EQ_NOBRSXY (which would prob break lock!).
2:30 - 4:00UTC Waited out the EQ. Did not attempt locking!
Attempt #2:
SDF Diffs: [see 1st attachement!]
Where We Stand:
We are still rung up from the Costa Rica EQ, so Ed is going to leave H1 in EARTHQUAKE state. (our range doesn't seem to mind and has decent [& increasing] range).
During some SDF cleanup work today I noticed that the OBSERVE.snap file for h1iopiscey was modified Monday evening 17th June to permit the DAC Duotone loopback to be ON.
Following the kernel panic of h1iscey that evening, the safe.snap had turned the DACDT ON. Transitioning to the OBSERVE.snap reference raised a sdf-diff, because this file had this setting as OFF. The operator accepted the new ON setting to transition to observation mode.
This channel is not in the DAQ, but a rudimentary trend can be obtained from the hourly autoburt (see below). This shows that the DAC DT loop back has been OFF since the start of O3, transitioning to ON Monday 17jun2019.
I'll follow up with the calibration group as to what this setting should be.
I will also work on making all IOP SDFs having only a safe.snap file, with OBSERVE.snap being a symbolic link to it.
WP8247 upgrade EX DAQ network switch to Brocade (Ruckus ICX-7150-24)
Dave:
The upgrade of the switch itself went as planned. Problems arose when I activated a port on sw-ex-h1fe to connect the new switch to the ADMINLAN.
After having previously done this upgrade at EY in March of this year, the switch swap-out went smoothly. With the proper tools (e.g. right-angled screwdriver), removing the obscured rack screws went well. Removing the side of the rack (with key) and the left 'ear' on the outgoing Netgear and the incoming Brocade allowed the switches to be retracted into the rack and removed though the side.
Powering down the Netgear sw-ex-h1daq did not cause any other systems' DAQ data to go bad. Once the Brocade sw-ex-h1daq was started, all the EX front ends and the pem at MX recovered their DAQ data.
To connect the new switch to the ADMIN LAN we are currently running an ADMIN ethernet cable over from the local h1fe switch (the tagging of this VLAN from the MSR is not currently working). I converted a slow controls port to an ADMIN port (0/7) on sw-ex-h1fe for this purpose. Unfortunately this was a tagged ADMIN port (from when we used to pair front end FE-LAN and IPMI on a single port) which caused some network issues mentioned in other alogs.
I'll keep this workpermit open to cover fixing the tagging of the ADMIN LAN from the MSR to the end station switches.
Beckhoff code changes:
Daniel, Patrick, Hugh:
As reported elsewhere, corner and end station Beckhoff restarts for new code were made. The Beckhoff SDF faux-models required restarts.
Due to time constraints and other activities requiring the DAQ, these two items were postponed.
Note that this means the new slow controls channels created today are not in the DAQ.
Some more details on the switch swap:
The original single mode SFPs were moved over to the new switch. I was careful to not mix them up, so the one communicating to the corner station is in 1/3/2 and the one communicating to Mid-X is in 1/3/4. Basically the switch itself was changed, but all fibers and SFP were not.
After today's Long Maintenance Day, handed the keys to H1 at 0:30utc (5:30pmPDT). Cheryl started an alignment & that was straightforward. Then went for locking, and for the most part that was fine. At 2:10utc (7:10pmPDT) we made it back to NOMINAL LOW NOISE!
While going through some SDF diffs, H1 had a few glitches, and then 20min later, got notification of an incoming earthquake (6+ from Japan & the S/P waves were large). EQ Response plot recommeded going to the LARGE EARTHQUAKE, but since I didn't want to lose lock, I thought I would try EARTHQUAKE. Shortly after this transition or at the same time, we saw the S & P waves. Then we lost lock at 2:29utc (7:29pmPDT)!
Now it's time for lunch. And missed out a few minutes of OBSERVING! But will give it another go after the earth settles down.
3:56 (8:56pmPDT): Tried locking DRMI and could still see low frequency seismic signals in POP18 & 90. Waiting a little bit more.....but also have a 5.7 in Solomons!
Here are some MC_F spectra.
Modal analysis of the reference cavity can be found at the 40m wiki.
Here is the same spectrum with updated calibration. I neglected the 2 poles around 15kHz (Change 3 in E1900103).
The calibration for MC_F is:
In transmission of the IMC the cavity pole at 8.8kHz needs to be added.
Terra called the control room and helped me excite the mode by increasing the gain in the dampining filter for mode 24 (no excitation required). We excited the mode until the PI_ESD_DRIVER_OUT monitors were several thousand counts. Though as we increased the gain we saw some broadband noise around our mechanical modes.
We set the ESD output matrix in the butterfly configuration (diagonal quadrants out of phase) and managed to ring up the slightly-lower-frequency 10.428 kHz mode (see first attachment, red is with the mode rung up). We then switched to the drumhead configuration (diagonal quadrants in phase), and managed to ring up the same mode again. So as yet we have not distingushed which mode this really is.
They saw something similar at LLO, and looked at the downconverted transmon QPD signal to distinguish between the two modes. During the first round of excitations I had the TR_Y QPD input matrix in the drumhead configuration (all quadrants added together). For the second round of excitations we switched the matrix to a pringle-mode. I will need to look back at the data and see if we saw our down-converted excited mode in the QPD.
Second attachment is the broadband noise with the ETMY ESD bias on, as noted by Jenne above.
The beams on the TransMon QPDs are so off-center that it might be hard or not possible to identify the modes using them. On each QPD (A & B) the lowest light segment has about 20x less light on it than the highest light segment. I think you'll need to center the beams on the QPDs to use them as a diagnostic.
I had a look anyway, and only see the downconverted mode when the Transmon QPD input matrix is in the pringle configuration, suggesting that the 10.427 kHz mode is a flower mode of ETMY. (I'm not sure if this is using only one QPD or some combination of both, it's not obvious to me from the PI screen.)
We didn't manage to ring up the 10.4305 kHz mode with our ETMY excitations, perhaps it is on a different test mass?
The last plots in this thread could be misleading. Slawek has pointed out that the QPDs should see the second order optical mode, but the linewidth we saw was too narrow for this... Maybe some electronic cross-talk?