The OPO PZT voltage reached the threshold and the squeezer relocked. After squeezer relock, the BNS range and squeezing level were worse. We tuned the OPO temperature (attached figure) and the range and squeezing level came back.

All the FMCS EPICS channels have been static since around 11:00 this morning. The attached plot shows a representative channel from CS and each out-building showing they stopped updating between 10:47 and 11:06. Interestingly most of the EPICS channels did not go invalid, but some did. This explains the mixture of green/white values on the FMCS MEDMs seen this afternoon. Jonathan and Patrick restarted the FMCS IOC at 15:01, at which point all the EPICS channels went to VAL=0, SEVR=Invalid.

At the time of writing, the corner station chiller-yard and wood-shop FMCS channels continue to be good. Therefore I have un-bypassed the critical fire-pump alarms for the weekend.

The current cell-phone alarm bypass list is now

Bypass will expire:
Mon 11 Sep 2023 03:16:29 PM PDT
For channel(s):
    H0:FMC-CS_CY_H2O_PUMPSTAT
    H0:FMC-CS_CY_H2O_SUP_DEGF
    H0:FMC-CS_WS_RO_ALARM
    H0:FMC-EX_CY_H2O_PUMPSTAT
    H0:FMC-EX_CY_H2O_SUP_DEGF
    H0:FMC-EY_CY_H2O_PUMPSTAT
    H0:FMC-EY_CY_H2O_SUP_DEGF
 

Back to Observing at 1809 UTC. Fully automated relock.

This happened during the evening lock (Wed) for few modes at 1kHz. I will look into what causing them to switch off the gain at the start of the lock. The modes were really low on monitor (less than 1) and they remained like that for a long time, hence I didn't switch them ON at that time.

Before anyone worries we are boiling our brs's, that temp channel is .1 C, so 220=22.0C.

Edited wrong units (you'd have to ask my subconcious how that passed my sanity check).

It seems to be an issue with the T3 BOSEM on FC1

OSEM spectra of T3 BOSEM on FC1 shows that it is very noisy compared to the rest - see pic attached. Fil and I power cycled AA chassis and that did not make any difference. Fil and Dave are currently power cycling HAM7 electronics chain and Dave is also restarting the models (SUSH7).

I have moved all suspensions in HAM7 into SAFE state.

Power cycle of h1sush7 IO Chassis has not fixed the issue, front end computer has been powered off a second time, Fil is heading out to replace the first ADC.

BOSEM T3 is now looking healthy after Fil replaced ADC card, as shown in the spectra attached below. So we are back in action.

Ryan and I have brought all the suspensions in HAM7 to ALIGNED state.

Replacing the first ADC has resolved the FC1 T3 OSEM issue.

Work done under WP 11401.

FRS ticket 29047 filed and closed

https://services1.ligo-la.caltech.edu/FRS/show_bug.cgi?id=29047

Observation time lost due to this fault was approximately 6 hours.

Elenna, Sheila

We ran the noise budget code for this no squeezing time. 

• We updated the optical gain (Calibratations.py, in the closedLoopSenseing function) using the calibration report here which Jeff pointed us to.  (The most recent one with the exported tag is the current calibration.)  This is the same as the inverse of the gain in H1:CAL-CS_DARM_CFTD_ERR filter called O4 gain if you have the correct calibration report.  Elenna also found the ratio of DCPD mA to DARM err counts by running the template that measures their transfer function aligoNB/H1/couplings/check_DARM_gain.xml for the braodband pcal injection from alog 72047.  These two steps are what we needed to do to get the calibration right so that the semiclassical shot noise caluculation seems correct.  
• We are using CAL_DELTAL, since this noise budget was run before the calibration fix of last week that channel is more accurate.  We are also using the TDCFs kappa_c and the cavity pole to calculate the shot noise. The radiation pressure noise is calculated with the arm transmitted power monitors. 
• There is no DAC noise included in this budget, as we aren't confident in our usual DAC noise projection right now.  68869  With recent improvements in the low frequency noise it would be good for us to revisit the PUM DAC noise projections soon, by running in the higher noise state and running the noise monitor estimate for that higher noise state. 
• We have changed the frequency noise in this budget. We measure frequency noise by switching CARM onto one sensor, (REFL B), then using that sensor as a out of loop frequency noise sensor.  There was a mistake in the code where the psd was instead multiplied by sqrt(2).  We have now divided the PSD by 2, which should give us the correct frequency noise projection where we are frequency noise limited.  Interestingly, this correctly predicts the darm noise at 4-5kHz where it should be an underestimate by sqrt(2) in the ASD.
• Vicky is working on modeling the quantum noise with Kevin, we are just doing the no squeeze budget here and will return to the noise budget with squeezing with Vicky.  
• Also attached are the sub budgets for laser, asc and length noise, with the DARM noise plotted from a time with squeezing.
• Laser noise: The 120Hz peak is well predicted by the IMC PZT yaw injection.  The frequency noise has the factor described above applied, and there may be some double counting at low frequency although we aren't sure.  
• ASC: CSOFT P, and the hard loops are the dominant contribution.  CHARD Y in particular is large, this is because of Gabriele's recent loop change which helped reduce the RMS and improve some nonlinear noise in DARM. 71927 Elenna is looking at if we can roll that off to keep the low frequency gain without this additional noise at 40Hz. 
• LSC: MICH is the dominant contribution to LSC, it is similar to the level of the ASC total. 

This is all commited as 0f9ffe0e

Sheila, Vicky - we have re-run the noise budget for following times:

Noise budget with squeezing. Changes here: using GDS instead of CAL-DELTAL, closer thermalized FDS time to no-sqz, using updated IFO gwinc parameters related to quantum noise calculation.
(Edit: was a glitch in the old time; updated to an FDS time without glitches. All plots updated.)

PDT: 2023-08-10 08:45:00.000000 PDT
UTC: 2023-08-10 15:45:00.000000 UTC
GPS: 1375717518.000000

PDT: 2023-08-10 09:35:52.000000 PDT
UTC: 2023-08-10 16:35:52.000000 UTC
GPS: 1375720570.000000

Noise budget with no squeezing. Same time as above, now calculates using gwinc quantum noise calculation instead of semiclassical calculation used previously.

PDT: 2023-08-10 10:18:11.000000 PDT
UTC: 2023-08-10 17:18:11.000000 UTC
GPS: 1375723109.000000

Both sqz & no-sqz noise budgets now use the correlated quantum noise calculation from gwinc, instead of semiclassical calculations for SN & QRPN. The gwinc budget parameters related to quantum noise calculation are consistent with the recent sqz data set (8/2, alog 72565), with readout losses evenly split between IFO output losses that influence optical gain (20%) and SQZ injection losses (20%), parameters in plot title here. This is high on SQZ injection losses, and slightly conservative on IFO output losses. This updated FDS time is thermalized and closer to the No-SQZ time; the time used previously was several hours earlier near the start of lock, w/ ifo not yet thermalized.

Unlike before, both budgets now show GDS-CALIB STRAIN, which on 8/10 was more accurately calibrated (see Louis's alog on Aug 8, LHO:72075, comparing CAL-DELTAL and GDS vs. PCAL sweep, and his record from 72531). CAL-DELTAL was previously overestimating range due to calibration inaccuracies. We got GDS-CALIB_STRAIN data from nds servers, and at first weren't able to get input jitter data from nds, due to the sampling rate change of IMC-WFS channels from 2k to 16k, 71242. Jonathan H. helped us fix this issue, so we can now pull GDS data and input jitter data from nds.ligo-wa.caltech.edu:31200 -- thank you Jonathan!! With this, the input jitter sub-budget is kind of interesting, looks to be mostly IMC-WFS in YAW.

A quick thought on discrepancy between expected and measured DARM between below several hundred Hz-- I don't know if this could be related to the recent update to gwinc CTN parameters (high/low index loss angles), related to quantum noise, or mystery noise. The recent gwinc CTN update seemed to have dropped the calculated CTN level slightly (maybe 10-15% or so). In April 2023, Kevin helped update CTN parameters LHO:68499 to reconcile H1 budget with the official gwinc parameters, while Evan made a correlated noise measurement 68482 where noise in the bucket seems more consistent with the older CTN estimate from gwinc (or very slightly higher). Another idea is that it could be related to quantum noise, such as SRCL detuning or sqz angle which could've changed since the sqz dataset, as quantum noise can also affect the noise in this region.

All pushed as git commit 28cf2664.

Edit: All pushed again as git commit 33ffd60b.

Added noise budgets with squeezing for HVAC off time on August 17 from alogs 72308, 72297.

When comparing this HVAC off time on Aug 17 with the noise budget from above on Aug 10, it's interesting to note the broadband difference in input jitter (Aug 10 vs Aug 17, HVAC off). Between these times, worth noting that I think there were several additional improvements (like LSC FF or SUS-related) as well.

Edit: updated 8/10 input jitter budget to the less glitchy noise budget time.

Much of the gap between expected DARM (black traces) and measured DARM (red traces) in the noise budget looks compatible with elevating the CTN trace. Budget plots with 100 Hz CTN @ 1.45e-20 m/rtHz are attached below for the no-HVAC times. This is almost 30% higher than the new gwinc nominal CTN at 100 Hz (i.e., 1.128e-20 m/rtHz --> 1.45e-20 m/rtHz). Compared to the old gwinc estimate of 1.3e-20, this is ~11% higher. Quantum noise calculation unchanged here.

This CTN level is similar to the 30% of excess correlated noise that Evan H. observed in April 2023, see LHO:68482. His cross-correlation measurement sees ~30% excess correlated noise around 100 Hz after subtracting input jitter noise, where that "30%" is using the newer gwinc CTN estimate of 1.128e-20 m/rtHz @ 100 Hz. This elevated correlated noise, if attributed to CTN, corresponds to CTN @ 100 Hz of about 1.3*1.128 = 1.46e-20 m/rtHz. See this git merge request for the gwinc CTN update ; this update lowered the expected CTN at 100 Hz by ~15%, from 1.3e-20 (old) to 1.1e-20 m/rtHz (new), based on updated MIT measurements.

For reference, I have plotted these various CTN levels as dotted traces in the thermal sub-budget.

To elevate CTN levels by 30% in the budget code, I scaled both high+low index loss angles by a factor of 1.8, specifically Philhighn 3.89e-4 --> 7e-4 ; Phillown 2.3e-5 --> 4.14e-5. It seems like much higher than this level ~1.45e-20 might be difficult to reconcile with the full budget.

Noteworthy w.r.t. squeezing: from the laser noise sub-budget, laser frequency noise looks within 33% of squeezed shot noise with ~3.7dB of squeezing. By contrast, the L1 noise budget from Aug 2023 (LLO:66532) shows laser noise at the ~20% level of squeezed shot noise with 5.3 dB of squeezing -- i.e. a lower laser noise floor past shot noise.

The following plots can be found in /ligo/gitcommon/NoiseBudget/aligoNB/out/H1/lho_all_noisebudgets_081723_noHVAC_elevatedCTN, and not yet commited to the git repo.

Plots with higher CTN are attached here for the SQZ / no-SQZ proper noise budget times from 8/10, when injections were run.

Comparing the sqz vs. no-sqz budgets suggests there might be more to understand here, to tease apart the contributions from coating thermal noise (CTN) vs. quantum noise in the bucket. In particular, something disturbing that stands out, is that I imagined that if elevated CTN is the physical effect we're missing, it would reconcile both NBs with and without squeezing. However, there is still some discrepancy in the un-squeezed budget, which was not resolved by CTN, and seems to have a consistent shape. I'm wondering if this is related to the IFO configuration as it affects the quantum noise without squeezing. I think this could result from a non-zero but small SRCL detuning since it looks like elevated noise, with a clear shape, that increases below the DARM pole. Simply elevating CTN to match the no-sqz budget would put us in conflict with squeezed darm, so I don't think it makes sense to elevate CTN further. The budget currently has 0 SRCL detuning as it "seems small-ish", but this parameter is somewhat unconstrained in the quantum noise models.

In models, the readout angle is upper-bounded by Sheila's contrast defect measurement, though in principle it could probably be anything lower than that too, which could be worth exploring. It might be helpful to have an external measurement of the thermalized physical SRCL detuning, or in the models allowing the SRCL detunings to vary, to explore how it fits or is constrained by the fuller noise budget picture.

Plots with squeezing can be found in /ligo/gitcommon/NoiseBudget/aligoNB/out/H1/lho_all_noisebudgets. No squeezing plots are in /ligo/gitcommon/NoiseBudget/aligoNB/out/H1/lho_darm_nosqz_noisebudget.

I pushed to git commit 70ca191c without elevated CTN and the associated extra traces. The relevant parameters are left commented out at the bottom of the QuantumParams file, and relevant code to plot the extra traces is commented out in the lho_all_noisebudgets script.

As a part of depricating CAL_AWG_LINES, I've updated the ISC_LOCK guardian to use the new main switches for the DARM_EXC lines for the transitions between NOMINAL_LOW_NOISE and NLN_CAL_MEAS. 

That main switch channel is H1:LSC-DARMOSC_SUM_ON, which enables excitations to flow through to the DARM error point when set to 1.0 (and blocks it when set to 0.0).

I've committed the new version of ISC_LOCK to the userapps repo, rev 26039.

Here's the updated 
/opt/rtcds/userapps/release/lsc/common/medm/
    LSC_OVERVIEW.adl
    LSC_DARM_EXC_OSC_OVERVIEW.adl
    LSC_CUST_DARMOSC_SUM_MTRX.adl

The new DARM oscillators screen (LSC_DARM_EXC_OSC_OVERVIEW.adl) is linked in the top-middle of the LSC_OVERVIEW.adl. The only sub screen on the LSC_DARM_EXC_OSC_OVERVIEW.adl is the summation matrix (LSC_CUST_DARMOSC_SUM_MTRX.adl).

I have not yet gotten to adding all the new PCAL oscillators to their MEDM screens, but I'll do so in the fullness of time.

detchar-request git issue for tracking purposes.

I found a bug in the
    /opt/rtcds/userapps/release/lsc/common/medm/
        LSC_DARM_EXC_OSC_OVERVIEW.adl
where DARMOSC1's TRAMP field was errantly displayed as all the 10 oscillator's TRAMPs; a residual from the copy pasta I made during the screen generation.

Fixed it. Now committed to the above location as of rev 26170.

Finally got around to updating the PCAL screens. Check out 
    /opt/rtcds/userapps/release/cal/common/medm/
        PCAL_END_EXC.adl
        CAL_PCAL_OSC_SUM_MATRIX.adl
as of userapps repo rev 26179.

See attached screenshots.

This design is the result of ECR E2300227 and IIET:28681.

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!

This design became ECR E2300227 and IIET:28681.

It has been installed as of Aug 01 2023; see LHO:71881.