I just checked the efficacy of the jitter noise cleaning.  Obviously we'd prefer to mitigate this in hardware, but it still seems useful to check up on.

There are still several vacuum pumps running near HAM1, so hopefully these jitter peaks won't be as prevalent once they get turned off in a few days. However, until then, it looks like the cleaning coefficients from before the vent are still good.  This makes some sense, in that we didn't do a lot that would change our coupling of the jitter noise into the interferometer dramatically. 

For now, I'll leave the noise subtraction as it was before the vent, with no changes.

Broadband:

Start: 1433619864 / 2025-06-10 12:44:06

Stop: 1433620174 / 2025-06-10 12:49:16

Simulines:

GPS start: 1433620215.301202

GPS stop: 1433621616.185126

2025-06-10 20:13:18,020 | INFO | File written out to: /ligo/groups/cal/H1/measurements/DARMOLG_SS/DARMOLG_SS_20250610T194958Z.hdf5
2025-06-10 20:13:18,028 | INFO | File written out to: /ligo/groups/cal/H1/measurements/PCALY2DARM_SS/PCALY2DARM_SS_20250610T194958Z.hdf5
2025-06-10 20:13:18,035 | INFO | File written out to: /ligo/groups/cal/H1/measurements/SUSETMX_L1_SS/SUSETMX_L1_SS_20250610T194958Z.hdf5
2025-06-10 20:13:18,040 | INFO | File written out to: /ligo/groups/cal/H1/measurements/SUSETMX_L2_SS/SUSETMX_L2_SS_20250610T194958Z.hdf5
2025-06-10 20:13:18,045 | INFO | File written out to: /ligo/groups/cal/H1/measurements/SUSETMX_L3_SS/SUSETMX_L3_SS_20250610T194958Z.hdf5

I'm working on going through some Observe SDFs, so that we're ready for observing soon.

• The IMC ASC PZT has been changed, so accepting that.
• A lockin oscillator in the LSC model had a ramp time change - I've reverted it.
• The CAL-INJ_TRANSIENT input switch is off, which double-disables hardware injections.  From Nov 2024 - Apr 2025, the input switch was on while the output was off.  I'm accepting that the input is off in addition to the output being off.  This matches the safe.snap.  This switch probably got left on when we last did some hardware injections - but it doesn't matter since the output is always correctly off.
• The ITMY reaction chain alignment offsets are now zero in the safe.snap file since we aligned it in vacuum.  I've accepted those values in the observe.snap file.
• I accepted the current value for the ISS' picomotor 8 speed setting.  The picomotor is disabled, it really doesn't matter at all, but this way I don't have to turn on the motor or anything.  This was last used to pico onto the ISS array last week.

Jim is currently working on going through many of the SEI SDFs.  The rest of the diffs I need to check with other commissioners to be sure about before we clear them, but I think we're getting close to having our SDFs cleared!

I went down to end Y to retrieve the usb stick that I remotely copied the c:\slowcontrols directory on h1brsey to, and also to try to connect h1brsey to the kvm switch in the rack. I eventually realized that what I thought was a vga port on the back of h1brsey was probably not, and instead I found this odd seeming wiring connected from what I am guessing is a hdmi or dvi port on the back of h1brsey, to some kind of converter device, then to a usb port on a network switch. I'm not sure what this is about, so I am attaching pictures.

Tue Jun 10 10:12:01 2025 INFO: Fill completed in 11min 57secs

around 11:15 local I observed an outlier on the VEA temperature trend. Zone 2 (Y output) appeared to be running beyond its norm. Because Eric was troubleshooting a heater coil in this particular zone (per WP 12589) this morning, this was not terribly surprising, but I decided to investigate anyway. According to FMCS, heating stage 1 was manually forced on. It appeared to hold at least 40% heating command in this condition. I don't recall a reason for this being manually enabled, nor did Eric. Since disabling it, heating command dropped from 40% to 0 and supply temperatures have fallen from 73F to 58. This might cause a sharper than usual course correct, but I would expect zone 2 to fall in line with the rest of the VEA by days end.

E. Otterman T. Guidry

Sheila, Elenna, Camilla

Sheila was questioning if something is drifting for us to need an initial alignment after the majority of relocks. Elenna and I noticed that BS PIT moves a lot both while powering up /moving spots and while in NLN. Unsure from the BS alignment inputs plot what's causing this.

This was also happening before the break (see below) but the operators were similarly needing more regular initial alignments before the break too.  1 year ago this was not happening, plot.

• Now:
  • While locking (Power up state #500 to NLN #600) BS PIT moves 40urad  plot
  • During a 2hr lock BS PIT moves 13urad plot
• Before Break:
  • While locking (Power up state #500 to NLN #600) BS PIT moves 43urad  plot
  • During a 4hr lock BS PIT moves 20urad plot

Last night Corey ran a simulines measurement shortly into the start of the lock, 84908. This measurement was mainly done as a test to confirm simulines wasn't breaking the lock, so we were not well thermalized. We can first report that simulines did not break the lock, so the previous lockloss that occurred during the simulines measurement was likely unrelated to simulines itself.

GPS start of measurement: 1433563079

I did a time machine on the calibration monitor screen for the GPS start of the measurement.

I was able to generate a report by running pydarm report --skip-gds

I have attached the generated PDF from this report, and I took a screenshot of the first page since there is an interesting result. The sensing function shows a large spring, which is probably due to the fact that we are operating with a significant SRCL offset, which is designed to compensate for 1.4 degrees of SRCL detuning, 84794.

However, it is important to remember that this calibration measurement was made while the IFO was unthermalized, but the SRCL offset measurement I linked here was performed with the IFO thermalized.

The results from this calibration report are saved in /ligo/groups/cal/H1/reports/20250610T035741Z/

Camilla and I swept the LVEA this morning between locks. The VAC team still has HAM1 pumps to turn off and valve in, as well as a setup with a laptop on the Y arm near the manifold, and a turbo on the output arm. They will get to this later in the day. Other notable things found on out walk through:

• Unplugged RF analyzer, SR785  by PSL racks
• Unplugged two extension cords under HAM2/3
• Unplugged dust monitor by BSC8 and moved the network cable to the dust monitor in the beir garten.
• HAM4 cable mechanically grounding to HEPI crossbeam on -Y side.
• Moved a few accelerometer cables draped over HEPI cross beams.

The heating coil in zone 2A of the LVEA was repaired this morning. There will be some variation in the trending while the PI loop adjusts. 

The CDS SDF has had 1 diff for the past 4 days because the second outlet of the EY Tripplite power-strip was turned on around 9am Friday 06jun2025. Strangely EY's lights were not turned on at all on Friday, so either this was a mistake for something had been plugged into the outlet ahead of time.

Asking around the control room, no one knows why this was turned on. Because driving to EY and entering the VEA is invasive on locking, we elected to turn it off for now.

Following the drop in LN2 level over the last few days (see plot) we decided to bump up the alarm level from 80% to 85% on all CPs to give the vacuum team an earlier warning that the PID controls system is not able to maintain a nominal level.

alarms was restarted 08:16 with the following change

Channel name="H0:VAC-LX_CP2_LT150_PUMP_LEVEL_PCT" low="8.5e+01" high="9.9e+01" description="CP2 Pump LN2 Level">
Channel name="H0:VAC-MY_CP3_LT200_PUMP_LEVEL_PCT" low="8.5e+01" high="9.9e+01" description="CP3 Pump LN2 Level">
Channel name="H0:VAC-MX_CP5_LT300_PUMP_LEVEL_PCT" low="8.5e+01" high="9.9e+01" description="CP5 Pump LN2 Level">
Channel name="H0:VAC-MX_CP6_LT350_PUMP_LEVEL_PCT" low="8.5e+01" high="9.9e+01" description="CP6 Pump LN2 Level">
Channel name="H0:VAC-EY_CP7_LT400_PUMP_LEVEL_PCT" low="8.5e+01" high="9.9e+01" description="CP7 Pump LN2 Level">
Channel name="H0:VAC-EX_CP8_LT500_PUMP_LEVEL_PCT" low="8.5e+01" high="9.9e+01" description="CP8 Pump LN2 Level">
 

TITLE: 06/10 Day Shift: 1430-2330 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Planned Engineering
OUTGOING OPERATOR: Ibrahim
CURRENT ENVIRONMENT:
    SEI_ENV state: CALM
    Wind: 4mph Gusts, 1mph 3min avg
    Primary useism: 0.02 μm/s
    Secondary useism: 0.18 μm/s
QUICK SUMMARY:
H1 was in IDLE when I arrived.
I will start trying to lock now.
 

Headline summary: We are very nearly back to NLN, only prevented in returning by the violin modes which are too high to engage OMC whitening. We have not yet been able to calibrate because of a very fast lockloss of unknown source.

The alog was down for most of the afternoon and evening, so I will do my best here to copy mesages from the mattermost chat, which served as the temporary alog.

Minor struggles in returning to full lock:

• The first lock, we did have to by-hand reduce the CARM offset to go to CARM_TO_REFL successfully.
• We reset the green references after ASC converged.
• The next lock (after setting green references and doing an initial alignment) this worked automatically, so no changes were made to guardian.
• MICH P rang up one lockloss, so I reverted the MICH ASC control to an older high bandwidth design. We will need to check the impact on the noise later

Once we achieved full power, we proceeded to try to solve some of the final instabilities leftover from last week. Changes made to avoid locking stability problems:

• New order of states. We now run: Max Power > Low Noise Coil Drivers > Transition from ETMX > Low noise ESD ETMX > Low Noise ASC > Low noise Length Control
  • we got a lot of saturation warnings because of the amplitude of the ADS lines in coil drivers, so the guardian now turns OFF the lines completely, and then turns them back on in lownoise ESD
  • I didn't change state numbers, but I changed the order, and some of the weights to ensure this is the path taken
  • this was tested successfully
• We no longer engage the DHARD P boost in FM8. This may have some effect on the noise which must be checked later
• We tested laser noise suppression; there are no problems
• While in OMC whitening, I ran a quick DARM OLG with Fransisco. There is slightly less phase, but overall it looks fine, at least compared to the reference. However, we don't have a lot of phase margin in general, should we fix that?

The plan was to try testing simulines again, however! We have had multiple very fast locklosses with no known origin. Two have happened shortly after arriving at OMC whitening. These are not coming from ASC and I don't see any ringup in DARM or LSC loops.

I noticed that the LLCV is railing at its top value, 100% open, it can't open no more.  This is a known issue, but it appears as if the valve is reaching 100% sooner than expected, meaning when the tank is almost half full.  First, I'm going to try a re-zero the LLCV actuator and await for the results.  First attachment is a 2 day plot of LLCV railing today and yesterday.  The second plot is a 3 year history looking at the tank level and the LLCV, it rails at 100% a few times.

(This is Oli)

Once we had been at 60W for two hours, I started a calibratoin measurement. I started with Simulines since yesterday I had gotten a broadband measurment done (84808). A couple minutes into the measurement, we lost lock. The cause is unknown, but I've attached the output for the simulines measurement (txt).

[Jenne Louis Matt]

The change in the filters used by calibration created a 10% calibration error. Louis is trying to fix this but in an effort to have a way to revert to the previous filters without losing lock Jenne came up with a cdsutils way to revert back. Essentially it toggles off the new filters ('H1:OMC-DCPD_A0 FM10 H1:OMC-DCPD_B0') FM10 and steps the demod phase ('H1:OMC-LSC_PHASEROT') in steps of 1 degree, 77 times, with a 0.065 sec delay (77steps/5seconds) between each step. The filter toggles have a 5 second ramp time, which informs the step delay in the cdsutils step, and the 77 degrees is the difference from the old demod phase and the new. Hopefully this avoids a lockloss in the event we are to revert, but may not. *fingers crossed*

Here is the command:

UPDATE:

It worked :) anti-alias filters off and OMC-LSC phaserot returned to nominal