Commissioning is complete and we have relocked. Observing at 1923UTC
ZM5 + ZM6 have had alignment dithers running accidentally in observing since Monday morning, which have now been turned off. (They were on from 9/16/2024 17:40 UTC until 9/19 16:47 UTC). These were small dither lines at 4.1 Hz, 3.5 Hz, 4.5 Hz, and 3 Hz.
BRSX has been running with it's heater almost maxed out at 9V for a while, meaning the hot pad has been sitting at about 50 C for a long time, so Tuesday I reduced the voltage to 7V and made an adjustment to the pico mass adjuster. Changing the heater voltage takes ~1day to settle out, the mass adjustment only took an hour or so to damp down. I adjusted the picomotor using the > button on the middle lower left control keypad on the overview in -1000 step increments. -1000 to engage the yoke, -2000 step adjustment to the mass, +1000 steps to disengage the yoke. This moved the dc position from around 0 to ~-6000. The 2V drop on the heater has now settled out to about +6000, and reduced the hot pad temp to about 40C, and reduced the igloo temp .3C . I think VEA temps trend up as weather cools off outside, higher temps push the dc position negative on this BRS, so I think I will wait a few weeks before making any more adjustments.
Followed instructions in 74681. Last done in 78782, 79988. Saved in /ligo/gitcommon/NoiseBudget/aligoNB/aligoNB/H1/couplings/ and pushed to git.
CHARD_P, CHARD_Y, MICH, PRCL, SRCL screenshots attached. The IFO had been in NLN for 4h15 when these were taken. The AS_A_YAW and PRCL offsets were turned off.
I modified the script used in 78969 to project PRCL noise to DARM through MICH and SRCL, and now added coupling through CHARD P + Y.
There is high coherence between PRCL and CHARD, but these active injections that Camilla did show that the main coupling of PRCL to DARM is not through CHARD.
This script is now in /ligo/gitcommon/NoiseBudget/simplepyNB/PRCL_excitation_projections.py (not actually a git repo)
Sheila, Vicky - we ran the noise budget using these updated couplings from Camilla.
Noise budget with squeezing - pdf and svg (and the quantum sub-budget with squeezing). Plots without unsqueezed DARM here: pdf and svg. Picked a time with high range, and good ~4.8dB squeezing.
Noise budget without squeezing - pdf and svg (and the quantum sub-budget without squeezing).
The remaining sub-budgets are for squeezed DARM: Laser, Jitter, LSC, ASC, Thermal, PUMDAC.
Noise below 25 Hz looks pretty well accounted for: 10-15 Hz ~ ASC (CHARD Y, then CSOFT P, CHARD P). 15-20 Hz ~ LSC (PRCL).
Some comments and caveats for these budget plots:
The code has been pushed to aligoNB repo, commit 95d3a88b. To make these noise budget plots:
Thanks to Erik von Reis for helping us update the aligoNB environment to newer python and scipy (etc) versions. Next to-do: have the budget code use median averaging to be more robust to glitches (which can be done now that the environment has an updated scipy!).
Ran the usual broad band and simulines following the wiki. I ramped the AS_A Y offset to OFF before starting this measurement.
Simulines start:
PDT: 2024-09-19 08:37:18.910765 PDT
UTC: 2024-09-19 15:37:18.910765 UTC
GPS: 1410795456.910765
2024-09-19 15:37:20,007 | INFO | File written out to: /ligo/groups/cal/H1/measurements/DARMOLG_SS/DARMOLG_SS_20240919T1
53719Z.hdf5
2024-09-19 15:37:20,021 | INFO | File written out to: /ligo/groups/cal/H1/measurements/PCALY2DARM_SS/PCALY2DARM_SS_2024
0919T153719Z.hdf5
2024-09-19 15:37:20,035 | INFO | File written out to: /ligo/groups/cal/H1/measurements/SUSETMX_L1_SS/SUSETMX_L1_SS_2024
0919T153719Z.hdf5
2024-09-19 15:37:20,046 | INFO | File written out to: /ligo/groups/cal/H1/measurements/SUSETMX_L2_SS/SUSETMX_L2_SS_2024
0919T153719Z.hdf5
2024-09-19 15:37:20,056 | INFO | File written out to: /ligo/groups/cal/H1/measurements/SUSETMX_L3_SS/SUSETMX_L3_SS_2024
0919T153719Z.hdf5
End:
2024-09-19 16:06:55,132 | INFO | File written out to: /ligo/groups/cal/H1/measurements/DARMOLG_SS/DARMOLG_SS_20240919T1
53719Z.hdf5
2024-09-19 16:06:55,144 | INFO | File written out to: /ligo/groups/cal/H1/measurements/PCALY2DARM_SS/PCALY2DARM_SS_2024
0919T153719Z.hdf5
2024-09-19 16:06:55,155 | INFO | File written out to: /ligo/groups/cal/H1/measurements/SUSETMX_L1_SS/SUSETMX_L1_SS_2024
0919T153719Z.hdf5
2024-09-19 16:06:55,166 | INFO | File written out to: /ligo/groups/cal/H1/measurements/SUSETMX_L2_SS/SUSETMX_L2_SS_2024
0919T153719Z.hdf5
2024-09-19 16:06:55,176 | INFO | File written out to: /ligo/groups/cal/H1/measurements/SUSETMX_L3_SS/SUSETMX_L3_SS_2024
0919T153719Z.hdf5
ICE default IO error handler doing an exit(), pid = 1416632, errno = 32
PDT: 2024-09-19 09:06:55.226746 PDT
UTC: 2024-09-19 16:06:55.226746 UTC
GPS: 1410797233.226746
The AS_A Y offset was turned off before this measurement, and it will stay off. I've accepted this in SDF observe.snap and removed it from ISC_LOCK.
Thu Sep 19 08:10:32 2024 INFO: Fill completed in 10min 28secs
Jordan confirmed a good fill curbside.
TITLE: 09/19 Day Shift: 1430-2330 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Observing at 154Mpc
OUTGOING OPERATOR: Ibrahim
CURRENT ENVIRONMENT:
SEI_ENV state: CALM
Wind: 4mph Gusts, 3mph 3min avg
Primary useism: 0.01 μm/s
Secondary useism: 0.10 μm/s
QUICK SUMMARY: Locked for 2hr41min. Calm environment. Planned calibration and commissioning today from 830-12 PT
TITLE: 09/19 Eve Shift: 2330-0500 UTC (1630-2200 PST), all times posted in UTC
STATE of H1: Observing at 153Mpc
INCOMING OPERATOR: Ibrahim
SHIFT SUMMARY:
H1's been locked almost 6.5hrs with a range hovering above 160Mpc (w/ only a few EX saturations on Verbal).
TITLE: 09/18 Eve Shift: 2330-0500 UTC (1630-2200 PST), all times posted in UTC
STATE of H1: Observing at 151Mpc
OUTGOING OPERATOR: Oli
CURRENT ENVIRONMENT:
SEI_ENV state: CALM
Wind: 21mph Gusts, 15mph 3min avg
Primary useism: 0.03 μm/s
Secondary useism: 0.09 μm/s
QUICK SUMMARY:
H1 was locked when I arrived (has been locked for 1.5hrs). Winds are a little up, but less than last night. All is looking well thus far.
TITLE: 09/18 Day Shift: 1430-2330 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Observing at 151Mpc
INCOMING OPERATOR: Corey
SHIFT SUMMARY: Observing at 155Mpc and have been locked for almost an hour. Quiet day with one lockloss but hands-off relocking.
LOG:
14:30 Relocking and at CARM_5_PICOMETERS
15:05 NOMINAL_LOW_NOISE
15:09 Observing
21:13 Lockloss
21:33 Lockloss from CHECK_MICH_FRINGES
21:38 Lockloss from FIND_IR
22:37 NOMINAL_LOW_NOISE
22:39 Observing
| Start Time | System | Name | Location | Lazer_Haz | Task | Time End |
|---|---|---|---|---|---|---|
| 15:03 | PEM | Robert | LVEA Receiving Door | n | Moving stuff | 15:05 |
| 15:30 | FAC | Eric | EX, EY | n | Checking glycol levels | 16:52 |
| 15:37 | FAC | Karen | Optics lab & Vac Prep | N | Technical cleaning | 15:53 |
| 19:12 | FAC | Kim | Receiving Door | n | Opening it | 20:12 |
| 20:37 | FAC | Tyler | MX, MY | n | 3IFO and Safety checks | 22:30 |
| 21:34 | FAC | Fil | Roof | n | Grabbing the lightning rod | 22:34 |
Jeff, Oli
I was looking over the Controls Summary Table and noticed a discrepancy between the Coil Driver Strength given in the table (11.9mA/V) and the value in the TMTS Controls Design Description(9.943mA/V). Using the make_OSEM_filter_model.m script along with looking at the driver circuit, Jeff and I were able to verify that the value shown on the Controls Design Description, 9.943 mA/V, was the correct value. The difference between the incorrect and correct value is over 19%!
We looked around at scripts that would use this coil driver value and found that the script we use for comparing transfer function measurements to the model, plotTMTS_dtttfs.m (found in $(sussvn)/TMTS/Common/MatlabTools/), had been using the wrong value to calculate the calibration, so that value was updated and committed to the svn. This difference will close the gap between the model and measurements. Thankfully that seems to be the only location where the wrong value was used.
Daniel, Marc, Fil, Richard, Erik, Dave:
Attached drawing shows the SUS ETMX DAC changes made yesterday.
Summary:
The new LIGO 28-bit DAC has replaced the h1susetmx model's 20-bit DAC signals. These comprise five L3 ESD signals, four L2 signals and four L1 signals.
The h1susetmx 18-bit DAC channels were not changed (the M0 and R0 signals).
The h1susetmxpi model's two 20-bit DAC signals were not changed, no h1susetmxpi model change was needed.
The routing of the h1susetmx model's L3, L2 and L1 signals to the 28-bit DAC was done using an existing matrix. Gains were applied using existing filter-modules. No h1susetmx model change was needed, this was a hardware change.
Details:
Please reference attached drawing and h1susetmx model snipet.
The h1susex front end comprises two ADCs, three 18-bit DACs, two 20-bit DACs and the new LIGO DAC. Setting the ADCs aside;
The third 18-bit DAC is only used by the h1sustmsx model, and so can be discounted.
The first two 18-bit DAC cards are used by h1susetmx (driving M0 and R0). These were not touched and are not applicable.
The first 20-bit DAC card is used by h1susetmx to drive L1 and L2 (four channels each).
The second 20-bit DAC card is shared between the h1susetmx and h1susetmxpi models. h1susetmx owns the first six channels, and drives five of them (L3-ESD DC+4QUAD). h1susetmxpi owns the last two channels (ESD left and right).
There are two types of Anti-Imaging (AI) chassis used here: the standard 18-bit/20-bit DAC AI (two inputs, each input is driven by a separate DAC), and the Parametric Instability (PI AI) chassis. The PI-AI has one input (block of eight channels) which internally are split into two blocks of six and two channels. The block of six channels is filtered normally and exits as chan 1-6 on front panel ('OUT 1-6'), the block of two channels is PI filtered and exits on its own front connector ('Band Pass Ch 7 & 8'). See attached photo.
Before:
The first 20-bit DAC is connected to one half of a standard AI chassis. Its output drives the L1, L2 signals.
The second 20-bit DAC is connected to a PI-AI chassis. The first 6 channels are driven by h1susetmx, the last two by h1susetmxpi.
The LIGO DAC is not connected to any AI chassis.
Now:
A second PI-AI chassis was installed in the rack, it is used to drive h1susetmxpi's DAC channels.
The first 20-bit DAC was disconnected from its AI (see note below).
The second 20-bit DAC was disconnected from the original PI-AI and connected to the new PI-AI. The PI driver cable was moved from the original to new AI. This means that other than the AI chassis change, the h1susetmxpi model and its drives were unchanged.
The first 8 channels of the LIGO DAC are connected to the original PI-AI (with its L3/ESD field cabling intact). Therefore the ESD analog filters were not changed in the transition from 20-bit to 28-bit DAC.
The second 8 channels of the LIGO DAC are connected to the standard AI (was connected to first 20-bit DAC). This permits drive of L1 & L2.
The attached MEDM snapshot shows the matrix/gain settings. The first 5 channels are driving the ESD, the second block of 8 the L1/L1.
Complications:
Initially the first 20-bit DAC (h1susetmx L1 & L2) was going to be left disconnected from any AI. However the lack of an AI watchdog signal put this DAC into error. Marc connected this DAC to a second input of a PI-AI chassis. This input does not internally connect to any filter block, but the interface card does supply the missing AI watchdog signal.
The IOP model's software watchdog (SWWD) needs to have the new LIGO DAC added to its DACKILL list, now that the new DAC is part of production.
Looking at data from a couiple of days ago, there is evidence of some transient bumps at multiples of 11.6 Hz. Those are visible in the summary pages too around hour 12 of this plot.
Taking a spectrogram of data starting at GPS 1410607604, one can see at least two times where there is excess noise at low frequency. This is easier to see in a spectrogram whitened to the median. Comparing the DARM spectra in a period with and without this noise, one can identify the bumps at roughly multiples of 11.6 Hz.
Maybe somebody from DetChar can run LASSO on the BLRMS between 20 and 30 Hz to find if this noise is correlated to some environmental of other changes.
I took a look at this noise, and I have some slides attached to this comment. I will try to roughly summarize what I found.
I first started by taking some 20-30 hz BLRMS around the noise. Unfortunately, the noise is pretty quiet, so I don't think lasso will be super useful here. Even taking a BLRMS for a longer period around the noise didn't produce much. I can re-visit this (maybe take a narrower BLRMS?), but as a separate check I looked at spectra of the ISI, HPI, SUS, and PEM channels to see if there was excess noise anywhere in particular. I figured maybe this could at least narrow down a station where there is more noise at these frequencies.
What I found was:
I was able to run lasso on a narrower strain blrms (suggested by Gabriele) which made the noise more obvious. Specifically, I used a 21 Hz - 25 Hz blrms of auxiliary channels (CS/EX/EY HPI,ISI,PEM & SUS channels) to try and model a strain blrms of the same frequency via lasso. In the pdf attached, the first slide shows the fit from running lasso. The r^2 value was pretty low, but the lasso fit does pick up some peaks in the auxiliary channels that do line up with the strain noise. In the following slides, I made time series plots of the channels that lasso found to be contributing the most to the re-creation of the strain. The results are a bit hard to interpret though. There seems to be roughly 5 peaks in the aux channel blrms, but only 2 major ones in the strain blrms. The top contributing aux channels are also not really from one area, so I can't say that this narrowed down a potential location. However, two HAM8 channels were among the top contributors (H1:ISI_HAM8_BLND_GS_X/Y). It is hard to say if that is significant or not, since I am only looking at about an hours worth of data.
I did a rough check on the summary pages to see if this noise happened on more than one day, but at this moment I didn't find other days with this behavior. If I do come across it happening again (or if someone else notices it), I can run lasso again.
I find that the noise bursts are temporally correlated with vibrational transients seen in H1:PEM-CS_ACC_IOT2_IMC_Y_DQ. Attached are some slides which show (1) scattered light noise in H1:GDS-CALIB_STRAIN_CLEAN from 1000-1400 on Septmeber 17, (2) and (3) the scattered light incidents compared to a timeseries of the accelerometer, and (4) a spectrogram of the accelerometer data.
TITLE: 09/18 Day Shift: 1430-2330 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Lock Acquisition
OUTGOING OPERATOR: Ibrahim
CURRENT ENVIRONMENT:
SEI_ENV state: CALM
Wind: 5mph Gusts, 3mph 3min avg
Primary useism: 0.01 μm/s
Secondary useism: 0.08 μm/s
QUICK SUMMARY:
Relocking and at CARM_5_PICOMETERS. Not sure yet why we lost lock, but it might've been an earthquake.
Lockloss from earlier this morning, 2024-09-18 13:39UTC, wasn't caused by an earthquake, but by the FSS saturating. This is the first FSS_OSCILLATION lockloss that we've had from NLN in a year
Back to Observing 15:09UTC.
Had to accept this sdf diff for ETMX_L3_ESDOUTF_LR to get into Observing. This change happened during TRANSITION_FROM_ETMX. Since this is our first relock since the DAC was changed out yesterday at EX, wondering if this was related at all to those changes.
I probably had a stray mouse click that turned that decimation filter off, and then did my SDF-accepting of the state of FMs 9 and 10 of the ESDOUTF filter banks. Thankfully it was just the decimation filter that I had wrong, which doesn't affect our sensitivity in any way.
Anyhow, I have updated the safe.snap file to accept the decimation filter being correctly ON (see attached). This will show up as an SDF diff again (opposite of what Oli posted this morning) in Observe and should be accepted. I don't want to set it in Observe right now, since accepting would require changing other things with the ETM, which I don't want to do right now. So, it'll stay as a diff.
Andrei, Sheila
This morning we are taking the commissioning time to get a sqz data set similar to 77133 with longer averaging time and no other changes to the IFO happening in parrallel.
Data times:
After this data collection, we ran SCAN_SQZANG, which resulted in a demod phase of 184.35
In the attached screenshots the units are different in the top and bottom plots, I filed a dtt bug because the plot disappears if I try to change the units on the bottom plot: 403
Late post of the subtracted quantum noises (FIS (+FDAS) and FDS).
While differences in dB look big on those plots, see these comparisons of just the quantum noise models relative to the total noise (FIS and FDS) -- below 100 Hz, these are really marginal / small differences in the quantum noise, which by 100 Hz is order 2-5 times below total DARM noise. So inferring low-frequency (<100 Hz) quantum noise paramters does require quiet glitch-free (rejected) long averaging times to nail down. So, this helps appreciate why figuring out low-freq quantum noise models is kinda tricky, given we can only measure the total noise in different sqz configurations. So far this analysis code is here.
Note due to the glitch in the no-sqz time, median averaging is required, or else we need to truncate to before the glitch (e.g. 400 seconds vs the full 600). Updating the noise budget environment to run median averaging, which requires the updated (but not fully updated) version of scipy, is underway so noise budget code can use median averaging.
I think several things related to quantum noise budgeting have changed since this sqz dataset in May 2024 (i.e. post-vent, including srcl detuning & fc detuning lho79929 amongst many other things) - so likely another sqz dataset in this vein is needed for more accurate quantum noise budgeting in O4b.
The parameters here in the figure titles are what was used to produce the quantum noise trace. It is rather "simple" at this stage, it does not yet include mode-mismatch, etc. The models do not match measurements well below 40-60 Hz, in part because noisy measurements (note the short 10-min measurement times).
Notably anti-squeezing does not match models well below 80 Hz, see anti-sqz vs. models after subtracting classical noise here. Including mode-mismatches may be able to resolve some of the discrepancies, but so far kinda unclear.
SQZ ADS dithers are now OFF during observing. See SDFs accepted - the ADS dither gains are set to 0 (so it is off), and the ASC gains and sensing matrix have bene reverted to the previous settings for AS42 ASC.
This should resolve the dithers being accidentally left on the past few days, see Sheila lho80185.
We lost lock during commissioning because of a big (100 cts) PIT step of ZM4, when it's TRAMP = 0.1. That TRAMP being too short was due to a guardian setting bug during SCAN_ALIGNMENT, which is now fixed. We tried the big ZM4 step in an attempt to re-measure the AS42 sensing matrix using ZM4 instead of ZM5, since the ZM5 steps gave very small changes in AS42 WFS with significant P/Y coupling. Measuring the AS42 sensing matrix with ZM4+6 might be worth trying again in the future (especially - check that ZM4 slider TRAMPS are >1 second).
The TRAMPs for ZM4,5,6 slider offsets are all set to 3 seconds now, and that has also been saved in SDF.