I have made an updated noise budget using the Cal Delta L trace. Currently, there is no channel with online cleaning implemented, although that is a work in progress. We can use this noise budget and the traces to estimate how much more sensitivity we might gain when the cleaning is applied. Also, The current cal delta L trace is calibrated, so no calibration"fudge" was required to make this budget.

I reran all injections for the ASC, LSC, Laser and Input Jitter budget. Kevin and Vicky have been working on the proper calculation of the quantum vacuum trace, and the quantum subbudget. This budget uses the "semiclassical" estimation, which may not be fully accurate. However, for these purposes, I think it is sufficient.

I purposefully removed the PUM DAC noise from this budget, as I am worried that the calculation may be inaccurate. Craig recently switched coil driver states to get a projection of our current PUM DAC noise (alog 68489). Craig states that this projection is 20 times lower than what the noisemons are telling us. I think it is best to leave out the DAC noise until we can determine what is correct.

Subbudgets:

• LSC: we are currently limited the most by MICH noise
• ASC: we are currently limited the most by CHARD P
• Laser noise: At low frequency, the jitter and frequency noise are comprable, at the mid range we are limited the most by jitter
• Input Jitter: the largest contribution seems to be in yaw

Overall, compared to the 60W noise budget (alog 68382), the noise traces are about the same. That budget showed us limited by MICH (if you ignore PUM DAC), and limited by jitter. The high frequency laser noise has improved. The ASC budget has improved. We are still limited by unknown noise in the mid range.

I will follow up with a comparison of the NB traces at 60W and 76W. I think if we can subtract the jitter noise, especially in the bucket, the comparison will show us improved sensitivity in the region when operating at higher power.

No suprise that the M1 offloading of PRM length actuation caused a large 3.4 Hz peak.

With the IFO down, I measured the PRM length lock actuation in three configurations:

1. only M3, no offloading to M1
2. M3 + M1 offloading with filters used in NLN and nominal gain of -0.02
3. M3 + M1 offloading with filters used in NLN and reduced gain of -0.01, the gain that we showed yesterday to reduce the 3.4 Hz peak in PRCL

Look at the attached plot: when offloading to M1, we create a huge peak at 3.3 Hz in the PRM actuation, and the trasnsfer function is very different from what we get with M3 only. Reducing the gain by a factor of two improves the situation just a little bit.

So PRM offloading need some work.

I took measurements of the M1 and M3 actuations, we can use them to design a new offload.

I wonder if the other HSTS are in the same situation: SRM has a very similar offload filters (with gain of -0.01)

TITLE: 04/20 Day Shift: 15:00-23:00 UTC (08:00-16:00 PST), all times posted in UTC
STATE of H1: Commissioning
CURRENT ENVIRONMENT:
    SEI_ENV state: CALM
    Wind: 9mph Gusts, 5mph 5min avg
    Primary useism: 0.02 μm/s
    Secondary useism: 0.17 μm/s
QUICK SUMMARY: H1 just unlocked after 7 hours as I walked into the Control Room, will start invesitgating the cause. Holding in DOWN to run PRM measurements. BRSY is ON.

• CDS, SEI, SUS all okay
• All dust monitors okay
• No alarms overnight

This is a feature that has been noted in other alogs, such as 68679, but there is a recurring transient noise source from approximately 20-40 Hz. It appears as a broad peak or bumpy structure, usually starting at 20 Hz. The peaks appear to be spaced about 4 Hz apart. This structure has been visible in the past, but it appeared very frequently in DARM tonight. The broadness and prominence of the peaks vary; sometimes they are much sharper, and have more harmonics. I have been loosely keeping a list of times when it appears, and I attempted to run a bruco on one of those times but it didn't indicate any additional coherence from 20-40 Hz than normal.

I'm tagging DetChar and PEM to hopefully follow up more on this!

Tonight after IFO thermalization, I remeasured the frequency noise and the contrast defect. Earlier in the day we changed the ring heaters to be set to 1.3 W on EX and 1.1 W on EY. The contrast defect is now down to 1.7 mW, comprable to a measurement made recently by Dan. Our frequency noise has also reduced at high frequency.

I have added a new frequency noise trace to the plot I put in a comment in alog 68842. See new plot below. I was sure to turn on LSC FF this time during the measurement. Comparing the brown and purple trace, our frequency noise is reduced from the ring heater change.

We could either step ETMY up again to 1.2 W and see if we gain even more, or we can call this setting good enough and stay here. The CO2s have some effect on the frequency noise, so we may be able to tune more improvement there.

J. Kissel, L. Dartez

I updated the calibration using pydarm export to push CALCS filter changes and EPICS records for TDCF calculations. The TDCF EPICS records pushed include the new _exact_ TDCF channels that Aaron Viets is testing out. In short, H1:CAL-DELTAL_EXTERNAL_DQ is calibrated to within 3% of H1:CAL-PCALY_RX_PD_OUT_DQ in magnitude up to about 450Hz (see syserr.png). However, we've negatively affected the GDS pipeline (see below) and we still need to debug the calculation of the TDCF channels, which are not producing sensible results (see tdep_ndscope.png). 

GDS Pipeline
This calibration has introduced a non-physical effect in the GDS pipeline (see darm.png), pointing to an issue with one of the new filter settings pushed today. I'm leaving the calibration up for now since it's decent in CAL-DELTAL_EXTERNAL / the control room. I'm going to be interfacing with the cal group to improve the GDS pipeline calibration and push new settings ASAP.

 Pcal demods
I cleared out the Pcal demods since the phase correction they are meant for is taken care of in pyDARM (through calcs.compute_epics_records(endstation=False, exact=True)), see (tdep_pca_demods.png).

I've also attached a screenshot of the relevant CALCS filterbanks (filter_after_cal.png), showing that I've cleared the previous fudges. A screenshot of the SDF changes for this calibration update are also attached.

The latest pyDARM report, which informed this cal update is attached as a pdf (see H1_calibration_report_20230420T014029Z.pdf).

Jennie, Elenna, Craig

For seven calibration meeasurements over the last two weeks I captured the thermal state of the interferometer, and used the broadband calibration injection taken at that time, and a 10 minute DARM measurement from a nearby quiet time, to get the calibration corrected DARM plots.

The thermal states were captured using thermal_state_capture.py in labutils.

The data was processed using Run_DARM_calib.ipynb in ligo/jennifer.wright/Documents/thermal_state

The BB injection measurements I used are in: /ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/O3/H1/Measurements/FullIFOSensingTFs

The DARM spectra I used for quiet times are in /ligo/home/jennifer.wright/Documents/thermal_state
 

Calibrated DARM plots are saved in /ligo/gitcommon/labutils/pcal_bb_inj_quick_cal/plots and data is saved in /ligo/gitcommon/labutils/pcal_bb_inj_quick_cal/data 

I am going to add post some more DARM measurements from other days as I process them.

J. Kissel

As a fall out of the installation of the newly updated D1900052-style coil driver noise monitor circuits LHO:68796, I've made the effort to understand the frequency response of the circuit (more on this later, but spoilers can be found in G2300866). Now that I have that understanding, I want to calibrate the signals with filters in the front-ends. To do *that* I need (a) easy access to the filter banks to install and turn on that calibration. Once saved in the foton file, I need to *load* those filters, so I need (b) easy access to the GDS_TP screen for the computer that houses these filters.

When I arrived at these issues, the coil driver monitor MEDM screens only had easy access to four-channel filter bank screens for the FASTIMON coil driver monitor channels, and no link anywhere to the "susaux" computers that house those filter banks.

To solve (a) I've created new four-channel NOISEMON screens, and added links to them on the BSFM and HXTS coild driver monitor screens.
    /opt/rtcds/userapps/release/sus/common/medm/bsfm/
        SUS_CUST_BSFM_M2_NOISEMON.adl        # new screen
        SUS_CUST_BSFM_MONITOR_OVERVIEW.adl   # updated to add links to NOISEMON screen and SUSAUX GDS_TP screen
    /opt/rtcds/userapps/release/sus/common/medm/hxts/
        SUS_CUST_HXTS_M2_NOISEMON.adl        # new screen
        SUS_CUST_HXTS_M3_NOISEMON.adl        # new screen
        SUS_CUST_HXTS_MONITOR_OVERVIEW.adl   # updated to add links to NOISEMON screen and SUSAUX GDS_TP screen
        



To solve (b), as you can see by the hashtag comments next to the MONITOR_OVERVIEW screens mentioned above, adding links to the SUSAUX computer's GDS_TP screens means I need to edit the macro files for all HXTS and the BS in order to make sure the generic link to the GDS_TP screen works. Every suspension that has coil driver monitors on a separate computer (which is all of them) could use these extra macro variables. But, given that I want to get out of this rabbit hole, I've only done this for the BS and HXTS so far. The following macro files, 
    /opt/rtcds/userapps/release/sus/common/medm/
        susbs_overview_macro.txt
        susfc1_overview_macro.txt
        susfc2_overview_macro.txt
        susmc1_overview_macro.txt
        susmc2_overview_macro.txt
        susmc3_overview_macro.txt
        suspr2_overview_macro.txt
        suspr3_overview_macro.txt
        susprm_overview_macro.txt
        sussr2_overview_macro.txt
        sussr3_overview_macro.txt
        sussrm_overview_macro.txt
now all have new variables
    AUXFEC, auxfec             (upper and lowercase macros for the DCUID for the sus aux computer; e.g. susauxh34 -- covering MC2, PR2, and SR2 -- has DCUID, or AUXFEC=108.),
    AUXFECNAME, auxfecname     (upper and lowercase macros for the computer name; e.g. FC2's coil driver monitor model is h1susauxh8, so auxfecname=susauxh8)

These changes have all been committed to the above locations in the userapps SVN. 
For LLO to import these benign yet very useful updates, just svn up the above mentioned common directories.

@opsinfo -- making these same updates for the quad, double, and single MEDM coil driver monitor screens and macros would be some excellent "chair work" if anyone wants to play along with me.

Stay tune for more details as I fill out these filters.

From the brute force search for the 3.4 Hz peak it turned out that the peak was dominating PRCL and visible in the PRM suspension signals.

I compared the M1/M3 offloading of PRM adn SRM, that should be nominally the same. I discovered that PRM M1 path has a gain of -0.02, the double of the gain in SRM M1 (-0.01). The offloading filters and the M1 damping filter are the same.

So tried reducing the M1 gain from -0.02 to -0.01. This had a clear and repetible effect on the 3.4 Hz peak. The lower offload gain reduced the peak a lot in PRCL, PRM and in many ASC signals (CHARD_P, CHARD_Y, CSOFT_Y and DSOFT_Y).

The first plot shows the PRCL_IN1 RMS reducing when changing the PRM M1 gain: there is an evident reduction since ther 3.4 Hz peak is dominating the PRCL motion in normal conditions.

The second plot shows how much the peak is reduced by changing the M1 gain: red and green are with high gain (-0.02) and blue with reduced gain (-0.01).

We shoudl measure and retune the PRM M1 and M3 crossover: there is room for further improvement.

The UGF servo for PRCL is working. For the moment being I'm injecting a line at 52.1 Hz. The plan is to track the evolution of the PRCL gain over a few locks. Hopefully we can then hard code the gain changes over thermalization and get rid of the gain servo.

The servo has a time constant of about one minute.

All parameters have been saved to SDF safe. Except:

• line amplitude H1:LSC-PRCL_UGF_OSC_CLKGAIN = 10
• servo input switch H1:LSC-PRCL_UGF_SERVO_SW1
• servo master switch H1:LSC-PRCL_UGF_MASTER

   

The H1 DMT system has been experiencing instability since early this morning.  This means that the GDS data is not available (via NDS2 or otherwise), including CALIB_STRAIN and the sensemon range.  Will report back when the issue has been resolved.

Elenna, Vicky

Operating with high generated sqz level ~ 16.5 dB, with IFO at 76W input, ~435 kW circulating, Elenna changed the SRCL offsets and we measured coherent SQZ rotations based on SRCL detuning.

Some takeaways:

• SRCL detuning + filter cavity detuning compound as coherent sqz rotations. Mis-rotations between FC + SRCL hit hardest in the bucket. With high generated squeezing levels, this matters more, because the cavities rotate in the elevated anti-squeezing noise. We will need to pick a generated SQZ level for O4, which optimizes quantum noise in the bucket.
  • This is almost certaintly anti-squeezing getting rotated in, changing generated sqz levels changes this excess bucket sqz rotation from SRCL, see this plot from LHO:68251 where we varied gen. sqz levels.
• FC is too narrow (~70 Hz FWHM) to un-rotate both the SRCL and RPN rotations of squeezing and anti-squeezing. FC is designed to un-rotate RPN (radiation pressure noise), largely below 100 Hz.
  • We have sometimes had to move the FC detuning to counter-act SRCL detuning, but this strategy has limited efficiency b/c FC is too narrow for SRCL, where the detuning is ~100-200 Hz around ~450 Hz.
• Mode-mismatch possibly adds into this, but very different PSAMS configurations seem to produce only slightly different sqz phase rotations.
• The DARM spring seems to evolve in the first 1-2 hours of IFO thermalization, we will try using the ADF to track this sqz angle rotation.
• At present, more "negative" SRCL filter bank offsets are better for SQZ, in that they do not induce higher frequency early-onset of anti-squeezing.

Here, at each SRCL offset, we rotate the SQZ angle to be ~0 deg (aka phase sqz) at high frequencies > kHz. And so, we can see how SRCL acts as basically a broadband filter cavity to coherent rotate the sqz angle around the coupled cavity pole. The "SRCL offset" in the plot legend refers to the arbitrary filter bank offset counts, H1:LSC-SRCL1_OFFSET. We did not what physical SRCL detuning (in e.g. degrees) this corresponds to during this squeeze mearement, but this has been measured before at this circulating power. I also tried to explore whether we can see the compounded effects of coherent sqz angle rotations from both SRCL detuning + mode-mismatch together, but this mode-mismatch rotation seems much smaller an effect than SRCL detuning rotations.

Tonight I made a measurement of our contrast defect at 430 kW with the latest ring heater and CO2 settings (using Craig's excellent scripts). ETMX RH: 1.4W, ETMY RH: 1W, CO2s are 1.7W as before.

Our contrast defect is about 2.2 mW now.

This measurement has caused some locklosses. The causes seem to have come from two places: the location of the band stop filters in DARM2 that are activated for the PCAL lines and the tramp for changing the darm offset. Dan put some checkers into the code to check that the bandstop is correct. I ran this measurement using a tramp of 2 seconds that I changed by hand (0.3 seconds causes a large glitch). Before I ran the measurement I checked that at this power and with the high violin modes we could step up to a darm offset of 9 pm. As always, this should be checked before running the code.

It appears that again the best damping settings for ITMY violin mode 5/6 and 8 have changed again. I have not done any testing for what is best, but the current settings are ringing up the modes. I am setting the gains for these modes to zero in the guardian.

However, FM1, 6 and 10 with a gain of 0.1 is working again for ETMY mode 1, so I have updated the guardian accordingly.