Reports until 14:50, Friday 20 January 2023
H1 ISC (CDS, ISC)
jeffrey.kissel@LIGO.ORG - posted 14:50, Friday 20 January 2023 - last comment - 14:31, Monday 23 January 2023(66923)
PRM HSTS M1 OSEM Damping Reverted to Former Filter Design -- BUT ONLY In L and P (All other Recycling Cavity HSTSs Remain With New Design)
J. Kissel, E. Capote, J. Driggers, S. Dwyer

Elenna and I were discussing the impacts of installing the Level 2 "low-noise" damping filter designs that have been turned ON for PRM, PR2, SRM, and SR2 the other day, (LHO:66859), and while doing so she, and the IFO, revealed that they've been having intermittent problems with a 3.3ish Hz oscillation during lock acquisition -- specifically while paused at PREP_ASC_FOR_FULL_IFO. In this state, we're still on RF DARM, at 2W PSL input power, but PRCL and SRCL are on their final in-vac sensing chain. Also, no fast ASC loops are on except for DHARD_P and DHARD_Y which feed back to the test masses (i.e. NOT HSTSs), but all WFS DC centering loops are on. 

It was bit chaotic, because 
    - an instance of the oscillation was actively happening where 3.3 Hz motion shows up in a lot of ISC and SUS channels, 
    - we found that a *different* 3.3 Hz damping system -- QUAD L2 to R0 damping -- was OFF LHO:66921
    - A common, occasional, confirmed unrelated, problem, that RM2 DAC outputs were saturating because the DC alignment is close to the edge of the DAC range was currently happening,
    - a brute-force suggestion was to revert all of the damping to the old filters, 
    - all while we were walking through 16 different sets of plots of metrics that we had that showed "it should be fine!," 
but because of Jenne's quick look through the ASD of all top mass OSEMs, she narrowed down the place where a 3.3ish Hz oscillation was the loudest to PRM, in longitudinal and pitch. 

So, on an impulse, I just turned off the ONLY L and P damping loops on PRM. 

This immediately stopped the oscillation, and the IFO remained happily locked with no abnormal loud monochromatic oscillations. Huh.

We've got lots more investigating to do as to why *only* the PRM's change to only the L and P filters makes so much difference, but for now, we're NOT "throwing the baby out..." and reverting ALL HSTS damping, but instead *ONLY* reverting the L and P damping loops for PRM. Said again, but differently, all other DOFs of recently "upgraded" damping loops remain in the newer configuration (including L and P filters for PR2, SRM, and SR2).

Attached is a screenshot of the configuration of the PRM M1 DAMP screen, and the screenshot of the acceptance in the SDF.

Images attached to this report
Comments related to this report
jeffrey.kissel@LIGO.ORG - 15:18, Friday 20 January 2023 (66924)CSWG, ISC, SUS
E. Capote, J. Kissel

Here's an interesting comparison of the top-mass OSEMs in three different L and P damping configurations (again, all other DOFs remain in the upgraded configuration during all three configs):
    - Former Design -- "old" design,
    - No L and P damping -- "no damping",
    - New Design -- "new" design

Looks like, at 3.3-ish Hz,
    - for L, "old" and "no" damping on are comparable and "new" makes things worse.
    - on the contrary, for P, "old" and "new" are comparable, and "no" is bad.

So -- thus far, my conclusion is that something about the PRM snow-flake is unique, and we might need to tailor the longitudinal loop -- and perhaps only a bit to improve / reduce the impact of this mode.... maybe.

 
Images attached to this comment
jeffrey.kissel@LIGO.ORG - 16:58, Friday 20 January 2023 (66927)CSWG, SUS
E. Capote, J. Kissel

Here's a similar comparison of 4 traces worth of PRCL and SRCL in three PRM L and P damping configurations -- again during PREP_ASC_FOR_FULL_IFO with low, 2W PSL input power:
   - "New damping, start of the lock" -- new damping on all SUS, all DOFs using the new damping filters
   - "New damping, later in lock" -- same configuration 
   - "No damping" -- PRM L and P damping loops OFF (all other sus and DOFs ON, still using the new damping filters)
   - "Old damping" -- PRM L and P damping loops reverted to old filters ON (all other sus and DOFs ON, still using the new damping filters)

Some conclusions:
   - This time around, PRCL and SRCL are in general a bit noisier, dominated above ~3 Hz by some other noise that when the IFO is at high power in nominal low noise -- i.e. what Elenna shows in this plot from LHO:66885. That means we don't see the *worsening* of the broad band noise that we see in that previous plot.

     Apologies: both this aLOG's plots and LHO:66885's plots of SRCL and PRCL are *not* completely calibrated. Yes, the channels used are the H1:CAL-CS_PRCL_DQ and H1:CAL-CS_SRCL_DQ channels, but their digital whitening before storing in the frames, five zeros at 0.3 Hz and five poles at 10 Hz, have not been removed. However, both aLOGs plots are not completely calibrated in *the same way* so any differences between the two are physical differences in the SRCL and PRCL displacement, either due to the damping loop differences or, much more prominently for the frequency region above ~5 Hz, that the IFO in this aLOGs plot is not yet in it's lowest noise state at high power. So the fact that we *don't* see the ~5-10 Hz region get broad-band *worse* in these aLOGs plots like we do in LHO:66885 is not inconsistent, it's just that this aLOG's IFO configuration is noisier.

BUT, all that aside, in this aLOG focusing on what changes we *do* see, 
   - In the PRCL plot, with the old damping filters, the 0.8 and 1.7 Hz modes are a little bit louder than with the new damping filters. That makes me happy, because I designed the new filters to have a bit more damping at these resonances. At the beginning of the lock, the problematic L / P resonance at 3.3 Hz is a bit louder with the *new* filter *and* we see a bit of the first harmonic of the 3.3 Hz resonance at 6.6 Hz. Also, not terribly unexpected, since I've sacrificed loop gain at this mode in order to create phase margin for the new low-pass filter which more aggressively cuts of 10 Hz and above. Once we sit there for a bit, though, clearly something gets mad about this level of 3.3 Hz mode in PRM -- and PRM alone -- because it starts to ring up throughout the IFO. Hurumph.

   - In the the SRCL plot, the story is interesting: 
       :: in the old damping configuration of PRM's L and P DOFs, the 0.8 and 1.7 Hz in *SRCL* are louder than with the new damping filter design. So, somehow, improving the PRM L and P filters quite dramatically improves the 0.8 and 1.7 Hz performance of SRCL. Maybe this is because SRCL uses some of the same sensor -- POP9 I -- to "subtract" the fundamental PRCL coupling from SRCL (which is nominally, mostly a separate, POP45 I sensor).

       :: this coupling between PRCL and SRCL is confirmed by the "later in lock" results when the 3.3 Hz mode sneaks above the other (presumably SRM or SR2) equivalent SRC cavity HSTSs, and its first harmonic 6.6 Hz is quite visible in SRCL the entire time.

So -- this could be a clue as to why all previous SISO attempts at modeling SRCL noise with damping-loop-injected SRC HSTS and HLTS OSEM noise never really successfully predict the noise... 

But yeah, the above comment's conclusion still stands -- we could just run like this for now :: with just PRM's L and P filters un-upgraded :: and then over-time take some more measurements to understand why PRM is the unique snowflake among the other recycling cavity HSTSs.
Images attached to this comment
elenna.capote@LIGO.ORG - 14:31, Monday 23 January 2023 (66949)

I have witnessed some concerning ~2 Hz motion in the yaw ASC loops that seemed to appear after the HSTS damping change. Since we are already seeing problems with PRM in L and P, I am concerned that the 2 Hz yaw mode might also be causing problems. Again, we don't know exactly why yet, and we will make use of maintenance time tomorrow to make some measurements of PRM. For now, I have reverted the PRM yaw damping to the "old" design. I have also SDFed this, see screenshot, and I can assure you that I *did* hit confirm after I saved the screenshot.

My main motivation here is to give some of the calibration and DetChar folks decent NLN quiet time without worrying 2 Hz shaking. I don't expect this to be a permanent solution.

Images attached to this comment