TITLE: 12/12 Day Shift: 16:00-00:00 UTC (08:00-16:00 PST), all times posted in UTC
STATE of H1: Calibration
OUTGOING OPERATOR: Corey
CURRENT ENVIRONMENT:
SEI_CONF state: WINDY
Wind: 3mph Gusts, 2mph 5min avg
Primary useism: 0.05 μm/s
Secondary useism: 0.67 μm/s
QUICK SUMMARY:
TITLE: 12/12 Owl Shift: 08:00-16:00 UTC (00:00-08:00 PST), all times posted in UTC
STATE of H1: Observing at 106Mpc
INCOMING OPERATOR: Ed
SHIFT SUMMARY:
In the post PSL Chiller crash, H1 is suffering from an ailment which is giving subtle noise issues in the 15-50Hz range (but Jeff K mentions this is probably due to microseism.).
GC network appears to be down (this will affect notifications for GRBs, superevents, incoming EQs, etc.), so no wifi, phones, teamspeak, and so on and so on.
Jeff is taking H1 over at 16:00utc for some short Cal measurements approved by Keita.
LOG:
H1's back to OBSERVING.
H1 still has the noisy ailment from 15-50Hz. :(
At around 6:40am local time (14:40utc), Richard M restored the GC network.
Only the edge network (office wall ports, wireless) in the OSB was down. An ethernet switch servicing those ports crashed. Richard restarted it around 6:35AM local. No Internet connectivity lost. GC servers, CDS, LDAS remained able to ship data and connect to external services such as lvalert and GraceDB.
H1's been locked 12.0 hrs with a range hovering around 112Mpc.
DARM 15-50Hz noise continues. I scanned through subsystems via the Detchar summary pages, but didn't find a smoking gun.
High microseism seems to have flattened out at the 90th percentile.
H1 just had a lockloss at 12:35utc. Working on relocking.
During our handoff tonight, Cheryl mentioned possible DARM noise on the DARM BLRMS ndscope for mainly the 20-34Hz band. One can certainly see noise on our running DARM spectra in the front of the room where a certain region gets noisy ever few seconds (but it can also be quiet up to a half to full minute, too.) It's subtle because we do not see the range dropping noticeably. Below are a couple of examples of the noise:
Will continue investigating, and tagging DetChar for assistance.
The noise Corey is seeing here are scattered light shelves pushing in to the spectrum because the microseism ground velocity is pretty high (for LHO). See attached BLRMS of the 0.1 to 0.3 Hz band. Gabriele's got a good aLOG modelling the effect in LHO aLOG 47417 -- though the scattered light source in his aLOG is not what's going on here; that particular source has been mitigated. Unclear what the particular source is, but my impressions come from Robert -- whom may have an aLOG pending...)
TITLE: 12/12 Eve Shift: 00:00-08:00 UTC (16:00-00:00 PST), all times posted in UTC
STATE of H1: Observing at 110Mpc
INCOMING OPERATOR: Corey
SHIFT SUMMARY: locked in Observe most of the shift
LOG:
Summary: Might be having network issues here. Have not been able to get my laptop on the GC wifi. Operator TeamSpeak computer cannot log into teamspeak (tried multiple servers). Verbal Alarms might not be working for all notifications.
As far as status for H1 and CDS Network, H1 has been in Observing for the last 8.5hrs (so during this alert time). h1 looks to be noisy in the 20-34Hz band for DARM.
As I went to my office, noticed that some of the phones outside the Control Room were not operational (they say they are "Registering...").
Tagging this as FRS.
TITLE: 12/12 Owl Shift: 08:00-16:00 UTC (00:00-08:00 PST), all times posted in UTC
STATE of H1: Observing at 112Mpc
OUTGOING OPERATOR: Cheryl
CURRENT ENVIRONMENT:
SEI_CONF state: WINDY
Wind: 3mph Gusts, 2mph 5min avg
Primary useism: 0.04 μm/s
Secondary useism: 0.68 μm/s
In the last 6hrs microseism has been inching up and it is at/above the 90th percentile.
QUICK SUMMARY:
Received handoff from cheryl regarding H1, violins, PSL chiller & possible noise on DARM. We can see glitches on DMT Omega in the 20-50Hz band (and this might be noisier on the 20-34Hz DARM BLRMS on nuc23).
The only GRD User Message is for violin gains not being at Guardian values.
H1's been locked for almost 8hrs.
On a scan of the access system, the middle Roll Up Door for receiving was telling me it was unlocked (yellow), but looked fine on inspection. I toggled a Force on it (OSB 6750 Diode 172 Lock) & this cleared (green-ed) it up. Sort of similarly, EY's west exterior vestibule door was in the "stuck open" state (yellow & flash); toggled Force for it and this cleared up.
H1 in Observe.
Plots attached show chiller and PSL power trends in the last lock before the chilller swap and the same signals in the current lock:
TITLE: 12/12 Eve Shift: 00:00-08:00 UTC (16:00-00:00 PST), all times posted in UTC
STATE of H1: Observing at 111Mpc
OUTGOING OPERATOR: Ed
CURRENT ENVIRONMENT:
SEI_CONF state: WINDY
Wind: 7mph Gusts, 3mph 5min avg
Primary useism: 0.03 μm/s
Secondary useism: 0.52 μm/s
QUICK SUMMARY: H1 back in Observe! Full recovery in 16 hours is commendable.
H1 Activities: timing error in entering Observe
Tyler G., Kyle R.
As the PSL was offline for much of the day, Tyler and I used this T.O.O. to continue coring the Turbo Station anchors in the floor of the EX VEA. 3 of 4 holes and 2 of 4 adhesive inserts are completed. We left our setup (a.k.a. "mess") as we intend to finish this Tuesday during the regular maintenance period.
J. Oberling, J. Bartlett, R. Savage, R. McCarthy, C. Soike, T. Guidry, S. Lorimer
Summary
Diode chiller failed due to a broken fitting, causing enough water to leak to trigger the chiller's low water level interlock, thereby bringing the entire PSL down. We installed the backup chiller, but it also failed (crystal chiller wasn't cooling the water). To get the system back up and running again we found a push-to-connect fitting that would work on a temporary basis until we could source a replacement. After some bumps, chiefly clearing air from the system, the PSL is back up and running again.
Details (massive wall of text warning)
As reported in Corey's alog here, the PSL diode chiller failed last night. Upon arriving this morning we found that one of the plastic push-to-connect fittings on the chiller bypass valve had failed, leaking enough water to trip the chiller's low water level interlock; this caused the shutdown of the PSL last night. With the chiller off, Jeff was gently testing the extent of the failure when the entire fitting snapped off at the valve, so it was barely hanging on as it was. The attached pictures show the failed fitting:
The quickest way to get back up and running was to swap in the backup chiller, so that's what we did. Once the backup chiller was installed, we powered everything on to test; the diode chiller fired up just fine, but the crystal chiller would not flow water (it would start, but the pump wasn't pumping). Knowing that we generally see a controller failure when swapping chillers, we swapped the crystal chiller controller with a spare (we had 2). This didn't help. Next idea was that the pump was air bound; we had bled it while filling, but maybe there was still some residual air keeping the pump from operating. Turns out this was the problem. After we bled the crystal chiller pump, it fired up without issue.
We then set about setting the operating pressure and flows for the crystal chiller circuits. For future reference, this is done by using the valve installed at the back of the chiller to throttle the flow until the operating pressure (read by the pressure meters mounted to the Al plate below the filters mounted on the wall) is in the range we want, then adjusting the bypass mounted on the wall to achieve the flow we want. At that point it becomes a balancing act between these 2 valves to set the operating pressure and flow for the system. This done, we let the chiller run and observed it to make sure everything was working as intended. At this point we noticed that the crystal chiller wasn't cooling the water; the chiller setpoint is 20.0 °C, the water temperature was ~29.0 °C. Since we had swapped in a new controller, we didn't suspect it as being the problem. With the chiller running, the heat exchanger coils were checked; they should be warm if the chiller is cooling properly. They were ice cold. Jeff checked the sight glass and did not see any refrigerant flowing, indicating that the chiller needs a recharge. So now we have one chiller unit with a busted diode chiller and a backup chiller unit with crystal chiller that wouldn't chill. Wonderful.
At this point we decided that the best course of action was to find a way to replace the failed fitting, either with an exact replacement from another chiller (like our working diode chiller with the not-working crystal chiller) or with fittings we could make work. We checked the bypass valve for the backup diode chiller, and found that the fitting scheme for the valve was completely different from the in-service diode chiller. Instead of plastic fittings with clear tubing, the backup diode chiller used stainless steel fittings, flexible metal tubing, and completely different connections. At some point while manufacturing these chillers for LIGO (the in-service chiller was orignally made for H2, which is now 3IFO; the backup chiller is our original H1 chiller unit. The SNs of these chillers are only a few numbers apart), TermoTek decided to change the internal design for the bypass valve water circuit. Wonderful.
At this point we began a part hunt for fittings we could possibly use to replace the failed one. In the end, the only fitting we could find that worked was a brass 10mm push-to-connect with a male tapered thread on one end. The valve uses straight pipe thread, so we used an adapter to make it work. While brass is not ideal for use with DI water, this is a temporary fix and won't hurt the system in the interim (we are no longer running the HPO, which cooled the laser gain crystals with direct water contact and was the reason for no brass in the system). The fourth picture shows the fix. We got the in-service chiller reinstalled and back up and running, leak checked, and operating pressure and flows set. Right before I was getting ready to start the PSL, the diode chiller gave a loud knock that shook the entire unit; the diode chiller pump was air hammering. It began performing a series of loud air hammers, and while it was doing this the chiller was completely unresponsive to control from the PSL computer; we had to shut it off at the wall. We were able to set the chiller so we could turn it on and off at the control panel (it can be turned on via a number of ways (line, key, remote start), but only one at a time (can't turn on at the control panel if Remote Start is selected)). After a series of starts and stops, the pump stopped air hammering. Our suspicion here is an air bubble got caught in the pump and wouldn't clear, causing the air hammering. Once we shut the chiller off and let it sit for a few minutes the air bubble cleared and the hammering stopped.
With the hammering stopped, we let the chiller run for ~45 minutes to see if the behavior would continue; it never did, so Ed restarted the PSL as reported here, and things are up and running once again. We'll monitor the chiller over the next couple of days to ensure everything is OK. In addition, we'll source a replacement valve and get that installed in a more controlled manner during an upcoming Tuesday maintenance window, thereby removing the brass fitting from the system. We will also get a HVAC tech to look at our backup crystal chiller and get it up and running again so we have a working backup, which we do not right now.
This series of events reminds me of the failure we experienced this last February (in-service chiller failed, then the backup failed upon installation, which required us to pull a chiller from 3IFO to get the PSL running again), and seems to be a running "feature" of these chillers (we almost always have some secondary issue when working on these chillers; generally this is a failure of a chiller controller, but not always, as today and February indicate). Thankfully, we didn't have to dip into 3IFO stock this time to return the system to normal operation. This, to me, is more evidence that we need to move on from these chillers to something smaller and less complex. These chillers were designed with cooling the HPO in mind. Since we no longer run the HPO and are using amplifiers (for O3 and for the upcoming pre-O4 PSL upgrades), these chillers are massive overkill for what we actually need, and almost always end up causing massive headaches with even the simplest of failures. This has been discussed as part of the pre-O4 PSL upgrades, and is a move I wholeheartedly support.
I want to give a huge Thank You! to Richard, Chris, Tyler, and Scott for their assistance this morning, it is much appreciated.
The Crystal chiller, which was not cooling, has been moved to the Mechanical building and setup for service. The refrigeration service has been called.
I will be ordering a few spare 10mm push to connect fittings.
A big thanks to Chris, Tyler, and Scott for all their rapid response and help.
Jenne, Rahul
This morning we made some changes to the Guardian Python code for the violin mode damping settings (with respect to notify window, please see alog 53776). This window was blinking when any manual intervention was being made.
The IFO is currently unlocked due to PSL issues, hence to test our changes we ran the code in the IDLE state. We applied some gain for one (or two) of the modes and the notify window successfully notified without blinking.
The next step is to see how this works when the IFO is locked (while being in Damping_on_DC).
Later in the afternoon when the IFO was locked, Jenne and I tested the new settings (in the Guardian python code) by applying a very small gain to one of the modes. And the notify window immediately popped up and stayed there without blinking. Once the old values were restored, the notification was off.
Today's RGA scan of HAM6 is attached. Richard and Carlos configured the unit so we can monitor remotely in control room. Computer sees device, but needs a firmware update before it will cooperate.
Total pressure at HAM6 is ~3e-7 Torr and SEM voltage set to 1000V.
HAM6 RGA is now functional via remote access! I left the device ON with cooling fan running. Firmware is also updated.
Refer to alog 53864 regarding GC network issues overnight. The edge network ports do not service CDS (CDS maintains a separate switch and connection to the LHO network switching core), and that network connection nor the upstream connection to our ISP went down. Coincidental, but not causal.