TITLE: 06/26 Day Shift: 1430-2330 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Lock Acquisition
INCOMING OPERATOR: Tony
SHIFT SUMMARY: Currently relocking and at ENGAGE_SOFT_LOOPS. Two locklosses during my shift, and we had a good amount of trouble messing with ALSX during relocking this second time.

After thislast lockloss, I went to Initial alignment, and while trying to lock green arms I had the same issues with the beatnote frequency and so Sheila and I went to adjust the fiber polarization to get it back to the values that it seems are ideal for ALS-X_FIBR_LOCK_FIBER_POLARIZATIONPERCENT and ALS-X_FIBR_LOCK_FIBER_TRANSRIGHTPOL, the closer we got to the correct values for those two channels, the worse the beatnote would get. It seems like the ideal max splot for the ALSX beatnote is 8.8dB and we started with it around -20dB, but as we adjusted the fiber polarization, the beatnote went down to -30dB. Trying to then adjust the fiber polarization to maximize the beat note sent the two fiber polarizatoin channels the complete opposite direction that we wanted, so we went back and based our movements on those two channels to slightly improve those values, and changed the minimum beatnote value to be -20dB (tagging ops, needs to be accepted in sdf) instead of -10dB as a temporary fix for now to make sure that we don't get stuck in fault again like last night.

LOG:

14:30 Detector unlocked and at FIND_IR
    - Initial alignment had been done by H1 Manager, but it had become stuck at the end at 10:46UTC and hadn't tried relocking again until 13:54UTC, and by that time it seems like the alignment had drifted because it couldn't lock
14:37 We started going through CHECK_MICH_FRINGES so I took us to DOWN and ran another initial alignment
14:52 Initial alignment done, relocking
15:41 NOMINAL_LOW_NOISE
15:47 Observing

16:04  Lockloss
16:29 Initial alignment complete, relocking
17:11 NOMINAL_LOW_NOISE
17:14 Observing

22:04 Lockloss
- Went to Initial alignment, had the same issues with the beatnote frequency and so Sheila and I went to adjust the fiber polarization to get it back to the values that it seems are ideal for ALS-X_FIBR_LOCK_FIBER_POLARIZATIONPERCENT and ALS-X_FIBR_LOCK_FIBER_TRANSRIGHTPOL, the closer we got to the correct values for those two channels, the worse the beatnote would get. It seems like the ideal max spot for the beatnote is 8.8dB and we started with it around -20dB, but as we adjusted the fiber polarization, the beatnote went down to -30dB. Trying to then adjust the fiber polarization to maximize the beat note sent the two fiber polarizatoin channels the complete opposite direction that we wanted, so we went back and based our movements on those two channels to slightly improve those values, and changed the minimum beatnote value to be -20dB instead of -10dB as a temporary fix for now to make sure that we don't get stuck in fault again like last night.

TITLE: 06/26 Eve Shift: 2300-0800 UTC (1600-0100 PST), all times posted in UTC
STATE of H1: Lock Acquisition
OUTGOING OPERATOR: Oli
CURRENT ENVIRONMENT:
    SEI_ENV state: CALM
    Wind: 20mph Gusts, 16mph 5min avg
    Primary useism: 0.03 μm/s
    Secondary useism: 0.06 μm/s
QUICK SUMMARY:

Current SQZ issue is Pump Fiber rej port in HAM7 High, nominal 35E-3, align fiber pol in sqzt0
H1:SQZ-SHG_FIBR_REJECTED_DC_POWER  = 0.312
I understand I should move the Pico motors before Inject Squeezing.
 

In the seiproc model we have some code that produces IFO basis ground motion channels i.e.: XARM_GND=ETMX_X_GND - ITMX_X_GND. There's X/Y arm and CARM and DARM channels.  They've in for years, but I'm not sure that much has been done with them. While talking to Neil about some earthquake stuff, I realized we don't have blrms calculated for these IFO dof ground channels, something that might be really useful for earthquake or microseism studies.So, I've filed ECR E2400233, channels went in at LHO yesterday. I'll let Huyen know, but the seiproc model parts aren't common between the sites.

Built a second SHG with the PPKTP crystal from MIT, did a measurement on the conversion efficiency and fit for the single pass nonlinear conversion efficiency E_nl = 0.0055W^-1. The single pass measurement of the PPKTP crystal give a nonlinearity d_eff = 5.41 pm/V. Generally d_eff of PPKTP is quoted around 9.3pm/V (Table 5.1 of Georgia's thesis)

Measurement of the phase matching curve with input power of 60 mW shows a dip around 35 celcius. The temperature controller reads in kOhm and is converted into celcius via the Steinhart-Hart equation:

A1 = 0.003354016
B1 = 0.0002569850
C1 = 2.620131e-6
D1 = 6.383091e-8

R25 = 10000
R = R_meas / R25
T = ( 1 / (A1 + (B1 * np.log(R)) + (C1 * np.log(R)**2) + (D1 * np.log(R)**3) ) ) - 273.15

Phase matching curve is plotted by using Equation 3.14, 3.20 and Table 3.2 from Sheila's thesis. I have fitted the sinc curve with T₀ = 34.9 and i_max = 11.79 , 18.00 and 32.00.

Lockloss @ 06/26 22:04UTC - most likely from wind

Last night the ALS_XARM node was stuck in a loop of tryin to go to increase flashes but Beckhoff was reporting some errors (PDH, PLL, others) so the node would jump to fault state (see Oli and Ryan C's alog78669). There were two issues I found: the unstall decorator that re-requested the node to jump out of FAULT only looks for Beckhoff error messages which might be temporarily not present, and the FAULT state has a jump transition in it to allow us to go to UNLOCKED. I have three possible solutions for this:

1. Line 208 of ALS_ARM.py forces a jump transition to UNLOCKED while in the FAULT state if the target state is unlocked. Based off of a comment in the code there, I believe the intent was to allow us to still go to unlocked if ALS is shuttered. This isn't desireable because I can't really see another state that would be the target, so it will always jump out of this FAULT state. Changing this line from looking at the target state to the request state should allow it to stay in fault unless we want it to go to unlocked.
2. Make the unstall node decorator smarter looking at more than just if there are any node notifications. In this case the notifications would only come from Beckhoff error messages, so this isn't good enough at times since the messages can flash by or temporarily go away.
3. Create a state just before Increase_Flashes that does a check of the ALS Beckhoff errors and will wait here until they are cleared. I worry that this will not be a clear enough indicator that we are in an error state though. It also could create a way to get stuck here and force more user intervention.

For now we'll try option #1 and see how that works. If we need to make it more sophisitcated we can test it out. The code with this change has been saved and will be reloaded when we drop out of Observing.

We are Observing at 154Mpc and have been Locked for 2.5 hours. Nothing to report.

RCG5.3.0 reads out the FPGA chip temperatures for both the Timing Card and the new LIGO 28AO32 DAC card. These are available as EPICS channels and can be trended in ndscope.

The attached image shows the past 24 hour trend, and where you can find these temperatures on the RCG MEDMs.

Closes FAMIS#27792, last checked 78496

TCSX: Originally at 29.6. Added 300mL to get to 30.1

TCSY: Already at 10.4. Nothing added.

No leak in water cup

Andrei, Sheila

We've observed that upon IFO switching its state to OBSERVING (H1:GRD-IFO_OK), we observe the so-called bounce modes of mirror suspencions at freqeuencies around 27.041 Hz in H1:SQZ-FC_LSC_DOF2 channel. These modes can be present in measurements for over 10 minutes. We have checked the occurances of these events over a few days, which will hopefully help us to determine the exact suspencion responcible for this behavior (Bouncemodes.png, /ligo/home/andrei.danilin/Documents/Oscillations.xml).

TJ, Sheila

The fast shutter guardian runs a check in DRMI on AS_A and AS_B, it checks that the power on those PDs are above and below thresholds, which are set by the 'SYS-MOTION_C_SHUTTER_G_TRIGGER_LOW' and 'SYS-MOTION_C_SHUTTER_G_TRIGGER_HIGH' channels.   This test was passed when we had the pressure spikes, because the beam to those diodes wasn't clipped.

TJ and I have been discussing adding an additional check to try to catch the type of problem we had in our recent pressure spikes, where there was clipping on AS_C.  The table below shows values with DRMI locked, to see if we can detect the problem before fully locking the IFO.  It seems that a check on the power on AS_C would cause false alarms, because of the variablity of DRMI build ups.  A check on the ratio of AS_C to AS_A or AS_B seems more viable, but still would probably risk false alarms.  The difference between the lowest "good" ratio for AS_C/AS_A and the highest bad ratio is only 3.5%, for AS_C/AS_B that difference is only 7%. 

Wed Jun 26 10:09:07 2024 INFO: Fill completed in 9min 3secs

Gerardo confirmed a good fill curbside.

I've written a python program which genenerates a DAC_TEST MEDM. It is accessible from the SITEMAP via the WD pull down (the CDS pull down is full).

WP11928 Install New LIGO-DAC in h1susex

Richard, Marc, Fil, Erik, EJ, Dave:

A new LIGO 28bit DAC card was installed in h1susex. The current 18 and 20 bit DAC drives can be tee'ed to the new DAC via a selection matrix. The first 8 DAC channels are being read back by an ADC in h1iscex, by the h1pemex model.

h1susex was moved from the production RCG 5.1.4 boot server (h1vmboot1) to the new RCG 5.3.0 boot server (h1vmboot0).

h1susauxex was powered down during this install.

The h1iopsusex model was modified to add the new DAC. h1susetmx was modified to drive the new DAC with any combination of the four production DACs it is driving (two are 18bit, two are 20bit).

A DAQ restart was required. Due to a DAQ configuration issue the 0-leg was offline for about an hour.

WP11937 New Cal models

Louis, Joe, Dave:

New h1cal[cs, ex, ey] were installed. A DAQ restart was needed.

WP11944 New Seiproc model

Jim, Dave:

A new h1seiproc model was installed. A DAQ restart was required.

DAQ Restart

Jonathan, Erik, Dave:

As mentioned above this was a messy restart because the new boot server rewrote the DAQ master file to only include the h1susex system. Our brief h1pemmx test yesterday did not pick this up since we did not do a DAQ restart.

The issue was found on the 0-leg, so did not impact the control room while we identified the problem as resolved it. The 1-leg restart went ahead with no issues.

After the DAQ was back up and running, we noticed that FW0 frame write times were sometimes 10-20 seconds longer than FW1's, and sometimes about the same. This situation persisted for about an hour and then resolved itself.

3IFO Dewpoint Sensor for HAM3

Bubba, Fil, Dave:

Fil investigated the HAM3 3IFO dewpoint sensor. It looks like a failed sensor.

Roof Camera

Fil, Marc, Dave:

Fil and Marc went onto the roof and restored the camera which attaches to the viewing platform. This camera is now working again.

h1sush2a DAC high quarter error

Erik, EJ, Dave:

We discovered that all the h1sush2a DACs had been in high-quarter-fifo error since 9th April 2024 (last day of O4 break). This frontend controls MC1, MC3, PRM, PR3.

We restarted the models and the DACs are now good.

See Erik's alog for details.

The Beckhoff timing system is reporting an error at the EX station following the new DAC install yesterday, which required a timing card with an updated firmware version. This error is actually just an informational message acknowlegding the firmware version difference on the timing card attached to the fourth port (port3) of the EX timing fanout.