OSEM estimator summary

Here's a quick summary of the Estimator installation from this week (Edgard, Oli, Jeff K, Brian L)

slides with basic info: T2500082 
FRS ticket 32526

Installation alogs
Infrastructure installed on HAM2/PR3 and HAM5/SR3, style updates to model, MEDM linked to sitemap - alog 83906

Tools installed in Estimator folder in the SUS SVN alog 83922

We updated the OSEM 10:0.4 calibration filters, but only on SR3 and PR3. alog 83913

Damping filters installed - alog 83926

Tested the fader switch - alog 83982

Designed and installed a blend for SR3 Yaw (DBL_notch in the first filter bank) - alog 84004

Created a new OSEM calibration script - alog 84005
(Edgard is thinking about a general version of this using Python, that is still TBD)

Fitting is well underway, but isn't done yet.

We made much more progress than we expected - thanks Oli and Jeff for all the help. It's not quite ready to go, we need to install the TF fits for the model.

We might have actually been able to test, except the temperature changes from the pumpdown were causing the SR3 optic to move, and the TFs were not very stable. Edgard is working on a log to document this. We have good fits for SR3 yaw taken Friday morning, and we might just try these remotely with Oli's help. We do plan to get a clean set of TFs in a few days when things have stabilized.

-- notes for next steps, thanks to Sheila for this --

We plan to leave the SR3 overall yaw damping gain at -0.5. This means we'll set the 'light damping' to -0.1  and the gain in the estimator to -0.4. Edgard used -0.1 for the fitting, but he notes that the Q's are pretty high so we may need to revisit this.

SR3 oplev channels are : H1:SUS-SR3_M3_OPLEV_{PIT,YAW}_OUT_DQ

Some interesting alogs about the impact of changes to SR damping: alog 72106 and 72130  

Elenna's PR3 coherence plots: alog 65495

Sat CP1 Fill

Sat Apr 19 10:08:32 2025 INFO: Fill completed in 8min 29secs

 

h1susauxh2 crash Fri 18 April 2025 23:43:02 PDT

h1susauxh2 models stopped running 23:43:02 Fri 18apr2025 PDT with an ADC timing error.

I am able to ssh onto the machine and first scans suggest we have lost an ADC in this system (only 7 of 8 are seen with lspci). We will need to power cycle the IO Chassis before deciding if an ADC replacement is needed.

This is an auxiliary SUS frontend for HAM2 meaning ADCs only and no control function has been lost.

Dmesg:

[Fri Apr 18 23:43:12 2025] rts_cpu_isolator: LIGO code is done, calling regular shutdown code
[Fri Apr 18 23:43:12 2025] h1iopsusauxh2: ERROR - An ADC timeout error has been detected, waiting for an exit signal.
[Fri Apr 18 23:43:12 2025] h1susauxh2: ERROR - An ADC timeout error has been detected, waiting for an exit signal.
 

2025 April vent - VAC diary

4-18 (Friday) activities:

- The corner pumpdown continued: the roughing pump was restarted at ~8:15
- After reaching 5E-1 Torr, the OMC turbo was started up (~15:10). The updated temperature control worked well again, neither the turbo pump, nor the controller did not heat up above 40 deg C during the whole process.
- After reaching 1E-4 Torr, the already spun up HAM6 and X-manifold turbos have been valved in to the volume (16:50)
- The 2 so far problematic annulus IPs are now doing well: at HAM4 and BSC8, the aux carts are ready to be taken off. The one at GV5 can now be switched on with good chances.
- The leak check continued at the X-manifold beamtube: ~80% of it was wrapped - this will be finished on Monday, and so the leak check itself will be also done

Now, as the pressure is <5.5E-5 Torr, WP12439 is closed, so the in-chamber HAM1 work is now possible again. HOWEVER, NOTE THAT HEAVY LIFTING IS STILL FORBIDDEN - and hopefully is not needed anymore.

Added the ISI to HLTS M1 OSEM calibration scripts to the SVN

Edgard

I added two matlab scripts to find the multiplicative correction factors for the OSEM calibrations by using the ISI Suspoint drives, as described in 83605. The script is still a work in progress, but it should be compatible with lightly damped ISI-to-M1 measurements like the ones in 83940 and 80863.

The scripts live in

/ligo/svncommon/SusSVN/sus/trunk/HLTS/Common/FilterDesign/Estimator/

and they are

extract_HLTS_ISI_dtttfs_for_OSEM_calibration.m
HLTS__ISI_to_OSEM_calibration.m

I will post the calibration comparisons with in air calibrations later.

 

Estimator progress/ SR3 model status

We've had an excellent week of progress on the estimator - thanks to everyone on site for the great hospitality!

Status of things as we go

1. The estimator is OFF. We set the damping of M1 Yaw back to -0.5.

2  There are new YAW estimator blends in the SR3 model. These were put into foton with autoquack. The foton file in userapps was committed to the SVN

3. We updated the safe.snap SDF file with a decent version of the OFF estimator. We HAVE NOT updated the observing.snap file. At this point, all the estimator settings should be the same in safe and observing. (I'm not sure how to update the observing.snap file)

4. All the work on the estimator design is all committed to the {SUS_SVN}/sus/trunk/HLTS/Common/FilterDesign/Estimator/  

 

-- some detailed notes on the blend design and svn commits follow --

Design new blend filters, load them into the model, commit the updated foton file

seems like a 2% error in the peak finding makes a bunch of noise in the estimator with the agressive blend, and is not a reasonable error (judgement call by Brian and Edgard)
 
>> print -dpng fig_2pcnt_error.png
>> print -dpng fig_2pcnt_error_result.png

Check noise again with 2% error in model/actual using the robust blend (EB blend) - we see the peaks are not any better.

I can't get a broad notch for notch 3 without causing the OSEM filter to be larger than 1. Issue seems to be the freq of the notches going past 60 deg. Could be tuned further.
Instead - use a simple notch.  This means we'll need to be quite accurate with the 3 peak - probably withing 0.5% of the actual frequency

figures
gain error - no performance hit
2% freq error - clear perf hit
1% freq error - acceptable perf hit - top mode clearly worse, but only a little
0.5% freq error - tiny perf hit at top mode only

print -dpng fig_perf1_gainerror.png
>> print -dpng fig_perf2_0p5freqerror.png
>> print -dpng fig_perf3_1p0freqerror.png
>> print -dpng fig_perf4_perfectmatch.png

turn the script into a blend design script - Estimator_blend_doublenotch_SR3yaw.m

update the yaw frequencies to 1.016, 2.297, 3.385
can we use autoquack? - yes!
Real foton file is: /opt/rtcds/userapps/release/sus/h1/filterfiles/H1SUSSR3.txt

(make a backup copy): /opt/rtcds/userapps/release/sus/h1/filterfiles$ cp H1SUSSR3.txt H1SUSSR3backup.txt

the file make_SR3_yaw_blend.m uses autoquack to put the new filters into the SR3 foton file.

(log notes)
please review the recent foton -c log file at
/opt/rtcds/lho/h1/log/h1sussr3/autoquack_foton_log_recent.log
   Checking foton file to see if filters got implemented correctly
BAD - Filter SR3_M1_YAW_EST_MEAS_BP has issues in sect. 1 : DBL_notch
at least one filter got messed up, please follow up...
Autoquack process complete
initial foton call succeeded
foton file ready for updating
starting foton cleanup process
final foton call succeeded
log file updated
please review the recent foton -c log file at
/opt/rtcds/lho/h1/log/h1sussr3/autoquack_foton_log_recent.log
   Checking foton file to see if filters got implemented correctly
BAD - Filter SR3_M1_YAW_EST_MODL_BP has issues in sect. 1 : DBL_notch
at least one filter got messed up, please follow up...
Autoquack process complete
>>

Check the foton file - it looks good - I checked the TFs by eye, and they look correct. the matlab error checker is irritated, but the matlab plots it makes look fine. I think it's OK.

Do a diff on the updated file and my backup - the only diffs I see are the new lines I added (that's good)

save the foton file, delete my backup.

press 'coef load' to get the new filters
(the CFC light goes green)

commit the updated foton file in userapps R31301

Save the work in the estimator folder

Estimator$ svn1.6 add fig*
A  (bin)  fig_2pcnt_error.png
A  (bin)  fig_2pcnt_error_result_EBblend.png
A  (bin)  fig_2pcnt_error_result.png
A  (bin)  fig_blend.png
A  (bin)  fig_perf1_gainerror.png
A  (bin)  fig_perf2_0p5freqerror.png
A  (bin)  fig_perf3_1p0freqerror.png
A  (bin)  fig_perf4_perfectmatch.png

$ svn1.6 add Estimator_blend_doublenotch_SR3yaw.m make_SR3_yaw_blend.m
A         Estimator_blend_doublenotch_SR3yaw.m
A         make_SR3_yaw_blend.m

committed in R12257

Set the model to a good state:

final switch = OFF.
gain of the normal yaw damping set back to -0.5

OSEM_Damper  = populated, but off (in=off, out=off, gain=0)
Estim_Damper = populated, but off (in=off, out=off, gain=0)

OSEM bandpass = populated and set to running state (on, gain=1)
MODEM bandpass =  populated and set to running state (on, gain=1)

 

accept SDF changes in H1:SUS-SR3_M1_
YAW_EST_MODL_BP
YAW_EST_OSEM_BP
YAW_DAMP_EST
YAW_DAMP_OSEM
save this to the safe file - I have not changed the observing file!

the SDF shows 0 differences

 

notes on Diff of foton file:

brian.lantz@cdsws44:/opt/rtcds/userapps/release/sus/h1/filterfiles$ diff H1SUSSR3.txt H1SUSSR3backup.txt
1025,1030d1024
< # DESIGN   SR3_M1_YAW_EST_MEAS_BP 0 sos(0.00026333867650529759, [0.99999999999999867; 0; -0.9999616512111712; 0; -1.999953052714962; \
< #                                   0.99995343154104388; -1.9997062783494941; 0.99970796324744837; -1.9998957078482871; \
< #                                   0.99989686159668212; -1.9999090565491939; 0.99990984807473893; -1.9999426937932141; \
< #                                   0.99994346902553977; -1.9999108726927539; 0.99991163318180731; -1.9999774146135141; \
< #                                   0.99997744772231478; -1.9999375279667919; 0.99993768590749621; -1.999963134023643; \
< #                                   0.99996328560740799; -1.9999399837273171; 0.9999401295235868])
1032,1037d1025
< SR3_M1_YAW_EST_MEAS_BP 0 21 6      0      0 DBL_notch  2.633386765052975870236851e-04  -0.9999616512111712   0.0000000000000000   0.9999999999999987   0.0000000000000000
<                                                                  -1.9997062783494941   0.9997079632474484  -1.9999530527149620   0.9999534315410439
<                                                                  -1.9999090565491939   0.9999098480747389  -1.9998957078482871   0.9998968615966821
<                                                                  -1.9999108726927539   0.9999116331818073  -1.9999426937932141   0.9999434690255398
<                                                                  -1.9999375279667919   0.9999376859074962  -1.9999774146135141   0.9999774477223148
<                                                                  -1.9999399837273171   0.9999401295235868  -1.9999631340236430   0.9999632856074080
1042,1047d1029
< # DESIGN   SR3_M1_YAW_EST_MODL_BP 0 sos(0.99973666135688777, [-1.000000000000002; 0; -0.9999616512111712; 0; -1.999965862142562; \
< #                                   0.99996754725922932; -1.9997062783494941; 0.99970796324744837; -1.9999754834715859; \
< #                                   0.99997627502341802; -1.9999090565491939; 0.99990984807473893; -1.999975984305477; \
< #                                   0.99997674481928778; -1.9999108726927539; 0.99991163318180731; -1.9999871245769849; \
< #                                   0.99998728252160574; -1.9999375279667919; 0.99993768590749621; -1.9999876354434321; \
< #                                   0.99998778124317389; -1.9999399837273171; 0.9999401295235868])
1049,1054d1030
< SR3_M1_YAW_EST_MODL_BP 0 21 6      0      0 DBL_notch  9.997366613568877680151559e-01  -0.9999616512111712   0.0000000000000000  -1.0000000000000020   0.0000000000000000
<                                                                  -1.9997062783494941   0.9997079632474484  -1.9999658621425620   0.9999675472592293
<                                                                  -1.9999090565491939   0.9999098480747389  -1.9999754834715859   0.9999762750234180
<                                                                  -1.9999108726927539   0.9999116331818073  -1.9999759843054770   0.9999767448192878
<                                                                  -1.9999375279667919   0.9999376859074962  -1.9999871245769849   0.9999872825216057
<                                                                  -1.9999399837273171   0.9999401295235868  -1.9999876354434321   0.9999877812431739

Took In-vacuum transfer functions for SR3 to test the fitting for the OSEM estimator

Edgard, Brian

We took a suite of measurements for SR3 similar the ones from 83940 with the intent of testing the OSEM estimator. We did not get quite that far, but we got data that will be useful to get a more accurate noise budget for the scheme.

The measurements were taken with the following settings

- The M1 DAMP filters were at a gain of -0.5, exchept for Yaw, which we reduced to a gain of -0.1.  This is the preferred configuration to get the data for the Yaw estimator.
- The coil driver filters in state 1.
- The ISI state was ISOLATED, but HEPI is locked, so we circumvented guardian by sliding off the Isolation Gain on HEPI.

Two different sets of measurements were taken. The ISI to M1 measurements live in:

/ligo/svncommon/SusSVN/sus/trunk/HLTS/H1/SR3/Common/Data

and are named:

2025-04-18_1900_H1ISIHAM5_ST1_WhiteNoise_SR3SusPoint_{L,T,V,P,Y,R}_0p02to50Hz_estimator.xml

The M1 to M1 measurements live in:

/ligo/svncommon/SusSVN/sus/trunk/HLTS/H1/SR3/SAGM1/Data

and are named

2025-04-18_2202_H1SUSSR3_M1_WhiteNoise_{L,T,V,P,Y,R}_0p01to50Hz.xml

All the changes were committed to the SVN as of revision 12258 (at the end of the day, after other work was committed too).

Friday OPS day shift report.

TITLE: 04/18 Day Shift: 1430-2330 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Planned Engineering
INCOMING OPERATOR: None
SHIFT SUMMARY:

Vacuum team has been working hard to get the turbo pumps runnign today, and got the turbo pumps on around 23:30 or so.
I have put up an NDCOPE on NUC 23 of one of the vacuum pressure sensors on BSC8 so non-VAC people could watch the vacuum pressure go down over the weekend.
Randy & Mitchel  did a run to pasco to getsme parts & got back from Pasco by 18:45 UTC
Overall it's been a quiet day.

LOG:

Start Time	System	Name	Location	Lazer_Haz	Task	Time End
15:10	VAC	Jordan	LVEA	N	Turning on roughing pumps	19:10
15:42	FAC	Kim	LVEA	N	Technical cleaning	15:42
16:25	EE	Fil & Marc	LVEA	N	Pulling cables	19:25
19:31	EE	Fil & Marc	LVEA	N	pulliung cables for HAM1	23:05
20:16	Tour	Amber & Tour	Control Room & Overpass	N	Giving a tour to some local kids.	19:46
20:32	VAC	Jordan	LVEA	N	Vacuuming	23:32
20:40	SEI	Brian & Edgar	End Y & X	N	Takin a look at the End stations	21:36
21:43	SUS	Edgar	Control Rm	N	Taking TF on HAM5	23:43

HVAC Fan Vibrometer checks

FAMIS 26374
The Vibrometers for the HVAC fans look ok , no interesng feates really stand out.

HAM 1 Cabling Complete

Finished dressing and installing cables for the new feedthroughs on HAM1. 

First we powered off the ISI interface and coil drivers for HAM1, disconnected all SEI cables from HAM1, redressed and reconnected them.  Next we dressed all HAM1 RF cables and installed to feed throughs.  We installed shrink tube to isolate the SMA connectors from each other.

All DSUB RM1, PM1, and ISC cables are reconnected.

There is a missing cable tray still to be dressed along the D6, D5, D4 side of HAM1.  Cables are temporarily dressed in this area, awaiting tray installation.  All SEI electronics remain off.

D. Sigg, F. Clara, M. Pirello

 

Power In ALS / SQZ / SPI Paths Post SPI Pick-off Install

J. Kissel scribing for S. Koehlenbeck, J. Freed, and R. Short
ECR E2400083
IIET 30642
WP 12453

Just writing a separate explicit aLOG for this for ease of reference in the future.

Before, during and after the SPI install we measured power along respective paths,
(1) The p-pol in-coming power into the whole ALS / SQZ / SPI pick-off path,
(2) The "ALS COMM" path: p-pol power in transmission of the ALS-PBS01 with the newly modified ALS-HWP2 position to get more power total power in the paths (3) and (4),
(3) The "SPI pick-off" path: The ~s-pol power in reflection of SPI-BS1,
(4) The "ALS/SQZ Fiber Distribution" path: ~s-pol power in transmission of SPI-BS1,
(see discussion in LHO:83978 as to why we're not so confident the reflection from ALS-PBS01 is entirely s-pol, which is why I say "~s-pol" here.)

The BEFORE vs. AFTER power in these paths is as follows:
  Path   Measured Between        Raw Power [mW]  PMC TRANS [W]     Date/Time Measured      Scaled Power [mW]  Fractional Power [%]
  (1)    ALS-L1 and ALS-HWP2         2060          103.2           2025-04-15 21:39 UTC       2095.9               ---

      % BEFORE
  (2)    ALS-M2 and ALS-L2           1970          102.8           2025-04-15 22:17 UTC       2012.2               96%
  (4)    ALS-M9 and ALS-FC2          48.7          103.0           2025-04-15 21:48 UTC         49.646              2%

      % AFTER
  (2)    ALS-M2 and ALS-L2           1790          103.3           2025-04-17 21:13 UTC       1817.7               87%
  (3)    SPI-L1 and SPI-L2            186          103.5           2025-04-16 22:43 UTC        188.7                9%
  (4)    ALS-M9 and ALS-FC2            50.5        103.5           2025-04-16 22:43 UTC         51.232              2%
where I've scaled all the raw power measurements by the rough nominal PMC TRANS power during recent observing times, 105 [W], i.e. 
(Scaled Power [mW]) = (Raw power) * (105 [W] / PMC TRANS [W])
and
(Fractional Power [%]) = 100 * {Scaled Power [mW]; paths (2)-(4)} / {Scaled Power [mW]; path 1}


As Ryan mentions in LHO:83989, for the purposes of safe long term storage, after all was said and done, we rotated SPI-HWP1 such that only 20 [mW] would go toward the SPI-FC1 fiber collimator, and it's dumped upstream just after SPI-L1. These AFTER power levels are what we anticipate running the rest of O4 in, with the SPI pick-off path safely out of commission.

2W Measurements
Head:    Ophir    10A-V2-SH SN122042 
Readout: Ophir    20C-SH    SN171175
Accuracy: +/-3%

200 mW Measurements:
Head:    Thorlabs S401C
Readout: Thorlabs PM100-D
Accuracy: +/- 7%

The attached picture summarizes all this info. The picture was take midday 2025-04-17, so you see the Ophir power meter in the middle of the ALS COMM 

Fri CP1 Fill

Fri Apr 18 10:09:22 2025 INFO: Fill completed in 9min 18secs

I confirmed a good fill curbside.

SPI Pick-off Path Install Day Three: Complete!

S. Koehlenbeck, J. Freed, J. Kissel, J. Oberling, R. Short

The SPI pick-off path installation on the H1 PSL table is now complete. The beam in the new SPI path has been reduced to 20mW and is currently being dumped with a razor dump between SPI-L1 and SPI-L2. Pictures attached reflect the final installation and layout, which will be be reflected in the updated as-built layout at a later date.

Associated entries: 83925, 83933, 83956, 83961, 83978, 83983 (and more to come)

ECR E2400083
IIET 30642
WP 12453

Here's Ryan's birdseye view labeled with all the components.
For details of the components, see the SPI BOM, T2300363, exported from its google sheets to -v4 as of this entry.

Install SPI pick-off path: Laser mode to fiber collimator

S. Koehlenbeck, J. Freed, R. Short, J. Kissel

The mode matching of the PSL pick-off beam to the SPI fiber collimator has been implemented using two lenses. The target beam has a mode radius of 550 µm at a position 63.5 cm downstream from the SPI beamsplitter (SPI-BS).

The lens configuration that produced the closest match to the target mode used:

• L1: Focal length = 100 mm

• L2: Focal length = 60 mm

Attached is a beam profile fit performed using JaMMT on data acquired with a WinCamD of the beam after SPI-L2. The measured beam radii at various distances from the SPI-BS are as follows:

Distance (cm)	Horizontal Radius (µm)	Vertical Radius (µm)
70.734	476	542
91.054	470	543.5
116.454	558.5	616.5

Both lenses are oriented such that their planar sides face the small beam waist between the two lenses. The arrows on the lens mounts point toward the convex surfaces.

The power transmission through the fiber has been measured to be 83 %.

ECR E2400083
IIET 30642
WP 12453


Some "for the record" additional comments here:
- Sina refers to the "SPI-BS" above, which is the same as what we've now officially dubbed as "SPI-BS1."

- Lenses were identified to be needed after the initial measurement of the beam profile emanating from SPI-BS1. That initial beam profile measurement is cited in LHO:83956, and the lens also developed in JaMMT with the lenses that were available from the optics lab / PSL inventory.

- If anyone's trying to recreate the model of the beam profile from the two measurements (LHO:83956 with no lenses, and the above LHO:83983) just note that the "zero" position is different in the quoted raw data; in LHO:83956 is the front of the rail, on Column 159 of the table, and in LHO:83983 the zero position is the SPI-BS1 reflective surface which is on Column 149 of the table, i.e. a 10 inch = 25.4 cm difference.

- The real SPI-L1 installed to create this mode-shape / beam profile is labeled by its radius of curvature, which is R = 51.5 mm, and thus its focal length is more precisely f = R*2 = 103 mm. (We did find a lens that does have f = 60 mm for SPI-L2, and it's labeled by its focal length.)

- "the fiber" is that which is intended for permanent use, depicted as SPI_PSL_001 in the SPI optical fiber routing diagram D2400110, a Narrow Key PM-980 Optical Fiber "patch cord" from Diamond, whose length is 30 [m]. This fiber will run all the way out to SUS-R2, eventually, to be connected as the input to the SPI Laser Prep Chassis (D2400156).

- Per design, light going into this fiber is entirely p-pol, due to polarization via SPI-HWP1 and clean-up by SPI-PBS01 just upstream. We did not measure the polarization state of the light exiting the fiber.

- The raw data that informs the statement that "the power transmission thru the fiber has been measured to be 83%":
     : We measured the input to the fiber coupler, SPI-FC1, via the S140C low-power power meter we'd been using throughout the install. The output power was measured via a fiber-coupled power meter Sina had brought with her from Stanford (dunno the make of that one).

     : We measured the power input to the fiber twice several hours apart (with the change in fiber input power controlled via the SPI-HWP1 / SPI-PBS01 combo).,
         (1) 19.9 [mW] with PMC TRANS power at 104.1 [W] at 2025-04-17 16:35 UTC (while the PMC power was in flux from enviromental controls turn on)
         (2) 180 [mW] with PMC TRANS power at 103.5 [W] at 2025-04-17 14:00 UTC (while the PMC power was quite stable)

     : We measured the output power
         (1') 16.6 [mW] with PMC TRANS power at 103.7 [W] at 2025-04-17 17:35 UTC (an hour later than (1))
         (2') 150 [mW] with PMC TRANS power at 103.5 [W] at 2025-04-17 14:00 UTC (simultaneous to (2))

     : Thus derive the transmission to be 
         (1'') (16.6 / 19.9) * (104.1/103.7) = 0.837 = 83.7% and 
         (2'') (150 / 180) * (103.5/103.5) = 0.833 = 83.3%

Beam Profiling the ALS / SQZ Fiber Distribution Pick-off Path in Prep for SPI Pick-off

J. Kissel scribing for S. Koehlenbeck, R. Short, J. Oberling, and J. Freed
ECR E2400083
IIET 30642
WP 12453

During yesterday's initial work installing the SPI pick-off path (LHO:83933), the first optic placed was SPI-BS1, the 80R/20T power beam-splitter that reflects most of the s-pol light towards the new SPI path. The pick-off is to eventually be sent into a SuK fiber collimator (60FC-SF-4-A6.2S-03), so we wanted to validate the beam profile / mode shape of this reflected beam.


The without changing any power in the ALS/SQZ/SPI pick-off path, the power now reflected from newly installed SPI-BS1 measured ~40 [mW] (see LHO:83946). This is too much for the WinCam beam profiler, so they used ALS-HWP2 to rotate the polarization going into ALS-PBS01, and thus reduced the reflected s-pol light in this ALS/SQZ/SPI pick-off path to ~10 [mW]. That necessarily means there's a little more of the ~2 [W] p-pol light transmitted and going toward the HAM1 light pipe, so they placed a temporary beam dump after ALS-M2 so as to not have to think about it.

The they set up a WinCam head on a rail and gathered the beam profile. With the WinCam analysis software on a computer stuck in the PSL, they simply gathered the profile information which I report here: 
# Distance[cm]	Radius[um]   Radius[um]
                   X             Y
    0.0           680.5         717
    17.78         465           504
    25.4          389           428.5
    30.48         346.5         368
    38.1          281.5         300.5

where "X" is parallel to the table, and "Y" is orthogonal to the table. The "0.0" position in this measurement is the "front" of the rail (the right most position as pictured in the attachment), which is Column 159 of the PSL grid. SPI-BS1 has the center of its reflective surface is set in +/- X position in Column 149 (within the existing ALS-PBS01 to ALS-M9 beam line). It's +/- Y position is set to create a reflected beam line along Row 30 of the grid, and the WinCam head and rail are centered in +/- Y on that Row to capture that beam.

Using this profile measurement, we find it to be quite different than expected from when this path was installed circa 2019 (see e.g. LHO:52381, LHO:52292, LHO:51610). Jason shared his mode matching solution from LHO:52292 with us prior to this week, and I've posted it as a comment to that aLOG, see LHO:83957.

We think we can trace the issue down to an error in the as-build drawing for the PSL:
- the whole beam path running in the +/-X direction from ALS-M1 to ALS-M2 is diagrammed to be on row 23 -- however, we find in reality, the path lies on row 25. That's 2 inches more between the (unlabeld) pick-off beam splitter just prior to ALS-M1 and ALS-M1 itself. Easily enough to distort a mode matching simulation.
- Jason confirms that he used the *drawing* to design the lens telescope for this ALS/SQZ fiber distribution pick-off path.

More on this as we work through a lens solution for the SPI path.

As of this entry, we elect to NOT create a new solution for the whole ALS/SQZ fiber distribution pick-off i.e. we *won't* adjust ALS-L1 or ALS-L5 in order to fix the true problem. But, we report what we found in the event that a case is better made to help mode matching and aligning into the ALS/SQZ fiber distribution pick-off easier -- as we have verbal confirmation that it was quite a pain.
For the record the fiber collimator used in the ALS/SQZ distribution pick-off is a Thor Labs F220 APC-1064.

Just a quick trend of the SM1PD1A EXTERNAL PD in transmission of ALS-M9 after they throttled the s-pol power in the ALS/SQZ/SPI path to ~10 [mW]. 
In that trend, you can see the different in "lights on" vs. "lights off" highlighted with the magenta vertical lines.

Note, as you can see in the picture, the reflection of ALS-M9 is dumped so as to not have to think about how much power is or is not going into the ALS/SQZ fiber distribution collimator (ALS-FC2), so the INTERNAL monitor PD that's in the distribution chassis itself is "correctly" unexpectedly reading nothing, so I don't show it.

Correction to the last sentence of the main entry -- the ALS/SQZ fiber collimator is *not* an, but instead a Thorlabs Fiber Port PAF2-5A, pictured well in FinalInstall_ALSfiber.jpg from LHO:83989.

I had incorrectly assumed that this collimator would be a copy of ALS-FC1, which *is* listed in E1300483 as an F220 APC-1064.

Relationship between violin mode height and narrow spectral artifact contamination, revisited

Summary

Q: What is the relationship between the strength of violin mode ring-ups and the number of narrow spectral artifacts around the violin modes? Is there a clear cut-off at which the contamination begins?

A: The answer depends on the time period analyzed. There was an unusual time period spanning from mid-June 2023 through (very approximately) August 2023. During this time period, the number lines during ring-ups was much greater than in the rest of O4, and the appearance of the contamination may have begun at lower violin mode amplitudes.

What to keep in mind when looking at the plots.

1. These plots use the Fscan line count in a 200-Hz band around each violin mode region, which is a pretty rough metric, and not good for picking up small variations in the line count. It's the best we've got at the moment, and it can show big-picture changes. But on some days, contamination is present, but only in the form of ~10 narrow lines symmetrically arranged around a high violin mode peak. (Example in the last figure, fig 7) This small jump in the line count may not show up above the usual fluctuations. However, in aggregate (over all of O4) this phenomenon does become an issue for CW data quality. These "slight contamination" cases are also particularly important for answering the question "at what violin mode amplitude does the contamination just start to emerge?" In short, we shouldn't put too much faith in this method for locating a cut-off problematic violin mode height.

2. The violin modes may not be the only factor in play, so we shouldn't necessarily expect a very clear trend. For example, consider alog 79825 . This alog showed that at least some of the contamination lines are violin mode + calibration line intermodulations. Some of them (the weaker ones) disappeared below the rest of the noise when the violin mode amplitude decreased. Others (the stronger ones) remained visible at reduced amplitude. Both clusters vanished when the temporary calibration lines were off. If we asked the question "How high do the violin modes need to be...?" using just these two clusters, we'd get different apparent answers depending on (a) which cluster we chose to track (weak or strong), and (b) which time period we selected (calibration lines on or off). This is because at least some of the contamination is dependent on the presence & strength of a second line, not a violin mode.

Looking at the data

First, let's take a look at a simple scatter plot of the violin mode height vs the number of lines identified. This is figure 1. It's essentially an updated version of the scatter plots in alog 71501. It looks like there's a change around 1e-39 on the horizontal axis (which corresponds to peak violin mode height).

However, when we add color-coding by date (figure 2), new features can be seen. There's a shift at the left side of the plot, and an unusual group of high-line-count points in early O4.

The shift at the left side of the plot is likely due to an unrelated data quality issue: combs in the band of interest. In particular, the 9.5 Hz comb, which was identified and removed mid O4, contributes to the line count. Once we subtract out the number of lines which were identified as being part of a comb, this shift disappears (figure 3).

With the distracting factor of comb counts removed, we still need to understand the high-line-count time period. This is more interesting. I've broken the data down into three epochs: start of O4 - June 21, 2023 (figure 4); June 21, 2023 - Sept 1 2023 (figure 5); and Sept 1 2023 - present (figure 6). As shown in the plots, the middle epoch seems notably different from the others.

These dates are highly approximate. The violin mode ring-ups are intermittent, so it's not possible to pinpoint the changes sharply. The Sept 1 date is just the month boundary that seemed to best differentiate between the unusual time period and the rest of O4. The June 21 date is somewhat less arbitrary; it's the date on which the input power was brought back to 60W (alog 70648), which seems a bit suspicious. Note that, with this data set, I can't actually differentiate between a change on June 21 and a change (say) on June 15th, so please don't be misled by the specificity of the selected boundary.