TITLE: 09/16 Eve Shift: 2330-0500 UTC (1630-2200 PST), all times posted in UTC
STATE of H1: Observing at 148Mpc
OUTGOING OPERATOR: Ryan S
CURRENT ENVIRONMENT:
    SEI_ENV state: CALM
    Wind: 12mph Gusts, 9mph 3min avg
    Primary useism: 0.01 μm/s
    Secondary useism: 0.10 μm/s
QUICK SUMMARY:

Currently observing at 150Mpc and have been Locked for 3 hours.

TITLE: 09/16 Day Shift: 1430-2330 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Observing at 155Mpc
INCOMING OPERATOR: Oli
SHIFT SUMMARY: After several EQs overnight ringing up violins, we took time to damp them before commissioning this morning. One lockloss after getting back to observing, followed by a straightforward relock.

• 14:30 - H1 up to OMC_WHITENING damping violins
• 15:54 - Reached NLN, starting commissioning
• 18:34 - Started observing, commissioning finished
• 19:16 - Lockloss - alog80119
• 20:39 - Observing

H1 has now been locked and observing for almost 3 hours.

LOG:

J. Kissel

The HAM-A driver chassis (D1100687) seems to now be the go-to, favored, coil driver for any and all new SUS stages that come along (see G1100968 for tabulated summary). However, each of these new SUS stages have different actuation requirements, so the actuator systems are often tailored to have the drivers with different output impedance, driving AOSEMs or BOSEMs, and then a bespoke magnet size.

As such, here, in prep for an update to the Controls Design Summary Table (again, G1100968), I demonstrate the output of a new, quick, comparison script 
    /ligo/svncommon/SusSVN/sus/trunk/Common/MatlabTools/
         compare_OSEM_actuator_strength.m (rev 11998)
that compares the output of our trusty "have to get it right, or else the IFO doesn't work" function that returns properties of SUS stages,
    /ligo/svncommon/SusSVN/sus/trunk/Common/MatlabTools/
make_OSEM_filter_model.m (rev 11997)
which I've just today updated to make sure that the HATS and OFIS information was correct when used.

Here's the output, sorted by total actuation strength per actuator (individual channel coil driver transconductance * single magnet+coil force coefficient):
    {'susType'}    {'isoStage'}    {'Osem Type'}    {'Magnet Size'}    {'Force Co [N/A]'}    {'Driver Type'   }    {'Driver TC [mA/V]'}    {'Total Strength [N/V]'}
    {'HATS'   }    {'M1'      }    {'B'        }    {'4.0Dx4.0T'    }    {[       0.39254]}    {'-v1 (100 Ohm)' }    {[          9.1059]}    {[           0.0035744]}
    {'BHSS'   }    {'M1'      }    {'A'        }    {'2.0Dx6.0T'    }    {[        0.0309]}    {'-v1 (100 Ohm)' }    {[          10.055]}    {[          0.00031069]}
    {'OFIS'   }    {'M1'      }    {'A'        }    {'3.0Dx6.0T'    }    {[        0.0695]}    {'-v2 (1.2 kOhm)'}    {[          0.9133]}    {[          6.3474e-05]}
    {'OPOS'   }    {'M1'      }    {'A'        }    {'2.0Dx6.0T'    }    {[        0.0309]}    {'-v2 (1.2 kOhm)'}    {[          0.9133]}    {[          2.8221e-05]}
    {'HTTS'   }    {'M1'      }    {'B'        }    {'2.0Dx3.0T'    }    {[         0.021]}    {'-v2 (1.2 kOhm)'}    {[         0.90474]}    {[          1.8999e-05]}
    {'HAUX'   }    {'M1'      }    {'A'        }    {'1.9Dx3.2T'    }    {[        0.0158]}    {'-v2 (1.2 kOhm)'}    {[          0.9133]}    {[           1.443e-05]}
    {'HATS'   }    {'M3'      }    {'A'        }    {'2.0Dx0.5T'    }    {[       0.00281]}    {'-v2 (1.2 kOhm)'}    {[          0.9133]}    {[          2.5664e-06]}

Notes: 
    - this is *per actuator*. One must go a step further and count number of actuators and lever arms if you want to convert to actuation strength in the Euler basis.
    - the magnet size is n.nDxn.nT for Diameter and Thickness (where thickness is aka length).

Just interesting to see "on paper," all in one place; not even the controls design summary table summarizes the information in this way.

Closes FAMIS#26470, last checked 79524
 
HEPI pump trends looking as expected (attachment)

Lockloss @ 19:16 UTC - link to lockloss tool

No obvious cause; I don't notice any DARM "wiggles" or "glitches" in this lockloss either.

I did two different tests to PRCL today that would hopefully help improve the low frequency noise.

PRCL feedforward test:

I tried fitting a new feedforward with Gabriele last week. We saved this in FM6. However, the comparison of the injection without feedforward and with feedforward showed that the coupling was worse with feedforward.

PRCL offset test with new HAM1 FF:

I engaged the previously tested PRCL offset (alog 79989), and tried the new HAM1 feedforward I fit. Not only does this HAM1 feedforward perform better than the previous tuning, generally the HAM1 coupling is smaller than without the PRCL offset.

Comparison plot. Compare the gold traces with the blue traces. These are both HAM1 feedforward OFF times, except gold is with no PRCL digital offset, and blue is with PRCl digital offset at -58. There is improvement in the noise in CHARD P, CHARD Y, and INP1 P (left three plots). PRC2 P noise looks the same (right side, second down). Then, red shows the new HAM1 feedforward with the PRCL digital offset. The reduction is noise is the same or better than the noise reduction achieved in the previous HAM1 feedforward tuning (see alog 79799). Again, I find it suspicious that the signifcant change seems to come from the loops that use the RF45 demod signal (CHARD and INP1), while the loop using RF9 only do not change (PRC2).

I consider this test a success, and the lower noise in CHARD Y with the PRCL offset on (left, second plot down) is evident.

The PRCL offset is back in the guardian in LOWNOISE_LENGTH_CONTROL and SDFed for observe. I SDFed the new HAM1 feedforward settings in both safe and observe.

State of H1: Observing at 155Mpc

H1 returned to observing at 18:34 UTC after relocking this morning, damping violins for about 90 minutes, and taking commissioning time (see previous logs for details on those activities).

Sheila, Vicky, Camilla, Naoki

We tried ADS using ZM5+6 and OMC3MHz Q.  This is a similiar strategy to what Masayuki tried in 64458, but a different implementation.  This worked and made the squeezing worse, so we think that for some reason aligning the OPO to the OMC is not the best for squeezing right now.

We saw that we can dither ZM5+6 with 3 counts out of ADS, which doesn't degreade the squeezing level (see Camilla's second attachment in 80113), but gives us good SNR in the 3MHz signal.  We think it would be fine to turn this down by a factor of 3, and still have enough SNR.  We added bandpass and low pass filters to ADS, and adjusted the phases, and closed the loops.  The attached screenshot of the input matrix was used with an ASC_MASTER gain of 1, these loops converged slowly over a few minutes and did a good job of maximizing the RF3MHz, as shown in the next two attachments.

We tested this first with anti-squeezing, where it seemed to keep the level of anti-squeezing high.  Then we tried it with squeezing with the PSAMs settings from the OMC test (see Camilla's alog), here the ADS matimized the RF3Q, but it added scatter at low frequency andmade the high frequency worse.  We turned the ADS off to run the sqz angle optimization script (sets SQZ angle according to 300 Hz sqz blrms), then engaged the ADS again, still the squeezing was worse than what the scan alignment script had done. 

After Camilla reverted the PSAMs to the settings we've been using for observing recently, we tried ADS again, which again maximized RF3 but made squeezing worse.  We moved the RF3 demod phase by about 20degrees after the alignment shift to reoptimize the squeezing, (the alignment has a strong impact on that demod phase), but the squeezing was still 1.7 dB worse than what Camilla found with manual alignment. Vicky's screenshots show the impact of running this ADS and them optimizing the sqz angle on squeezing and RF3 MHz here, and a comparison of the ADS and AS42 signals here. 

AS Oli and I found we were not using the same bias setting for all the quads (ITMY around half bias) and we've now ran the charge measurements since the vent, I edited RUN_ESD_EXC.py as detailed in 79672 and reloaded all 4 ESD_EXC_{QUAD} guardians.

Camilla, Vicky, Sheila, Naoki. 

We tried three PSAMs settings: 5.5V/-0.8V (original), 8.8V/-0.8V (April values), 3.1V/-0.8V (close to best in OMC scan). The original was best (-5dB at high frequency and -3dB at 300Hz) we we reverted to that. 

• Starting at 5.5V/-0.8V, SQZ was already good here, over 5dB at 2kHz. Updated ref 18, ref 20 in camilla.compton/Desktop/16Sept_PSAMS.yaml. 
• Tried April ZM4 PSAMs value 8.8V/-0.8V, left ZM5 value as it was very close already (had 8.8V/-0.67V in April). Ran scan sqz alignment and sqz angle. SQZ wasn't bad here but not as good as starting values. Updated ref 21, 22.
• Then tried closer to ZM4 PSAMs values found in OMC scan 80010: had found we can't go all the was to 0V offset on ZM4 as we get scatter around 100-300Hz. Used 3.1V/-0.8V. Ran scan sqz alignment and sqz angle. Took ref 23 (ASC dithers on) and ref 24 (ASC dithers off), can see no difference with dithers on vs off, plot. 
• In these settings we turned on the ASC that Sheila/Vicky are testing, it started to make SQZ better and then we saw some scatter < 100Hz and SQZ became worse. Maybe the scatter was effecting the ASC.  
• Took no SQZ time: 17:38:00UTC to 17:49:00UTC. Ref 19. 
• Reverted PSAMs and alignment to starting settings. As SQZ was best at high and low frequencies with these settings. DTT plot of all references attached. 

FAMIS 31051

No major events of note this week, although it looks to me like maybe the rise in PMC reflected power has slowed down? Hard to tell exactly, but that would certainly be interesting if true.

Noting observation of Operator team: high state locklooses seem to ring up violins.

This morning at 1410522546 we lost lock from an EQ while at POWER_10W. Since then the violins have been rung up. The IFO has been in OMC_WHITENING damping violins for over an hour, so this does effect observation time.

Looking at the SUS outputs at the lockloss time, it seems there is high counts on the MASTER_OUT channels, mainly in ETMY and ITMs, for the 2.5 seconds after the lockloss, plot attached. Unsure if this is feedback, glitching or active damping. Tagging ISC/SUS. Is this excepted?

Mon Sep 16 08:12:05 2024 INFO: Fill completed in 12min 1secs

Gerardo confirmed a good fill curbside.

TITLE: 09/16 Day Shift: 1430-2330 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Lock Acquisition
OUTGOING OPERATOR: Tony
CURRENT ENVIRONMENT:
    SEI_ENV state: CALM
    Wind: 14mph Gusts, 10mph 3min avg
    Primary useism: 0.04 μm/s
    Secondary useism: 0.09 μm/s
QUICK SUMMARY: H1 lost lock early this morning at 11:01 UTC from a non-obvious cause, then while relocking, a M6.3 EQ from the Northern Mariana Islands caused a lockloss while powering up and kept H1 down for a while. Currently have relocked up to OMC_WHITENING and have been damping violins for about 20 minutes. Commissioning planned to start at 15:30 UTC.

• Wind and microseism bands are low (despite several recent quakes)
• All other systems nominal

TITLE: 09/16 Eve Shift: 2330-0500 UTC (1630-2200 PST), all times posted in UTC
STATE of H1: Observing at 152Mpc
INCOMING OPERATOR: Tony
SHIFT SUMMARY: Currently observing at 156Mpc and have been locked for 1.5 hours. The huge earthquake kept us down for most of my shift, but we were finally able to get back up. The earthquake tripped almost everything, and the IMs and PR2 had become shifted so much that we weren't getting any flashes on the X or Y arms in IR during initial alignment. With Camilla's help, we were able to get INPUT_ALIGN for XARM to run by watching the driftmon trends for those optics and using the optic align channels to adjust their pointing back to where they had been before the earthquake. After that, the rest of initial alignment went by quickly and then relocking was smooth.
LOG:

23:00UTC Unlocked and waiting for ground to stop moving from lockloss-causing earthquake
00:00 Untripped suspensions(MC2, MC3, SRM, IM2, OFI, TMSX), HEPI(HAM1), and ISI(all except HAM6) that had tripped
00:36 Ground finally moving less, started an initial alignment
    - INPUT_ALIGN - no light from XARM IR
    - Tried INPUT_ALIGN for YARM - still no luck
    - We had to trend PR2 and IM1/2/3/4 driftmon and adjust OPTICALIGN to change pointing to what it was before the earthquake
02:26 initial alignment done, relocking
03:25 NOMINAL_LOW_NOISE
03:27 Observing