TITLE: 04/16 Day Shift: 15:00-23:00 UTC (08:00-16:00 PST), all times posted in UTC
STATE of H1: Commissioning
INCOMING OPERATOR: Oli
SHIFT SUMMARY:

IFO is in NLN and COMISSONING - the squeezer is having lock issues and a team of comissioners, fellows and other staff are in the control room and working on fixing it.

19:29 UTC: Began Locking (No initial alignment)

20:15 UTC: Began Initial Alignment (after 3 IR_COMM based locklosses)

IR COMM Weirdness:

Once we started locking, ALS locked fine but IR_COMM was not found, prompting a troubleshoot of this part. There was extremely noise behavior in the relevant channel (H1:LSC-TR_X_NORM_INMON) where the usually normalized (to 1) values were showing up bizarrely high. (Screenshot 1). After initial alignment, this issue was resolved.

20:36 UTC: Initial Alignment Complete

21:21 UTC: Reached NLN

21:24 UTC: H1 is OBSERVING

21:36 UTC: Dropped out of observing due to squeezer lockloss - a team of commissioners are on the case.

22:55 UTC: Trying to get into OBSERVING without squeezing while we troubleshoot the squeezer.

LOG:

Shiela, Naoki, Rahul, Kar Meng, Terry

Same as yesterday (77188), we are again today having trouble locking the FC. Wind is again constant at 0-20mph. Can get green flashes but no locking, even with FC feedback turned off, VCO locking also fails. 

Rahul changed the M1 coil driver state on FC1 and FC2 from state 1 (usually only used in TFs) to state 2: IFO nominal for other triples. State 2 contains a low pass filter. 

Rahul took FC2 P and L transfer functions, look healthy and same as 66414.

Rahul took FC2 OSEMINF spectrums and checked ther health, as previously had issues with FC1 BOSEMS  (72563). Can see the 0.3 to 0.4Hz peak, Rahul's not worried about it but we could check old data for this peak.

I pulled EX Accelerometer Power Conditoiner S2300070 per WP11813 to investigate a bad channel and the restult was that the input resistor had blown on that channel.  The symptom was that the channel was completely off, no LED activity on the front panel for that channel.  The current draw per channel at 24V is < 63mA, the 10 ohm resistor is rated at 1/4 watt which gives us an upper limit of 160mA current.  It could have been inrush current that blew this resistor as they have only been tested on bench and not with kepkos' higher current rating.  This is part of the low pass filter for these accelerometer channels.  I replaced the 10 ohm 1/4 watt resistor with a 5W resistor.  I will keep an eye on these, if this becomes an issue, we might consider replacing the resistors with higher wattage versions as there is space on the board for it.

Channel Order
CH1 - Cable 7 - AA7 - OPLEV-Y
CH2 - Cable 8 - AA8 - BSC9_X
CH3 - BLK_NL - U2_9 - Manifold1
CH4 - Cable 10 - AA10 - BSC9_Z
CH5 - Cable 11 - AA11 - TableX
CH6 - Cable 12 - AA12 - BSC_Floor
CH7 - Cable 13 - AA13 - Ebay_Floor
CH8 - BLK-NL - U2_11 - Manifold2
CH9 - empty - empty (ready to replace the Meggit single channel device)

Jennie W, Sheila,

We turned off the 9 and 45 MHZ sideband EOMs and unplugged the 118 MHz modulation at the PSL racks. See this alog for how to do this.

We locked the IMC and mis-aligned ITMX.

DC centering loops 3 and 4 were turned on.

Sheila took the OMC lock guardian to PREP OMC scan and turned on the OMC ASC.

We waited for this to converge then turned it off.

We turned input power up to 10W from 2W and then locked the OMC in length manually by using the PZT offset slider to search for a high peak ~ 15mA.

After finding it we turned on the locking with a gain of 24 and the boost and int filters on (we checked the settings we needed in the guardian as we couldn't get the OMC guardian to lock it for us).

Then we turned off the OMC ASC.

We tuned up the OM3 and OMC alignment slightly to maximise the power on OMC-DCPD_SUM_OUTPUT and minimise it on OMC-REFL_A_LF_OUT16.

OM3 was moved down in yaw only from -108 to -117 and OMC was moved down in yaw from 210.5 to 195.5 and down in pitch from 350.4 to 340.4. The final values for the sliders are here.

Quiet time locked after aligning 16:21:03 UTC - 16:24:13 UTC

OMC-REFL_A_LF_OUT16 = 0.652644 mW

OMC-DCPD_SUM_OUTPUT = 15.6162 mA

Quiet time unlocked 16:25:31 UTC -16:27:35 UTC

OMC-REFL_A_LF_OUT16 = 30.106 mW

OMC-DCPD_SUM_OUTPUT = 0.000456763 mA

We took the IMC guardian offline and shuttered the green light going into both arms at the ISC tables, and with ISC_LOCK guardian in idle so it wouldn't keep trying to relock IMC.

Quiet time dark measurement 16:43:38 - 14:46:19 UTC

OMC-REFL_A_LF_OUT16 = -0.0132979 mW

OMC-DCPD_SUM_OUTPUT = -0.00106226 mA

The scan template is saved as /ligo/home/jennifer.wright/Documents/OMC_scan/2024_04_16_OMC_scan.xml

With the references for the time series of the three pertinent channels as:

Ref 0 OMC-DCPD_SUM_OUT_DQ

Ref 1 OMC-PZT2_EXC

Ref 2 OMC-PZT2_MON_DC_OUT_DQ

J. Kissel

EXECUTIVE SUMMARY

After having visited the calibration of the HAUX alignment sliders since 2016 (see LHO:30010), it's time to re-measure and recalculate what these gains should be, as we've lost confidence in their accuracy. 

I've recalibrated the IM1, IM2, IM3, IM4 alignment sliders today, such that one count offset in [pitch, yaw] produces 1 microradian in [pitch, yaw] according to the OSEMs. To correct from the previous incorrect calibration, slider values would have needed to be multiplied by factors of 20 to 30 [urad/"urad"].

METHODS AND RESULTS

In order get something in play quickly, I've used the OSEMs as my absolute angle reference, having been calibrated into microns [um] for years and cast into PITCH and YAW through trusted OSEM2EUL matrices to produce pitch and yaw in microradians [urad]. 

Recall the goal is to calibrate the output of the OPTICALIGN banks, which are nominally in Euler basis DAC counts [DAC ct] such that when you request the slider to move in your desired physical unit (in this case, [urad]) then the output of the bank requests the appropriate amount from the DAC. Thus, we need a gain, H where
    slider offset [urad] * H [DAC ct / urad] = DAC output [DAC ct]        (1)


In short, the method is:
    (i) Set the OPTICALIGN gain to 1.0 so there's no confusion during the measurement.
    (ii) Request the slider offset to be a range of values (I arbitrarily chose [-10000, -5000, -1000, 1000, 5000, 10000]; six data points such that a linear regression had plenty to grab on to)
    (iii) At each requested value, record the OSEM values.
    (iv) Fit a line to a plot of OSEM value vs. slider value, i.e. (slope * slider value + offset). The slope will be in units of [urad / DAC ct].
    (V) Invert the slope to obtain the slider calibration gain in units of [DAC ct / urad].
I used an ipython session interactively to do so for all IMs at the same time via for loops, while the IMC was unlocked and misaligned.

Here're the results in units of [DAC ct / urad] (rounded to the nearest 4th decimal place):
         PIT       YAW
IM1     9.9093    5.3457
IM2    10.1124    5.4868
IM3    12.5623    6.8758
IM4    10.9005    5.6289

Note that the results are not insignificantly different from suspension to suspension, even though every HAUX actuation chain should be the same. So, I've elected to install these suspension specific gains (like we have with other suspensions that have had recent attention), rather than a generic gain for suspension type based on a model of the actuation strength.

The first two pages of 2024-04-16_H1SUSIM_AlignmentSlider_Recalibration_GainFitPlots.pdf shows the plots of data, and their fits. As an aside, because I drove the slider requests programmatically via ipython, it was easy to measure both the pitch and yaw OSEM values during the other DOF's slider changes. As such, I also gathered the amount of cross-coupling between pitch drive and yaw response and vice versa, yaw drive and pitch response, in units of [urad / DAC ct]. This is shown on the last two pages. The good news is that the off-diagonal cross-coupling is an order of magnitude or two less than the expected diagonal coupling (I think auto-y-axis-scaling dataviewer or ndscope sessions have scared us for years). That being said, IM3 is the worst offender.

After I installed the new calibration, I've made sure to set the *actually* [urad] value to reproduce the same [DAC ct] output that had been requested with the previous incorrect ["urad"] values (generated with the incorrect [DAC ct / "urad"] gain, G). The method for doing so is revealed through a quick algebra exercise,
    slider offset [urad] * H [DAC ct / urad] = DAC output [DAC ct]                 (1)
    bad slider offset ["urad"] * G [DAC ct / "urad"] = DAC output' [DAC ct']       (2)

    want
    DAC output [DAC ct] = DAC output' [DAC ct'],

    so
    slider offset [urad] * H [DAC ct / urad] = bad slider offser ["urad"] * G [DAC ct / "urad"]
    
    slider offset [urad] = bad slider offset ["urad"] * G [DAC ct / "urad"] / H [DAC ct / urad]     (3)
or, in words, multiply the old bad offsets by the ratio of (old gain / new gain) to get the new well-calibrated offsets.

In addition to calibrating the offsets, I also updated the visual representation of the available range on the MEDM screen. In this case, given that the HAUX are driven with 18-bit DACs, then each OSEM can drive 2^17 - counts. The EUL2OSEM matrix elements for conversion of pitch and yaw to each of the four OSEMs is +/-8.594 [um / urad], so that means that a Euler basis pitch and yaw [DAC ct] drive cannot exceed 2^17 / 8.594 = 15251 [Eul DAC ct]. After dividing by the above calibration for each, that takes the slider limits to (roughly, taking the lowest range -- IM3 -- as the limiter) +/- 1200 [urad] for pitch and +/- 2200 [urad] for yaw.

2024-04-16_H1SUSIM_AlignmentSlider_Recalibation_OPTICALIGN_Screens_after_correctunits.png shows the final product after all of these changes,
    - the new slider gain values,
    - the new slider offset values to reproduce the same DAC output, and
    - the updated range of values.

Operators be aware: the amount of nudging you need to do on IM4 during initial alignment will need to change as a result of this re-calibration. Using the same math as Eq. (3) above, [1, 10, 100, 1000] "urad" nudges now are actually, roughly [0.05, 0.5, 5. , 50] "urad" nudges.

2024-04-16_H1SUSIM_AlignmentSlider_Recalibration_Notes.txt are my very rough notes from the morning's work, including all mistakes, as well as ipython code snippets to take actions, store information, and make plots. Could be cleaner for future users, but alas.

Swept the LVEA at the end of maintenance. All of the usual checks on  T1500386 were done, the only thing I noticed was that there were some cables plugged into the SQZT0 table that were not connect to anything else. These are for the hymodyne delta DC, PD1 DC, and PD2 DC according to their labels.

The items mentioned from last week's sweep (alog77058) are still there - pem setups, FARO, etc. as expected for the near future.

IFO is in IDLE for TUESDAY MAINTENANCE

Maintenance work is wrapping up, Camilla is detransitioning our LVEA Hazard state and we will being locking as soon as maintenance activities end.

New channels have been added to the CDS SDF, and h1cdssdf was restarted on h1ecatmon0. Current values have been accepted and are being monitored.

WP11812

Jamie, Jonathan, Erik, Dave:

The two CAL HASH channels (H1:CAL-CALIB_REPORT_HASH_INT and H1:CAL-CALIB_REPORT_ID_INT) were moved from the h1calcs model, where they were being acquired as single-precision floats, to a new custom EPICS IOC called cal_hash_ioc, where they are acquired as signed 32bit integers.

The h1calcs.mdl model was modified to remove the EPICS-INPUT parts for these channels. The model was then restarted.

The IOC, which was being tested with H3 channels, was modifed and rstarted to serve the H1 channels as integers.

The EDC was modified to add H1EPICS_CALHASH.ini to its master list. This added 5 channels the the DAQ, the two hash channels and three IOC status channels.

The EDC was restarted, followed in short order by a DAQ restart.

Tue Apr 16 10:12:16 2024 INFO: Fill completed in 12min 11secs

Jordan confirmed a good fill curbside. Plot looks strange because the DAQ was being restarted during the fill.

I used the IM4 pico to center the beam on the QPD with 2W into the mode cleaner this morning (screenshot attached). We had some shifts of input alignment during the vent and difficulty recovering (see 76359 76291).  Now our range is 165 and locking seems reliable, so we are resetting the IM4 QPD to zero here so that we can use this as a reference in the future.  LLO tells us that they realign IM3 to this QPD every few months.

This increased the sum of IM4.  Since this sum is used to normalize our PRG channel, this will need a recalibration.

Lately it's been very difficult to fit an efficient SRCL feedforward filter, as reported many times by Camilla et al. (76993). Here I'm trying to figure out why. Spoiler alert: I don't have an answer yet.

The main problem with the SRCL FF filter (see first plot), is that the transfer function to fit has a large phase rotation, that looks basically like a phase advance (the opposite of a delay) of about 2 ms. This is very large, and being an advance, it can't be realized in a precise and simple wasy digitally.

First observation: we can fit a pretty good SRCL FF if we allow for unstable poles, i.e. poles with positive real parts (see second plot) Of course this is not something that can be implemented in the real time system. The fit ends up having a unstable complex pole at about 420 Hz and about 5 Hz. I have no intepretation for the origin of those poles, and they might very well be only a way to reproduce a phase advance (think of the Padé approximation for phase delays).

So the question is: what is the origin of this large phase rotation? It's not seen at LLO, for example see 70548

Second observation: this phase advance appeared after we switched the LSC FF from ETMX (full chain) to ETMY PUM. The third plot compares the MICH and SRCL feedforward to be fit in two cases: an old measurement when the FF was going to ETMX, and a more recent measurement with the FF going to ETMY PUM only. For both MICH and SRCL the orange traces (FF to ETMY) show a phase advanced with respect to the blue traces (FF to ETMX). For some reasons I don't fully understand, this rotation is more problematic for SRCL than for MICH, although fitting MICH has also been more difficult and the MICH FF is relevant at lower frequencies than SRCL, so maybe the phase advanced isn't that problematic.

Looking at the measurement of the MICHFF to DARM and SRCLFF to DARM, one can see that there seems to be an additional phase delay in the FF path through ETMY PUM with respect to the FF path through ETMX full chain. Since this transfer function is at the denominator when computing the ratio SRCLtoDARM/SRCLFFtoDARM that gives use the LSC FF to fit, this seems to explain the additional phase advance we observe.

The ETMY PUM L2 lock filter bank contains a "QPrime" filter module that compensates partially the additional 1/f^2 due to the actuation from L2 instead of L3. This filter however doesn't seem able to explain this additonal phase delay.

I'm now suspicious that there might be something wrong or mistuned in the ETMY L2 drive, maybe a whitening filter missing or not functioning properly or not properly compensated?

It would be worth doing a quick test in the next commissioning time with full IFO locked: inject some white noise on ETMX L2 L and ETMY L2 L and comapre the two transfer functions to DARM. In theory they should be equal, except for a sign difference. If they're not, then there must be something wrong with ETMY, since we're using ETMX L2 to lock without issues.

TITLE: 04/16 Day Shift: 15:00-23:00 UTC (08:00-16:00 PST), all times posted in UTC
STATE of H1: Preventive Maintenance
OUTGOING OPERATOR: Tony
CURRENT ENVIRONMENT:
    SEI_ENV state: CALM
    Wind: 12mph Gusts, 7mph 5min avg
    Primary useism: 0.04 μm/s
    Secondary useism: 0.13 μm/s
QUICK SUMMARY:

IFO was unlocked upon entry - now staying down for Planned Tuesday Maintenance

A lock loss this morning from unknown reasons had the IFO running an initial alignment after it struggled to lock in the main locking. I was alerted after it timed out locking green in initial alignment. By the time I logged in and accidentally restarted green locking, increase flashed had fixed it and it have moved on in the initial alignment sequence. I'll let it finish with the hopes that it will help maintance recover slightly quicker, but not start locking again since maintenance is about to start.

I'm not sure why green was struggling so much this morning, I'll have to dive deeper into it later it. It doesn't normally time out if it can lock this easily.

Workstations were updated and rebooted.  This was an os package update.  Conda packages were not updated.

TITLE: 04/15 Eve Shift: 23:00-07:00 UTC (16:00-00:00 PST), all times posted in UTC
STATE of H1: Observing at 154Mpc
OUTGOING OPERATOR: Ryan C
CURRENT ENVIRONMENT:
    SEI_ENV state: SEISMON_ALERT
    Wind: 10mph Gusts, 5mph 5min avg
    Primary useism: 0.04 μm/s
    Secondary useism: 0.15 μm/s
QUICK SUMMARY:

Nicely Observing H1 handed off by RyanC.  He mentioned, same issue with SRC for alignment and needing to skip it (that's atleast 3x in a row).  He also mentioned a drop out of Observing due to SQZ_FC as observed last night (and tweaks Naoki made for this).  Currently, waiting for a M5.9 S.Korea earthquake to roll through with its R-wave in 10min.