WP 12384
Power supply that provides ±18V to SUS Rack SUS-C6 (ITMY, ITMX, BS) was replaced. Fan bearings was starting to fail, causing loud grinding sound. Coordinated work with control room as this required powering off the the SUS Watchdog chassis.
F. Clara, J. Figueroa
WP 12372
The h1seih16 IO chassis was upgraded with new hardware in preparation for the HAM1 ISI installation:
The Adnaco in slot A2 was replaced. Timing issues reported in May 2023, alog 70010. The existing ADCs and DAC were moved to the new Adnaco card slot A2. The two new ADC’s were installed in Adnaco card slot A3.
D. Barker, F. Clara, E. Von Reis
Patrick T, Dave B, Jonathan H, Sheila D, TJ S
Summary: Today during maintenance more of the cameras were swapped over to the new camera code on a new server. This caused a lock loss since there was an offset with the new camera code, so the code and servers were swapped back for most cameras.
Some of these swapped cameras are ones we use in locking. At the end of maintenance, I skipped over initial alignment and started to lock the IFO. When we got to the ISC_LOCK state ADS_TO_CAMERAS, we could see the PRG get pulled away over a minute, as well as other signals on the FOMS, before we lost lock. Looking into it, the calulated P & Y, or X & Y depending on which channel you're looking at, channels were different from before the camera swap. The offset that this created moved us away from our alignment setpoints to cause the lock loss. Had I ran an initial alignment we might have run into this soon as we use the green ITM cameras, but we might have lost our alignment references there as well.
While it is possible to find and try to adjust for all of the offsets that the new code introduced, it would be much safer to do this after the IFO achieved full lock and we could transition the IFO off of the cameras, switch to the new code/servers, and then see what the offset is and adjust accordingly. Doing it while not locked risks losing our saved offsets, so we decided to revert the code and server changes for today and plan for another day to implement this.
The leaking pump seal in the chiller 1 pump has been repaired at End Y.
The following electronics were installed in the SEI-C1 rack:
U42: BSC-ISI Interface S1203890
U41: BSC-ISI Interface S1203891
U40: BSC-ISI Interface S1203983
U39: HAM ISI AA Interface S1202074
U38: HEPI AI S1202068
U37: HAM ISI AA Interface S1202075
U36: ISI Coil Driver S1103327
U34: ISI Coil Driver S1103350
U32: Binary In Interface S1203076
Part of the HAM1 ISI installation. Units left powered off. Field cabling arrived onsite today, will be installed next Tuesday.
F. Clara, J. Figueroa, M. Pirello
The LVEA has been swept.
Tue Mar 11 10:10:24 2025 INFO: Fill completed in 10min 21secs
M. Todd, C. Cahillane, S. Dwyer
Yesterday during commissioning, I ran some intensity noise injections. The excitation amplitudes were much too small to start out, so I tuned them as I went along to make sure we had enough coherence in DARM while not driving too hard (trickier at LFs). The injections were 9 bandlimited excitations injected into ISS_SECONDLOOP_EXCITATION, with the injection script located at /ligo/gitcommon/iss_noise_measurements/iss_noise_injection_caller.py. Should these need to be ran again, the individual bands can be uncommented and so the script can run all the bands sequentially by itself now that the excitations are tuned well.
When I inject below 100Hz, there starts to arise some non-linearities in the ISS_SECONDLOOP_RIN channel, which then get injected into DARM. These get more prevelant and higher amplitude as the excitation frequency band goes down. This is shown in Figure 1.
I will analyze the results and comment on this post with the calculated transfer function of intensity noise to darm using this data. The data can be found in the bandlimit-named folders in /ligo/gitcommon/iss_noise_measurements/data/. Most of the injections also have pictures of the coherence and live psds during the injection.
Notes:
The excitations were tuned by looking at the PSD of the DARM error signal while locked, using quick_psd and mapping the shape and amplitude to match it with a slightly higher amplitude. The amplitude will be far too weak as the TF is not known but by tuning the amplitudes by hand while injecting, I saw that the excitation amplitudes need to be about 15 orders of magnitude greater; but the shape of the excitation worked pretty well.
quick_psd H1:LSC-DARM1_IN1_DQ --duration 60 -t1 1422021858 --excitation
M. Todd, S. Reddy, M. Chaturvedi
Mayank, Siva and I worked on alignment yesterday to ensure that the internal alignment is still set. The alignment to the QPD should be the same alignment to the PDs, for instance. With the addition of the iris as an alignment reference we wanted to ensure that this reference still head.
We were able to maximize the QPD and PDs powers simultaneously with the iris installed, confirming everything is internally aligned. However, we are clipping on the iris aperature and need a smaller beamsize through the iris to remove this. Without the iris, our common maximized alignment yielding a QPD power of about .9 mW, while with the iris installed we have about .76 mW.
M. Todd, C. Compton, S. Dwyer
By adding a few lines of code to the SQZ_MANAGER.py, we zero the BLRMS when we are not injecting squeezing which serves only to make the BLRMS plots a little nicer. But basically it switches off the inputs and sets the OFFSET to one so the log calculation is zero-d. Then this effect is removed anytime we open the beam-diverter.
This change was svn commited in addition with some other sqz_manager changes, see alog SQZ Guardian redudancy removal
def zero_blrms():
log(f'Zeroing SQZ BLRMS by adding H1:SQZ-DCPD_SUM/NULL_LP_X_OFFSETs. Turning off input.')
for i in range(6):
ezca.get_LIGOFilter(f'SQZ-DCPD_SUM_LP_{i+1}').switch_off('INPUT')
ezca.get_LIGOFilter(f'SQZ-DCPD_NULL_LP_{i+1}').switch_off('INPUT')
ezca.get_LIGOFilter(f'SQZ-DCPD_SUM_LP_{i+1}').switch_on('OFFSET')
ezca.get_LIGOFilter(f'SQZ-DCPD_NULL_LP_{i+1}').switch_on('OFFSET')
return
def restore_blrms():
log(f'Restoring SQZ BLRMS by zeroing H1:SQZ-DCPD_SUM/NULL_LP_X_OFFSETS. Turning on input.')
for i in range(6):
ezca.get_LIGOFilter(f'SQZ-DCPD_SUM_LP_{i+1}').switch_off('OFFSET')
ezca.get_LIGOFilter(f'SQZ-DCPD_NULL_LP_{i+1}').switch_off('OFFSET')
ezca.get_LIGOFilter(f'SQZ-DCPD_SUM_LP_{i+1}').switch_on('INPUT')
ezca.get_LIGOFilter(f'SQZ-DCPD_NULL_LP_{i+1}').switch_on('INPUT')
return
M. Todd, C. Compton, S. Dwyer
At almost every state before BEAMDIV_OPEN_FDS, there was a turn_off_sqz() call, which contains some redudancies when jumping to these states.
We removed these calls (except in Down) and added them to the respective checkers for each state. (LOCK_SHG_CHECKER, LOCK_OPO_CHECKER, ETC...).
This should allow the jump between no injected squeezing states without having to call the turn_off_sqz() each time unless something unlocks.
I also added some changes to the blrms in SQZ_MANAGER.py, see alog Zeroing SQZ BLRMS during no squeezing
Changes were commited to svn with
Aubrey, Camilla
We plumb-bob marked the locations of ISCT1 and IOT2, labeled "03/25" with black pen and added labels of the heights at each corner. Example photos attached.
We removed the BSC1 temperature sensor to run some testing in the lab. Will reinstall next week.
After testing in the lab, the sensors are working as designed, outputs are clean. We reinstalled the BSC1 temperature sensor but left it floating (not attached to BSC1). The BSC3 sensor we isolated from BSC3 with a thermal pad, and the power supply was isolated from the pier it is resting on. This is an effort to remove ground loops on these systems. Will revisit next week.
M. Pirello, F. Clara
After review of the data over the week, we saw a marked improvement in temprature information so we reapplied the BSC1 sensor to the chamber along with a thermal pad to maintain electrical ground isolation. We also isolated the power box for both supplies.
M. Pirello, F. Clara, D. Barker
J. Kissel Today Dave installed all the simulink front-end code infrastructure that Oli and I built for PM1 (see LHO:83214), Oli created a generic MEDM macro for PM1 and attached a call to that file with the generic HTTS MEDM screen to the sitemap yesteday. That meant I had everything in place for me to completely fill out the PM1 infrastructure: - Populated OSEM2EUL, SENSALIGN, and EUL2OSEM matrices with generic HTTS values - Populated OSEMINF filter banks with standard OSEM calibration filters and turned them ON with a gain of 1.0 for now - Populated the DAMP filter with standard (recently improved) HTTS damping filters - Populated the COILOUTF filter bank with HAM-A coil driver frequency response compensation, and turned the filters on with magnet polarity compensating gains of UL LL UR LR = +1, -1, -1, +1' - Populated and turned on the RMS filtering to support the watchdog trigger signals, and set the threshold to 150 [urad_RMS] as is the case for other HTTS - Turned on the on-diagonal elements of the DRIVEALIGN matrix - Set the calibration gain of the OPTICALIGN alignment offsets to 1.0, which is not the right number, but standard for HTTS. Turn the offset ON. Then monitored and accepted all the settings in the h1sushtts_safe.snap, expect the OPTICALIGN offsets. The committed the safe.snap and filter file to the userapps repo. All we need now is PM1 itself!
Expanding on the digital setup of the coil driver signal chain:
- Populated the COILOUTF filter bank with HAM-A coil driver frequency response compensation, and turned the filters on with magnet polarity compensating gains of UL LL UR LR = +1, -1, -1, +1'
- I copied the COILOUTF frequency response from RM1, which has
FM1 LPM1 zpk([52.32;50.77],[0.5;3174],1,"n")
FM6 AntiLPM1 zpk([0.5;3174],[52.32;50.77],1,"n")
- I set the H1:SUS-PM1_BIO_M1_STATEREQ to 2.0 to ensure the response of the HAM-A driver's low-pass (which is always jumpered to ON) is correctly compensated with only FM6 ON via "caget" on the command line.
J. Kissel ECR E1700228 WP 12370 I've executed the PR3 Optical Lever QPD AA Cable move from SUS-C4 U11 D9 Port 7 to SUS-C4 U32 D9 Port 8 described in more detail a few days ago (LHO:83168) in order to make room for the incoming PM1 (per ). See LHO:83168 for "before" pictures; I attach "after" pictures here: - 2025-03-11_SUS-C4_PR3OplevMove_U11_AAChassis_After_1 shows that D9 port 7 and 8 of U11 AA chassis are now vacant, - 2025-03-11_SUS-C4_PR3OplevMove_U11_AAChassis_After_2.jpg shows that this AA chassis is serial number S1202339. - 2025-03-11_SUS-C4_PR3OplevMove_U32_AAChassis_After_1.jpg shows the big-picture scene around U32 AA chassis, - 2025-03-11_SUS-C4_PR3OplevMove_U32_AAChassis_After_2.jpg shows the cable, "H1:OP LEV_PR3_AA" or "H1:SUS-HAM2_88" specifically, connected into to U32 AA chassis D9 port 8, the last "IN29-31," spigot of this AA chassis that supports sush2a's ADC1. - 2025-03-11_SUS-C4_PR3OplevMove_U32_AAChassis_After_3.jpg shows that this U32 AA chassis is serial number S1202340
Proof that (after we restored the alignment offsets at the M1 stage) PR3 optical gross function has returned. From the trends alone, I see that - the pitch signal is a bit noisier, maybe 0.1 [urad] more RMS. - the yaw signal is drifting slowly at a super small slow 0.02 [urad/minute]. The total SUM of the QPD segments have returned to the identical value tho. Will gather more data, e.g. ASD, to confirm if, and at what frequency, the performance is worse in pitch. Will wait patiently in yaw to see if the trend is something interesting or some transient that doesn't matter. I suspect that this change in character won't matter at all. Recall we DO NOT use the PR3 optical lever for any controls, only for monitoring and driven characterization.
Here's a look at the amplitude spectral density of the PITCH and YAW signals before and after the change.
In short: No concern -- the optical lever performance is equivalent as before
Also -- hidden beneath the comparison of
"read out by U11 AA chassis, ADC0 of sush2b, then shipped over to sush2a via IPC to be processed by PR3 model"
vs.
"read out by U32 AA chassis, ADC1 of sush2a, directly processed by PR3 model"
is that the "after" time period is during maintenance day when site-wide sensor correction is turned OFF.
So, the only substantial change in performance (and the increase in RMS I mentioned in the above LHO:83290) is in PITCH but it's because sensor correction is now off, vs. the before data both in the trends and the reference traces here where it was on.
(Good job sensor correction!)
Also in pitch, there's a bit of broadband increase in noise between 5 and 20 Hz, but this may be where the optical lever QPD is ADC noise limited. But also, a slight increase in noise doesn't really matter -- because the optical lever is much noisier compared to the real motion of the suspension. Even during driven measurements, we struggle to get coherence in this region.
There're some minor improvements in character of sharp features in both pitch and yaw above 10 Hz.
Attached are two examples where it seems that ALS losses lock after the ESD linearization hits its saturating limit, there are several more examples like this.
With the linearization on, we measured the transfer function from drivealign L out to LL master out to be -2.3. Taking into account the gain of 0.25 in the eul2esd matrix, we would need to add a gain of -9.2 in the drivealign matrix to try locking ALS without the linearization.
I've added in lscparams use_ESD_linearization, which is set to True right now to keep things the same as they currently are. I've added an if statement for this in the ALS_DIFF guardian that will set the ETMX_L3_DRIVEALIGN gain to -9.2 if it is set to False.
The linearization used to be turned on in ISC_LOCK's PREP_FOR_LOCKING state, but TJ commented several things out of this state that were redundant with things that SDF would take care of when safe.snaps get reverted. Since we want to use a flag to determine how this is set, I've put it back into PREP_FOR_LOCKING that checks the flag in lscparams.
At the EY station the compressor is being replaced - after the one at EX is done. In this aLog, in the comments, the progress of this operation is tracked continuously, until the 1st startup by the supplier, Rogers Machinery. Another important consideration here, is that the purge line at EY needs to be replaced (based on an FTIR test - see DCC LIGO-E2300222-v2. As it can be seen, the level of contamination reaches even the 10 ug/cm2 value). This operation will be done after the April-May vent, so the EY station will be ready to be vented after O4. 02-25 (maintenance Tuesday): the old compressor was pulled out (it is temporarily stored in the EY receiving area). The beginning of the purge and TMDS lines with the associated brackets and unistruts were taken off. The new compressor unit and dryer skid were anchored in the mechanical room. Here it is important to mention that the orientation of the inlet was brought closer to the purge line inlet into the VEA, so the overall length of the associated circulation lines will be much shorter. Next is the electrical and pneumatic installation, which will be completed in the next 1-2 weeks.
The filter tree was installed and supports anchored to the slab. Ken also reports that electrical installation is complete. Connection to the purge air header is awaiting CF fittings from the supplier. However, startup testing can continue prior to header connection.
The 1st startup of the compressor was carried out by Rogers Machinery on March 18th, during maintenance hours.
To get in Observing I had to accept some SDF diffs for SQZ, and PCALY. There was also still a PEM CS excitation point open as well. There was a notification about PCALY OFS servo malfunction so I looked at it and it was railed at -7.83, so I toggled it off and back on and it brought it back to a good value. I also did not receive a call, a voicemail just appeared.
09:21 UTC observing
H1:SQZ-LO_SERVO_IN1GAIN was left at -15 by accident, reverted to -12 and saved in sdf.
DriptaB, FranciscoL
SDF diffs for PCALY were incorrect. The timing of these changes match the h1iscey reboot done the same day (82902). Today around 19:00 UTC (almost three weeks later), we used EPICS values from the Pcal calibration update done in September (80220) to revert changes. Saved changes in OBSERVE and SAFE.