TITLE: 10/15 Day Shift: 1430-2330 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Aligning
OUTGOING OPERATOR: TJ
CURRENT ENVIRONMENT:
SEI_ENV state: CALM
Wind: 4mph Gusts, 3mph 3min avg
Primary useism: 0.03 μm/s
Secondary useism: 0.38 μm/s
QUICK SUMMARY:
When I Arrived ISC_LOCK was in Inintial_alignment, Init_Align was in Locking Green Arms, and ALSY arm has no light on it.
Last lockloss was 2024-10-15_13:01:37Z ISC_LOCK NOMINAL_LOW_NOISE -> LOCKLOSS
TJ Said he got called by H1 Manny just before 7:30.
I will be running Oli's script as described in Alog 76606 to save all slider values before the CDS team does their DAQ Restart thing.
TITLE: 10/15 Eve Shift: 2330-0500 UTC (1630-2200 PST), all times posted in UTC
STATE of H1: Observing at 155Mpc
INCOMING OPERATOR: TJ
SHIFT SUMMARY: Very quiet shift tonight. Once H1 relocked at the start of the shift, we've been observing with steady range.
H1 has now been locked for almost 5 hours.
Lockloss @ 23:29 UTC - link to lockloss tool
No obvious cause, but looks to be some ETMX L3 motion right before the lockloss.
H1 back to observing at 00:23 UTC. Fully automatic relock.
TITLE: 10/14 Day Shift: 1430-2330 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Observing at 156Mpc
INCOMING OPERATOR: Ryan S
SHIFT SUMMARY: We've been locked for almost 8 hours, locked almost the whole shift.
LOG:
| Start Time | System | Name | Location | Lazer_Haz | Task | Time End |
|---|---|---|---|---|---|---|
| 15:26 | FAC | Karen, Kim | FCES | N | Tech clean, out at 15:46 | 17:59 |
| 19:25 | FAC | Karen | MidY | N | Tech clean | 20:20 |
TITLE: 10/14 Eve Shift: 2330-0500 UTC (1630-2200 PST), all times posted in UTC
STATE of H1: Observing at 155Mpc
OUTGOING OPERATOR: Ryan C
CURRENT ENVIRONMENT:
SEI_ENV state: USEISM
Wind: 16mph Gusts, 13mph 3min avg
Primary useism: 0.04 μm/s
Secondary useism: 0.50 μm/s
QUICK SUMMARY: H1 has been locked for over 7 hours and observing for the past 2 hours.
The well pump has been cycled twice during our tank cleaning work. The pump is currently operating for a manual cycle time of 20 minutes, at which point we will identify its level and record it for future reference. For those interested, the well pump takes ~40 seconds to begin filling after being cycled on. C. Soike E. Otterman T. Guidry
25 minutes of pump runtime adds roughly 48" of water to the well tank.
Sheila, Camilla
17:23 - 1745 Turned off SQZ IFO ASC and ran SCAN _SQZ_ALIGNMENT (changed ZMs by ~20urad max plot but BLRMs worse) and then SCAN_SQZANG (changed by 4deg, BLRMS improved but still worse than original). DTT comparing: shows that the AS42 SQZ IFO ASC did better than guardian SCAN_SQZ alignment and angle.
17:50:30 - 18:30:30 UTC - Took No Squeezing time. IFO had been in NLN for 2h10m. Checked NLG = 13.8 (0.12133/0.008785), following 76542. OPO temperature was already at best.
Went back to FDS with ASC and ran SCAN_SQZANG. After the first FDS data set, we turned off ASC.
FDS Data set:
| State | Time (UTC) | Start time (gps) | Angle | DTT Ref |
Notes |
| FDS ASC on | 17:16 | 1 | |||
| FDS SCAN_ALIGN | 17:49 | 2 | (ASC off). SQZ worse than with AS42: plot | ||
| No SQZ | 17:50:30 - 18:00:30 (10min) | 1412963448 | N/A | 0 | |
| FDS | 18:06:00 - 18:12:00 (6min) | 1412964378 | 182.4 | 3 | |
| Glitch 2 minutes in, looked simular to FDS | |||||
| Mid SQZ + | 18:26:00 - 18:32:00 (6min) | 1412965578 | 216.6 | 4 | Aimed for No SQZ level at 2kHz |
| A SQZ | 18:36:00 - 18:42:00 (6min) | 1412966178 | (-)105.6 | 5 | |
| A SQZ +10deg | 18:42:15 - 18:48:15 (6min) | 1412966553 | (-)115.1 | 6 | |
| A SQZ -10deg | 18:48:30 - 18:54:30 (6min) | 1412966928 | (-)95.2 | 7 | |
| Mid SQZ - | 18:56:00 - 19:02:00 (6min) | 1412967378 | 136.9 | 8 | Aimed for No SQZ level at 2kHz |
| FDS +10deg | 19:03:30 - 19:09:30 (6min) | 1412967828 | 192.8 | 9 | |
| FDS -10deg | 19:10:00 - 19:16:00 (6min) | 1412968218 | 172.0 | 10 | |
|
FDS (repeat, ASC off)
|
19:16:30 - 19:22:30 (6min)
|
|
182.4
|
11
|
Slightly worse than ref3
1h10 later with ASC off
|
Plot attached showing ASQZ and Mid sqz trends and FDS trends. Saved as camilla.compton/Documents/sqz/templates/dtt/14Oct2024_SQZ_FDS_ASQZ/SQZ.xml.
Then did scan SQZ ang (adjusted 182.4 to 183.9) and turned on ASC in FDS. Then turned off ASC and went to FIS (un-managed form ISC_LOCK). Tweaked SQZ angle as it wasn't optimized at high freq.
FDS Data set:
| State | Time (UTC) | Start time (gps) | Angle | DTT Ref |
Notes |
| FIS | 19:40:30 - 18:46:30 (6min) | 1412970048 | 193.4 | 3 | |
| Mid SQZ + | 19:47:30 - 18:53:30 (6min) | 1412970468 | 218.0 | 4 |
Aimed for No SQZ level at 2kHz
(SEI state changed to useism at 19:52 UTC)
|
| A SQZ | 19:56:00 - 20:02:00 (6min) | 1412970978 | (-)103.3 | 5 | |
| A SQZ +10deg | 20:02:30 - 20:08:30 (6min) | 1412971368 | (-)113.8 | 6 | |
| A SQZ -10deg | 20:09:00 - 20:15:00 (6min) | 1412971758 | (-)93.8 | 7 | |
| Mid SQZ - | 20:16:30- 20:22:30 (6min) | 1412972208 | 147.0 | 8 | Aimed for No SQZ level at 2kHz |
| FIS +10deg | 20:24:30- 20:30:30 (6min) | 1412972688 | 203.8 | 9 | |
| N/A | Got distracted and changed angle too soon | ||||
| FIS -10deg | 20:35:45- 20:41:45 (6min) | 1412973363 | 183.9 | 10 | |
| FIS (repeat) | 20:42:00- 20:48:00 (6min) | 1412973738 | 193.4 | 11 | V. simular to ref 3. Maybe slightly better |
Plot attached showing FIS ASQZ and Mid sqz trends and FDS trends. Saved as camilla.compton/Documents/sqz/templates/dtt/14Oct2024_SQZ_FIS_ASQZ/SQZ.xml.
No SQZ 20:49:00UTC to 20:51:00UTC while we went back to FDS, I started it at 185deg and ran SCAN_SQZANG, angle adjusted to 189deg. Back to Observing at 20:57UTC.
FAMIS 31055
The PSL has been taken down a few times in the past week as part of the glitching investigations, and this is seen clearly on several trends. Also, since the NPRO controller was swapped 5 days ago but the potentiometers on the daughter board were not adjusted on the one swapped in (alog80566), some of the readbacks for the NPRO channels are reporting inaccurate values, namely the laser diode powers. The controller is planned to be swapped back to the original tomorrow so these readbacks will be fixed.
Other item of note is that every time the PMC was unlocked last week, it seems to have relocked with a slightly higher reflected power and corresponding lower transmitted power (see stabilization trends). Looking at the PMC REFL camera image, there could be something to gain from an alignment tweak into the PMC, so I'll try that tomorrow during maintenance and see if there's any improvement.
17:22 UTC We started comissioning, starting a little late today due to the IFO not being fully locked and thermalized.
Mon Oct 14 10:12:33 2024 INFO: Fill completed in 12min 29secs
Travis confirmed a good fill curbside.
In the past few weeks, a number OPO temperature changes have been made while the detector was in observing mode (per the relevant instructions). These changes have been highly successful at increasing the range, particularly the most recent couple of OPO changes. However, this type of rapid improvement in the spectrum can create challenges when measuring the spectrum of the data in downstream data analysis pipelines (similar to how the sudden turn-on of the line subtraction was problematic). When the OPO adjustment has created significant changes to the spectrum, the time periods during the transition should be CAT1 vetoed (tagging Detchar-request).
As an example of these transitions, I've included a range timeseries and a daily spectrogram with the transition time indicated. I also have included a before/after spectrum comparison showing the broadband improvement at high frequency.
To mitigate the impact on data analysis pipelines, future transitions should either be made while briefly out of observing or tracked by Detchar for CAT1 vetoes.
I've wrote a small script to revert ZM sliders after a SCAN_ALIGNMENT is run (SQZ_MANAGER state 105) incase we don't like it. It does a rough search for when this state was last run in the past day (it probably can be reduced but I needed a larger range for testing) using minute trends. From this time it then does a more narrow second trend to get more accurate state boundary times (did this for speed of nds2 calls), then it just takes the slider values of ZM{4,6} from a minute before the most recent SCAN_ALIGNMENT started and caputs them.
You can change the lookback time by changing the "days" and "hours" variables at the top of the script which lives at /opt/rtcds/userapps/release/sqz/h1/scripts/revert_sqz_align.py
Overall the finidings were similar to the previous days, with a few exceptions. On Monday there was ground motion reported around 7:00. On Tuesday, there was also earthquake ground motion, and a slight increase in glitch rate around the hours of 1:00-3:00, and at 12:00 and 15:00. On Wednesday, there were no significant changes to report. On Thursday, there was rotational wind motion around hours 1-5:00 and glitch rate increase around hours 6:00-8:00. Also there was a decrease in the Detchar Fscan lines to around 400, which was less than previous days. On Friday, there were no significant changes to report. Fscans lines increased back to the normal range. On Saturday, there was earthquake motion around 19:00. On Sunday, there was a slight increase in the lock/strain/sensitivity around 16:00.
TITLE: 10/14 Day Shift: 1430-2330 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Lock Acquisition
OUTGOING OPERATOR: Oli
CURRENT ENVIRONMENT:
SEI_ENV state: CALM
Wind: 4mph Gusts, 3mph 3min avg
Primary useism: 0.03 μm/s
Secondary useism: 0.42 μm/s
QUICK SUMMARY:
2 high state locklosses on this reaquisition, TRANSITION_FROM_ETMX at 13:55 UTC and a LOWNOISE_ESD_ETMX at 14:44 UTC
DARM coherence low range check
Over the summer, Sam, Robert, and I investigated several peaks in DARM, including one at ~35.4 Hz and a peak that oscillates between 30-40 Hz. The 35.4 Hz peak was found to couple strongly at HAM1 and HAM6 (see alog 79546). Shut-offs of the office area air handler and the main chillers showed that the peak decreases when these systems are shut off, though it doesn't disappear completely. See Figure 1 and Figure 2 with office area air handler shut offs at 19:33:00-19:38:30 and 19:43:00-19:55:00 (alog 79888), and Figure 3 for main chiller shut offs (alog 73941). Note that there is also a fainter peak about 0.2 Hz above the 35.4 Hz peak as seen in Figure 4 but it is unclear if it also decreases when the HVAC is shut off.
The oscillating 30-40 Hz peak tends to be near 40 Hz at the beginning and end of the UTC day and drops to near 30 Hz in the middle of the day as seen in Figure 5. It often appears sinusoidal as seen in Figure 6 but sometimes has a more random appearance as in Figure 7. It is seen in microphones and magnetometers as well, and first appeared at least as early as 6 June 2024. Its source has yet to be identified.
These peaks were dicussed in a presentation at the end of our summer fellowship as well as in a DetChar call, now posted on the DCC: LIGO-G2402140.
TITLE: 10/14 Eve Shift: 2330-0500 UTC (1630-2200 PST), all times posted in UTC
STATE of H1: Observing at 158Mpc
INCOMING OPERATOR: Oli
SHIFT SUMMARY: Pretty quiet evening with just one lockloss followed by an automatic relock. Range has been keeping fairly steady this lock.
H1 has been locked and observing for just over 4 hours.
Output of Oli's script:
anthony.sanchez@cdsws29: python3 update_sus_safesnap.py
No optics or groups entered. -h or --help to display opt-ions.
anthony.sanchez@cdsws29: python3 update_sus_safesnap.py -h
usage: update_sus_safesnap [-h] [-p] [-o [OPTICS ...]]
Reads the current OPTICALIGN_{P,Y}_OFFSET values and uses those to overwrite
the OPTICALIGN_{P,Y}_OFFSET values in the burt files linked from their
respective safe.snap files.
options:
-h, --help show this help message and exit
-p, --print-only Use -p or --print-only to only print the beforeand
after values without updating the values saved in
safe.snap. (default: False)
-o [OPTICS ...], --optics [OPTICS ...]
Type the names of optic groups (ex. itm) or individual
optic names (ex. pr2), with spaces in between. Case
does not matter.
OptGroup | Optics OptGroup | Optics
itm ITMX etm ETMX
ITMY ETMY
bs BS tms TMSX
TMSY
rm RM1
RM2 pr PRM
PR2
im IM1 PR3
IM2
IM3 mc MC1
IM4 MC2
MC3
sr SRM
SR2 ifo_out OFI
SR3 (om if w/o OFI) OMC
OM1
fc FC1 OM2
FC2 OM3
zm_in OPO zm_out ZM4
ZM1 ZM5
ZM1 ZM6
ZM3
(default: none)
anthony.sanchez@cdsws29: python3 update_sus_safesnap.py -o itm bs rm im sr fc zm_in etm tms pr mc ifo_out zm_out
Running $(USERAPPS)/isc/h1/guardian/update_sus_safesnap.py
Updating and printing out saved OPTICALIGN_{P,Y}_OFFSET values from safe.snap vs current values for these optics:
ITMX ITMY BS RM1 RM2 IM1 IM2 IM3 IM4 SRM SR2 SR3 FC1 FC2 OPO ZM1 ZM2 ZM3 ETMX ETMY TMSX TMSY PRM PR2 PR3 MC1 MC2 MC3 OFI OMC OM1 OM2 OM3 ZM4 ZM5 ZM6
Traceback (most recent call last):
File "/opt/rtcds/userapps/trunk/isc/h1/scripts/update_sus_safesnap.py", line 318, in <module>
old_new = replace_offsets(opt_dicts(optics), print_only=print_only)
File "/opt/rtcds/userapps/trunk/isc/h1/scripts/update_sus_safesnap.py", line 201, in replace_offsets
cur_vals.append(ezca[pchanname])
File "/var/opt/conda/base/envs/cds/lib/python3.10/site-packages/ezca/ezca.py", line 304, in __getitem__
return self.read(channel)
File "/var/opt/conda/base/envs/cds/lib/python3.10/site-packages/ezca/ezca.py", line 294, in read
pv = self.connect(channel)
File "/var/opt/conda/base/envs/cds/lib/python3.10/site-packages/ezca/ezca.py", line 272, in connect
raise EzcaConnectError("Could not connect to channel (timeout=%ds): %s" % (self._timeout, name))
ezca.errors.EzcaConnectError: Could not connect to channel (timeout=2s): H1:SUS-OFI_M1_OPTICALIGN_P_OFFSET
anthony.sanchez@cdsws29: python3 update_sus_safesnap.py -o zm_out
Running $(USERAPPS)/isc/h1/guardian/update_sus_safesnap.py
Updating and printing out saved OPTICALIGN_{P,Y}_OFFSET values from safe.snap vs current values for these optics:
ZM4 ZM5 ZM6
SUS-ZM4_M1_OPTICALIGN_P_OFFSET
Old Saved: -7.92342523045482380439e+02
New Saved: -772.2246009467159
SUS-ZM4_M1_OPTICALIGN_Y_OFFSET
Old Saved: -9.85740674423158566242e+02
New Saved: -981.3613025567112
SUS-ZM5_M1_OPTICALIGN_P_OFFSET
Old Saved: -1.15000000000000000000e+02
New Saved: -115.0
SUS-ZM5_M1_OPTICALIGN_Y_OFFSET
Old Saved: -4.60000000000000000000e+02
New Saved: -460.0
SUS-ZM6_M1_OPTICALIGN_P_OFFSET
Old Saved: 1.39848934620929139783e+03
New Saved: 1408.6829424213722
SUS-ZM6_M1_OPTICALIGN_Y_OFFSET
Old Saved: -2.83802124439147348767e+02
New Saved: -260.05899996129443
anthony.sanchez@cdsws29: python3 update_sus_safesnap.py -o ifo_out
Running $(USERAPPS)/isc/h1/guardian/update_sus_safesnap.py
Updating and printing out saved OPTICALIGN_{P,Y}_OFFSET values from safe.snap vs current values for these optics:
OFI OMC OM1 OM2 OM3
Traceback (most recent call last):
File "/opt/rtcds/userapps/trunk/isc/h1/scripts/update_sus_safesnap.py", line 318, in <module>
old_new = replace_offsets(opt_dicts(optics), print_only=print_only)
File "/opt/rtcds/userapps/trunk/isc/h1/scripts/update_sus_safesnap.py", line 201, in replace_offsets
cur_vals.append(ezca[pchanname])
File "/var/opt/conda/base/envs/cds/lib/python3.10/site-packages/ezca/ezca.py", line 304, in __getitem__
return self.read(channel)
File "/var/opt/conda/base/envs/cds/lib/python3.10/site-packages/ezca/ezca.py", line 294, in read
pv = self.connect(channel)
File "/var/opt/conda/base/envs/cds/lib/python3.10/site-packages/ezca/ezca.py", line 272, in connect
raise EzcaConnectError("Could not connect to channel (timeout=%ds): %s" % (self._timeout, name))
ezca.errors.EzcaConnectError: Could not connect to channel (timeout=2s): H1:SUS-OFI_M1_OPTICALIGN_P_OFFSET
anthony.sanchez@cdsws29:
That error to my update_safe_snap script shouldn't happen again - I had put the OFI as an option in there for overwriting the OPTICALIGN offset settings, but it turns out that the OFI doesn't have opticalign offsets! Neither does the OPO, so I've removed both of those from the code.
It seems to now be working correctly (but it's tricky to test) so hopefully there are no more issues with running it.