TITLE: 08/23 Day Shift: 1430-2330 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Corrective Maintenance
INCOMING OPERATOR: Oli
SHIFT SUMMARY:

IFO is in ACQUIRE PRMI and MAINTENANCE

There have been 2 initial alignments (fully auto), many locklosses due to ASC reasons and many more due to wind gust speeds (to the best of our knowledge). We were in NLN for a total of 46 minutes today! Additionally, the LVEA has been swept in prep for observing (alog 79666). The comissioners are gathering a weekend operator task list.

We've had a rough day trying to get locked due to the following reasons:

PI Mode Mania (alog 79665)

PI modes since we have been back are getting rung up right after we enter NLN. While usually the culp[rit is mode 24, mode 31 does sound on verbal too. Camilla and Naoki tried to ring them up to investigate and they were not able to ring up mode 24, implying a potential slight change in the PI modes. We could not get locked to investigate thgis further but we tyhink thart this might be related to the short <1hr 30 mins locks that we are getting.

Wind Speed Story:

Wind gusts have been over 30mph for the last few hours and this has made getting locked extremely difficult with easily over 10 failed lock attempts from ALS (usually Y) to DRMI. While this is annoying, it is also a known impedance.

OMC Trans Camera Conundrum:

The OMC Trans Camera is observed to shake/flicker at an unknown state (we saw it once today and a few times yesterday)/ By the time we were ready to investigate when this flicker occurs, we started having our locking issues. We did rule out camera auto-exposure problems.

Pop 18 Peculiarity (alog 79663) :

Pop 18 is particularly low and we have been moving PRM and SRM in order to maintain DRMI until we can offload. A potential plan is to go fix it in the LVEA (ISCT1) but since we were unable to investgiate while locked, this is going to be delayed to another day given that the issue still persists.

What we want to do once locked:

• Calibration sweeps right as we reach NLN, 1 hour after (mostly thermalized) and if possible
• LSC Feed Forward Tuning
• PI Solution
• Wrangle SDFs

LOG:

We can edit this list as needed. 

We are having trouble locking this afternoon because of the wind, but we have some requests for the operators this weekend if they are able to relock. 

We've changed the nominal locking power to 61W, in the hopes that this might avoid the PI or let us pass through it quickly.

When we first get to NLN, please take the IFO to NLN_CAL_MEAS and run a calibration sweep.  If we stayed locked for ~1.5 hours, please re-run, and if we are ever locked for more than 3 hours please re-run again. 

After the calibration has run, we would like to check the camera set points since we have seen earlier today that they are not optimal and that might be related to our PI problem.  We already updated the offset for PIT1, but we'd like to check the others.   We modified the script from 76695 to engage +20 dB filters in all these servos to speed up the process.   Each DOF should take a little more than 15 minutes.  We'd like these run with the POP beam diverter open, so we can see the impact on POP18 and POP90.  The operators can run this by going to /ligo/gitcommon/labutils/beam_spot_raster and typing python camera_servo_offset_stepper.py 1 -s now  (and once 1 completes, run 2 and 3 if there's time.)

I've added 3 ndscope templates that you can use to watch what these scripts do.  the templates are in userapps/asc/h1/templates/ndscope/move_camera_offsets_{BS, DOF2_ETMX, DOF3_ETMY}.yml  We'd like to see if any of these can increase the arm powers, or POP18.  If there is a better value found, it can be set to the default by updating lscparams.py lines 457 to 465. 

TITLE: 08/23 Eve Shift: 2300-0800 UTC (1600-0100 PST), all times posted in UTC
STATE of H1: Corrective Maintenance
OUTGOING OPERATOR: Ibrahim
CURRENT ENVIRONMENT:
    SEI_ENV state: CALM
    Wind: 26mph Gusts, 22mph 5min avg
    Primary useism: 0.05 μm/s
    Secondary useism: 0.12 μm/s
QUICK SUMMARY:

Currently at ACQUIRE_DRMI_1F. We've been working on locking, but progress has been slow due to high winds. A few minutes ago we were at LOWNOISE_ASC, but lost lock. Max power is currently set in lsc_params as 61W to hopefully bypass the new PI. Continuing locking attempts.

I've often been increasing the COMM offset when I see arm cavity flashes during DRMI acquisition for a few months.  I think based on anecdotal evidence that this helps DRMI lock faster, and it hasn't caused any issue with the CARM handoffs in the times I've done it manually. So Ryan, Elenna and I have just now added this offset into the guardian (ISC_LOCK ARMS_OFF_RESONANCE offset is changed from -100o to -2000). 

At full lock after the ADS has converged, I checked the beam position on POP A. When we do full IFO ASC, POP A is not in-loop, but POP A is the sensor for the PRM in DRMI ASC (PRC1). We've had PRC1 off for the vent recovery. I reset the POP A offsets to center the beam in full lock, and Ryan changed the DRMI guardian to use PRC1 again in DRMI ASC.

The POP A yaw offset changed significantly, which is possibly related to our very low POP18 value since the recovery (Sheila's alog 79663).

Values are SDFed.

Comparing POPAIR B now to the last good lock in July (before the damage), we only have 54% as much power in POP18 in full lock, in DRMI we have 71%.  At full power, the power on POPAIR B is 78% of what it was before the damage, in DRMI we have 86%.  This might indicate we have an alignment problem, which could perhaps contribute to our PI problems.  Other indicators suggest that our alignment is mostly OK: the arm power, PRG, coupled cavity pole, and kappa C all seem to be similar or slightly better than before the vent. 

I tried moving the BS camera pitch offsets, during the thermalization (our locks are short enough that we have to do things during the thermalization we might rather do later.)  This did seem to improve the arm power (more than the thermalization trend), but if anything it made POP18 slightly worse.  Screenshot attached.  We lost lock before being able to try yaw. 

For future reference, the ndscope I used for this is in userapps/asc/h1/templates/ndscope/move_camera_offset/move_camera_offsets_BS.yaml

LVEA was swept. Lights, WAP, paging system all off. Found nothing extra plugged in apart from usual PEM equipment.

There are a few unconnected BNCs connected to the PSL/SQZ racks that aren't being used. Some tools left on HAM5 pier -X+Y pier (didn't remove as in the middle of locking). SQZ bay crane is a few meters off it's parking spot. Farro is now plugged in near SQZ racks. Large clean-room in the +Y bay is plugged in but off (doubt this has changed).Still long extension cord to HAM3 dust monitor.

I am taking another look at what steps in lock acquisition take a very long time. See Georgia's previous alog on this: 76398

I noticed some of the power up steps seem to take longer than they should. I found some timers that are longer than necessary, so I am shortening them.

• Reduced 30 sec timer to 10 sec in "Power 10 W" > this is a timer to wait on ASC boost engagements that have a 1 and 6 second ramp time respectively
• loosened move spots ADS convergence thresholds from 0.6 to 1.2 > I tightened these thresholds by a factor of 10 previously (from 6 to 0.6)
• I combined a few steps of "lownoise ASC": changing the MICH gains with CHARD P, and doing all DHARD P and Y controls in one step reducing a few of the timer waits that were 5 seconds each
• I noticed the AS A yaw offset tRamp is set to 20 seconds in lownoise ASC, but then the step only waits 10 seconds before moving on, so now the tramp is set to 10 seconds
• I increased the Max Power ADS convergence threshold, was 0.001 is now 0.002
• I reduced the thermal waits in Max Power from 30 to 20

Just a note about many of the longer waits and tight convergence thresholds: powering up to 75 W was sometimes a very shaky process that required a much tighter convergence in the soft loops, otherwise runaway instabilities would often cause locklosses. We have previously relaxed some of these tight constraints to speed up lock but we didn't catch them all. This should take care of more of them (but maybe not all).

Naoki, Vicky, Camilla

After the vent, we can reach NLN, but we have locklosses from PI24 at 10.431 kHz. The SUS_PI guardian tries to damp, but it does not help. Vicky checked that the frequency of this PI is 10431.03 Hz as shown in the attachment. This is within the input bandpass filter (428.5-433.5 Hz after downconversion by 10kHz). 

We tried to excite the PI24 with ETMY. We used awggui and sent a sine wave at 431 Hz to H1:SUS-PI_PROC_COMPUTE_MODE24_BP_EXC. We could excite/damp the PI24 RMSMON by changing the damping phase so PI damping should work. We increased the damping gain for PI24 from 1000 to 10000, which is set by SUS_PI guardian.

Fri Aug 23 08:15:20 2024 INFO: Fill completed in 15min 15secs

TITLE: 08/23 Day Shift: 1430-2330 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Corrective Maintenance
OUTGOING OPERATOR: Tony
CURRENT ENVIRONMENT:
    SEI_ENV state: CALM
    Wind: 3mph Gusts, 2mph 5min avg
    Primary useism: 0.01 μm/s
    Secondary useism: 0.10 μm/s
QUICK SUMMARY:

IFO is in DOWN and MAINTENANCE

Continguing our work on tuning the IFO for observing following the recent vent

TITLE: 08/23 Eve Shift: 2300-0800 UTC (1600-0100 PST), all times posted in UTC
STATE of H1: Corrective Maintenance
INCOMING OPERATOR: Tony
SHIFT SUMMARY:
Took over from Tony at 6pm local (1utc) who was covering the first part of my shift. 

Elenna was getting H1 to NLN, well to the Inject Squeezing state, so she could hand off to Naoki for Squeezer optimization. 

H1 eventually made it to NLN and range was approaching 140Mpc, but then PI Mode 24 rung up againand had a lockloss (even with PI DAMPING for SUSPI). 

At any rate, with the lockloss, took the opportunity to run an Intial Alignment to capture the green references that Elenna got earlier today.  (I did have touch up SR2+SRM alignment by hand for SRC_ALIGN_OFFLOADED.)

Oh, also made the edit to ISC_LOCK to 'not' skip the SHUTTER ALS step.

The first attachment shows the DARM with/without squeezing today (blue: with squeezing, orange: without squeezing). The range is ~140 Mpc with squeezing and ~124 Mpc without squeezing. 

Above 1 kHz, DARM with squeezing is as good as the start of O4b and we have 4.8 dB squeezing at 2 kHz. The DARM below 1 kHz is worse and we will need to optimize FF and fix the calibration. We may also need to optimize PSAMS to improve the bucket sensitivity.

I ran SCAN_ALIGNMENT_FDS three times and accepted SDF as shown in the second attachment.
 

Both the X and Y arm green references have been set! Please run a full initial alignment at the next lockloss.

The X arm green references have been set several times and have stayed fairly the same; only the Y arm references have been an issue.

Procedural notes:

• after DRMI locked, we went to the DHARD WFS state, which is close to where the arm alignment control switches from the green WFS to the red (DHARD) WFS
• I started both "setEndGreenQPDOffsets_XARM.py" and "setEndGreenQPDOffsets_YARM.py" which are scripts found in "/opt/rtcds/userapps/release/als/h1/scripts"
• This changes the transmon QPD offsets that are in-loop with the PZTs on the table, controlling the pointing of the green light into vacuum. Therefore, while the arm alignment on red changes, the green alignment can follow and keep the cavity locked and co-aligned with green during these changes.
• Next, we stopped at "prep asc for full ifo" so I could once again step through the "engage asc" state by hand
• I had to walk some loops before turning them on, and I did similar SRC ASC walking as described in last night's recovery alog
• remember, "move_arms_dev.py", found in "/opt/rtcds/userapps/release/asc/h1/scripts" is a useful script for stepping arm alignment, such as CHARD
• Once all the alignment converged in "engage soft loops", I set the green references for both arms, following the steps I outline next

Green references steps:

• run the aforementioned green references scripts while waiting for the signals to converge
• Use "scope for green QPDs" found in sitemap>ALS>End X/Y overview>QPD offsets>!reset references drop down menu
• watch the bottom two scope plots for convergence of X and Y signals respectively.
• Once these signals converge, ctrl-C the scripts to stop them
• SDF green offsets in ALS X/Y
• Go to CAM ITM page on End X/Y overview screen
• average the Pitch and Yaw "position" signals for 30 seconds (command line: z avg -30 [channel name])
• Enter that new value into the "nominal field"
• SDF on ALS X/Y screen

SDFs for ALS X and Y are attached. The ALS X values have stayed fairly similar, and the ITMX CAM Yaw value I measured was exactly the same as the previous, so it did not appear as an SDF diff.

Final notes:

• I turned back on the PRC2 and INP1 DRMI ASC in the ISC_DRMI guardian. SRC DRMI ASC is still off, as is PRC1 (we should check the POP A offsets before turning this back on).
• If the initial alignment proceeds well, the next lock should not require any SRC1 offsets to lock. I am commenting out the SRC1 offsets in the "engage ASC for full IFO" state.
• We should add "shutter ALS" back into the path (I forgot to shutter ALS by hand and BOY does that cause a bunch of extra darm noise)

Today's activities:

- HAM7 turbo was valved out, and switched off. This pump needs ~3 hrs to spin down
- Immediately after this, FCV-2 was opened, so HAM7 was connected with the main volume via BSC3
- Then, RV1 (relay-tube remaining valve), FCV-4 and FCV-3 (valves towards HAM8 along the FCT) have been also opened

- Later, after the HAM7 turbo spun down, the backing supersucker cart was disconnected from it
- During the day, HAM6 RGA bakeout was ramped down. This RGA tree was also valved together with a small Ion-pump, which always keeps it under UHV.
- This RGA's filaments were also fired up. RGA scans of its small volume will be done in the upcoming days, then it will be valved together with the main volume (HAM6), and RGA scans will be done of HAM6, and these scans will be compared with the Corner RGA scan results

So, the interferometer is now fully open. The exact pumpdown time (from the start of the roughing to the opening of large GVs) was 14 days 17.25 hours. This is by far the shortest pumpdown so far. In dcc T2400085 the pumpdown will be more thoroughly analyzed, and will be compared with past pumpdowns, especially with the last one during February of 2024.

The pressures:
Corner (PT-120 and PT131): 6.3E-8 Torr
HAM6: 2.4E-7 Torr
HAM7: 1.25E-7 Torr
CP1: ~2.5E-8 Torr
CP2: ~5E-8 Torr

I reverted the Changes to ALS_ARM.py that were put in today because the DOF2 WFS were not working.

After HAM7/FC GVs were open this morning, I aligned FC1/2 and FC GR is locked. FC GR trans is ~110, which is reasonable. 

I measured NLG following 76542. The measured NLG is 16 (0.247/0.0154=16), which is a bit lower than the last measurement in 78000. The OPO temperature is very different from before as shown in the attached SDF.

Camilla, Oli

We looked into the weird results we were seeing in the ITMX In-Lock SUS charge measurements. The coherence when the bias is on for both the bias and length drives is always good, but the coherences are bad (usually below 0.09) for both bias and length drives when the excitations run with the bias off.

I compared the differences in the coherence value outputs in the python script versus the matlab script(screenshot), and although the values are calculated slightly differently and are not exactly the same, they are resonably close enough that we can say that there is not an issue with how we are calculating the coherences.

Next, we used ndscope to look at the latest excitations and measurements from July 09th (ndscope-bais on, ndscope-bias off). Plotting L3_LOCK_BIAS_OUTPUT, L3_DRIVEALIGN_L2L_OUTPUT, L3_LVESDAMON_UL_OUT_DQ, and L3_ESDAMON_DC_OUT_DQ for both ITMX and ITMY, if there was an issue with the excitations not going through, we would expect to see nothing on the ESDAMON and LVESDAMON channels, but we do see them on ITMX.

We were still confused as to why we would see the excitations go through the ESDAMON channels but still have such low coherence, so we compared the ITMX measurements to ITMY on dtt for the July 09th measurements looking at how each excitation showed up in DARM and what the coherence was. When the bias was on, both the bias drive and Length drive measurements look as we expect, with the drive in their respective channels, a peak seen in DARM at that frequency, and a coherence of 1 at that frequency(bias_drive_bias_on, length_drive_bias_on). However, in the comparisons with the bias off, we can see the excitations in their channels for both ITMX and ITMY, but while ITMY has the peak in DARM like the bias on measurements, ITMX is missing this peak in DARM(bias_drive_bias_off, length_drive_bias_off). The coherence between DARM and the excitation channel is also not 1 on ITMX.

We showed these results to Sheila and she said that these results for ITMX with the bias off make sense if there is no charge built up on the ITM, which would be the first time this has been the case! So there are no issues with the excitations or script thankfully.

We will be making changes to the analysis script to still run the analysis even if the coherence is low, and will be adding a note explaining what that means.