david.barker@LIGO.ORG - posted 08:12, Friday 02 August 2024 (79428)
Fri CP1 Fill
Fri Aug 02 08:05:54 2024 INFO: Fill completed in 5min 50secs
Images attached to this report
Fri Aug 02 08:05:54 2024 INFO: Fill completed in 5min 50secs
As Ryan C reported yesterday, LVEA dust 5 is reporting a low battery and dust 6 stopped running 16:28 Wed 31jul2024 PDT. Attachment shows MEDMs and 7 day trends of 300nm particulate counts.
I power cycled DM6 which was frozen and I found DM5 unplugged so I plugged it back in and turn it back on. DM5 is in the cleanroom by HAM3 and it needs to be turned back off when we go back to observing(OPSInfo).
I was running the TFs for SRM to confirm that the suspension is good before we close HAM5, but the transfer function for L was a noticable amount lower in magnitude as compared to the measurements taken on July 17th right before we vented HAM5(pdf). We reran L but this time with the OPTICALIGN offsets turned ON, and the results matched our pre-vent measurements, which seemed strange and prompted looking into whether the RT OSEM has a problem. I've looked back at the state of SRM when the July 17th transfer functions were run, and T, V, R, P, and Y were run in DAMPED and OPTICALIGN offsets were OFF(T&R, V&Y, P). HOWEVER, when the L transfer function was run, SRM was ALIGNED and OPTICALIGN offsets were ON (P: 4254, Y: -9231)(L pre-vent). So that's why today's regular (offset OFF) L didn't match the pre-vent L, and why my second measurement of L with the offset on did match.
Yaw is the only other dof that was affected by the offsets being ON vs OFF, but the pre-vent Y measurements were taken with the offsets OFF, and these match with today's offset OFF measurements so we're all good there.
I'm not sure if there are still concerns about the RT OSEM on SRM M1, now that we know why L matches the pre-vent L, so I'm not sure if these results clear us for closing HAM5 or not.
Main set of measurement results (2024-08-01_2000) - SRM DAMPED, OPTICALIGN offset OFF:
$(sussvn)/HSTS/H1/SRM/SAGM1/Results/2024-08-01_2000_H1SUSSRM_M1_ALL_TFs.pdf
Second set of measurement results (2024-08-01_2200) - SRM DAMPED, OPTICALIGN offset ON:
$(sussvn)/HSTS/H1/SRM/SAGM1/Results/2024-08-01_2200_H1SUSSRM_M1_ALL_TFs.pdf
Full comparison of Pre-Vent, Post-Vent offset OFF (main) set, and Post-Vent offset ON set
$(sussvn)/HSTS/Common/Data/allhstss_2024_July17vAug01_H1SUSSRM_M1_PreVsPostOFIVent_ALL_TFs.pdf
I agree with Oli that SRM will be "as good as it has been between 2021 and 2024" if we leave it as is, but for different, more expanded reasons covered below.
To expand on Oli's "RT OSEM has a problem" -- the issue is that with the alignment offsets OFF, the RT (right) OSEM sensor / flag has expanded enough that the flag is only barely occulting the LED / PD beam, close to "open light." Thus the drop in magnitude response for Length and Yaw, the only two DOFs that use the RT OSEM. In fact, the M2 UL and M3 UL OSEMs, i.e. the lower stage left OSEMs are further *engaged*, close to "closed light." This is consistent with an overall positive yaw (+RZ) of the suspension w.r.t. the cage.
The *current* SRM alignment offsets are
(P: 1663, Y: -3095 [urad]) 2024-08-01, post OFI recovery and aux laser alignment, in air, HEPI locked
This digital request of *negative* ~3 millirads of yaw *centers* the OSEMs, implying that the OSEMs have been centered to the *alignment offsets ON* position. With the OSEMs centered, the magnitude of the response increases and looks cleaner because both LF and RT are contributing to measurement of the L and Y DOFs.
This checks out with the last time that we moved the OSEMs w.r.t. to the flags -- in 2021 -- see LHO:60576 where our goal was to keep the physical alignment of the optic the same, even though moving the OSEMs changes the digital request to get there. In that case, we kept the physical alignment and centered the top mass OSEMs to the alignment offsets ON, preserved physical alignment.
Importantly -- the result of the 2021 adventure of reproducing in-vac alignment while the IFO was in air was to leave the alignment offsets at
(P: 1738.28, Y: -3296 [urad]) 2021-11-08 (LHO:60578)
which is within 200 [urad] of the current slider values, and where the OSEMs are reasonably centered and responding well now.
These are also consistent with pre-vent in 2024 with OFI KTP damage in place, where with HAM5/6 HEPIs locked, a single-bounce IFO beam was used to find a good alignment
(P: 2192, Y: -3166 [urad]) 2024-07-17 (LHO:79246)
The offsets that Ibrahim used only on the L DOF during the July 17th health check, as Oli quotes, are:
(P: 4254, Y: -9231 [urad]) 2024-07-17 (LHO:79202)
which I believe were some very-lost, very-brief, temporary "I didn't realize HEPI was locked" alignment state used just prior to the official single bounce restoration later that day, LHO:79246, so the values of these should be ignored.
Finally, I attach a trend of the SRM alignment offsets over the last 4 months of sordid history with the OFI's KTP damage, covering both in-air and in-vac, HEPI unlocked and unlocked.
This also confirms that SRM's alignment, in all of these scenarios, is never needed to be outside of the
(P: 1600-2400 [urad], Y: 3000-3500 [urad])
range, i.e. less than 1 [mrad] from the 2021 positions (and the I suspect the large low pitch request after venting is the need to account for bouyancy of the optic, so really the alignment should stay within 0.5 pmrad] = 500 [urad] of those 2021 values.)
Note that this requested alignment range consumes a little less than half of the DAC range at ~50000 [ct] for the pitch OSEMs (T2 and T3) and yaw OSEMs (LF and RT).
Thus, if we just leave SRM alone, I suspect we'll be just as happy the SRM alignment and OSEM performance as we were between Nov 2021 until Jul 2024. This was the same decision we made in 2021. We'll just have to somehow remember that, for SRM, in order to get centered OSEMs to provide a OK performance on the top-mass "health check" transfer functions, we need the alignment offsets ON and in within 500 [urad] of (P: 2200, Y: -3300 [urad]). We can test where the boundaries of the alignment slider requests vs. RT OSEM performance decay during pump-down.
That being said, if we really want to mechanically relieve the yaw offset and restore centering of M1 RT (and M2 & M3 UL) we can...
Opened IIET Ticket 31769, to record that we've thought carefully about this decision to "let the 2021 OSEM position and SRM mechanical alignment ride," but that we reserve the right to try to mechanically offload *next* time. Hopefully the ticket and this aLOG series provides enough breadcrumbs to remember that we should relieve the alignment when we have the AUX laser set up already.
TITLE: 08/01 Day Shift: 1430-2330 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Corrective Maintenance
INCOMING OPERATOR: None
SHIFT SUMMARY: Today's work was mostly lots of final checks/cleaning before we can close the enclosures. Doors are not on, but HAM6 TFs show that we are good to go(SUS, SEI), and we are having problems with one of the OSEMs on SRM M1 on HAM5, so we'll be looking at that more tomorrow.
LOG:
| Start Time | System | Name | Location | Lazer_Haz | Task | Time End |
|---|---|---|---|---|---|---|
| 15:07 | FAC | Karen | LVEA | n | Tech clean | 16:04 |
| 15:08 | FAC | Kim | LVEA | n | Tech clean | 15:33 |
| 15:14 | VAC | Gerardo | LVEA | n | Checking on purge air | 15:37 |
| 15:33 | FAC | Eric | EY | n | Chiller tasks | 15:46 |
| 15:33 | Rahul | LVEA | n | Checking with Gerardo about purge air | 15:34 | |
| 16:01 | FAC | Tyler | MY, EY | n | Ladder inspections | 17:22 |
| 16:18 | FAC | Chris | EY, EX | n | Filter work in mech room | 17:06 |
| 16:20 | SUS | Rahul | Remote | n | Taking HAM6 SUS TFs | 17:15 |
| 16:39 | FAC | Karen, Francisco | PCAL Lab | yes(local) | Tech clean | 16:53 |
| 16:56 | OFI | Betsy, Mitchell | LVEA | n | HAM5 finishing up work | 19:09 |
| 17:03 | VAC | Travis | LVEA | n | Adjusting purge air | 17:23 |
| 17:07 | PEM | Robert, Millie, Carlos | EX | n | Moving seismometers into EX | 17:35 |
| 17:09 | FAC | Karen | LVEA | n | Tech clean | 18:30 |
| 17:09 | FAC | Kim | LVEA | n | Tech clean | 18:30 |
| 17:18 | EE | Fil | LVEA | n | Grounding checks for HAM5/6 | 19:12 |
| 18:03 | Sheila, Mattia | LVEA | n | looking into the HAMs (started 17:30) | 18:03 | |
| 18:10 | OFI | Jeff | LVEA | n | Figuring out HAM grounding issues | 19:18 |
| 18:16 | OFI | Keita | LVEA | n | Checking in on OFI team | 19:07 |
| 18:32 | ISI | Jim | LVEA | n | ISI | 19:12 |
| 18:43 | SUS | Ibrahim | LVEA | n | Collecting SUS(picious) parts | 19:14 |
| 19:11 | FAC | Travis + Norco guy | MX, EX, MY, EY | n | Doing repairs | 20:28 |
| 19:16 | OFI | Betsy | LVEA | n | Helping Jeff | 20:04 |
| 19:26 | PEM | Robert, Sam | LVEA | n | Looking at sound equipment | 20:48 |
| 19:28 | VAC | Gerardo | LVEA | n | Adjusting purge air | 19:31 |
| 20:05 | CDS | Dave, Jonathan | LVEA | n | CDS LVEA sweep | 21:08 |
| 20:31 | CDS | Tony | LVEA | n | Setting up PSL nuc outside PSL enclosure | 21:08 |
| 20:36 | SUS | Rahul, Jeff | LVEA | n | Checking EQ stops in HAM5 | 21:23 |
| 20:56 | SUS | Ibrahim | LVEA | n | Dropping off dental mirror | 20:57 |
| 20:58 | OFI | Betsy | LVEA | n | Helping with OFI stuff | 21:23 |
| 21:33 | OFI | Fil | LVEA | n | Cleaning up | 22:02 |
| 21:51 | Camilla | LVEA, OpticsLab | n | Cleaning rampage | 23:42 | |
| 22:06 | EE | Rahul, Fil | LVEA | n | Investigating I/O issue at HAM5 | 22:28 |
| 22:31 | Ibrahim, Fil | LVEA | n | Cleaning up | 22:42 |
Tony, Fil, Erik, Jonathan, Dave:
On the outside of the north-east corner of the LVEA PSL enclosure there is a wall display computer which shows the enclosure camera images.
Today we replaced this aging mac-mini computer with an Intel NUC configured as a FOM machine.
The new machine is called lveapslfom. It is currently configured to show the same camera images as the PSL FOM in the control room.
The computer's display is snapshotted and can be viewed on the CDS web server
I took the SR3 transfer functions this afternoon. I took SUS_SR3 to damped then reengaged the test filter outputs and set gains to 1, and turned off the damping filter outputs and set the M1 coil driver state from 2 to 1.
While taking the V TF Rahul and I noticed the shapes looked weird, from this we noticed that the T1 analog dewhitening coil driver wasn't switching on and off which led to the investigations in alog79419.
Data lives here
/ligo/svncommon/SusSVN/sus/trunk/HLTS/H1/SR3/SAGM1/Data/
2024-08-01_2000_H1SUSZM6_M1_WhiteNoise_L_0p02to50Hz.xml
2024-08-01_2000_H1SUSZM6_M1_WhiteNoise_P_0p02to50Hz.xml
2024-08-01_2000_H1SUSZM6_M1_WhiteNoise_Y_0p02to50Hz.xml
2024-08-01_2000_H1SUSZM6_M1_WhiteNoise_T_0p02to50Hz.xml
2024-08-01_2000_H1SUSZM6_M1_WhiteNoise_R_0p02to50Hz.xml
2024-08-01_2000_H1SUSZM6_M1_WhiteNoise_V_0p02to50Hz.xml
Plots:
- all DOFs to all DOFs compared against the model for this measurement (2024-08-01_2000_H1SUSSR3_M1_ALL_TFs.pdf), and then
- a comparison between this measurement and the 2 most recently available known-good measurement (2024-08-01_H1SUSSR3_M1_Phase4b_unDamped_ALL_ZOOMED_TFs.pdf).
After my discovery in this alog that the phase and gain margins were pretty tight on HAM2, I did a bunch of olg measurements on HAM2&3 and tweaked the loop gains and boost filters to reduce the gain peaking around 40 hz. More or less all DOFs on these chambers had ugfs around 35hz and phase margins around 5 degrees. Kinda suprised this was stable, I haven't looked at these in a long time. I do wonder if something is funky with the measurement, but I don't know what that would be. Attached image shows one of the worst, the Z dof on HAM3. Blue and yellow are the new loops gain and sensitivity, red and purple are the old loop. The filter changes might make things slightly worse in the 10-20 hz region, but that should be somewhat compensated by the HEPI to ISI feedforward. Should improve the 30-40 hz motion somewhat though.
Legend is reversed on the plot. What was old is new, etc.
J. Kissel
Executive Summary: Took SUS ZM6 (a HAM "Simple" Double Suspension, or HSDS) health-check transfer functions. Looks good. H1SUSZM6 is GO FOR DOORS
Here're the results of pre-doors health check of the suspended dynamics and OSEM electronics of H1 SUS ZM6 after the vent to repair the OFI.
ZM6 wasn't mechanically touched at all during the vent, so we expect everything to be just as excellent as before, and this is indeed the case.
Attached are the usual plot collections showing
- all DOFs to all DOFs compared against the model for this measurement (2024-08-01_1937_H1SUSZM6_M1_ALL_TFs.pdf), and then
- a comparison between this measurement and most recently available known-good measurement (allhxdss_2024-08-01_H1SUSZM6_Phase3a_PreDoorsCloseout_ALL_ZOOMED_TFs.pdf).
HAM5 ISI was floating and damped with HEPI locked.
Coil Driver configuration requested to be in State 2, to correctly compensate the analog HAM-A driver that's permanently jumpered to have its low pass ON.
No alignment offsets were on during the measurement.
Data lives here
/ligo/svncommon/SusSVN/sus/trunk/HXDS/H1/ZM6/SAGM1/Data/
2024-08-01_1937_H1SUSZM6_M1_WhiteNoise_L_0p02to50Hz.xml
2024-08-01_1937_H1SUSZM6_M1_WhiteNoise_P_0p02to50Hz.xml
2024-08-01_1937_H1SUSZM6_M1_WhiteNoise_Y_0p02to50Hz.xml
Comparison script -- svn up'd prior to changes, and then with this data added -- has been committed to
/ligo/svncommon/SusSVN/sus/trunk/HXDS/Common/MatlabTools/
plotallhxds_tfs_M1.m rev 11913
Fil, RyanC, Rahul
We have replaced the triple top coil driver for SUS SR3 after finding binary issues with T1 channel on the M1 stage - see pic attached. T1 LP filter was not switching OFF and was stuck at ON. We looked at the SUS HAM5-6 system wiring diagram on D1002740 and found out that the chassis is at slot41, Rack C7. At first Fil tried re-setting the chassis (binary chasiss was power cycled) and then replaced cable no 44 and 45 (page 1 0f D1002740), which didn't give us the desired results, i.e T1 was still stuck at On, while channel LF and RT (Test/COIL) turned Red at the AI chassis.
Fil then decided to replace the Top Triple coil drive and this fixed the issue. Given below are the s/n of the old and new coil driver,
New - S1001082
Old - S1100192
I have added the above information on the e-traveler.
J. Kissel Executive Summary: Took SUS OFI health-check transfer functions. Looks good. H1SUSOFI is GO FOR DOORS. Here're the results of pre-doors health check of the suspended dynamics and OSEM electronics after we've swapped the KTP crystal (LHO:79344) and Fused-Silica Wedge (LHO:79363) to repair the OFI. Note, this is also after the SD OSEM was pulled and replaced (see LHO:79387). Attached are - the individually processed full DOF to DOF plots -- 2024-08-01_1741_H1SUSOFI_M1_ALL_TFs.pdf - the comparison between the most-recent pre-vent data from LHO:79198 -- allofiss_2024-08-01_H1SUSOFI_Phase3a_PreDoorsCloseout_ALL_ZOOMED_TFs.pdf The OFI suspension and electronics look healthy, with a similar frequency response to the 2024-07-17 data with the expected lower coherence that one gets in air with purge running. ISI was floating and damped during this measurement. Digital request of coil driver state was 2, matching the analog electronics (a HAM-A driver) that has been jumpered with the low pass filter ON. No alignment offsets were on during the measurement. Data lives here: /ligo/svncommon/SusSVN/sus/trunk/OFIS/H1/OFI/SAGM1/Data/ 2024-08-01_1741_H1SUSOFI_M1_WhiteNoise_L_0p02to50Hz.xml 2024-08-01_1741_H1SUSOFI_M1_WhiteNoise_T_0p02to50Hz.xml 2024-08-01_1741_H1SUSOFI_M1_WhiteNoise_Y_0p02to50Hz.xml Data comparison script with this data added to it has been updated and committed to /ligo/svncommon/SusSVN/sus/trunk/OFIS/Common/MatlabTools/ plotallofis_tfs_M1.m [rev 11909]
SUS HAM 5-6 System Wiring Diagrams D1002740
Grounding and Shielding at LIGO T1200131
Things to note:
1. HAM6 ISC cabling was not checked for ground loops
2. Short found on the OFI (cable SUS_SQ_30). Pin 13 shorting to ground. In-chamber ground NOT resolved.
3. All cables listed below passed testing:
SUS_HAM5_001 (SR3 Top)
SUS_HAM5_002 (SRM/SR3 Shared)
SUS_HAM5_019 (SR3 Middle)
SUS_HAM5_020 (SR3 Bottom)
SUS_HAM5_003 (SRM Top)
SUS_HAM5_025 (SRM Middle)
SUS_HAM5_026 (SRM Bottom)
SUS_ZM6_21 (ZM6)
SUS_HAM6_10 (OMC Top/Left)
SUS_HAM6_11 (OMC Right/Side)
ISC_236 (OM1)
ISC_237 (OM2)
ISC_238 (OM3)
In HAM5, Mitchell and I could not find the source of the shield grounding issue on the OFI AOSEM cable chain. We did the usual tricks:
1) Disconnected 25pin at the feedthru to see if the connector screws were touching the flange (no they didn't seem to be)
2) Made sre the 4th unused quadrapus cable end was not stowed anywhere that caused grounding to the shield
3) Fussed with/lifted/recoiled all of the coils in many places, no change to grounding.
In the past, when none of the above fix the issue, the entire cable length gets swapped out. However in consult with Kissel and commissioners, we did not feel these AOSEM control warranted needing to do this given that we are mid O4b. Opening a ticket to deal with this later.
After OFI shroud was put back on Mitch and I unlocked HAM5 ISI. Shifts from the range of reference position were all less than 7urad. Looking at trends CPS RX and RY locations changed up to 15 urad while the OFI work was being done and the table was locked. I will change the reference postion to be in the middle of that range, but should be very close to where the table is hanging now.
This morning I took transfer function measurements on all of the suspensions in HAM6 chamber and they look healthy.
The templates are given below,
/ligo/svncommon/SusSVN/sus/trunk/OMCS/H1/OMC/SAGM1/Data
2024-08-01_1900_H1SUSOMC_M1_WhiteNoise_L_0p02to50Hz.xml
2024-08-01_1900_H1SUSOMC_M1_WhiteNoise_P_0p02to50Hz.xml
2024-08-01_1900_H1SUSOMC_M1_WhiteNoise_R_0p02to50Hz.xml
2024-08-01_1900_H1SUSOMC_M1_WhiteNoise_T_0p02to50Hz.xml
2024-08-01_1900_H1SUSOMC_M1_WhiteNoise_V_0p02to50Hz.xml
2024-08-01_1900_H1SUSOMC_M1_WhiteNoise_Y_0p02to50Hz.xml
/ligo/svncommon/SusSVN/sus/trunk/HTTS/H1/OM1/SAGM1/Data
2024-08-01_1900_H1SUSOM1_M1_WhiteNoise_L_0p02to50Hz.xml
2024-08-01_1900_H1SUSOM1_M1_WhiteNoise_P_0p02to50Hz.xml
2024-08-01_1900_H1SUSOM1_M1_WhiteNoise_Y_0p02to50Hz.xml
/ligo/svncommon/SusSVN/sus/trunk/HXDS/H1/OM2/SAGM1/Data
2024-08-01_1600_H1SUSOM2_M1_WhiteNoise_L_0p02to50Hz.xml
2024-08-01_1600_H1SUSOM2_M1_WhiteNoise_P_0p02to50Hz.xml
2024-08-01_1600_H1SUSOM2_M1_WhiteNoise_Y_0p02to50Hz.xml
/ligo/svncommon/SusSVN/sus/trunk/HTTS/H1/OM3/SAGM1/Data
2024-08-01_1630_H1SUSOM3_M1_WhiteNoise_L_0p02to50Hz.xml
2024-08-01_1630_H1SUSOM3_M1_WhiteNoise_P_0p02to50Hz.xml
2024-08-01_1630_H1SUSOM3_M1_WhiteNoise_Y_0p02to50Hz.xml
The postprocessing of the data is still ongoing and the plots will be posted soon.
I commited all the data to the svn and processed the results.
OM1:
Looks good.
OM2:
All the plots look frequency shifted a Hz smaller except for in L.
OM3:
Looks good.
OMC:
Some peaks shifted to the right/larger frequency by <1Hz or so.
The current measurements taken on OM2 is consistent with previous results (see LHO alog 65028) and so its all good.
OMC is also healthy and consistent with previous measurements taken in the past 1 year - see plot attached below.
Dew point measurement taken this morning read at -43.6 oC. Measurement taken before any activity inside chambers. Soft covers were on HAM5 and HAM6, HAM7 is isolated.
End of the day dew point measurement, at -43.5 oC.
In the afternoon we started placing components on HAM6 and HAM5 to measure the isolation ratio (green components in the attached).
The idea is to use the AUX laser we used for alignment, which will give us ~13mW through the SRM, and retroreflect the beam downstream of the OM1 so the return beam will be about 4mm in diameter at SRM (input beam is ~3mm in diameter, the IFO beam is ~4.4mm, so the return beam will be closer to the IFO beam in size).
Back-propagating return beam was located by inserting a HWP (not in the attached) between TFP and TGG, it's hitting the 50:50 cube and is going in the direction of point B in the first attachment. We blocked the forward propagating beam downstream and confirmed that the return beam went away.
The return beam is supposed to be colinear with the input beam but we haven't made any assessment of that. We will set up a temporary power meter holder at point B (haven't done that today). The HWP is still there in HAM5 but make sure to remove it when you measure the return beam power at point B.
The iris is roughly centered to the forward-propagating beam, but it's not very accurate. It's good enough to block the back-propagating rejected beam that is deflected away into -X direction.
50% of the input beam comes into the direction of point A, and we put a power meter holder there. You still have to adjust the height of the power meter but it's easy to see from the -X door using IR camera.
We misaligned SRM to see if we can locate the SRM reflection of back-propagating return beam in the direction of point A, but couldn't find any. We might try locating it again tomorrow.
Some little Where Is Waldo photos with the added measurement items now in HAM5 in prep for OFI isolation measurement.
Relative Humidity reading from in chamber while doors open with 4 people in the area was 37% today.
Tagging for EPO.
J. Kissel
Executive Summary: In prep for the upcoming vent, I've measured the undamped dynamical transfer functions of the H1SUSOFI. The dynamics look healthy.
The rest of the story: The OFI's digital control system has had a sordid history (mostly the OSEM2EUL and EUL2OSEM matrices, but also the damping loops), and assessment of it's health has been person power limited over the years. I've fixed all that today, and restored the suspension's control system to good health -- such that the transfer functions match the model as they did (once) in 2023. More details explaining the plots later, but we're good to go for the vent.
Today's data lives here
/ligo/svncommon/SusSVN/sus/trunk/OFIS/H1/OFI/SAGM1/Data
2024-07-17_1741_H1SUSOFI_M1_WhiteNoise_L_0p02to50Hz.xml % undamped
2024-07-17_1741_H1SUSOFI_M1_WhiteNoise_T_0p02to50Hz.xml
2024-07-17_1741_H1SUSOFI_M1_WhiteNoise_Y_0p02to50Hz.xml
2024-07-17_1950_H1SUSOFI_M1_WhiteNoise_L_0p02to50Hz.xml % damped
2024-07-17_1950_H1SUSOFI_M1_WhiteNoise_T_0p02to50Hz.xml
2024-07-17_1950_H1SUSOFI_M1_WhiteNoise_Y_0p02to50Hz.xml
The OSEM2EUL and EUL2OSEM matrices were generated in a Matlab workspace with
/ligo/svncommon/SusSVN/sus/trunk/OFIS/Common/MatlabTools
make_susofis_projections.m [rev 10980]
which, notably is an improved version of the script with the Yaw lever arm bug fixed (see LHO:61353).
and populated into EPICs with
/ligo/svncommon/SusSVN/sus/trunk/Common/MatlabTools/
fill_matrix_values.m [rev 11862]
The first attached screenshot shows the "new" restored matrix values, and that they were accepted into SDF.
(Recall, the OFI lives on the front-end model "h1susifoout", and this model's safe and OBSERVE .snap files both point to the same file, so there's no need to accept the SDF DIFFs in both SAFE and OBSERVE,
$ pwd
/opt/rtcds/lho/h1/target/h1susifoout/h1susifooutepics/burt
$ ls -l
lrwxrwxrwx 1 controls 69 Oct 10 2022 OBSERVE.snap -> /opt/rtcds/userapps/release/sus/h1/burtfiles/h1susifoout_observe.snap
lrwxrwxrwx 1 controls 69 Oct 10 2022 safe.snap -> /opt/rtcds/userapps/release/sus/h1/burtfiles/h1susifoout_observe.snap
)
For the record, the previous matrix values -- where matrix elements are single DOF to DOF unity maps with gains of 1.0 were accepted into SDF on Tuesday April 25 2023, two months before the start of O4 (LHO:68984). These elements were leftovers from some guest-star testing that was done just prior -- see e.g. LHO:68910, which was motivated by evidence of back scatter in the OFI, see e.g. LHO:68846.
The data in the main aLOG above (LHO:79198) was exported and individually processed with /ligo/svncommon/SusSVN/sus/trunk/OFIS/Common/MatlabTools/ plotOFIS_dtttfs_M1.m [rev 11875] I also exported and individually processed the large back-log of data taken for the OFI since 2019, '2021-10-11_2300' | LHO:60211| Oct-Nov 2021 Vent pre-install of OFI shroud '2021-11-09_2217' | LHO:60603| Post-OFI shroud install, mechanical interference alleviated '2021-11-10_1750' | LHO:60610| Doors on, in-air close out measurements '2021-12-14_1400' | LHO:61055| Health-check post vent after pumpdown '2023-04-18_1800' | LHO:68846| Health-check in-vac, due to suspicions of backscatter caused by the OFI '2024-04-24_1500' | LHO:77391| Health-check after first major alignment excursion in O4b due to KTP crystal damage (LHO:77392); has bad basis change matrices leftover from LHO:68910 poorly restored via trending '2024-07-17_1741' | LHO:79198 | Pre-vent TFs after updating / restoring bases matrices These data are committed to /ligo/svncommon/SusSVN/sus/trunk/OFIS/H1/OFI/SAGM1/Results/. I then added the above historical log information to the TF comparison script for the OFI (after updating to absorb similar updates from LLO) /ligo/svncommon/SusSVN/sus/trunk/OFIS/Common/MatlabTools/ plotallofis_tfs_M1.m [rev 11902] such that I could make the comparison of all of this data posted as the second attachment to the main entry. The YAW DOF in those plots (page 3) exposes the history the best: 2019-10-11 17:50 -- This is the former "high loss" OFI from aLIGO, prior to the complete rebuild and upgrade that was needed for frequency-dependent-squeezing. 2021-10-11 23:00 --\ 2021-12-14 14:00 -- -- These two 2021 data sets show the OFI *after* upgrading to the FDS capable ultra low loss faraday. Apparently the yaw moment of inertia is a bit less, or the yaw cabling stiffness is a bit higher, so the resonant frequency shifts up a bit. However, this data still has the lever arm bug, so you see the magnitude is a factor of 2 larger than the model. 2023-04-18 18:00 -- This is just after I fixed the lever arm bug, and thus now the magnitude lines up with the model. It's also just prior to when the EUL2OSEM and OSEM2EUL matrices where left in the testing configuration just before and throughout O4 up until Jul 17th. 2024-04-24 15:00 -- Due to suspicions of back-scatter, with too little person power, we restored the basis change matrices to *something* but definitely not the correct basis matrices. We green-lighted the dynamics with a hand waive of "well, it doesn't look like it's *rubbing,* and we guess that it's looked like this and didn't have damping loops on for all of O4 so... probably fine?" 2024-07-17 17:41 -- This aLOG series, with the basis change matrices restored -- and the dynamics restore to the 2023-04-18 goodness.
