A while ago Robert helped me resurrect the T240 in the BRS enclosure at EY, which we want to see if we can use to get better subtraction from the BRS during windy times. Right now, it seems like the T240 sees more low frequency noise than the ground seismometer we currently have on the ground outside the BRS box, during both a quiet time last night and during 30mph winds on the 7th. First plot shows the asds during both times. Red, dark blue and bright green are during the windy time, dark green, pink and light blue are during the quiet time. For both times, the T240 in the enclosure shows more noise noise below .1 hz than the ground STS. It could be that there is more temperature variation for that seismometer or it's platform. During the quiet time, this extra noise probably wouldn't be a performance issue, if we used this sensor for feedforward, but I haven't looked at the effect  on the isi controls during windy time

But the coherence with the BRS is slightly better, shown in the second image. The red line on the second plot is the coherence during the windy time between the BRS and the ground STS, the dark blue line is the coherence from the enclosure seismometer with the BRS, and most places the blue line is slightly higher than the red. It is also interesting to compare the bright green and light blue lines, which are the coherence between the two seismometers during the two different times. I'm a little surprised how much coherence there is between the seismometers during the windy time (bright green line), I kind of thought we "knew"  the coherence lengths for tilt were too short for that much coherence. This seems to be true for the light blue line, which is the coherence between the seismometers during the quiet time.

   Attached below are the CPI noise spectra plots. All the HAM look OK. ITMX_ST2_CPSINF_H3, ITMY_ST2_CPSINF_V2, ETMY_ST2_CPSINF_V2 are elevated on the BSC plots.  

I compared spectrograms of CAL-DELTAL_EXTERNAL_DQ from an old lock when there was evidence of scattered light from OMC motion (47399, 2019-03-07 18:45:00 PST, 2019-03-08 02:45:00 UTC) with spectrograms from last night (2019-03-15 05:15:00 PDT, 2019-03-15 12:15:00 UTC, GPS: 1236687318).

In brief: there's no more evidence of scattered light noise at low frequency, see the comparison of the spectrograms below (left old, right new)

This might eb due to the fact that the OMC ASC signals all show much less motion. Below: high and low noise are two periods where there was high or low scattered light noise (correlated with OMC ASC motions), and new data is from last night. The OMC ASC signals move much less last night. This is probably due to the improvements described in 47488.

Sheila, Nutsinee

Here I plot a quick couple of data points from yesterday's measurement. A more detail analysis will come later (extracting sqz/asqz from higher averages DARM spectrum and fitting with the Monte Carlo). These sqz/asqz data points were acquired using the 10s average blrms around 1.65kHz. The loss of 40% fits the measurement pretty well (same as Livingston). We need more non linear gain to accurately determine the phase noise.

• ALS X had glitches this morning.  Sometimes they looked more like our classic 'rainy day' glitches, and other times it looked like the noise eater was oscillating (the difference being how often the glitches / noise happens - if it's constant, it's the noise eater).
  • Toggling the ALS X end laser's noise eater twice, the second time waiting more than 20 seconds before turning it back on, seems to have helped.  The first time I toggled it off, the noise immediately went away, but then started coming back a few minutes later.  Since the second time, it hasn't really been noisy.
• There is also some kind of big oscillation at 74.75 Hz.  It's very obvious when we get to TR_CARM if you look at the arm buildups or the CARM error signal.  A few times we've lost lock while doing TR_CARM and / or CARM_150_pm, but this last lock we made it through those, and lost lock on RF_DARM.
  • This last lock, I measured the COMM loop and the TR_CARM version of the loop once we'd made that transition, and both seemed totally fine loop-stability-wise. 
  • Sheila reminded me that Craig and Dan had some lines on (alog 47542) - I disabled the common mode board's excitation input, and the line is gone.  All better now.
• Lost lock at lowering the 9MHz modulation depth - Sheila has now turned off that excitation point.

Dan, Danny, Alexei

Tonight we powered up the SR3 heater again to 0.5W5W, we took a cal sweep before and after and can see it actually has a reasonable change (red with SR3, blue before SR3).

Once we had thermalised we tried some common CO2 increases, it didn't made a small improvement in PRG and arm power at the start but it didn't help with much more. I then zeroed CO2Y and dropped CO2X steadily to 0.2W. The range stayed fairly constant throughout all this but the arm powers and PRG got worse for most CO2 changes. I was adjusting the SRC1 offsets to try and maximise the cavity pole as we went along, there were some CO2 values giving higher kappa_c for the same cavity pole frequency.

The SR3 heater has been switched off and the CO2s have been set back to nominal. SRC1 offsets set back to zero. We're sat ~96Mpc up from 88Mpc before SR3, although given the calibration change I'm not sure what this range increase actually ends up being.

All this work was done from 1236673000 to 1236690900 if people are looking through the data during this time.

Robert, Sheila, Nutsinee

Better alogs will be coming with details, but earlier this evening we spent some time doing squeezing tests.  From about 20:50 UTC to 23:50 UTC (including time when IFO unlocked and was relocked), Nutsinee did measurements of squeezing and anti-squeezing for three different nonlinear gains.  

From 23:50 UTC Dick went into the CER to do a couple of tests, the IFO lost lock during this time.  

After relocking Robert and I did some test of the acoustic coupling from ISCT6.  Robert has more details, but some main points are:

• The coupling goes away when the squeezer beam diverter is closed
• The level of the coupling is higher for anti-squeezing than squeezing
• Increasing the gain of the CLF loop can reduce the coupling
• Changing the CLF power and keeping the UGF roughly the same does not change the coupling
• Changing the LO loop gain doesn't seem to change the coupling
• Changing the OPO loop gain doesn't seem to change the coupling
• Lastly we reduced the green power into the fiber from 20mW to 10mW we reduced the nonlinear gain from about 2.4 to 1.8, which only had a small impact on the acoustic coupling when anti-squeezing.  We scaled the OPO length servo gain, but not the gain of the other loops. 

We attempted to do the measurement where we offset the squeezer laser frequency from the PSL to see the two lumps in darm from backscatter and seeding.  The squeezer laser is moving too much relative the the PSL to do this measurement.  We could probably make this better by implementing the IMC VCO FF, or if we used a pick off that isn't in the ref cav path as they do at LLO we wouldn't have as much motion.  

Dan Brown, Craig

We are injecting lines into the DARM spectrum as follows:

Intensity: 76.4 and 3250 Hz
Frequency: 74.7 and 4500 Hz
9 MHz AM:  72.3 Hz

Keita, Anamaria

Following the work on pick-up on the PZT electronics at LLO, we find that there is coherence between PZT1 MON and DARM at various peaks! And PZT1 MON is so noisy that the noise is larger that the dither peak at 4.1k.

We would like to add toroids to these signals as soon as possible and will carefully check tightening of cables.

Keita, Sheila, Craig

We were confused about why my sign flip on the front end UIM stage helped flatten out the PCAL to DARM TF from last night.  Keita and I checked all the front end calibration filters, and things seemed to make sense without a sign flip.  We also injected some white noise during a lockloss and took a TF from CAL CS LOCK L3 IN1 to the calibrated outputs for each stage: H1:CAL-CS_DARM_ANALOG_ETMX_L{1,2,3}_OUT, as well as the summed total H1:CAL-CS_DARM_CTRL_DELAY_IN1, and compared this to Sheila's DARM model: the models matched well, and no sign flip seemed necessary.  
This seems like a good method of verifying the front end calibration, the template is too big to attach but is exists at /ligo/home/controls/craig.cahillane/Calibration/FrontEndDARMCalibrationCheck.xml

We reset all front end gains to 1.0 and remeasured PCAL to DARM.  Things were good to 2% from 25 Hz to 1000 Hz using the sensing function fit from yesterday and Jeff's actuator gains from here.  We decided to leave the front end calibration here, even though it underestimates DARM meters at 20 Hz by 10%, because the 20 Hz region doesn't have a huge effect on our reported BNS range.  We recognize that this will be a problem for overestimating BBH range, but given the good match at higher frequencies this is the best calibration we have.  

Sheila, Daniel, Nutsinee

Late alog, but here it is!

Quick conclusion: 25.3% loss calculated from measured 3MHz transimpedance and single sideband transmission during full IFO lock. I forgot to set the oscillascope to 50Ohms impedance when I took the measurement of RF in Vpk so that's where most of the uncertainty would come from (after correcting it by a factor of 2).

Details: To measured the transimpedance we bounce the beam of the ITMY (PR2, SR2 misaligned). We first scanned CLF single sideband (crystal temperature moved away from nlg region but optimized for co-resonance) with 24dB whitening on the OMC DCPD on. Then we locked the OMC and took note of the current read by the DCPD SUM (without 24dB whitening). Using the transimpedance at DC (400Ohms), Vrms measured off RF in (the one that goes into the common mode board, this is to avoid 23dB attenuation) and the 3MHz transmission of 0.1 (using the OMC cavity pole of 0.3MHz) we calculated the transimpedance at 3MHz to be 659.5Ohms.

Z_rf = V_rf_rms/sqrt(I_clf*I_cr)

Then during the full lock, using 20mA for DCPD sum current and Vrms of the 3MHz RF in measured on the floor we calculated CLF current:

Iclf = (1/Icr)*(V_ifo_rms/Z_rf)^2 

Using the DCPD responsivity of 0.858 A/W we calculated the loss to be 23.5%. The factor of 10 to correct for OMC transmission has been included. So this is the amount of loss we have between OPO -> SRM -> OMC input. 

The code used for this calculation is attached.

[Jon, Jamie, Chris, Craig]

Summary

We've developed and installed a new Python tool for budgeting IFO noise: aligoNB. At its core, this package contains Python translations of the Matlab scripts used to generate H1 noise budgets. However, it also significantly extends our noise-budgeting abilities:

• Ability to display "live" noise budgets, with traces updating every 2-3 sec. based on new witness-channel data from NDS (available only on-site)
• Ability to create hierarchical sub-budgets for any noise term
• All functionality accessible from a simple command-line interface, runnable from any control room machine

Several examples illustrating the different ways this tool can be used are shown below.

Using the code

In general, the code is executed from the command line with a budget argument (either "H1" or "L1") and one or more option flags configuring properties of the budget. The full usage can be printed to the terminal by executing the help command:  $ aligonb -h

Examples

1. Generate a live-updating noise budget

launches a window displaying the online (current) noise budget. By default, the traces auto-update every 3 seconds. The update interval can be changed by providing a numerical argument in seconds immediately after the --online flag.

2. Generate a static budget from a specific time

similarly generates a static budget for data in the GPS time range 1235813418 to 1235813418+60 seconds. If no time arguments are provided, the time range defaults to that of the last H1 noise budget.

3. Include only specific noise terms in the budget

generates a budget consisting of only the Quantum and ASC noise terms. The noise terms are separated by spaces and can be arbitrarily many.

4. List all available noise terms

prints the full list of available H1 noises to the terminal:

H1
H1.ClosedLoopSensing
H1.Dark
H1.Quantum
H1.Quantum.ClosedLoopSensing
H1.Quantum.Shot
H1.Quantum.RadiationPressure
H1.OMCLength
H1.DAC
H1.OSEM
H1.ASC
H1.ASC.CHARDPit
H1.ASC.CHARDYaw
H1.ASC.DHARDPit
H1.ASC.DHARDYaw
H1.ASC.MICHPit
H1.ASC.MICHYaw
H1.ASC.PRC2Pit
H1.ASC.PRC2Yaw
H1.ASC.CSOFTPit
H1.ASC.DSOFTPit
H1.ASC.SRC2Pit
H1.ASC.SRC2Yaw
H1.Intensity
H1.MICH
H1.SRCL
H1.InputJitter
H1.InputJitter.InputJitterPit
H1.InputJitter.InputJitterYaw
H1.ResidualGas
H1.Thermal
H1.Thermal.SuspensionThermal
H1.Thermal.CoatingBrownian
H1.Seismic
H1.Newtonian
H1.OMCASC
H1.OMCASC.OMCPosX
H1.OMCASC.OMCPosY
H1.OMCASC.OMCAngX
H1.OMCASC.OMCAngY
H1.Frequency
H1.CalLines
H1.CalLines.PCALY
H1.CalLines.PCALX
*H1.DARMMeasuredRef0
*H1.DARMMeasured

Noise terms beginning with an asterisk are reference traces, and are not included in the calculated noise total. Noise terms containing sub-components (e.g., H1.InputJitter.InputJitterPit and H1.InputJitter.InputJitterYaw) can be sub-budgeted as described below.

5. Generate a noise sub-budget

generates the budget of sub-terms which make up the ASC noise. In this case, the sub-terms are the contributions from each angular degree of freedom. Sub-budgets can be generated for any noise term which has sub-components defined (these can be identified using the  $ aligonb H1 -l  command described above).

Developing the code

Location and organization

Anyone working with the noise budget is welcome to edit the code as necessary. The code base is located at /ligo/gitcommon/Noisebudget/aligonb.

Relative to this directory, the file ./aligoNB/H1/budget.py contains the noise and budget class definitions. New noise terms can be defined here following the convention of the existing terms, and the new class name should be added to the list of noises inside the H1 class. Existing noise terms can also be modified as needed.

When a budget is generated, each noise class has three methods that are executed sequentially:

• load(): Reads in any static data from a DTT template, text file, etc.
• update(): Fetches NDS data for any channels specified in the "nds_channels" list attribute.
• calc(): Computes the noise term using the data loaded by steps 1 and/or 2.

The most common workflow is to load a measured coupling from file using load(), pull NDS witness-channel data using update(), and finally apply the coupling to the data using calc(). The methods are broken up this way to prevent static data from having to be reloaded every time a live budget updates. The load() method is called only once initially, while update() and calc() are called at every update.

The code is under git version control (https://git.ligo.org/NoiseBudget/aligoNB). We ask that any changes be pushed back to this central repository so that a master copy can be maintained. The issue tracker can be used to report bugs and to request new functionality.

Work in progress

Jamie is continuing to develop an improved user interface which will enhance the appearance of the plotting. He is also adding binary NS inspiral range information to the plots. Craig is working with Gabriele to implement an estimator of the total scatter noise, which will be a new addition to the H1 budget. Jon will work on producing an analogous Python translation of the LLO budget.

It seems that we could enhance our A2L decoupling by including the quadratic terms such as DH_P(t) * CS_P(t) when doing offline noise subtraction.

Please see the attached plot for an example. 

Details:

Note that a2l noise in t-domain is given by 

    dL(t) = dy(t) * dTheta(t),

where dy is the spot position and dTheta is the angular motion of a mirror. In the online A2L feedforward (as done in the SUS L2 stage), we do

    dL_ff(t) = dy(DC) * dTheta(t),

i.e., subtracting the dominating 'linear' coupling. The dither locking basically does the same thing as it servos dy(DC) to a fixed value. 

On the other hand, we also have

    dy(t) ~ dy/dTheta * dTheta( t - t_delay),

where dy/dTheta is a constant determined completely by the cavity's geometry. For the off-resonance 01/10 modes, the delay time is on the order

    t_delay ~ 2L/c ~ 3x10^{-5} sec,

which is effectively 0 for the A2L coupling we are interested in. 

As a result, it suggests that the A2L noise will contain terms like 

    dL(t) ~ dTheta(t)**2,

in the time domain. 

The argument above suggests that in the offline data cleaning, in addition to include the linear ASC terms, such as DH_P(t), we can also include quadratic terms that are the products of ASC outputs in the time-domain, e.g., DH_P(t) * CS_P(t). 

In the attached plot, the blue trace is the calibrated DARM ('GDS-CALIB_STRAIN') at gps: 1236207018 + [0, 2048] sec. I took 8 sec of data per fft and 50% overlap, thus 511 averages in total.

In the orange trace is the DARM after removing all the linear ASC coupling using a freq-domain MISO-coherence-based subtraction. We don't see any significant improvement over the noise, which is as expected as the soft dithering loops should zero the linear coupling. 

In the green trace, we further include quadratic ASC outputs and again do the freq-domain MISO-coherence analysis. This seems to improve the subtraction in the 10-30 Hz band where the ASC noise dominates.

The caveat is that the subtraction done so far are all in the freq-domain. I haven't tested how-well a t-domain Wiener filter could reproduce the result. More importantly, due to the amount of clean lock stretches available, we haven't checked how stationary the quadratic coupling is from one time to another. 

Nevertheless, the initial result seems promising, and including those quadratic terms should not be technically hard in the offline subtraction.