After a lock loss this morning Sheila and I spent some time looking further into the mode spacing for ALS (alog80065). We each took an arm and looked at the mode spacing and peak heights at good alignments and some not as good alignments. This exercise didn't yield any major revelations, but did confirm that our Y arm definitely doesn't have perfect mode matching, X arm seems to be better than Y. 

Attachment 1 - ALS Y 00 mode to 2nd order mode spacing. This showed that yesterday Sheila and Ibrahim missed the small 1st order mode between these and Sheila has sinced updated their FSR and FHOM values (alog80076).

Attachment 2 - An example of ALS Y locking below the max flashes, showing that some of our power is in the higher order modes.

Attachment 3 - ALS X comparison of attachment 1

Attachment 4 & attachment 5  - ALS X 1st order peak spacing and height for an okay alignment (4) vs a better alignment (5).

Attachment 6 & attachment 7 - Same as above but for the 2nd order modes.

Lockloss @ 16:36 UTC - link to lockloss tool

No obvious cause, but there's a small hit on ETMX about 100ms before the lockloss. We've often seen similar motion before locklosses like this.

FAMIS 26295

Laser Status:
    NPRO output power is 1.822W (nominal ~2W)
    AMP1 output power is 64.33W (nominal ~70W)
    AMP2 output power is 137.7W (nominal 135-140W)
    NPRO watchdog is GREEN
    AMP1 watchdog is GREEN
    AMP2 watchdog is GREEN
    PDWD watchdog is GREEN

PMC:
    It has been locked 16 days, 21 hr 59 minutes
    Reflected power = 22.18W
    Transmitted power = 104.8W
    PowerSum = 127.0W

FSS:
    It has been locked for 0 days 8 hr and 13 min
    TPD[V] = 0.8122V

ISS:
    The diffracted power is around 1.5%
    Last saturation event was 0 days 8 hours and 13 minutes ago

Possible Issues: (all are known)
    AMP1 power is low
    PMC reflected power is high
    ISS diffracted power is low

Fri Sep 13 08:12:45 2024 INFO: Fill completed in 12min 41secs

TITLE: 09/13 Day Shift: 1430-2330 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Observing at 156Mpc
OUTGOING OPERATOR: TJ
CURRENT ENVIRONMENT:
    SEI_ENV state: CALM
    Wind: 11mph Gusts, 7mph 3min avg
    Primary useism: 0.01 μm/s
    Secondary useism: 0.07 μm/s
QUICK SUMMARY: H1 has been locked and observing for just over 6 hours. Looks like one automated relock overnight.

• Wind and ground motion low
• All other systems nominal

I just noticed a chat message from Erik that there was only one hour of Seismic blrms data being displayed in the control room. This has to do with the fact that after h1dmt1 was restarted there was only 1 hour of trend data available in the last 48  hours due to the mis-mounting of the /gds trends directory. The trend files are now available back to yesterday afternoon, so a restart of the blrms monitors should expand the displayed data to at least 16 hours. I tried to contact the control room via teamspeak, but I did not get a reply. I will wait until the control room is manned to restart the blrms monitors. This should have no effect other than to cause the blrms monitor displays to update.

TITLE: 09/13 Owl Shift: 0500-1430 UTC (2200-0730 PST), all times posted in UTC
STATE of H1: Observing at 152Mpc
OUTGOING OPERATOR: Tony TJ
CURRENT ENVIRONMENT:
    SEI_ENV state: CALM
    Wind: 13mph Gusts, 6mph 3min avg
    Primary useism: 0.02 μm/s
    Secondary useism: 0.09 μm/s
QUICK SUMMARY:
H1 has been locked and observing for 9 hours and 24 minutes.
A whole lot of nothing has happened during this shift.

3:22 UTC GRB-Short E511196

Sheila, Louis, Francisco

Following LHO:80044, we measured ASC-DHARD_P(Y) for different ASC-AS_A_DC_YAW_OFFSET and found the loswet values of DHARD_Y at an offset of -0.05.

The "DTT_AS_A_*.png"s show the outputs of DHARD_DARM_240912 when changing AS_A_DC_OFFSET with a reference trace for when the offset was nominal (ASC-AS_A_DC_YAW_OFFSET = -0.15). Each trace has a marker at the two highest peaks in the ASC-DHARD power spectrum (the middle plot on the left). DTT_AS_A_neg0_05 shows the lowest value in the power spectrum compared to DTT_AS_A_neg0_10, while preserving coherence (lowest-left) and phase values (middle-rigt), compared to DTT_AS_A_0. AS_A_NDSCOPE corroborate on the times at which these measurements were done and the values for AS_A offset.

TITLE: 09/12 Day Shift: 1430-2330 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Observing at 150Mpc
INCOMING OPERATOR: Tony
SHIFT SUMMARY:

IFO is in NLN and OBSERVING (since 19:43 UTC)

It's been a good day both for observing and comissioning.

OBSERVING:

We needed to do an initial alignment after the comissioning period ended but were able to fully automatically get to NLN after that and have stayed there since.

Lockloss 17:37

COMISSIONING:

• Calibration Sweep ran successfully while IFO was thermalized - alog 80057
  • Secondary sweep with Francisco's offsets ran also (comment to the linked alog)
• SQZ Work
  • Tried to optimize squeezing with thermalized IFO, successfully done (since yesterday's SQZ optimization was not done for thermalized IFO)
  • Tried to test other PSAM settings and then lost lock in the process.
• DMT Reset/Troubleshooting
  • DMT went down and is having issues backfilling 48hrs of data. Erik and Jonathan know and are finding temp solutions while we investigate.
• IMC Gain Redistribution
  • More changes made to the gains during the Laser Noise Suppression stage. These are meant to keep IFO safer during EQs. They were tested with the first lock today and we didn't lose lock so so far, the changes worked.

Accepted SDFs attached.

LOG:

TITLE: 09/12 Eve Shift: 2330-0500 UTC (1630-2200 PST), all times posted in UTC
STATE of H1: Observing at 154Mpc
OUTGOING OPERATOR: Ibrahim
CURRENT ENVIRONMENT:
    SEI_ENV state: CALM
    Wind: 15mph Gusts, 9mph 3min avg
    Primary useism: 0.03 μm/s
    Secondary useism: 0.11 μm/s
QUICK SUMMARY:

H1 is locked and Observing for the past 4 hours.
DMT seems to be having trouble retrieving data beyond the hour for some reason.
The DMT PEM NUC trends have been replaced with a temporary ndscope.

Sheila, Ibrahim

Context: ALSY has been misbehaving (which on its own is not new). Usually, problems with ALS locking pertain to an inability to attain higher magnitude flashes. However, in recent locks we have consistently been able to reach values of 0.8-0.9 cts, which is historically very lockable, but ALSY has not been able to lock in these conditions. As such, Sheila and I investigated the extent of misalignment and mode-mismatching in the ALSY Laser.

Investgiation:

We took two references, a "good" alignment, where ALSY caught swiftly with minimal swinging, and a "bad" alignment where ALSY caught with frequent suspension swinging. We then compared their measured/purported higher order mode widths and magnitudes. The two attached screenshots are from two recent locks (last 24hrs) from which we took this data. We used the known Free Spectral Range and G-factor along with the ndscope measurements to obtain the higher order mode spacing and then compared this to our measurements. While we did not get exact integer values (mode number estimate column), we convinced ourselves that these peaks were indeed our higher-order modes (to a certain extent that will be investigated more). After confirming that our modes were our modes, we then calculated the measured power distribution for these modes.

The data is in the attached table screenshot (copying it was not very readable).

Findings:

• Both alignments were found to be pretty bad, so can't really compare to one another. Evidenced by similarity in fractional magnitude.
• Magnitude distribution in M(0,0) shows that only 70% of our power is going into the main 0,0 mode, implies a bad alignment since we're reading 0.9+ on both of these count values, and these are supposed to be normalized to 1.
• ~18% of our power is going into the first higher order mode, which implies a misalignment
• ~6.5% of our power is going into the second order mode, which implies a mode mismatch (and also some misalignment).

Next:

• Take more data points of actually good alignments that may have a higher distribution of power in its 0,0 mode (as designed). 70% is apparenltly quite bad alignment/mode-match wise
• See if there's a particular difference between different successful ALSY lock counts
• Since we were quite misaligned, do the same investigation for ALSX and guage

Investigation Ongoing

-Brice, Sheila, Camilla

We are looking to see if there are any aux channels that are affected by certain types of locklosses. Understanding if a threshold is reached in the last few seconds prior to a lockloss can help determine the type of lockloss, which channels are affected more than others, as well as

We have gathered a list of lockloss times (using https://ldas-jobs.ligo-wa.caltech.edu/~lockloss/index.cgi) with:

1. only Observe and Refined tags (plots, histogram)
2. only Observe, Refined, and Windy tags (plots, histogram)
3. only Observe, Refined, and Earthquake tags (plots, histogram)
4. Observe, Refined, and Microseism tags (note: all of these also have an EQ tag, and all but the last 2 have an anthropogenic tag) (plots, histogram)

(issue: the plots for the first 3 lockloss types wouldn't upload to this aLog. Created a dcc for them: G2401806)

We wrote a python code to pull the data of various auxilliary channels 15 seconds before a lockloss. Graphs for each channel are created, a plot for each lockloss time are stacked on each of the graphs, and the graphs are saved to a png file. All the graphs have been shifted so that the time of lockloss is at t=0.

Histograms for each channel are created that compare the maximum displacement from zero for each lockloss time. There are also a stacked histogram based on 12 quiet microseism times (all taken from between 4.12.24 0900-0930 UTC). The histrograms are created using only the last second of data before lockloss, are normalized by dividing by the numbe rof lockloss times, and saved to a seperate pnd file from the plots.

These channels are provided via a list inside the python file and can be easily adjusted to fit a user's needs. We used the following channels:

Lockloss during SQZ comissioning during a suspect ZM4 move.

Took Calibration Sweep at 13ish H1 NLN Lock.

BB Start and End: 15:27 UTC, 15:35 UTC

File Names:

Simulines GPS End and Start: 1410190636, 1410192001

File Names:

File written out to: /ligo/groups/cal/H1/measurements/DARMOLG_SS/DARMOLG_SS_20240912T153646Z.hdf5
File written out to: /ligo/groups/cal/H1/measurements/PCALY2DARM_SS/PCALY2DARM_SS_20240912T153646Z.hdf5
File written out to: /ligo/groups/cal/H1/measurements/SUSETMX_L1_SS/SUSETMX_L1_SS_20240912T153646Z.hdf5
File written out to: /ligo/groups/cal/H1/measurements/SUSETMX_L2_SS/SUSETMX_L2_SS_20240912T153646Z.hdf5
File written out to: /ligo/groups/cal/H1/measurements/SUSETMX_L3_SS/SUSETMX_L3_SS_20240912T153646Z.hdf5

Calibration Monitor Screenshot taken right after hitting run on BB attached.

Marc Daniel

We measured the gain and phase difference between the new DAC and the existing 20-bit DAC in SUS ETMX. For this we injected 1kHz sine waves and measure gain and phase shifts between the two. We started with a digital gain value of 275.65 for the new DAC and adjusted it to 275.31 after the measurement to keep the gains identical. The new DAC implements a digital AI filter that has a gain of 1.00074 and a phase of -5.48° at 1kHz, which corresponds to a delay of 15.2µs.

This puts the relative gain (new/old) to 1.00074±0.00125 and the delay to 13.71±0.66µs. The variations can be due to the gain variations in the LIGO DAC, the 20-bit DAC, the ADC or the AA chassis.

A while ago Oli found that some earthquakes cause IMC splitmon saturations, possibly causing locklosses. I asked Daniel this with respect to the tidal system to see if we could improve the offloading some. After some digging we found that some of the gains in the IMC get lowered to -32db at high power, greatly reducing the effective range of the IMC SPLITMON. He and Sheila decided that the best place to recover this gain was during the LASER_NOISE_SUPPRESSION state (575) so Sheila added some code to that state to redistribute some the gain (lines 5778 -5788): 

            self.gain_increase_counter = 0
        if self.counter ==5 and self.timer['wait']:
            if self.gain_increase_counter <7:  #icrease the imc fast gain by this many dB
                #redistribute gain in IMC servo so that we don't saturate splitmon in earth quakes, JW DS SED
                ezca['IMC-REFL_SERVO_IN1GAIN'] -= 1
                ezca['IMC-REFL_SERVO_IN2GAIN'] -= 1
                ezca['IMC-REFL_SERVO_FASTGAIN'] += 1
                time.sleep(0.1)
                self.gain_increase_counter +=1
            else:
                self.counter +=1

We tried running this, but an error in the code broke the lock. That's fixed now, the lines are commented out in ISC_LOCK and we'll try again in some other day.