Displaying reports 14861-14880 of 86428.Go to page Start 740 741 742 743 744 745 746 747 748 End
Reports until 20:04, Tuesday 24 October 2023
H1 General
anthony.sanchez@LIGO.ORG - posted 20:04, Tuesday 24 October 2023 (73723)
Transient Injections

Followed the instruction found here:
https://docs.google.com/document/d/1AXIOEC6XkT9Mp47Ny4aEZu0ucMTprHV0lA-Bu1KJnvk/edit
and ran the following command @ 2:42 UTC and got the following output:


anthony.sanchez@cdsws13: hwinj detchar safety --run
ifo: H1
waveform root: /ligo/groups/cal/H1/hwinj
config file: /ligo/groups/cal/H1/hwinj/hwinj.yaml
GraceDB url: https://gracedb-playground.ligo.org/api/
GraceDB group: Test
GraceDB pipeline: HardwareInjection
excitation channel: H1:CAL-INJ_TRANSIENT_EXC
injection group: detchar
injection name: safety
reading waveform file...
injection waveform file: /ligo/groups/cal/H1/hwinj/detchar/detchar-hwinj-schedule_LIGO-T1900555-PROPOSED_H1_INJECTIONS.txt
injection waveform sample rate: 16384
injection waveform length: 390.0 seconds
reading log file...
injection log file: /ligo/groups/cal/H1/hwinj/detchar/detchar-hwinj-schedule_LIGO-T1900555-PROPOSED_H1_INJECTIONS_log.csv
injection log entries: 75
initiating ligo_proxy_init for GraceDB access...
injection start GPS: 1382236977.6
H1:CAL-INJ_TINJ_TYPE => 3
H1:CAL-INJ_TINJ_TYPE => 3
H1:CAL-INJ_TRANSIENT_SW2 => 1024
H1:CAL-INJ_TRANSIENT_SW2 => 1024
H1::CAL-INJ_TRANSIENT => ON: OUTPUT
H1::CAL-INJ_TRANSIENT => ON: OUTPUT
=== EXECUTING AWG INJECTION ===
this will wait until the injection is nearly complete...
ndshosts: h1daqnds1 and h1daqnds0
getting host by name: h1daqnds1
found host
testpoint_client 1.0.0
found version 4 or newer test point interface
H1:CAL-INJ_TRANSIENT_SW2 => 1024
H1:CAL-INJ_TRANSIENT_SW2 => 1024
H1::CAL-INJ_TRANSIENT => OFF: OUTPUT
H1::CAL-INJ_TRANSIENT => OFF: OUTPUT
H1:CAL-INJ_TINJ_TYPE => 0
H1:CAL-INJ_TINJ_TYPE => 0
=== INJECTION COMPLETE ===
creating injection events in GraceDB...
creating event: Detchar_HW_INJ_H1_1382236987.6.json
creating event: Detchar_HW_INJ_H1_1382236992.6.json
creating event: Detchar_HW_INJ_H1_1382236997.6.json
creating event: Detchar_HW_INJ_H1_1382237002.6.json
creating event: Detchar_HW_INJ_H1_1382237007.6.json
creating event: Detchar_HW_INJ_H1_1382237012.6.json
creating event: Detchar_HW_INJ_H1_1382237017.6.json
creating event: Detchar_HW_INJ_H1_1382237022.6.json
creating event: Detchar_HW_INJ_H1_1382237027.6.json
creating event: Detchar_HW_INJ_H1_1382237032.6.json
creating event: Detchar_HW_INJ_H1_1382237037.6.json
creating event: Detchar_HW_INJ_H1_1382237042.6.json
creating event: Detchar_HW_INJ_H1_1382237047.6.json
creating event: Detchar_HW_INJ_H1_1382237052.6.json
creating event: Detchar_HW_INJ_H1_1382237057.6.json
creating event: Detchar_HW_INJ_H1_1382237062.6.json
creating event: Detchar_HW_INJ_H1_1382237067.6.json
creating event: Detchar_HW_INJ_H1_1382237072.6.json
creating event: Detchar_HW_INJ_H1_1382237077.6.json
creating event: Detchar_HW_INJ_H1_1382237082.6.json
creating event: Detchar_HW_INJ_H1_1382237087.6.json
creating event: Detchar_HW_INJ_H1_1382237092.6.json
creating event: Detchar_HW_INJ_H1_1382237097.6.json
creating event: Detchar_HW_INJ_H1_1382237102.6.json
creating event: Detchar_HW_INJ_H1_1382237107.6.json
creating event: Detchar_HW_INJ_H1_1382237112.6.json
creating event: Detchar_HW_INJ_H1_1382237117.6.json
creating event: Detchar_HW_INJ_H1_1382237122.6.json
creating event: Detchar_HW_INJ_H1_1382237127.6.json
creating event: Detchar_HW_INJ_H1_1382237132.6.json
creating event: Detchar_HW_INJ_H1_1382237137.6.json
creating event: Detchar_HW_INJ_H1_1382237142.6.json
creating event: Detchar_HW_INJ_H1_1382237147.6.json
creating event: Detchar_HW_INJ_H1_1382237152.6.json
creating event: Detchar_HW_INJ_H1_1382237157.6.json
creating event: Detchar_HW_INJ_H1_1382237162.6.json
creating event: Detchar_HW_INJ_H1_1382237167.6.json
creating event: Detchar_HW_INJ_H1_1382237172.6.json
creating event: Detchar_HW_INJ_H1_1382237177.6.json
creating event: Detchar_HW_INJ_H1_1382237182.6.json
creating event: Detchar_HW_INJ_H1_1382237187.6.json
creating event: Detchar_HW_INJ_H1_1382237192.6.json
creating event: Detchar_HW_INJ_H1_1382237197.6.json
creating event: Detchar_HW_INJ_H1_1382237202.6.json
creating event: Detchar_HW_INJ_H1_1382237207.6.json
creating event: Detchar_HW_INJ_H1_1382237212.6.json
creating event: Detchar_HW_INJ_H1_1382237217.6.json
creating event: Detchar_HW_INJ_H1_1382237222.6.json
creating event: Detchar_HW_INJ_H1_1382237227.6.json
creating event: Detchar_HW_INJ_H1_1382237232.6.json
creating event: Detchar_HW_INJ_H1_1382237237.6.json
creating event: Detchar_HW_INJ_H1_1382237242.6.json
creating event: Detchar_HW_INJ_H1_1382237247.6.json
creating event: Detchar_HW_INJ_H1_1382237252.6.json
creating event: Detchar_HW_INJ_H1_1382237257.6.json
creating event: Detchar_HW_INJ_H1_1382237262.6.json
creating event: Detchar_HW_INJ_H1_1382237267.6.json
creating event: Detchar_HW_INJ_H1_1382237272.6.json
creating event: Detchar_HW_INJ_H1_1382237277.6.json
creating event: Detchar_HW_INJ_H1_1382237282.6.json
creating event: Detchar_HW_INJ_H1_1382237287.6.json
creating event: Detchar_HW_INJ_H1_1382237292.6.json
creating event: Detchar_HW_INJ_H1_1382237297.6.json
creating event: Detchar_HW_INJ_H1_1382237302.6.json
creating event: Detchar_HW_INJ_H1_1382237307.6.json
creating event: Detchar_HW_INJ_H1_1382237312.6.json
creating event: Detchar_HW_INJ_H1_1382237317.6.json
creating event: Detchar_HW_INJ_H1_1382237322.6.json
creating event: Detchar_HW_INJ_H1_1382237327.6.json
creating event: Detchar_HW_INJ_H1_1382237332.6.json
creating event: Detchar_HW_INJ_H1_1382237337.6.json
creating event: Detchar_HW_INJ_H1_1382237342.6.json
creating event: Detchar_HW_INJ_H1_1382237347.6.json
creating event: Detchar_HW_INJ_H1_1382237352.6.json
creating event: Detchar_HW_INJ_H1_1382237357.6.json
uploads complete.
anthony.sanchez@cdsws13:

 

H1 AWC (AWC, CDS, DetChar-Request, ISC)
keita.kawabe@LIGO.ORG - posted 17:20, Tuesday 24 October 2023 - last comment - 10:51, Wednesday 08 November 2023(73706)
OM2 thermistor sensor voltage supplies are oscillating (Fil, Fernando, Keita)

Summary:

It seems that the supply voltage for thermistors is oscillating, the frequency depends on whether or not the supply is loaded with thermistors (830mHz open to 1.66Hz fully connected to the in-chamber thermistors), the amplitude of the oscillation jumps seemingly randomly, and this is also happening for the unused Beckhoff module for the yet-to-be-installed second T-SAMS unit, all measured at the back of the Beckhoff chassis. (Can't we measure this from Beckhoff itself, without me going to the floor?)

Fil and Fernando quickly set up the same Beckhoff module in the lab and didn't observe this. Could we swap or maybe restart the modules in the chassis?

As of now, Beckhoff cable is disconnected from the back of the heater driver chassis. (I'm applying DetChar-Request tag just so people know, but we're just changing from one no-comb configuration to the other.)

Detaisls:

Since the past findings about OM2 and 1.66Hz comb (alogs 73367, 73233, 72967 72241 and 72061) didn't make sense, I went to the floor and remeasured the comb in the Beckhoff heater output (which goes to the heater driver input) as well as thermistor pins in the back of the heater driver chassis while Beckhoff connection was intact.

Turns out that all of these things share the same frequency but the voltage across thermistor pins was ~3 orders of magnitude larger than Beckhoff heater driver output pins (pin 9 and 19) (the latter were referenced from the driver board ground as it's common mode for both pins). I used a scope on battery and the thermistor voltage was like roughly 1Vpp 1.66Hz rectangular wave (1st pic). Yellow is the voltage across pin10 and 23 (across thermistor 1), blue is pin9 and 22 (thermistor 2) of the DB25 at the back of the driver chassis when the Beckhoff cable was still connected.  Voltage difference seemed to have come from the temperature difference of the thermistors (I disconnected the Beckhoff cable and measured the thermistor 1 and 2 resistance incl. cables to be 7.41k and 4.08k, respectively). When I disconnected the cable from the chassis and just measured the pin10-23 and pin9-22 voltage coming from the cable (picture 2), they were both about 1.2V pp. This is supposed to be the source voltage for thermisters. The frequency slowed down by about a factor of 2 (832mHz) when the thermistors were disconnected.

For your convenience, below is a table of which pins are what (see e.g. E1100530 and D2000212). Note that thermistors themselves only have two pins, therefore supply and readback pins are bundled together in chamber as shown. Supply is presumably a reference voltage supplied through a reference resistor.

which thermistor? DB25 pin Beckhoff in chamber
1 10 Temperature Supply 1A+ thermistor 1 pin 1
(10&12 bundled together in chamber)
12 Temperature Readback 1A+
23 Temperature Supply 1A- thermistor 1 pin 2
(23&25 bundled together in chamber)
25 Temperature Readback 1A-
2 9 Temperature Supply 2A+ thermistor 2 pin 1
(9&11 bundled together in chamber)
11 Temperature Readback 2A+
22 Temperature Supply 2A- thermistor 2 pin 2
(22&24 bundled together in chamber)
24 Temperature Readback 2A-

 

Went to the CER, disconnected the cable from the back of the Beckhoff chassis and did the same measurement. Frequency didn't change but the amplitude was much smaller (~280mVpp instead of 1.2Vpp) for a while, but suddenly the amplitude of the thermistor 1 supply changed back to 1.2V (pic 3). Nuts. When the beckhoff cable was reconnected (and the connection to in-chamber thermistor was restored) the frequency went back to 1.66Hz (picture 4).

Picture 5 shows pin 10-23 (thermistor 1 supply) and pin12-25 (thermistor 1 readback, which is not connected to anything). Picture 6 is the same thing but for the unused Beckhoff unit for the second T-SAMS. It's strange that the same thing is happening in two independent units. Picture 7 is the thermistor 1 supply and pin 6-19 (voltage output for the heater driver). It really seems that this is a problem of the supply voltage.

I checked the 24V power strip for the Beckhoff chassis but it was good (pic 8 and 9).

Fil and Fernando set up EL3692, which is the Beckhoff unit used for Thermistors. They didn't observe this oscillation behavior.

I wanted to do some injections into thermistors to see how this couples to DARM but didn't have time.

Images attached to this report
Comments related to this report
daniel.sigg@LIGO.ORG - 00:46, Thursday 26 October 2023 (73754)
Link

Well, this seems to be a feature! The EL3692 terminal has 2 measurement inputs for resistance but only one ADC and current source. In alternating mode it switches between the 2 channels continuously. From the scope traces, the measurement time per channel looks like about ~400 ms. This is consistent with the data sheet. We expect about ~0.16 mA of current in the range between 10 Ω and 10 kΩ.

fernando.mera@LIGO.ORG - 16:07, Friday 27 October 2023 (73782)
Link 

Fil, Marc, Keita, Daniel, Fernando

Fil and I set a test bank in the lab and verified the square pulses found are part of the features of the EL3692 terminal when both channel reading is set. Then we implemented a configuration using a continuous reading over the channel 1 and one shot reading over the channel 2 (under request by a raising edge on the Start Conversion input in the module, that will be never used). 

Finally the scopes show the continuous signal in the channel 1 with some minor noise component that is still in analysis (basically 60Hz and 12Hz) however this virtually solves the main problem with the square pulses. One ECR should be open to double the quantity of EL3692 in the places where reading in both channels are necessary since just one channel provides continuous reading at this point. 

Note: the autorange feature was left intact so the new configuration will not cause any limitation in the resistor range to be measured and also will keep the same PDO to not break the Epics configuration.

Attached: scopes and the EL3692, configuration applied to the EL3962 and spectral analysis for the noise signals.
Images attached to this comment
fernando.mera@LIGO.ORG - 17:00, Tuesday 31 October 2023 (73886)
Link 

WP 11501

Daniel Keita Fernando

Today we configured the one channel reading on the two Beckhoff EL3692 modules for the PSL IO Chassis. After restarting the system Keita Daniel and I were to the rack to scope the thermistor channels we verified the absence of the square pulses reported initially. Finally the module R20 CH2 was rewired to R21 CH1 and configured in the system accordingly. Attached the picture including the R20 and R21 EL3692 modules for reference.
Images attached to this comment
fernando.mera@LIGO.ORG - 17:17, Thursday 02 November 2023 (73940)
Link 

After having a solution for the issue duplicating the number of EL3692 modules, and ECR and FRS ticket have been created:

ECR:
https://dcc.ligo.org/E2300408-v1

FRS ticket:
https://services1.ligo-la.caltech.edu/FRS/show_bug.cgi?id=29563
fernando.mera@LIGO.ORG - 10:51, Wednesday 08 November 2023 (74092)
Link

Daniel, Fernando

As part of the WP11506  a new configuration was loaded into the Beckhoff system which includes the 1-channel continuos reading for the EL3692 terminals. The change included the rewiring in the TCS Corner EtherCAT chassis TSAMS consisting of connecting the second channel in the EL3692 (R20) to the first channel in the terminal EL3692 (R21) to match the TwinCAT configuration added. The disconnected wires are not currently connected ot any thermistor on the floor.

H1 CDS
jonathan.hanks@LIGO.ORG - posted 17:17, Tuesday 24 October 2023 (73719)
WP11491 Replacing CUR network switches 
As per WP11491 I replaced sw-cur-aux and sw-spare-c.  They were replaced by a pair of 8200s in a stacked config.  The stacked switch is sw-cur-aux-stk.

Apart from replacing older switches this should also give a bandwidth boost to users in the CUR.  The link from the core to sw-cur-aux-stk was upgraded (via optics switch) to 10g.  All rj45 ports are 1g instead of the 10/100 that was on sw-spare-c.
H1 ISC
vladimir.bossilkov@LIGO.ORG - posted 17:16, Tuesday 24 October 2023 - last comment - 17:42, Tuesday 24 October 2023(73718)
Restart of H1OAF0 changed OMC0 filters

Vlad, Naoki, Jenne

Naoki noticed that there were some unexpected SDF differences in the DCPD calibration filterbank in PI, which is actually a copy of the OMC DCPD A0 and B0 filterbanks, being part of the OMC0 model. The OMC filterbanks were also affected.

The filter which calibrates Amps to Watts got disabled in the restart for both A0 and B0 filterbanks [see attachment].
We checked in the observing.snap; these filters should indeed be On. Hence this change was reverted.

We haven't spotted any other blaring issues from the restart.

Images attached to this report
Comments related to this report
vladimir.bossilkov@LIGO.ORG - 17:42, Tuesday 24 October 2023 (73720)
Link

OMC was not locking. Some more things needed reverting in CS_IOP as well from the same issue.

Specifically: OMC-DCPD_A_GAINSET and its B equivalent [see screenshot]

Images attached to this comment
H1 TCS
camilla.compton@LIGO.ORG - posted 17:09, Tuesday 24 October 2023 - last comment - 15:17, Wednesday 01 November 2023(73717)
Reverted ETMX HWS to old LED Source, Realigned and Restarted Code.

TJ, Camilla. WP #11483.

Uninstalled the "new" S&K HWS laser (TSOP M1900163) from the ALS table, stored it in it's case in the LVEA TCS cabinets. Removed fiber and fiber launcher.  This was installed in 62089.

Reinstalled the "old"  diode source M530F2 (eye safe). Using M92L02 20um multi-mode fiber and original D1800125 fiber launcher. Reduced length of the tube of D1800125 fiber launcher as we thought we need to bring the F=125mm lens closer to the launcher.  

Realigned the path to get a retro-reflected beam off ETMX and checked this by mis-aligning ETMX. Took new references on EX, and ITMs at 00:08UTC.


Photos before and after attached. Decision made to swap back to original source in T2300336. Will update FRS 14310 with Aidan. 

Images attached to this report
Comments related to this report
camilla.compton@LIGO.ORG - 10:42, Wednesday 25 October 2023 (73732)
Link

We are getting data, see attached, but the TOTAL_PIXEL_VALUE is changing as we thermalize, which we don't want. There is some clipping happening which we can work to minimize on table.

Images attached to this comment
camilla.compton@LIGO.ORG - 15:17, Wednesday 01 November 2023 (73919)
Link

TJ and I repeated the laser swap EY 73878 but struggled to get an unclipped beam. We went back to EX ~3pm Oct 31st to understand if the EX beam was clipping somewhere to get the bad HWS data above. We saw the beam was clipping on the edges of BS2 and M2 and then after clipping L1 (1" optic), the beam appears round again. Layout D1800270.

In 42171 and T1000717 there is mode matching solutions of this path showing the beam should remain under 10mm diameter until the Transmon telescope. We don't remember this ever being the case. The beam starts around 10mm and then diverges to >1" after L3, rather than converging.  

We think we should revisit this mode matching to understand what our input optics should be and check all the lenses are correct (they are labeled as in D1800270).

H1 SQZ
victoriaa.xu@LIGO.ORG - posted 16:36, Tuesday 24 October 2023 - last comment - 11:05, Monday 26 February 2024(73696)
SQZ-OMC mode scan with hot OM2

Kevin, Sheila, Evan, Vicky

Summary: SQZ-OMC mode scans with hot OM2, and PSAMS 120/120 vs. 200/200. From this data, we should get single-bounce SQZ-OMC mode-matching with hot OM2, check SQZ readout losses (AS port throughput), and measure OMC losses via cavity visibility when locked/unlocked to the squeezer beam. With hot OM2, in sqz single bounce, SQZ-OMC mode-matching looks a bit better with PSAMS 120/120 than 200/200.

We'll ask Jennie W. to help us fit these SQZ-OMC mode scans. She can fit the double-peak in the 2xHOM, to give an accurate measure of SQZ-OMC mode-matching with hot OM2 and these two PSAMS settings. Here is just naively calculating mismatch from the relative power in TEM20 (TEM20/(TEM00 + TEM10/01 + TEM20)), and then calculating the total power not in TEM00 (ie 1-TEM00/(TEM00 + TEM10/01 + TEM20)), to get the following estimates on SQZ-OMC mode matching:

PSAMS 120/120, scan: 10/24/23 19:46:53 UTC + 200 seconds.
   --> mismatch ~ TEM20/peak_sums ~ 2%.      Total incl. mismatch + misalignment: 1-tem00/peak_sums ~ 8%.
PSAMS 200/200, scan: 10/24/23 19:04:57 UTC + 200 seconds.
   --> mismatch ~ TEM20/peak_sums ~ 5%.      Total incl. mismatch + misalignment: 1-tem00/peak_sums ~ 12%.

We will follow-up with analysis on OMC loss measurements based on cavity visibility, more accurate SQZ-OMC mode mismatches from these scans, and checking single-bounce SQZ powers through the AS port.

---------------------------------------------------------------------------

Notes:

---------------------------------------------------------------------------

Some relevant alogs, as we try to piece together the SQZ-IFO, IFO-OMC, and SQZ-OMC mode matchings:

Images attached to this report
Comments related to this report
jennifer.wright@LIGO.ORG - 14:38, Thursday 22 February 2024 (75931)
Link

Thanks to Vicky for helping me update the code to work for SQZ measaurements I had some trouble fitting these in the past as the fitting code was not subtracting off the dark current on the measurements, this doesn't matter so much for mode scans using the PSL as this has a much higher power through the OMC than the SQZ beam (16mA on the DCPDs vs. 0.5 mA on the DCPDs).

For the first measurement taken on 24th October 2023, hot OM2, PSAMS (ZM4 at 120V, ZM5 at 120V).

I used 70s of data taken starting at 1382212031.

See attached plots of the mode scan with identified peaks, and the carrier 02 peaks fitted as a sum of lorentzians.

The blue line shows the data zoomed in to the C02 peak. Th red line shows the sum of lorentzians using the fitted parameters of both centre frequencies, both amplitudes, and the half-width at half-maximum of an individual peak.

The purple line shows the lorentzian sum as a function of the initial fitting parameters.

 

The fitted mode spacing is 149.665 - 149.153 MHz = 0.512 MHz, which is less than the expected HOM spacing 0.588 MHz from this entry which uses the original measurements by Koiji in Table 25.

The mode-mismatch is 0.0062 + 0.0071 /( 0.0062 + 0.0071 + 0.45) = 2.9 % for the 02 modes with the lower frequency mode (horizontal I think) being higher in magnitude.

Code to do run mode scans is OMCScan_nosidebands6.py and fit the data is in fit_two_peaks_no_sidebands6.py located in labutils/omcscan git reposiotory on /dev branch, ran using labtutils conda enrvironment at labutils gitlab).

Run OMCscan_nosidebands6.py with

python OMCscan_nosidebands6.py 1382212031 70 "PSAMS 120/120, SQZ-OMC 1st scan" "single bounce" --verbose -m -p 0.008 -o 2

And also it is neccessary to hard code in the C02 mode being the 5th largest mode and 01 being the third largest in order to get a good fit as the sidebands are off.

Inside OMCscan_nosidebands6.py

find the module:

def identify_C02(self):

then change the lines shown after:

#set frequency to be that of third largest peak.

to read:

third_larg = np.argsort(self.peak_heights)[-3]#third largest is 01.

fourth_larg = np.argsort(self.peak_heights)[-5]#fifth largest is 02

Non-image files attached to this comment
jennifer.wright@LIGO.ORG - 11:05, Monday 26 February 2024 (75933)
Link

For the second measurement taken on 24th October 2023, hot OM2, PSAMS (ZM4 at 200V, ZM5 at 200V).

I used 80s of data taken starting at 1382209515.

See attached plots of the mode scan with identified peaks, and the carrier 02 peaks fitted as a sum of lorentzians.

The blue line shows the data zoomed in to the C02 peak. Th red line shows the sum of lorentzians using the fitted parameters of both centre frequencies, both amplitudes, and the half-width at half-maximum of an individual peak.

The purple line shows the lorentzian sum as a function of the initial fitting parameters.

 

The fitted mode spacing is 149.757 - 149.204 = 0.552 MHz, which is less than the expected HOM spacing 0.588 MHz from this entry which uses the original measurements by Koiji in Table 25.

The mode-mismatch is 0.019 + 0.016 / (0.016 + 0.019 + 0.42) = 0.054 = 5.4 % for the 02 modes with the lower frequency mode (horizontal I think) being higher in magnitude.

Code to do run mode scans is OMCScan_nosidebands7.py and fit the data is in fit_two_peaks_no_sidebands7.py located in labutils/omcscan git reposiotory on /dev branch, ran using labtutils conda environment at labutils gitlab).

Run OMCscan_nosidebands7.py with

python OMCscan_nosidebands7.py 1382209515 80 "PSAMS 200/200, SQZ-OMC 2nd scan" "single bounce" --verbose -m -o 2

And also it is neccessary to hard code in the C02 mode being the 4th largest mode and 01 being the third largest in order to get a good fit as the sidebands are off.

Inside OMCscan_nosidebands7.py

find the module:

def identify_C02(self):

then change the lines shown after:

#set frequency to be that of third largest peak.

to read:

third_larg = np.argsort(self.peak_heights)[-3]#third largest is 01.

fourth_larg = np.argsort(self.peak_heights)[-4]#fourth largest is 02

Non-image files attached to this comment
H1 TCS
thomas.shaffer@LIGO.ORG - posted 16:27, Tuesday 24 October 2023 - last comment - 09:04, Wednesday 25 October 2023(73704)
Swapped TCSX chiller for new chiller

Summary - Camilla and I removed the running TCSX chiller and replaced it with a new ThermoFlex 1400 SN#1153600201231003.

We've been having some issues with the TCSX laser relocking itself during Observing (ex: alog73331). This seems to be due to inconsistent water temperature from two of our three chilers, causing the temperature of the laser to shift slightly. We've swapped out SN#0110193301120813 for the new chiller and sent off the spare chiller for service. We input the settings from the CO2Y chiller and it the new chiller fired right up and seems to be outputing correct flow and pressure. We'll keep an eye on it the next few days.

Comments related to this report
thomas.shaffer@LIGO.ORG - 09:04, Wednesday 25 October 2023 (73729)
Link

Flow with the new chiller seems much more stable and the laser is operating at a slightly lower temperature (23.4C vs 24.5C) and a slightly higher output power (41.9W vs 40.9W). In the attached shot I'm unsure why the flow rate, as seen by the flow meter under the BSC, starts a bit higher and then over the course of ~4hours settles back to where it is now. I'd expect the system to settle much faster than that. For reference alog72267 is the last time we swapped the chillers and SN813 didn't show this.

When packing up our old spare chiller (SN#822) to be sent in for service, we found a small piece of metal, about the size of a bb in the outlet quick disconnect. This clearly wasn't helping the flow, but this chiller also had a refrigerant leak. Definitely time to be sent in.

Images attached to this comment
H1 General (TCS)
anthony.sanchez@LIGO.ORG - posted 16:15, Tuesday 24 October 2023 - last comment - 16:37, Tuesday 24 October 2023(73714)
Tuesday Maintanence day Eve Shift Start

TITLE: 10/24 Eve Shift: 23:00-07:00 UTC (16:00-00:00 PST), all times posted in UTC
STATE of H1: Preventive Maintenance
OUTGOING OPERATOR: Oli
CURRENT ENVIRONMENT:
    SEI_ENV state: CALM
    Wind: 15mph Gusts, 12mph 5min avg
    Primary useism: 0.05 μm/s
    Secondary useism: 0.18 μm/s
QUICK SUMMARY:
Full day of maintenance so Locking will start here after the channel H1:TCS-ITMX_HWS_LIVE_AQUISITION_GPSTIM SPM channel issue is resolved.
Tagging TCS.

I will be watching EY and EX temps. And OPO SDF Diffs when getting to Observing.

I also have H1:DAQ-H1EDC_CHAN_NOCON is 88 which seems like a few things are still not working correctly.
Tagging CDS.

 

Comments related to this report
camilla.compton@LIGO.ORG - 16:37, Tuesday 24 October 2023 (73715)
Link

The TCS-ITMX_HWS 88 channels not connecting errors were as I hadn't yet restarted the ITMX HWS code that makes these channels after Jonathan's work on h1hwsmsr 73699. I've now restarted the code and it's working well. Doesn't effect locking. 

H1 General
oli.patane@LIGO.ORG - posted 16:08, Tuesday 24 October 2023 (73713)
Ops DAY Shift End

TITLE: 10/24 Day Shift: 15:00-23:00 UTC (08:00-16:00 PST), all times posted in UTC
STATE of H1: Preventive Maintenance
INCOMING OPERATOR: Tony
SHIFT SUMMARY: Maintenance is over and we are starting the process of getting back up.

Things to keep track of:

- EY heater tripped off at some point and caused temps to drop, should be good now but keep close eye on EY temps.

- There will be an OPO TEMP SDF, but shouldn't be any other sqz diffs
LOG:

15:00UTC Detector Locked for 28.5hrs, all SUS Charge measurements ran
23:00 Starting to move back towards locking    

Start Time System Name Location Lazer_Haz Task Time End
15:03 TCS Camilla CR N CO2 Blast on ad off 15:10
15:04 FAC Karen EY n Tech clean 16:35
15:05 FAC Kim EX n Tech clean 16:21
15:07 FAC Randy EX/EY n Cleanroom moving stuff 21:10
15:11 VAC Jordan, Travis FCETube n Closing gate valves and replacing ion pump 19:27
15:15 ISC TJ CR n Moving Common CARM Gain 15:27
15:24 SQZ Vicky Remote n SQZ adjustments 15:53
15:28 PSL Jason CR n PMC alignment 15:38
15:30 VAC Janos FCEncl n Getting stuff 15:45
15:51 EE Fil LVEA n New electronics install 15:52
15:53 SQZ Sheila, Vicky CR n OMC Scans (misaligning ITMX, ETMX) 22:28
15:58 ISI Arnaud remote n ETMX tests 17:23
16:01 FAC Cindi FCES n Tech clean 17:53
16:07 TCS Camilla, TJ Mech Room n Replacing TCSX CO2 Chiller 16:56
16:18 ISI Jim CR n ISI tests (ETMY misaligned) 17:24
16:21 FAC Kim LVEA n Tech clean 18:40
16:43 TCS Camilla LVEA n Into LVEA for TCS 16:56
16:51 CDS Jonathan CER n Cloning HWS MSR disk 19:05
16:52 FAC Karen LVEA n Tech clean 18:22
17:00 HWS TJ, Camilla EX VEA YES Swap HWS 22:54
17:10 PSL Jason, Austin Optics Lab n Oplev work 18:58
17:14 FAC Chris, Eric Sitewide n Grease supply fans 17:59
17:17 DMT Dave remote no add channels to dmt epics, DAQ restart required 20:31
17:17 DAQ Dave remote no Add zotvac0 epics channels to DAQ. DAQ restart required 20:31
17:18 DAQ Dave remote no DAQ RESTART. Needed for EDC changes and new h1susprocpi model 20:31
17:24 ISI Jim CR n ETMX/ETMY tests 22:19
17:25 FAC Mitch EX/EY n Dust mon/HEPI pump checks 18:06
17:54 FAC Cindi LVEA Receiving n Getting cardboard 22:26
18:19 ISC Keita LVEA n OM2 19:17
18:28 SUS Dave remove no Restart Vlad's new h1susprocpi model, DAQ restart required 18:29
18:29 FAC Tyler, Eric LVEA n Walking floor 18:52
18:29 SUS Dave remote no Install Vlad's new h1susprocpi model, DAQ restart is required 20:31
20:03 FAC Christina OSB n Moving pallet w/ forklift 22:13
20:09 FAC Tyler, Eric FCES n Tour 20:31
20:11 ISC Keita LVEA n OM2 work 20:53
20:14 VAC Jordan, Travis, Janos FCETube n Pump swap 21:28
20:24   TJ LVEA n Looking for parts 20:49
20:32 FAC Tyler, Eric EY n Look at EY temp excursion 21:29
20:41 TCS Jason, Randy, Austin LVEA n Putting 3IFO TCSX away 20:59
21:14 HWS TJ, Camilla Optics Lab, LVEA n Looking for parts 21:35
21:30 VAC Janos EX/EY n Working with pumps 22:11
21:53 CDS Jonathan CUR n Network switching 22:54
22:05 ISC Keita CER n Measuring Beckoff voltage 22:29
22:12 VAC Janos LVEA n Pumps 22:18
LHO VE
jordan.vanosky@LIGO.ORG - posted 16:04, Tuesday 24 October 2023 (73712)
Installation of FCT Ion Pump (C1 Cross)

Jordan, Mitchell

Today, we were able to install one of the new 150 l/s ion pumps on FC-CI, C1 cross. The Ion Pump/Tee/Angle valve assembly was pre-built in the staging building and then pumped down and leak checked. This assembly was stored under vacuum and then brought to the Filter Cavity Enclosure.

We closed FCV-3 (BSC3), FCV-5, FCV-6, and FCV-9 (HAM8) to isolate the C1 cross. Then closed the -Z axis GV on the C6 cross to isolate the ion pump port. We then vented the ion pump assembly with N2 and removed the angle valve/6" zero-length reducer on the cross, and installed the ion pump on the 6" CF port. A genie lift was used to lift/hold the ion pump while the connections were made.

Once installed, we used the leak detector/small turbo to pump down the assembly, and then helium leak tested the one CF connection that was made. There was no detectable signal above the helium background of 9.5E-11 Torr-l/s.

The ion pump was powered on locally, and quickly dropped to ~8E-8 Torr, using a new IPCMini controller. The -Z gate valve remains closed, and the rest of the FCT gate valves were reopened once the ion pump was leak checked and powered on. We will continue with the installation of the rest of the pumps in the LVEA in the following weeks.

Images attached to this report
H1 AOS
louis.dartez@LIGO.ORG - posted 15:35, Tuesday 24 October 2023 (73711)
LVEA swept 
LVEA swept.
LHO VE (VE)
travis.sadecki@LIGO.ORG - posted 14:59, Tuesday 24 October 2023 (73709)
GV8 Annulus Ion Pump replaced

The GV8 annulus ion pump was replaced today with a rebuilt, Galaxy-style pump body and a rebuilt old-style (fanless) MiniVac controller.  A controller swap took place last week, but upon powering on this controller with the new pump, I noticed that the polarity of the controller was positive.  So, I powered it down and swapped it with another rebuilt controller with negative polarity.  

The annulus system was pumped down to the mid e-5 torr range via local turbo and aux cart, at which time I powered on the ion pump.  Within a couple of minutes, the display on the controller showed 1-light of ion current (good).  The local turbo and aux cart were disconnected and the system restored to nominal Observing-run mode.  

H1 CDS
david.barker@LIGO.ORG - posted 14:16, Tuesday 24 October 2023 - last comment - 14:44, Tuesday 24 October 2023(73705)
CDS Maintenance Summary: Tuesday 24th October 2023

WP11492 SUSPROC PI PLL model changes

Vladimir, Naoki, Erik, Dave

A new h1susprocpi model was installed. A DAQ restart was required

WP11485 h1hwsmsr disk replacement

Jonathan.

The failed 2TB HDD disk which is part of the /data raid was replaced with a 2TB SSD drive. At time of writing it is 70% done with the new disk rebuild.

Jonathan also cloned the boot disk. I verified that /data is being backed up to LDAS on a daily basis at 5am.

WP11478 Add HOFT and NOLINES H1 effective range to EPICS and DAQ.

Jonathan, Dave:

On Keith's suggestion, the HOFT and NOLINES versions of the H1 effective range were added to the dmt2epics IOC on h1fescript0. The MPC and GPS channels were also added to the H1EPICS_DMT.ini for inclusion into the DAQ. A DAQ restart was required.

WP11488 Deactivate opslogin

Jonathan

The old opslogin machine (not to be confused with opslogin0) was powered down.

WP11479 Add zotvac0 epics monitor channels to DAQ

Dave:

H1EPICS_CDSMON was modified to add zotvac0's channels. A DAQ restart was required.

DAQ Restart

Jonathan, Dave:

The DAQ was restarted for the above changes. This was a very messy restart.

0-leg was restarted. h1gds0 needed a second restart to sync its channel list.

EDC on h1susauxb123 was restarted

8 minutes later fw0 spontaneously restarted itself. At this point h1susauxb123 front end locked up, all models and EDC crashed.

Jonathan connected a local console to h1susauxb123, but there was no errors printed, the keyboard was unresponsive. h1susauxb123 was rebooted.

After the EDC came back online, the DAQ 1-leg was restarted.

h1gds1 needed a second restart to sync up its disks.

Comments related to this report
david.barker@LIGO.ORG - 14:30, Tuesday 24 October 2023 (73707)
Link

Tue24Oct2023
LOC TIME HOSTNAME     MODEL/REBOOT
13:01:42 h1oaf0       h1susprocpi <<< model restart


13:02:34 h1daqdc0     [DAQ]  <<< 0-leg restart
13:02:43 h1daqfw0     [DAQ]
13:02:43 h1daqtw0     [DAQ]
13:02:44 h1daqnds0    [DAQ]
13:02:51 h1daqgds0    [DAQ]
13:03:21 h1susauxb123 h1edc[DAQ] <<< EDC restart
13:03:52 h1daqgds0    [DAQ] <<< 2nd gds0 restart


13:09:26 h1daqfw0     [DAQ]  <<< spontaneous FW0 restart (crash of h1susauxb123 at this point)


13:22:34 h1susauxb123 ***REBOOT*** <<< reboot h1susauxb123, start EDC
13:23:20 h1susauxb123 h1edc[DAQ]
13:23:36 h1susauxb123 h1iopsusauxb123
13:23:49 h1susauxb123 h1susauxb123


13:26:01 h1daqdc1     [DAQ] <<< 1-leg restart
13:26:11 h1daqfw1     [DAQ]
13:26:11 h1daqtw1     [DAQ]
13:26:12 h1daqnds1    [DAQ]
13:26:20 h1daqgds1    [DAQ]
13:26:48 h1daqgds1    [DAQ] <<< 2nd GDS1 restart
 

david.barker@LIGO.ORG - 14:44, Tuesday 24 October 2023 (73708)
Link

DMT2EPICS configuration file, HOFT and NOLINES added:

{
    "prefix": "H1:",
    "entries": [
        {
            "engine": "dmt",
            "config": {
                "url": "https://marble.ligo-wa.caltech.edu/dmtview/SenseMonitor_CAL_H1/H1SNSW%20EFFECTIVE%20RANGE%20%28MPC%29/data.txt",
                "pv-name": "CDS-SENSMON_CAL_SNSW_EFFECTIVE_RANGE_MPC",
                "pv-gps": "CDS-SENSMON_CAL_SNSW_EFFECTIVE_RANGE_MPC_GPS",
                "disconnected-value": -1.0,
                "period": 30.0
            }
        },
        {
            "engine": "dmt",
            "config": {
                "url": "https://marble.ligo-wa.caltech.edu/dmtview/SenseMonitor_Clean_H1/H1SNSC%20EFFECTIVE%20RANGE%20%28MPC%29/data.txt",
                "pv-name": "CDS-SENSMON_CLEAN_SNSC_EFFECTIVE_RANGE_MPC",
                "pv-gps": "CDS-SENSMON_CLEAN_SNSC_EFFECTIVE_RANGE_MPC_GPS",
                "disconnected-value": -1.0,
                "period": 30.0
            }
        },
        {
            "engine": "dmt",
            "config": {
                "url": "https://marble.ligo-wa.caltech.edu/dmtview/SenseMonitor_hoft_H1/H1SNSH%20EFFECTIVE%20RANGE%20%28MPC%29/data.txt",
                "pv-name": "CDS-SENSMON_HOFT_SNSH_EFFECTIVE_RANGE_MPC",
                "pv-gps": "CDS-SENSMON_HOFT_SNSH_EFFECTIVE_RANGE_MPC_GPS",
                "disconnected-value": -1.0,
                "period": 30.0
            }
        },
        {
            "engine": "dmt",
            "config": {
                "url": "https://marble.ligo-wa.caltech.edu/dmtview/SenseMonitor_Nolines_H1/H1SNSL%20EFFECTIVE%20RANGE%20%28MPC%29/data.txt",
                "pv-name": "CDS-SENSMON_NOLINES_SNSL_EFFECTIVE_RANGE_MPC",
                "pv-gps": "CDS-SENSMON_NOLINES_SNSL_EFFECTIVE_RANGE_MPC_GPS",
                "disconnected-value": -1.0,
                "period": 30.0
            }
        }
    ]
}
 

H1 SEI
arnaud.pele@LIGO.ORG - posted 12:05, Tuesday 24 October 2023 - last comment - 07:20, Wednesday 25 October 2023(73688)
ETMX ISI - 1.23Hz hunting

Summary - Jim fixed it with a little shake.

We cycled through the various ISI state controls. The 1Hz line would start appearing when stage 1 is isolated. In any states below this point, we can clearly see the difference in the 'sensor response' of the local H1 L4C wrt T240 or CPS. While Jim was taking an olg measurement, the ISI tripped, which seem to have changed the response of the H1 L4C back to the nominal response, see the first pdf attached, showing the L4C/T240 local TF, before (p1) vs after (p2) the ISI trip. The 2nd pdf attached shows the ISI spectra in the isolated state before (p1) vs after (p2) the shake, no other changes.
We've had sticky L4Cs in the past and solved it in a similar way (see alog 38939), but the symptoms were much more obvious than a slight change in resonant frequency as we are seeing here.

Timeline of tests :

16:04 - 16:12 UTC ETMX ISI/HEPI OFFLINE
16:15 - 16:30 UTC HEPI ON / ETMX ISI OFFLINE
16:31 - 16:37 UTC HEPI ON /ETMX DAMPED
16:38 - 16:44 UTC HEPI ON / ETMX ST1 ISO - We can see the giant ~1Hz line
16:45 - 16:48 UTC HEPI ON/ ETMX ST1 ISO - H1 L4C gain 0.5 - sym filter off - ~1Hz line goes down
16:50 - 16:52 UTC HEPION/ETMX ST1/ST2 ISO - H1 L4C gain 0.5 - sym filter off
16:55 - 17:07 UTC Back to nominal
17:25 - Jim changing stage 1 Rz blend to noL4C
17:38 - Jim changing stage 1 Y blend to noL4C
18:00 - Jim measuring Rz olgf

Ref alog 73625

Non-image files attached to this report
73688_20231024114838_etmx_l4c_response.pdf
73688_20231024115848_etmx_spectra2.pdf
Comments related to this report
jim.warner@LIGO.ORG - 16:43, Tuesday 24 October 2023 (73716)
Link

The ITMY peak is also coming the a "stuck" H1 L4C. This problem is kind of subtle, the L4C only seems to misbehave when the isolation loops are on and the accelerations on the L4C are low. Because tripping ETMX seemed to fix that L4C, I tried it on ITMY. To do this, I put the ISI in damped, ramped on an offset on the ST1H1 actuator, then turned it off with a zero ramp time. I did this for 2k, 3k and 4k counts of drive. All of these caused a bigger signal than the ETMX trip earlier, but the ITMY H1 L4C is still "stuck". Attached asds compare the corner 1 and corner 2 l4c-to-t240 local tfs before and after the whacks. No difference before vs after, but brown and pink are before, red and blue are after. 

But, changing ITMY Y and RZ St1 blends to 250mhz blends that don't use the H1L4C makes the 1.something hz peak on ITMY go away. This also worked on ETMX. I've set both ISIs to not use their H1 L4Cs, we'll watch for a while and re-evaluate next week. At this point, only ITMX is still using it's H1 L4C.

Images attached to this comment
gabriele.vajente@LIGO.ORG - 07:20, Wednesday 25 October 2023 (73726)
Link

The two lines around 1.3 Hz are gone from DARM.

Unfortunateely it's hard to tell if this improved the nosie above 10 Hz, because there are a lof of scattered light events (4 Hz cryobaffle?)

Images attached to this comment
H1 AOS
sheila.dwyer@LIGO.ORG - posted 15:48, Friday 20 October 2023 - last comment - 18:22, Tuesday 24 October 2023(73621)
PSAMs vs SQZ repeat measurement

Naoki, Sheila

Summary:  We have repeated the test from 73400, with our higher level of squeezing after the crystal move, and with the ASC off for squeezing angles other than squeezing.  This seems to generally reproduce the results in that alog, convincing us that most of the rotation we are seeing is from the mode matching change not an alignment shift.  

We have saved references in userapps/sqz/h1/Templates/dtt/DARM/PSAMS_tests_Oct202023.xml.  This is a copy of PSAMS_tests_Oct112023.xml, with the references saved there and shown in alog 73400  The times written below are minimum times, for many of these references there is actually more time.  

times (PSAMs 200/200):

set sqz angle back to sqz, turned AS42 and FC ASC, set PSAMs to 120/120 with 30 second ramp

times (PSAMS 120/120):

Images attached to this report
Comments related to this report
victoriaa.xu@LIGO.ORG - 18:22, Tuesday 24 October 2023 (73721)SQZ
Link

For PSAMS 120 vs. 200, adding in subtracted squeezing dBs data for this 20 Oct 2023 dataset (new crystal spot with more sqz, better controlled alignment), and from our initial dataset LHO:73400 12 Oct 2023 (before the crystal move so less sqz, ASC running the whole time). A model of unsqueezed quantum noise is used as the reference for the subtraction; relevant GWINC IFO parameters are in the plot title. 

Now working on fitting the mode-mismatch amplitudes + phases to a GWINC quantum noise model.

Images attached to this comment
H1 DetChar
gabriele.vajente@LIGO.ORG - posted 08:50, Wednesday 18 October 2023 - last comment - 18:35, Friday 27 October 2023(73546)
Low Frequency Noise (<50 Hz)

Using two periods of quiet time during the last couple of days (1381575618 + 3600s, 1381550418 + 3600s) I computed the usual coherences:

https://ldas-jobs.ligo-wa.caltech.edu/~gabriele.vajente/bruco_STRAIN_1381550418/
https://ldas-jobs.ligo-wa.caltech.edu/~gabriele.vajente/bruco_STRAIN_1381575618/

The most interesting observation is that, for the first time as far as I can remember, there is no coherence above threshold with any channels for wide bands in the low frequency range, notably between 20 and 30 Hz, and also for many bands above 50 Hz. I'll assume for now that most of the noise above ~50 Hz is explained by thermal noise and quantum noise, and focus on the low frequency range (<50 Hz).

Looking at the PSDs for the two hour-long times, the noise belowe 50 Hz seems to be quite repeatable, and follows closely a 1/f^4 slope. Looking at a spectrogram (especially when whitened with the median), one can see that there is still some non-stationary noise, although not very large. So it seems to me that the noise below ~50 Hz is made up o some stationary 1/f^4 unknown noise (not coherent with any of the 4000+ auxiliary channels we record) and some non-stationary noise. This is not hard evidence, but an interesting observation.

Concerning the non-stationary noise, I think there is evidence that it's correlated with the DARM low frequency RMS. I computed the GDS-CALIB RMS between 20 and 50 Hz (whitened to the median to weight equally the frequency bins even though the PSD has a steep slope), and the LSC_DARM_IN1 RMS between 2.5 and 3.5 Hz (I tried a few different bands and this is the best). There is a clear correlation between the two RMS, as shown in a scatter plot, where every dot is the RMS computed over 5 seconds of data, using a spectrogram.

 

 

Images attached to this report
Comments related to this report
gabriele.vajente@LIGO.ORG - 11:01, Wednesday 18 October 2023 (73554)
Link

DARM low frequency (< 4 Hz) is highly coherent with ETMX M0 and R0 L damping signals. This might just be recoil from the LSC drive, but it might be worth trying to reduce the L damping gain and see if DARM RMS improves

 

Images attached to this comment
gabriele.vajente@LIGO.ORG - 13:04, Wednesday 18 October 2023 (73560)
Link

Bicoherence is also showing that the noise between 15 and 30 Hz is modulated according to the main peaks visible in DARM at low frequency.

Images attached to this comment
elenna.capote@LIGO.ORG - 20:53, Wednesday 18 October 2023 (73579)
Link

We might be circling back to the point where we need to reconsider/remeasure our DAC noise. Linking two different (and disagreeing) projections from the last time we thought about this, it has the correct slope. However, Craig's projection and the noisemon measurement did not agree, something we never resolved.

Projection from Craig: https://alog.ligo-wa.caltech.edu/aLOG/index.php?callRep=68489

Measurement from noisemons: https://alog.ligo-wa.caltech.edu/aLOG/uploads/68382_20230403203223_lho_pum_dac_noisebudget.pdf

christopher.wipf@LIGO.ORG - 11:15, Friday 20 October 2023 (73620)
Link

I updated the noisemon projections for PUM DAC noise, and fixed an error in their calibration for the noise budget. They now agree reasonably well with the estimates Craig made by switching coil driver states. From this we can conclude that PUM DAC noise is not close to being a limiting noise in DARM at present.

Images attached to this comment
jeffrey.kissel@LIGO.ORG - 09:51, Tuesday 24 October 2023 (73691)CDS, CSWG, ISC, OpsInfo, SUS
Link 

To Chris' point above -- we note that the PUMs are using 20-bit DACs, and we are NOT using and "DAC Dither" (see aLOGs motivating why we do *not* use them in LHO:68428, and LHO:65807, namely that [in the little testing that we've done] we've seen no improvement, so we decided they weren't worth the extra complexity and maintenance.)
christopher.wipf@LIGO.ORG - 15:25, Tuesday 24 October 2023 (73710)
Link

If at some point there’s a need to test DAC dithers again, please look at either (1) noisemon coherence with the DAC request signal, or (2) noisemon spectra with a bandstop in the DAC request to reveal the DAC noise floor.  Without one of those measures, the noisemons are usually not informative, because the DAC noise is buried under the DAC request.

christopher.wipf@LIGO.ORG - 18:35, Friday 27 October 2023 (73784)
Link

Attached is a revised PUM DAC noisemon projection, with one more calibration fix that increases the noise estimate below 20 Hz (although it remains below DARM).

Images attached to this comment
H1 SQZ
camilla.compton@LIGO.ORG - posted 14:51, Tuesday 17 October 2023 - last comment - 18:30, Tuesday 24 October 2023(73524)
SQZ OPO Crystal Moved

Naoki, Vicky, Sheila, Camilla. WP 11470.

OPO Crystal Move

Following last time we moved the OPO crystal 65684, we used the wincam dell laptop and gray E-870 PI shift driver box (stored in LVEA SQZ cabinet) and the OPO crystal cable Daniel attached the the +X HAM7 flange. Adjusted OPO temperature from 31.684 degC to 31.804 degC for co-resonance while scanning rather than stationary. 

To scan the OPO PZT fast enough, we used external function generator and Thorlabs driver at the racks for the OPO PZT to scan over more than 1 FSR (around 1-9V scan). 

We were able to move the OPO crytal over its full range and found 6 spots with red/green co-resonance, attached pdf shows the places we moved. LLO found 10-13 potions which is surprisingly more than us, 73502. 

Through O4 we've been using the 2nd posltion from the right, but left the crystal on the 2nd spot from the Left. 

Photos attached of the PZT scan (yellow trace), OPO IR trans light measured on HD PDA (pink trace), Green trans from CLF path (green trace). The green alignment looked bad at all spots. This could be from misalignment of OPO path or HOMs present in fiber. When we next go into HAM7 we can look at this. 

NLG Measurement

Turn down green pump power with SQZT0 wave plate to 4mW in to stop the OPO lazing. We measured NLG of 14 (OPO_IR_PD_LF_OUTPUT amplified / unamplifed = 0.0136/0.00092). This reduced to NLG of 12 over a few minutes. 

Homodyne Measurement 

We balanced the HD by reducing the seed power and realigned to maximize visibility. At start of measurement visibly was 14 and at the end it NLG was 12. Vicky, Sheila Naoki took Homodyne measurements which were hard with NLG drifting. Measured 4.5dB whihc is less than the 6dB measured last week 73376. But we think we could have offloaded the ASC alignments incorrectly to not see good SQZ on the HD.  

SQZ in IFO

Ended with NLG of 13.5 into IFO. Amplified power of 0.0196, unamplified seed of 0.00149. Though this may be changing quickly. 

Took some no sqz data while TJ tested updates to the Observing with No SQZ wiki. Accepted sdfs to go back into observing. Vicky adjusted OPO tempurature and had to adjust the SQZ angle from 142 to 163, squeezing looks better 4dB+ but we expect the angle and OPO tempurature may need to be adjusted over the next hours...

Images attached to this report
Non-image files attached to this report
Oct17_OPO_CrystalMove.pdf
Comments related to this report
sheila.dwyer@LIGO.ORG - 16:22, Tuesday 17 October 2023 (73534)
Link

On the bad alignment of the green to the OPO shown in Camilla's photos of the scope:

We normally apply an offset to PZT1, which we were not doing this morning.  This offset impacts the cavity alignment, as you can see in Vicky's screenshots from April 2022.  62856

Here are some past alogs showing an OPO cavity scan with the green transmission.  

Dec 2022: 66527  (we should do a repeat of a scan like this now, with lowered green power and a slow scan, to see if things have really degraded). 

April 2022: 62691

Sept 22 we swapped the CLF collimator.

victoriaa.xu@LIGO.ORG - 20:37, Tuesday 17 October 2023 (73535)
Link

With this new crystal position, we have more squeezing in DARM, at first briefly measuring ~4.8 dB SQZ at 2kHz! It has since settled to ~4.2dB in Observe. As Camilla said, this is with the 2nd spot from the left edge (5th from the right). The optimal OPO temperature will be changing as it settles into this new spot, so there we may need to tune co-resonance temperature over the next few days to re-optimize.

Just before injecting SQZ to the interferometer, with OPO trans = 80uW, NLG was measured as 13.15. We took some sqz/asqz/meansqz loss measurements, and will do subtraction using the following times. Measurements using dtt cursors:

  • SQZ, ~4.8 dB
    • 1381612908 - 1381612998
  • No SQZ
    • 1381613053 - 1381614325
  • Anti-sqz, 14.0 dB
    • 1381616445 - 1381616576
  • Mean-sqz, 11.0 dB
    • 1381616609 - 1381616740
  • After 22:33:40 UTC (gpstime 1381617238), we went back to Observe with SQZ at this spot.

Loss analysis and subtraction to follow.

NLG variation over an early ~6min of operating at this new spot is interesting. I think we see the crystal's green losses increasing rapidly. In the screenshot, the OPO was locked in green (~80uW green transmitted power, but no intensity stabilization so green power varied).

  • We see the crystal's non-linear gain decrease by ~11.7% over 6 minutes for fixed input green power (NLG = (max_amplified/unamplified) ; the top red trend shows decay of the maximum amplified seed power. The maximum amplified seed power can be found by optimizing the OPO crystal temperature, but this decay of NLG was not recoverable by optimizing crystal temperature (bottom trend = attempts to optimize opo crystal temp).
  • NLG decay does look consistent with the decay of transmitted green power over ~6 minutes. The decay of green transmission for fixed input green power could result from fast crystal losses/absorption/etc in green. This lowered green pump power, results in a lower non-linear gain for red/sqz. That is, I think this NLG decay can be explained by fast green losses in the opo crystal, and doesn't necessarily require fast variations in red (i.e. these fast green losses don't have to also be fast red sqz losses).

edited to include: NLG measured ~7 hours later in the lockloss. After ~4 hours with stabilized green trans = 80uW, the opo co-resonance changed from 31.638 degC to 31.617 degC, and we recovered the same NLG after tuning the temperature, so the interaction strength (probably also the red losses) did not degrade much in this time.

edited to include darm sqz 15 min after relocking: SQZ reached 4.8dB again after relocking; the darker bottom SQZ trace is taken ~15 minutes into this next lock. This is operating at the new spot for ~8 hours.

Images attached to this comment
victoriaa.xu@LIGO.ORG - 18:30, Tuesday 24 October 2023 (73722)
Link

For these squeezed darms at the new crystal spot, here's adding in subtracted sqz data for these times of anti-squeezing, squeezing, and mean-squeezing (i.e. LO loop unlocked, sqz phase is unlocked from the IFO beam and spinning through all sqz angles).

Images attached to this comment
Displaying reports 14861-14880 of 86428.Go to page Start 740 741 742 743 744 745 746 747 748 End