Looking closely, one can see that the noise between 18 and 22 Hz is slighlty improved. It's small, but it's there.

I took this issue to the Noise sprint on Wednesday and Adrian Helming-Cornell, Jane Glanzer,Vishal Yalla took up the project.
Dave Barker and Erik also apparently tried to also look into this as well and by Wednesday's lunch time there was some sharing of information

The Noise Sprint group started a google doc where we put all the information that we were gathering:
https://docs.google.com/document/d/127y-9zX6So-zWHxpziH0cU9SAjMjV1lUiJrwKRHdB4A/edit

That may not be a clickable link so here is the content:

alog: https://alog.ligo-wa.caltech.edu/aLOG/index.php?callRep=71725 

 

PCAL X Noise found by Shivaraj

Shivaraj sent Rick and I a message about some noise found on H1:PCALX_TX_PD and H1:PCALX_RX_PD.
https://ldas-jobs.ligo-wa.caltech.edu/~detchar/summary/day/20230703/cal/pcal_x/

This particular noise took place on the 3rd of July, LHO was empty of people except an operator. Clear examples of this type of noise on these channels can also be found on the 4th, the 5th, and 17th of july.


Checking the same channels on EY:
There is some form of noise on H1:PCALY_TX_PD that shows up on the 11th , 12th, and 13th of this month that looks similar, though not as often and not as intense as the noise found on PCALX and it's not always on both the PCALY_TX and PCALY_RX PD at the same time like seen at EX.

I have reached out to Shivaraj, to try to learn more about this and see if it's a problem for DARM. Which it doesn't seem to be according to what he saw in Bruco .

This noise could point to a problem with our PCAL lasers since its in both TX and RX PD's on at EX. But it also could be the AOM, or the OFS being saturated , or otherwise interacting with changes in temp or humidity.

This could also be a DAQ issue, like a chassis or board because it's showing up on both channels at the same time at EX. Shivaraj mentioned that there might be "cross talk between different channels in a board, and if the glitches are in the light and seen by both PD's they would also show up in other channels, which we could likely use to our advantage."

 

PCAL Background: 

-> PCAL = Photon Calibration 

Used for calibration using test masses at the ends stations of the interferometer using a physical force

 

PCAL chassis layout: https://dcc.ligo.org/cgi-bin/private/DocDB/ShowDocument?.submit=Identifier&docid=S1400489&version=5 

 

Potential Causes: 

• Laser 
• AOM
• AOM Power Supply 

 

Tasks:

• See how often this occurs via summary pages
• Try and compare the noise to other channels (list on the way)/look for excitations
• Trend PCAL lines and systematic error in lines, do they affect transfer functions?
• (High Priority) Is H1:GRD-ISC_LOCK_STATE_N in NLN_CAL_MEAS?  State 700? 
  • Are PCAL noise bursts happening in nominal low noise (state 600), calibration measurements (state 700)
  • Can find on IDVW 
  • Alog when Power supply was replaced see if noise was present before this date.
    • We do see this noise before May 2nd in both PCALX and PCALY. April 10th-14th. Rules out power supply change.
• Some noise in the BSC9 (which is in EX) X/Y/Z channels on July 3rd 2023 from about 14-20utc from 20-40ish Hz.
  • BLRMS these channels, any temporal correlations between these guys and TX/RX noise bursts?
  • What about the endstation ground motion SEI system BLRMS?

 

Channel Names: 

(Might have correlation between calibration channels; however chassis channels are not resolving without calibration channels) 

 

• H1:CAL-PCALX_RX_PD_WATTS_OUT
  H1:CAL-PCALX_TX_PD_WATTS_OUT
• H1:CAL-PCALX_SHUTTERPOWERENABLE
• H1:CAL-PCALX_RECEIVERMODULETEMPERATURE   (Jitter on channel) 
• H1:CAL-PCALX_TRANSMITTERMODULETEMPERATURE ( Jitter on channel) 
• H1:CAL-PCALX_OPTICALFOLLOWERSERVOOSCILLATION
• H1:CAL-PCALX_OFS_AOM_DRIVE_MON_OUTMON 
  • H1:CAL-PCALX_OFS_AOM_DRIVE_OUTMON (Plotting)
• H1:CAL-PCALX_WS_PD_OUTMON
• Effectively any channel that starts with H1:CAL-PCALX_ [ varable ]
  AOM , OFSPD, OFS, TX, RX, OPTICALFOLLOWER

 

Calibration channels:  

Link to GSTAL If you find a time that the kappas have some weird signals then check out the GSTAL data for those times as well.

 

• H1:CAL-CS_TDEP_KAPPA_UIM_OUTPUT 
• H1:CAL-CS_TDEP_KAPPA_PUM_OUTPUT
• H1:CAL-CS_TDEP_KAPPA_TST_OUTPUT
• H1:GRD-ISC_LOCK_STATE_N Look for state 700

 

Chassis documentation: https://dcc.ligo.org/LIGO-D1400153

 

Other instances:

June 9

June 10 - few lines

June 11 - few lines

June 19

June 24

July 3

July 4

July 5

July 11

July 17

July 18

July 19

July 20

July 21 - few lines

July 25 - few lines

 

• DAC update:
  • The channel we use to drive the test mass is sampled at a different rate (16Hz) vs what the pcal photodiodes  (16Khz)
  • Means we may be inserting this noise into the photodiodes because of this difference, if the driving channels are only 16hz. (Later confirmed that this is not the case.) 
  • H1:CAL-PCALX_TX_PD_WATTS_OUT_DQ  and the corresponding RX channels on both X and Y end are all not available on LIGO-DV web. Though they are available on the CDS network and the control room. 
  • Going to get 16kHz DAC readback channels that are faster to try and confirm if this is the issue. Working with Dave and Erik, we have confirmed that the driving channels are 16khz channels but the readback channels are still only 16hz which prevents us from getting analysis results above 8 hz using LIGO DV. 
  • Using ndcscope & Diaggui we have confirmed that there is an issue when the Roaming PCAL X line changes. Which is a PCAL Line that gets changed by a Gaurdian node every 24 hours of NLN Lock state. The issue is that the Roaming X line is changed without a ramp down/up time. This may be the start of the noise that we are seeing but this has not been confirmed yet. The solution to this would be to add a second channel, and ramp down the initial channel and replace the initial frequency of the roaming X line with a ramp up of the next frequency.  

I have 2 gps times that I have narrowed this down to happen between.

Between 1372456038 -1372456158


Calibration channels:  

July 4th, 2023: 16:00:00 - 18:00:00 UTC (1372510818 GPS) 

 

H1:CAL-CS_TDEP_KAPPA_PUM_OUTPUT, raw,start: 2023-07-04 16:00:00 (1372521618) len: 2:00:00.

H1:CAL-CS_TDEP_KAPPA_UIM_OUTPUT, raw,start: 2023-07-04 16:00:00 (1372521618) len: 2:00:00.

H1:CAL-CS_TDEP_KAPPA_TST_OUTPUT, raw,start: 2023-07-04 16:00:00 (1372521618) len: 2:00:00.

 

 

 

 

July 3th, 2023: 14:00:00 - 16:00:00 UTC (1372510818 GPS) 

 

H1:CAL-CS_TDEP_KAPPA_PUM_OUTPUT, raw,start: 2023-07-03 14:00:00 (1372428018) len: 2:00:00.

H1:CAL-CS_TDEP_KAPPA_UIM_OUTPUT, raw,start: 2023-07-03 14:00:00 (1372428018) len: 2:00:00.

H1:CAL-CS_TDEP_KAPPA_TST_OUTPUT, raw,start: 2023-07-03 14:00:00 (1372428018) len: 2:00:00.

 

 

https://ldas-jobs.ligo-wa.caltech.edu/~detchar/summary/day/20230703/cal/pcal_x/ 

 

More searching is needed to ensure that this is resolved.

You can see from the in-lock charge plots that V_eff changed the direction of it's trend at certain times, roughly listed below. In the plot attached, the bias voltage applied to the DC ESD changed at certain times 68123 67698. I wanted too see if these times agreed (shown in G1600699). More investigation is needed as the current plots only go back as far as March but this could explain the trend in ITMY V_eff. Not shown in plot is that EX bias was off 10 March to 05 April 2023 (68446).

Optic	V_eff changed direction, plots above.  estimated dates	Bias voltage applied to the DC ESD changed, plot attached
ITMX	Feb/March 2023	No change
ITMY	April 2023	23rd April 2023
ETMX	No change	28th Feb 2023
ETMY	end of April 2023	28th Feb 2023

The sdf diff screen in the screenshot isn't the real diffs. This is showing "FULL TABLE" and "SORT ON SUBSTRING: DHARD_Y". How I left it yesterday.  To see the actual diffs, you should change the dropdown boxes to "SETTING DIFFS" and "SHOW ALL". I expect the diffs were from waiting for the ADS camera's to converge. 

Brina, Genevieve, Camilla

We took a look at this lockloss to see if there were any anomalies in the optics. We saw some motion in the ETMX channels starting at 2023/07/25 23:54:54 UTC (~40ms before the lockloss).

Daniel pointed out that FM4,7,9 are turned off when FM6 is turned on. These filters all have 5 second ramp times so we are probably getting the transient from these filters being still ramping down as the gain is ramped up. I've accepted these as OFF in the safe.snap sdf see attached. So they should be reverted on sdf revert.

We saw a similar transient in DHARD_P but haven't looked at it yet so we should repeat this process with other filters.

Most of the individual filters in this module have a 2-5s ramp time. For whatever reason, FM4/5/7/9 are all on just before DHARY gets engaged, They then get turned off while FM6 is turned on, a short time before the input to the moduleis turned on. However, there is not enough time for these filters to ramp off, so they are still on during the inital gain ramping. 

This transient is not visible in the optics anymore, see attached. I'll put the tramp back to 5s but ISC_LOCK will need to be reloaded when we are out of observe. Opened and closed FRS 28647. 

Brina, Genevieve and Lance are going to look for transients from other filters and at other times, Elenna suggested checking DHARD_P. 

How to turn off RFSBs.

Disconnect the cable for 118MHz on the patch panel at the bottom of the PSL rack (1st picture).

On top of the patch panel there's a 24MHz amplifier, don't turn it off.

On top of the 24MHz thing, there are amplifiers for 9MHz and 45MHz. You will turn off the output of both (2nd picture showing the 45MHz unit with the RF output switch in OFF position).

If we just believe TCS frontend simulation, H1:TCS-SIM_ITMY_SUB_DEFOCUA_FULL_SINGLE_PASS_OUTPUT was ~17.05uD during the last OMC scan before we gave up.

We might be able to use this to distinguish between the two patches in the MM parameter space (update in https://alog.ligo-wa.caltech.edu/aLOG/index.php?callRep=71477) but I'll wait for the OMC scan fitting results.

Executive Summary: The mode mis-match with no central heating on the ITM is 8.2%, the mode mis-match with central heating on the ITM is 3.6%.

For the first scan:

T0 = 1373734011

delta T = 87s

OMC scan is shown in the first png image.

Fitted C20/02 peak is shown in the first pdf.

We expect the HOM spacing to be 0.588 MHz as per this entry and DCC T1500060 Table 25.

The mode spacing is 148.796 - 149.388 = 0.592 MHz.

The ratio of second order to zeroth order carrier is (0.575 + 0.853)/(0.575 + 0.853 + 15.90) = 0.082 = 8.2 % mode mis-match

To run the code checkout git branch /dev of labutils and run measurement.

python OMCscan_nosidebands3.py 1373734011 87 "Sidebands off, 10W input, cold ITM + OM2" "single bounce" --verbose -m -o 2

and for the split peak fitting:

python fit_two_peaks_no_sidebands3.py

 

For the second scan:

T0 = 1373736206

delta T = 90s

OMC scan is shown in second png image.

Fitted C20/02 peak is shown in the second pdf.

The mode spacing is 148.741 - 149.338 = 0.597 MHz.

The ratio of second order to zeroth order carrier is (0.201 + 0.428)/(0.201 + 0.428 + 17.02) = 0.036 = 3.6 % mode mis-match

Run the following on the same git branch.

python OMCscan_nosidebands4.py 1373736206 90 "Sidebands off, 10W input, hot ITM + cold OM2" "single bounce" --verbose -m -o 2 -p 0.01

and for the split peak fitting:

python fit_two_peaks_no_sidebands4.py

data is in labutils/omc_scan/data/2023-07-18

files in labutils/omc_scan

figures in labutils/omc_scan/figures/2023-07-18

Summary:

Incorporated the fit results and updated the plot. Original analysis is in alog 71145.

In the attached, there are two pairs of patches, each pair comprising yellow and lighter blue, that represent the previous measurement (alog 71145 where ITMX single bounce was used with no TCS, OM2 hot/cold) and two pairs, each pair comprising greenish blue and darker blue, that represent the measurent done this time (ITMY single bounce, cold OM2, TCS ON/OFF).

Since it's impossible that the beam parameters of ITMX single bounce beam on the OMC are totally different from those of ITMY single bounce, you can just look at the distance between pairs and judge which ones represent the reality. In this case, the patches in the left half plane are the clear winners.

Details and caveats:

Calculation done for the ITMY single bounce is exactly the same as ITMX except that the measured losses are different and the mode actuator is ITMY central TCS instead of OM2.

As for the TCS optical power I  used H1:TCS-SIM_ITMY_SUB_DEFOCUS_FULL_SINGLE_PASS_OUTPUT~17uD for the central heating (zero for no heating). I simply doubled the number for double-pass effect. If this is grossly off the result might look different.

Since 1st order HOM power was not negligible in ITMY single bouncer scan, as a first order approximation, I used P2/(P0+P1+P2) as the measured mode matching loss where P0, P1 and P2 are the power of 00, 1st order and 2nd order mode (for the 2nd order mode, 20 and 02 were resolved by the fit code). I've done this to ITMX single bounce scan too just for consistency.

If the model is perfect and has everything, the difference between yellow "X, OM2" and greenish-blue "Y, OM2 Cold/TCS OFF" should be explained by the difference in the ITM ROC, substrate lensing/heating including the TCS (and IFO heating prior to lock loss, since we haven't waited for hours and hours after the IFO was unlocked). It would be interesting to see if ITM difference will make the plot look any different.

However, the model doesn't have ITMX and ITMY, it's just a single ITM at the average location. Though it's easy to implement that feature in principle, I have a suspicion that the numbers used for ITM substrate lens effect in the past could be off, and I've contacted GariLynn. Wait for the conclusion of that discussion.

A big caveat is that you cannot quickly draw conclusion about the full IFO mode matching from this. At the very least, you have to take into account that the arm mode is primarily determined by the HR and that the carrier coming to OMC from inside the arms only experience the ITM lensing once (-ish).

Another big caveat is that the ADC was railing for the 00 mode peak. Look at the 2nd attachment bottom where H1:OMC-DCPD_B_STAT_MIN=-(2^19). It's not as bad as the finesse measurement (alog 71888) as the scan was slower, but if we want a better data we need to redo it with lower power or w/o x10 gain.

Last attachment shows what happens when you change OM2 (left, 1 step in the plot = maximum range of the T-SAMS) or ITM heating (right, 1 step = 10uD single pass).

Update: it's coherent with H1_PEM-EX_VMON_ETMX_ESDPOWER48_DQ and H1_PEM-EX_VMON_ETMX_ESDPOWER18_DQ, and *not* with CS or EY VMON channels.

(Last time we tried to hunt this comb down, I think we didn't have high resolution coherence plots generated to high enough frequencies for these channels.)

Plots attached. The gray dots are harmonics of a separate 99.9989 Hz comb.

It looks like the behaviour of this comb changed again on July 13, shifting slightly in frequency, before then disappearing again on July 14. It is as yet unclear what caused the changes.

The attached weekly average Fscan From July 12 - 19 shows these changes around 280 Hz especially.

This comb seems to reappear between 7:30 and 9:00 UTC on July 19, 2023. Hopefully this time range can point to something that specifically changes. See attached daily Fscan image