TITLE: 04/04 Day Shift: 15:00-23:00 UTC (08:00-16:00 PST), all times posted in UTC
STATE of H1: Observing at 152Mpc
INCOMING OPERATOR: Ryan C
SHIFT SUMMARY:

H1's been locked for the last 15+hrs and most of today was used for commissioning time and RyanC took us back to Observing at 2300 (:42).  :)

LOG:

• 1506 Commissioning Time begins (for Squeezer work)
• 1635-1655 pressure washing of cable trays out near the water tower (chris, tyler, eric)
• 1727-1755 Parts run to MX (fil)
• 1746-1752 Checks at Fire Pump/woodshop building (karen)
• 1821-2249 Updating and then Revert of jitter cleaning coefficients (jennie)
• 2022- ~2100 Unplanned phone outtage on site for roughly an hour.
• Did not have time to  run a PCal-DARM Broad Band meas for Louis at the end of Commissioning time.  :(
• 2300:42 Back to Observing (with H1 lock clock at 15hr20min!)

TITLE: 04/04 Eve Shift: 23:00-07:00 UTC (16:00-00:00 PST), all times posted in UTC
STATE of H1: Commissioning
OUTGOING OPERATOR: Corey
CURRENT ENVIRONMENT:
    SEI_ENV state: CALM
    Wind: 11mph Gusts, 8mph 5min avg
    Primary useism: 0.03 μm/s
    Secondary useism: 0.28 μm/s
QUICK SUMMARY:

• Winds calming down
• SQZ commissioning is wrapping up
• We've been locked for 15:18

Naoki, Eric, Camilla

We continued the PSAMS coarse scan in 76925. Yesterday, IFO was not thermalized, but today IFO is thermalized at least for 7 hours. It seems our nominal 140/90 (strain voltage 7.22/-0.71) would be close to optimal. The detail analysis will follow.

This time, after we moved PSAMS, we compensated the alignment change caused by the PSAMS change by looking at OSEM. This works well for ZM4, but not for ZM5 and we need to touch ZM5 in addition to the compensation. This might be related to the beam miscentering in ZM5 as reported in 75770.

no sqz (10 min)

PDT: 2024-04-04 08:06:30 PDT
UTC: 2024-04-04 15:06:30 UTC
GPS: 1396278408

asqz 200/115 (strain voltage 9.59/-0.702) (5 min)

PDT: 2024-04-04 08:41:34 PDT
UTC: 2024-04-04 15:41:34 UTC
GPS: 1396280512

sqz 200/115 (5 min)

PDT: 2024-04-04 08:49:14 PDT
UTC: 2024-04-04 15:49:14 UTC
GPS: 1396280972

asqz 200/200 (strain voltage: 9.59/2.67) (5 min)

PDT: 2024-04-04 09:28:12 PDT
UTC: 2024-04-04 16:28:12 UTC
GPS: 1396283310

sqz 200/200 (5 min)

PDT: 2024-04-04 09:36:04 PDT
UTC: 2024-04-04 16:36:04 UTC
GPS: 1396283782

asqz 100/200 (strain voltage 6.83/2.72) (5 min)

PDT: 2024-04-04 09:55:09 PDT
UTC: 2024-04-04 16:55:09 UTC
GPS: 1396284927

sqz 100/200 (5 min)

PDT: 2024-04-04 10:02:23 PDT
UTC: 2024-04-04 17:02:23 UTC
GPS: 1396285361

asqz 0/200 (strain voltage 2.2/2.72) (5 min)

PDT: 2024-04-04 10:27:25 PDT
UTC: 2024-04-04 17:27:25 UTC
GPS: 1396286863

sqz 0/200 (5 min)

PDT: 2024-04-04 10:35:27 PDT
UTC: 2024-04-04 17:35:27 UTC
GPS: 1396287345

asqz 140/90 (strain voltage 7.22/-0.71) (5 min)

PDT: 2024-04-04 11:04:22 PDT
UTC: 2024-04-04 18:04:22 UTC
GPS: 1396289080

sqz 140/90 (5 min)

PDT: 2024-04-04 11:12:41 PDT
UTC: 2024-04-04 18:12:41 UTC
GPS: 1396289579

asqz 170/90 (strain voltage 8.80/-0.70) (5 min)

PDT: 2024-04-04 11:55:59 PDT
UTC: 2024-04-04 18:55:59 UTC
GPS: 1396292177

sqz 170/90 (5 min)

PDT: 2024-04-04 12:03:26 PDT
UTC: 2024-04-04 19:03:26 UTC
GPS: 1396292624

asqz 75/90 (strain voltage 5.77/-0.71) (5 min)

PDT: 2024-04-04 12:24:44 PDT
UTC: 2024-04-04 19:24:44 UTC
GPS: 1396293902

sqz 75/90 (5 min)

PDT: 2024-04-04 12:31:39 PDT
UTC: 2024-04-04 19:31:39 UTC
GPS: 1396294317

asqz 130/125 (strain voltage 7.21/0.26) (5 min)

PDT: 2024-04-04 14:58:24 PDT
UTC: 2024-04-04 21:58:24 UTC
GPS: 1396303122

sqz 130/125 (5 min)

PDT: 2024-04-04 15:06:03 PDT
UTC: 2024-04-04 22:06:03 UTC
GPS: 1396303581

asqz 130/83 (strain voltage 7.22/-1.2) (5 min)

PDT: 2024-04-04 15:39:41 PDT
UTC: 2024-04-04 22:39:41 UTC
GPS: 1396305599

sqz 130/83 (5 min)

PDT: 2024-04-04 15:46:36 PDT
UTC: 2024-04-04 22:46:36 UTC
GPS: 1396306014

Jennie W, Sheila, Gabriele remotely

Summary:  With the ISS second loop open, we were able to move the IMs without loosing lock.  We realized that the BS camera set point is not ideal for power recycling gain, and that is the reason that the IM moves seemed to improve build ups.  After reseting the camera servo set point, we were able to increase power on the ISS array and IM4 by moving IM1 yaw in the opposite direction from past moves ( 76534 and 76607 ). 

Details:

We moved IM1 and 3 with the ISS second loop open (take IMC_LOCK to LOCKED), this allowed us to move the input pointing without loosing lock. 

We believe that the improvements in build ups seen in 76534 and 76607 were due to the spot on the ITMs/BS moving. When Jennie moved the IMs in the same direction as these earlier attempts, the build ups increased in both arms and LSC POP, but once the CAM1 YAW servo converged the build ups where back to where they started (screenshot).  The IM move also decreased the power on the ISS second loop array (in and out of loop sums) and IM4 trans QPD dropped, indicating that this move may have been the wrong direction to reduce any clipping in HAM2.  We then moved the CAM1 YAW set point to where the error signal was at the maximum build up time, and this restored the build ups.  

Jennie moved the IMs back to their starting place, which restored the power on IM4 trans and the ISS array, then we walked the CAM1 YAW offset (BS camera feeds back to PRM) to maximize the POP and arm powers, we found that an offset of -236 counts seemed best.   This is consistent with what Jennie and Camilla found with the stepper scripts in 76770.  In 76695, Camilla looked at how the camera offsets change from lock to lock, when they are set after ADS converges. This gave us a roughly 0.5% more power in the arms. We want to change the guardian to use this set point in every lock, and retune the ITMs A2L gain for this new set point, but we haven't done that today.

Next Jennie moved IM1 yaw in the positive direction, which increased the power on IM4 trans and ISS second loop array PDs screenshot and here.  While she was doing this the sqz team was injecting anti-sqz, but when they were done we had a quick quite time for a DARM comparison, it appears that we might have made the noise worse.  We wll double check as we revert this move after the squeezers are finished.

We stopped using the SQZ_ANG_ADJUST in  76742 so no longer need the SQZ 1300Hz ADF line to be on in observing. We're turned it off and accepted in sdf. H1:SQZ-RLF_INTEGRATION_ADFEN

Turned on new MICH FF at 19:45UTC, details and plot in 76956. Updated safe and observe sdf's and ISC_LOCK.

Took SRCL measurements 19:50-20:05UTC.

Gabriele suggested that we rerun Sheila's DARM comparison scripts (76768) to look at time from last night. I used the instructions that Sheila wrote in LHO:76768.

The two times I used are from Gabriele's DARM comparison (listed below), however I just used 600s segments instead of the full 3600s. Also, these plots compare DELTAL_EXTERNAL since we were having nds issues on-site and couldn't fetch GDS-CALIB_STRAIN for a few hours.

O4a GPS 1389058533
ER16 (last night) GPS 1396241443

Attachments:

comparison.png: DARM comparison shared by Gabriele in Mattermost showing that we are almost back down to the O4a level of noise near 100Hz.

compare_darm_spectra.pdf: DARM spectra comparison showing that we're currently pretty much right at late O4a noise levels above 70Hz. Our noise is better from about 18Hz to about 33Hz but our noise floor is higher now 50-70Hz.


compare_darm_range_integrand.pdf: BNS range integrand comparison

compare_cumulative_range.pdf: comparison of the cumulative range at both GPS times. BNS range is matched between the two times below about 18Hz and right at 150Hz (by eye). If I'm interpreting this plot correctly, we're doing better than late O4a now between 20 & 70Hz but slightly worse everywhere else. After talking to Sheila about how to interpret this plot: we are doing better from 20Hz to around 35Hz, then losing range 35Hz to ~70Hz. The improvements are likely from the new DARM offloading but those improvements are being negatively affected by other low frequency noise we're still trying to figure out.

H1 has been out of Observing most of the morning for mostly Squeezer measurements; will return to Observing at 4pm local time (or sooner).

Jennie, Jenne, Sheila

I pushed Jenne's updated cleaning but cannot check if this is better or worse until our problems getting data from nds2 are fixed.

I ran the following:

cd /ligo/gitcommon/NoiseCleaning_O4/Frontend_NonSENS/lho-online-cleaning/Jitter/CoeffFilesToWriteToEPICS/

python3 Jitter_writeEPICS.py

I accepted these DIFFS in OAF model in OBSERVE.snap but we might have to revert them before finish of the commissioning period today if we find out the cleaning is worse.

GPS 139627823 - 16 mins quiet time from last night.

11:12:41 UTC - 11:18:38 UTC quiet time just before cleaning implemented.

11:19:55 UTC new cleaning drops.

11:31:30 UTC end of quiet time.

Thu Apr 04 10:05:02 2024 INFO: Fill completed in 4min 58secs

Gerardo confirmed a good fill via camera. TCmins close to trip temps, it is chilly outside, 40F (4C)

Here are two plots which show the same thing:  the excess low frequency noise noted yesterday 76924 has gotten better but we are still worse at low frequency than we were April 2nd.

The first plot is just a DARM comparison (without cleaning, CAL DELTA L), the second is a plot of the low frequency blrms (  BLRMS 2 is brown is 20-29 Hz, BLRMS 3 is pink is 38-60 Hz).

The third plot shows the same blrms against a ground motion blrms, ground motion doesn't seem to be an explanation.

J. Oberling, R. Crouch, T. Guidry

Since the last update we have tried a couple of things.

First, we attempted to align the FARO to the BSC2 chamber directly.  We placed the FARO in the biergarten and shot the chamber-side door flanges.  We used the SMR to sweep along the outside of the +X side of the +Y door flange, and the +Y side of the +X door flange.  The shots were done as circles, which we could then place a point at circle center to represent the center of the door flange.  The hope was we could then project lines to represent the X and Y axes, and use that to align to our origin using a Plane/Axis/Center Point alignment routine.  I won't go into much detail, as it didn't work.  We used this alignment to look at PSI-6 in the biergarten, and it was off by over 1cm; we then looked at LV-35 and that one was off by even more.  I don't remember exact values as we didn't save screenshots since the devaiations were so large.  Let's say that if these deviations were true, I'm not sure how we would have a functioning, aligned, and alignable IFO.  So, that experiment didn't work, moving on.

Today we decided to try using height marks 901, 902, and 903 to set our Z axis alignment.  We looked at marks 901 and 902 with an autolevel and compared them to our BSC2 door flange scribe average we had used the water tube level to measure (alog 75974) and the listed local Z coordinate from T1100187.  Results:

• 901:
  • T1100187: -54.7 mm
  • Water level: -55.2 mm
  • Difference: -0.5 mm
• 902:
  • T1100187: -62.7 mm
  • Water level: -62.9 mm
  • Difference: -0.2 mm

Not bad, and definitely not the almost +4mm the FARO was measuring for these marks w.r.t. BTVE-1.  If we use our differential height survey from alog 75771 we can also calculate the local Z axis coordinate for mark 903, which comes out to -79.8 mm (versus the listed coordinate of -79.9 mm from T1100187), and again not the almost +4mm reported by the FARO when measured w.r.t. BTVE-1.  It's looking more and more like there was some error in the Z axis position of BTVE-1; whether that error was in setting the monument itself or in setting BSC2 w.r.t. to BTVE-1 we cannot say.  The fact of the matter is that when compared to BSC2 as it sits right now based on our water level survey, the height marks we've looked at are pretty close to their listed coordinates and BTVE-1 is definitely not.  We also happened to do the same differential height survey with BTVE-1 (also in alog 75771), so we can calculate a local Z coordinate for BTVE-1 based on our height mark 903 (which we have now tied to BSC2 Z=0).  Doing so gives a local Z axis coordinate for BTVE-1 of -1060.3 mm (Z₉₀₃ - deltaZ_BTVE-1/903 = -79.8 - 980.5); this becomes -1060.9 mm once we convert to our global coordinate frame (which is decidedly not the -1057.2 mm all of the old documentation lists it as).

Now that we have local Z coordinates for 901, 902, 903, and BTVE-1 that have all been tied to BSC2 Z=0, we used these to set a new alignment.  First, we need global Z coordiantes for our 3 height marks.  We got these by using a autolevel to set a magnetic nest inline with the height mark to be measured.  The FARO was put into an intial alignment using BTVE-1, PSI-1, PSI-2, and PSI-6 (X and Y are generally pretty good, Z is off but we don't care yet), and we then placed the SMR on the nest we placed inline with 903.  From this we got an X/Y coordinate for the nest that we could use to calculate our global Z.  Once this was done we added 903 into the alignment routine, and removed PSI-1, PSI-2, and PSI-6 for the Z axis fit.  we then moved the FARO to a position where we could see 901 and 902 and shot them in the same way we did 903.  Ultimately, we ended up with an alignment using BTVE-1, PSI-1, PSI-2, and PSI-6 for X and Y and 901, 902. and 903 for Z.  The coordinates used for the height marks were (format is [X,Y,Z]):

• 901: [1075.8, 12366.1, -55.7] mm
• 902: [1078.9, 24938.8, -63.3] mm
• 903: [1082.6, 37455.6, -80.0] mm

Tyler has a screenshot of the results of the alignment that he'll post as a comment to this alog.  One thing to note here: We were not using the new BTVE-1 Z as part of the Z axis alignment, only marks 901, 902, and 903.  It's somewhat comforting to see the Z axis coordinate of BTVE-1 as calculated by the alignment routine as close as it is to what we think the nominal shoud be based on our water level survey of BSC2.  The PSI monuments are all out, especially PSI-2.  I'm not sure how concerning this is, as we don't trust the Z coordinates of the PSI monuments anyway.

One caveat here, all of the height marks we used are almost in a line down the Y axis, with very little deviation in the X axis coordinate (a deltaX of less than 7mm across ~25m of the Y axis).  I'm not entirely confident we're picking up the global tilt of our X axis with this configuration.  We want to take this alignment and test and refine it; first thing we can do is get some more height marks spread along the X axis to hopefully catch the global X axis tilt.  More to come!

Kevin and Vicky helped to get the old range comparison plots from the noise budget working with some updates to the noise budget.  The first plots show the spectra, range integand and the cumulative range for a comparison between O4a and a few days ago.  This is range calculated by gwinc, the sensmon range is shown in the legend. 

Looking at the darm spectra and the range difference plot here, you can see that we gained about 15Mpc of range from low frequency improvements including DARM offloading.  Above 40Hz our recent sensitivity has been worse, we lose 15 Mpc from the decreased sensitivity beween 40-100 Hz and another 7 or so from the worse sensitivity above 100Hz. 

Last night we had slightly better BNS range after the squeezer alignment work 76757 , the same comparison of O4a to last night shows that we are loosing less range from 65-300 Hz, as shown in this plot as well. 

I've also made this comparison for no squeezing, using times from 76537 and 76540: here.  This shows that without squeezing the mid frequency sensitivity (30-70Hz) has gotten worse which is costing roughly 10Mpc of range.

Elenna's sensitivity comparison from a few weeks ago contains helpful links to recent changes: 76449

All three times we tried to move the input beam (76534, 76607 and yesterday), we caused a lock loss when moving in the yaw direction.

Approximate lock loss times: 1394946678 1395096385 1395535842

All lock losses appear to show the same behavior:

• IMC transmission drops in a "small" step before anything else happens. IMC transmission then stays constant for 120 ms, then drops quickly
• This corresponds to a "glitch" in REFL_SERVO_ERR, the start of a "ramp" in REFL_SERVO_OUT, and a discrete step in LSC error signals (PRCL, MICH, SRCL)
• Shortly after that, all signals go crazy, but there is no evident oscillation

Those lock losses are indeed very fast, and this seems to point to a CARM problem.