TITLE: 10/30 Day Shift: 15:00-23:00 UTC (08:00-16:00 PST), all times posted in UTC
STATE of H1: Observing at 155Mpc
OUTGOING OPERATOR: Austin
CURRENT ENVIRONMENT:
SEI_ENV state: CALM
Wind: 2mph Gusts, 1mph 5min avg
Primary useism: 0.03 μm/s
Secondary useism: 0.47 μm/s
QUICK SUMMARY: IFO been in NLN for 4h40
High Pitched Fire Panel alarm in the CUR was on 15:58 to 15:00:45UTC as the FAC team worked with the fire system. Tagging DetChar
ITMY mode 5 and 8 are not damping so I will try turning gains to zero, plot attached. 73826. Tagging SUS.
ITMY mode 8 was damping with old settings rather than gain = 0 that Ryan had saved in lscparams as VIOLIN_DAMPING was not yet reloaded, will plan to do this when out of observing.
I've put Ryan's new ITMY#8 FM1+FM6+FM10, G=+0.4, settings which is damping it well. I have left ITMY#5 at 0 gain for now.
There is no noticeable change in the data quality at 14:58 (assuming there is a typo in the original log entry). I've attached a spectrogram of the strain data from 14-15UTC. There is non-stationary noise at low frequency throughout the hour and no change is visible at the time of the fire alarm.
I reloaded VIOLIN_DAMPING guardian so it will now keep ITMY#8 gain at 0 to avoid ringing up. Also changed ITMY#5 gain at 0 after talking with Rahul. Tagging SUS.
The H1 system gave me a call this morning (~10:20 UTC 10/30), but when I checked the system in NoMachine, the IFO was at INCREASE DARM OFFSET and relocking and I couldn't find any issue (perhaps the timer ran over the limit?). However, once we got to NLN (10:26), I did see that the SQZ_MANAGER guardian was having some trouble, showing the warning, SQZ ASC AS42 not on??? in the guardian message log. It would cycle between this message and going back into FDS, so I hit RESET_SQZ_ASC before trying to go back into FDS, which looked to have solved the issue. - Tagging SQZ.
Tony and I looked into this and the reason Austin was called was that the IFO had been relocking for 2 hours so the H1_MANAGER's 2 hour "wait_for_nln" timer was up. The reason for the long relocking period was a lockloss at LASER_NOISE_SUPPRESSION 575 state 1382693851, Ryan had a lockloss here this weekend too 73787.
NLN Lockloss at 8:20UTC - 1382689308
TITLE: 10/30 Eve Shift: 23:00-07:00 UTC (16:00-00:00 PST), all times posted in UTC
STATE of H1: Observing at 157Mpc
INCOMING OPERATOR: Austin
SHIFT SUMMARY: We stayed locked the whole shift 13:07 as of 07:00UTC, I found new settings for ITMY mode8 (FM1+FM6+FM10, G=+0.4) and possibly ITMY mode5/6 (FM6+FM8+FM10, G=-0.02) I left mode 5s gain at zero since I'm not too sure about it yet.
05:21 I went to comissioning to run a calibration measurement alog73828
05:53: Back to Observing
INFO | bb output: /ligo/groups/cal/H1/measurements/PCALY2DARM_BB/PCALY2DARM_BB_20231030T052240Z.xml
Simulines:
GPS start: 1382678928.729304
GPS stop: 1382680256.772195
2023-10-30 05:50:38,627 | INFO | File written out to: /ligo/groups/cal/H1/measurements/DARMOLG_SS/DARMOLG_SS_20231030T052832Z.hdf5
2023-10-30 05:50:38,648 | INFO | File written out to: /ligo/groups/cal/H1/measurements/PCALY2DARM_SS/PCALY2DARM_SS_20231030T052832Z.hdf5
2023-10-30 05:50:38,659 | INFO | File written out to: /ligo/groups/cal/H1/measurements/SUSETMX_L1_SS/SUSETMX_L1_SS_20231030T052832Z.hdf5
2023-10-30 05:50:38,671 | INFO | File written out to: /ligo/groups/cal/H1/measurements/SUSETMX_L2_SS/SUSETMX_L2_SS_20231030T052832Z.hdf5
2023-10-30 05:50:38,683 | INFO | File written out to: /ligo/groups/cal/H1/measurements/SUSETMX_L3_SS/SUSETMX_L3_SS_20231030T052832Z.hdf5
ICE default IO error handler doing an exit(), pid = 2479290, errno = 32
STATE of H1: Observing at 155Mpc
TITLE: 10/29 Eve Shift: 23:00-07:00 UTC (16:00-00:00 PST), all times posted in UTC
STATE of H1: Observing at 160Mpc
OUTGOING OPERATOR: Camilla (DAY)
CURRENT ENVIRONMENT:
SEI_ENV state: CALM
Wind: 6mph Gusts, 3mph 5min avg
Primary useism: 0.02 μm/s
Secondary useism: 0.20 μm/s
QUICK SUMMARY:
The action of loading new filter modules likely caused an (expected) interruption in the output of the real-time model on h1lsc0 - this is the cause of the transient DAQ checksum (CRC) error
TITLE: 10/29 Day Shift: 15:00-23:00 UTC (08:00-16:00 PST), all times posted in UTC
STATE of H1: Observing at 156Mpc
INCOMING OPERATOR: Ryan C
SHIFT SUMMARY: Didn't take calibration measurements as we weren't thermalized, if LLO is down Ryan with take it.
LOG: ITMY mode8 was increasing so I turned off the gain this morning and then used half the gain (0.1) with the opposite sign to slowly damp it this afternoon. Ryan tried this in 73812. Nothing changed in lscparams but Ryan thinks we should save lscparams to keep gain at zero if we have a lockloss. Tagging SUS.
SHG PZT volts was close to railed at 100V with temperature drifts, see attached. We do have a checker for this when the IFO isn't in NLN 71595 but this drift was quick. It automatically relocks at a better PZT value (56V, middle of range). It unlocked at 22:33UTC and we were back in observing at 22:46.
SHG was v. quick to relock but the FC was slow, not really finding IR ad failing at TRANSITION_TO_IR. it took ~7 attempts to lock. I paused SQZ_FC in DOWN after 4 failed lock attempts an touch FC2 as in 73797 but the green FC trans was already good. After 3 more attempts it locked itself.
Sun Oct 29 10:09:07 2023 INFO: Fill completed in 9min 3secs
After 3h56 at NLN. 1382630509 this is the longest lock we've had in 24 hours.
Similar glitches in DARM/ETMX in the 750ms before lockloss, see attached and compare to 73817, 73578, 73539.
After 4 locklosses at LOCKING_ALS, started initial alignment at 16:38UTC, finished at 16:58UTC. We had to go though PRMI locking even after initial alignment. NLN at 17:52UTC. Observing at 18:16UTC (24 minutes for ADS to converge).
High frequency SQZ is again 73798 starting bad, with DARM > 3kHz worse than NO_SQZ. Touched OPO temperature, attached, didn't help.
In this lock and the last I turned off ITMY Mode 8 gain as Ryan did 73812 as it is slowly ringing up, tagging SUS.
As yesterday, 73804, we still have some large temperature drifts in LVEA zone 5. Plot attached. Also seeing EY VEA temperature drop, will keep an eye on this..
TITLE: 10/29 Day Shift: 15:00-23:00 UTC (08:00-16:00 PST), all times posted in UTC
STATE of H1: Observing at 155Mpc
OUTGOING OPERATOR: Austin
CURRENT ENVIRONMENT:
SEI_ENV state: CALM
Wind: 3mph Gusts, 2mph 5min avg
Primary useism: 0.01 μm/s
Secondary useism: 0.14 μm/s
QUICK SUMMARY: IFO has been locked for 3 hours. Plan to do calibration measurements at 11amPT.
There was a lockloss at 10:49UTC 1382611811 after 3h45 at NLN. Followed by an automatic relock (3 locklosses around DRMI locking).
The overnight lockloss had DARM / ETMX looking strange in the 0.5s before, see attached. We've been noticing this sort of lockloss in the past few weeks, e.g. Oli's 73578 analysis, 73539.
Took MICH FF measurements following instructions in lsc/h1/scripts/feedforward/README.md but running MICHFF_excitation_ETMYpum.xml. Data saved in lsc/h1/scripts/feedforward/ as .txt files. Last tuned MICH in 73420.
I saved a new filter in FM6 as 27-10-23-b (red trace) but it made the MICH coupling worse between 20 and 80Hz so we left the original (pink trace). We could try to re-fit the data to load in Wednesday's commissioning period.
I re-fit this data and think i have a better filter saved (not loaded) in FM3 as "27-10-23-a". We could try this during a commissioning period this week if we wanted to try to further improve MICH.
Tried this FM3 FF 2023/11/14 16:04:30UTC to 16:06:30UTC. It did not cause a lockloss. I did not run the MICH comparism plot but DARM looked slightly worse. Plot attached.
From 16:07:05, I tried FM6 which is the currently installed MICH FF (FM5) without the 17.7Hz feature 74139.
I tried to test a new MICH FF FM3 Camilla made. First I measured the current MICH FF FM5 as shown in the attached figure. The pink and black curves are the current MICH FF FM5 on 20231027 and 20231103, respectively. The current MICH FF gets worse between 30-80 Hz in a week. The MICH FF on 20231103 was measured after 6.5 hours into lock. Then I ramped the MICH FF gain to 0 and turned off FM5 and turned on FM3. After I ramped the MICH FF gain to 1, a lockloss happened immediately.
Sorry that this caused the 1383077917 lockloss.
Unsure why this FM3 would be unstable. Lockloss occurred 10 seconds after MICHFF had finished ramping on (13s - 3sec ramp time). FM3 MICH_FF looks to be outputting ~ factor of 2 higher than the current FM5 filter. Don't see any obvious instabilities in the 10seconds before the lockloss.
LSC and ASC plots attached. I wonder if the lockloss was just badly timed. We could attempt to repeat this before our Tuesday Maintenance period.
Sheila, Naoki, Camilla
We took FDS, Anti-SQZ and Mean SQZ data at different NLGs: 14, 17, 43, 82 and 123. We think we see evidence of frequency noise. We see less squeezing at high NLGs: around 4.5dB of SQZ at NLG < 43.1 but at NLG 81.9 and 122.8, squeezing at 1kHz reduced to 3.6 and 3.1dB. Attached Plot.
Each time we optimized SQZ angle around 1kHz. Because of this, the low frequency increased noise at high NLGs could be due to incorrect rotation, rather than phase noise.
Time (UTC)
|
Demod phase
|
DTT ref#
|
NLG |
SQZ dB at 900Hz
|
|
FDS
|
21:23:40-21:26:00
|
152.25
|
3
|
13.9
|
-4.3
|
FDAS
|
21:27:30- 21:32:30
|
228.10
|
6
|
13.9
|
15.2
|
Mean
|
21:33:47- 21:38:00
|
-
|
7
|
13.9
|
12.7
|
No SQZ
|
21:40:00 -21:44:50
|
-
|
0
|
-
|
|
FDS (not optimized)
|
21:51:20 -21:54:30
|
164.57
|
Deleted
|
43.1
|
-4
|
FDAS (Left ASC off)
|
21:56:00 -21:59:45
|
226.2
|
5
|
43.1
|
19.1
|
FDS (retake)
|
22:03:00 -22:06:13
|
167.42
|
4
|
43.1
|
-4.3
|
Mean
|
22:06:45 -22:09:52
|
-
|
8
|
43.1
|
16.9
|
FDS
|
22:37:50- 22:41:00
|
172.16
|
9
|
122.8
|
-3.1
|
FDAS
|
22:42:43-22:45:45
|
217.67
|
10
|
122.8
|
24.7
|
Mean
|
22:46:35 - 22:49:55
|
-
|
11
|
122.8
|
|
FDS
|
22:57:30- 22:59:40
|
169.31
|
12
|
81.9
|
-3.6
|
FDAS
|
23:01:20 - 23:02:55
|
219.56
|
13
|
81.9
|
22.7
|
Mean sqz
|
23:03:26 - 23:05:45
|
-
|
14
|
81.9
|
20
|
FDS (left IFO here)
|
23:19:38
|
154.14
|
15
|
17.1
|
-4.5
|
Data saved in /camilla.compton/Documents/sqz/templates/dtt/20231025_GDS_CALIB_STRAIN.xml
Time (UTC)
|
Unamplified OPO OPO_IR_PD_LF
(Scan Seed)
|
OPO trans (uW)
|
OPO Temp (degC)
|
Amplified (maxium) H1:OPO_IR_PD_LF
(Scan OPO PZT)
|
NLG
(Amplified / (Unamplified Peak Max - Unamplified Dark Offset))
|
|
Peak Maximum | Dark Offset | |||||
21:15
|
786e-6
|
-16e-6
|
80.54 uW
|
31.446
|
0.0112
|
13.9
|
21:44
|
|
|
100.52
|
31.414
|
0.0346
|
43.1
|
22:17
|
|
|
120.56
|
31.402
|
0.160
|
199.5 (SQZ loops went unstable)
|
22:30
|
|
|
110.5
|
31.407
|
0.06617
|
82 (didn't use)
|
22:36
|
|
|
115.46
|
31.405
|
0.09853
|
122.8
|
22:52
|
|
|
110.5
|
31.407
|
0.0657
|
81.9
|
22:09
|
769e-6
|
-15e-6
|
80.5
|
31.424
|
0.0137
|
17.1
|
Vicky and Naoki did an NLG sweep on the Homodyne in 73562.
Edits to NLG table in above alog: Last measurement was at 22:09 23:09 UTC. For measuring unamplified we scanned OPO PZT and for amplified we scanned SEED PZT.
Setup for each SQZ Measurement:
Attached are fits of squeezing loss, phase noise, and technical noise to this NLG sweep on DARM: we can infer 25-30% total SQZ losses, ~25 mrad rms phase noise, with technical noise almost -12 dB below shot noise.
Losses are tracked in the SQZ wiki and gsheet. Of the 30% total inferred loss, we expect 20%: that is 7.5% injection loss, and 13.7% readout loss.
Remaining ~10% mystery loss is compatible with mode-mismatch: in sqz-omc single bounce mode scans, LHO:73696, we estimate 8-15% mismatch, and we observe the frequency-dependence of the mismatch as we vary squeezer beam profile using PSAMS: 73400, 73621.
In the fits, [loss, phase noise, technical noise] are fit to the measured SQZ and Anti-SQZ, given the measured NLG, using equations from the aoki paper. "Loss from mean sqz" is the calculated loss from the measured NLG and measured mean-sqz dB; it is not a fit, but depends on the calibration from NLG to generated SQZ dB.
Some summary slides here show the progression of our loss hunting, which are so far lining up with Sheila's projections from 73395.