Lockloss @ 11/08 20:17UTC after nearly 2.5 hours locked due to a local earthquake
[Tony, Erik]
CDS Laptops have been locking up when the lid was closed then reopened.
There is a fix, but it has to be applied by individual users.
From the "Applications" menu (upper left) go to "Settings" -> "Power Management" -> "System".
Screen shot attached.
With "On Battery" selected, change the Laptop Lid action action to "Suspend", then change the System sleep mode to "Suspend".
Select "Plugged In" and make the same changes.
The laptop will now go into suspend mode when the lid is shut. When you reopen it, the screen will be blank for a bit, but if you press the space bar, it will wake up after several seconds.
Also, you may now use your personal account when logging in to the laptop. The controls user can still be used. The settings described above are per-user. If you make the changes as controls, that won't affect your personal account.
If you use the controls user, you may want to check these settings each time you logged in since somebody else may have changed them.
Richard, Oli
We had a Check PSL Chiller verbal alarm almost an hour ago, and Richard heard it beeping in the diode room so he added 120mL of water to the PSL chiller.
Fri Nov 08 10:01:53 2024 INFO: Fill completed in 1min 52secs
Very short fill. Travis saw a vapor cloud to confirm the fill.
Camilla, Oli
Recently, because of the PSL/IMC issues, we've been having a lot of times where the IFO (according to verbals) seemingly goes into READY and then immediately goes to DOWN because the IMC is not locked. Camilla and I checked this out today and it turns out that these locklosses are actually from LOCKING_ARMS_GREEN - the checker in READY that is supposed to make sure the IMC is locked was actually written as nodes['IMC_LOCK'] == 'LOCKED' (line 947), which just checks that the requested state for IMC_LOCK is LOCKED, and it doesn't actually make sure the IMC is locked. So READY will return True, it will continue to LOCKING_ARMS_GREEN, and immediately lose lock because LOCKING_ARMS_GREEN actually makes sure the IMC is locked. This all happens so fast that verbals doesn't have time to announce LOCKING_ARMS_GREEN before we are taken to DOWN.
To (hopefully) solve this problem, we changed nodes['IMC_LOCK'] == 'LOCKED' to be nodes['IMC_LOCK'].arrived and nodes['IMC_LOCK'].done, and this should make sure that we stay in READY until the IMC is fully locked. ISC_LOCK has been reloaded with these changes.
The reason it has been doing this is because there is a return True in the in main method of ISC_LOCK's READY state. Then a state returns True in its main method, it will skip the run method.
I've loaded the removal of this in ISC_LOCK.
TITLE: 11/08 Day Shift: 1530-0030 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Lock Acquisition
OUTGOING OPERATOR: Ryan C
CURRENT ENVIRONMENT:
SEI_ENV state: CALM
Wind: 2mph Gusts, 1mph 3min avg
Primary useism: 0.03 μm/s
Secondary useism: 0.39 μm/s
QUICK SUMMARY:
Currently relocking and we had been in PREP_FOR_LOCKING for 15 minutes now so I took us to DOWN and then restarted locking.
Last night's lockloss (11/08 11:15UTC)
Lockloss tool gave it the IMC tag, and I do see that ASC-AS_A did drop down and the IMC lost lock less than 10ms later(ndscope), but I don't see anything that could have caused this to happen.
17:59UTC Back to Observing
H1 called for help from the initial alignment timer expiring, we're getting hit by an earthquake (6.2 from Chile). It was only in GREEN_ARMS, I brought it to down for now, once the ground motion calms down I'll restart locking, secondary microseism is also increasing.
I've restarted locking after seeing greenarms hold for a few minutes.
TITLE: 11/08 Eve Shift: 0030-0600 UTC (1630-2200 PST), all times posted in UTC
STATE of H1: Observing at 161Mpc
INCOMING OPERATOR: Ryan C
SHIFT SUMMARY:
IFO Locked for 8 Hours, No Superevent candidates
Everything is running smoothly.
LOG:
no log
Summary:
Attached shows a lockloss at around 11:31 PST today (tGPS~1415043099). It seems that the fast shutter, after it was shut, bounced down to momentarily unblock the AS beam at around the time the power peaked.
For this specific lock loss, the energy deposited into HAM6 was about 17J and the energy that got passed the fast shutter is estimated to be ~12J because of the bouncing.
Bouncing motion was known to exist for some time (e.g. alogs 79104 and 79397, the latter has an in-air slow-mo video showing the bouncing), it seems as if the self damping is not working. Could this be an electronics issue or mechanical adjustment issue or something else?
Also, if we ever open HAM6 again (before this fast shutter is decomissioned), it might be a good idea to make the shutter unit higher (shim?) so the beam is still blocked when the mirror reaches its lowest position while bouncing up and down.
Details:
The top panel shows the newly installed lockloss power monitor (blue) and ASC-AS_A_DC_NSUM which monitors the power downstream of the fast shutter (orange).
The shutter was triggered when the power was ~3W or so at around t~0.36 and the ASC-AS_C level drops by a factor of ~1E4 immediately (FS mirror spec is T<1000ppm, seems like it's ~100ppm in reality).
However, 50ms later at t~0.41 or so, the shutter bounced back down and stayed open for about 15ms. Unfortunately this roughly coincided with the time when the power coming into HAM6 reached its maximum of ~760W.
Green is a rough projection of the power that went to OMC (aka "AS_A_DC_NSUM would have looked like this if it didn't rail" trace). This was made by simply multiplying the power mointor itself with AS_A_DC_NSUM>0.1 (1 if true, 0 if false), ignoring the 2nd and 3rd and 4th bouncing.
All in all, for this specific lock loss, the energy coming to HAM6 was 16~17J, and the energy that got past FS was about 11~12J because the timing of the bounce VS the power. OMC seems to be protected by the PZT though, see the 2nd attachemt with wider time range,
The time scale of the lock loss spike itself doesn't seem that different from the L1 lock loss in LLO alog 73514 where the power coming to HAM6 peaked tens of ms after AS_A/B/C power appreciably increased.
OMC DCPDs might be OK since they didn't record crazy high current (though I have to say the IN1 should have been constantly railing once we started losing lock, which makes the assessment difficult), and since we've been running with bouncy FS and the DCPDs have been good so far. Nevertheless we need to study this more.
Two lock losses, one from last night (1415099762, 2024-11-08 11:15:44 UTC, 03:15:44 PST) and another one that just happened (1415132263, 2024/11/08 20:17:25 UTC) look OK.
The shutter bounced ~50ms after the trigger but the power went down before that.
Two more lock losses from today (1415141124, 2024-11-08 22:45:06 UTC and 1415145139, 2024-11-08 23:52:00 UTC) look OK.
In these plot, shutter open/close is judged by p(monitor)/p(AS_A) < some_threshold (open if true).
DriptaB and RickS
Today we investigated the 20 dB gain deficit in the Optical Follower Servo (OFS). We found that the loop offset being set at 7.0 V may have been the source of the issue.
We followed the procedure in LIGO-T1400486 to test the performance of the OFS board and everything seemed normal.
We centered the beam on the OFS PD in the transmitter module and used the REFL output beam on the PS4 (WSH) power standard to set the loop offset to 3.94 V (V2 on the HP power supply)which gave 300 mW in the REFL beam.
We then measured the OFS OLTF (Souce at CLTF TEST IN; PD MON / ERR MON) and set the gain at 7.60 V (V1 on the HP power supply) to give a UGF of 100 kHz. The phase margin is about 55 deg, as expected.
The loop seems to be operating normally now. Screenshot of the OLTF measurement attached.
The system was left with the covers on the two power senors in the responsivity ratio setup, the anodized aluminum beam block at the output of the Tx module, the two external shutters closed and the Remote/Local switch in the Local position.
TITLE: 11/08 Eve Shift: 0030-0600 UTC (1630-2200 PST), all times posted in UTC
STATE of H1: Observing at 160Mpc
OUTGOING OPERATOR: Corey
CURRENT ENVIRONMENT:
SEI_ENV state: CALM
Wind: 5mph Gusts, 4mph 3min avg
Primary useism: 0.02 μm/s
Secondary useism: 0.24 μm/s
QUICK SUMMARY:
IFO is Currently locked and OBSERVING for 2 hours and 45 minutes !
TITLE: 11/07 Day Shift: 1530-0030 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Aligning
INCOMING OPERATOR: Tony
SHIFT SUMMARY:
H1's Returned To Join L1 & V1 For Some Triple Coincidence!
The day started with Daniel driving to EY to fix our ailing ALSy laser. After that Camilla ran an H1 alignment and got H1 back to NLN for a bit for some Observing time, but then there was a lockloss. After this tried locking, but DRMI/PRMI both looked ugly, so another alignment was needed (and this wasn't trivial since the Manual Alignment attempts did NOT do the trick and for a full Initial Alignment, SRY was too misaligned and required some "alignment by hand" with SR2 & SRM. But after this, H1 returned to NLN and we've been there for over 2.5hrs (in mostly Observing for this time other than a 15min drop for Vicky to touch up the Squeezer).
OPERATOR NOTE: If EX HEPI trips, call Jim!! (this is due to low fluid levels near the trip level)
LOG:
ls /opt/rtcds/userapps/release/sus/common/scripts/quad/InLockChargeMeasurements/rec_LHO -lt | head -n 6
total 511
-rw-r--r-- 1 test_user controls 160 Oct 8 07:58 ETMX_12_Hz_1412434733.txt
-rw-r--r-- 1 test_user controls 160 Oct 8 07:50 ETMY_12_Hz_1412434262.txt
-rw-r--r-- 1 test_user controls 160 Oct 8 07:50 ITMY_15_Hz_1412434244.txt
-rw-r--r-- 1 test_user controls 160 Oct 8 07:50 ITMX_13_Hz_1412434243.txt
-rw-r--r-- 1 test_user controls 160 Sep 24 07:58 ETMX_12_Hz_1411225133.txt
The latest measurements were already documented in this alog, and the measurements were not run this week.
Adjusted OPO temperature to maximize RF6 with SQZ_MANAGER paused and the guardian SQZ_ANG_ADJUST in "DOWN".
Then turn back on SQZ_ANG_ADJUST = "ADJUST_SQZ_ANG_SDF", and adjusted the squeeze angle servo setpoint (the ADF demod phase, H1:SQZ-ADF_OMC_TRANS_PHASE from -133 to -124, see accepted SDF) to maximize squeezing (increased ~ 1 dB squeezing at kHz) and range (trends, increased like 5-10 Mpc?).
As reported in 79897, a bump has been apparent in the H1 spectrum in the vicinity of the Crab pulsar for much of O4b.
So far, it looks like:
The attached plots are all generated from Fscan weekly and monthly averaged data. The feature can be seen most clearly in these long-duration spectra.
There is a git issue tracking the problem here, with some additional discussion history and more plots: https://git.ligo.org/detchar/detchar-requests/-/issues/273
WP 12139
Entry for work done on 11/5/2024
Two 3T seismometers were installed in the LVEA Biergarten next to the PEM area. Signals are routed through the SUS-R3 PEM patch panel into the CER. Signals are connected to PEM AA chassis 4 and 5.
F. Clara, J. Warner
There are 2 of these plugged in, they are 3 axis seismometers, serial numbers T3611670 and T3611672. The first one is plugged into ports 4,5 & 6 on the PEM patch panel, the second is plugged into ports 7,8 & 9. In the CER, T3611670 is plugged into ports 21,22 & 23 on PEM ADC5 and T3611672 is plugged into ports 27,28 & 29 on PEM ADC4. In the DAQ, these channels are H1:PEM-CS_ADC_5_{20,21,22}_2K_OUT_DQ and H1:PEM-CS_ADC_4_{26,27,28}_2K_OUT_DQ. So far the seismometers look like they are giving pretty good data, similar to the STS and the old PEM Guralp in the biergarten. The seismometers are oriented so that the "north" marking on the their carry handles is pointed down the X-arm, as best as I could with eyeballing it.
I need to figure out the calibrations, but it looks like there is almost exactly -15db difference between these new sensors and the old PEM Guralp, but maybe the signal chain isn't exatly the same.
Attached images compare the 3T's to the ITMY STS and the existing PEM Guralp in the biergarten. First image compares asds for each seismometer. Shapes are pretty similar below 40 hz, but above that they all have very different responses. I don't know what the PEM guralp is calibrated to, if anything, it looks ~10x lower than the STS (which calibrated to nm/s). The 3T's are about 5x lower than the PEM sensor, so ~50x lower than the STS.
Second image are tfs for the X,Y & Z dofs between the 3T's and the STS. These are just passive tfs between the STS and 3T's to see if the have similar response to ground motion These are generally pretty flat between .1 and 10hz. The X & Y dofs seem pretty consistent, the Z tfs are different starting around 10hz. I should go and check that the feet are locked and have similar extension.
Third image are tfs between the 3T's and the exist PEM Guralp. Pretty similar to the tfs with the STS, horizontal dofs all look very similar, flat between .1 and 10hz, but the ADC4 sensor has a different vertical response.
I'll look at noise floors next.
The noise for these seems almost comparable to T240s, above 100 mhz, less certain about noise below 100mhz, these don't have thermal enclosures like the other ground sensors. Using mccs2 in matlab to remove all the coherent noise with the STS and PEM Guralp, the residual noise is pretty close to the T240 spec noise in SEI_sensor_noise. Attached plots are the asds and residuals after finding a scale factor that matches the 3T asds to the calibrated ITMY STS asds. Solid lines are the 3T asd, dashed lines are the residuals after coherent subtraction.
For convenience I've attachd the response of the T240 and the STS-2 from the manuals.
These instruments both have a steep fall-off above 50-60 Hz.
This is not compensated in the realtime filters, as it would just add lots of noise at high frequency, and then we'd have to roll it off again so it doesn't add lots of nasty noise.
T240 user guide - pg 45
https://dcc.ligo.org/LIGO-E1500379
The T240 response is pretty flat up to 10 Hz, has a peak at ~ 50 Hz, then falls off rapidly.
STS-2 manual - pg 7
https://dcc.ligo.org/LIGO-E2300142
Likewise the STS-2 response is pretty flat up to 10 Hz, then there is ripple, and a steep falloff above 60 Hz
22:05 Observing