The DM first starting having issues at ~11am 2 weeks ago on April 22nd (Tues) for seemingly no reason, there wasn't any work or alogs that day that would made us suspicious of causing this.
Following my alog comments on alog84282, Dave showed me where the physical comtrol box is in the CER, restarting it brought the connection back but I then found that the dust monitor had no flow :(. This DM hasn't been used since we got it calibrated in April of 2024, so I swapped it for the last pumpless spare we had which has good flow but now it's not connecting again. I've tried powercycling the DM itself, the ioc, and the comtrol box then the ioc which is what got the other DM to reconnect, and it still getting "No reply from device within 1000 ms" for all its PVs. The DM it self is working and reading counts properly.
Doing a telnet network status (comand "ss -e") on h0epics for the diode room port yielded:
timer:(keepalive,38min,0) uid:1001 ino:20939307 sk:ffff8800b67bd500
ESTAB 0 0 10.105.0.80:37347 10.105.0.100:8000
(CoreyG, MitchR, RandyT, JimW)
Previous work posted here.
Today started with Randy and Mitch getting the small green tractor to EX and then working on compacting some of the very soft sand around the wind fence (on the front side of the Wind Fence---closest to EX).
Started to remove the final 3-wind fende panels (of 6 total). While driving the orange rental manlift (on the backside of the wind fence), it managed to get dug in some pretty deep sand a few times. On the last dig-in, we kept the manlift here (dug out/compacted sand around it and focused work on the furthest away wind fence panel since we already had the orange manlift here). The plan is to do everything for this panel location all at once:
Today we made it to step 4 and did the 1st/bottom horizontal wire.
We ran out of the thick wire, so the trailer was brought back to the Corner Station so the 1200lb spool can be loaded into the trailer in the morning. Then will continue getting that 1-panel installed....and then work on getting the orange manlift unstuck.
J. Kissel It was brought to my attention that the DC centering loops for the REFL path weren't working, so we revisited the sign of the RM1 and RM2 signal chains to confirm the functionality. Recall, - 2025-04-21 Daniel Fil and Marc found that raw ADC input voltage for OSEM sensor readbacks for the RMs were negative, and have been for over a decade, discovered as they replaced the in-air, sat-amp to vac feedthru cable which flipped the sign for both RM1 and RM2 OSEM sensors. LHO:84027 - 2025-04-25 Daniel, acknowledging that this OSEM sensor sign flip should be accounted for somewhere, decided to stick the sign flip in the 4x COILOUTF gains, typically reserved for magnet polarity compensation. LHO:84123 He acknowledged that putting the compensating sign there would impact the REFL WFS DC centering loops, and we've later realized this will also impact the alignment sliders. - 2025-04-29 For the above three "don't put the sign flip there!" reasons, on 2025-04-29, I reverted Daniel's COILOUTF gain sign flip. LHO:84186 That means that regardless of whether RM1 or RM2 have the wrong magnet polarity (see LHO:40853 which concluded it was RM2***), the actuator chain's sign will be the same as it has been for a very long time, and no ISC or alignment loops should need adjusting. I left that aLOG with a "we'll adjust the damping loop signs once the in-chamber work dust settles." - 2025-04-30 Rahul, a day later, wanted to resolve the remaining issue. I then communicated to Rahul that we needed to flip the sign in the DAMPING loops, and *only* in the DAMPING loops, because these are the only loops that would need to be changed. He instead re-flipped the coil output filter COILOUTF gains again, see LHO:84204, and accepted them into SDF. So, today, 2025-05-06 I again reverted the sign back to how they've been since 2013 $ caget H1:SUS-RM1_M1_COILOUTF_UL_GAIN H1:SUS-RM1_M1_COILOUTF_LL_GAIN H1:SUS-RM1_M1_COILOUTF_UR_GAIN H1:SUS-RM1_M1_COILOUTF_LR_GAIN H1:SUS-RM1_M1_COILOUTF_UL_GAIN 1 H1:SUS-RM1_M1_COILOUTF_LL_GAIN -1 H1:SUS-RM1_M1_COILOUTF_UR_GAIN -1 H1:SUS-RM1_M1_COILOUTF_LR_GAIN 1 $ caget H1:SUS-RM2_M1_COILOUTF_UL_GAIN H1:SUS-RM2_M1_COILOUTF_LL_GAIN H1:SUS-RM2_M1_COILOUTF_UR_GAIN H1:SUS-RM2_M1_COILOUTF_LR_GAIN H1:SUS-RM2_M1_COILOUTF_UL_GAIN -1 H1:SUS-RM2_M1_COILOUTF_LL_GAIN 1 H1:SUS-RM2_M1_COILOUTF_UR_GAIN 1 H1:SUS-RM2_M1_COILOUTF_LR_GAIN -1 and now have also flipped the damping loop sign, to account for the OSEM sensor readback sign change fixed from the in-air satamp to feedthru change $ caget H1:SUS-RM1_M1_DAMP_L_GAIN H1:SUS-RM1_M1_DAMP_P_GAIN H1:SUS-RM1_M1_DAMP_Y_GAIN H1:SUS-RM1_M1_DAMP_L_GAIN 1 H1:SUS-RM1_M1_DAMP_P_GAIN 1 H1:SUS-RM1_M1_DAMP_Y_GAIN 1 $ caget H1:SUS-RM2_M1_DAMP_L_GAIN H1:SUS-RM2_M1_DAMP_P_GAIN H1:SUS-RM2_M1_DAMP_Y_GAIN H1:SUS-RM2_M1_DAMP_L_GAIN 1 H1:SUS-RM2_M1_DAMP_P_GAIN 1 H1:SUS-RM2_M1_DAMP_Y_GAIN 1 This *positive* damping loop gain is markedly different than any other suspension, which have damping loop gains negative. Now I'm pretty confident that means that RM1's magnet polarities have been installed incorrectly, rather than RM2 as declared in 2018 ***. However, because we tried during this vent and can't access the magnets to verify the polarity, let alone change it (see LHO:84178), we will leave this situation as is because we don't want to have to think about the down-stream impacts of alignment and DC centering. That being said, the ISC team is going to put a positive digital alignment offset in PIT and YAW now, and will confirm that this steers the beam according to standard SUS convention: :: with a right-handed coordinate system defined by +L perpendicular to, and coming out from, the HR surface, and +V pointing up, :: +PIT should push the optic "down" curling around the +T access, and ::: +YAW should push the optic "counter clockwise, if you're looking from above the mirror, down the -V axis." If they find this backwards, the may request a change... For now, in this sign configuration, I've - Confirmed that the damping loops close and are stable, and - Saved the current sign state into the userapps repo copy of the h1sushtts_safe.snap, to which the target area's safe.snap and OBSERVE.snap both point, /opt/rtcds/lho/h1/target/h1sushtts/h1sushttsepics/burt$ ls -l safe.snap lrwxrwxrwx 1 controls advligorts 64 Oct 5 2017 safe.snap -> /opt/rtcds/userapps/release/sus/h1/burtfiles/h1sushtts_safe.snap /opt/rtcds/lho/h1/target/h1sushtts/h1sushttsepics/burt$ ls -l OBSERVE.snap lrwxrwxrwx 1 controls advligorts 64 Jun 22 2018 OBSERVE.snap -> /opt/rtcds/userapps/release/sus/h1/burtfiles/h1sushtts_safe.snap Attached are - a screenshot of me accepting the correct, above mentioned, COILOUTF and DAMP gains in SDF (I swear and promise I hit accept after I took the shot.) - a one-month trend of the RM1 COILOUTF gains, with the above associated timeline called out - a one-month trend of the RM2 COILOUTF gains, with the above accociated timeline called out
Jennie W, Sheila,
I have been working on a numerical model to check against some of our single bounce and full IFO measurements of the OMC to IFO mode-matching. Keita did a similar analysis using single bounce measurements and an alamode mode-matching simulation here alog #71145. In this entry while trying to check input parameters for the model, Sheila, Keita, Camilla and I worked out that the original; design for the OMC telescope has an extra 14 cm between OM1 and the input to the OMC.
My model takes the parameters for the bow-tie OMC cavity design from LIGO-T1300189, page six.
distance between two flat mirrors = distance between two curved mirrors = 0.2816m
diagonal distance between one curved and one flat mirror = 0.2844m
The RoC for each curved mirrors is take from LIGO-T1500060
Mirror C6 in table in appendices is curved mirror 1 in OMC design.
RoC CM1 = 2.57321 m
Mirror C5 is CM2
RoC CM2 = 2.57369 m.
Using the ABCD matrices for each mirror and the spaces between them I solved for the q parameter of the circulating mode just inside the input coupler.
This is q = -0.1408 + 0.7102i m.
This gives a beam waist between the two flat mirrors of 4.9044e-4 m. Note: The following analysis is all for the vertical modes, since the OMC has some astigmatism due to a non-zero angle of incidence in the horizontal direction we simplify our analysis by only considering the vertical modes in the mode propagation, this is especially easy for our particular OMC (OMC001) as it has a very small degree of astigmatism (108 kHz difference vs the fwhm of the resonance at 667 kHz) between the vertical and horizontal modes.
I then start just in front of OM2 using a q parameter (q_pre_OM2 = 0.8902 + 0.8034j) Sheila worked out from propagating the q from table 1 of LIGO-T1200410 for just after SRM using her alamode model from (alog #84089) entry.
I construct some 70 x 70 grid of possible q parameters.
I then propagate this towards the OMC using both the hot (1.75m RoC) and cold (2.1m RoC) that OM2 can have in its two PSAMS states (for calibration of the heater see alog #65276 and for the radii of curvature see alog #71145).
The q parameter can be used to define the electric field amplitude transverse to the beam propagation direction z:
U = 1/q ( exp( -jk ( x2 + y2 ) / 2q ))
where k is the wavenumber of the light and x and y are the transverse distances from the center of the beam in the horizontal and vertical directions.
Using the overlap integral:
O(q1,q2) = | U2 U1* |2 / ( |U1|2 |U1|2 )
where U1 is the field amplitude for TM 00 mode of the OMC and U2 is the field amplitude of the pre-OM2 mode after propagation to the OMC.
for the OMC field and each of the fields propagated from before OM2 I work out two mode mis-match plots, where mode-mismatch (MM) is:
MM % = (1 - O(q1,q2)) * 100,
in terms of the imaginary and real parts of the q parameter I started with upstream of OM2. See image 1 for the grid of pre-OM2 modes against the mis-match each mode would have with the OMC mode at the OMC after propagating through a cold OM2 and OM3. See image 2 for the same plot but with the mis-match the pre-OM2 grid would have after propagating through a hot OM2 and OM3.
On both images the original mode before OM2 is shown by a white star and the coloured countours show the mode-mis-match percentage at the OMC. The white contour in each plot is a measurement of the single bounce mode-mismatch measured in alog #79229 for the cold state and in alog #78727 for the hot state.
Sheila verified these mode-matching values for the hot and cold state of OM2 by propagating q_pre_OM2 in her model to the OMC and overlapping it with the OMC q parameter from my model.
The points where the two measurement contours overlap give us two possible q parameters for the real mode pre-OM2 in the single bounce state. See the third image, where the blue contour is the mode-mismatch measured with the OM2 in the cold state and the red contour that measured with the OM2 in the hot state. The light blude star is the pre-OM2 q used in my numerical model obtained from Sheila's alamode model.
The two possible qs that match experiment are q1 = 0.593 + 0.925j and q2 = 1.626 + 0.967j. This gives a beamwaist of 5.597e-4 m located 0.681 m behind OM2 or a beamwaist of 5.722e-4m located 1.714m behind OM2.
Terra Hardwick and others did some on-bench beam profiler measurements in HAM6 (alog #41490) and their model for between OM1 and OM2 seems to be consistent with q1 rather than q2.
The OMC waist used in the orginal mode-matching design document for the OM1-OM2-OM3 telescope (LIGO-T1000317) was 5.09e-4 m.
Note the OMC has two waists, one between the two flat mirrors (closer to the input coupler) and a larger waist between the two curved mirrora.
The waist (in the vertical direction) I calculated for the as-built curvatures was 4.9043e-4 m. This was with the flat mirror-flat mirror distance in the OMC as 0.2816 m and the flat mirror-curved mirror diagonal as 0.2844m.
The waist from Zac Korth's measurements (LIGO-D1300507) of our OMC before installation was 4.907e-4 m (vertical waist between two flat mirrors) with the flat-flat distance as 0.2815m and the flat-curved diagonal distance as 28.42m.
Code used to run analysis is at https://git.ligo.org/aligo_commissioning/omc-mode-matching and the main file is OM2_to_OMC_h_c.m. The commit is 50465375.
After the survey of the large LN2 dewar jacket pressures (alog 84028) we used an ISP500 scroll pump to pump the jackets on CP2 and CP3.
CP3 took ~4 days of pumping to bring the pressure from 220 mtorr to <10 mtorr. CP2 was much faster with about 8 hours of pumping from 18 mtorr to 9 mtorr.
All other tanks (excluding CP4 not in use) had jacket pressures around 10 mtorr, so no additional pumping needed.
Closing WP 12498
Debasmita, Preeti, Gaby
Robert did some injections at 0.2 Hz in the BS HEPI which showed a slight increase in DARM. We wanted to check further if the microseismic ground motion (0.1-1.0 Hz) is creating any noise in LHO as it does in LLO. For this, we chose the glitches in DARM picked up by omicron, having frequency in the range 10-60 Hz and SNR in the range 5-20.
glitch rate vs ground motion in 0.1-0.3 Hz | glitch rate vs ground motion in 0.3-1.0 Hz | |
Pearson correlation coefficient | 0.605 | 0.472 |
Spearman correlation coefficient |
0.602 |
0.439 |
The attached pdf shows qscans of some of the glitches chosen from high microseismic days. It is not very clear from the qscans if the glitches have arch like morphology, which is usually the case for glitches caused by scattered light. But, some of the glitches do show repetition within short time interval which make us suspect if they are produced by scattered light. We are still working on this to figure out if it is the process of scattering which is upconverting the low frequency ground motion to create noise in the 10-60 Hz band.
In summary, it looks like the microseismic ground motion is affecting the DARM sensitivity at LHO, maybe not as much as it does at LLO.
WP12510 Add Geist environment sensors
Jonathan, Dave:
Last Friday I started five EPICS IOCs for the four new out-building sensors and one for the existing MSR sensor.
Yesterday I installed the MX and MY Geist watchdog 1250 sensor units in the CDS VEA racks (details in forthcoming alog).
Today we added the new EPICS Channels to the EDC+DAQ. A new H1EPICS_ENV.ini file was created, it is generated by running generate_env_ini.py
This new INI was added to the edcumaster.txt file.
WP12511 Add h1daqfw2 EPICS LOAD MON channels to DAQ
Jonathan, Dave:
A new H1EPICS_CDSMON.ini was created with the addition of h1daqfw2's channels.
New JAC Slow Controls channels
Daniel, Dave:
A previous slow controls upgraded generated new INI channels for the JAC system. Back then we elected to not add them to the DAQ immediately, rather wait for the next target-of-opportunity, which was today.
DAQ restart
Jonathan, Erik, Dave:
The DAQ was restarted to install the new channels for:
No major issues, GDS0 needed a second restart. Due to vent activities we did not take the trend writers offline for this restart, rather just restarted the EDC following the 0-leg restart.
Jonathan tested his new restart-less frame writer during this restart.
EDC channel count 59188 + 84 = 59,272
This daqd restart was used as a test of h1daqfw2's ability to adjust on the fly. It went well. As expected the new code saw the changes and adjusted.
Amoung the changes were additions to the system monitoring channels. We did the restart towards the end of the hour. Normally that would mean losing close to an hours worth of trend data. In this case the framewriter adjusts its channel list on the fly. Below you can see two channels dumped from a 1hr minute trend frame. The ...H1DAQFW1... was an old pre-existing channel, ...H1DAQFW2... channel was new. You can see that the new channel was added midway with a zero fill of the data before it existed, while the older channel was not impact (or thrown away with the daqd restart).
In addition, over the weekend I figured it wouldn't take too much work to put a minimal nds1 interface onto the framewriter. So both Erik and I were able to take some simple measurements through the daqd restart without interruption. I did have some issues with streaming the data from the edc (the bit we restarted). This functionality is very much not ready for control room use, but did work as a proof of principle.
Dump of a old and a new channel from a frame generated while the other frame writers were being restarted:
root@h1daqfw2:/frames/trend/minute/14305# framecpp_dump_channel --channel H1:CDS-MONITOR_H1DAQFW1_CPU_LOAD_PERCENT.mean H-H1_M-1430589600-3600.gwf Frame file: H-H1_M-1430589600-3600.gwf DEBUG: Processing channel: H1:CDS-MONITOR_H1DAQFW1_CPU_LOAD_PERCENT.mean DEBUG: Trying as ADC DEBUG: Is a ADC Name: Compress: 266 (Endianness: Little Scheme: 10) Type: 2 NData: 60 NBytes: 416 Data: 6.28729164004326, 4.17406255081296, 3.57833329414328, 3.60958333561818, 3.66750004241864, 3.67500002260009, 3.71916669532657, 3.74739585369825, 3.8817708991468, 3.82260420769453, 5.55906248788039, 3.87937504226963, 3.93562503432234, 3.91968751251698, 3.82739583849907, 3.62052083040277, 3.62010418747862, 3.69833336497347, 3.68625002404054, 3.66718753005068, 5.32447914779186, 3.67375002975265, 3.71656252965331, 3.73489584351579, 3.89322916989525, 3.90125003928939, 3.93125004768372, 3.86749999498328, 3.91406253824631, 3.71927081222336, 5.44343745956818, 3.61781248822808, 3.68937503372629, 3.71395837391416, 3.7930208645761, 3.76812503834565, 3.7355208667616, 3.62187499354283, 3.70145832026998, 3.80020837162932, 5.48312501261632, 3.90666671544313, 3.92562501778205, 3.9627083795766, 3.95802086566885, 3.92802087018887, 3.80010416110357, 3.63791664664944, 3.62510419090589, 3.62989583437641, 5.31531244814396, 2.30302085528771, 0.95135415866971, 3.71520840749145, 3.72906252816319, 3.93354169155161, 4.05625004221996, 2.55833331122994, 2.94218750347694, 4.27510416905085 root@h1daqfw2:/frames/trend/minute/14305# root@h1daqfw2:/frames/trend/minute/14305# framecpp_dump_channel --channel H1:CDS-MONITOR_H1DAQFW2_CPU_LOAD_PERCENT.mean H-H1_M-1430589600-3600.gwf Frame file: H-H1_M-1430589600-3600.gwf DEBUG: Processing channel: H1:CDS-MONITOR_H1DAQFW2_CPU_LOAD_PERCENT.mean DEBUG: Trying as ADC DEBUG: Is a ADC Name: Compress: 266 (Endianness: Little Scheme: 10) Type: 2 NData: 60 NBytes: 96 Data: 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1.34916668335597, 4.81020835687717, 4.67812503005068, 4.78708336452643, 4.95833332886299, 4.98052083601554, 4.76249999230107, 4.90572916567326 root@h1daqfw2:/frames/trend/minute/14305#
The chilled water pumps at Mid X and Mid Y were run for several minutes today in order to exercise the bearings and re-wet the seals. This caused a drop in the temperature trending in NDSCOPE but is not an indication of a problem.
Tue May 06 10:12:46 2025 INFO: Fill completed in 12min 43secs
The first four attached plots shows the regression of the PR3 damping signals from C/DHARD dofs (residual motion CHARD_P_IN1 etc).
The last two plots shows the regression of the HAM2 ISI signals from PR3 damping signals - the coherence and spectra.
The data is from one hours low noise H1 lock on March 27, 2025 6:00 UTC.
The corresponding results for L1 are in 76513
Betsy, Daniel, Fil, Elenna, Jennie, Sheila, Ryan S, Camilla
Day 1: 84193, Day 2: 84228, Day 3: 84230 and 84239
To do's from this alog: Confirm ASC REFL RF cable numbers, decide whether to swap SLED pico cables or medm names, tilt ASC REFL B diode to dump reflected beam and realign.
Other things that still need to be done in REFL path: Move LSC diodes to correct to distance (so beam has 0.2 to 0.3mm beam raduis) and check alignment of beam on these diodes.
After this we will be ready ot move onto the POP path, Keita is checking the expected separation of POP and ASLS beams as it's important we don't center the shared optics on the POP path only.
Dry air skid checks, water pump, kobelco, drying towers all nominal.
Dew point measurement at HAM1 -42.1 °C
.
FAMIS26041 (I meant to do this famis task last Friday)
Most chambers are still elevated due to the vent.
Closes FAMIS26377
For the CS, everything looks fine. MR_FAN5_170_1 is the noisiest fan at ~ 0.4.
For the OUT buildings, MY_FAN1_270_1 looks fairly noisy and got a little worse 2 days ago.
Laser Status:
NPRO output power is 1.828W
AMP1 output power is 70.35W
AMP2 output power is 140.2W
NPRO watchdog is GREEN
AMP1 watchdog is GREEN
AMP2 watchdog is GREEN
PDWD watchdog is GREEN
PMC:
It has been locked 13 days, 19 hr 33 minutes
Reflected power = 23.39W
Transmitted power = 105.5W
PowerSum = 128.9W
FSS:
It has been locked for 0 days 17 hr and 26 min
TPD[V] = 0.8035V
ISS:
The diffracted power is around 3.6%
Last saturation event was 1 days 23 hours and 16 minutes ago
Possible Issues:
PMC reflected power is high
TITLE: 05/06 Day Shift: 1430-2330 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Planned Engineering
OUTGOING OPERATOR: None
CURRENT ENVIRONMENT:
SEI_ENV state: MAINTENANCE
Wind: 9mph Gusts, 5mph 3min avg
Primary useism: 0.02 μm/s
Secondary useism: 0.11 μm/s
QUICK SUMMARY: Vent work continues today with more HAM1 alignment and wind fence work.
The DR dust monitor counts did not look correct, its was only reading zero for over 2 weeks, I went out and power cycled it and made some counts which I was not able to see on epics. I then tried to restart the IOC, and it struggled to come back. After a little over 5 minutes it did come back and started showing counts again.
The DR is having network issues again, ~an hour after the restart. I'll try swapping this one with one of our 2 pumpless spares.
2025/05/06 11:09:20.443023 gt521s1 H1:PEM-CS_DUST_DR1_HOLDTIMEMON: No reply from device within 1000 ms
2025/05/06 11:09:21.444241 gt521s1 H1:PEM-CS_DUST_DR1_STATE: No reply from device within 1000 ms
2025/05/06 11:09:21.787891 gt521s1 H1:PEM-CS_DUST_DR1_OPSTATUS: Input "SH 600*00337" mismatch after 0 bytes
2025/05/06 11:09:21.787919 gt521s1 H1:PEM-CS_DUST_DR1_OPSTATUS: got "SH 600*00337" where "OP " was expected
2025/05/06 11:09:22.344822 gt521s1 H1:PEM-CS_DUST_DR1_HOLDTIMEMON: Input "OP H 58*00404" mismatch after 0 bytes
2025/05/06 11:09:22.344838 gt521s1 H1:PEM-CS_DUST_DR1_HOLDTIMEMON: got "OP H 58*00404" where "SH " was expected
2025/05/06 11:09:22.394988 gt521s1 H1:PEM-CS_DUST_DR1_STATE: Input "H 57*00403" mismatch after 0 bytes
2025/05/06 11:09:22.395020 gt521s1 H1:PEM-CS_DUST_DR1_STATE: got "H 57*00403" where "OP " was expected
2025/05/06 11:09:22.445131 gt521s1 H1:PEM-CS_DUST_DR1_OPSTATUS: Input "P H 57*00403<8d>OP H 57" mismatch after 0 bytes
2025/05/06 11:09:22.445164 gt521s1 H1:PEM-CS_DUST_DR1_OPSTATUS: got "P H 57*00403<8d>OP H 57" where "OP " was expected
Swapped the dust monitor and now it won't come back and the IOC can't connect to/see the DM.
2025/05/06 11:42:20.506771 gt521s1 H1:PEM-CS_DUST_DR1_HOLDTIME: No reply from device within 1000 ms
2025/05/06 11:42:20.507000 _main_ H1:PEM-CS_DUST_DR1_HOLDTIME: @init handler failed
2025/05/06 11:42:20.507100 _main_ H1:PEM-CS_DUST_DR1_HOLDTIME: Record initialization failed
Bad init_rec return value PV: H1:PEM-CS_DUST_DR1_HOLDTIME ao: init_record
2025/05/06 11:42:21.508499 gt521s1 H1:PEM-CS_DUST_DR1_SAMPLETIME: No reply from device within 1000 ms
2025/05/06 11:42:21.508670 _main_ H1:PEM-CS_DUST_DR1_SAMPLETIME: @init handler failed
2025/05/06 11:42:21.508762 _main_ H1:PEM-CS_DUST_DR1_SAMPLETIME: Record initialization failed
Bad init_rec return value PV: H1:PEM-CS_DUST_DR1_SAMPLETIME ao: init_record
Keita, Elenna, Jennie W.
We have taken three beam profile measurements along the REFL path on HAM1: one in the location where REFL WFS B will go, one in the location where REFL WFS A will go, and one measurement further "downstream" where we placed a steering mirror after where WFS B will go and steered back towards the edge of the table. We will post further details later, more measurements to be made along this path tomorrow.
Note that the same glitches we had in the original installation (alog 8934) were still there. Quoting my alog from 2013,
it was still difficult to obtain good data because of some kind of glitches. It's not clear if it was due to NanoScan or the beam, the beam was well damped and was not moving on the viewer card, there was no noticable intensity glitch either. But the symptom was that the statistics window shows nice steady data for anywhere from one second to 30 seconds, then there's some kind of glitch and the scan/fit image looked noticably different (not necessarily ugly), the diameter mean becomes larger and the stddev jumps to a big number (like 10% or more of the mean, VS up to a couple % when it's behaving nice), and the goodness of fit also becomes large. Somehow no glitch made the beam diameter number smaller. I just kept waiting for a good period and cherry-picked.
We measured the beam radius using NanoScan at four points around the WFS sled (roughly WFSA position, roughly WFSB position, far field 1, far field 2). We used D4sigma numbers instead of 1/e**2 numbers. NanoScan outputs diameter not the radius, and the table below shows the raw number.
We assumed that the WFS position would be ~0.5" from the +Y edge of the WFS sled for both A and B. Distances were measured using stainless steel rulers and are relative to the 50:50 splitter on the WFS sled that also acts as the steering mirror for WFSa.
position | distance [mm] | 2*avg(wx) [um] | 2*std(wx) | 2*avg(wy) | 2*std(wy) |
WFSA | 94 | 670.26 | 2.34 | 778.95 | 2.82 |
WFSB | 466.5 | 793.73 | 6.38 | 711.29 | 11.95 |
downstream 2 | 788.5 | 1484.15 | 12.46 | 1387.24 | 58.32 |
downstream 1 | 1092.5 | 2253.78 | 50.67 | 2119.24 | 68.30 |
In all of the above measurements, "Profile averages" was 10, "Rolling profile Averages" was 3.
We also measured between M5 and 50:50 splitter for ASC-LSC split as well as between M2 and RM1. Numbers will be added to this alog.
We'll also measure the beam size at LSC REFL_B location on Monday before proceeding to POP path.
Here are some comments about the measurement process:
The beam profiler is difficult to use because the profiler head easily swivels once it is place. The swivel seems to be driven by the fact that the cable is very stiff and made stiffer by the addition of the foil so it is cleanroom safe. Several times today, I would pick up or set down the profiler and the head would swivel. I tried tightening the screw holding the post to the base, and I tried tightening the screw that holds the post to the head, but it is not tight enough to prevent swiveling. I found the best method was to line up the profiler in the designed location, and hold the head and cable in place while someone else ran the measurement. That makes this a minimum two person job, but there was enough juggling that having a third person was sometimes helpful.
When we went in around 3 pm to do the final measurement of the day I measured the particle count: 0.3u was 10 and 0.5u was 0. I used the standing particle counter on the +Y side of the HAM1 chamber- briefly unplugged to carry it over to the -Y side for the measurement. I didn't measure when closing up because Keita is heading out to do a few more tasks on HAM1. The handhelp particle counter isn't working, so we have to carry this large one on a stand around to use.
WFS sled is still excellent, 84 to 85 deg Gouy phase separation.
In the attached, four measurement points have error bars both in the position and the beam size but it looks negligible. There's no concern for WFS, it's good to go as is.
However, just for the record, the astigmatism is bigger now (which is inconsequential in that ASC DOF separation is determined by the Gouy phase even if there's an astigmatism). The waist location difference is ~49mm now VS ~14mm or so before (just eyeballing the old plot from alog 8932) for a beam with the Rayleigh range of ~200mm. Not sure if this is the result of the AOI change or beam position change on curved mirrors and lenses, but I won't fix/correct this.
This morning we entered to do one more beam profile measurement. First Jennie and I refoiled the cable of the nanoscan profiler, since it was very stiff from multiple layers of foil. Then, before opening the cover to the table, I measured the dust counts by carrying the stand particle counter over to our working side like I did on Friday. The read was 0 and 0 for 0.3um and 0.5 um particles. I know it was working however, because as I carried the counter over outside the cleanroom it counted 19 each of 0.3 and 0.5 um particles.
Then, Jennie and I took one more beam profile measurement, this time on the LSC REFL path, after the final beamsplitter (M18). LSC REFL A (on transmission of M18) is placed on the table as in the drawing, but the LSC REFL B sensor (reflection of M18) was further away relative to the splitter. My quick rough measurement showed that LSC REFL B was about 160 mm away from M18.
I measured the distance of LSC REFL A to the front surface of M18 to be 128 mm. Then, I set LSC REFL B off to the side, and placed the profiler about 128 mm away from M18 on reflection of the splitter. We measured the beam profile, and then I re-placed LSC REFL B, this time at a distance of 128 mm to M18.
I have attached a very rough drawing of the REFL path and the locations where we made beam profile measurements. Each X on this drawing marks a beam profile measurement location. I also marked the Xs with letters A-G.
The measurements Keita reports above correspond the measurements C, D, E and F on this drawing. The difference between E and F, which is not depicted in my drawing, is a different placement of the temporary steering mirror relative to the sled.
We still need to report details on the measurements for locations A, B, and G.
Beam size upstream of the WFS sled
Unfortunately this is preliminary.
We measured the beam size at 4 different location upstream of the WFS sled marked as A, B, C and D. D data cannot be used as there's no data/picture of D locaiton but that's fine as far as position A data is good. Unfortunately, though, the position A horizontal width looks narrower than it really is (2nd attachment). The beam might be clipping in the nanoscan aperture or there might be a ghost beam or bright background light in the Region Of Interest (ROI), or ROI is defined poorly, effectively clipping the beam. Must remeasure.
LSC REFL_B (and therefore REFL_A) beam radius is ~0.1mm, which is tinier than my preference, the diode is 3mm (in diameter) so the beam could be larger. The diodes are placed close to the focus of the lens upstream (number 18 in a circle in the first attachment) so the beam won't move when the beam position moves on that lens. Moving away from that position will be fine as far as the deviation is much smaller than the focal length (~200mm). Rayleigh range is like 3cm or maybe smaller (0.1mm waist -> RR=10*pi mm), it should be easy to double the beam size by moving the sensors away from the lens by a couple inches. We'll do this after POP alignment.
Location | Distance from the closest component | wx [um] | std(wx) [um] | wy [um] | std(wy) [um] |
A |
225mm downstream of M2, hard to measure the position accurately. Nanoscan wx*2 number looks narrower than it really is. Must remeasure. |
2683.6/2
|
14.2/2
|
3562.9/2 | 4.4/2 |
B | 303mm downstream of M5. | 3936.9/2 | 64.5/2 | 3960.8/2 | 83.1/2 |
C |
128mm downstream of the last 50:50 for LSC REFL_A/B. LSC-REFL_B location (tentative). |
211.6/2 | 12.7/2 | 247.3/2 | 4.5/2 |
D | Exact position unknown, between RM1 and M2, less than 1400 downstream of M2. Beam size numbers look good. | 3703.6/2 | 3.0/2 | 4332.8/2 | 4.5/2 |
After everything is done we'll make a good measurement of distances between everything by either using a long/short ruler (preferred) or counting bolt holes or both.
Yesterday Betsy and I measured the distances between these optics:
Camilla and I went back out today to redo the measurements at the locations labeled "A" and "D" in Keita's diagram. This table reports the D4sigma values, like Keita's tables above.
We forgot that we had left ITMX aligned, so the original measurements in this alog are no good. Keita and I remeasured these again today (May 6) and I am updating the table below with the new data. We also got two more measurements in new locations that are not indicated in Keita's diagram.
Location | Distance from closest component | wx [um] | std wx [um] | wy [um] | std wy [um] |
A | 238 mm (+- 3 mm) downstream of M2 (nanoscan image) | 4038.9/2 | 1.4/2 | 4206.2/2 | 3.3/2 |
D | 314 mm (+- 3 mm) upstream of RM1 (measured from nanoscan front to metal ring around the RM, the mirror surface may be set back from the ring by another 1mm or so, hard to tell) (nanoscan image) | 3950.6/2 | 2.8/2 | 4315.0/2 | 2.6/2 |
New location, after RM2 | 374 mm upstream of M5 (nanoscan image) | 2304.8/2 | 36.3/2 | 2335.9/2 | 37.1/2 |
New location, between RM1 and RM2 | 345 mm upstream of RM2 (measured from nanoscan front to metal ring around RM) (nanoscan image) | 1650.9/2 | 2.3/2 | 1805.1/2 | 3.2/2 |
Leaving this older comment: It is difficult to measure these distances well with the ruler, so I would guesstimate error bars of a few mm on each distance measurement reported here.
Some new notes: when we reduce teh purge air flow, the measurements become much more stable and there is no need to "cherry pick" data as Keita discussed in earlier comments. Also, I think we have finally managed to tighten the screws on the nanoscan posts enough that it doesn't slide around anymore.
I opened up the DM that had no flow to find that the internal tubing was not even connected, I swapped this one back this morning and it came right back no problem and we can see it on epics. The one that I took off has some kind of network issue.