TITLE: 07/16 Day Shift: 1430-2330 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Corrective Maintenance
INCOMING OPERATOR: Oli
SHIFT SUMMARY:
IFO is DOWN and in CORRECTIVE MAINTENANCE
A very dynamic day that I will try to sum up as best as I can. Check alogs 79102, 79164, 79167, 79160, 79178, 79156, their comments and the plethora of alogs about this OFI issue.
Context: IFO has been struggling to lock due to what we think is an OFI issue. The plan today was to test out our movement of SR3 in the +Y direction to see if we can get to NLN to the point of potentially delaying a vent to fix/replace the OFI. Here’s what happened next:
14:30 UTC (Shift Start): Tuesday Maintenance had been canceled, Sheila and I were moving the IFO up in the new SR3 +Y position but losing lock repeatedly at around ENGAGE_ASC_FOR_FULL_IFO. This happened for a few hours. Allowed maintenance activities happened (technical cleaning, HVAC stuff, NORCO delivery).
14:30 - 18:00 UTC: 3 IPA tour groups came in as expected. They went to the LVEA, which disrupted locking activities so we waited a bit until they were out.
18:26 UTC: We finally reach NLN for the first time since Friday. The range is low at around 130 MPc. Tuning, measurement and assessment of the IFO alignment begins. The alignment doesn’t look fantastic but we are NLN.
19:14 to 19:37 UTC: I take a calibration sweep by Sheila’s request since it seems that we are not well calibrated only to find out that simulines is broken and that there is no way to generate the report even for broadband on its own. Calibration team takes a look at this very briefly, confirm that the kappa c is 90% so we’re calibrated enough. Then, we discover a newer, more pressing problem.
~20:00 UTC: Keita and Sheila realize that there is only 80% of the beam power making it to sensors (table comments to alog 79160). This then took priority because it meant that should we lose lock, there could be damage to the IFO in unknown ways, including to the pressure. A quick discussion was had and commissioners agreed to manual over to ADJUST_POWER (20:31 UTC) and then slowly bring the power down until we can safely unlock the IFO. Until..
20:32 UTC: Lockloss. Sheila adjusted the power by only 1W down to 59W and we lost lock immediately. The cause for this is generally unknown but it meant we are now unlocked and need to check quickly for damage. Janos and the Vacuum team were called in to check the pressures for any glitches or spikes and thankfully, everything was okay on that front.
21:00 UTC: LVEA transitioned to LASER HAZARD per WP 11979 for SQZ work primarily.
22:00 UTC: After the SQZ work, a meeting was called to discuss next steps, specifically with respect to venting. IFO has been DOWN since then.
23:00 UTC: Prep is being done to vent, such as activating the purg
LOG:
Start Time | System | Name | Location | Lazer_Haz | Task | Time End |
---|---|---|---|---|---|---|
14:37 | FAC | Chris | EY | N | HEPA Cartridge Replacement | 15:37 |
15:03 | FAC | Karen | EY | N | Technical Cleaning | 16:08 |
15:03 | 15:03 | |||||
15:03 | FAC | Kim | EX | N | Technical Cleaning | 16:08 |
15:45 | EPO | Camilla | EX, Ctrl Room | N | IPA Tour | 17:45 |
16:02 | SUS | Jeff | LVEA, eracks | N | Take pictures | 16:06 |
16:52 | VAC | Travis | LVEA | N | Parts search, racks | 17:03 |
17:37 | FAC | Kim, Karen | FCES | N | Technical Ckeaning | 17:44 |
17:45 | FAC | Eric | FCES | N | HVAC Check | 17:45 |
17:50 | FAC | Eric | FCES | N | HVAC Check | 18:04 |
21:05 | SQZ | Sheila, Naoki, Camilla | LVEA | YES | SQZT7 Alignment References | 22:05 |
21:06 | SAF | LVEA IS LASER HAZARD | LVEA | YES | LVEA IS LASER HAZARD | 21:06 |
22:53 | PCAL | Rick, Dan, Shinko | EY | N | PCAL Tour @ EY | 01:53 |
23:24 | SEI | Jim | LVEA | N | HEPI Locking for Vent | 00:24 |
23:24 | SAF | Camilla | LVEA | YES | Taking LVEA to laser safe | 23:44 |
23:25 | OPS | Camilla | LVEA | Y | De-transition | 00:25 |
Naoki, Sheila, Camilla. WP 11979
Using the SQZ (ZM4/5/6) and SRM alignment of our last time in NLN, Naoki added two irises in the IR path of SQT7 so that we can keep store this alignment if we vent. This is the path of the SQZ beam heading to the IFO, reflected off beam divertor, to serve as a reference for the alignment which doesn't have good throughput in HAM5.
As noted in alog79128 the beam on AS_C isn’t centered in this alignment, it’s around 0.1-0.3 off center. We moved ZM4 to align to the center of AS_C (noisy as NSUM was 0.15mW), we didn't see a noticeable difference on the irises.
TITLE: 07/16 Eve Shift: 2300-0800 UTC (1600-0100 PST), all times posted in UTC
STATE of H1: Corrective Maintenance
OUTGOING OPERATOR: Ibrahim
CURRENT ENVIRONMENT:
SEI_ENV state: CALM
Wind: 9mph Gusts, 7mph 5min avg
Primary useism: 0.22 μm/s
Secondary useism: 0.07 μm/s
QUICK SUMMARY:
Sitting in IDLE, and there's currently a discussion going on about venting
There was another pressure spike in HAM6 volume this morning at ~4:28:35 am PDT. The total rise in pressure in HAM6 is 1.15E-8 Torr. This pressure rise was also seen in BSC2 (PT120B), where the total pressure rise was ~3E-10 Torr. See attached plot. Top channel is BSC2 PT120B gauge, middle plot is HAM6 (PT110) and the bottom is the IFO lock state, where -10 is equal to IDLE, so this does not correlate with any lockloss.
Looking at the RGA on the Output tube, there is a small bump in AMU 28 at the same time as the pressure spike, see 2nd attachment. The blue trace on the bottom plot is AMU28 ion current for each 5ms dwell time scan (0-100), so not a true MID scan. Using PT120B as a quick calibration for the RGA at the time just before the pressure rise (P~8E-9 Torr) , and AMU 2 & 18 ion current (Sum~8E-9 amp). Calibration is ~1 to 1. The AMU28 rise is ~2E-10 Torr. Typical HCs (41, 43, 53, 55, 57) had no significant change and similarly for argon (AMU 40), so this does not seem to be argon instability of the ion pumps.
I'd suggest that you consider a CC gauge or ion pump arc, not an argon instability.
Ibrahim, Sheila, TJ, Camilla, Naoki
Since the +/- pitch alignments of SR3 from 79103 both seem like they will not work, this morning I ran intial alignment for the +Y spot again. After running SR2 align (single bounce, 10W), the power on AS_C NSUM was 0.0219 Watts arriving in HAM6, 5% worse than the 0.023W before Friday (79101). Attached are screenshots of the AS air camera and the sliders after running initial alignment. After PRMI ASC ran, POP18 NORM was 45, POP90 NORM was 48 counts (sliders and camera in PRMI).
DRMI locked with POP18 NORM of 50 counts, so still with 15% less power than last Thursday. We have had a number of locklosses trying to get to DC readout. We saw that again a DARM Offset of 9e-5 causes the ASC to fail and causes a lockloss, so we changed the DARM offset to 6e-5, and made edits to OMC_LOCK to allow it to lock (lowered prominence in FIND_CARRIER to 5, and height to 6, threshold in OMC_LOCKED to 6 instead of 10).
We have been able to lock, with a range of 100Mpc.
Editing to add a comparison of this lock to last Thursday's lock.
The single bounce throughput is (0.219/0.023) = 95% of what it was last Thursday. The optical gain is then expected to be srt(0.95) = 0.97. Right now kappa C is reporting an optical gain of 0.907, 1 hour in to the thermalization, so significantly worse than expected. I think think that this is beyond the range of values where kappa c is a good approximation, so we need to run a calibration measurement soon.
AS_A, AS_B DC, AS_C, and OMC REFL are 86% of what they were last Thursday. Power recycling gain and arm powers are still thermalizing, but may be a bit low. OFI PD A (the one in HAM7, measures rejected beam from the TFP on the side of the OFI closer to HAM6), is lower by 5%, Camilla pointed out to me that the power on this diode changes each time that we move ZM4/5/6, so it's not very reliable for comparisons. OFI PD B, the one in HAM5 that measures the rejected beam from the first polarizer in the OFI, sees more rejected power by 17% than it did on Thursday.
We opened the AS beam diverter and captured screenshots of the image with the normal exposure of 800 and with the exposure lowered to 50.
Since we learned about the lower throughput in full lock (didn't know about that before), we're making whatever we can to assess the performance of H1 with this alignment.
However, this means that we will dump more than 10% of power spike into whatever is absorbing power in the next lock loss. I don't think this is a sustainable way to operate H1. I asked Sheila to reduce the power and unlock after we're done with noise characterization. Calibration is NOT going to be done fully as it involves fixing something that doesn't run as of now, we'll have to skip that.
Attached is a comparison of now (Jul 16) VS 8 days ago (Mon Jul 08), both ~2 hours into 60W lock.
channels (all OUT_DQ) | Tue Jul 16 | Mon Jul 08 | Now/Before |
ASC-AS_C_NSUM | 0.583 | 0.702 | 0.830 |
ASC-OMC_A_NSUM | 0.532 | 0.629 | 0.846 |
ASC-OMC_B_NSUM | 0.519 | 0.615 | 0.844 |
ASC-AS_A_DC_NSUM | 50240 | 60769 | 0.827 |
ASC-AS_B_DC_NSUM | 54311 | 66061 | 0.822 |
OMC-REFL_A_LF | 571.2 | 687.4 | 0.831 |
Same table but with a new column for our SR3 -P alignment from a 17 hour lock on May29. These values were taken the same as above.
channels (all OUT_DQ) | May 28 | Tue Jul 16 | Mon Jul 08 | Now/Before |
ASC-AS_C_NSUM | 0.595 | 0.583 | 0.702 | 0.830 |
ASC-OMC_A_NSUM | 0.571 | 0.532 | 0.629 | 0.846 |
ASC-OMC_B_NSUM | 0.538 | 0.519 | 0.615 | 0.844 |
ASC-AS_A_DC_NSUM | 52000 | 50240 | 60769 | 0.827 |
ASC-AS_B_DC_NSUM | 55383 | 54311 | 66061 | 0.822 |
OMC-REFL_A_LF | 675.6 | 571.2 | 687.4 | 0.831 |
Closes FAMIS#26000, last checked in alog78993
For the HAMs low frequency noise is reduced
For the BSCs the ETMs look different at low frequency, esp ST2__CPSINF_V{1,2,3}
IFO is in NLN and in MAINTENANCE as of 18:26 UTC (52 min lock)
With the +Y position detailed in alog 79164, we were able to achieve NLN.
Taking calibration sweeps right now.
We ran the coherence plot (instructions in LowRangeChecks wiki) for 2024/07/16 18:47 UTC with reported 132MPc, plot attached. See lots of coherence with SRCL, PRCL, MICH so we plan to re-tune these feedforwards. The CHARD coherence <15Hz isn't new but the coherence around 30Hz is, it might be coupling through the LSC loops though.
After turning SRCLFF gain down from 1.14 to 1.0, the coherence looked a lot better and the range increased to 145MPc.
We took FF measurements for SRCL, MICH and PRCL, saved to /opt/rtcds/userapps/release/lsc/h1/scripts/feedforward. Before fitting these we found we didn't like this IFO alignment (79172).
As looked at in 79117 and 78399. the OFI's temperature control changes as we power up.
In a nominal lock before this alignment change, VOLTAGEBACK changes 0.0091V and the temperature wobbles 0.0031 degC: plot.
In today's power up at the new alignment, VOLTAGEBACK changes 0.0267V and the temperature wobbles 0.0135 degC: plot. This is 3 to 4.5 times larger than usual and larger than the changes we saw May 28th/29th 78442 power-ups: 0.0458V and 0.0097degC plot.
Note that we don't understand if this is damaging at all but it makes us think that we are closer to clipping the OFI or have the beam spot in a different position in relation to the TEC/thermistor: TEC is on bottom of the OFI TGG holder (OMC side): G1902217 slide 22. Unsure location of thermistor.
CS Mains mon trend attached.
At the beheast of Jeff, I have revived this script from 2011 written in python2 to generate medm matrixes. Updating seemed pretty straightfoward, I ran a builtin automated conversion to start, "2to3 file.py" (-w if you want it to actually write the changes).
I tested it by running "python3 generate_KisselButton2024.py 10 4 H1:OMC-ADC_INMTRX" and copy pasting the output into a blank .adl which gives me this 10x4 matrix button with a connected display window based on the input channel arg. It needs a minumum of 3 args: #rows #col channel. You can also specify the size of the button/matrix, and the linked related display .adl file(you can put the whole path).
The new script is found at /opt/rtcds/userapps/release/cds/common/scripts/generate_KisselButton2024.py, and is svned. I left the old script where it is (the same name minus the 2024).
Amazing -- thanks Ryan!
AS_A Counts after shuttering yield a ratio of 325 ppm. Find screenshot below. Template for this ndscope is saved under:
/opt/rtcds/userapps/release/sys/h1/templates/ndscope/fastshuttercheck.yaml
This is with the +Y alignment spot in SR3 detailed in alog 79103:
Start | +P move | -P move | +Y move | -Y move | |
SR3 P slider | 438.7 | 651.1 | 138.7 | 438.7 | 438.7 |
SR3 Y slider | 122.2 | 122.2 | 122.2 | 322.2 | -167.8 |
Today we conducted a brief test on the SUS-EX ESD DAC vs the SUS-EX LD32 DAC, both driving the PEM AA chassis at end X per WP11976. This testing was cut short due to relocking attempts. We changed the cable to the PEM output ~1:10pm PST, and replaced the cable back to its original position at ~2:15pm PST. We are still looking at the results of this testing.
F. Clara, R. McCarthy, M. Pirello, D. Sigg
We compared the output of the 20-bit DAC with the LIGO DAC. There is delay of about 90us. More than we would have expected. Decimation filter delay for a ~30kHz cut-off is about 14us. The filters are getting processed and sent to the DAC at a rate of 1MHz. So, maybe ~1-3us processing delay.
Yesterday, the fast shutter test failed due to dark offsets in the AS WFS DC NSUM channels.
The guardian started running the TwinCAT testing code, which works as intended: it sends a close command to the trigger logic, which in turn fires the fast shutter. The fast shutter works fine as can be seen on the HAM6 geophones. The slow controls readbacks also indicate that both fast shutter and PZT shutter are closed no later than 200ms after the trigger. However 0.5sec after the guardians started the test, it checks the AS WFS DC NSUM outputs and compares them against dark offset limits of ±15. Since the dark offset on WFS B was over 30, the guardian then sent an abort command to the TwinCAT code and reported a failure.
That story agrees with my observation on Friday night when I started looking at the FS after 11:15 PM.
Sheila reported (79092) that the Fast Shutter reopened only after ~50ms or so. It seems that the low voltage drive to keep the shutter closed was not working. 1st attachment shows the last time that happened at around 23:10 local time. Daniel points out that the shutter was in an error state at that time but that was after Ryan power cycled the FS driver. We don't know exactly what kind of state the fast shutter was in here.
The next time the HV firing was tested was at 23:23 local time (2nd attachment), the shutter was kept shut (i.e. low voltage thing was somehow working) but there are two things to note.
The last FS test I've done was 00:12 local time on Jul/13 when the error was cleared, with the smaller power than nominal (3rd attachment). Bouncing was as bad but the power coming to HAM6 was smaller (see the trigger power at the top left). AS_B_NSUM was somewhat smaller (more like 10).
The reason why AS_B_NSUM is worse is because I reduced the analog DC gain by a factor of 10 and compensated for that by digital gain. The effect of analog offset as well as ADC/electronics noise are 10x worse than AS_A. I adjusted the dark offset while IMC was unlocked but we can probably increase the threshold to 30 or so if it continues to bother us.
Bouncing behavior might be more serious as it could mean that the beam was close to the end of the travel of the FS mirror (and it was bad on Friday because of funny alignment), or low voltage drive was somehow still funny. I suspect the former.
Here is my attempt at recreating the (rough) timeline of events related to the fast shutter Friday night (all times in UTC):
Seems like ASC-AS_B_DC gain was probably a red herring, important thing is that the beam got uglier/bigger at some point, therefore a part of the beam was not blocked by the fast shutter.
First attachment shows when ASC-AS_B_DC gain switch was flipped from x10 to x1 on Tuesday. You can see that the Fast Shutter has been firing OK until Friday evening.
The rest of the plots show the FAST Shutter test done by the Beckhoff at three different points in time, i.e. the last test before my AS_B_DC change ("happy" Monday July/08 ~16:37 UTC or 9:37 local), the first one after my AS_B_DC change ("happy" July/11 4:43 UTC or Wed July/10 21:43 local time), and the first time the FAST shutter went into the error mode ("sad" Jul/13 4:56 UTC or Fri Jul/12 21:56 local time). The last one is when Sheila and Ryan started having problem.
Important points are:
From these, my conclusion is that the beam position on the fast shutter mirror was pretty much the same in all three tests, but the beam was pretty ugly for the "sad" plot as was witnessed by many of us on AS port camera. Because of this a part of the lobe was missed by the Fast Shutter. Centering an ugly beam on AS_C might have complicated the matter.
Later, when I forced the test with much lower power, the error was cleared because even though the ugly beam was still there the power went lower than the "shutter closed" threshold of the guardian.
I don't fully understand who did what when during the time the shutter was in the error state (it includes people pressing buttons and power cycling the driver and then pressing buttons again, and I certainly pressed buttons too).
Looking at this, and since Daniel agrees that the Fast Shutter has been working fine, my only concerns about locking the IFO are:
FYI, fast shutter has never failed to fire up and never failed to keep shutter closed when the trigger voltage crossed the threshold of 2V since I connected the ASC-AS_C analog sum to the PEM ADC to monitor the trigger voltage at 2kHz at around Jul/11 2024 18:30 UTC, i.e. in the past 5 days.
In other words, FS has never failed when we actually needed it to protect AS port.
In the 1st attachment, top is the trigger voltage monitored by the ADC. Red circles indicate the time when the trigger crossed the threshold. We've had 12 such events, including 4 that happened after Friday midnight local time.
Middle plot shows when the fast shutter was driven with high voltage (sensed by GS13). Bottom shows the AS_A_DC_NSUM and B_DC_NSUM.
The reason why it looks as if the trigger level changed before and after t=0 on the plot is because a 1:11 resistive divider with a total resistance of 10kOhm was installed at t=0. Before that, the 2V threshold was 32k counts, 2980 counts after.
The rest of plots show that each and every time the shutter was triggered by the trigger voltage rather than a test, it always fired up and kept the shutter closed.