TITLE: 11/26 Day Shift: 1530-0030 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Observing at 146Mpc
OUTGOING OPERATOR: None
CURRENT ENVIRONMENT:
SEI_ENV state: CALM
Wind: 7mph Gusts, 4mph 3min avg
Primary useism: 0.01 μm/s
Secondary useism: 0.17 μm/s
QUICK SUMMARY:
TITLE: 11/26 Eve Shift: 0030-0600 UTC (1630-2200 PST), all times posted in UTC
STATE of H1: Planned Engineering
INCOMING OPERATOR: None
SHIFT SUMMARY: We had 2 locklosses, the first was easy to recover from, the second is still in progress. We're at MAX_POWER right now.
LOG:
| Start Time | System | Name | Location | Lazer_Haz | Task | Time End |
|---|---|---|---|---|---|---|
| 00:16 | PEM | Rene, Alicia | CER | N | Setup measurement, huddle test | 00:33 |
| 00:20 | ISC | Kar Meng | Optics lab | LOCAL | OPO work | 01:13 |
| 00:21 | ISC | Marc | Optics lab | LOCAL | Help with osciliscope issue | 00:59 |
| 00:52 | PEM | Robert, Sam | EndX | N | Setup measurement | 01:20 |
04:10 UTC NLN
04:30 UTC We went into Obseving after I cleared a leftover EX PEM EXC
01:21 UTC lockloss
It looked just like the previous lockloss but larger, it was an ETMX glitch a 1/4 sec before the lockloss.
03:12 UTC lockloss at LOW_NOISE_ESD_ETMY
[Alicia Calafat, Joan-Rene Merou, Sheila Dwyer] Lock-loss events at the AS port can send short, high-power optical pulses towards the photodiodes. At full-power operation these pulses can carry of order tens of joules in a few milliseconds, which is potentially hazardous for the InGaAs diodes if not mitigated. The fast shutter in HAM6 (TOASTR) protects the AS port by inserting a mirror into the beam and dumping the pulse into a dedicated beam dump.
Previous aLOGs have highlighted the importance of understanding the fast shutter response during lock losses:
- In November 2024, "Fast shutter bouncing happens with an inconvenient timing" (aLOG 81130) reported a lock loss around tGPS ≃ 1415043099 where the fast shutter, after closing, briefly bounced open again roughly when the power into HAM6 reached its maximum (~760 W). The energy deposited into HAM6 was estimated to be ≃ 17 J, with ≃ 12 J leaking past the shutter due to the bounce.
- In June 2025, "OPS Monday day shift start" (aLOG 85393) described a lock loss at ≃ 100 kW circulating power that did not trigger the fast shutter. The maximum power at HAM6 (~1.4 W) stayed below the analogue fast shutter trigger threshold (≃ 3-4 W). The same PEM channel was used to estimate the power incident on HAM6, and it was noted that the calibration in this configuration is a factor of 10 smaller than in observation mode because the 90:10 beam diverter was open.
These and related reports motivate a more systematic study of the timing of the fast shutter response during lock losses, in particular the trigger-to-10-percent rise time inferred from the HAM6 PEM channel. As a secondary quantity, we also keep track of the energy deposited in HAM6 to flag potentially dangerous high-energy pulses. Data and calibration
The analysis is based on a list of lock-loss events stored in a JSON file (index.cgi.json), each with an event id, a nominal GPS time and a refined GPS time.
For each event, the script reads the PEM channel
H1:PEM-CS_ADC_5_19_2K_OUT_DQ
at 2048 Hz over a symmetric window around the refined GPS time. The channel is recorded in ADC counts and converted to physical power in watts with a single calibration factor CALIBRATION_W_PER_COUNT, which depends on the optical configuration:
- Observation mode (beam diverter in nominal configuration): about 0.177 W/count, consistent with the estimates in aLOG 81130.
- Configuration with the 90:10 beam diverter open: the PEM sees about ten times less power and the effective calibration is reduced by a factor of 10, i.e. 0.0177 W/count, as explicitly stated in aLOG 85393.
For the present study the default calibration is CALIBRATION_W_PER_COUNT = 0.0177, corresponding to the beam diverter open configuration. All reported powers are in watts and all integrated quantities are in joules. If one wants to compare directly with the energies quoted in aLOG 81130, the same script can be re-run with CALIBRATION_W_PER_COUNT = 0.177, in which case all energies scale up by a factor 10. Definition of peak, trigger level and 10-percent point
For each event the script computes:
- The peak power at HAM6, defined as the maximum of the calibrated power time series P(t) in the analysis window (peak_value_W, at time peak_time_gps).
- A pre-event plateau level, defined as the median of P(t) before the peak.
- A 10-percent-of-peak level, ten_percent_power_W = 0.1 x peak_value_W, and the corresponding time on the rising edge, rise_10pct_time_gps (first sample where P(t) ≥ 0.1 x peak_value_W and t ≤ peak_time_gps).
- An effective trigger level, trigger_level_W, used as a proxy for the fast-shutter trigger threshold. By default this is 0.2 W, but for a handful of events it is raised to a larger value to avoid small pre-pulses (see below). The trigger time trigger_time_gps is defined as the first sample where P(t) ≥ trigger_level_W on the rising side.
- The effective trigger-to-10-percent rise time, trigger_to_10pct_time_s = rise_10pct_time_gps - trigger_time_gps, which quantifies how quickly the HAM6 power grows from the effective trigger level to 10 percent of its peak during the lock loss.
- The deposited energy in the main pulse, integrated_energy_J, computed by integrating P(t) from the trigger up-crossing to the first down-crossing of the same trigger level after the peak, using a trapezoidal rule in time. Per-event trigger tuning
In most lock losses the nominal trigger level of 0.2 W lies well below the main peak and above any pre-event fluctuations, so the first up-crossing of 0.2 W is a good proxy for when the shutter would be triggered.
However, in several events the 0.2 W line is already crossed by small bumps before the main pulse. In these cases the nominal 0.2 W crossing is clearly too early compared to the onset of the main lock-loss pulse, and the resulting trigger_to_10pct_time_s would not characterize the main burst but instead include a long interval over a small pre-pulse.
To avoid this, the script allows per-event overrides of trigger_level_W. For a small number of GPS times, the trigger level is manually raised so that it sits above the pre-pulse but still below the main peak. The set of events with custom trigger levels is encoded in the CUSTOM_TRIGGER_LEVELS dictionary in the script and currently includes events at:
- GPS 1443656698
- GPS 1443956187
- GPS 1444867592
- GPS 1445889945
- GPS 1446288577
- GPS 1446552568
- GPS 1446642040
For these events, the diagnostic plots show the higher trigger level as a horizontal line and use its first up-crossing to define trigger_time_gps. CSV summary
All per-event measurements are written to: outputs/lockloss_log.csv with one row per lock loss. The columns are:
- event_id: string identifier of the event copied from index.cgi.json.
- event_gps: refined GPS time of the lock loss (s).
- peak_time_gps: GPS time at which the peak power is reached (s).
- peak_value_W: peak power at HAM6 (W).
- ten_percent_power_W: 10 percent of the peak power (W).
- trigger_time_gps: GPS time at which P(t) first reaches the effective trigger level (s). For most events the trigger level is 0.2 W; for a handful of events it is raised as described above.
- rise_10pct_time_gps: GPS time at which P(t) first reaches 10 percent of the peak on the rising side (s).
- trigger_to_10pct_time_s: difference between rise_10pct_time_gps and trigger_time_gps (s).
- integrated_energy_J: time integral of P(t) between the trigger up-crossing and the first down-crossing after the peak (J).
To give a compact overview of the CSV content, the table below shows the first five rows of the current file, illustrating the typical numerical values one obtains:
| event_id | event_gps [s] | peak_time_gps [s] | peak_value_W [W] | ten_percent_power_W [W] | trigger_time_gps [s] | rise_10pct_time_gps [s] | trigger_to_10pct_time_s [s] | integrated_energy_J [J] |
|---|---|---|---|---|---|---|---|---|
| 1442831740 | 1442831739.506836 | 1442831739.550293 | 76.23296356201172 | 7.623296356201172 | 1442831739.5288086 | 1442831739.5410156 | 0.01220703125 | 0.7808257855358534 |
| 1442889453 | 1442889452.898926 | 1442889452.9663086 | 61.84770584106445 | 6.184770584106445 | 1442889452.8920898 | 1442889452.9282227 | 0.0361328125 | 1.674310484304442 |
| 1442904451 | 1442904451.206055 | 1442904451.2641602 | 81.97347259521484 | 8.197347259521484 | 1442904451.2441406 | 1442904451.255371 | 0.01123046875 | 0.8560717486398062 |
| 1442926321 | 1442926320.563965 | 1442926320.625 | 73.39449310302734 | 7.339449310302735 | 1442926320.5576172 | 1442926320.5947266 | 0.037109375 | 1.6212408712308388 |
| 1443044104 | 1443044104.236328 | 1443044104.3188477 | 66.14673614501953 | 6.614673614501953 | 1443044104.227539 | 1443044104.2773438 | 0.0498046875 | 1.7385223870514892 |
- GPS 1443956187, trigger level raised to 0.6 W:
- GPS 1444867592, trigger level raised to 1.0 W:
- GPS 1445889945, trigger level raised to 0.3 W:
- GPS 1446288577, trigger level raised to 2.5 W:
- GPS 1446552568, trigger level raised to 0.5 W:
- GPS 1446642040, trigger level raised to 8.0 W:
Taken together, these examples show that a single nominal trigger level of 0.2 W is adequate for the majority of the sample, but a small number of events benefit from per-event tuning to avoid contamination from pre-pulses or slow ramps when measuring the trigger-to-10-percent rise time.
Histogram of trigger-to-10-percent rise times
The second plot, produced as
Because the PEM channel is sampled at 2048 Hz, all trigger-to-10-percent times fall on a discrete grid T = N/2048 s. The discrete histogram shows that only a small set of such N values occur frequently, reflecting the repeatable shape of the fast-shutter pulse in this configuration. The red portions highlight that only a small subset of events required raising the trigger level to avoid pre-pulses; the bulk of the sample is well described by the nominal 0.2 W level.
TITLE: 11/26 Day Shift: 1530-0030 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Planned Engineering
INCOMING OPERATOR: Ryan C
SHIFT SUMMARY: Maintenance day went pretty smoothly and wrapped up mid-morning. After running an alignment, locking went smoothly, but H1 lost lock after 1 minute at low noise. Relocking after that went smoothly also, but took just a bit longer. Since then, PEM measurements have been ongoing and H1 has been locked for just over 2 hours.
LOG:
| Start Time | System | Name | Location | Lazer_Haz | Task | Time End |
|---|---|---|---|---|---|---|
| 15:56 | FAC | Ken | LVEA | N | Outlet work BSC1/2 | 18:09 |
| 15:56 | FAC | Richard | LVEA | N | Showing Ken the outlet | 16:13 |
| 15:59 | FAC | Eric | MER | N | Replacing heating element | 16:28 |
| 16:14 | FAC | Nellie | EY | N | Technical cleaning | 17:22 |
| 16:16 | CDS | Erik | Remote | N | Rebooting h1susauxe{x,y} | 16:17 |
| 16:20 | VAC | Gerardo | EX | N | Turning on compressor | 18:01 |
| 16:26 | FAC | Kim | EX | N | Technical cleaning | 17:53 |
| 16:28 | FAC | Eric | Site | N | Running fire pumps | 17:07 |
| 16:29 | CDS | Fil | LVEA | N | Pulling JAC cables [HAM1/2 to SAFE] | 18:59 |
| 16:30 | VAC | Jordan | LVEA | N | Measurements near Y-BTM | 16:40 |
| 16:47 | CDS | Marc | LVEA | N | Pulling JAC cables | 18:59 |
| 16:54 | CDS | Daniel | LVEA | N | Pulling JAC cables | 18:59 |
| 16:59 | VAC | Jordan | EX | N | Compressor | 18:01 |
| 17:03 | CDS | Jackie | LVEA | N | Pulling JAC cables | 18:59 |
| 17:34 | FAC | Richard | LVEA | N | Checking on Ken | 17:43 |
| 17:35 | FAC | Nellie | FCES | N | Technical cleaning | 18:31 |
| 18:10 | FAC | Richard | LVEA | N | Taking pictures | 18:22 |
| 18:13 | VAC | Jordan | LVEA | N | Measurements at HAM6 septum | 18:18 |
| 18:20 | FAC | Kim | LVEA | N | Technical cleaning | 19:24 |
| 18:31 | FAC | Nellie | LVEA | N | Technical cleaning | 19:16 |
| 18:46 | PEM | Robert, Rene, Alicia | CER | N | Setting up magnetometers | 19:46 |
| 18:55 | ISC | Keita, Kar Meng | Opt Lab | N | OPO work | 19:35 |
| 19:25 | VAC | Jordan, Gerardo | EX | N | Shutting down compressor | 19:53 |
| 20:57 | ISC | Kar Meng | Opt Lab | Local | OPO work | 00:03 |
| 21:21 | CDS | Jackie | MY | N | Delivering parts | 21:57 |
| 22:41 | ISC | Sheila | Opt Lab | Local | OPO work | 23:08 |
| 00:16 | PEM | Rene, Alicia | CER | N | Setup measurement, huddle test | 00:33 |
| 00:20 | ISC | Kar Meng | Optics lab | LOCAL | OPO work | Ongoing |
| 00:21 | ISC | Marc | Optics lab | LOCAL | Help with osciliscope issue | Ongoing |
TITLE: 11/26 Eve Shift: 0030-0600 UTC (1630-2200 PST), all times posted in UTC
STATE of H1: Planned Engineering
OUTGOING OPERATOR: Ryan S
CURRENT ENVIRONMENT:
SEI_ENV state: CALM
Wind: 5mph Gusts, 3mph 3min avg
Primary useism: 0.01 μm/s
Secondary useism: 0.21 μm/s
QUICK SUMMARY:
In prep for the upcoming CDS upgrades and vent Ryan, Jennie, and I went through the safe SDFs and accepted any values we thought needed it. We accepted all of the sus alignment sliders and checked on things like th IMC PZTs. The HWS had the center cross positions different, accepted. The ZM5 SAMS servo limit was also accepted.
We did our best combing through other subsystems and checking on both monitored and unmonitored channels, and they looked good to our eyes by either being automation controlled or reverted in SDF revert.
Tue Nov 25 10:08:11 2025 INFO: Fill completed in 8min 7secs
Gerardo confirmed a good fill curbside.
Last night I ran a longer version of the full magnetic injection suite starting at about 03:10 UTC, and it finished at 07:33 UTC. This used the same parameters as last week's run, except I doubled the injection time to 5 minutes each.
Exact times and injection parameters are in the usual log directory for the magnetic injections: /ligo/www/www/exports/pem/WeeklyMagneticInjection/logs/1448075483.txt
The last batch of injections (all 7 of the ones at EY E-bay) mistakenly overlapped with a scheduled SQZ script, so last night I re-ran these between 05:29 and 06:06 UTC.
Analysis results and plots can be found here: https://ldas-jobs.ligo.caltech.edu/~ryan.short/pem/Weekly_Mag_Inj/H1_Injection_Results/O4/20251125_1448075483/
[Dave, Erik]
h1susauxey and h1susauxex were rebuilt using RCG version 5.5.2 and restarted.
TITLE: 11/25 Day Shift: 1530-0030 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Planned Engineering
OUTGOING OPERATOR: None
CURRENT ENVIRONMENT:
SEI_ENV state: CALM
Wind: 4mph Gusts, 3mph 3min avg
Primary useism: 0.01 μm/s
Secondary useism: 0.21 μm/s
QUICK SUMMARY: H1 is observing and has been locked for almost 13 hours. In and out of observing overnight due to PEM and SQZ tests. DIAG_MAIN reports the CO2 lasers aren't at their nominal power, which I know was changed as part of a script overnight. Maintenance day today; the list seems relatively light.
Lost lock at 15:58 UTC, assuming due to people out in the LVEA near BSC1/2.
Workstations were updated and rebooted. This was an OS packages update. Conda packages were not updated.
Kevin, Sheila, help from TJ and others
I started a script running on my nomachine session that should start a 10kHz ADF sweep at 11, step down the CO2s at around 12:30, measure nlg and rerun the ADF sweep at 1:30 and again at 3am. If the IFO stays locked through all this the CO2s will be set back to normal at 4:30 am. If the IFO unlocks the script will quit and the CO2s will be reset by the guardians.
At some point within the last year, both the X and Y-axis accelerometers (PEM-CS_ACC_LVEAFLOOR_HAM1_X and Y) were kocked off (pictured here) the small metal cube they were mounted to. I reattached them as of Nov 11, 2025. I believe the capacitor position sensor box was pushed back into the accelerometers which knocked them off. Image 3 shows where the CPS box is in relation to HAM1 (circled in red) and image 4 shows where it is in relation to the accelerometers.
Additionally, two other accelerometers have been remounted with epoxy in August: PEM-CS_ACC_BEAMTUBE_SRTUBE_X (remounted August 5, 2025) and PEM-CS_ACC_BEAMTUBE_YMAN_X (remounted August 12, 2025). Both had fallen off the beamtube and had been hanging in the air for an unknown amount of time until someone noticed.
The HAM 1 floor accelerometers appear to have been moved on or around April 18, 2025 during the HAM1 work during the break between O4c.1 and O4c.2. The coherence between the two signals dramatically changes character after that date. I attach some plots of the coherence between accelerometers the day after you repositioned them, as well as data from 0000-0100 UTC on a few example days. I'm not sure that it was moved exactly on April 18, but the coherence data begins to differ from the reference on that date.
Some DRMI locking info
MICH, PRCL, SRCL filter banks during the "acquire DRMI 1f" state before the lock is grabbed.
OLGs for MICH, PRCL, SRCL after 1F acquisition, DRMI ASC engaged.
PRMI OLGs
PRCL and MICH filter banks while PRMI is locked before PRMI ASC is turned on.
15:33 UTC GRB-Short E619679