J. Kissel, E. Goetz

Now that some front end infrastructure is in-place for monitoring the systematic error of CAL-DELTAL_EXTERNAL against PCAL, we have to include corrections to DELTAL_EXTERNAL and PCAL to account for the impacts of anti-aliasing, delays, and imperfect estimation of the inverse sensing and actuation in the CALCS model. To that end, I have included these corrections as transfer function values stored in EPICS records (note that these are higher precision than what is currently written to the EPICS records; in the next days we will have a better solution to push these EPICS records to the front end)
    'CAL-CS_TDEP_PCAL_LINE1_DELTAL_PCAL_CORR_REAL': -0.006073503332940157,
    'CAL-CS_TDEP_PCAL_LINE1_DELTAL_PCAL_CORR_IMAG': -0.0013606856967624704,
    'CAL-CS_TDEP_PCAL_LINE2_DELTAL_PCAL_CORR_REAL': 5.899769524086836e-06,
    'CAL-CS_TDEP_PCAL_LINE2_DELTAL_PCAL_CORR_IMAG': -3.699645821510619e-07,
    'CAL-CS_TDEP_PCAL_LINE3_DELTAL_PCAL_CORR_REAL': 8.386397287449958e-07,
    'CAL-CS_TDEP_PCAL_LINE3_DELTAL_PCAL_CORR_IMAG': -1.5081314667072642e-07,
    'CAL-CS_TDEP_PCAL_X_COMPARE_DELTAL_PCAL_CORR_REAL': -5.9041552773359905e-06,
    'CAL-CS_TDEP_PCAL_X_COMPARE_DELTAL_PCAL_CORR_IMAG': 3.7352291714501767e-07,
    'CAL-CS_TDEP_PCAL_Y_COMPARE_DELTAL_PCAL_CORR_REAL': 5.899769524086836e-06,
    'CAL-CS_TDEP_PCAL_Y_COMPARE_DELTAL_PCAL_CORR_IMAG': -3.699645821510619e-07,
    'CAL-CS_TDEP_PCAL_LINE5_CORRECTION_REAL': -0.000891357719598607,
    'CAL-CS_TDEP_PCAL_LINE5_CORRECTION_IMAG': -6.855875512501219e-05,
    'CAL-CS_TDEP_PCAL_LINE5_DELTAL_PCAL_CORR_REAL': 0.0019506922912537398,
    'CAL-CS_TDEP_PCAL_LINE5_DELTAL_PCAL_CORR_IMAG': -0.0012367241766306207,
    'CAL-CS_TDEP_PCAL_LINE6_CORRECTION_REAL': -0.0003463121477292491,
    'CAL-CS_TDEP_PCAL_LINE6_CORRECTION_IMAG': -2.2361738471929133e-05,
    'CAL-CS_TDEP_PCAL_LINE6_DELTAL_PCAL_CORR_REAL': 0.00031722752183511923,
    'CAL-CS_TDEP_PCAL_LINE6_DELTAL_PCAL_CORR_IMAG': -0.0011010520099375882,
    'CAL-CS_TDEP_PCAL_LINE7_CORRECTION_REAL': -0.00016511918561500546,
    'CAL-CS_TDEP_PCAL_LINE7_CORRECTION_IMAG': -1.0773445503552214e-05,
    'CAL-CS_TDEP_PCAL_LINE7_DELTAL_PCAL_CORR_REAL': -0.0002494269255759141,
    'CAL-CS_TDEP_PCAL_LINE7_DELTAL_PCAL_CORR_IMAG': -0.0005356018866498055,
    'CAL-CS_TDEP_PCAL_LINE8_CORRECTION_REAL': -9.56073427066754e-05,
    'CAL-CS_TDEP_PCAL_LINE8_CORRECTION_IMAG': -6.836645060102044e-06,
    'CAL-CS_TDEP_PCAL_LINE8_DELTAL_PCAL_CORR_REAL': -0.0002616172956290841,
    'CAL-CS_TDEP_PCAL_LINE8_DELTAL_PCAL_CORR_IMAG': -0.00018845087631648119,
    'CAL-CS_TDEP_PCAL_LINE9_CORRECTION_REAL': -1.2253118668315672e-05,
    'CAL-CS_TDEP_PCAL_LINE9_CORRECTION_IMAG': -1.866404318229895e-06,
    'CAL-CS_TDEP_PCAL_LINE9_DELTAL_PCAL_CORR_REAL': -9.67618312303927e-06,
    'CAL-CS_TDEP_PCAL_LINE9_DELTAL_PCAL_CORR_IMAG': 5.78098087799133e-06,
    'CAL-CS_TDEP_PCAL_LINE10_CORRECTION_REAL': -6.138898212894542e-07,
    'CAL-CS_TDEP_PCAL_LINE10_CORRECTION_IMAG': -4.1525414776953105e-07,
    'CAL-CS_TDEP_PCAL_LINE10_DELTAL_PCAL_CORR_REAL': -7.42023357685704e-07,
    'CAL-CS_TDEP_PCAL_LINE10_DELTAL_PCAL_CORR_IMAG': 1.4076461554037913e-07


These were computed by using the method pydarm.calcs.CALCSModel.deltal_ext_pcal_correction() for the CAL-CS_TDEP_PCAL_LINE*_DELTAL_PCAL_CORR_* channels. Note that this calculates DELTAL/PCAL correction and what we need to install (because the front end does a division instead of multiplication) is the inverse of what this method returns. We have also specified include_whitening=False, endstation=False because the DELTAL_EXTERNAL signal is not whitened and the PCAL channels are corner station channels.

Note that CAL-CS_TDEP_PCAL_LINE*_CORRECTION_* channels are computed the usual way using pydarm.pcal.PcalModel.pcal.compute_pcal_correction() using endstation=False inside of pydarm.calcs.CALCSModel.compute_epics_records().

We also had to be a little careful because the LINE1-3 PCAL channels are Y-arm channels while 5-10 are X-arm channels, so we had to make sure to set ref_pcal_2_darm_act_sign=1 for X and ref_pcal_2_darm_act_sign=-1 for Y EPICS records. This should be improved in a future merge request.

When the gain of the ISS second loop was changed, the input offset was not adjusted. This results in the output of the 2nd loop ISS to saturate after a lock loss, until the offset slowly gets compensated by the offset loop. But, this now typically takes like 5 minutes. I adjusted the offset (H1:PSL-ISS_THIRDLOOP_OUTPUT_OFFSET) from 587.3 to 1272. We will have to check after the next lock loss that this actually works.

TITLE: 04/26 Day Shift: 15:00-23:00 UTC (08:00-16:00 PST), all times posted in UTC
STATE of H1: Calibration
SHIFT SUMMARY:
LOG:

!LVEA STILL LASER HAZARD!
IFO status: Currently still locked and in NLN_CAL_MEAS to allow a Calibration sweep.

A massive reduction in SDF Diffs occured today as you can see there are much fewer diffs then there was from my last alog, which is great!!! we are many steps closer to using the OBSERVE button!
For the time being the Operator core will use UNDISTURBED bit with the OBSERVING Observatory Mode selected until we can get the proper intention bit working by reducing the SDF DIffs to zero and getting all Gaurdian node OKed.

                                                                                                                                                                                                                                                                                                                              
Lockloss notes:
Lockloss info from before my shift started can be found here                                                                                                                                                                                                                                                                          During the shift there weren't any locklosses.  
                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                           

We've been seeing the sqz angle needs adjusting between the start of the lock and a few hours in 68853.

This morning I tried to optimize the SQZ angle every ~10minutes after the start of the lock (IFO in NLN at 15:47 UTC). I aimed to reduce the 3,4,5,6 BLRMS, ADF RMS at 1300Hz and the DARM plot. See Operator's SQZ Troubleshooting Wiki for some SQZ angle tuning instructions. Results attached. The angle changes around 20 degrees in the first 1h30 of the lock. We could think about adding a SQZ angle adjuster to the THERMALIZING guardian or something similar alog#68948. However the optimum angle is tricky to choose as there's a fairly large (+/- 10deg) range that gives very similar squeezing, see attached plot taken at 17:30 - 17:40 UTC (1h40 after NLN). 

We could try to retake Sheila's pre-O3 squeezing verus angle  alog#55760 plot overnight in the next weeks to understand this better. 

Daniel suggests checking the stability of squeezing using the ADF calculated SQZ angle (H1:SQZ-ADF_OMC_TRANS_SQZ_ANG). See attached for how this increases 15deg in the first 1 hour of a lock. Nominally the ADF line is off and we don't yet have data for a clean long lock where the SQZ angle wasn't adjusted.

J. Kissel, E. Goetz, T. Sanchez

While teaching Tony how to use the command line infrastructure to gather a full set of calibration sweeps, we noticed that the default list of measurements was missing a companion PCAL measurement to the last TST stage actuation strength measurement.

Before we changed anything we ran the check of "what will the command do if I just run it," and got
    $ pydarm measure
    available measurements:
      pcal: PCal response, swept-sine (/ligo/groups/cal/ifo/H1/templates/PCALY2DARM_SS__template_.xml)
      bb  : PCal response, broad-band (/ligo/groups/cal/ifo/H1/templates/PCALY2DARM_BB__template_.xml)
      sens: sensing function (/ligo/groups/cal/ifo/H1/templates/DARMOLG_SS__template_.xml)
      act1x: actuation X L1 (UIM) stage response (/ligo/groups/cal/ifo/H1/templates/SUSETMX_L1_SS__template_.xml)
      act2x: actuation X L2 (PUM) stage response (/ligo/groups/cal/ifo/H1/templates/SUSETMX_L2_SS__template_.xml)
      act3x: actuation X L3 (TST) stage response (/ligo/groups/cal/ifo/H1/templates/SUSETMX_L3_SS__template_.xml)
    measurement sequence:
      ['bb', 'sens', 'pcal', 'act1x', 'pcal', 'act2x', 'pcal', 'act3x', 'bb']
    Use --run-* option to actually execute measurement
You'll see that the list is missing a companion 'pcal' to 'act3x'.

So, we edited the default list by changing 
     /ligo/groups/cal/ifo/H1/
         pydarm_cmd_H1.yaml
Specifically, the lines under the parameter "measurement_sequence" such that it now reads
 measurement_sequence:
  - bb
  - sens
  - pcal
  - act1x
  - pcal
  - act2x
  - pcal
  - act3x
  - pcal
  - bb


Now, the dry-run of pydarm measure reads
    $ pydarm measure
    available measurements:
      pcal: PCal response, swept-sine (/ligo/groups/cal/ifo/H1/templates/PCALY2DARM_SS__template_.xml)
      bb  : PCal response, broad-band (/ligo/groups/cal/ifo/H1/templates/PCALY2DARM_BB__template_.xml)
      sens: sensing function (/ligo/groups/cal/ifo/H1/templates/DARMOLG_SS__template_.xml)
      act1x: actuation X L1 (UIM) stage response (/ligo/groups/cal/ifo/H1/templates/SUSETMX_L1_SS__template_.xml)
      act2x: actuation X L2 (PUM) stage response (/ligo/groups/cal/ifo/H1/templates/SUSETMX_L2_SS__template_.xml)
      act3x: actuation X L3 (TST) stage response (/ligo/groups/cal/ifo/H1/templates/SUSETMX_L3_SS__template_.xml)
    measurement sequence:
      ['bb', 'sens', 'pcal', 'act1x', 'pcal', 'act2x', 'pcal', 'act3x', 'pcal', 'bb']
    Use --run-* option to actually execute measurement

I've committed this new version of the yaml to the Calibration/ifo/H1/ git repo, as of 092dc147.

TITLE: 04/26 Eve Shift: 23:00-07:00 UTC (16:00-00:00 PST), all times posted in UTC
STATE of H1: Calibration
CURRENT ENVIRONMENT:
    SEI_ENV state: CALM
    Wind: 19mph Gusts, 12mph 5min avg
    Primary useism: 0.05 μm/s
    Secondary useism: 0.09 μm/s
QUICK SUMMARY:

- IFO has been locked at the start of my shift for ~7 hours

- Alert handler/CDS/DMs ok, wind looks to be picking up a bit, but nothing too bad so far

- Currently, there are calibration sweeps going on

• If we do have undisturbed time during the night, I will make a note of that in a separate alog

We have started the campaign to set the Settings Definition Files (SDF) for the OBSERVE state of H1.  LSC and ASC had many changes which I have looked through and then Accepted in SDF for the current Lock stretch (after some consult with TJ and Elenna).  (Hitting Accept in SDF sets the current Epics channel value to be the new Set point value for future reference.)  None of the LSC channels listed for the current lock are ones that are adjusted during lock stretch by Guardian.  Some of these channels may change between lock stretches so will watch for these at next Observing stretches to see what is dynamic and then decide to unmonitor, etc.

In the very unlikely chance that someone needs to reset one of the settings from today based on this interface, attached are the snapshots of what was loaded from some older setpoint.

BOS had over 1800 channels so no snapshot taken (which woulnd't be useful anyways).

J. Betzwieser, L. Dartez, E. Goetz, J. Kissel, J. Rollins

The details are happening all too fast in order to write them all down here but at the 10000 foot level, as of 2024-04-26 19:54 UTC, we've updated
   - the primary CAL-CS variables that create CAL-DELTAL_EXTERNAL_DQ, which correspond to the interferometrically-measured free parameters (optical gain, cavity pole, actuation gains for TST, PUM, and UIM changes)
       :: Values are informed by last Thursday's 2023-04-20 IFO measurement. No major change here, just pushing these to get them consistent with the rest of the pipeline. Not informed yet by the current state of the IFO, especially the TCS settings and SRCL offsets

   - The "DARM model transfer function function values at calibration line frequencies" EPICs records
       :: Importantly, this comes with changes that are the fall out of LHO:68880 and the solution pyDARM Merge Request 234

   - The GDS-CALIB_STRAIN pipeline has new filters, and importantly its got a configuration change that now using the corner station copy of the PCAL, H1:CAL-DELTAL_REF_PCAL_DQ, as it's measure of the PCAL system rather than the end-station.
       :: Again, this is the fall out of LHO:68880

Many details to come in the comments.

Wed Apr 26 13:15:37 2023 INFO: Fill completed in 37secs

Super quick fill, but plot looks good.

TITLE: 04/26 Day Shift: 15:00-23:00 UTC (08:00-16:00 PST), all times posted in UTC
STATE of H1: Calibration
CURRENT ENVIRONMENT:
    SEI_ENV state: CALM
    Wind: 10mph Gusts, 8mph 5min avg
    Primary useism: 0.02 μm/s
    Secondary useism: 0.10 μm/s
QUICK SUMMARY:
!LVEA IS STILL LASER HAZARD!

Locking was straight forward. Though we did go through PRMI_ACS .

Wind-Y team has been making good progress on the wind fence today without disturbing the IFO.
To ensure that the Y End Wind Fence work doesn't break our lock Jim had me turn off sensor correction for H1:ISI-ETMY.
H1:ISI-ETMY_ST1_SENSCOR_Y_NORM_FILT4_SW1R has been engaged to minimize the amount of "Bad_stuff" that gets sent to the ISI signal.
Please see screenshot attached below for future references.

APS is here again to day to work on the door locks for Filter Cavity End Station.

IFO has been locked for over 3.5 hours in NOMINAL_LOW_NOISE to allow for commissioning.
Some SQZ Angle adjustments have been made by Camilla.
Richard went into the CER and started poking things randomly and a source of noise was discovered to be the PMT Power Supplies which were then were turned off. 

The Calibration group is now taking a block of IFO time for Calibration measurements.

It's been fairly quite. very little wind, seismic motion, and the Violins look great!

Things to look forward to:
There is a need to move BIG RED the fork lift, from it's positon near the water tank to the staging building sometime in the next 24 hours. So if we lost lock there is an oppertunity to move BIG RED, so contacting Tyler after the next lock loss is a must.

We'd like to try and get the IFO into the OBSERVE State. So please try to resolve any SDF Differences that your sub systems currently have so we can try getting the IFO into the OBSERVE state. Please see Screenshot below of the SDF screen to determine if you can help resolve some SDF Diffs. Thanks! :) 

Adrian, Camilla, Gabriele, Fil, Richard

While trying to track down the source of the 4 Hz bumps in DARM, Richard noticed the cosmic ray photomultiplier tube (PMT) power supply voltage display numbers were jumping around. When he reset the dial, we noticed the 4 Hz oscillations in H1:PEM-ADC_5_29_2K_OUT_DQ disappeared for a few minutes. We unplugged the power supply to the PMTs at 19:05:00 UTC and have not seen 4 Hz features in the ADC channel or DARM since. Plots of the change in ADC channel timeseries behavior when Richard first touched the power supply knobs as well as the ADC channel behavior after the power supply was unplugged are attached. A spectrum comparing the ADC power supply plugged in (blue) and unplugged (red) is attached. We had about 40 minutes to watch DARM before some commissioning tasks started and we didn't see any more bumps. Another plot is forthcoming for this...

(edit for spelling...)

Today we made more tests of the effect of differential CO2 annular heating and the effect of thermalization on various parameters. Specifically, we measured the CARM open loop gain, PRCL open loop gain, and DARM spring at various times during power up. In parallel, the squeezing team also attempted to tune sqz during different points of thermalization. We also intended to measure frequency noise and contrast defect, but were unable to due to locklosses. See alog 68971 for details on last night's CO2 tests and the preliminary results of contrast defect and frequency noise.

The TCS setting that we tested was a differential annular CO2 step. CO2X was increased to 4W and CO2Y was left at 1.7W. The annular heating engages at the Power 25W state. The preliminary results showed marked improvement in frequency noise. The ring heaters were set to the nominal 76W settings: ETMX 1.3W, ETMY 1.2W.

CARM OLG

We measured the CARM olg during the first three hours of IFO thermalization. The results are plotted here. The show that the CARM gain drops in similar fashion to PRCL. However, we are not in danger of instability, and the gain levels off into the second hour of lock. We can increase the CARM gain as we thermalize, and increasing it will likely improve our frequency noise above 4 kHz (see 68967). Gabriele is working on implementation. He will add a comment describing the implementation.

PRCL UGF

We returned to changing the PRCL gain by hand. The PRCL gain does drop steadily as we thermalize, but at a different rate than measured by Gabriele. The UGF servo will need to be recommissioned for a few locks to collect data and then we can fit the thermalization trend.

DARM Spring

I made some measurements of the DARM spring through thermalization and also with different SRCL offsets. See the plot here. I measured both the DARM OLGTF and a PCAL to DARM transfer function to create this plot. I think the trend shows that we need less SRCL offset at the start of the lock, and then thermalization increases the SRCL detuning. For example, within the first hour, a SRCL offset of -80 was sufficient. By the third hour, we were moving towards needing something like the usual SRCL offset of -165. Jeff has commissioned low frequency line injections to track this better than I can with these measurements. I look forward to further results on this front.

Other effects

We were not able to make any well-defined measurements of these quantities, but two things were evident by eye during this lock: The frequency noise was improved, and the jitter noise was worse.

Lockloss

At the end of the third hour, we experienced an ASC lockloss. By eye, it seems to be a CSOFT P ring up, but given the amount of cross coupling it is hard to be sure. During a subsequent lock, I made some sensing matrix measurements of the ASC REFL signals at high power. There are some changes in the PRC2 P sensing that could be causing problems. Or, the problem could be something else entirely.

Unfortunately we don't have enough time right now to determine what exactly is the ASC problem and how fix it. Gabriele and I have chosen to revert the CO2X annular change to the previous setting of 1.7W (common with CO2Y). We know this setting is stable. We have commissioned the PRCL gain, various feedforward and more at this particular setting. We would also like to deliver a stable interferometer to the start of ER15 in the morning. We don't think we should give up on this setting though. We would like to use commissioning time in the next week to debug the ASC problem and regain stability with the new setting. We think this is a good change for the frequency noise. We also think that the increased jitter noise present is a clue that there are perhaps ASC offsets that could be causing the instability. We are making the CARM gain change though, as that is something that will occur independent of the CO2 change, and it will improve our frequency noise above 4 kHz.

LIGOCAM shows H1:PEM-EX_MAG_VEA_FLLOR_X/Y/Z_DQ as disconnected. I confirmed that (i) the magnetometer was still in place (ii) the power supply was on and (iii) the magnetometer box was running. I couldn't follow the triaxial signal cables from the box to the PEM racks - the cables are bound up with a whole bundle under the beamtube near the BRS. I still don't know why they're marked as failing.