Channels not found list attached as a picture.

I have attached a screenshot of the broadband measurement from this morning. It shows that the calibration uncertainty is within +-2%, which means that our new calibration is excellent!

For those who want to plot the latest PCAL broadband, you can use a template that I have saved in /opt/rtcds/userapps/release/cal/h1/dtt_templates/PCAL_BB_template.xml (aka [userapps] cal/h1/dtt_templates/)

In order to use this template, you must find the GPS time of the start of the broadband measurement, which I found today by converting the timestap in Tony's post above into GPS time. This template pulls data from NDS2 because it uses GDS, so you will also need to go to the "Input" tab, and put your current GPS time in the "Epoch stop" entry that is within the "NDS2 selection" box. The current time will hopefully be after the start time of the broadband measurement, so that will ensure that the full span of the data you need is requested from NDS2. If you don't do this, the template will give you an error if you try to run.

Unfortunately, since we don't want the ifo trying to relock all night if we lose lock, I have to select DOWN, but that means that the request for ISC_LOCK is not in the right spot for us to stay Observing. So we won't be Observing overnight, but will be locked (at least until we lose lock, then we will be in DOWN)

Here is some more information about some of the problems Oli faced last night and how they were fixed.

PM1 saturations:

Unfortunately, this problem was an error on my part. Yesterday, Sheila and I were making changes to the DC6 centering loop, which feeds back to PM1. As a part of updating the loop design, I SDFed the new filter settings, but inadvertently also SDFed the input of DC6 to be ON in safe. We don't want this; SDF is supposed to revert all the DC centering loop inputs to OFF when we lose lock. Since I made this mistake, a large junk signal came in through the input of DC6 and then was sent to the suspension, which railed PM1 and then tripped the HAM1 ISI. Once I realized what was happening, I logged in and had Oli re-SDF the inputs of DC6 P and Y to be OFF.

You can see this mistake in my attached screenshot of the DC6 SDF; I carelessly missed the "IN" among the list of differences.

DHARD P filter engagement:

In order to avoid some control instabilities, Sheila and I have been reordering some guardian states. Specifically, we moved the LOWNOISE ASC state to run after LOWNOISE LENGTH CONTROL. This should not have caused any problems, except Oli noticed that we lost lock twice at the exact same point in the locking process, right at the end of LOWNOISE ASC when the DHARD P low noise controller is engaged, FM4. I attached the two guardian logs Oli sent me demonstrating this.

I took a look at the FM4 step response in foton, and noticed that the step response is actually quite long, and the ramp time of the filter was set to 5 seconds. I also looked at the DARM signal right before lockloss, and noticed that the DARM IN1 signal had a large motion away from zero just before lockloss, like it was being kicked. My hypothesis is that the impulse of the new DHARD P filter was kicking DARM during engagement. This guardian state used to be run BEFORE we switched the coil drivers to low bandwidth, so maybe the low bandwidth coil drivers can't handle that kind of impulse.

I changed the ramp time of the filter to 10 seconds, and we proceeded through the state on the next attempt just fine.

We should still take another measurement when we are more thermalized, but just after 40 minutes of NLN the broadband results look good. I also checked the calibration line grafana page, and all the uncertainties are within 5%. Most are within 2-3% except the 33 Hz line which is at 4%.

I've loaded in the filter changes in the CALCS model

We confirmed this new calibration is good in this alog: 84963.

I am going to add a few more details and thoughts about this calibration here:

Currently, we are operating with a digital offset in SRCL, which is counteracting about 1.4 degrees of SRCL detuning. Based on the calibration measurement, operating with this offset seems to have compensated most of the anti-spring that has been previously evident in the sensing function. However, our measurements still show non-flat behavior at low frequency, which was actually best fit with a spring (aka "pro-spring"). However, the full behavior of this feature appears more like some L2A2L coupling. It may be worthwhile to test out this coupling by trying different ASC gains and running sensing function measurements.

Joe pointed out to me this morning in the cal lines grafana, and we also saw in the very early broadband measurement last night (84959), that the calibration looks very bad just at the start of lock, with uncertainties nearing 10%. This seems to level off within about 30 minutes of the start of the lock. Since that is pretty bad, we might want to consider what to do on the IFO side to compensate. Maybe our SRCL offset is too large for the first 30 minutes of lock, or there is something else we can do to mitigate this response.

Just watching the grafana for this recent lock acquisition, it took about 1 hour for the uncertainty of the 33 Hz line to drop from 8% to 2%.

We should be careful with the PRG comparison- I am not sure the change in the PRG is "real" because before the vent, we had not updated the PRG calibration to account for reduced power on IM4 trans that occurred after the O4a/O4b break. However, I did update the PRG calibration last week to account for it. It could still be correct; one reason why I didn't update the PRG calibration before was because it seemed "good enough", but I'm not sure if it's good enough to a few percent to make this kind of comparison.

2 Seconds of data in this data span is missing.
Our tools can't pull the entire time for this No SQZ ing time.
Johnathan has given us the 2 seconds that are missing from the data 12 minute data stretch.

"I don't have good news for you.  There is a 2s gap in there at 1433627912-1433627913 on H-H1_llhoft.  The H-H1_HOFT_C00 is worse, I don't see frames in the 1433627.... range at all." ~ Johnathan H.

We were able to salvage 674 seconds from this time that can be useful. 
Useful GPS time: 1433627238 -1433627912

h1tcshws sdfs attached.

Reverted BaffePDs to what they were 3 months ago, attached, unsure why they would have changed.

SQZ ADF frequency sdfs accepted, we do not know why these would have been accepted at the values -600 that they've been at some of the past 2 weeks.

ASC SDFs were from changes to DC6, cleared.

Cleared these SDFs for the phase changes for LSC REFL A and B.

I trended these, and see that FM2 was on in all three of these last time we were in observing, so these must have been erroneously accepted in the observing snap.

I also accepted the HAM7_DK_BYPASS time from 1200 to 999999 after checking with Dave, as attached.

These large BS PIT changes began 5th to 6th July 2024 (plot). This is the day shift from the time that the first lock like this happened 5th July 2024 19:26UTC (12:26PT): 78877 at the time we were doing PR2 spot moves. There also was a SUS computer restart 78892 but that appeared to be a day after this started happening.

Sheila, Camilla

This reminded Sheila of when we were heating a SUS in the past and causing the bottom mass to pitch and the ASC to move the top mass to counteract this. Then after lockloss, the bottom mass would slowly go back to it's nominal position.

We do see this on the BS since the PR2 move, see attached (top 2 left plots). See in the green bottom mass oplev trace, when the ASC is turned off on lockloss, the BS moves quickly and then slowly moves again over the next ~30 minutes, do not see simular things on PR3. Attached is the same plot before the PR2 move. And below is a list of other PR2 positions we tried, all the other positions have also made this BS drift. The total PR2 move since the good place is ~3500urad in Yaw.

• Different time May 21st to 24th 2024:
  • BS Oplev Drift
  • Plot shows 30urad M1 drift
  • PR2 Alignment Sliders P: 1435, Y: 1130
• Pre July 5th 2024:
  • No BS Oplev Drift
  • Plot shows 5urad M1 drift
  • PR2 Alignment Sliders P: 1565, Y: 3210
• July 5th 2024 to 6th Feb 2025:
  • BS Oplev Drift
  • Plot shows 50urad M1 drift
  • PR2 Alignment Sliders P: 1535, Y: 2785
• 6th Feb 2025 to 10th Feb 2025:
  • BS Oplev Drift
  • Plot shows 30urad M1 drift
  • PR2 Alignment Sliders P: 1480, Y: 1195
• 10th Feb 2025 to now:
  • BS Oplev Drift
  • Plot shows 30-40urad M1 drift
  • PR2 Alignment Sliders P: 1430, Y: -245

To avoid this heating and BS drift, we should move back towards a PR2 YAW of closer to 3200. But, we moved PR2 to avoid the spot clipping on the scrapper baffle, e.g.  77631, 80319, 82722, 82641.

I did a bit of alog archaeology to re-remember what we'd done in the past.

• In August of 2015, we found that we were struggling with PR3 pitch alignment jumping, then cooling down upon lockloss.  Alog 20268 talks about the implementation of the lock loss compensation, which first appeared in ISC_DRMI guardian in rev 11228.
• At some point (I didn't dig to find out when precisely), we also implemented the same filters for BS pitch.
• By Jan 2020, both BS and PRM had the soft ASC turn-off.
• In Jan 2020, ISC_DRMI rev 20905 we removed this soft ASC turn-off for both PR3 and BS.  The referenced alog 54709 notes that we shouldn't need those anymore, since we had installed wire heating baffles, to prevent the wires from being illuminated and heating up.
• We haven't had the soft turn-off filters in use since 2020, about 3 months before the end of O3b.  This may be why Camilla saw that we were seeing BS drift at the end of O3b.
• Perhaps our alignment during O4, until we moved the PR spots in May 2024, was such that we weren't susceptible to this wire heating.
• I don't think PR3 is seeing the same kind of trouble that it did back in 2015 upon lockloss, so I think its wire heating baffles are working as designed, so no need to make any changes to the PR3 controls.
• Sheila made the point that because we unclipped some of the +Y side of the beam (without moving the spot on the BS), maybe there is a bit more light that is illuminating the barrel of the BS or getting to the wires.  Or, something?  Without having looked at the actual drawings, I could imagine that the wire heating baffles are working better on PR3 than they are on the BS, because we hit PR3 much closer to normal incidence, whereas with the BS the light could be sneaking around the baffles.  Robert thinks that light could get inside the cage baffle and reflect around and be hitting and heating the wires.
• All of this seems to say that we should re-implement the soft ASC turn-off for the BS. I had a quick look at the 1/e time for the BS to move after lockloss (it's about 241 seconds), and the 1/e time for the filters (about 240 seconds, despite my quoting in alog 54706 that they were 25 min filters (2*pis are hard!)

To put back the soft turn-off of the BS ASC, I think we need to:

• Disable the BS M1 ASC lockloss trigger.  Jeff reminded me that this would foil my plans, since it turns off the ASC signals to the EUL2OSEM matrix.  This will mean that neither the Pit nor the Yaw BS M1 signals will be shut off by the lockloss trigger.  To disable, we'll need to set H1:SUS-BS_M1_TRIG_ASC_ENABLE to zero (which means that the ASC signals will always be passed to the EUL2OSEM matrix).  I don't think this is in guardian anywhere, so we should only need to change it and then accept in safe and observe snap files.
• Change ISC_DRMI around line 66 such that BS pit gain is not set to zero.  Also, have it turn off FM1 in addition to turning off the input.
• Change ISC_DRMI around line 141 to not hit the BS pit RSET button.

Camilla made the good point that we probably don't want to implement this and then have the first trial of it be overnight.  Maybe I'll put it in sometime Monday (when we again have commissioning time), and if we lose lock we can check that it did all the right things.

I've now implemented this soft let-go of BS pit in the ISC_DRMI guardian, and loaded.  We'll be able to watch it throughout the day today, including while we're commissioning, so hopefully we'll be able to see it work properly at least once (eg, from a DRMI lockloss).

This 'slow let-go' mode for BS pitch certainly makes the behavior of the BS pit oplev qualitatively different. 

In the attached plots, the sharp spike up and decay down behavior around -8 hours is how it had been looking for a long time (as Camilla notes in previous logs in this thread).  Around -2 hours we lost lock from NomLowNoise, and while we do get a glitch upon lockloss, the BS doesn't seem to move quite as much, and is mostly flattened out after a shorter amount of time.  I also note that this time (-2 hours ago) we didn't need to do an initial alignment (which was done at the -8 hours ago time).  However, as Jeff pointed out, we held at DOWN for a while to reconcile SDFs, it's not quite a fair comparison. 

We'll see how things go, but there's at least a chance that this will help reduce the need for initial alignments.  If needed, we can try to tweak the time constant of the 'soft let-go' to further make the optical lever signal stay more overall flat.

The SUSBS SDF safe.snap file is saved with FM1 off, so that it won't get turned back on in SDF revert.  The PREP_PRMI_ASC and PREP_DRMI_ASC states both re-enable FM1 - I may need to go through and ensure it's on for MICH initial alignment.

RyanS, Jenne

We've looked at a couple of times that the BS has been let go of slowly, and it seems like the cooldown time is usually about 17 minutes until it's basically done and at where it wants to be for the next acquisition of DRMI.  Attached is one such example.

Alternatively, a day or so ago Tony had to do an initial alignment.  On that day, it seemed like the BS took much longer to get to its quiescent spot.  I'm not yet sure why the behavior is different sometimes.

Tony is working on taking a look at our average reacquisition time, which will help tell us whether we should make another change to further improve the time it takes to get the BS to where it wants to be for acquisition.