TITLE: 03/20 Day Shift: 1430-2330 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Lock Acquisition
CURRENT ENVIRONMENT:
SEI_ENV state: CALM
Wind: 47mph Gusts, 31mph 3min avg
Primary useism: 0.09 μm/s
Secondary useism: 0.41 μm/s
QUICK SUMMARY:
H1 had reached Nominal_LOW_NOISE [600] at 16:09 UTC
Commissioning had started.
A button pusher accidentally pressed the NLN_ETMY[710] button on the ISC_LOCK screen.
There was enough time to pause and Look at the ISC_LOCK graph, to look for a way back to NOMINAL_LOW_NOISE[600].
The Graph has a path out of NLN_ETMY[710] to NEW_DARM[711], then to RETURN_TO_ETMY[712], then to DARM_RECOVER[713].
But since DARM_RECOVER[713] didn't have a path back o NLN[600] I thought we would still be stuck.
So I held us in NLN_ETMY for a few more moments while I checked the alog and found Ryan Short's alog76320 .
I then quickly pulled up an Ndscope to find that Ryan and company had lost lock and not returned back to NLN[600].
Other alogs that mention NLN_ETMY all mention locklosses. so that was our last well documented path out of NLN_ETMY.
There was some confidence building amongst the wealth of knowledge within the Control Room that we should manuel from NLN_ETMY[710] to BACK_TO_ETMX[561].
Since that was the intuition and consensus of the room full of knowledgable people we tried it.
This led us to be stuck in BACK_TO_ETMX and a LOG that said:
2025-03-20_16:25:29.616860Z ISC_LOCK [BACK_TO_ETMX.run] USERMSG 0: EX ESD bias is off.
2025-03-20_16:25:29.617144Z ISC_LOCK [BACK_TO_ETMX.run] USERMSG 1: EX ESD must be off. DARM not transitioned. HELP ME!!!!
And we then lost lock due to high winds.
In the Future, If you find your self in NLN_ETMY, maybe try DARM_RECOVER instead.
Relocking as been abismal.
Thu Mar 20 10:06:49 2025 INFO: Fill completed in 6min 46secs
J. Kissel Recall there is an analog TEST voltage input to the OMC DCPD in-vacuum transimpedance amplifier TIA (D2000592), whose in-air interface is through the OMC DCPD Whitening Chassis' (D2200215) J4 D9M port labeled "From AI/DAC / Test Inputs." This whitening chassis lives in U24 of ISC-R5 by HAM6. port. This port usually connected to a DAC via cable ISC_444, and the DAC channels can be used to test the response of the TIA / Whitening / AA / ADC chain entirely remotely. However, these test inputs are not always engaged and functional; they are governed by analog relay switches. These relay switches themselves are governed by digital binary input, generated by the Beckhoff slow-controls system. This is aLOG is about how to find and use these relay switches. It's been a while since I used this screen (July 2023; LHO:71225), and it looked different than I remember and can't find an aLOG about the change, so I document it here. See attached screenshot. What's shown as "A_Relayset & B_Relayset" are the settings channels H1:OMC-DCPD_A_RELAYSET and H1:OMC-DCPD_B_RELAYSET. Setting these to "On" or "1.0" turns ON the relay enabling the test input excitation. Setting these to "Off" or "0.0" turns OFF the relay disabling the test input excitation. In the screenshot, the A channel relayset is called out with a deep purple arrow. What's shown as "A_Relaytoggle" & "B_Relaytoggle" are momentary channels H1:OMC-DCPD_A_RELAYTOGGLE and H1:OMC-DCPD_B_RELAYTOGGLE. These are momentary channels, that if set to "On" or "1.0," it toggles the RELAYSET to the opposite setting it's currently in, and then self-restores to "Off" or "0.0." So, on the screen, hitting "On" changes the relay state, and hitting "Off" does nothing. In the screenshot, the A channel relaytoggle is called out with a dark green arrow. Note -- there is only one differential test input from the J4 D9M, "From AI/DAC" port of the whitening chassis. So if you turn on BOTH A and B test input relays, it drives BOTH A and B's test inputs simultaneously with signal identical to the input. If you want, or only need to, drive one DCPD's TIA path at time, then turn on only that corresponding relay.
Back by popular demand, the "TP CLEAR" button on the CDS overview which clears all open test points with the exception of these normally kept open when in Observe.
The CDS Overview now permits one testpoint to be kept open on h1calinj, h1calcs and h1iopomc0. As before, h1calinj's TP is expected to be an EXC. I've removed h1lsc's permitted two TPs. Attachment shows MEDM snippet for these models.
To make space to add the "TP CLEAR" button I've modified the CDS section to position the command buttons immediately following the related-display buttons (see attachment).
TITLE: 03/20 Day Shift: 1430-2330 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Aligning
OUTGOING OPERATOR: Oli
CURRENT ENVIRONMENT:
SEI_ENV state: CALM
Wind: 37mph Gusts, 25mph 3min avg
Primary useism: 0.05 μm/s
Secondary useism: 0.44 μm/s
QUICK SUMMARY:
H1 was locked for 12.5 hours but lost lock due to High Winds at 13:39 UTC .
When I arrived H1 was still struggling to lock while the winds howled aross the the roof of the CS.
So far I have run an Initial_Alignment, and taken ISC_LOCK to IDLE, & Observatory mode to Wind.
When the tumbleweeds stop running across the road we will be ready to lock!
The hourly forcast is leaning less toward Compact Binary Collisions and more toward Tumbleweed Traffic Collisions, so watch out for those tumbleweeds.
TITLE: 03/20 Eve Shift: 2330-0500 UTC (1630-2200 PST), all times posted in UTC
STATE of H1: Observing at 151Mpc
INCOMING OPERATOR: Oli
SHIFT SUMMARY:
IFO is in NLN and OBSERVING as of 01:00 UTC (4 hr lock)
Extremely calm shift with one lockloss (alog 83460). Re-acquisition was fully automatic.
We also rode out a 5.6 EQ from Alaska in which Guardian correctly went into EQ mode before the waves hit.
LOG:
None
Ibrahim A, Jeff K
Re-measurement of the BBSS Bounce and Roll modes following changes to the BBSS parameters. Measurements show that these still closely match the new model.
The differences from the original BBSS FDR are:
TITLE: 03/19 Day Shift: 1430-2330 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Lock Acquisition
INCOMING OPERATOR: Ibrahim
CURRENT ENVIRONMENT:
SEI_ENV state: CALM
Wind: 6mph Gusts, 3mph 3min avg
Primary useism: 0.02 μm/s
Secondary useism: 0.42 μm/s
SHIFT SUMMARY:
H1 had been locked since before I got on shift.
Tyler went to start "Big Red" the forklift while it was parked at the water tank. He did not move it just starteded the motor and let it idle.
I asked him to please note the time the motor was started and when it was shut off just incase it's important to detchar folks.
17:43 UTC time Big Red's motor turned on.
17:49 UTC time turned off.
GRB-Short candidate E565397 19:19:39 UTC
Fell from Observing to Commissioning at 21:20 UTC because the SQZr unlocked , it is relocking it's self, no intervention from me.
back to Observing at 21:23UTC
@ 23:28:53 UTC! Lockloss from unkown cause. Sorry Ibrahim :(
LOG:
Start Time | System | Name | Location | Lazer_Haz | Task | Time End |
---|---|---|---|---|---|---|
19:57 | LASER HAZ | LASER HAZARD | LVEA (\u2310\u25a0_\u25a0) | YES | LVEA IS LASER HAZARD (\u2310\u25a0_\u25a0) | 06:36 |
14:29 | FAC | Nelly | Optics lab | N | Technical cleaning | 14:44 |
16:27 | FAC | Mitchel & Tyler | Anti-room/receiving | N | Measuring unistrut for roll up door repair. | 22:02 |
17:24 | FAC | Tyler | Water tank | N | Starting Big Red | 17:54 |
17:25 | FAC | Kim | H2 | N | Technical cleaning | 18:25 |
17:59 | FAC | Mitchel | Offsite | N | Fetching parts from machine shop in town | 19:59 |
20:56 | FAC | Mitchel & Betsy | CER | N | Rolling door repair | 21:10 |
Lockloss that killed our 15hr lock. No immediate causes.
H1 back to OBSERVING at 03-20 01:00 UTC
TITLE: 03/19 Eve Shift: 2330-0500 UTC (1630-2200 PST), all times posted in UTC
STATE of H1: Observing at 151Mpc
OUTGOING OPERATOR: Tony
CURRENT ENVIRONMENT:
SEI_ENV state: CALM
Wind: 8mph Gusts, 4mph 3min avg
Primary useism: 0.02 μm/s
Secondary useism: 0.47 μm/s
QUICK SUMMARY:
IFO is in NLN and OBSERVING as of 08:09 UTC (~15 hr lock!).
Plan is to stay observing for as long as we can, though the microseism is on the rise.
Dropped from Observing to Commissioning at 17:22:53 UTC
TJ and I ran the A2L Script Multi Pretty script on All Quads.
Python3 /opt/rtcds/userapps/release/isc/h1/scripts/a2l/a2l_min_multi_pretty.py -a
['ETMX', 'ETMY', 'ITMX', 'ITMY'] ['P', 'Y'] a2l script done!
All complete.
*************************************************
RESULTS
| OPTIC|P/Y| Initial | Final | Diff |
| ETMX | P | 3.23 | 3.31 | 0.08 |
| ETMX | Y | 4.9 | 4.96 | 0.06 |
| ETMY | P | 5.52 | 5.57 | 0.05 |
| ETMY | Y | 1.35 | 1.37 | 0.02 |
| ITMX | P | -0.53 | -0.54 | -0.01 |
| ITMX | Y | 3.21 | 3.23 | 0.02 |
| ITMY | P | 0.06 | 0.04 | -0.02 |
| ITMY | Y | -2.74 | -2.76 | -0.02 |
While also watching this ndscope to ensure that they crossed 0 using this ndscope templat:
ndscope /opt/rtcds/userapps/release/asc/h1/templates/ndscope/A2L_script_ADS.yaml
Returned to Observing at 17:47:22 UTC
I've now merged a2l_min_multi_pretty.py and a2l_min_multi.py so that the terminal output looks a bit better and it now has the option to print out that table in html format for easy alogging.
Wed Mar 19 10:11:18 2025 INFO: Fill completed in 11min 14secs
Today's fill has a winter look to it, OAT 5C 42F and overnight min -3C 26F
I was able to take 2 SQZ DARM Coherence Double Precision checks, once with 30 averages, and once with 70 averages.
Larger than 70 averages was giving me a "gap in data error".
To repeat this in the future:
Measurement settings I used to get the 70 averages to run.
Input settings i used to get the 70 Averages to run with out crashing.
The epoch time being too far in the past might be the reason diaggui was crashing unexpectedly, more testing is needed. -tagging CDS because unexpected crashes of diaggui_test.
Patrick, Jonathan, Sheila, TJ
During locking following maintenance Tue 18mar2025 we tried to move the BS camera from its old server (h1digivideo2) to its new server (h1digivideo5) for a second time. We had tried this the previous week but ran into locking issues with h1asc's use of this camera's centroid values and so had to move this, along with the ITM cameras back to h1digivideo2.
The plan was to just move one camera, h1cam26, to the new server and make the gain changes on h1asc's camera centering to compensate for the new video IOC, as was done when the ETM cameras were moved last year.
It became quickly apparent that the centroid values were more noisy with the new code in addition to being offset (plot shows CAM26_X, new code on left, old code on right).
We suspect the issue may be due image masking. The old code applied an image mask before calculating the centroids, the new code takes the image as a whole. The image snapshot shows that the edge of the optic is visible to the right, an issue the ETM images do not have.
We reverted CAM26 back to the old server at 17:00 PDT.
During the testing of BS on the new server I removed it from the camera dummy ioc. After it was reverted back to the old server I added its new PVs back to the dummy ioc to green up the EDC.
Here is the current camera situation, cameras running the old code are marked with the RED VID2
During our BS camera work there was a consensus that it would be good if the BS image was displayed on a control room FOM. It was generally agreed that the ITMX_SPOOL camera on nuc35 could be replaced with the BS camera.
I made the fom yaml change and rebooted nuc35 at 09:47 PDT. The new FOM screen is attached.
TITLE: 03/19 Day Shift: 1430-2330 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Observing at 145Mpc
OUTGOING OPERATOR: Oli
CURRENT ENVIRONMENT:
SEI_ENV state: CALM
Wind: 5mph Gusts, 3mph 3min avg
Primary useism: 0.02 μm/s
Secondary useism: 0.24 μm/s
QUICK SUMMARY:
H1 has been locked and Observing for 6 and a half hours.
Looks like H1 was relocked via the H1 Manager Guardian at 08:09 UTC this morning.
We went through locking ALS5 times, until H1 Manager went through an initial alignment, which allowed a quick relock after that.
All systems seem to be functioning.
I thought that perhaps the Lockloss last night was cause by the Earthquake, but that earthquake struck while H1 was relocking and was not the cause of the lockloss.
Currently the Lockloss is unknown. LL pics attached.