TITLE: 03/26 Day Shift: 15:00-23:00 UTC (08:00-16:00 PST), all times posted in UTC
STATE of H1:Maintenance
CURRENT ENVIRONMENT:
    SEI_ENV state: Maintenance
    Wind: 2mph Gusts, 2mph 5min avg
    Primary useism: 0.03 μm/s
    Secondary useism: 0.21 μm/s
QUICK SUMMARY: We lost lock at 14:41UTC, cause still to be looked at. Maintenance activities have started.

TITLE: 03/26 Eve Shift: 23:00-07:00 UTC (16:00-00:00 PST), all times posted in UTC
STATE of H1: Observing at 152Mpc
INCOMING OPERATOR: None
SHIFT SUMMARY:
Since the last mid shift report there was another lockloss at 6:08 UTC .
Once again relocking went just fine without an Initial_Alignment in 56 minutes with out intervention by the opperator.
There was a PI 31 ring up @ 6:51 UTC but while I was trying to find te right buttons to press it was supressed.

LOG:
Camilla's measurements will start Running again at 2am and continue until 6am.

TITLE: 03/26 Eve Shift: 23:00-07:00 UTC (16:00-00:00 PST), all times posted in UTC
STATE of H1: Observing at 152Mpc
CURRENT ENVIRONMENT:
    SEI_ENV state: CALM
    Wind: 6mph Gusts, 4mph 5min avg
    Primary useism: 0.02 μm/s
    Secondary useism: 0.19 μm/s
QUICK SUMMARY:

Lock lasted 8 hours and 51 min
Lockloss 3:34 UTC still investigating the cause of this lockloss.
Camilla had some measurements running while we were in Observing see Alog 76695 and was concerned that perhaps her measurements had made the arm powers drop significantly. So I pulled up some ndscopes of H1:GRD-ISC_LOCK_STATE_N and the Circulating Arm powers  H1:ASC-X_PWR_CIRC_OUT16 & H1:ASC-Y_PWR_CIRC_OUT16.
I did see that the arm power did dip before H1:GRD-ISC_LOCK_STATE_N changed to a down state.

But!!! I also did the same for the Lockloss that happened this morning with out her measurement running and saw the same behavior of the Arm power dipping before the Down state was declared by ISC_LOCK. I then decided (arbitrarily) that it was reasonable to think that the time between the ISC_LOCK state change and an observed loss of 10% of the Power in the arms would be a good metric to determine if the lockloss was "Caused" by this measurement.
I have effectively convinced myself that Camilla's A2L measurements have not caused this lockloss.... but I'm open to evidence that I have overlooked.

Relocking:
I have not taken ISC_LOCK through Initial_Alignment before relocking. H1 Is alrerady back to NOMINAL_LOW_NOISE  44 Minutes from NLN to NLN with out intervention from the Operator.  49Min 9 Sec from OBSERVING to OBSERVING.


 

Sheila, Jennie W

At around 21:49 UTC we used the step_45MHz.py in userapps/isc/h1/scripts to step the modulation depth in steps of 1dB down from 21dBm to 18dBm. This script adjusts the loop gains to compensate for a drop in power on the RF45 PDs.

Its also important to open the POP beam diverter to monitor what is happening to the RF 45 PD signals.

This is to check that the noise does not decrease with decreasing modulation depth which would imply that the modulator was imposing noise on the carrier through the ISS loop.

At around 22:18 UTC we put the modulation depth down by 3 dB we saw a 4% increase in the DARM broadband noise (measured the level at 2kHz with cursors) which is the green trace in the second image. The level of KAPPA C (shown in first image on bottom plot) only decreased by around 1% over this time, so we suspect some other cause other than a change in optical gain being responsible for this.

When we stepped the modulation depth up by 3dB (third image) we saw no change in the noise from the nominal state (purple trace on second image). Kappa C (bottom plot) looks almost the same as the nominal also.

In the fourth image it can be seen that f_C does not change much either.

DriptaB, LouisD, TonyS, FranciscoL

We noticed a 0.4% change from the value at the end of O4a for the X/Y ratio. We found alog 76562 where the Pcal EY EPICS values were changed. We have now changed them back to O4a values. See screenshot of SDF screen to find values. We will follow up with an updated value of X/Y to see if anything went wrong.

For future reference: steps to update SDF

1. 'caput' the channels to be changed
2. sitemap --> CAL EX(Y) --> GDS --> SDF TABLE --> ACCEPT (under select all, only afer triple checking numbers) --> CONFIRM.
3. SDF RESTORE SCREEN --> ! SELECT REQUEST FILE --> open "safe.snap" --> LOAD TABLE. Look for differences and confirm changes if needed (was not needed for EY).
4. Load OBSERVE.snap by following step (3).
5. Open FORCE COEFF CALCULATION and check that changes were applied.

Sheila, Naoki

We plan to scan the ZM alignment and need the fast SQZ BLRMS for that. We copied the BP filter for BLRMS 5 at 1.7kHz to BLRMS 6 and replaced the 0.1 Hz LP to 1 Hz LP for BLRMS 6.  So the BLRMS 6 is same as BLRMS 5 now, but has 1 Hz LP instead of 0.1 Hz LP. The SDF is attached.

TITLE: 03/25 Eve Shift: 23:00-07:00 UTC (16:00-00:00 PST), all times posted in UTC
STATE of H1: Commissioning
OUTGOING OPERATOR: Ryan S
CURRENT ENVIRONMENT:
    SEI_ENV state: CALM
    Wind: 4mph Gusts, 2mph 5min avg
    Primary useism: 0.03 μm/s
    Secondary useism: 0.25 μm/s
QUICK SUMMARY:
H1 has been locked for 4 hours and 22 minutes, We are currently in commissioning while Robert does injections.
The current plan is to stay in comissioning until 6PM then go into Observing.

TITLE: 03/25 Day Shift: 15:00-23:00 UTC (08:00-16:00 PST), all times posted in UTC
STATE of H1: Commissioning
INCOMING OPERATOR: Tony
SHIFT SUMMARY: Locked most of the day; several commissioning activities ongoing with observing periods in between.

• 16:15 - Lockloss; likely human caused
• 17:00 - Starting initial alignment
• 17:27 - IA finished, starting lock acquisition
• 18:03 - Lockloss from TRANSITION_FROM_ETMX
• 18:43 - Reached NLN
• 19:23 - Started observing
• 20:32 - Dropped observing for commissioning tests

LOG:

J. Kissel
ECR E1700387
IIET 9392
WP 11743

Tomorrow, we continue on the adventure towards upgrading the suspension watchdog systems that Oli, Dave and I have been chugging along on for the previous two weeks (see, eg, LHO aLOGs 76305, 76269 and 76545).
This week, we're tackling a big chunk -- all of the HAM triple suspensions, both large and smal, i.e. the 7 HSTS and 2 HLTS. 

Note :: these are the final suspensions that are hooked up to their respective ISIs, so this should be the last major upgrade.

As such I've:
    In the SUS model library parts,
    - Converted the BLRMS trigger generating systems to include a trust-worthy RMS calculation, coupled with a down-stream low-pass filter,
    - Removed all evidence of the USER DACKILL watchdog aggregator system
    - While I was there, I removed remaining evidence of the long-defunct / depricated "online detector characterization" ODC system, long since replaced by guardian state information
    On the top level SUS models,
    - Removed all evidence of the USER DACKILL watchdog aggregator system
    - Removed the IPC sender of the USER DACKILL to the respective ISI
    - Verified that the removal of library block output ports didn't botch any of the top level connections, reconnecting and re-organizing as needed
    On the top level of the ISI models,
    - Replaced the IPC receiver of the USER DACKILL watchdog from all respective SUS

which impacts all of the following models:

    Top Level ISI               Top Level Optic     Governing Library Part
    h1isiham2.mdl               h1susmc1.mdl        HSTS_MASTER.mdl
                                h1susmc3.mdl        HSTS_MASTER.mdl
                                h1suspr3.mdl        HLTS_MASTER.mdl
                                h1susprm.mdl        RC_MASTER.mdl

    h1isiham3.mdl               h1susmc2.mdl        MC_MASTER.mdl
                                h1suspr2.mdl        RC_MASTER.mdl

    h1isiham4.mdl               h1sussr2.mdl        RC_MASTER.mdl

    h1isiham5.mdl               h1sussr3.mdl        HLTS_MASTER.mdl
                                h1sussrm.mdl        RC_MASTER.mdl

    (no change to isiham7)      h1susfc1.mdl        HSTS_MASTER.mdl

    (no change to isiham8)      h1susfc2.mdl        HSTS_MASTER.mdl

In addition, some of the lower level SUS library parts were also impacted,
    SIXOSEM_T_STAGE_MASTER.mdl
    FOUROSEM_STAGE_MASTER.mdl
    FOUROSEM_STAGE_MASTER_OPLEV.mdl

All of the above model changes have been committed to the userapps SVN repo in revs 27310, 27311, 27312, and 27313.
    

We aimed to do A2L steps over the weekend, 15 minutes/step  76630, 76683, but as Elenna points out with the camera servos running the beam spot stayed static on the mirror while the mirror actuation point changed.

Looking at data from A2L tuning in April 2023 68384 attached plot, A2L steps are ~0.4 for a change of around 2 in the camera offset  (TRAMP 120s). We'll keep around the steps same as the weekend: +/- 1.0 per 15 minutes to up to +/-2.0 in the H1:ASC-CAM_{PIT,YAW}{1,2,3}_OFFSET channels during observing with nominal TRAMPs extended from 10s to 120s. These offsets are already unmonitered in sdf as reset each lock, I unmonitered the TRAMPs.

These offfsets vary up to 3 counts lock to lock, see attached plot. Set based on ADS converging.

Script saved in /ligo/gitcommon/labutils/beam_spot_raster/camera_servo_offset_stepper.py  Scheduled to run if we're in NLN via tmux session on cdsws26 at:

• 6pm - 10pm on CAM1 (BS => CAM1 => PRM)
• 10pm to 2am on CAM2 (ETMX => CAM2 => ITMX, ETMX)
• 2am to 6am  on CAM3 (ETMY => CAM3 => ITMY, ETMY)

Tony will be here during the first set so can cancel the others if there is any issues.

We scanned the FC detuning as shown in the first attachment. The nominal FC detuning is -28. The FC detuning below -31 seems better around 30 Hz. The second attachment shows that the BNS range at -34 FC detuning seems a few Mpc better than nominal so we set the FC detuning at -34 as shown in the third attachment.

A sinc function / temperature measurement from the single pass (spare) SHG is shown. The basic idea of the experiment was to see if the crystal is intact (it is). For this purpose, the crystal was pumped with 1064 nm and after one pass (single pass) it was checked how much green light was generated. The temperature was adjusted to find the best possible phase matching temperature.

No similarity to Mount Saint Helens, as described in 76239, was observed. Conclusion, the crystal is intact. (What seems strange is the asymmetry in the side maxima.)

• Pump power 20 mW
• Dark noise 0.9 µW
• Transmitted power 16.8 mW --> just 84 % power is transmitted (probably because the focus was too large, resulting in clipping somewhere inside the housing)
• Fit equation: A*(np.sinc((T-T0)/width))**2 
• Plot is dark noise corrected

Setup:

•  NTC (71-01T1002FF)
•  TEC (Laird)
•  controller (Thorlabs)

RickS, DaveB, TonyS, FranciscoL

On Friday, March 22, we measured an SRS SR340 function generator (FG) using three Keithley digital multimeters (KVM) to calculate the latency between each KVM. The FG was configured to make a ramp/sawtooth wave set to 20 Vpp at 0.1 Hz. The KVMs were configured to read 200 samples without delay. Figure "...200samples.pdf" shows the raw data from the KVM. Figure "...samples_zoom.pdf" is zoomed in the first section with a line fitted to the data. The line has a slope of m = 2 V/s.

The differences from the first KVM (id: 8019157) to the second KVM (id: 8018958) is plotted in blue on figure "...samples_diff.pdf" and yields a mean of 40.4 mV with a standard dev. of 0.21 mV. The differences from the first KVM to the third KVM (id: 1148559) is plotted in red on figure "...samples_diff.pdf" and yields a mean of 0.0808 V with a standard dev. of 0.44 mV. Figure "...samples_diffsub.pdf" plots each voltage difference individually. These values yield a latency between KVMs of 20.2 ms and 40.4 ms, respectively. To calculate the overall timing of the loop that stores the data, we measured the difference between a KVM 8019157 with itself (current - previous) and got a mean value of 0.1212 V, as indicated by figure "samples_diff2.pdf". The total latency of three keithleys for this measurement is of 60.6 ms.

The data shows that there is a latency of 20.2 ms between each KVM. It is safe to assume that, to sample 4 keithleys simultaneously, there will be an overall latency of 81 ms (~ 12 Hz). This latency is well within our design limits of measuring at a sample rate of 5 times per second.

Jennie W, Sheila

Jennie moved the DARM offset (H1:OMC-READOUT_X0_OFFSET  from 10.9 to 7.74 in slow steps) which changed the DCPD sum from 40mA on the DCPDs to 20mA.  This makes the SRCL feedforward adding noise below 70 Hz, but had no impact on the sensitivity above 80 Hz, as shown in the first attachment. 

The second attachment shows a DARM OLG measurement before and after the change, the gain at 60 Hz was the same within 1%.

R. Short, T.J. Shaffer

We discovered this afternoon that starting an injection on the OMC model did NOT cause H1 to drop observing. After looking into the DIAG_EXC Guardian node, which checks for errant excitations and prevents going into observing accordingly, we discovered two models had been added to the exclude_list: omc and caley. These appear to have been added in May of 2023 (pre-O4a) and never committed to svn. TJ and I both recalled these models having ongoing excitations in the leadup to O4a, but neither of us could remember why. Clearly they are not needed anymore, so they have been removed, and the exclude_list is again empty (the one exception remains for the CAL-INJ_CW_EXC excitation).

Errant injections into the omc and caley models will now properly prevent H1 from observing.

Artem, Louis, Camilla

For the in-lock charge measurements to swap from ETMX L3 to ITMX L3 with NEW DARM, we copied from ETMX FM7 into H1:SUS-ITMX_L3_DRIVEALIGN_L2L FM7. The SUS_CHARGE swap will turn this on and go back to the nominal FM4, FM5 at the end (is this required?).  Hope this will avoid the lockloss we caused last week: 76604.

Jennie W, Sheila, Camilla

I looked at the results of the A2L tests from the weekend for ETMY, ITMX and ETMX.

For ETMY the steps seem too small / A2L gain changing has little effect on the power recycling (LSC-POP-A and ASC-POP_NSUM), build-ups (ASC-{X,Y}_PWR), range (MPC range channel and BLRMS channels) or optical gain (KAPPA C). See first image.

More of a difference can be seen in the arm build-ups and PRG for ETMX. The best value for P2L looks like 4.4 as this maxmises the arm power and PRG, while the best range is for a Y2L of 4.6. See second image.

Y2L gains for ITMX seem to already be at their optimised value in terms of arm build-ups and power recycling, however the range improved slightly when the P2L gain was at  -0.4. See third image.

In summary maybe we need to retune ETMX and ITMX A2L gains a bit, but for ETMY it doesn't seem to gain us much.

See comment from Elenna below, we will run these again as per this entry.

Sheila, Daniel, Naoki, Nutsinee

This morning OPO failed to lock because our green launch power was too high. As of this morning the OPO guardian will take itself to DOWN when the power reaches above 35mW. Though this doesn't stop SQZ_MANAGER from re-requesting OPO to lock even if the pump ISS fails repeatedly (because SHG launch power was too high). Daniel also cranked up the OPO PZT offset to 10V using CLF slow offset to lower the lock point of the OPO PZT.

We made a few rough adjustments to the OPO guaridan:

1) In the ENGAGE_PUMP_ISS if ISS fails up to 20 times it will take itself to DOWN.  Injecting squeezing with no pump ISS means bad squeezing. Squeeze level will drift. Squeeze angle will drift. We shouldn't inject bad squeezing into the interferometer.

2) If the SHG launch power is higher than 35mW the flipper will close and the guardian will take itself to DOWN. The point of this statement is to protect the fiber. We should close the flipper.

3) We added two functions and two GuardStateDecorator.  GRLAUNCH checker lives in DOWN state and @ISS_checker lives in PRE_LOCK_CLF. If SQZ_MANAGER tries to take OPO to lock when these bad conditions are still true, OPO will refuse to go up and stays in DOWN.

The code has been loaded into the OPO Guardian. We still see to make SQZ_MANAGER put out nofification as well. For now the notifications live in the OPO guardian.

Naoki, Daniel, Nutsinee

Today we increased RF6  from -22dBm to -13 dBm and 8 dBm. We saw excess noise at 8 dBm above 300Hz but no excess noise at -13dBm. REF 12 is the squeezing at -22dB before we started the test. Using the time from alog76553. REF9 and REF10 both show squeezing at -13dBm RF6 at different squeeze angle where one has a better sensitivity at low frequency bucket. REF13 shows squeezing at 8dBm RF6. The excess noise above 300Hz cannot be improved with squeeze angle. Investigation is required.

We turned off ADF sqz angle servo during the test. We readjusted the ADF squeeze angle demod phase and accepted the new value in the SDF.

We are parking RF6 at -12dBm. Since Daniel didn't like the unlucky number 13.

Robert, Mitchell, Corey, Tony, Betsy, TJ, and Alena, Eddie and the SLiC team

In O4a, scattering noise at or near the current DARM noise floor was likely produced by 3 sources in the input MC tube (74772). The most important source was the MC baffle by HAM3, followed by the MC baffle by HAM2. I think that the main reason these two baffles produced scattering noise is that they were not angled enough and so they retro-reflected light scattered from certain optics as well as reflecting light between optics. To mitigate this, we increased the angle of these two baffles from 5 to 10 degrees (75637, 75654). We also increased the damping of both baffles in order to reduce the cutoff frequency of scattering shelves.

In addition, the beam tube itself might have been producing scattering noise associated with its axial resonance of 15.2 Hz (Fig. 1).  Because of this possibility, we installed nozzle baffles in all MC-tube nozzles that have blank-off flanges (15 total - 75654 ). Blank-off flanges are generally the most problematic nozzle equipment because they cover the whole nozzle and the circular milling groves retro-reflect some of the incident light from a wide range of angles. We also installed two nozzle baffles in the upper two ports of the +Y door of HAM3 (last page of Fig. 2).

Finally, we installed an unplanned baffle to hide a portion of the MC-tube wall that was likely retro-reflecting light scattered from MC3 (75688). This glint was identified in beam-spot photos, photos that are taken and illuminated  from near the beam spot locations on the optics.

Figure 2 shows beam spot photos taken from the point of view of each of the six optics before and after the mitigations. There were some auto-focus problems with some of the "before" pictures. Some of the photos are annotated with features and possible problems.

Figure 3 shows the damping of the two MC baffles