<b>TITLE:</b> 03/30 Eve Shift: 23:00-07:00 UTC (16:00-00:00 PST), all times posted in UTC
<b>STATE of H1:</b> Observing at 153Mpc
<b>OUTGOING OPERATOR:</b> Tony
<b>CURRENT ENVIRONMENT:</b>
SEI_ENV state: CALM
Wind: 6mph Gusts, 3mph 5min avg
Primary useism: 0.02 μm/s
Secondary useism: 0.23 μm/s
<b>QUICK SUMMARY:</b>
IFO is in NLN and OBSERVING as of 23:11 UTC
Other
1 Dust monitor not working properly - H1:PEM-CS_DUST_PSL101 Error: data set contains 'not-a-number' (NaN) entries
Broadband PCal (approximate) start time:
Calibration : 21:05 UTC
GPSTIME: 1395867918
pydarm measure --run-headless bb
Simulines start time:
gpstime;python /ligo/groups/cal/src/simulines/simulines/simuLines.py -i /ligo/groups/cal/src/simulines/simulines/newDARM_20231221/settings_h1_newDARM_scaled_by_drivealign_20231221_factor_p1.ini;gpstime
Start time:
PDT: 2024-03-30 14:15:18.460144 PDT
UTC: 2024-03-30 21:15:18.460144 UTC
GPS: 1395868536.460144
PDT: 2024-03-30 14:36:51.289748 PDT
UTC: 2024-03-30 21:36:51.289748 UTC
GPS: 1395869829.289748
Files written:
2024-03-30 21:36:51,207 | INFO | File written out to: /ligo/groups/cal/H1/measurements/DARMOLG_SS/DARMOLG_SS_20240330T211519Z.hdf5
2024-03-30 21:36:51,216 | INFO | File written out to: /ligo/groups/cal/H1/measurements/PCALY2DARM_SS/PCALY2DARM_SS_20240330T211519Z.hdf5
2024-03-30 21:36:51,222 | INFO | File written out to: /ligo/groups/cal/H1/measurements/SUSETMX_L1_SS/SUSETMX_L1_SS_20240330T211519Z.hdf5
2024-03-30 21:36:51,226 | INFO | File written out to: /ligo/groups/cal/H1/measurements/SUSETMX_L2_SS/SUSETMX_L2_SS_20240330T211519Z.hdf5
2024-03-30 21:36:51,231 | INFO | File written out to: /ligo/groups/cal/H1/measurements/SUSETMX_L3_SS/SUSETMX_L3_SS_20240330T211519Z.hdf5
Due to the DARM coherence with REFL RIN (76766) and measured PRCL/REFL RIN coupling (76805), I tried changing the PRCL offset to see if that would reduce this coupling.
I first began this test very early in the lock, so the coupling to REFL RIN was increasing with time due to thermalization. However, I was able to make a consistent improvement with the coupling by changing the PRCL offset. The improvement held an hour later as well. I found a minimum to the PRCL/REFL RIN coupling. This change also slightly improved PRCL coupling to DARM, and PRCL coupling to PRC2 Y and CHARD Y.
I changed the PRCL1 offset with a 30 second ramp, and started small. I was able to work up to making 10 ct step changes at a time with the long ramp. I also made sure to monitor the POP9 inputs to be sure I wasn't saturating the PD.
A positive PRCL offset made the PRCL/REFL_RIN coupling worse. To confirm I wasn't getting fooled by thermalization, I chopped this a few times. A +10 ct PRCL1 offset made the coupling worse even with the changes from thermalization.
Next, I took negative steps in the PRCL offset. I was able to see the phase flip sign between -60 and -70 ct. I narrowed this down to between -62 and -65 ct. This lines up with Gabriele's prediction from alog 76810.
See final plot of PRCL/RIN and PRCL/DARM here
Plots of PRCL/CHARD Y, PRC2 Y, SRCL and MICH here
I set the offset to -62 ct, and then chopped on and off a few times. PRCL/REFL_RIN coupling reduced by 33 dB. PRCL/PRC2 Y and PRCL/CHARD Y reduced by 7 dB. PRCL/DARM reduced by a few dB below 20 Hz. There was no significant change in the PRCL/MICH or PRCL/SRCL coupling.
I took two sets of quiet time for comparison:
1395862735 -62ct offset ON
1395863349 -62ct offset OFF
1395863966 -62ct offset ON
Gabriele and I do not see any change in DARM with this new offset. However, I think we should check how this has changed CARM at low frequency. Time pending, I'd like to rerun the frequency noise injections and see if there is any change at low frequency.
Other notes: when I first went to run quiet time, I noticed large peaks around 45 Hz in DARM. I checked the PRCL OLG to be sure everything was ok with the new offset. The peaks ended up being HAM3 scattered light from a beam dump Robert had removed. However, I noticed the PRCL UGF was low. Top of the phase bubble is 26 deg phase and around 30 Hz. I increased the PRCL2 gain by 30% to move the UGF from 22.5 Hz to 30 Hz. This is more in line with Evan's measurement, 76605. Plot here
Attached plot shows a comparison of DARM with and without offset. As Elenna said, unfortunately no change.
We also ran two BruCos with PRCL offset and without PRCL offset
Coherence with REFL_RIN is there without the offset, and it's gone with the offset.
Coherence with CHARD_Y is lower with the offset than without the offset. Same is true of coherence with PRLC: there without the offset, lower with the offset
I added this PRCL offset to the guardian. In the set up for "lownoise_length_control", the code sets the PRCL offset to zero, and a tRamp of 10 seconds, then it turns the offset on. Then, in the run state, the PRCL offset is engaged to be -62 in the same step that engages the SRCL offset.
There will be some SDF diffs due to this change.
Based on the PRCL injections I performed yesterday, alog 76805, I decided to try making adjustments of the PRM L2A gains to see if I could make changes to the PRCL/CHARD Y coupling. For the test, I adjusted the gain in the PRM M3 L2Y drivealign bank. I used a ramp time of 30 seconds and started small to avoid locklosses.
Generally, a positive L2Y gain made the PRCL/DARM coupling worse above 10 Hz. I tried gains of 0.01, 0.03, and 0.1. I saw the PRCL/DARM transfer function increase above 15 Hz at gains of 0.03 and 0.1 (no visible change at 0.01). There was no appreciable change in the PRCL/CHARD Y transfer function, but the coherence decreased as the gain increased. To confirm I wasn't being fooled by thermalization (we were locked for 4.5 hours during these tests), I went back to zero gain to confirm the transfer functions were still the same.
I then tried the negative direction. Gains of -0.03 and -0.1 reduced the PRCL/DARM transfer function above 15 Hz, but with the -0.1 gain I noticed an increase in the coupling below 10 Hz. Again, little change in the PRCL/CHARD transfer function, but a reduction in coherence with increasing negative gain. While I was thinking about what this means, there was a lockloss from ETM saturations. It appears the changing L2A gain caused the lockloss. There was a ring up in the DARM control signal at about 1 Hz. The increased coupling at low frequency is probably to blame.
A comparison of CHARD/PRCL and DARM/PRCL at 0, 0.1 and -0.1 PRM L2Y gain is shown here.
Also to note, during these tests I saw no change in the PRCL/MICH and PRCL/SRCL coupling.
Given that the PRCL/CHARD coupling is not changing appreciably, but the PRCL/DARM coupling is changing is probably a sign that we are incorrectly compensating for some other problem.
Sat Mar 30 10:09:46 2024 INFO: Fill completed in 9min 42secs
The Server we usually use for teamspeak is:
teamspeak.ligo.org , which I believe is a server hosted offsite, possibly at MIT, that is ping-able but teamspeak service is no longer working.
LLO's Operators Cannot Log in to this server either.
I reached out to Dave this morning about this, and he mentioned something right before he hung up to investigate that made me want look at the passwords page for another server name and password.
On the passwords pageI found another teamspeak server: teamspeak3.ligo.org . Which uses the same password as the old server!
I logged in and sent a link to Elenna to see if she could log in. Dave, Elenna, and I all met in there at effectively the same time and confirmed that it works.
Current issue with this is that there is not an LHO Control Room Channel, And I dont have the Credentials to make a permanent one.
I am Currently Hanging out in the LHO COMM/OPS MEETING ROOM.
If you have any questions about this please call the Operator at the LHO Control room @ (509) 372-8204
LLO has confirmed that they are also in this new Teamspeak server.
Ive been informed that Fred Donovan out at MIT, who manages that server, has corrected the teamspeak networking issue. We can now log back into the normal server: teamspeak.ligo.org, which has all of our normal channels. Thank you to Fred Donovan for finding & correcting the issue and David Shoemaker for reaching out to us know the issue is resolved.
TITLE: 03/30 Day Shift: 15:00-23:00 UTC (08:00-16:00 PST), all times posted in UTC
STATE of H1: Observing at 153Mpc
OUTGOING OPERATOR: None
CURRENT ENVIRONMENT:
SEI_ENV state: CALM
Wind: 13mph Gusts, 10mph 5min avg
Primary useism: 0.03 μm/s
Secondary useism: 0.21 μm/s
QUICK SUMMARY:
When I arrived H1 was locked for 4 hours but not observing.
I have since taken the Observatory mode to Observing until a comissioner decides to start running tests.
Team Speak is not working, I'm getting a Failed to Connect to server error. I'm restarting the verbals computer now.
Please call 509 372 8204 to reach the the control room until I can figure out how to fix teamspeak.
Everything else looks pretty good.
TITLE: 03/30 Eve Shift: 23:00-07:00 UTC (16:00-00:00 PST), all times posted in UTC
STATE of H1: Observing at 152Mpc
INCOMING OPERATOR: None
SHIFT SUMMARY:
IFO is in NLN and OBSERVING as of 06:08 UTC (56 min lock)
Lock Acquisition and Issues with PRMI Locking - Part 2
Check Midshift Update (alog 76807) for Part 1
The same weird brief PRMI behavior happened and it just couldn’t lock. I let guardian do its automation thing through MICH Fringes, but after PRMI unlocked 4 more times and couldn’t even recover PRMI from Down like last lock, I ran an initial alignment. While it was a slow initial alignment, it seemed to fix something because locking was extremely smooth (DRMI locked without PRMI).
It is worth mentioning that throughout my two lock acquisitions today, DRMI could not lock following PRMI/MICH - either DRMI locked immediately or we lost lock/got stuck some time after trying to lock PRMI.
LOG:
03:42 UTC - DRMI Unlocked, cause unknown
03:56 UTC - Lockloss at ENGAGE_DRMI_ASC after getting DRMI locked
04:52 UTC - Running initial alignment - locking getting nowhere and failing at PRMI, showing the same strange noisy trace
05:23 UTC - Initial Alignment complete - took an uncharacteristic 35 minutes
06:04 UTC - NLN Reached (41 mins from down!)
06:08 UTC - H1 is OBSERVING
Start Time | System | Name | Location | Lazer_Haz | Task | Time End |
---|---|---|---|---|---|---|
17:26 | ops | LVEA | corner | YES | LVEA is Laser HAZARD !!!! | 15:24 |
20:10 | PEM | Robert | LVEA | YES | PEM Injections | 20:43 |
20:44 | PRCL | Elenna | Remote | N | PRCL Investigations | 20:56 |
20:57 | SQZ | Naoki | CrtlRm | N | 100/100 ASQZ | 21:21 |
21:24 | CARM | Jenne W | CtrlRm | N | Common mode board tests | 21:25 |
21:29 | SQZ | Naoki | CtrlRm | N | 125/125 ASQZ | 21:52 |
21:53 | PEM | Robert | CtrlRm | N | Shaking Injection on the input arm. | 22:10 |
22:19 | PRCL | Elenna | Remote | N | PRCL Measurements. | 22:33 |
22:35 | SQZ | Naoki | CrtlRm | N | Quiet Time no Sqz | 22:51 |
22:52 | PEM | Robert | CtrlRm | N | PEM Shaking input side @ 12.6hz | 23:00 |
23:18 | PCAL | Tony, Francisco | Pcal Lab | Local | Getting LLO Intergrating Sphere | 00:18 |
23:47 | PEM | Robert | LVEA | YES | Taking photos | 00:47 |
TITLE: 03/29 Eve Shift: 23:00-07:00 UTC (16:00-00:00 PST), all times posted in UTC
STATE of H1: Locking
OUTGOING OPERATOR: Tony
CURRENT ENVIRONMENT:
SEI_ENV state: CALM
Wind: 11mph Gusts, 8mph 5min avg
Primary useism: 0.03 μm/s
Secondary useism: 0.26 μm/s
QUICK SUMMARY:
IFO is LOCKING - planning to go into ovserving as soon as we get to NLN
Other:
1 Dust monitor not working properly - H1:PEM-CS_DUST_PSL101 Error: data set contains 'not-a-number' (NaN) entries
IFO is in NLN and OBSERVING since 00:46 UTC (2 hr 25 min lock)
Lock Acquisition and Issues with PRMI Locking
While locking, we would only lock PRMI for a 5-10 seconds before it would lose lock (not complete lock, just PRMI). Interestingly, the same wiggly behavior was seen in the multiple PRMI locklosses (Screenshot 1). Trending LSC loops more generally (there was mention of movement before our last lockloss), there seens to have been motion in PRCL and MICH 5 seconds before the PRMI lockloss. In the 9s that this particular screenshot’s PRMI lock held, there was an oscillation seen in MICH OUTand more strongly in PRCL IN (screenshot 2). No clue if this is relevant but it seems to have happened before the PRMI lockloss so may have caused it.
Seeing that the input channels had notably more fluctuation in the signal, I checked the SRCL INand MICH IN and noticed that the LSC MICH IN signal was the loudest, getting a strange kick that seems to have led into the PRMI lock but got worse as time passed. Screenshot 3 illustrates this.
After 10 or so locklosses in PRMI, we lost total lock and interestingly, upon re-locking, this issue did NOT occur. I trended the LSC behavior during the DRMI lock (which was quickly successful and didn’t actually go through PRMI) and no LSC kicks were present. This leads me to think that there may be something exacerbating the PRMI locking and relocking (in the LSC loops) that does not affect the DRMI locking maybe?
Or maybe this is just a red herring and these loops always run for PRMI locking only but were a tad more aggressive in this alignment configuration so needed a total lockloss to “try again”.
SDF Diffs
Per Jennie’s direction, accepted SDF diffs that corrected previously accepted incorrect sdf diffs (screenshot 4).
Log:
00:39 UTC - Reached NLN
00:46 UTC - IFO is OBSERVING
[Elenna, Gabriele]
Elenna did two PRCL noise injections, at times separated by about 1h40m. We measured the transfer function to the other LSC loops and to REFL_RIN, since we observed coherence of DARM with RIN and DARM with PRCL.
The most striking observations are:
The transfer function PRCL_IN1 / PRCL_OUT should be a good measurement of the optical gain. The gain measured the second time is ~0.75 the gain measured the first time. So we're losing PRCL optical gain over time. Not a new story. Probably thermal effects.
PRCL to MICH and SRCL coupling got smaller.
PRCL to CHARD_P got smaller, but PRCL to CHARD_Y got larger (by a factor 3-4, depending on frequency). This might be explained if the beam spot is moving on the PRM over time, in yaw, to increase the length to angle coupling. It's interesting that this is happening in yaw and we know we have a yaw alignment problem in the PRC.
Another interesting coupling is from PRCL to REFL_RIN. Ideally we should not have any linear coupling from PRCL to REFL power. This could happen if PRCL or CARM were locked off resonance. The fact that the coupling RIN / PRCL is getting larger (by a factor 2) might indicate that the PRCL (or CARM) offset is changing over time. Probably thermal effects? Maybe also related to the change in optical gain?
Following up on the PRCL to RIN coupling. From a measurement in 68899, I estimate that the PRCL actuation strenght is 1e-7 microns/cts at 4 Hz, assuming the SUS-ISCINF counts are the same as PRCL_OUT counts and that the OSEM L witness is calibrated in microns. This allows me to convert the REFL_RIN / PRCL_OUT in REFL_RIN / PRCL displacement. It is fairly flat, and in the two measurements it changed from 200 1/um to 400 1/um
From a simply double cavity model, one can compute the RIN in reflection as a function of the PRCL and CARM offsets from resonance. The actual REFL power depends a lot on the losses and reflectivity of the mirrors, and here I haven't included any sidebands. So this is at best an order of magnitude guess.
This simple model shows as expected a linear dependency of PRCL > RIN coupling with the PRCL offset. To explain the measured coupling one should have a PRCL offset between 0.025 and 0.050 nm. This seems small enough to be realistic.
My guess is that this offset is probably due to higher order modes created by the yaw misalignment in the PRC
Using the same actuation strenght estimate, and the measured TFs from PRCL_OUT to PRCL_IN1, we can estimate the PRCL optical gain in the two cases: 2.3e6 and 1.7e6 cts/micron, where cts are measured at PRCL_IN1.
So the offsets that minimize PRCL to RIN would be 58 and 85 counts.
TITLE: 03/29 Day Shift: 15:00-23:00 UTC (08:00-16:00 PST), all times posted in UTC
STATE of H1: Commissioning
INCOMING OPERATOR: Ibrahim
SHIFT SUMMARY:
Nominal_Low_Noise Reached at 20:03 UTC
The Following comissioning tasks were attempted:
Robert
Elenna PRCL (current doing 20mins)
Naoki 100/100 ASQZ
Jennie CMB OLG measure at 1h30 in NLN
Naoki 125/125 ASQZ (20mins) until 2:50pm
Robert (20mins) until 3:10pm
Elenna PRCL (~10mins) until 3:30pm
Robert (20mins)
Camilla FF injections (maybe- could wait until we're better thermalzied Monday)
last 2 did not finish.
Lockloss at 23:00 UTC
Unknown source of lockloss, but there was a PEM group member in the LVEA "unplugging stuff" when the lockloss happened. More investigations needed.
ScreenShots attached.
LOG:
Start Time | System | Name | Location | Lazer_Haz | Task | Time End |
---|---|---|---|---|---|---|
17:26 | ops | LVEA | corner | YES | LVEA is Laser HAZARD !!!! | 15:24 |
15:50 | PEM | Robert | LVEA | YES | Veiwport Cameras | 17:50 |
16:12 | ISC | JenneW & Camilla | LVEA | yes | Power Cycling SR785 | 16:24 |
20:10 | PEM | Robert | LVEA | YES | PEM Injections | 20:43 |
20:44 | PRCL | Elenna | Remote | N | PRCL Investigations | 20:56 |
20:57 | SQZ | Naoki | CrtlRm | N | 100/100 ASQZ | 21:21 |
21:24 | CARM | Jenne W | CtrlRm | N | Common mode board tests | 21:25 |
21:29 | SQZ | Naoki | CtrlRm | N | 125/125 ASQZ | 21:52 |
21:53 | PEM | Robert | CtrlRm | N | Shaking Injection on the input arm. | 22:10 |
22:19 | PRCL | Elenna | Remote | N | PRCL Measurements. | 22:33 |
22:35 | SQZ | Naoki | CrtlRm | N | Quiet Time no Sqz | 22:51 |
22:52 | PEM | Robert | CtrlRm | N | PEM Shaking input side @ 12.6hz | 23:00 |
Jenne, Jennie
As we were about to go to Observing today, we noticed two DIFFs in observe in EYISC model.
Looking through the alog Jenne noticed that Ryan accepted these diffs the other day, but they showed up the opposite way round as diffs today meaning the guardian changed them back as we locked. Therefore the evening operator should accept these diffs to be
2 for COMBOOST and 6 for IN1GAIN.
Naoki, Vicky, Sheila, Camilla
To scan the sqz angle to optimize the squeezing in the bucket, we copied the SCAN_SQZANG state in SQZ_MANAGER guardian in LLO. This state will find the optimal sqz angle to minimize the BLRMS3 at 350 Hz. We replaced the 0.1 Hz LP with 1 Hz LP for BLRMS3. We will test this state tomorrow.
We tested the SCAN_SQZANG state and it seems to work. The result is saved here.
https://lhocds.ligo-wa.caltech.edu/exports/SQZ/GRD/SQZANG_SCAN/
Vicky, Naoki, Nutsinee
To scan the ZM alignment, we copied the SCAN_ALIGNMENT state in SQZ_MANAGER guardian in LLO. After some debugging, we successfully ran this state. The result is saved in here.
https://lhocds.ligo-wa.caltech.edu/exports/SQZ/GRD/ZM_SCAN/
This state scans the ZM4/ZM6 COM and DIF P/Y. We need the proper diagonalization to define the COM and DIF, but we have not done it today. The state fits the BLRMS6 at 1.7kHz and finds the optimal ZM slider value for minimizing the BLRMS6 as shown in the first attachment. After each ZM scan, the SQZ angle is also scanned and the optimal SQZ angle is found as shown in the second attachment.
The third attachment shows the BLRMS. The T1 cursor shows when the sqz-optimized scan was done. After the scan, the BLRMS6 looked good, but the BLRMS3 (yellow) was not so good and the BNS range was below 150 Mpc. So we tweaked the sqz angle and the BNS range reached more than 150 Mpc.
The original SCAN_ALIGNMENT tries to find the minimum of squeezing, but we modified it so that it can also try to find the maximum of anti squeezing. The T2 cursor in the third attachment shows when the asqz-optimized scan was done. The result is saved here.
sqz-optimized: https://lhocds.ligo-wa.caltech.edu/exports/SQZ/GRD/ZM_SCAN/240327132206/
asqz-optimized: https://lhocds.ligo-wa.caltech.edu/exports/SQZ/GRD/ZM_SCAN/240327144407/
The fourth attachment shows the ZM slider after the sqz-optimized and asqz-optimized scan. The ZM4 Y is almost the same, but other ZM alignment is different by 10-20 counts between the sqz-optimized and asqz-optimized scan. The proper diagonalization of ZM4/6 would resolve it.
Since the SCAN_ALIGNMENT touches the TRAMP of ZM slider, we reverted it after the scan as shown in the fifth attachment.
Screenshot of the SCAN_ALIGNMENT_FDS (105) guardian state maximizing anti-sqz, just like Masayuki's LLO:64903. This update to SQZ_MANAGER is committed to svn revision 27339.
It looks like this tuning improved the noise in the bucket. Maybe reducing the misterious excess broadband noise?
This also reduces the "excess noise" as estimated using Artem's method (computing the difference between the PSD now and in O4a).
Artem, Jennie W., Gabriele Following up on alog 76516. We compared DARM for following configurations: * No squeezing O4a, 12/20/2023 18:10-18:20 * With squeezing O4a, 01/12/2024 01:35:15-01:45:15 * No squeezing now, 03/17/2024 04:45:31-04:55:31 * With squeezing now, 03/17/2024 08:18:46-08:28:46 Specifically, following ASDs were calculated: sqrt(abs(no_sqeezing_now^2 - no_squeezing_o4a^2)), and sqrt(abs(squeezing_now^2 - squeezing_o4a^2)). These are shown as blue and red traces on the attached plot. The original DARM traces are shown in gray. Our preliminary conclusion from this is that it appears that excess noise is ~same with and without squeezing. We'll make this plot with longer time series and do some more tests. Jupyter notebook is available here.
Here is my plot which is just binning calibrated CAL-DELTAL_EXTERNAL_DQ and then excluding all the ASD values where the noise now is better than the noise in 04a (these are at low frequency and this is where our noise has improved due to ASC control noise improvements and new DARM configuration).
Then I use the same maths as Artaem to get:
excess noise with no squeezing = sqrt( (ASD with no squeezing now)^2 + (ASD with no squeezing in 04a)^2)
excess noise with no squeezing = sqrt( (ASD with squeezing now)^2 + (ASD with squeezing in 04a)^2)
These also seem to be the same in my plot, which implies that the excess noise is indeed due to some correlated noise (i.e. non-quantum).
See evolution and reduction with ZM alignment: 76757