N. Aritomi, J. Kissel, C. Compton, T. Shaffer

As we were poking around for ideas as to why violin modes are now constantly getting rung up, we found that the lock-loss triggers were never installed in any of the parametric instability damping control models. TJ's doing some trending in parallel to me writing, and I hear him verbally convincing himself via trends that this isn't the source of violin mode ring ups; I guess he'll write a comment, or something to share his convincement. 

For those who haven't heard of these "lock loss triggers" -- they're fast-front-end, 16 kHz speed triggers that shut off all global control to the suspensions to ensure that -- upon lockloss -- no garbage ISC control signals (including violin mode damping) are sent to the test masses -- which have historical been a source of violin mode ring up.

Regardless, of whether TJ's convinced that this isn't our problem *today,* I still think this is an oversight in the design that should be rectified.

I've opened a work-permit this this to be done in one of the upcoming maintenance days -- WP:11322.

Shown are the recommended places where the lock-loss tool should interrupt the signals in 
    - h1susetmypi.mdl (and h1susetmxpi.mdl should be modified in the same way) and 
    - h1susitmpi.mdl

WP11314 Ramped CP1 fill

Gerardo, Richard, Travis, Jordan, Dave:

My code change was not ready for today's 10:00 fill, so we did one at the old time of 13:15.

Gerardo confirmed this was a good fill curbside.

New code summary:

Opening the LLCV is now ramped over 5 minutes

Closing is still as fast as the valve can move.

The code change details:

New PV added to IOC: H1:VAC-CP1_OVERFILL_LLCV_RAMP_TIME_SECONDS

The YAML configuration file parser now reads a new llcv_ramp_time_seconds line (default is 0)

At time of fill, instead of setting the LLCV to MAX_VAL as part of the pre-fill, it now overwrites the starting value to test caput is working.

In the fill loop, if the run_time is within the ramp_time, the LLCV is ramped to the next value.

If ramp time=0, the LLCV is set to the MAX_VAL in one caput, identical to pre-ramp code.

If during the ramping an end-of-fill condition is detected (cancel, fill-completed, TC failure, discharge line pressure out-of-bounds) the fill is stopped and LLCV returned to starting position.

Note that opening the LLCV is ramped, but closing it back to the starting value is still done with a single write (prevents excessive LN2 loss when overflowing).

Attached trends show both the standard logarithmic version, and a linear one zoomed in to show the new ramp

Carried out some noise injections while violin modes were being damped. Analysis will follow. Times below

ASC-DC3_Y_EXC
    butter("BandPass",8,0.5,5)zpk([],[1.5+i*2.59808;1.5-i*2.59808;1.5+i*2.59808;1.5-i*2.59808;1.5+i*2.59808;1.5-i*2.59808],1,"n")
   
ampl 10
start    PDT: 2023-07-17 12:12:25.248450 PDT
         UTC: 2023-07-17 19:12:25.248450 UTC
         GPS: 1373656363.248450
stop     PDT: 2023-07-17 12:14:28.217030 PDT
         UTC: 2023-07-17 19:14:28.217030 UTC
         GPS: 1373656486.217030

ampl 30
start   PDT: 2023-07-17 12:15:09.156033 PDT
        UTC: 2023-07-17 19:15:09.156033 UTC
        GPS: 1373656527.156033
stop    PDT: 2023-07-17 12:19:34.343574 PDT
        UTC: 2023-07-17 19:19:34.343574 UTC
        GPS: 1373656792.343574

DHARD_Y_EXC 
resgain(0.22, 2,14)resgain(0.48,3,20)resgain(2.5,8,15)cheby1("BandPass", 6,1, 0.05,3)gain(2000)zpk([1],[0.1],1,"n")

ampl 0.6
start   PDT: 2023-07-17 12:25:39.173166 PDT
        UTC: 2023-07-17 19:25:39.173166 UTC
        GPS: 1373657157.173166
stop    PDT: 2023-07-17 12:30:06.552000 PDT
        UTC: 2023-07-17 19:30:06.552000 UTC
        GPS: 1373657424.552000

ampl 1.0
start   PDT: 2023-07-17 12:30:58.643632 PDT
        UTC: 2023-07-17 19:30:58.643632 UTC
        GPS: 1373657476.643632

resgain(1.2,5,10)resgain(0.22,3,20)resgain(0.45,2,22)resgain(2.2, 1.5,23)
cheby1("BandPass",6,1,0.08,3)gain(1000)zpk([1],[0.1],1,"n")
ampl 1.0

start PDT: 2023-07-17 12:37:54.797826 PDT
      UTC: 2023-07-17 19:37:54.797826 UTC
      GPS: 1373657892.797826

Since our violins troubles June 26/27th, 71129, 71342, 71063, the higher harmonics have remained very rung-up, see attached plot. These higher harmonics do not damp during our lock although Rahul and the SUS team are starting to look into doing this. Jenne suggested in 71063 that this could be the cause of our fundamentals re-ringing up on each lockloss.

C. Compton, J. Oberling

With the lockloss I took the opportunity to walk Camilla through adjusting the ISS diffracted power %, as it has been trending a little low since last week's PSL recovery.  We increased the ISS RefSignal from -2.01 V to -2.00 V, which brought the ISS diffracted power % to ~2.5% (it does move around a little).  This change was accepted in the ISS SAFE SDF to prevent a SDF revert from inadvertently reverting the ISS RefSignal (see attached screenshots; it looks like last week's adjustment from -2.02 V to -2.01 V was not captured in SDF).

We did not run the CP1 fill at 10am today. I am making a code change (WP11314)  to ramp the LLCV open. We will run it this afternoon, hopefully while H1 is locked o see if we have reduced the impact on the range.

1373650934 after 10h13 in NLN. No obvious reason for LL.

While doing my usual Monday morning PSL checks I noticed the chiller was throwing an alarm.  Upon investigating I found it throwing a Low Level alarm, so I added 150mL of water to top it off.  This stopped the alarm.  According to the fill log and a quick alog search we have been adding ~150mL every 6 weeks or so; this is in contrast to the old PSL chiller (O1 through O3), where we were adding ~150mL on a weekly basis.  Everything with the chiller looked OK.

TITLE: 07/17 Day Shift: 15:00-23:00 UTC (08:00-16:00 PST), all times posted in UTC
STATE of H1: Observing at 135Mpc
CURRENT ENVIRONMENT:
    SEI_ENV state: CALM
    Wind: 21mph Gusts, 15mph 5min avg
    Primary useism: 0.06 μm/s
    Secondary useism: 0.06 μm/s
QUICK SUMMARY: IFO has been in NLN 7h30

Dust monitors, VAC, SUS, SEI, CDS okay.

TITLE: 07/17 Owl Shift: 07:00-15:00 UTC (00:00-08:00 PST), all times posted in UTC
STATE of H1: Lock Acquisition
SHIFT SUMMARY:

EQ recovery mostly handled by Ryan C at beginning of shift.  Per suggestion from Rahul via TeamSpeak, looked at Violins after locklosses, but could not find anything out of the ordinary over our recent woes and back 2+weeks ago and earlier, when they were much better. 

H1's been locked for about 7.5hrs (double coincidence for most of this time).

Winds are picking up, and a bit cooler (73degF) than yesterday morning.
LOG:

• 0727 OBSERVING
• 1441 Restarted out-building weather (per alog 66769).  They were roughly down from 1130-1440utc.

Smooth Sailing Shift thus far with H1 locked for 3.5+hrs, ~136Mpc, low winds, & no noticeable EQs.

TITLE: 07/17 Owl Shift: 07:00-15:00 UTC (00:00-08:00 PST), all times posted in UTC
STATE of H1: Lock Acquisition
CURRENT ENVIRONMENT:
    SEI_ENV state: CALM
    Wind: 18mph Gusts, 14mph 5min avg
    Primary useism: 0.04 μm/s
    Secondary useism: 0.05 μm/s
QUICK SUMMARY:

Receiving a nice H1 very close to be OBSERVABLE...babysitting violins and away we will go!

Surprised to see winds tonight, but looks like they are waning *knock on wood* & it's a balmy 81degF.  Here's to no earthquakes!

TITLE: 07/16 Eve Shift: 23:00-07:00 UTC (16:00-00:00 PST), all times posted in UTC
STATE of H1: Lock Acquisition
SHIFT SUMMARY:

• Lockloss from a 6.6 from Argentina
• Ran an initial alignment
• Currently in OMC_WHITENING damping violins as of 07:00UTC
• Handing off to Corey

Lock#1:

• I reloaded the SUS_CHARGE guardian at 23:26UTC for changes Camilla made and if we lose lock I'll reload the rest of the ESD_EXC_{QUAD} guardians. I reloaded these at 03:53UTC
• The PSL anteroom dust monitor yellow alarmed a few times but went down after 5-10 minutes.
• We got hit by a 6.6 from Argentina at 3:18 UTC and lost lock at 03:29

Lock#2:

• Starting trying to relock at 4:10UTC
• both arms went through increase flashes, Yarm finished quickly and was able to lock although still a little shaky, Xarm took its time in increase flashes as usual but got it after 2 rounds
• Seismic to calm at 04:29UTC
• Couldnt get DRMI (a few flashes at 100) or PRMI (No flashes above 20), went to CHECK_MICH_FRINGES which was successful then Lockloss during PRMI 04:39UTC

Lock#3:

• Lockloss at ALS ( The wind was picking up at this point and stayed around 20-30 mph for the next hour) 04:41UTC

Lock#4:

• Couldnt get DRMI, or PRMI I tried to help but it went to CHECK_MICH pretty quickly. AS_AIR looked Yawed. Lockloss during CHECK_MICH 04:52UTC, going to start an IA

Lock#5:

• Started IA at 04:53UTC
• Another EQ came through during IA, 5.6 from Indonesia
• No issues in IA until I couldn't get SRY, AS_AIR look great, and I couldn't maximize ASC_AS_A_DC_NSUM_OUT16 with any combination of SRM pitch/yaw
• I decided to back into regular locking at 05:31UTC, DRMI flashes looked much better and it was able to catch after a few minutes
• Had to stop at OMC_WHITENING to damp violins at 06:16UTC

LOG:

No log for this shift

Thought we were gonna make it but then the R wave came through and took us out. Lockloss at 03:29UTC, I'm gonna hold at pre_for_locking for things to calm down a bit.

[Jenne, Naoki, Brina, Caden, Robert, Lance, Camilla]

Since alignment changes were so impactful yesterday (alog 71302) and we still have higher noise than when OM2 was hot last week, and also higher noise than our April 60W times with cold OM2 (eg, Elenna's alog 71284 yesterday), we tried some alignment shifts today with some PEM vibration injections going, to see if we could find a better alignment.  For now, we've left the IFO with the same settings it had last night since there's nothing that's significantly better.  Nothing we've found comes close to matching the broadband (good) noise level of the April 60W time, or the last week hot OM2 times.

• The camera servos are very slow, so I wanted to switch back to ADS. However, just asking the camera servo to do so dramatically changed the alignment of the IFO; arm buildups were going down and some of the ASC looked unstable.
  • There isn't a handy way to switch back to the camera servos without having the offsets be set to your current position, so we used the Camera servo guardian to go back to using the cameras (which reset the camera offsets), and then Naoki by hand set the camera servo offsets to where we had been overnight.
  • I then turned on the A2L excitations (but not the servos), and changed the A2L gains to zero the error signals.
  • Then we again used the camera servo to switch over to ADS, and we saw much less change in the circulating power buildups. The third attachment shows the situation at that time. 
    • Note that this means that after a long time of thermalization, the place the ADS would keep the IFO is different than the place the camera servos keep the IFO.  I *think* that it's better with the camera servos, since that's where we're maintaining better buildups. 
• Once back on ADS, I tried moving A2L setpoints to see if that would change the jitter peak around 120 Hz, and see if it would change the broadband excess noise we seem to have. I also tried changing the AS36Q yaw offset, but I think that even with A2L moves, the current value of 35k count offset is the best.
  • I can pretty dramatically change the circulating arm powers.  In particular, changing the ETM Y2L set points was giving us an extra 10kW circulating, but that seemed to not be the best place.
• Robert reminded me / pointed out that the 120 Hz jitter peak isn't necessarily the only thing to be mindful of, since he can likely move that by adjusting damping and weights on the PSL periscope, so we should probably focus on the broadband noise increase and try to fix that. Unfortunately, none of the moves we made today seemed to affect it. 
• Around 21:50:00 UTC seemed to be a pretty good time, but again not better than with the hot OM2.
• We ended things by trying to improve some of the low freq by changing the ITMY A2L gains.  The second attachment shows where I left things when we lost lock due to a closeby earthquake. 

The first attachment shows a big-picture of the moves we made today. 

Daniel points out that the time with OM2 hot may have been some of our best-ever sensitivity around 70 Hz.  It would be helpful to have a plot like alog 71309, but including Elenna's time from April 6th, to see if pre-O4 we ever had as good of sensitivity around 70 Hz. 

It's also a little tricky to compare our HWS data using our plotter to what Elenna and Cao posted yesterday.  It would be helpful to either have the times from Cao's plot, or have Cao plot where it looks like our ITMX spot was at 21:50 UTC today. 

Mode matching of the single bounce beam to the OMC is really bad and we don't know why. We don't even know the beam shape of the single bounce beam hitting the OMC. I constrained the beam shape by looking at the OMC scan data.

There are many OMC single bounce scans but the most recent two w/o RF SBs, one with cold and the other with hot OM2, were carefully analyzed by Jennie to resolve 02 and 20 mode as separate peaks (alogs 70502 and 71100), so I used them here.

If you just want to see the results, look at the third panel of the first attachment.

X-axis is the normalized waist position difference, Y-axis is the normalized waist radius difference. From the measured cold mode matching loss of 11.5%(!!) and hot loss of 6.2%, and the fact that the loss changed by only changing the ROC of OM2, the beam parameters hitting the OMC were constrained to two patches per each OM2 ROC. Yellow is when OM2 is cold, blue is when OM2 is hot. Arrows show how cold (yellow) patches are transformed to hot (blue) patches when OM2 ROC is changed by heating.

Note that we're talking about inconceivably huge mismatching parameters. For example, about -0.3 normalized waist position difference (left yellow patch) means that the waist of the beam is ~43cm upstream of the OMC waist. Likewise, about +0.3 normalized waist radius difference  means that the beam waist radius is 690um when it should be 490um.

We cannot tell (yet) which patch is closer to reality, but in general we can say that:

• The beam is too big (Normalized waist radius difference is positive) when the OM2 is cold.
• If the reality is more like the patches on the left half of the plot, making ROC even smaller will give us a better matching.
• If on the right half of the plot, changing ROC won't do much, we need to change the distance between OM2 and OMC.

There are many caveats. The first one is important. Others will have limited impact on the analysis.

• We don't know yet if this "MM loss" measurement is really a fair representation of mode decomposition of the beam hitting the OMC. If for example there's a position-dependent loss  (e.g. dust particulates on the OMC mirrors close to the center of the beam spot, it doesn't have to be on HR, it could be on AR of input or output coupler) the analysis will be totally off. Separate evaluation needs to be made to make sure that this isn't (or is) the case.
• I assumed that the distance between OM2 and OMC waist is as designed (~37cm). This sounds like a fair assessment as the error of a few cm hardly matters (1.4cm error corresponds to the normalized mismatch parameter of 0.01).
• I assumed that the measured MM loss could have +-10% fractional error, i.e. loss=(1+-0.1)*lossMeasured.
• I assumed that the ROC is 2m cold and 1.75m hot, but I haven't checked the thermistor, so these numbers could be off, which could have a minor impact.
• I assumed that the beam is round w/o astigmatism.

Moving forward:

• It would be difficult to down-select one of the two pairs of patches by going to the middle heating setting. It might be possible to use ITM central heating or maybe PR3. I'll look at the Gouy phase of these relative to OM2.
• Even if we can down-select, that won't give us any REAL guidance as to what we should do. We WILL see what to do to make the single bounce matching better, but doing so w/o understanding why is a risky thing. Besides, doing so might make our jitter coupling in full lock worse.
• Aforementioned characterization of the schmutz. For that matter, I suddenly remembered that Daniel wanted to see the QPD/OMCREFL ratio when I was calibrating the OMCREFL. That might help or not but I'll pull the data.
• We can do a similar analysis for full locked IFO beam.

Measured IFO beam self-heating absorption, using data form Saturday April 1st when Dan had an IFO lock with CO2s off. CO2's had been off for 6 hours, and the IFO had been locked for 2h30, see attached plot of thermal state. A better method was used in alog 66098, I'll work on how to use correctly this with Dan/Cao.

See attached plot made using Aidan's absorption plot script (instructions in TCS wiki) in /ligo/gitcommon/labutils/hws_absorption_fit/april2023.

ITMX and ITMY: ~128mW absorbed = 350ppb (128mW / 363kW arm power from H1:ASC-{X/Y}_PWR_CIRC_OUT16). Coatings are expected to have 0.5ppm (500ppb) coating absorption.

We've previously measured significantly higher absorption on ITMX, which has known point absorbers, not sure what's changed apart from significantly higher circulating power - 360kW rather than 230kW. Previously measured: