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.

While h1susex is running on RCG5.3.0 I have modified the CDS overview to show this so we don't forget that these models need a special build.

I've used the sliver between the filter-status and the ipc-status to show this.

This morning it seems XARM was having some issues related to the PLL (seen yesterday in alog78660) beatnote. This caused the XARM to keep jumping from unlocked -> increase_flashes -> fault, as seen in the log. After a bit it was able to fix itself and the GREEN_ARMS section of IA finished in about ~30 minutes, the rest of IA went fine and only took 15 minutes. The longer GREEN_ARMS time caused the H1_MANAGER IA timer of 40 minutes to expire and IA got stuck in INIT_ALIGN_FINISHED and SRC_ALIGN_OFFLOADED for ALIGN_IFO.

Vicky, Begum, Camilla: Vicky and Begum noted that the CLF ISS and SQZ laser is glitchy.

Vicky's plot shows CLF ISS glitches started with O4b, attached.

Timeline below shows SQZ laser glitches started May 20th and aren't related to TTFSS swaps. DetChar - Request : Do you see these gltiches in DARM since May 20th?