Francisco, Elenna, help online from Joe B
We used the thermalized calibration measurement that Tony took in alog 84949, and ran the calibration report, generating report 20250610T224009Z. We had previously done this process for a slightly earlier calibration measurement with guidance from Joe. Upon inspection of the report, Joe recommended that we change the parameter is_pro_spring from False to True, which significantly improved the fit of the calibration. The report that Tony uploaded in his alog includes that fit change. Since we were happy with this fit, Francisco reran the pydarm report, this time requesting the generation of the GDS filters. After this completed, we inspected the comparison of the FIR filters with the DARM model, and saw very good agreement between 10 and 1000 Hz.
Two things we want to point out are that the nonsens filter fits included a lot of ripple a low frequency, but it still looks small enough that we think it is "ok". We also saw some large line features at high frequency in the TST filters, which Joe had previously assured us was ok.
While online with Joe, we had also confirmed that the DARM actuation parameters, such as gains and filters, matched in three locations: in the suspension model itself, in the CAL CS model, and in the pydarm ini file.
Since we confirmed this was all looking good, Francisco and I proceeded with the next steps, which we followed from Jeff's alog here, 83088. We ran these commands in this order:
pydarm commit 20250610T224009Z --valid
pydarm export --push 20250610T224009Z
pydarm upload 20250610T224009Z
pydarm gds restart
At this point, Jeff notes that he had to wait 12 minutes running "pydarm gds status" and running the broadband measurement to confirm the calibration is good. Francisco and I also knew we needed to check the status of the calibration lines on grafana. However, a few minutes after we started the clock on this wait time, the IFO lost lock.
We think the calibration is good, but we have not actually been able to confirm this, which means we cannot go into observing tomorrow (Wednesday) before making this confirmation.
Doing so requires some locked time with calibration lines on and a broadband injection for a final verification of this new calibration. The hope is that we can achieve this tonight, but if not, we must do so tomorrow before going into observing. (Note: because of the different rules of "engineering" data versus "observing" data, we could go into observing mode tonight without this confirmation).
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%.