FAMIS 20704

The NPRO has had a couple of sudden power jumps in the past week, seen also by output of AMP1 and less so from AMP2. The AMP LD powers didn't move at the same time as these jumps.

PMC transmitted power continues to fall while reflected power increases; when we swap the PMC tomorrow morning this should finally be put to rest.

Jason's brief incursion last Tuesday shows up clearly in environment trends.

TITLE: 07/01 Eve Shift: 2300-0500 UTC (1600-2200 PST), all times posted in UTC
STATE of H1: Observing at 154Mpc
OUTGOING OPERATOR: Ibrahim
CURRENT ENVIRONMENT:
    SEI_ENV state: SEISMON_ALERT
    Wind: 16mph Gusts, 11mph 5min avg
    Primary useism: 0.07 μm/s
    Secondary useism: 0.07 μm/s
QUICK SUMMARY: H1 has been locked and observing for just over 3 hours. ITM bias change tests while observing have resumed for the afternoon.

• Wind is slightly elevated, microseism is low
• All other systems nominal

TITLE: 07/01 Day Shift: 1430-2330 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Observing at 158Mpc
INCOMING OPERATOR: Ryan S
SHIFT SUMMARY:

IFO is in NLN and OBSERVING as of 20:17 UTC (3 hr xx min lock)

Very calm rest-of-shift after a speedy <1 hr 30 min lock acquisition.

Other:

1. Accepted SDF Diff is screenshotted (SUS SRM)
2. ITMY L3 Bias is UNMONITORED until Robert is done working on it (to not affect observing). Also screenshotted
3. Expecting 5.3 EQ from Japan

LOG:

FAMIS 21042

pH of PSL chiller water was measured to be just above 10.0 according to the color of the test strip.

Naoki, Camilla

We continued the ZM4 PSAMS scan with hot OM2 in 78636. We changed ZM4 PSAMS strain voltage from 7.5V to 5.5V and saw the squeezing and range improvement as shown in the first attachment. The second attachment shows the squeezing imrovement. The squeezing level is 5.2dB around 2 kHz.

We also tried 4.5V ZM4 PSAMS, but it is worse than 5.5V. So we set the ZM4 PSAMS at 5.5V. The ZM5 PSAMS strain voltage is -0.78V.

Everytime we changed ZM4 PSAMS, we compensated the ZM4 pitch alignment with slider and ran SCAN_ALIGNMENT_FDS and SCAN_SQZANG.

18:15-18:35UTC took MICH, PRCL, SRCL LSC noise budget injections. Following instructions in 74681 and 74788. Last taken with cold OM2 in 78554.

Committed in ligo/gitcommon/NoiseBudget/aligoNB/aligoNB/H1/couplings and on aligoNB git. For plot, used gpstime 1403879360 # Hot OM2, 2024/07/01 14:29UTC, Observing Time, O4b, IFO locked 3h30 hour, 158MPc range

In addition to usual references, I added H1:CAL-CS_{MICH,PRCL,SRCL}_DQ and saved as ref13.

Comparing today's lsc noise budget to cold OM2 lsc noise budget in 78554:

• PRCL is the same and still dominates <30Hz
• MICH is now worse 10-20Hz and 40-100Hz (we were unsuccesfull in installing an imporved FF 78774)
• SRCL is now better <30Hz, above this it's a wash, better some places, worse others but a factor of 10 below DARM.

IFO is in LOCKING after an unknown LOCKLOSS at 18:55 UTC

Scheduled 8:30 - 11:30 PT (15:30 UTC to 18:30 UTC) Comissioning went well and finished at 11:36 PT.

Other:

• 16:53 - 16:58 UTC, Erik put in a 0 amplitude excitation in H1:SUS-ETMX-L1_CAL_EXC in order to test alog 78746's failed excitation start during Saturday's Cal Sweep. Comments on that alog are relevant to this.

After Sheila/Jennie's 78776 SRM move, the SRCL FF got worse. Compare green before SRM move to brown after move in attached plot. We tuned the SRCL FF gain from 1.18 to 1.14 to improve from brown to blue trace. If we see SRCL coherence, we could remeasure and fit the FF.  Accepted in sdf and lscparams.

Mon Jul 01 10:12:00 2024 INFO: Fill completed in 11min 56secs

Gerardo confirmed a good fill curbside.

Sheila, Jennie W

We lost some range with the hot OM2 so we thought to see if we could move SRM and raise the coupled cavity pole to regain this range as we did before in this entry.

Took 5 minutes no squeeze time.

Opened POP beam diverter to monitor POPAIR

Following the procedure in this entry we opened the SRC1 ASC loops by turning off input and offsets simultaneously after changing ramp to 0.1s.

Set the ramp to 10s, turn gain to 0, clear history, gain back to 4.

Then we started to move SRM alignment sliders.

The starting alignment sliders are here.

started yaw steps down on SRM, wrong way as f_cc avg went down, changed to up in  yaw, then noticed POPAIR_RF18 was going down so switched to pitch steps down. Found a poitn at which it no longer chnaged fcc, went back to maximum found for f_cc. The trends can be seen here where the first vertical cursor is when we opened the beam diverter and the second is when we thought we had the highest coupled cavity pole (middle bottom trace). So we put the SRM sliders to their values for this time after finishing.

I then changed offsets in SRC1 ASC to -0.0417 for ASC-SRC1_P_OFFSET and 0.0977 for ASC-SRC1_Y_OFFSET but didn't turn them on while we grabbed 5 minutes no squeeze time.

17:05:30 UTC closed loops and switched on new offsets.

Sheila used the second period of no squeeze time to plot the how the range compares to June 24th when we had a cold OM2. This plot shows the DARM comparison on the top plot (Yellow is cold OM2, blue is hot OM2) and the range difference on the bottom. This plot shows the cumulative range comparison on the top (yellow is cold OM2, blue is hot OM2) with the same difference in range plotted on the bottom. From the bottom plot it looks like with hot OM2 we gain range between 25 and 40Hz, don't gain between 40 and 90 Hz and lose range for hot OM2 above this point.

So summary is, we didn't completely recover the range by raising the coupled cavity pole. Hot OM2 is good for low frequency range but not for high frequency. We still need to do some PSAMS tuning today so this might regain us range at higher frequencies.

Last checked in alog78246, closes FAMIS 28450.

For the CO2 lasers, ITMY and ITMX have dropped in power but only by a small amount (by ~1 and <1 [W]? I'm not sure on the units).

ITMY and ITMX HWS_SLEDPOWERMON dropped to zero last Tuesday as they were turned off due to alignment issues alog78654, and the SPHERICAL_POWER is still flat lined from the SR3 moves.

We tried the new hot OM2 MICH FF filter loaded in FM5 from 78688. The original FM6 FF was better, see attached, so we left everything as nominal. Is  MICH changing over time so that last weeks injections are not good today?

TITLE: 07/01 Day Shift: 1430-2330 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Observing at 155Mpc
OUTGOING OPERATOR: Oli
CURRENT ENVIRONMENT:
    SEI_ENV state: CALM
    Wind: 3mph Gusts, 1mph 5min avg
    Primary useism: 0.01 μm/s
    Secondary useism: 0.08 μm/s
QUICK SUMMARY:

IFO is in NLN and OBSERVING (3 hr 35 min lock)

• When I got in, the H1 CS Dust LAB1 300NM Dust Alarm was sounding, so will investigate this.
• Per a sticky note left on the screen hinting to alog 78729, I put SUS_ITMY L3 Bias back into SDF Monitoroing. While TJ's screenshot hinted at 4 SDF Diffs (3 in ITMY and 1 in ITMX) to remonitor, I only found the 3 diffs for ITMY and re-monitored those (screenshot).

Link to report.

• The duty factor for the week was 72.15%. This is much better than the performance in the previous week, which was beset by locking problems.
• The average BNS range was around 150 Mpc. The week started with a range of 130 Mpc in the first observation stretch but subsequently climbed to 150 Mpc later that day -- after a commissioning break (alog 78340). It remained around 150 Mpc for the rest of the week but touched 160 Mpc on the last day (Sunday), following a SQZ returning (alog 78467).
• A couple of the lock-losses, on Wednesday and Thursday, appeared to be due to signals in ETMX (alog 78417, alog 78392).
• Some sources of BNS range drops appear to be (a) nonlinear noise, especially, at low frequencies (< 15 Hz); (b) noise in SUS MC2 ( less than ~0.1 Hz); (c) noise due to acoustic coupling in HAM6 (~40 Hz); (d) elevated wind speeds.
• Hveto: 28 channels appeared in Hveto this week of which 14 were not seen in the previous week.
• FScan: Plots were present for all days. The line counts are 729, 879, 1027, 977, 828, 699, and 814, respectively, somewhat on the high side on Wednesday.

TITLE: 07/01 Eve Shift: 2300-0800 UTC (1600-0100 PST), all times posted in UTC
STATE of H1: Observing at 157Mpc
INCOMING OPERATOR: Oli
SHIFT SUMMARY: One lockloss early in the shift, but recovery was simple and have been observing since. H1 has now been locked for 7 hours.

• 23:39 - Lockloss - alog78765
  • Touched up RefCav alignment - alog78766
• 00:57 - Observing

LOG:

Lockloss @ 23:39 UTC - link to lockloss tool

Locked for 26 minutes. No obvious cause, but I see the ETMX motion about 100ms before the lockloss this time.

I'm going to take this opportunity to do a quick FSS RefCav alignment adjustment so that it can hopefully make it until Tuesday when we swap out the PMC.

Calibration sweep taken today at 2106UTC in coordination with LLO and Virgo. This was delayed today since we were'nt thermalized at 1130PT.

Simulines start:

PDT: 2024-06-29 14:11:45.566107 PDT
UTC: 2024-06-29 21:11:45.566107 UTC
GPS: 1403730723.566107

End:

PDT: 2024-06-29 14:33:08.154689 PDT
UTC: 2024-06-29 21:33:08.154689 UTC
GPS: 1403732006.154689
 

I ran into the error below when I first started the simulines script, but it seemed to move on. I'm not sure if this frequently pops up and this is the first time I caught it.

Traceback (most recent call last):
 File "/var/opt/conda/base/envs/cds/lib/python3.10/multiprocessing/process.py", line 314, in _
bootstrap
   self.run()
 File "/var/opt/conda/base/envs/cds/lib/python3.10/multiprocessing/process.py", line 108, in r
un
   self._target(*self._args, **self._kwargs)
 File "/ligo/groups/cal/src/simulines/simulines/simuLines.py", line 427, in generateSignalInje
ction
   SignalInjection(tempObj, [frequency, Amp])
 File "/ligo/groups/cal/src/simulines/simulines/simuLines.py", line 484, in SignalInjection
   drive.start(ramptime=rampUp) #this is blocking, and starts on a GPS second.
 File "/var/opt/conda/base/envs/cds/lib/python3.10/site-packages/awg.py", line 122, in start
   self._get_slot()
 File "/var/opt/conda/base/envs/cds/lib/python3.10/site-packages/awg.py", line 106, in _get_sl
ot
   raise AWGError("can't set channel for " + self.chan)
awg.AWGError: can't set channel for H1:SUS-ETMX_L1_CAL_EXC