Search criteria
Section: H2
Task: SYS
R. Crouch, J. Oberling
Yesterday we began measuring the locations of the vacuum chamber support tube ends using the FARO laser tracker. We started with the support tubes for the WBSC3 chamber and the +X ends of the WBSC2 support tubes as these were the most readily accesible. The remaining support tubes in the LVEA (WBSC1, WBSC2 -X ends, and all WHAM chambers except WHAM7) have iLIGO-era PEM Interface Plates on them that block the support tube; some of these plates have undocumented spacers between them and the support tubes they are attached to, meaning we cannot accurately locate the support tube end w.r.t. the PEM interface plate and therefore making an accurate measurement of the support tube location impossible. As an aside, Jim is in the process of removing these plates from the chambers (so far WHAM3 and WHAM4 are complete, WHAM1 and WHAM2 are 75% complete), so we can get at these support tube ends as the opportunity arises (he will then reinstall these plates, as they make for very convient mounts for dial indicators).
Measurement Method
This is a fairly straightforward measurement, but there is a somewhat subtle "gotcha" that needs to be accounted for to get an accurate measurement. But first things first, we aligned the FARO to the LVEA's Building Coordinate system using our red alignment nests, then applied the X and Y axis rotations required to align the FARO to the site global coordinate system (see T0900340 for a brief overview of the coordinate systems in use). We then loaded CAD models of the support tubes, that Ryan downloaded from the SolidWorks vault with each model in the site global coordinate system, into the FARO's control software, PolyWorks. PolyWorks automatically reads the coordinate system information contained in the CAD files and places these models in position w.r.t. to the site global coordinate system. This gives us nominal locations of the support tube ends, a guide for our measurements, and also a nice visual reference for where everything is positioned.
Now for the "gotcha." The physical support tubes have a hole in the center of each end that is not represented in the CAD model, and this hole is large enough that the FARO target (a Spherically Mounted Retroreflector, or SMR, with a 1.5" diameter) sits slightly inside the hole. This means that when you're taking a measurement of the center of the support tube end using this hole the SMR is not measuring the location of the actual support tube end, it is a few mm inside of it. To account for this we did the following:
To take the measurement we used the Build/Inspect mode in PolyWorks. In this mode we have to be sure to select the "Towards Object" compensation method, which automatically compensates for the radius of the SMR (3/4", or 19.05 mm). If "None" is selected the FARO measures to the center of the SMR, but our measurement point is at the edge of the SMR, since that's what is physically touching the support tube, so we need to compensate for that radius. This gives us the deviations of the measurement point, which can then applied to the point representing the center of each support tube end to give their measured location. The results of our measurements are shown in the attachment. Since we had measurements for each end of the WBSC3 support tubes I also added a distance feature representing the measured length of each WBSC3 support tube.
Wrapping Up
Some points for discussion/further thought. Keep in mind that the BSC support tubes are not exact representations of where their respective optics are; we only aligned the optic during aLIGO install, and in the end didn't really care where the support tubes ended up as long as HEPI had enough range to work. This means that any deviation from nominal seen in the support tube ends is not an indication of misalignment of that chamber's optic.
This work was associated with LHO WP 12947, which also included the WBSC1 +X support tube ends. Those support tubes still have PEM interface plates installed, so we are currently unable to measure them (will do in the future once the plates are removed). Since we completed the rest of the measurements involved, I've closed the WP.
J. Kissel, D. Sigg, D. Barker ECR E2100485 ECR E2200401 WP 12901 Continuing on the deprecation of 18-bit DAC path (ECR E2100485), we upgraded the h1iscex's DAC0 card today from an 18- to a 20-bit DAC. One of the front-end models that use that DAC is the h1pemex model. Here's the before vs. after for the models. While there, I found and left the new ADC card from ECR E2200401's PEM sensor array expansion. I'd thought it was installed solely for characterizing the 32CH LIGO DAC, but it had only been temporarily used for that. It should be there! And also, the electric field meter ADC should also remain there. If the PEM team wants to account for the factor of 4x gain change in the DAC calibration, I installed new DACOUTF filters upstream of the GDS filters that are used to drive the DACs. The model has been committed to /opt/rtcds/userapps/release/pem/h1/models/ h1pemex.mdl : r28026 --> r34059
Randy and I installed new CR ceiling.
Betsy had a local company fabricate a C3 ceiling for our Mega Cleanroom. This ceiling has velcro opening to allow access for Septum removal. Opening extends to end of CR opening on the -X side and ends just short of the +X opening.
J. Kissel, M. Todd, S. Dwyer Just recording this for posterity in case: Matt and I wanted to (continue) parallelizing our work on characterizing the ISS Array at full / nominal power (60W into the PSL) and characterizing RPM dynamics for future HSTS Estimator modeling, respectively. The estimator team discovered a week or two ago that PRM has a different dynamical response when the SUS is ALIGNED vs. MISALIGNED. So, I misaligned IM4 and PR2 to ensure the 60W didn't go anywhere but a fixed location, and aligned PRM. The worry is that IM4 doesn't have a "safe" designated fixed location to dump its reflected beam when misaligned -- there's no "parking dump" like there is for PRM. So -- this an aLOG to indicate the times of high power with IM4 misaligned and what little info we have about the physical position. I say "what little information about the position we have" because IM4, which is a HAUX suspension -- while IM4 has recently had its OSEM sensor PD sat amp upgraded, we have not measured or installed an absolute calibration for the sensors with an ISI injection. We know from other suspensions, that OSEM PDs can have factors of 2x to 3x errors between the "generic calibration based on electronics and [likely ancient] open light current measurement" and the modern absolute calibration from the ISI GS13s. There *is* a calibration of the IM4 alignment sliders -- installed in Apr 2024 (LHO:77211). However, that calibration was based on the OSEM sensor PDs. So we have to take the fidelity of this calibration with a huge grain of salt a la the above distrust in OSEM PD calibration. So -- IM4 had the following alignment offsets requested of its sliders: OFFSET OUT16 ["urad"] [EB-DAC ct] P +114.539 +1248.53 Y +111.103 +625.387 and its *misalignment* offsets -- which are not calibrated in the front-end, but I've calibrated them using the (P,Y) = (10.9005 , 5.6289) [EB-DAC ct / "urad"] calibration from LHO:77211 here: OFFSET OUT16 ["urad"] [EB-DAC ct] P +50.915 +555.0 Y +98.598 +555.0 So, misaligned, that give a total requested displacement of OFFSET OUT16 ["urad"] [EB-DAC ct] P 165.454 1803.532 Y 209.701 1180.388 IM4 was misaligned, with PRM aligned and PR2 misaligned, and 60W into the IMC from 2025-10-28 16:08 UTC to 2025-10-28 17:06 UTC. After 17:06 UTC, the IMC power remained at 60W, but I aligned IM4 and PR2 and misaligned PRM. (The normal "IFO DOWN" configuration). (So yes, we didn't turn the IMC power down before we went from misaligned to aligned, either.)
There was a relatively small (~2E-9 Torr) pressure rise in HAM1, which is well aligned with these activities. Both its magnitude, and it's rate of rise are orders of magnitude smaller than a "proper pressure spike event", but it is worth mentioning. We'll keep an eye out.
Trying to narrow down why TMS x is involved in lock losses we have replaced the TMS coil driver that works on F1,2,3 and LF. Chassis S1102670 was replaced with S1102666. The operator returned the system to damping. This is a wait and see test.
We're assembling the first unit that incooporates all upgrades including the QPD tilt and here are minor problems we've stumbled upon. (No ISS array unit with an upgrade to tilt the QPD (E1400231) has been assembled before as far as I see and nobody seems to have cared to update all drawings.)
First picture is an example of the QPD before upgrade. QPD assembly (D1400139) and the cable connector assembly (D1300222) are mounted on the QPD platform by the QPD clamp plate (D1300963-v1, an older version) and a pair of split QPD connector clamps (d1300220). Two pieces of kapton insulation sheets are protecting the QPD assy from getting short-circuited to the platform.
After the upgrade, the QPD assy sits on top of a tilt washer (D1400146, called beveled C-bore washer) that tilts the QPD by 1.41deg in a plane that divides YAW and PIT plane by 45 degrees (2nd picture). The bottom kapton will go between the washer and the QPD platform plate.
Problem 1: Insulation between the QPD clamp and the QPD pins is a bit sketchy.
Titled QPD means that the bottom of the QPD assy is shifted significantly in YAW and PIT. A new asymmetric QPD clamp plate with tilted seating for the screws (D1300963-v2) has been manufactured to accommodate that. But we have no record of updated kapton insulators, so the center of the clamp bore doesn't agree with the kapton (3rd picture, note that the QPD rotation is incorrect in this picture, which had to be fixed when connecting the cable). Since the tilt washer is not captured by anything (it's just sandwiched between the clamp and the platform plate), it's not impossible to shift the QPD assy such that some of the QPD pins will be grounded to the clamp and thus to the QPD platform plate.
You must check that there's no electrical connection between the QPD assy and the platform each time you adjust the QPD position in the lab.
Problem 2: New QPD connector clamp posts are too long, old ones are too short.
Old posts for the QPD connector are 13/16" long, which is too short for the upgrade because of the tilt washer, see 4th picture where things are in a strange balance. It seems as if it's working OK, but you can wiggle the post a bit so the post slides laterally relative to the clamp and/or the platform, it settles to a different angle and suddnly things become loose. To avoid that, you tighten the screws so hard that they start bending (which may be already starting to happen in this picture).
Also, because the clamp positions are 45 degrees away from the direction of tilt, one clamp goes higher than the other.
To address these, somebody procured 1" and 15/16" posts years ago, but they're just too tall to the point where the clamps are loose. If anything, what we need are probably something like 27/32" and 7/8" (maybe 7/8" works for both).
We ended up using older 13/16" posts, but added washers. Two thin washers for the shorter clamp, two thin plus one thick for the taller one (5th picture). This works OK. Shorter screw is the original, longer screw was too long but it works.
Problem 3: It's easy to set the rotation of the QPD wrong.
When retrofitting the tilt washer and the newer QPD clamp plate, you must do the following.
I screwed up and put the QPD on the connector at a wrong angle. It's easy to catch the error because no quadrant responds to the laser, but it's better not to make a mistake in the first place. It will help if the QPD assy barrel is marked at the cathode-anode1 corner.
It seems that D1300222 and D1101059 must be updated. Systems people please have a look.
D1300222: A tilt washer (D1400146), a new QPD clamp (D1300963-v2) and two sheets of kapton insulation are missing. Spacers are longer than 13/16".
D1101059: Explicitly state that part #28 (D1300963, QPD clamp) must be D1300963-v2.
I installed the beam dumps (which are two plates of filter glass, probably from Schott?) for the array after cleaning them according to E2100057.
There are marks that look like water spots and/or some fog that couldn't be removed by repeated drag wiping with methanol (see picture).
After installation, I found that these plates are very loosely captured between two metal plates, see the video, this seems to be by design. I don't like it but the same design has been working in chamber for years.
To investigate the 70Hz feature in HAM1 chamber, which Jim reported in his alog (LHO 84638) I started looking into the structural resonances of the periscope which is installed in HAM1 (see two pictures which TJ sent me, was taken by Corey here - view01, view02) .
Betsy, handed me a periscope (similar but not exactly the same) for investigation purpose, which is now setup in staging building. I attached an accelerometer to the top of the periscope and connected it to the front end of the B&K setup for hammer impact measurements - see picture of the experimental setup here.
At first I used two dog clamps to secure the periscope. The results of the two dog clamp B&K measurement is shown in this plot (data from 0.125 to 200Hz)) - one can see a 39Hz feature in the Z hit direction. See zoomed-in (30-100Hz) figure here.
Next, I attached a third dog clamp, just like in HAM1 chamber and took a second round of measurements (especially for Z direction impact).
This plot compares the two vs three dog clamps scenario on the periscope and one can see that the resonance mode has been pushed up from 39Hz to 48Hz.
Morning (JennieW, Rahul, Keita)
We used the PRX flashes to align the POP path.
POP periscope location is good but the drawing is not.
The POP periscope position, which was set yesterday by Camilla and others, was right. That means that the drawing on D1000313-v19 is wrong. The periscope in reality is about an inch toward -Y direction relative to D1000313-v19. See the first picture, which was shot with a cellphone inserted under the top periscope mirror and looking straight down the bottom mirror. This means that the dichroic (M12) needed to be shifted by the same amount too.
Since the distance betwen the IFO and the lens for POP WFS doesn't matter that much, everything downstream (i.e. 90:10, PM1 tip-tilt, a lens, 50:50 and POP LSC as well as POP WFS) will be installed using the drawing.
We mainly rotated the periscope mirror clamps around the post for rough alignment, but we might have changed the mirror height by a millimeter or two in the process.
PM1, which is calld that because it's the 1st (and the last) suspended Mirror for POP, is somehow called RM3 in D1000313. Systems please fix it.
Set the IR beam spot height/position on the periscope as well as the dichroic
The IR beam is supposed to be about 6mm or 1/4" lower than the center line of both of the periscope mirrors as well as the dichroic. This is because the green ALS beams are supposed to be ~13mm higher than IR. See L1200282 “CPy-X, CPx-Y” case on Table 1.
Top Periscope Mirror
It was almost impossible to see how much the beam is lower than the center of the top and bottom periscope mirror. Using the IR viewer card, I and Jennie agreed that the beam is lower than the center, but we could not quantitatively say how much especially on the top. We'll leave it as is, and if the green beam from the end station is too high we will have to use pico because we periscope is already as high as possible.
Bottom peri mirror
If everything is as intended, the bottom periscope mirror is 4" high from the ISI surface and the POP beam is 1/4" lower than that, therefore the POP beam is (1-0.25*sqrt(2)) = 0.646" = 16.4mm away from the bottom edge of the mirror.
Using a ruler in chamber (and measuring the dimensions of a spare Siskiyou mount using caliper), the height of the bottom periscope mirror center was calculated to be ~4.07" from the ISI surface, i.e. 0.7" too high. This means that, when the beam height measured from the ISI is as designed (i.e. 4"-1/4"), the POP beam is (1-(0.25+0.07)*sqrt(2))=0.547"=13.9mm away from the bottom edge of the mirror.
If you have difficulty understanding this, see the cartoon.
POP beam radius is ~2mm, so 13.9mm (or even 13mm for that matter) looks like a safe distance to me. I don't see the need to readjust the height of the bottom periscope mirror.
I adjusted the top periscope mirror to set the beam height right after the bottom peri mirror to be ~3.75" using the IR viewer card and a ruler.
Dichroic
I placed the dichroic about 1" into -Y direction relative to the drawing (because I had to), and used the bottom periscope mirror to set the beam height close to the dichroic to be ~3.75".
Then I used the dichroic to steer the beam into the direction of the location for PM1 without placing 90:10.
For the beam profile measurement, the downstream alignment is done without 90:10. Later we will install 90:10 back in place and do the final alignment.
Fil Marc Daniel
We noticed that the photodiode pins of the in-air cable that connects to RM1 and RM2 were flipped. This will flip cathode and anode which will only matter if there is a bias applied.
Going thru the schematics it seems that with 1:1 wiring the PD anode and cathode are flipped compared to what is shown in Sat Amp D080276. I assume somebody noticed this and flipped the corresponding pins of the in-air cable to correct for it back in 2013. The polarity of the PD doesn't really matter, if there is no bias. We checked the RM sat amps and they have no bias.
If the Sat Amp PDs are connected as shown om D080276, the OSEM values will be negative. Indeed, the RMs had negative OSEM values as expected. However, all ZMs have positive values, since nobody bothered to flip the pins. We propose to no longer flip the PD pins for the RMs and work with positive OSEM values in the future.
J. Kissel First, supporting Daniel's findings that the RM1 and RM2 HTTS OSEM sensor readbacks have been incorrectly negative for ages, I attach a trend of the OSEM ADC input values (and OSEMINF OFFSETS and GAINs) back to 2017. Not said explicitly in the above aLOG -- Daniel / Fil / Marc installed fresh new DB25 Sat Amp to Vac Feedthru cables (D2100464) just after this aLOG as a part of cabling up the new signal chain for PM1. These cables are one-to-one pin-for-pin cables so it *should* have played no role in the sign of the sensors or how they're connected. However, it's now obvious that RM1 and RM2 have had the ADC input voltages as negative for a *very* long time. I reviewed the signal chains for the OSEM PDs; see G2500980. The RMs are using a US 8CH satamps D1002818 / D080276. I attach a screen-cap of page 4, which highlights that - UK 4CH satamps D0900900 / D0901284 use . a negative reverse bias configuration, with . anode connected to bias and cathode connected to the negative input of the TIA, and . an inverting differential amplifier stage - US 8CH satamps D1002818 / D080276 use . a positive reverse bias configuration, with . cathode connected to the bias and anode connected to the negative input of the TIA, and [hence the apparent "pin-flip" from the other two satamp types] . a non-inverting differential amplifier stage - US 4CH satamps D1900089 / D1900217use . a negative reverse bias configuration, with . cathode connected to the bias and anode connected to the negative input of the TIA, and . a non-inverting differential amplifier stage [hence the overall "sign flip" from the other two] I disagree with Daniel that "the polarity of the PD" i.e. how the anode and cathode are connected to the transimpedance amplifier. All versions of the PD pinout + SatAmp configure the system in a reverse bias, be it negative or positive. In these configurations, even in a zero bias configuration, photocurrent always flows from from cathode to anode as light impinges on the PD. So if the anode is hooked up to the negative input of the transimpedance amp (as in D1002818), that signal will have a different sign than if the cathode is hooked up to the negative input (as in D0900900 and D1900089). The RMs should have their *positive* bias from the D080276 circuit applied. In 2011, we'd agreed in G1100856 to jumper all OSEM satamps to the "L" position, a.k.a. the LIGO OSEM a.k.a. AOSEM position, which uses a bias voltage and is thus in photo conductive or pc mode. This is mostly because we wanted to not have to think about keeping track of which satamps are jumpered and which are not, but also because the BOSEM PD didn't mind have a bias, even though it was designed to have no bias. Given the "thought of 2nd to last, last, and never" history of the RMs as they traversed subsystem from ISC to SUS circa O1, moving from the ASC front-end to a SUS front-end circa O2, then never really appearing in wiring diagrams until O3, etc. it wouldn't surprise me if the RMs didn't get the memo to put the bias jumper in the "L" position jumpering pins 2 and 3. I disagree with Daniel: only the US 4CH satamp D1900089 / D1900217 should read negative with light on it. So, my guess is that that someone "in 2013" (i.e. during aLIGO install prior to O1) didn't understand these subtleties between the UK 4CH and US 8CH satamp, saw the "different from UK 4CH satamp" and tried fixing the pins of the in-air D25 from satamp to vacuum flange. Regardless, the new cable has cleared up the issue, and ADC voltage from RM1 and RM2 is now positive.
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
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%
In the attachment you will find the JAMMT model for the measured beam profile of the PSL pick off with the origin a SPI-BS1, as well as the lenses used to adjust the mode of the beam for the fiber collimator FC60-SF-4-A6.2-03.
J. Kissel scribing for S. Koehlenbeck, J. Oberling, R. Short, J. Freed ECR E2400083 IIET 30642 WP 12453 Another quick summary aLOG at the end of the day, with more details to come: - With the power in the ALS/SQZ pick-off path to 10 [mW] for beam profiling, - Installed a two lens system to handle the unexpectedly different beam profile of the ALS/SQZ pick-off path - Remeasured the resulting mode after the two lens system, and we're happy enough. We're gunna call them SPI-L1 and SPI-L2. - Installed steering mirrors SPI-M1 and SPI-M2. - Rotated ALS-HWP2 to increase the s-pol light in the ALS/SQZ/SPI path to return the power transmitted through SPI-BS1 going to the ALS/SQZ fiber collimator back to 50.5 [mW]. This set the SPI path to 186 [mW] with the PMC TRANS measured at 103.5 [W]. The ALS_EXTERNAL PD in transmission of ALS-M9 measured 31 [mW] ***. - Installed SPI-HWP1 and SPI-PBS01 - Measured the power at each port of SPI-PBS01, with the intent to optimize the SPI-HWP1 position to yield maximum p-pol transmission through SPI-PBS01. *** We expect this is lower than the goal of ~45 [mW] (from LHO:83927) because we've not yet re-aligned the ALS/SQZ fiber collimator path after the install of the SPI-BS1, which translates the beam a bit due to the thickness of the beam splitter. We intend to get back to this once we're happy with the SPI path.
Small correction to above is after installing SPI-HWP1 and SPI-PBS01, we adjusted HWP1 to have 20mW in transmission of PBS1 (not maximum quite yet) to start alignment into the fiber. Using the two steering mirrors downstream of PBS1 and the collimating lens in front of the fiber, Sina maximized the transmission as measured with the output of the fiber on a spare PD. We then took power measurements of the input and output of the fiber:
This is a good start, but with a target ratio of >80%, there's still more work to be done here improving the beam into the fiber collimator. Out current mode-matching solution claims we should have 95% mode overlap into the fiber, so hopefully the issue is alignment, but it's entirely possible we'll revisit the mode-matching to see if improvements can be made there too.
The attached photo represents the optical layout as it stands as of where we stopped today, with the new SPI fiber in blue on the left (north) side of the table.
Re-post of Ryan's picture at the end of day 2, labeled with the almost entirely complete SPI pick-off path. Critically here, this shows the PSL row/column grid, confirming that this whole ECR E1900246 ALS pick-off path is 2 rows "higher" in +Y than is indicated on the current version of the as built PSL drawing D1300348-v8.
Ryan grabbed another picture I attach here. This shows the ALS pick-off path on this day in order to support the identification that the beamline between ALS-M1, through the faraday ALS-FI1 and ALS-L1, etc stopping at ALS-M2 (not pictured) is on row 25 of the PSL table *not* row 23 as drawn in D1300348-v8. I attach both the raw picture and my labeled version. So, ya, ALS-M1 should have its HR surface centered on Row 25, Col 117. Note, the grid in the picture is labeling bolt holes. Because the optical elements are all ~4 inches above the table, the beams appear offset from the way they travel on along the grid given that the photo was taken at a bit of an angle from vertical. May the future updater of D1300348 bear this in mind.
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.
In the attachment you will find the fit with JAMMT to the measured beam profile data with offset correction:
| Distance (cm) | Radius horiz. (um) | Radius vert. (um) |
| 17.46 | 680.5 | 717 |
| 35.24 | 465 | 504 |
| 42.86 | 389 | 428.5 |
| 47.94 | 346.5 | 368 |
| 55.56 | 281.5 | 300.5 |
J. Kissel, S. Koehlenbeck, J. Oberling, R. Short, J. Freed ECR E2400083 IIET 30642 WP 12453 After this morning's kerfuffle / belated power-outage recovery with the PSL HVAC system was resolved, Sina, Ryan, and Josh began the procedure we're walking thru outlined in Section 1 of T2500024. We're keeping running notes on the fly at the bottom of the google-doc for now. In summary here, with more details to come, we got as far as - Clearing out some old IO equipment that unused and in the way of the SPI pick-off path - Measuring the power around ALS-PBS01 - Installing the new ALS/SPI 80R/20T beam splitter - Measuring the beam profile along the future SPI path, in reflection of this 80R/20T beam splitter.
Among the first things we did was measure the power at various places along the ALS beam path to get a good starting point. For the ~2W beams we used an Ophir 20C-SH (datasheet says accuracy of +/- 3%) and for ~100 mW beams we used a S401C, (datasheet says accuracy of +/- 7%). For laser safety, we would unlock the PMC and shutter the laser while we were placing these power meters, so I also kept track of the PMC TRANS to scale our measurements by input power appropriately. We did NOT turn on the PMC's intensity stabilization servo (ISS), for no particular reason other than we forgot to turn it on for the first measurement, and then wanted to stay consistent. This meant that the PMC TRANS itself was slowly noise at that +0.5 [w] level, so my reported values below are "eyeball averages." So, not exactly a NIST-level precision/accuracy setup, but good enough for sanity checks. As such, I'm not going to bother report uncertainty in the numbers below. Here're the results (again, this is prior to doing anything to the path). Times of measurements are all for 2025-04-15, and in UTC, such that trends of other PDs may be captured if need be. Location Power Meter [mW] PMC Trans [W] Time [UTC] (1) Going in to ALS-HWP2 2060 103.2 21:39 # expected: 2000 [mW]; good! (between ALS-L1 and ALS-HWP2) (2) p-pol in trans of ALS-PBS01 1970 102.8 22:17 # expected: 1950 [mW]; good! (between ALS-M2 and ALS-L2) (3) s-pol in refl of ALS-PBS01 49.4 103.2 21:44 # expected: 50 [mW]; good! (between ALS-L1 and ALS-M9) (4) s-pol in refl of ALS-M9 47.7 103.0 21:48 # 44.9 [mW] reported by ALS-C_FIBR_EXTERNAL_DC_POWERMON, which is in trans of ALS-M9 at this time; good! (between ALS-M9 and ALS-FC2) All of these powers match expectation quite exquisitely. My guess for the inconsistency of (4) with the EXTERNAL monitor PD is that the beam splitter ratio of ALS-M9 programmed into the beckhoff calibration of the PD's channel is a bit off, but this can be cross-checked later. We then installed SPI-BS1 (the 80R/20T BS), and cross-checked the reflectivity reported in LH0:83863. Location Power Meter [mW] PMC Trans [W] Time [UTC] (5) s-pol in refl of SPI-BS1 37.7 102.4 22:22 The PMC power is lower between (3) and (5), the input to the SPI-BS1 is different, so we need to scale the measurement a bit, Input Power to SPI-BS1 = 49.4 [mW] * (103.2 / 102.4) = 48.81 [mW] REFL power from SPI-BS1 = 37.7 [mW] Fractional reflection = 37.7 [mW] / 48.81 [mW] = 0.772 = 77% (from LHO:83863) = 77%. Thus, our results today are consistent with what Josh and Keita measured in the optics lab.
Pictures from the work on 2025-04-15. The first three attachments are without labels, just in case the pics are needed for something else in the future. The diagram we were working with (from the SPI ECR) is also attached here for convenience. The second three attachments *are* labeled, so I'll describe what happened using those. 20250415_some_optics_removed_labeled.jpg - This is (mostly) the how the team started the day: with the area where the SPI pick-off path is intended to go full of un-diagrammed spare/unused stuff. I highlight red circles everything that was removed in this first attachment. Additionally, before the picture was taken, ALS-M8 and ALS-FC1 were removed and the temporary large vertical beam block was installed. 20259415_all_optics_removed_labeled.jpg - This is the "after" all components cleared picture, and the table layout during the power measurements. As you can imagine, because of the lens tube on the SM1PD1A, there was no room between the PD and ALS-M9 to insert a power meter to measure the transmitted light thru ALS-M9. As such, we can't validate the beam-splitting ratio of that optic. Ah well. 20250415_end_day_1_labeled.jpg - This is how we left yesterday: We SPI-BS1 installed in its permanent location. Downstream, we sent the reflected beam into a WinCam head such that we could profile the beam incoming to the SPI path -- and assess whether we need lenses in order to adjust the beam size to match our fiber collimator. While we definitely saw the expected change in power and alignment at ALS-FC2, we elected to restore the power and alignment later.
J. Kissel, B. Lantz, E. Bonilla, D. Barker ECR E2400405 IIET 32526 WP 12459 Using a linear combination of LHO:83724, the google slides in G2402303, and talking to Brian/Edgard who arrived for their week long visit today -- we installed the OSEM estimator infrastructure today on PR3 *and* SR3. We've only filled in enough infrastructure to ensure that it's function is entirely OFF. Hopefully we'll get further this week. The new channels have been initialized in the safe.snap for PR3 and SR3. /opt/rtcds/userapps/release/sus/h1/burtfiles/ h1suspr3_down.snap h1sussr3_safe.snap We made edits to Brian / Edgard's work on common library parts, /opt/rtcds/userapps/release/sus/common/models HLTS_MASTER_W_EST.mdl SIXOSEM_T_STAGE_MASTER_W_EST.mdl medm screens /opt/rtcds/userapps/release/sus/common/medm/hxts SUS_CUST_HLTS_OVERVIEW_W_EST.adl /opt/rtcds/userapps/release/sus/common/medm/estim/ ESTIMATOR_OVERVIEW.adl CONTROL_6.adl (see attached notes for details). And then I made edits to /opt/rtcds/userapps/release/isi/h1/models/ h1isiham2.mdl h1isiham5.mdl to add PCIE Dolphin IPC senders to send out the calibrated ISI HAM ST1 GS13s that are pre-projected into the PR3 and SR3 suspension point euler basis, and then modified /opt/rtcds/userapps/release/sus/h1/models/ h1suspr3.mdl h1sussr3.mdl top level models to receive those IPC, and pipe them in to top of the new main libary part, the HLTS_MASTER_W_EST.mdl Finally, after Dave installed the model changes and restarted the ISIs and HLTSs, we edited the sitemap /opt/rtcds/userapps/release/cds/h1/medm/ SITEMAP.adl to use the HLTS_OVERVIEW_W_EST.adl. Everything file I mention above has been committed to its respective location in the svn. Screenshots of stuff will come in the comments.
h1isiham2 top level BEFORE vs. AFTER, focusing on the change to the output CART to PR3 EUL Suspension Point projections of IPC senders.
h1isiham5 top level BEFORE vs. AFTER, focusing on the change to the output CART to SR3 EUL Suspension Point projections of IPC senders.
Top level of h1suspr3 BEFORE vs. two AFTERs, one focusing on the IPC and the other on the main library block.
HLTS_MASTER_W_EST.mdl screenshot focusing on where the suspension point signals come in.
Some detail on the M1 block inside the HLTS_MASTER_W_EST, because I've cleaned up how the ISIFF is added into the ISC signals. This is the SIXOSEM_T_STAGE_MASTER_W_EST block. Part of the cleanup is to create a new subsystem block ADDFF, so we now have EPICs monitors and test points before and after the ADD. These will be useful for commissioning.
Here's the HLTS MEDM screen overview now, with the new parts highlighted. The second attachment here is a preview of what the infrastructure.
J. Oberling, R. Crouch
Today we took pre-deinstall measurements of the position of the optical table surface of the WHAM1 passive stack. The plan was to use the FARO to measure the coordinates of several bolt holes, using a threaded nest that locates the Spherically Mounted Retroreflector (SMR) precisely over the bolt hole, on both the +Y and -Y side of the chamber. This, unfortunately, did not happen in full due to the untimely death of the FARO's climate sensor (or the FARO's ability to read the climate sensor, we're hoping for the former). The FARO cannot function without this sensor as it relies on accurate measurements of the air temperature, relative humidity, and air pressure to feed into a model of the refractive index of air, which it needs to accurately calculate the SMR distance from the FARO. We did manage to get a few points measured before the sensor died. I've reached out to FARO tech support about getting a new climate sensor and should hear back from them tomorrow (they usually replay in 1 business day).
Summary
We were able to get measurements of 3 bolt holes, all in the furthest -Y line of bolt holes, and an old IAS monument from aLIGO install before the FARO's climate sensor died. The results are listed below under the Results heading. The most interesting thing here is there appears to be an error in WHAM1 placement in the x-axis, as the bolt holes we measured are all ~37.25 mm too far in the -X direction from nominal. We also set a scale on the wall across from the -Y door of the WHAM1 chamber that is registered to the current elevation of the optical table; placing an autolevel so it sights 150.0 mm on this scale (sighting the side of the scale with the 0.5 mm tick marks) places that autolevel 150.0 mm above the surface of the passive stack's optical table.
Details
We started on the -Y side of the WHAM1 chamber. The FARO was set with a good view of its alignment monuments and the passive stack's optical table. We ran through the startup checks and calibrations without much issue (we did see a return of the odd 'ADM Checks Failing' error, which had been absent for about 1 month, but it immediately went away and didn't come back when we performed a Go Home operation). FARO monuments F-CS026 through F-CS035, inclusive, were used to align the FARO to the LHO LVEA local coordinate system; the 2 standard deviation device position uncertainty after this alignment was 0.016 mm (PolyWorks does 100 Monte Carlo simulations of the device position). This complete, we started measuring.
First, as a quick test of the alignment we took a look at old IAS monument LV24. This monument was used to align the WHAM2 ISI during aLIGO install, and its nominal X,Y coordinates are [-20122.0, -3050.7] mm (there is no z-axis coordinate as we were not setting these in Z back then, a separate set of wall marks was used for z-axis alignment). The results are shown in the 1st attached picture; again, ignore the z-axis results as I had to enter something for the nominal or PolyWorks wouldn't accept the entry, so I rounded to the closest whole number (this isn't even the surface of the monument, it's the point 2" above it where the SMR was, due to use of the Hubbs Center Punch Nest (which has a 2" vertical offset when using a 1.5" SMR)). Knowing how we had to set these older monuments, since I'm one of the people that set them, I'm not entirely surprised by the X and Y deviations. The monuments we set for aLIGO install (the LV monuments) were placed w.r.t. a set of monuments used to align iLIGO, which themselves were placed w.r.t. the monuments used to install the vacuum equipment during facility construction (the PSI monuments), which themselves were placed w.r.t. the BTVE monuments which define the interface between the arm beam tubes and the LVEA vacuum equipment, which we then found errors in their coordinates during our alignment of the FARO during the O4a/b commisioning break in 2024. Not at all surprised that errors could have stacked up without notice over all of those monuments set off of monuments set off of monuments set off of... Also, take note of the x-axis coordinate of this monument, this will be important later.
We then set about taking measurements of the passive stack optical table. To map the bolt holes we measured we used an XY cartesian basis, assuming the bolt hole in the -X/-Y corner was the origin. We then proceeded to increment the number by the bolt hole (not distance), following the same XY axis layout used for the IFO. Using this scheme the bolt holes for the table corners were marked as:
We were able to get measurements for bolt holes (0,0), (14,0), and (25,0). We were in the process of measuring bolt hole (36,0) (the +X/-Y corner bolt hole) when the FARO's climate sensor died.
To get the coordinates for the bolt holes I used the .EASM file for WHAM1 with the passive stack configuration located at D0901821-v4. From the assembly, using eDrawings, I was able to get coordinates w.r.t. the chamber origin for the bolt holes we measured. Those were then added to the coordinates for the WHAM1 chamber, in the LVEA local coordinate system, to get nominal coordinates for the bolt holes. I also had to add 25.4 mm to the z-axis coordinates to account for the 1" offset of the nest we were using for the SMR; the center of the SMR sits 1" above the point being measured, so I needed to manually add that offset to the nominal z-axis coordinate of the bolt hole. For reference, according to D0901821 the global coordinates for WHAM1 are [-22692.0, 0.0, 0.0] mm; when converted to the LVEA local coordinate system (removing the 619.5 µrad downward tilt of the X-arm) this becomes [-22692.0, 0.0, +14.1]. The measurement results are shown in the 2nd attached picture. Notice those x-axis deviations? Remember the measurement we made of LV24? Clearly the FARO alignment is not 37 mm off, as the measurement of LV24 showed, so something is definitely up with the x-axis coordinate of the WHAM1 chamber (error in chamber placement? aLIGO WHAM1 is the iLIGO WHAM2 chamber, moved from its old location next to WHAM3).
Results
We can do some analysis of the numbers we have, although limited since we only have 3 points in a line. This really only applies to the furthest -Y line of bolt holes on the table, since we weren't able to get measurements of the +Y side to get a more full picture of where the table is sitting, but it's something. Position tolerances at install in 2012 were +/-3.0 mm in all axes.
I do want to note that D0901821-v4 claims the table surface should be -187.8 mm in LVEA local coordinates (-201.9 mm in global), but this is not the number we used when installing the passive stack in 2012. In 2012 we used -185.9 mm local (-200.0 mm global), as can be seen in D0901821-v2. To compare our measurements to the install numbers I changed the nominal z-axis coordinate to match that of our install target (-185.9 + 25.4 mm SMR offset = -160.5 mm) and the results are shown in the final attached picture.
Wall Scale Registered to Current Table Surface Elevation
To finish, we set a scale on the -Y wall directly Crane East of the WHAM1 chamber and registered it to the current elevation of the passive stack's optical table. To do this we used a scale provided by Jim (the scale was in inches, with 0.01" tick marks) and an autolevel. We set the autolevel at a fixed elevation on the -Y side of the chamber. The scale was then placed at each corner of the optical table, starting with the -X/+Y corner, and the autolevel was used to sight the scale; only the scale was moved, the autolevel was fixed (rotated only to follow the scale, but not moved otherwise). We then averaged the 4 scale readings to get the table elevation, set the autolevel to this reading with the scale back at our starting point (we actually didn't have to move it, thankfully), and then set a scale on the wall using the autolevel. The 4 scale readings:
The average of the 4 readings is 5.9", and since the autolevel was already sighting 5.9" on our starting point at the -X/+Y corner we left it there. This may seem high, but we had to have the autolevel high enough that we could see over the various components mounted to the table surface. We then turned the autolevel and set a scale on the wall. This scale was in mm (since that's what we had), but this worked out OK. 5.9" is ~149.9 mm (149.86 mm to be exact), so we set the wall scale so it read ~149.9 mm when sighted through the autolevel. So a 150.0 mm reading on this scale (sighting the side with the 0.5 mm tick marks) is ~150.0 mm above the current position of the passive stack's optical table.
This closes LHO WP 12442.
TJ O'Hanlon informed me via email that there indeed was an error in the x-axis coordinate at both LHO and LLO, due to the thickness of the septum between HAM1 and HAM2 not being taken into account, which had not been propagated to all of the SYS mechanical layout drawings (and some of the CAD files as well). I had completely forgotten about this, and explains why we had moved the WHAM1 passive stack monument LV25 further in the -X direction some time back in 2012; the first attached picture shows this (the clear cut out next to the existing monument was the old position of LV25 before we moved it). I went spelunking through my old 2012 emails to find some communication about this, but all I could find was an email chain re: LLO setting the LHAM6 support tubes and not being able to get them in the proper y-axis position. Dennis replied that this was due to the septum thickness and would apply to HAM1 and HAM6 at both sites, and that he would update E1200625 with the correct coordinates for all involved chambers. From E1200625 the x-axis coordinate of WHAM1 should be -22726.7 mm, so I have updated the PolyWorks project with this new, correct coordinate; this is shown in the 2nd attached picture.
From this I can now say that the -Y row of holes on the WHAM1 passive stack's optical table are ~2.56 mm too far in the -X direction. If we were to use the FARO to survey monument LV25 my guess is that would explain the 2.5 mm error, seeing as how nearby LV24 was also ~2.0 mm too far in -X direction. As stated in the main alog this difference doesn't exactly surprise me given the "monuments placed off of monuments placed off of monuments" situation we have here. The FARO was aligned to our X and Y axes using monuments PSI-1, PSI-2, PSI-6, and BTVE-1, so any error between these 1st and 2nd generation monuments and the 4th generation LV monuments will be measured by the FARO.
While I was at it I went ahead and applied the required transform for local to global coordinates. This is done by creating a new coordinate system and applying the requisite tilt of both the X and Y axes. The tilt must be entered in degrees and for the opposite axis. This is because our, for example, y-axis tilt angle w.r.t. local gravity is a rotation of the x-axis. Since PolyWorks works off of axis rotation, we enter the y-axis angle as an x-axis tilt (same for the x-axis angle). To get PolyWorks to correctly calculate the transform matrix both values should be entered as positive numbers (I'm not entirely sure why). The values to enter:
The calculated transform matrix is shown in the 4th attached picture, which properly matches Table 10 in T980044 (note, the numbers in the transform matrix are in radians, even though I had to enter the rotations in degrees). To confirm this was correct I manually calculated the correct global z-axis coordinate using the formula in Section 2.3 of T0900340 for each bolt hole; the results were the same between my calculation and PolyWorks'. The final picture shows the bolt hole survey in the LHO global coordinate frame.
Jeff asked me to plot a comparison for SR3 M1 between all degrees of freedom comparing it in vacuum versus in air. I've plotted the last two measurements taken for SR3 from last August at the end of the OFI vent. One measurement was taken in air, and the other was taken in vacuum The pressure for the in vacuum measurement wasn't all the way down to our nominal, but as Jeff said in his alog at the time when we were running these measurements: "most of the molecules are out of the chamber that would contribute to buoyancy, so the SUS are at the position they will be in observing-level vacuum" (79513).
Calling out the "interesting" off-diagonal elements:
D R I V E D O F
L T V R P Y
L -- nc nc meh eand YI
R T nc -- YI eand nc meh
E
S V meh YI -- meh nc YI
P
R VI esVI VI -- YI VI
D
O P esVI VI YI meh -- YI
F
Y YI nc nc nc nc --
Here's the legend to the matrix, in order of "interesting":
VI = Very Interesting (and unmodeled); very different between vac and air.
esVI = Modeled, but Still Very Interesting; very different between vac and air
YI = Yes, Interesting. DC response magnitude is a bit different between vac and air, but not by much and all the resonances show up at roughly the same magnitude.
meh = The resonant structure is different in magnitude, but probably just a difference in measurement coherence
eand = The cross coupling is expected, and not different between air and vac.
nd = Not Different (and unmodeled). The cross-coupling is there, but it doesn't change from air to vac.
I've bolded everything above "meh" to help guide the eye.
Recapping in a different way, because the plots are merged in a really funky order,
VI = L to R (pg 14),
T to P (pg 22),
Y to R (pg 33)
esVI = T to R (pg 16)
L to P (pg 20)
YI = L to Y (pg 28), Y to L (pg 27),
T to V (pg 12), V to T (pg 11),
V to P (pg 24),
P to R (pg 25),
Y to V (pg 31),
Y to P (pg 35)
What a mess!
The matrix of interesting changes is NOT symmetric across the diagonal
The matrix has unmodeled cross-coupling that *changes* between air and vac
For the elements that are supposed to be there, (like L to P / P to L and T to R / R to T), the cross coupling different between air and vacuum.
For some elements, the cross-coupling is *dramatically worse* at *vac* than it is at air.
Why is there yaw to roll coupling, and why is it changing between air and vacuum??
There's clearly more going on here than just OSEM sensor miscalibration that the Stanford team found with PR3 data in LHO:83605. These measurements are a mere 8 days apart!
The plan *was* to use SR3 as a proxy during the vent to test out the OSEM estimator algorithm they were using to improve yaw, but ... with this much different between air and vac, I'm not so sure the in-air SR3 measurements to inform an estimator to be used at vacuum.
HAM1 Before Photos: (HAM1 chamber open just under 90min for this activity)
This morning before the deinstall activities begin, took the opportunity to photo document the HAM1 optical layout. Keita requested I take photos to record the layout wrt to the iLIGO bolt pattern, because rough alignment of optical components on the new SEI ISI for HAM1 will be done utilizing the bolt patterns of the Optics Tables; so I took a few more photos than normal (top view and angled with a focus on the REFL path). Took large photos with the Canon 60D DSLR camera as well as my camera phone.
The photos are being populated in this Google Drive folder: https://drive.google.com/drive/folders/1yDKp7aByA_TYJ12c8j8BnZM_pd1Q2DBZ?usp=sharing
Naming each photo referencing an updated layout Camilla Compton made which labels all beam dumps, but I also had to use an older layout to preserve naming since the layout on HAM1 currently looks like D1000313v16 (which is also referenced for naming the photos).
The above folder has the Canon photos, and I'll be adding the camera phone images next.
Contamination Control Notes:
Tagging ISC, SUS, SYS, and SEI. Rest in power HAM1 Stack!
J. Kissel, R. McCarthy, M. Pirello, O. Patane, D. Barker, B. Weaver 2025-04-06 Power outage: LHO:83753 Among the things that did not recover nicely from the 2025-04-06 power outage was the +18V DC power supply to the SUS ITMY / ITMX / BS rack, SUS-C5. The power supply lives in VDC-C1 U23-U21 (Left-Hand Side if staring at the rack from the front); see D2300167. More details to come, but we replaced both +/-18V power supplies and SUS ITMY PUM OSEMs satamp did not survive the powerup, so we replaced that too. Took out +18V Power Supply S1300278 -18V Power Supply S1300295 ITMY PUM SatAmp S1100122 Replaced with +18V Power Supply S1201919 -18V Power Supply S1201915 ITMY PUM SatAmp S1000227
And now... the rest of the story. Upon recovery of the suspensions yesterday, we noticed that all the top-mass OSEM sensor values for ITMX, ITMY, and BS were low, *all* scattered from +2000 to +6000 [cts]. They typically should be typically sitting at ~half the ADC range, or ~15000 [cts]; see ~5 day trend of the top mass (main chain, M0) OSEMs for H1SUSBS M1,ITMX M0, and H1SUSITMY M0. The trends are labeled with all that has happen in the past 5 days. The corner was vented on Apr 4 / Friday, so that changes the physical position of the suspensions and the OSEMs see it. At the power outage on Apr 6, you can see a much different, much more drastic change. Investigations are rapid fire during these power outages, with ideas and guesses for what's wrong are flying everywhere. The one that ended up having fruit was that Dave mentioned that it looked like "they've lost a [+/-18V differential voltage] rail or something," -- where he's thinking about the old 2011 problem LLO:1857 where - There's a SCSI cable that connects the SCSI ports of a given AA chassis to the SCSI port of the corresponding ADC adapter card on the back of any IO chassis - The ADC Adapter Card 's port has very small, male pins that can be easy bent if one's not careful during the connection of the cable. - Sometimes, these male pins get bent in such a way that the (rather sharp) pin stabs into the plastic of the connecter, rather than into the conductive socket of the cable. Thus, (typically) one leg, of one differential channel is floating, and this manifests digitally in that it creates an *exact* -4300 ct (negative 4300 ct) offset that is stable and not noisy. - (as a side note, this issue was insidious: once one bent male pin on the ADC adapter card was bent, and mashed into the SCSI cable, that *SCSI* cable was now molded to the *bent* pin, and plugging it in to *other* adapter cards would bend previously unbent pins, *propagating* the problem.) Obviously this wasn't happening to *all* the OSEMs on three suspensions without anyone touching any cables, but it gave us enough clue to go out to the racks. Another major clue -- the signal processing electronics for ITMX, ITMY and BS are all in the same rack -- SUS-C5 in the CER. Upon visiting the racks, we found, indeed, that all the chassis in SUS-C5 -- the coil drivers, TOP (D1001782), UIM (D0902668) and PUM (D0902668) -- had their "-15 V" power supply indicator light OFF; see FRONT and BACK pictures of SUS-C5. Remember several quirks of the system that help us realize what's happened (and looking at the last page of ITM/BS wiring diagram, D1100022 as your visual aide): (1) For aLIGO "UK" suspensions -- the OSEM *sensors'* PD satellite amplifiers (sat amps, located out in the LVEA within the biergarten) that live out in the LVEA field racks are powered by the coil drivers to which their OSEM *coil actuators* are connected. So, when the SUS-C5 coil drivers lost a differential power rail, that makes both the coils and the sensors of the OSEM behave strangely (as typical with LIGO differential electronics: not "completely off" just "what the heck is that?"). (2) Just as an extra fun gotcha, all of the UK coil drivers back panels are *labeled incorrectly* so that the +15V supply voltage indicator LED is labeled "-15" and the -15V supply is labeled "+15". So, this is why the obviously positive 18V coming from the rack's power rail is off, but the "+15" indicator light is on an happy. #facepalm (3) The AA Chassis and Binary IO for these SUS live in the adjacent SUS-C6 rack; it's + and - 18V DC power supply (separate and different from the supplies for the SUS-C5 rack) came up fine without any over-current trip. Similarly the IO chassis, which *do* live in SUS-C5, are powered by a separate single-leg +24V from another DC power supply, also coming up fine without over-current trip. So, we had a totally normal digital readback of the odd electronics behavior. (4) Also note, at this point, we had not yet untripped the Independent Software Watch Dog, and the QUAD's Hardware Watchdog had completely tripped. So, if you "turn on the damping loops" it looks like nothing's wrong; at first glance, it might *look* like there's drive going out to the suspensions because you see live and moving MASTER_OUT channels and USER MODEL DAC output, missing that there's no IOP MODEL DAC output. and it might *look* like the suspensions are moving as a result because there are some non-zero signals coming into on OSEMINF banks and they're moving around, so that means the damping loops are doing what they do and blindly taking this sensor signal, filtering it per normal, and sending a control signal out. Oi. So, anyways, back to the racks -- while *I* got distracted inventorying *all* the racks to see what else failed, and mapping all the blinking lights in *all* the DC power supplies (which, I learned, are a red herring) -- Richard flipped on the +18V power supply in VDC-C1 U23, identifying quickly that it had over-current-tripped when the site regained power. See the "before" picture of VDC-C1 U23 what it looks like tripped -- the "left" (in this "front of the rack" view) power supply's power switch on the lower left is in the OFF position, and voltage and current read zero. Turning the +18V power supply on *briefly* restored *all* OSEM readbacks, for a few minutes. And then the same supply, VDC-C1 U23, over-current tripped again. So Richard and I turned off all the coil drivers in SUS-R5 via their rocker switches, turned on the VDC-C1 U23 left +18V power supply again, then one-by-one powered on the coil drivers in SUS-C5 with Richard watching the current draw on the VDC-C1 U23 power supply. Interesting for later: when we turned on the ITMY PUM driver, he shouted down "whup! Saw that one!" With this slow turn on, the power supply did not trip and power to the SUS-R5 held, so we left it ...for a while. Richard and I identified that this rack's +18V and -18V power supplies had *not* yet had their fans upgraded per IIET:33728. Given that it was functioning again and having other fish to fry, we elected to not *yet* to replace the power supplies. Then ~10-15 minutes later, the same supply, VDC-C1 U23, over-current tripped again, again . So, Marc and I went forward with replacing the power supplies. Before replacement, with the power to all the SUS-C5 rack's coil drivers off again, we measured the output voltage of both supplies via DVM: +19.35 and -18.7 [V_DC]. Then we turned off both former power supplies and swapped in the replacements (see serial numbers quoted in the main aLOG); see "after" picture. Not knowing better we set the supplies to output to a symmetric +/-18.71 [V_DC] as measured by DVM. Upon initial power turn on with no SUS-R5 coil drivers on, we measured the voltage from an unused 3W3 power spigot of the SUS-R5 +/-18 V power rail, and measured a balanced +/-18.6 [V_DC]. Similar to Richard and I earlier, I individually turned on each coil driver at SUS-C5 while Marc watched the current draw at the VDC-C1 rack. Again, once we got the ITMY PUM driver we saw a large jump in current draw. (this is one of the "important later") I remeasured the SUS-R5 power rail, and the voltage on positive leg had dropped to +18.06 [V_DC]. So, we slowly increased the requested voltage from the power supply to achieve +18.5 [V_DC] again at the SUS-R5 power rail. This required 19.34 [V_DC] at the power supply. Welp -- I guess whomever had set the +18V power supply to +19.35 [V_DC] some time in the past had come across this issue before. Finishing up at the supplies, we restored power / turned to all the remaining coil drivers had watched it for another bit. No more over-current trips. GOOD! ... but we're not done! ... upon returning to the ITMY MEDM overview screen on a CDS laptop still standing by the rack, we saw the "ROCKER SWITCH DEATH" or "COIL DRIVER DEATH" warning lights randomly and quickly flashing around *both* the L1 UIM and the L2 PUM COILOUTFs. Oli reported the same thing from the control room. However, both those coil drivers power rail lights looked fine and the rocker switches had not tripped. Reminding myself that these indicator lights are actually watching the OSEM sensor readbacks; if the sensors are some small threshold around zero, then the warning light flashes. This was a crude remote indicator of whether the coil driver itself had over-current tripped because again, the sensors are powered by the coil driver, so if the sensors are zero then there's a good chance the coil driver if off. But in this case we're staring at the coil driver and it reports good health and no rocker switch over-current trip. However we see the L2 PUM OSEMs were rapidly glitching between "normal signal" of ~15000 [cts] and a "noisy zero" around 0 [ct] -- hence the red, erratic (and red herring) warning lights. Richard's instincts were "maybe the sat amp has gone in to oscillations" a la 2015's problem solved by an ECR (see IIET:4628), and suggest power cycling the sat amp. Of course, these UK satamps () are another design without a power switch, so a "power cycle" means disconnecting and reconnecting the cabling to/from the coil driver that powers it at the satamp. So, Marc and I headed out to SUS-R5 in the biergarten, and found that only ITMY PUM satamp had all 4 channels' fault lights on and red. See FAULT picture. Powering off / powering on (unplugging, replugging) the sat amp did not resolve the fault lights nor the signal glitching. We replaced the sat amp with a in-hand spare and fault lights did NOT light up and signals looked excellent. No noise, and the DC values were restored to their pre-power-outage values. See OK picture. So, we're not sure *really* what the failure mode was for this satamp, but (a) we suspect it was a victim of the current surges and unequal power rails over the course of re-powering the SUS-C5 rack, which contains the ITMY PUM coil driver that drew a lot of current upon power up, which powers this sat-amp (this is the other of the "important later"); and (b) we had a spare and it works, so we've moved on with post-mortem to come later. So -- for all that -- the short answer summary is as the main aLOG says: - The VDC-C1 U23 "left" +18V DC power supply for the SUS-R5 rack (and for specifically the ITMX, ITMY, and BS coil drivers) over-current tripped several times over the course of power restoration, leading us to - Replace both +18V and -18V power supplies that were already stressed and planned to be swapped in the fullness of time, and - We swapped a sat-amp that did not survive the current surges and unequal power rail turn-ons of the power outage recovery and subsequent investigations. Oi!
J. Kissel, M. Pirello 2025-04-06 Power outage: LHO:83753 Among the things that did not recover nicely from the 2025-04-06 power outage was the Timing Comparator D1001370 that lives in ISC-C2 U40 (see component C261 on pg 3 of D1900511-v9). The symptom was that its time-synchronizing FPGA was caught in a bad state, and the timing fanout in the CER Beckhoff status for the comparator was reporting that H1:SYS-TIMING_C_FO_A_PORT_13_NODE_UPLINKUP was in error (a channel value of zero instead of one). We didn't know any of this at the start of the investigation. At the time of investigation start, we only new of an error by following through the automatically generated "SYS" screens (see attached guide), SITEMAP > SYS > Timing > Corner A Button [which had a red status light] > TIMING C_FO_A screen Port 13, dynamically marked as a "C" for comparator [whose number was red, and the status light was red] > Hitting the "C" opens the subscreen for TIMING C_FO_A NODE 13, which shows that red "Uplink Down" message in the middle right The screenshot shows the NODE 13 screen both in the "now" fixed green version state, and a time-machined "broken" version. Going out to the CER, we found that status light for Digital Port 13 == Analog Port 14 on the timing fanout (D080534; ISC-C3 U11) was blinking. Marc tried moving the comms cable to analog port 16, because "sometimes these things have bad ports." That didn't work, so we moved it back to analog port 14. That port's comms fiber cable was not labeled, so we followed it physical to find its connection to the SQZ timing comparator (again in ISC-C2 U40, thankfully "right next door"), to find it's "up" status light also blinking. Marc suggested that the comparators may lose sync, so we power cycled it. This chassis doesn't have a power switch, so we simply disconnected and reconnected its +/-18 V power cable. After waiting ~2 minutes, all status lights turned green. #FIXEDIT