REMOVE SEARCH FILTER
SEARCH AGAIN
Search criteria
Section: X1
Task: SUS
J. Kissel, O. Patane, F. Clara ECR E2400330 Calling this out explicitly: We have changed the OSEM PD satellite amplifiers on H1SUSPRM, H1SUSPR3, H1SUSBS, H1SUSSR3, and H1SUSSRM top masses; see LHO:85463 We chose to implement ECR E2400330 by modifying spare chassis ahead of time, and installing those modified spares in place of the old chassis (which will become some other suspensions' "new" amps next week). Though the ECR only changes the whitening stage frequency response. However, because the old vs. new chasses have different set of other overall transimpedance gain determining components, the read-back for the OSEM PDs will likely change slightly. Thus, the OSEMs' recast as EULER basis signals will also change slightly, *looking* like an alignment change, even though the alignment of the physical suspension will NOT have changed. This won't be in any consistent direction, and the transimpedance gain is determined by components that have value at any value within the components' tolerance. I attach two examples, H1SUSPR3 and H1SUSBS, of the levels we're talking about -- In the OSEM basis, it's 1-3 [urad], and same in the EULER basis. For the beam splitter, a physical change in alignment of that magnitude would be significant, hence me bringing it up explicitly. So, the new normal for the following suspension alignment starts on 2025-07-01 12:30 UTC: H1SUSPRM H1SUSPR3 H1SUSBS H1SUSSR3 H1SUSSRM We'll definitely have to re-run initial alignment after today's maintenance day, given that (unrelated) - we rebooted the entire electronics racks at EY to replace failing power supplies, - we rebooted the seih23 - we adjusted the green camera alignment
This morning, while waiting for Maintenance, noticed that after the In-Lock SUS Measurement, we did not "automatically" return to Observing (which would only be a few min due imminent Maintenance). Turns out there was an ITMx SDF Diff for (H1:SUS-ITMX_L3_LOCK_L_TRAMP, see attached).
Since it was starting to get hectic in here leading up to Maintenance, I did not do anything about this SDF and kept H1 out of Observing.
Ivey and Edgard,
We just finshed a fit of the Yaw-to-Yaw transfer functions for the OSEM estimator using the measurements that Oli took for SR3 last Tuesday [see LHO: 85288].
The fits were added to the Sus SVN and live inside '~/SusSVN/sus/trunk/HLTS/Common/FilterDesign/Estimator/fits_H1SR3_2025-06-30.mat' . They are already calibrated to work on the filter banks for the estimator and can be installed using 'make_SR3_yaw_model.m', which lives in the same folder [for reference, see LHO: 84041, where Oli got the fits running for a test].
Attached below are two pictures of the fits we made for the estimator.
The first attachment shows the Suspoint Y to M1 DAMP Y fit. We made sure to fit the asymptotic behavior as well as we could, which ends up being 0.95x10^{-3} um/nm (5% lower than expected from the OSEM calibration). The zpk for this fit is
'zpk([-0.024+20.407i,-0.024-20.407i,-0.044+11.493i,-0.044-11.493i,0,0],[-0.067+21.278i,-0.067-21.278i,-0.095+14.443i,-0.095-14.443i,-0.07+6.405i,-0.07-6.405i],-0.001)'
The second attachment shows the M1 drive Y to M1 DAMP Y fit. We kept the same poles that we had for the other fit, but manually fit the zeros and gain to make a good match. The zpk for this fit is
'zpk([-0.051+8.326i,-0.051-8.326i,-0.011+19.259i,-0.011-19.259i],[-0.067+21.278i,-0.067-21.278i,-0.095+14.443i,-0.095-14.443i,-0.07+6.405i,-0.07-6.405i],12.096)'
Hopefully Oli and co. will have time to test this soon!
The new filters have been loaded in. Here are the matlab plots for the fits for SUSPOINT_Y_2GAP and for EST_MODL_DRV_Y_2GAP.
Famis 28411 Weekly In-Lock SUS Charge Measurement.
This command is very useful to determine if the SUS charge measurements ran in the last week:
ls /opt/rtcds/userapps/release/sus/common/scripts/quad/InLockChargeMeasurements/rec_LHO -lt | head -n 6
Coherence for bias_drive_bias_off is 0.06426009151210332, which is below the threshold of 0.1. Skipping this measurement
Cannot calculate beta/beta2 because some measurements failed or have insufficient coherence!
Cannot calculate alpha/gamma because some measurements failed or have insufficient coherence!
Something went wrong with analysis, skipping ITMX_13_Hz_1434811847
There were some light end station VAC pump checks/disassemblies but they didn't seem to affect the measurements, the error bars are much better/smaller than the last time when it was windy out.
ETMY's charge is high (>50V) on half of the quadrants, it appears stable if we discount the previous bad measurement.
ETMX's charge is hovering within +/-10V of 50V except for LR_P, it also appears stable ignoring the previous measurement.
Ibrahim, Rahul
The first round of B&K test results for BBSS & HRTS were posted in LHO alog 84654 . Now were are presenting the second round of test results after making the following improvements on BBSS - (a) added four side dampers (D1101299), two on each side, (b) two lower structure Y-brace strut - D1900589. Please see figure (IMG_2926) for reference. We have also removed the four optical posts which were earlier attached to the HRTS. Finally we attached four Vibration Absorbers (D1002424) to BBSS.
The B&K test results are attached below as a pdf document. We have taken 9 measurements with different boundary conditions, each of which is explained below. For each case the tri-axis accelerometer was mounted on the BBSS frame (marked as position P1 or P2 here) - X axis is along the longitudinal side of the BBSS, Y axis is the vertical and Z is transverse. For HRTS, it's shown in page 9 of the pdf document.
Test 1a (see page 2): case - BBSS (without HRTS) and no side dampers or Y-brace attached to BBSS, Accelerometer position P1.
Test 1b (see page 3): case - BBSS & HRTS and no side dampers or Y-brace attached to BBSS, Accelerometer position P1.
Next ,side dampers and Y-brace attached.
Test 2a (see page 5): case - BBSS & HRTS with side dampers and Y-brace attached to BBSS (No Vibration Absorbers), Accelerometer position P1. Hammer hits on the center of the structure.
Test 2b (see page 6): case - BBSS & HRTS with side dampers and Y-brace attached to BBSS (No Vibration Absorbers), Accelerometer position P2. Hammer hits on the center of the structure.
Test 3 (see page 7): case - BBSS & HRTS with side dampers and Y-brace attached to BBSS (No Vibration Absorbers), Accelerometer position P1. Hammer hits on the side of the structure (left or right).
Test 4 (see page 8): case - BBSS & HRTS with side dampers and Y-brace attached to BBSS (No Vibration Absorbers), Accelerometer position P2. Hammer hits on the side of the structure (left or right).
Test 5 (see page 9): case - BBSS & HRTS with side dampers and Y-brace attached to BBSS (No Vibration Absorbers), Accelerometer attached to HRTS. Hammer hits on HRTS.
Next ,side dampers Y-brace and Vibration Absorbers attached.
Test 6a (see page 11): case - BBSS & HRTS with side dampers, Y-brace attached to BBSS and Vibration Absorbers, Accelerometer position P1. Hammer hits on the center of the structure (X axis or longitudinal direction).
Test 6b (see page 12): case - BBSS & HRTS with side dampers, Y-brace attached to BBSS and Vibration Absorbers, Accelerometer position P1. Hammer hits on the center of the structure (Y axis or vertical direction).
Test 6c (see page 13): case - BBSS & HRTS with side dampers, Y-brace attached to BBSS and Vibration Absorbers, Accelerometer position P1. Hammer hits on the center of the structure (Z axis or transverse direction).
Test 7a (see page 14): case - BBSS & HRTS with side dampers, Y-brace attached to BBSS and Vibration Absorbers, Accelerometer position P1. Hammer hits on the side of the structure (X axis or longitudinal direction).
Test 7b (see page 15): case - BBSS & HRTS with side dampers, Y-brace attached to BBSS and Vibration Absorbers, Accelerometer position P1. Hammer hits on the side of the structure (Y axis or vertical direction).
Test 7c (see page 16): case - BBSS & HRTS with side dampers, Y-brace attached to BBSS and Vibration Absorbers, Accelerometer position P1. Hammer hits on the side of the structure (Z axis or transverse direction).
Test 8a (see page 17): case - BBSS & HRTS with side dampers, Y-brace attached to BBSS and Vibration Absorbers, Accelerometer position P2. Hammer hits on the center of the structure (X axis or longitudinal direction).
Test 8b (see page 18): case - BBSS & HRTS with side dampers, Y-brace attached to BBSS and Vibration Absorbers, Accelerometer position P2. Hammer hits on the center of the structure (Y axis or vertical direction).
Test 8c (see page 19): case - BBSS & HRTS with side dampers, Y-brace attached to BBSS and Vibration Absorbers, Accelerometer position P2. Hammer hits on the center of the structure (Z axis or transverse direction).
Test 9a (see page 20): case - BBSS & HRTS with side dampers, Y-brace attached to BBSS and Vibration Absorbers, Accelerometer position P2. Hammer hits on the side of the structure (X axis or longitudinal direction).
Test 9b (see page 21): case - BBSS & HRTS with side dampers, Y-brace attached to BBSS and Vibration Absorbers, Accelerometer position P2. Hammer hits on the side of the structure (Y axis or vertical direction).
Test 9c (see page 22): case - BBSS & HRTS with side dampers, Y-brace attached to BBSS and Vibration Absorbers, Accelerometer position P2. Hammer hits on the side of the structure (Z axis or transverse direction).
The raw data (.csv files) generated by the B&K software are stored at the following location,
/ligo/home/rahul.kumar/Desktop/scripts/bnk_csv_files
In preparation for the RCG upgrade, we are using the relocking time to reconcile SDF differences in the SAFE file.
Here are some of mine:
I have also determined that the unmonitored channel diffs in the LSC, ASC, and OMC models are guardian controlled values and do not need to be saved.
Not accepting or reverting the h1sqz, h1ascsqzfc, or slow controls cs_sqz sdfs, attached. As these have the same observe and safe files.
Accepted H1:TCS-ETMX_RH_SET{LOWER,UPPER}DRIVECURRENT as ndscope-ing shows they are normally at this value.
Some of these SDFs may have then led to diffs in the OBSERVE state. I have reverted the roll mode tRamp, and accepted the OSC gains in the CAL CS model.
I updated the OPTICALIGN OFFSETs for each suspension that we use those sliders on. I tried using my update_sus_safesnap.py script at first, but even though it's worked one other time in that past, it was not working anytime I tried using it on more than one suspension at a time (it seems like it was only doing one out of each suspension group). I ended up being able to get them all updated anyway eventually. I'm attaching all their sdfs and will be working on fixing the script. Note that a couple of the ETM/TMS values might not match thesetpoint exactly due to the screenshots happening during relocking and after they had moved a bit with the WFS
Before going back to bed, wanted to check violins, and noticed that ITMx MODE13 was ringing up again. I'm guessing the settings RyanC had going were not being used. So, I put in what RyanC had 2hrs ago for the last lock, and within 2min, it quickly damped out the rung up MODE13.
I have NOT made a change/updated lscparams.
NEW Settings:
ITMx MODE13: FM1 + FM4 + FM10 + gain = -0.2
OLD Settings:
ITMx MODE13: FM1 + FM2 + FM4 + FM10 + gain = 0.0
OK, going back to bed. Sleep...we'll see.
TITLE: 06/14 Eve Shift: 2330-0500 UTC (1630-2200 PST), all times posted in UTC
STATE of H1: Lock Aquisition
INCOMING OPERATOR: Corey
SHIFT SUMMARY: A quaternary of issues, environmental (wind and an earthquake), hardware, and software it seems. The new DAMP_BOUNCE_ROLL seems to be killing it everytime it engages so I've commented it out.
LOG:
| Start Time | System | Name | Location | Lazer_Haz | Task | Time End |
|---|---|---|---|---|---|---|
| 15:22 | FAC | LVEA is LASER HAZARD | LVEA | YES | LVEA is LASER HAZARD \u0d26\u0d4d\u0d26\u0d3f(\u239a_\u239a) | 05:18 |
| 00:46 | OMC | Keita | LVEA | Y | Investigate OMC PZT | 00:56 |
I checked the screenshots when I got home and saw that we had been sitting in DAMP_BOUNCE_ROLL for ~20 minutes with the state completed, so I hopped on and requested it to move on to NLN, I'm not sure why H1_MANAGER wasn't moving it on as the REQUEST was set to NLN as it should have been.
ITMX13 decided it didn't want to damp again, so I had to find some new settings. FM1 + FM4 + FM10 G = -0.2 seems to be working. I've set its gain to zero in lscparams in the meantime and reloaded the node.
Kiet and Sheila,
Following up on the investigation posted in aLOG 84136, we examined the impact of higher-order violin mode harmonics on the contamination region.
We found that subtracting the violin peaks near 1000 Hz (1st harmonic) from those near 1500 Hz (2nd harmonic) results in frequency differences that align with many of the narrow lines observed in the contamination region around 500 Hz.
Violin peaks that we used (using O4a+b run average spectra)
F_n1 = {1008.69472,1008.81764, 1007.99944,1005.10319,1005.40083} Hz
F_n2 = {1472.77958,1466.18903,1465.59417,1468.58861, 1465.02333, 1486.36153, 1485.76708} Hz
Out of the 35 possible difference pairs (one from each set), 27 matched known lines in the contamination region to within 1/1800 Hz (~0.56 mHz)—most within 0.1 mHz. Considering that each region actually contains >30 peaks, the number of matching pairs likely increases significantly, helping explain the dense forest of lines in the comtaimination region.
Next steps:
The Fscan run average data are available here (interactive plots):
Fundamental region (500 Hz):
1st harmonic region (1000 Hz):
2nd harmonic region (1500 Hz):
Adding plot comparing the PSDs before and after getting rid of the peaks that can be indentified by this method.
TITLE: 06/13 Eve Shift: 2330-0500 UTC (1630-2200 PST), all times posted in UTC
STATE of H1: Lock Acquisition
OUTGOING OPERATOR: Ryan S
CURRENT ENVIRONMENT:
SEI_ENV state: CALM
Wind: 17mph Gusts, 11mph 3min avg
Primary useism: 0.04 μm/s
Secondary useism: 0.12 μm/s
QUICK SUMMARY:
We've lost lock at POWER_10Ws twice in a row, within a 5 seconds of entering the state. I'm worried of how rung up the violins will be now, as they looked large right before the 2nd lockloss. I'm going to stop at CHECK_VIOLINS on my way up now. Both locklosses tag ADS_EXCURSION
Received phone call at 1:20amPDT.
Saw that H1 was at NLN, and ready to go to Observing, but could not due to SDF Diffs for LSC & SUSETMY (see attached screenshot):
1) LSC
I was not familiar with these channels, so I went through the exercise of trying to find their medm, but for the life of me I could not get there! The closest I got was LSC Overview / IMC-MCL Filter Bank, but they were not on that medm. (probably spent 30min looking everywhere and in between with no luck). Looked at these channels in ndscope & these channels were at their nominals for the last lock. Also looked in the alog, and only saw SDF entries for them from 2019 & 2020. Ultimately, I just decided to do a REVERT (and luckily, H1 did not lose lock).
2) SUSETMY
Then H1 automatically went back to Observe.
Maybe Guardian, for some reason took these channels to these settings? At any rate, going to try to go back to sleep since it has been an hour already (hopefully this does not happen for the next lock!).
These MCL trigger thresholds come from the IMC_LOCK Guardian and are set in the 'DOWN' and 'MOVE_TO_OFFLINE' states.
In 'DOWN', the trigger ON and trigger OFF thresholds are set at 1300 and 200, respectively, for the IMC to prepare to lock as seen in the setpoints from Corey's screenshot.
In 'MOVE_TO_OFFLINE', the trigger ON and trigger OFF thresholds are set at 100 and 90, respectively (for <4W input), as seen in the EPICS values from Corey's screenshot.
So, it would seem that after the lower thresholds were set when taking the IMC offline sometime recently, they were incorrectly accepted in SDF. I'll accept them as the correct values in the OBSERVE.snap table once H1 is back up to low noise, as I expect they'll show up as a difference again.
Lost lock due to the ETM Glitch while commissioning.
2025-06-12 23:39 UTC Back to Observing
Accepted sdfs for SUSPROC (filter for Roll modes) and for LSC (IMC-MCL_FM_TRIG thresholds) to get into Observing. Control room at the time didn't know who changed the MCL thresholds, so I just accepted them.
TITLE: 06/12 Day Shift: 1430-2330 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Observing at 144Mpc
OUTGOING OPERATOR: Ibrahim
CURRENT ENVIRONMENT:
SEI_ENV state: CALM
Wind: 6mph Gusts, 4mph 3min avg
Primary useism: 0.01 μm/s
Secondary useism: 0.11 μm/s
QUICK SUMMARY:
H1 is still locked and has been for 5 hours and 45 minutes.
But the DCPDs are diverging again, Like there is some sort of Roll mode ring up again.
Turns out its the Same Roll mode from yesterday. I applied the same gain from yesterday to the roll mode and it has turned around immediately. I have accepted this as an SDF Diff so we can stay observing.
GRB-Short E573164 @ 1454 UTC stand down
it has been requested of me to run the PSAMS script if we were still locked this morning. Camilla just walked and I her and I will start working on PSAMs when the Stand Down ends.
Dropped out of Observing for Commissioning at 15:51UTC. Optimistic plan for commissioning time today:
Randy, Ibrahim
Today, Randy an I fit checked the BBSS Structure Support Plate (D2500013) and the Lifting Bar Assembly (D1100802) for the BBSS.
Overall, everything fit. See pictures below. Some relevant notes:
Sheila, Elenna, Camilla
Sheila was questioning if something is drifting for us to need an initial alignment after the majority of relocks. Elenna and I noticed that BS PIT moves a lot both while powering up /moving spots and while in NLN. Unsure from the BS alignment inputs plot what's causing this.
This was also happening before the break (see below) but the operators were similarly needing more regular initial alignments before the break too. 1 year ago this was not happening, plot.
These large BS PIT changes began 5th to 6th July 2024 (plot). This is the day shift from the time that the first lock like this happened 5th July 2024 19:26UTC (12:26PT): 78877 at the time we were doing PR2 spot moves. There also was a SUS computer restart 78892 but that appeared to be a day after this started happening.
Sheila, Camilla
This reminded Sheila of when we were heating a SUS in the past and causing the bottom mass to pitch and the ASC to move the top mass to counteract this. Then after lockloss, the bottom mass would slowly go back to it's nominal position.
We do see this on the BS since the PR2 move, see attached (top 2 left plots). See in the green bottom mass oplev trace, when the ASC is turned off on lockloss, the BS moves quickly and then slowly moves again over the next ~30 minutes, do not see simular things on PR3. Attached is the same plot before the PR2 move. And below is a list of other PR2 positions we tried, all the other positions have also made this BS drift. The total PR2 move since the good place is ~3500urad in Yaw.
To avoid this heating and BS drift, we should move back towards a PR2 YAW of closer to 3200. But, we moved PR2 to avoid the spot clipping on the scrapper baffle, e.g. 77631, 80319, 82722, 82641.
I did a bit of alog archaeology to re-remember what we'd done in the past.
To put back the soft turn-off of the BS ASC, I think we need to:
Camilla made the good point that we probably don't want to implement this and then have the first trial of it be overnight. Maybe I'll put it in sometime Monday (when we again have commissioning time), and if we lose lock we can check that it did all the right things.
I've now implemented this soft let-go of BS pit in the ISC_DRMI guardian, and loaded. We'll be able to watch it throughout the day today, including while we're commissioning, so hopefully we'll be able to see it work properly at least once (eg, from a DRMI lockloss).
This 'slow let-go' mode for BS pitch certainly makes the behavior of the BS pit oplev qualitatively different.
In the attached plots, the sharp spike up and decay down behavior around -8 hours is how it had been looking for a long time (as Camilla notes in previous logs in this thread). Around -2 hours we lost lock from NomLowNoise, and while we do get a glitch upon lockloss, the BS doesn't seem to move quite as much, and is mostly flattened out after a shorter amount of time. I also note that this time (-2 hours ago) we didn't need to do an initial alignment (which was done at the -8 hours ago time). However, as Jeff pointed out, we held at DOWN for a while to reconcile SDFs, it's not quite a fair comparison.
We'll see how things go, but there's at least a chance that this will help reduce the need for initial alignments. If needed, we can try to tweak the time constant of the 'soft let-go' to further make the optical lever signal stay more overall flat.
The SUSBS SDF safe.snap file is saved with FM1 off, so that it won't get turned back on in SDF revert. The PREP_PRMI_ASC and PREP_DRMI_ASC states both re-enable FM1 - I may need to go through and ensure it's on for MICH initial alignment.
RyanS, Jenne
We've looked at a couple of times that the BS has been let go of slowly, and it seems like the cooldown time is usually about 17 minutes until it's basically done and at where it wants to be for the next acquisition of DRMI. Attached is one such example.
Alternatively, a day or so ago Tony had to do an initial alignment. On that day, it seemed like the BS took much longer to get to its quiescent spot. I'm not yet sure why the behavior is different sometimes.
Tony is working on taking a look at our average reacquisition time, which will help tell us whether we should make another change to further improve the time it takes to get the BS to where it wants to be for acquisition.
TITLE: 06/10 Day Shift: 1430-2330 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Planned Engineering
OUTGOING OPERATOR: Ibrahim
CURRENT ENVIRONMENT:
SEI_ENV state: CALM
Wind: 4mph Gusts, 1mph 3min avg
Primary useism: 0.02 μm/s
Secondary useism: 0.18 μm/s
QUICK SUMMARY:
H1 was in IDLE when I arrived.
I will start trying to lock now.
I've changed the sign of the damping gain for ITMX 13 in lscparams from +0.2 to -0.2 after seeing it damp correctly in 2 lock stretches. The VIOLIN_DAMPING GRD could use a reload to see this change.
I have loaded the violin damping guardian, since the setting RyanC found still works.
Ibrahim, Rahul
Rahul and I installed the BBSS Vibration Absorbers. We then took more B&K measurements and Rahul is analyzing them. Pictures attached.
