Thu Jul 27 10:05:59 2023 INFO: Fill completed in 5min 55secs
Travis confirmed a good fill curbside.
Sidd, Jane We used available data to look at the glitch rates so far during the run and compare to O3. The times used in the analysis were: O3: May 24th - July 10th (observing duration 2912751 secs) O4: May 24th - July 18th (observing duration 2922144 secs) The Omicron triggers used in this analysis were SNR above 7.5 and frequency between 10 Hz and 1024 Hz. The first plot shows the glitch rate between O3 and O4 during the times mentioned above. O3 May 24th - July 10th glitch rate: 16.08 per hour O4 May 24th - July 18th glitch rate: 19.86 per hour The second plot shows the glitch rate as a function of various SNR bins. We can see in this plot a reduction in the noise above an SNR of 50, whereas below 50 the rate has almost doubled as compared to O3. In the third image I've include the Gravity Spy classifications of the glitches (with confidence > 90%) and we can see that fast scattering is the dominating class. The increase in the fast scatter seems to be related to the increase in low frequency noise at around 20-40 Hz, shown in the fourth image of an Omicron glitchgram.
Following the new instructions found in the TakingCalibrationMeasurements wiki, I ran a broad band measurement and then the simulines script. Attached calibration monitor screen just before starting the BB. The new instructions don't mention running pydarm report any, but below are the locations of the hdf5 files that were generated.
Simulines start - 1374510089.146829
Simulines end - 1374511414.209376
2023-07-27 16:43:15,796 | INFO | File written out to: /ligo/groups/cal/H1/measurements/DARMOLG_SS/DARMOLG_SS_20230727T16211
2Z.hdf5
2023-07-27 16:43:15,843 | INFO | File written out to: /ligo/groups/cal/H1/measurements/PCALY2DARM_SS/PCALY2DARM_SS_20230727
T162112Z.hdf5
2023-07-27 16:43:15,855 | INFO | File written out to: /ligo/groups/cal/H1/measurements/SUSETMX_L1_SS/SUSETMX_L1_SS_20230727
T162112Z.hdf5
2023-07-27 16:43:15,867 | INFO | File written out to: /ligo/groups/cal/H1/measurements/SUSETMX_L2_SS/SUSETMX_L2_SS_20230727
T162112Z.hdf5
2023-07-27 16:43:15,879 | INFO | File written out to: /ligo/groups/cal/H1/measurements/SUSETMX_L3_SS/SUSETMX_L3_SS_20230727
T162112Z.hdf5
Out of Observing from 1543 -1544 UTC while the TCSX CO2 laser relocked itself. This has become a more frequent problem (summary alog71594) and Camilla tried adjusting the chiller setpoint this past Tuesday. Might be time to try swapping chillers as we did in O3.
FAMIS 25489
Laser Status:
NPRO output power is 1.826W (nominal ~2W)
AMP1 output power is 67.19W (nominal ~70W)
AMP2 output power is 134.8W (nominal 135-140W)
NPRO watchdog is GREEN
AMP1 watchdog is GREEN
AMP2 watchdog is GREEN
PMC:
It has been locked 8 days, 19 hr 52 minutes
Reflected power = 16.55W
Transmitted power = 108.5W
PowerSum = 125.0W
FSS:
It has been locked for 0 days 19 hr and 26 min
TPD[V] = 0.9562V
ISS:
The diffracted power is around 2.8%
Last saturation event was 0 days 19 hours and 26 minutes ago
Possible Issues: None
TITLE: 07/27 Day Shift: 15:00-23:00 UTC (08:00-16:00 PST), all times posted in UTC
STATE of H1: Observing at 148Mpc
CURRENT ENVIRONMENT:
SEI_ENV state: CALM
Wind: 7mph Gusts, 3mph 5min avg
Primary useism: 0.01 μm/s
Secondary useism: 0.04 μm/s
QUICK SUMMARY: Locked for 18 hours, everything is calm at the moment. I'll be taking us out of Observing shortly for a calibration measurement while LLO is down for logging.
TITLE: 07/27 Owl Shift: 07:00-15:00 UTC (00:00-08:00 PST), all times posted in UTC
STATE of H1: Observing at 145Mpc
SHIFT SUMMARY:
- 7:22 - inc 5.0 EQ from Vanuatu
- EX saturations @ 8:20/10:13/11:38/14:32
- 9:33 - Fire control panel alarm in the CUR went off, acknowledged alarm for now for this to be looked at in the morning, alarm notification in question attached here - Tagging FMCS
- 11:21 - inc 5.3 EQ from Russia
- All in all, a quiet night, leaving H1 to TJ with H1 in observing, currently at a 17:48 hour lock
LOG:
No log for this shift.
H1 is still observing (13:48 hours as of writing this). All systems appear stable, seismic motion is low.
TITLE: 07/27 Owl Shift: 07:00-15:00 UTC (00:00-08:00 PST), all times posted in UTC
STATE of H1: Observing at 146Mpc
CURRENT ENVIRONMENT:
SEI_ENV state: CALM
Wind: 4mph Gusts, 3mph 5min avg
Primary useism: 0.01 μm/s
Secondary useism: 0.04 μm/s
QUICK SUMMARY:
- CDS/SEI/DMs ok
- H1 has been observing for just under 10 hours
TITLE: 07/27 Eve Shift: 23:00-07:00 UTC (16:00-00:00 PST), all times posted in UTC
STATE of H1: Observing at 145Mpc
SHIFT SUMMARY: IFO is LOCKED and OBSERVING - same lock as before shift (23:06 UTC)
1. Dust counts in the optics lab were just high for the first 10 minutes of shift - all dust counts now within nominal range.
2. Went out of then back into observing for two seconds at 5:55:54 UTC due to a SQZ lockloss and relock - it was all automated.
3. The new H1_Manager is not giving me any trouble.
LOG:
| Start Time | System | Name | Location | Lazer_Haz | Task | Time End |
|---|---|---|---|---|---|---|
| 23:26 | CDS | Marc | MY | N | Looking for parts | 23:46 |
Tagging SQZ. This wasn't a SQZ unlock that kicked us out of observing but the sdf diffs we've beeen seeing related to the TTFSS gain changing. See alog 71658.
>> guardctrl log -a "5:54 UTC" -b "5:57 UTC" DIAG_SDF
2023-07-27_05:55:54.019533Z DIAG_SDF [RUN_TESTS.run] USERMSG 0: DIFFS: syscssqz: 2
IFO is in NLN and OBSERVING at 149MPc - same lock as from before the shift (23:06UTC).
A few earthquakes passed through from Samoa and Vanuatu and Verbal called them out appropriately (setting itself back to CALM/WINDY ~30 minutes after each alert).
Nothing else of note.
J. Kissel We now have heard from search groups that they don't (yet, definitively) mind having more calibration lines -- as long as they're subtracted. Further, we've re-found the need to make continuous measures of the low-frequency end of the sensing and response function. Finally, we want to use an excitation solution that is more robust than awg (which is what the recently re-started CAL_AWG_LINES guardian uses). As such, I propose the following changes: (1) In the PCAL models' library part: expand the same solution that's already in use -- front-end, synchronized oscillators whose parameters are controllable by EPICs -- piped into the same "LINE_SUM" channels that already exist and stored into frames. Since we always seem to find more uses for PCAL lines, I've added 20 more beyond the 10 that are already there, for a total of 30 at each end station. There're no new fast channels / test points needed, since we only monitor the SUM of all the oscillators, and that sum is already stored in the frames. (2) In the h1omc model's LSC block*** which contains the DARM control filters -- add front-end, synchronized oscillators 10 in total -- and sum them in to the error point of the loop, just down stream of DARM_ERR, just like the actual excitation point, DARM1_EXC. We'll only store the sum of the oscillators in the frames, like in the PCAL system using the pre-existing channel stored in the frames -- LSC_CAL_LINE_SUM -- so no new data storage burden there. However, because we're using these DARM calibration lines as measures of the open loop gain, loop suppression, and closed loop gain, we need to store the test point immediately *downstream* of the summation point, which, in H1's case is DARM1_IN1. (We'd already stored DARM1_IN2 as the test point just downstream of awg-style excitations -- which is still needed for swept sine and broadband excitations). (***the LSC block is intentionally *not* a library part, since L1's LSC control needs are different that H1's). So -- this proposal's impact on data storage is (20 PCALX + 20 PCALY + 10 DARM) oscillators * (5 EPICs records per OSC) = 250 new EPICs records at 16 Hz, and ONE new test point stored at 16 kHz. I attach screenshots of "before" vs "after" changes in the comments below. I'll now use this documentation to write the ECR to install, hopefully next Tuesday (7/31/2023).
PCAL library part, before vs. after.
I took the opportunity to re-organize other parts visually for clarity as well, but there's no functional change other than the 20 new oscillators.
Also, as a minor simulink detail -- the individual OSC blocks *had* been a library part with-in a library part bug since the beginning of time (someone copied and pasted the block, but forgot the annoying feature of library sub-blocks that if you copy a block within a model that's already a library, it stays linked to the original thing you copied. One needs to explicitly "disable link" and "break link" if you don't want that sub-block to reference the other). Instead, I *actually* made a new library part, since I new I wanted to copy the same thing to the LSC model.
Thus, the PCAL_MASTER.mdl library now relies on a new library part,
/opt/rtcds/userapps/release/cal/common/models
CAL_OSC_MASTER.mdl
which is manifested in the PCAL model as the oscillators "PCALOSC1," "PCALOSC2," ... "PCALOSC30".
2023-07-26_PCAL_MASTER_PCAL_OSCfocus_before.png shows the impacted parts of the PCAL_MASTER.mdl library part before the changes.
2023-07-26_PCAL_MASTER_PCAL_OSCfocus_after.png shows the impacted PCAL_MASTER after the changes.
2023-07-26_CAL_OSC_MASTER.png shows the new CAL_OSC_MASTER library block, and 2023-07-26_CAL_OSC_MASTER_inside.png shows the innards.
And here's the LSC block before and after the changes.
Here, again, I took the opportunity to aesthetically clean up the garbled mess that was all the things that have been stapled on and around the DARM bank over the years.
But, the only functional changes are
(a) the new oscillators,
(b) the move of the CAL_LINES summation point from into DARM_CTRL to into DARM_ERR,
(c) the DARMOSC_SUM test point and epics monitor, and
(d) the storage of DARM1_IN1 in the frames.
The changes (b) and (d) are "interesting." For old iLIGO reasons that I don't remember, the "DARM" calibration lines were summed in down stream of the DARM bank, i.e. into DARM_CTRL. Even though the infrastructure is there (I personally installed it circa 2012-2013), we haven't used these DARM calibration lines *at all* in the advanced LIGO era. This is because we quickly realized that we need such a "CTRL" excitation at each stage of QUAD's DARM actuation if we want to track the actuation strength of each stage of the QUAD separately like we do now.
Now, we want to re-invoke the "DARM" calibration lines to constantly measure the DARM open loop gain, G, or more specifically the loop suppression, 1/(1+G), so we can divide it *out* of an adjacent PCAL line measure of the response function, C/(1+G). But, as always, we need two test points surrounding it, the so-called "IN1" (just up stream of the excitation) and "IN2" (just down stream of the excitation) points.
Of course, when measuring live, it doesn't matter where in the loop this trifecta of IN1+EXC=IN2 system of channels are; you'll get the same answer whether it's up or down stream of the DARM banks.
BUT, while we already store DARM_ERR and DARM_OUT in the frames, which could both equally be the "IN1" channel,
- there was no convenient test point to store after the DARM OUT,
- I wanted the calibration lines to mimic the location of where the awg input DARM1_EXC was injected in the loop -- i.e. in between DARM1_IN1 and DARM1_IN2, and
- I figure the DARM1_IN1 test point (which comes by default with the DARM1 standard filter module) is already there and has a more natural name.
So, I moved the summation point.
So, when we analyze these calibration lines offline, we'll be taking the transfer function between the following channels to get the following equivalent loop characterizations:
H1:LSC-DARM_ERR_DQ / H1:LSC-DARM1_IN1_DQ == "IN1/IN2" == G
H1:LSC-DARM1_IN1_DQ / H1:LSC-CAL_LINE_SUM_DQ == "IN2/EXC" = 1/(1 + G)
H1:LSC-DARM_ERR_DQ / H1:LSC-CAL_LINE_SUM_DQ == "IN1/EXC" = G/(1 + G)
To the ECR process!
Following on from 71381, today during commissioning time, I injected 2.6Hz sine wave into in H1:OMC-SUS_M1_TEST_{L, P, Y, V, T, R}_EXC by increasing gradually the gain until when we reach the peak-to-peak amplitude around 40 urad or 4um on the H1:OMC-SUS_M1_DAMP_{L, P, Y, V, T, R}_INMON channels. I didn't get this amplitude in R or V due as any higher gain was causing DAC saturations.
DARM plot attached during these times. Can see a lot of coupling with P, Y, L. Not anything easily noticeable with R, V, T.
TITLE: 07/26 Eve Shift: 23:00-07:00 UTC (16:00-00:00 PST), all times posted in UTC
STATE of H1: Observing at 150Mpc
CURRENT ENVIRONMENT:
SEI_ENV state: CALM
Wind: 15mph Gusts, 11mph 5min avg
Primary useism: 0.02 μm/s
Secondary useism: 0.05 μm/s
QUICK SUMMARY:
IFO is in NLN and OBSERVING
Optics Lab dust monitor (300NM) is going off so will investigate
TITLE: 07/26 Day Shift: 15:00-23:00 UTC (08:00-16:00 PST), all times posted in UTC
STATE of H1: Observing at 143Mpc
SHIFT SUMMARY: Relocked two times today completely automatic. Longer period of commissioning today, but we are back into Observing now.
LOG:
| Start Time | System | Name | Location | Lazer_Haz | Task | Time End |
|---|---|---|---|---|---|---|
| 15:15 | FAC | Cindi | MX | n | Tech clean | 16:47 |
| 15:52 | FAC | Christina | Opt lab, MX | n | Property search | 16:19 |
| 16:22 | VAC | Jordan, Travis | MY | n | Hepta and turbo pump work | 16:57 |
| 16:56 | FAC | Cindi | Mechnal Room | N | Tech clean | 18:26 |
| 17:12 | PCAL | Tony, 2 Detchar | PCAL lab | local | PCAL lab measurement | 17:30 |
| 18:08 | FAC | Tyler | CS AHU | n | Looking into AH fan noise | 18:08 |
| 18:33 | FAC | Karen | Vacuum Prep | n | Tech Clean | 20:03 |
| 18:37 | - | Fanis, Christopher | arms | n | Drive down arms and film | 20:37 |
| 19:50 | SEI | Jim | cr | n | HAM1 loop test | 20:20 |
| 21:07 | FAC | Chris | MY | n | Grab items | 21:27 |
| 21:23 | ISC | Gabriele | remote | n | SRCLFF meas. | 22:00 |
| 22:00 | DetChar | Sidd | CR | n | HW safety inj | 22:14 |
| 22:15 | ISC | Camilla | CR | n | OMC shaking test | 22:45 |
Jenne, Sidd
Performed the safety injections at 1374444261.56. The injections information is uploaded on GraceDB playground. The details of injected parameters can be found here https://git.ligo.org/siddharth.soni/hardware_injections/-/tree/main/data
Sidd ran into the same error today as I did last time, so I added a comment to the hwinj git issue.
Now that we're back to our lower noise situation with OM2 hot, we're redoing the test that Oli ran in 71304 to look at how much different our noise is with and without the calibration lines on. We expect that this will primarily show that the noise right around the line frequencies is reduced, as suggested by Gabriele in 71614. I don't think we expect any major changes other than right around the lines, but if we do, that would be very interesting.
Since the low frequency calibration lines are back on this week (alog 71706), it took more 'doing' than normal to turn off the calibration lines. ISC_LOCK's NLN_CAL_MEAS does not currently turn off the CAL_AWG_LINES guardian-controlled lines, so I selected LINES_OFF in that guardian. However, that didn't actually stop all of the lines, so I also did an awg clear 8 * to stop the lines going to the DARM1_EXC. TJ is looking into ensuring that NLN_CAL_MEAS takes care of the awg lines.
I'm a little surprised, but I'm not seeing much of a difference in the spectra when the lines are on vs. off. All 4 panels are the same 4 traces (noted above in the bullet points), but zoomed differently. These traces are all of the GDS-CALIB_STRAIN_NOLINES, so for times that the calibration lines are on, they've been subtracted out of the data here (note that the 'new' CAL_AWG_LINES are not yet subtracted, so those are still present in this channel). I expected this channel to show some noise around the calibration lines for times when the Cal lines were on. But, I'm not really seeing anything.
I'm not sure if the PCALY_DARM lines are coming back on at the same height each time or not. It's possible that they are, and it's just that the attached ndscope can only look at 16 Hz channels, and so the beating between lines / aliasing is causing it to look like they are not. But, just to flag that we should check to ensure that the lines are coming on with awg at the amplitude requested.
Looking closely, one can see that the noise between 18 and 22 Hz is slighlty improved. It's small, but it's there.
