Thu Jun 13 10:10:35 2024 INFO: Fill completed in 10min 32secs
Gerardo confirmed a good fill curbside.
Ran the usual broadband and simulines sweep starting at 1538UTC.
Simulines start:
PDT: 2024-06-13 08:46:11.048813 PDT
UTC: 2024-06-13 15:46:11.048813 UTC
GPS: 1402328789.048813
Simulines end:
PDT: 2024-06-13 09:07:41.142373 PDT
UTC: 2024-06-13 16:07:41.142373 UTC
GPS: 1402330079.142373
Files:
024-06-13 16:07:41,052 | INFO | File written out to: /ligo/groups/cal/H1/measurements/DARMOLG_SS/DARMOLG_SS_20240
613T154612Z.hdf5
2024-06-13 16:07:41,060 | INFO | File written out to: /ligo/groups/cal/H1/measurements/PCALY2DARM_SS/PCALY2DARM_SS
_20240613T154612Z.hdf5
2024-06-13 16:07:41,066 | INFO | File written out to: /ligo/groups/cal/H1/measurements/SUSETMX_L1_SS/SUSETMX_L1_SS
_20240613T154612Z.hdf5
2024-06-13 16:07:41,071 | INFO | File written out to: /ligo/groups/cal/H1/measurements/SUSETMX_L2_SS/SUSETMX_L2_SS
_20240613T154612Z.hdf5
2024-06-13 16:07:41,076 | INFO | File written out to: /ligo/groups/cal/H1/measurements/SUSETMX_L3_SS/SUSETMX_L3_SS
_20240613T154612Z.hdf5
A second simulines was ran after Francisco made some changes. Below is the info of that simulines.
Start:
PDT: 2024-06-13 09:55:53.982484 PDT
UTC: 2024-06-13 16:55:53.982484 UTC
GPS: 1402332971.982484
End:
PDT: 2024-06-13 10:17:24.832414 PDT
UTC: 2024-06-13 17:17:24.832414 UTC
GPS: 1402334262.832414
Files:
2024-06-13 17:17:24,764 | INFO | File written out to: /ligo/groups/cal/H1/measurements/DARMOLG_SS/DARMOLG_SS_20240613T165554Z.hdf
5
2024-06-13 17:17:24,771 | INFO | File written out to: /ligo/groups/cal/H1/measurements/PCALY2DARM_SS/PCALY2DARM_SS_20240613T16555
4Z.hdf5
2024-06-13 17:17:24,776 | INFO | File written out to: /ligo/groups/cal/H1/measurements/SUSETMX_L1_SS/SUSETMX_L1_SS_20240613T16555
4Z.hdf5
2024-06-13 17:17:24,780 | INFO | File written out to: /ligo/groups/cal/H1/measurements/SUSETMX_L2_SS/SUSETMX_L2_SS_20240613T16555
4Z.hdf5
2024-06-13 17:17:24,785 | INFO | File written out to: /ligo/groups/cal/H1/measurements/SUSETMX_L3_SS/SUSETMX_L3_SS_20240613T16555
4Z.hdf5
TITLE: 06/13 Day Shift: 1430-2330 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Observing at 150Mpc
OUTGOING OPERATOR: Ryan C
CURRENT ENVIRONMENT:
SEI_ENV state: CALM
Wind: 5mph Gusts, 3mph 5min avg
Primary useism: 0.02 μm/s
Secondary useism: 0.12 μm/s
QUICK SUMMARY: Locked for 15 hours, calm environment. Planned calibration and commissioning today from 830-1200PT.
TITLE: 06/13 Eve Shift: 2300-0800 UTC (1600-0100 PST), all times posted in UTC
STATE of H1: Observing at 153Mpc
INCOMING OPERATOR: Ryan C
SHIFT SUMMARY: Fairly quiet shift with H1 observing most of the time. H1 has now been locked for 8.5 hours.
LOG:
No log for this shift.
I was asked what needs to be done to convert kappa c into real physical units [mA/pm]. KappaC is a dimensionless number that represents the current optical gain as a fraction of what it was at some point in the past. In O4 that time corresponds to when the front end calibration was last updated (or 'exported'). You can see a list of calibration reports that have been exported to the front end on the H1 cal page. The entries with the 'exported' tag were used to update the front end and are used as reference for KappaC afterwards until the front end is updated once again. Since the meaning of KappaC=1 changes over time, you cannot easily trend the KappaC channel over long periods of time to compare optical gain values (yet*). You have to be sure to look at the most recently exported report and look up the optical gain (shown on the first page of the report PDF and in the enclosed pydarm_H1.ini file as "coupled_cavity_optical_gain). Moreover, the optical gain is reported in [DARM_ERR counts/m], not in physical units. To convert to mA/m (or mA/pm) we need to take the transfer function OMC-DCPD_SUM_OUT/DARM_IN1 [mA/ct]. However, this TF can change from lock to lock (see LHO:76000 for some discussion of this). So, given a particular GPS time, if you want to convert KappaC to mA/m you need to get the latest exported report to figure out what KappaC is in DARM_ERR cts/m, measure the OMC-DCPD_SUM_OUT/DARM_IN1 [mA/cts] transfer function (this is pretty flat so really you can condense this to a single number instead of a frequency dependent array) and multiply them. Ultimately, you end up with the following conversion: KappaC * Opt gain [DARM_ERR cts/m] * OMC-DCPD_SUM_OUT/DARM_IN1 [mA/cts] = Opt gain [mA/m] I've written a script that does this. It takes a single argument: the time at which to evaluate the optical gain. It uses the functionality I set up for a component of the noise budget (first mentioned in LHO:76000). On gitlab the script lives at https://git.ligo.org/louis.dartez/pydarm-utils/-/blob/4018924870892f1f3ecd2fb7281e47f5df2a3f29/scripts/optical_gain.py. On the workstation, it currently lives at /ligo/home/louis.dartez/repos/pydarm-utils/scripts/optical_gain.py To run the script: 1.) activate the pydarm-utils environment:conda activate /ligo/home/louis.dartez/conda/pydarm-utils
2.) runpython /ligo/home/louis.dartez/repos/pydarm-utils/scripts/optical_gain.py TIME
, where TIME is either a GPS time or a date string (use the -h option for formatting) It will download 10 minutes of data starting at the provided time so it may take a short while. Here is what the output should look like:(/ligo/home/louis.dartez/conda/pydarm-utils) louis.dartez@cdsws22: python optical_gain.py 1397102112.6 Using reference report: 20240330T211519Z Reference optical gain [DARM_ERR cts/m]: 3438377.6611055154 ________________________________________________________________________________ [Memory] Calling pydarm_utils.io.gwpy_utils.get_data... get_data([ 'H1:OMC-DCPD_SUM_OUT_DQ', 'H1:LSC-DARM1_IN1_DQ', 'H1:CAL-CS_TDEP_KAPPA_C_OUTPUT'], 1397102112.6, 1397102712.6) Opening new connection to nds.ligo-wa.caltech.edu... connected [nds.ligo-wa.caltech.edu] set ALLOW_DATA_ON_TAPE='True' Checking channels list against NDS2 database... done Downloading data: |█████████████████████████████████████████████████████████████| 601.0/601.0 (100%) ETA 00:00 _________________________________________________________get_data - 9.4s, 0.2min KappaC: 1.0068259239196777 Optical gain [DARM_ERR cts/m]: 3461847.765427341 DARM_IN1/OMC-DCPD_SUM_OUT [DARM_ERR cts/mA]: 4.0557094393989246e-07 optical gain [mA/pm]: 8.535739103490618
State of H1: Observing at 156Mpc and locked for 4 hours.
[SQZ] SQZ dropped out at 02:07 UTC, but Guardians were able to bring everything back on their own. After that, since H1 was already out of observing, I ran SQZ_MANAGER through SCAN_SQZANG since it had been noted earlier that SQZ could be better. I saw marginal improvements in DARM and range (only about 1-2Mpc), and H1 resumed observing at 02:13 UTC.
[SEI] H1 entered earthquake mode at 03:13 UTC suddenly from a Picket Fence network peak. I noticed the US.HWUT.00.BHZ station channel was highlighted in orange and the trend was drifting around in a non-real ground motion-like way, so I expect this to be a false alarm trigger as no on-site ground motion sensors saw any sudden motion. Seismic configuration went back to CALM 10 minutes later at 03:23 UTC.
Ryan C. pointed out to me that something like this errant Picket Fence trigger has happened before (alog77554), but the peaks in the cases this evening weren't nearly as high as in that instance.
SheilaD, ThomasS, FranciscoL
Wrote a script to change
H1:SUS-ETMX_L3_DRIVEALIGN_L2L_GAIN
H1:CAL-CS_DARM_FE_ETMX_L3_DRIVEALIGN_L2L_GAIN
using the mean of the last 30 minutes of H1:CAL-CS_TDEP_KAPPA_TST_OUTPUT. This script will be tested before making calibration measurements, next Thursday (manifest a locked IFO).
The reason we are changing the gains is because we want to maintain the DARM open loop the same, and SRCL and MICH feedforward stable. We use KAPPA_TST because it is a monitor of how much the gains are changing - it should be 1, ideally.
The script filters the data where KAPPA_TST does not change for more than 20 seconds - see drivealign_kappa_tst_1401031920-1401044520.pdf - to avoid weighting the mean, and changes the gains with respect to the percentage that KAPPA_TST is from 1. The attached plots were used to test the script at different gps times. "drivealign_allchannels_*.pdf"
plots the retreived channels from gwpy. "drivealign_kappa_tst*.pdf" plots the results from the
filtering
process.
The top plot is subtracting the values of KAPPA_TST, if the difference is zero it will start filtering (after 20 seconds). The two bottom-left figures show KAPPA_TST, one (top) without filtering and the other one (bottom) filtering the data. The bottom left are histograms taking (top) all the data, and (bottom) the filtered data. The script has arguments to run without plotting, or without changing the values. The output of the script that produced the attached plots is saved on terminal.txt.
The script is currently in: /ligo/home/francisco.llamas/commissioning/KappaToDrivealign.py
Following on from Sheila's alog 77427, checked on VAC trends and OFI temperature around April 22nd.
I checked (maybe a repeat of someone else) that there were no vacuum spikes during the locks when Kappa_C dropped or the locklosses afterwards. Plot of Kappa_ C with VAC channels attached.
Looking at the OFI TEC readbacks during that time, they were significantly noisier than usual during Tuesday maintenance after the 5% optical gain drop, before out alignment shift. Noisy between 6:30am and 4pm. This is before any Tuesday maintenance 77363 or injections start. Plot attached, including zoom out and zoom in. It also happened the May 28th to May 30th.
In 78442, we show that these larger than usual OFI temperature swings on locklosses and powerups so happened May 28th/29th when we adjusted our SRC alignment (SRC 250urad). Is this a sign there is an alignment where we are hitting something in the OFI?
TITLE: 06/12 Day Shift: 1430-2330 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Observing
INCOMING OPERATOR: Ryan S
SHIFT SUMMARY: Locked most of the shift then a lockloss with a suspicious ETMX signal just before lockloss ended a 18 hour lock. We just got back to low noise again.
Relocking:
DRMI, PRMI, and MICH wouldn't lock with poor alignment, so I ran an initial alignment, all automatic. After initial alignment it went up to PREP_DC_READOUT_TRANSITION and then ran into the same issue Tony saw last night (alog78383). Ryan and I discussed a way to fix this in ISC_LOCK and he will make a change to remove ISC_LOCK's requesting of OMC_LOCK to Down too early.
LOG:
Over the last week, we had a locking difficulty that started last Tuesday (shown roughly by the first vertical line in the attached screenshot), and caused poor range with high ASC and LSC noise, as well as locking difficulty in DRMI and when engaging the DARM offset. This has been largely solved over the weekend by adjusting triggering in DRMI(), and introducing offsets into the AS72 WFS, which control the alignment of SRM (78382).
We attempted to move the beam in the OFI starting on Thursday, 78290, this resulted in pressure spikes that Dave and Gerardo alerted us to on Friday evening. On Friday morning we reverted these alignment changes.
The attached screenshot shows that the PRG and arm powers are the same now as before the pressure spikes. The optical gain seems to be better, and the cavity pole worse. These changes may be related to the SRM alignment changes, and there was a similar lock on May 30th.
I made a little plot to see if/how the ETMs charge has changed, from before and after the vent. ETMY seems to be trending towards zero for both the inlock and oplev measurements, ETMX on the other and seems fairly static on the inlocks and is slightly rising as seen by the oplev measurements. ETMX also show opposite signs of charge for the different measurements.
TITLE: 06/12 Eve Shift: 2300-0800 UTC (1600-0100 PST), all times posted in UTC
STATE of H1: Lock Acquisition
OUTGOING OPERATOR: TJ
CURRENT ENVIRONMENT:
SEI_ENV state: CALM
Wind: 9mph Gusts, 6mph 5min avg
Primary useism: 0.02 μm/s
Secondary useism: 0.14 μm/s
QUICK SUMMARY: H1 is in the process of relocking and currently up to PREP_DC_READOUT_TRANSITION. We ran into the issue with the OMC DCPDs not having the same gains after the whitening change again, so TJ and I are looking into a fix.
To hopefully avoid the OMC DCPDs getting stuck at wrong values due to OMC_LOCK getting requested DOWN at an inopportune time (more details in alog78275), for now I've commented out the section of code at the end of PREP_DC_READOUT_TRANSITION which does this. I'll think about some replacement code to handle if OMC_LOCK gets stuck here, but it's possible just removing what's there already will be enough.
Changes have been loaded into Guardian and committed to svn.
Sheila and Keita have double-checked the sign convention of what beam positions mean given some A2L gain on an optic. Since we have had some errors in the past few weeks, I'm summarizing their findings in this alog (and will link to this alog from the 3 measurements we have over the last few weeks).
Here is a summary table, in units of A2L gain:
alog 77443, 26 Apr 2024 | alog 78119, 29 May 2024 | alog 78283, 6 June 2024 | |
SR2 P2L gain | +5.5 | -1.0 | +8.0 |
SR2 Y2L gain |
-4.5 | +0.3 | +1.5 |
SRM P2L gain | -3.4 | -5.5 | -1.0 |
SRM Y2L gain | +3.6 | +1.85 | +6.0 |
Here is that data translated into inferred position on the SRC optics, in mm:
26 Apr 2024 | 29 May 2024 | 6 June 2024 | |
SR2 Pit position [mm] | 11.1 mm below center | 2.0 mm above center | 16.1 mm below center |
SR2 Yaw position [mm] | 9.1 mm -X of center | 0.6 mm +X of center | 3.0 mm +X of center |
SRM Pit position [mm] | 6.8 mm above center | 11.1 mm above center | 2.0 mm above center |
SRM Yaw position [mm] | 7.2 mm -X of center | 3.7 mm -X of center | 12.1 mm -X of center |
I have added comments to the CalcSpotPos.py script, including a printout to the terminal that reminds us of these sign conventions when using the script.
The script is still in ...../userapps/isc/common/scripts/decoup/BeamPosition/CalcSpotPos.py .
Reproduced below is a table of M1 OSEM P and Y INMON for the SRC optics I made at the request of Alena. I've just made the same thing in alog 78493 but figured that this is a better (more convenient) place for others to find these numbers.
XXX=PIT | XXX=YAW | |
H1:SUS-SR3_M1_DAMP_XXX_INMON | -171 | -600 |
H1:SUS-SR2_M1_DAMP_XXX_INMON | -25.9 | +55.3 |
H1:SUS-SRM_M1_DAMP_XXX_INMON | -280 | -474 |
Jennie W, Sheila, TJ
This is done to reduce the coupling we get to length from having off-centre spot positions on the mirrors.
The script can be found in userapps/isc/common/scripts/decoup/a2l_min_generic_LHO.py .
See the steps the script runs in the bottom two plots and the reponse of the ADS demodulated signals in the top plots.
I ran ETMX P and Y first by calling the script with
python a2l_min_generic_LHO ETMX BOTH
changed P and Y
H1:SUS-ETMX_L2_DRIVEALIGN_P2L_SPOT_GAIN => 3.22
H1:SUS-ETMX_L2_DRIVEALIGN_Y2L_SPOT_GAIN => 4.99
ETMY
both P and Y changed
H1:SUS-ETMY_L2_DRIVEALIGN_P2L_SPOT_GAIN => 4.3
H1:SUS-ETMY_L2_DRIVEALIGN_Y2L_SPOT_GAIN => 0.92
ITMX
both P and Y changed
H1:SUS-ITMX_L2_DRIVEALIGN_P2L_SPOT_GAIN => -0.99
H1:SUS-ITMX_L2_DRIVEALIGN_Y2L_SPOT_GAIN => 2.88
ITMY
H1:SUS-ITMY_L2_DRIVEALIGN_P2L_SPOT_GAIN => -0.36
H1:SUS-ITMY_L2_DRIVEALIGN_Y2L_SPOT_GAIN => -2.5
16:35:52 UTC all A2L gains set and script finished.
CHARD_Y coupling was still bad so we reran Y degree of freedom for all test masses.
ETMX
Want to change gain from 4.99 to 4.98, rounded to 2 decimal places. St.Div is 0.925. Change of 0.01
H1:SUS-ETMX_L2_DRIVEALIGN_Y2L_SPOT_GAIN => 4.98
ETMY
Want to change gain from 0.92 to 0.93, rounded to 2 decimal places. St.Div is 0.145. Change of -0.007
H1:SUS-ETMY_L2_DRIVEALIGN_Y2L_SPOT_GAIN => 0.93
ITMY
Want to change gain from -2.5 to -2.5, rounded to 2 decimal places. St.Div is 1.0. Change of -0.001
Gain did not change.
3 A2Ls changed by 17:33:32 UTC.
ITMX
Want to change gain from 2.88 to 2.87, rounded to 2 decimal places. St.Div is 0.496. Change of 0.01
H1:SUS-ITMX_L2_DRIVEALIGN_Y2L_SPOT_GAIN => 2.87
3 A2Ls changed by 17:33:32 UTC.
I don't think these values made it into lscparams' dictionary a2l_gains['FINAL'] (starting around line 451 in lscparams.py), so they were reverted for the next lock, and they were accepted as the previous values in alog 78383.
Keita, Sheila,Robert, TJ, Jennie, Corey, Tony
Dave and Gerardo alerted us that there have been vacuum spikes after locklosses in HAM6 yesterday. We are looking at what circulating powers were and what the lockloss transient was at the time of locklosses that caused and didn't cause a vacuum spike in HAM6. Here is a comparison table:
time | AS_C peak | POP A LF | which alignment | spike? |
6/7 1:12:35 | 0.938*10 = 9.378 | 5505 | bad | 3.6e-8 |
6/7 3:04:08 | 1.35*60 = 81 | 26739 | bad | 4.28e-8 |
6/7 03:51:29 | 1.05*60 = 63 | 27032 | bad | 1.5e-7 |
6/7 23:15:54 UTC | 0.342*2 =0.684 | 1109 | good | no |
6/7 20:54 UTC | 1.58*2= 3.16 | 651 | good, PRG was tanking | no |
In the bad alignment, the beam was clipped on it's way to AS_C, so that diode wasn't catching all the power it would have in the good alignment. AS_A and AS_B saturate at the time of locklosses.
The spike in vacuum pressure was higher with each successive lockloss, although the power on AS_C was largest in the second one.
One of the three pressure spikes from yesterday was the lock loss from 10W, others were from 60W.
1st plot shows the worst one in terms of the pressure spike (the last one at 6/7 1:12:35 UTC, 60W).
This doesn't tell us the cause of the pressure spike, that requires different investigations.
Anyway, the 2nd plot shows the lockloss from today after Sheila, Jennie and TJ moved to a better alignment.
SR2 doesn't move much over the power range from 2W to 25W, and ASC-AS_C_NSUM doesn't show the sign of clipping. Everything looks saner and thus better.
The only concern is if this "better" alignment will still burn things in HAM6. We haven't observed pressure spikes from 2W lock losses with this alignment today but that only happened twice.
To clarify, "bad" alignment that produced pressure spikes was only for Thursday, and the "better" alignment today is supposed to be the same as or at least quite similar to pre-Thursday. Since we haven't had any pressure spikes with pre-Thur. alignment, I doubt that we'll see any pressure spikes with this alignment either.
However, picos had to be moved by large amount to go from pre-Thur. to Thur. and then to Fri. alignment. Even though Fri. alignment should be clouse to pre-Thur., we expect some not-so-large difference in the WFS sled centering, thus in the HAM6 alignment.
Out of caution, we'd like to see that losing lock at 10W won't cause pressure spikes before proceeding further. We chose 10W, because a pressure spike was observed at that power with a loss of lock with a bad (Thu.) alignment. If we don't see any spike for many lock losses with current (Fri.) alignment it would be safe to proceed.
Since automated DC lock won't work for this "good" alignment yet (that problem existed before Thursday and it seems to persist today), Sheila and I asked Tony to lock the IFO, bring it to 10W with RF, kill lock and observe pressure. If there's a spike he will stop, otherwise he will repeat.
We'll reconvene tomorrow.
Attached is an annotated HAM6 picture.
Also, plots with more piranis showing all three pressure spikes was posted in alog 78327.
Since FS seems to have worked, potential point that could have made pressure spikes are:
Jennie W, Sheila
After our picoing efforts, at 22:50 UTC today Sheila and I measured the A2L gains of the SRM and SR2.
Sheila notched 31 Hz out of the SRCL control loop and I injected a line at this frequency first at SUS-SRM_M3_LOCK_P_EXC, then SUS-SRM_M3_LOCK_Y_EXC.
Sheila changed the A2L gains for the corresponding degree of freedom so that the line height was minimised in SRCL_IN1 and in DARM using the channels H1:SUS-SRM_M3_DRIVEALIGN_P2L_GAIN and H1:SUS-SRM_M3_DRIVEALIGN_Y2L_GAIN.
SRM spot position:
P2L -1 with precision of 1
Y2L 6 with a precision of 0.5
(not too sure of the precisions as I lost my alog halfway through (d'oh).
We then did the same thing for SR2 by injecting in the M3_LOCK P and Y channels and changing the DRIVE ALIGN gains for SR2.
SR2 spot position was
Y2L 1.5 with precisioon of 0.25
P2L is 8 with precision of 1
The templates for these measurements are in: /ligo/home/jennifer.wright/Templates/Measure_spot_size_SR2.xml and Measure_spot_size_SRM.xml
Sheila and Keita have recently found and fixed sign convention errors. Please see alog 78393 for the corrected interpretation of A2L gains to inferred spot positions.
At the request of Alena, here's a table of M1 OSEM P and Y INMON for the output optics right after A2L measurements (starting ~2024/Jun/06 23:10:00 UTC):
XXX=PIT | XXX=YAW | |
H1:SUS-SR3_M1_DAMP_XXX_INMON | -171 | -600 |
H1:SUS-SR2_M1_DAMP_XXX_INMON | -25.9 | +55.3 |
H1:SUS-SRM_M1_DAMP_XXX_INMON | -280 | -474 |
Last night and today we are in a different spot through the OFI. See Sheila's alog 78096 for the move that was made.
Overall, SR2 and SRM yaw are much closer to center in this position, however SRM pitch is farther from center. I did a quick double check of the SRM pit, and indeed this is where it wants to be.
The previous spots (with the previous SR3 alignment) are recorded in alog 77443.
ampl [cts] of line at 31.0 Hz | A2L gain step size when minimizing | CAL-DELTAL line reduction factor | Final A2L gain | Inferred new spot position [mm] | Change from alog 77443 position | |
SR2 P2L | 1.0 | 0.1 | 100x | -1.0 | -2.0 | 13.1 mm other side of center |
SR2 Y2L | 1.0 | 0.1 | 100x | +0.3 | 0.6 | 9.7 mm other side of center |
SRM P2L | 2.0 | 0.1 | 50x | -5.5 | -11.1 | 4.3 mm farther from center |
SRM Y2L | 2.0 | 0.1 | 30x | +1.85 | 3.7 | 3.5 mm closer to center |
Attached are the saved SDF diffs for both Observe and Safe snap files.
Sheila and Keita have recently found and fixed sign convention errors. Please see alog 78393 for the corrected interpretation of A2L gains.
Sheila, Camilla. During this May 28th/29th SRC alignment, the OFI sees larger than usual temperature swings on locklosses and powerups. See plot attached. We saw similar larger OFI temperature swings on the re-locking attempts after our April 22nd optical gain drop before we changes alignments, shown in 78399 and second attached plot. Is the beam in this alignment hitting something in the OFI? Could be more likely the yaw alignment as that is common in both alignments with larger temperature swings.
There had been a suggestion (passed to me by Sheila) that we should measure the beam positions on SRM and SR2 after the big move that we made this week (which is summarized in alog 77427).
We don't have a premade script to do this like we have for the test masses, so I just did it by hand. One at a time, I put in a line using the ADS screen to SR2 or SRM pit or yaw, then changed the corresponding A2L element to minimize the line height in CAL-DELTAL_EXTERNAL. I was also watching SRCL_IN1 and SRCL_OUT, but the lines disappeared in the SRCL signals before they disappeared in the DARM signal, so I just used DARM.
All A2L values for SR2 and SRM had been 0.0, so I'm not going to bother putting in a 'before' column in the table below since they were all the same value of zreo.
After finding those values, I ran /opt/rtcds/userapps/release/isc/common/scripts/decoup/BeamPosition/CalcSpotPos.py to get from A2L coefficient to beam spot. This script had been made for IMC optics, but since SRM and SR2 are the same style, the calculation should be the same. Reminder of where this calc comes from (it's referenced in the script): alog 31402.
We don't have any 'before' measurements to compare to, but at least we now have some amount of information of where we are on these optics after the big move.
I'm pretty sure that these new A2L values can only be good, so I've accepted them in both safe and observe snaps for SR2 and SRM (see first and second attachments, only 2 rows per SDF table are accepted). These A2L gains for non-test mass suspensions are not under guardian control, so this should be good enough to keep them in place.
In the table below, the Cal-Deltal line reduction factor ends up really just being the ratio of the peak height in DARM before I started doing anything to that dof, and the noise level. To do a better job of measuring this, I would have had to increase my excitation amplitude, but that didn't seem important enough to do given the limited commissioning time we had.
ampl [counts] of line at 30.5 Hz | A2L gain step size when minimizing | CAL-DELTAL line reduction factor | Final A2L gain | Inferred spot position [mm] | |
SR2 P2L | 0.1 | 0.1 | 50x | +5.5 | 11.1 |
SR2 Y2L | 0.1 | 0.3 | 45x | -4.5 | -9.1 |
SRM P2L | 0.7 | 0.1 | 100x | -3.4 | -6.8 |
SRM Y2L | 0.7 | 0.1 | 50x | +3.6 | 7.2 |
I don't have time right now to think through the whole left-vs-right sign convention (it's discussed in alog 31402), but it does look like we're rather 'diagonal' in the SRC now, since the signs of the spot positions are opposite for SR2 vs SRM (eg one positive P2L and one negative P2L means the beam is on opposite sides of center).
Anamaria, Sheila
About sign conventions:
This means that on SR2 the spot is 11mm above the rotation center and 9 mm in the negative X direction from the center. On SRM the spot is 6.8mm below the center of rotation, and 7.2mm in the negative x direction.
Sheila and Keita have recently found and fixed sign convention errors. Please see alog 78393 for the corrected interpretation of A2L gains.