with help online from Joe B

I revised this title to "attempted" because this push has failed and we reverted to the calibration from 20250610T224009Z.

Today I pushed a new calibration from calibration report 20250628T190643Z. We changed the SRCL offset on 6/26 which had a small effect on the sensing function, enough that Joe and I (with input from Sheila) decided to push a new calibration. With the change in the sensing function, I tagged a previous report on 6/26 with epoch-sensing and epoch-hfrl. When I regenerated the report, I set is_pro_spring to empty, since the previous iteration of the report showed that there was very little spring in the DARM sensing measurement, at least to 10 Hz. I confirmed with Joe that the resulting corner plots for the sensing that show very poor fits for F_spring and Q are ok- this is because the pipeline is unable to fit any appreciable spring in the sensing function.

I checked the GDS filter results by eye, and confirmed they all looked flat. I then went ahead to push this new calibration, following steps we took last time, specifically:

pydarm commit 20250628T190643Z --valid

pydarm export --push 20250628T190643Z

pydarm upload 20250628T190643Z

pydarm gds restart

Then, we waited ten minutes to begin the calibration measurement. This is where I made an error- I checked that the GDS calib strain channels all looked sensible, and I saw some lines updating on grafana, so I assumed we were good to go. Corey began a calibration suite, which starts with a broadband measurement. However, the broadband results were not very good. We lost lock right at the end of the measurement. This was my mistake- I never checked if kappaC and kappaTST had settled, which it looks like they hadn't. So, I think we need to relock and check the calibration again. If it still looks poor, we can revert to the previous calibration. This must be done before we go back to observing.

Follow up edit below here:

We relocked after the push above and remeasured and saw the calibration was even worse than before (orange trace). We think this may be a fit error to the L2 actuation function, but we're not sure. Joe helped me revert the calibration to the previous version, from 20250610T224009Z. Corey and I ran an early broadband and saw the error was better, red trace. Still not the best, but we were not thermalized yet. Hopefully we can try a new push next week with a better cal.