Last done in April 2024.
plots for reference, 1412435458.png, HWS_aborbs.png
Using /ligo/gitcommon/labutils/hws_absorption_fit/april2024/fit_absprtion_v2.py with lockloss time 1412435458, edited P_y and P_x values to adjust the fit.
ITMX: 155mW absorbed = 398ppb (155mW / 389kW)
ITMY: 140mW absorbed = 360ppb (140mW / 389kW)
April 2022 (62468, 62782) | Nov 2022 (66036) | April 2023 (71400) | April 2024 | October 2024 | |
ITMX | 430ppb | 490ppb | 475ppb | 430ppb |
398ppb |
ITMY | 370ppb | 385ppb | 375ppb | 330ppb |
360ppb |
Oli, Ibrahim
As a follow-up to yesterday's alog (80689), attached are plots showing length and pitch M1 transfer functions for the four measurements between LHO and LLO taken between August 30th and October 11th, with different M1 blade positions, compared to their matching models (different d1 values).
The d1 values given in the legend for each model are the physical d1 values (based on the model), aka in the same set of d1 values as the ones originally given in the FDR document. Note that these d1 values differ from the d1 values given next to the measurements in Ibrahim's allbbss TFs from yesterday, since those d1 values are based on the actual blade locations and theoretical center of mass. So since these d1 values don't line up between the model d1's and the d1's we get based on where we put the blades, there is something more going on. The models don't correspond to where we would expect to see a bp of -4mm (avg), so this is something we will be discussing.
Wed Oct 16 10:15:38 2024 INFO: Fill completed in 15min 34secs
Closes FAMIS 26012. Last checked in alog 80608.
No significant changes from last week.
Overnight the ITMX coil driver states were wrong, causing the ASC controls to satuate the PUM durring acquisition. (This become aparent when the DHARD gains are increased at the end of DHARD WFS, which happens right before PARK_ALS_VCO 80699)
This used to be reset in ISC_LOCK PREP_FOR_LOCKING state, this has been commented out (line 618), with a note that SDF will take care of this, this has been commented out in the guardian for over a year. Indeed. we found that the coil driver state was incorrectly set to 3
The attached screenshot shows the error was introduced to the safe.snap sometime between 2:30 and 5 pm yesterday, as it was correctly reset in the first two locking attempts of the day, but wasn't correctly reset after the lockloss at 5 local time last night.
Erik, EJ, Dave:
We found that h1susitmx's safe.snap file was truncated from 2265 lines to 1336 lines (last 929 lines removed) at 14:47 Tue 15oct2024. This truncated file was loaded into the model at 17:09 Tue. The BIO STATEREQ channels were in the missing block, and so were not restored to val=2 until the safe.snap file was fixed Wed 09:20.
TITLE: 10/16 Day Shift: 1430-2330 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Corrective Maintenance
OUTGOING OPERATOR: TJ
CURRENT ENVIRONMENT:
SEI_ENV state: CALM
Wind: 4mph Gusts, 2mph 3min avg
Primary useism: 0.02 μm/s
Secondary useism: 0.27 μm/s
QUICK SUMMARY:
TJ was up all night damping Violin modes!
When I walked in IFO was Unlocked and struggling to lock green arms.
Relocking:
I've Requested Inintial Alignment.
Locking Notes:
Initial_Alignment went smooth, DRMI_1F locked quickly:
ISC_LOCK got past DHARD_WFS and immediately I_X Saturations started to happen.
We noticed that the Saturations were coming from the ITMX L2 stage.
Sheila spotted the fact that the Coil Drivers were in the wrong state.
H1:SUS-ITMX_BIO_L2_UL_STATEREQ = 3
H1:SUS-ITMX_BIO_L2_UR_STATEREQ = 3
H1:SUS-ITMX_BIO_L2_LL_STATEREQ = 3
H1:SUS-ITMX_BIO_L2_LR_STATEREQ = 3
But they needed to be in state 2 instead!
Sheila stopped me from just quickly changing that 3 to a 2, which would have broken the lock.
Apparently Shelia relieved one of the Coil Drivers from driving, and then changed the state of that Coild Driver while it was not driving. Then turned that coil driver back on and rotated it back into driving with the restof the Coil Drivers. The she would rotate another Coil Driver out of driving to update the state. Maintaining at least 3 coil Drivers at a time.
Apparently there is a matrix change from driving with all 4 Coils to driving with 3 coils.
Then change the ramp time and value from 3 to 2, then change the matrix to rotate through all 4 coild drivers to "free" a different coild driver from driving. is the procedure that kept our lock. Please see Sheila's alog.
We believe that there was a change to Prep_for_locking that is supposed to update the state of the coild drivers before locking.
P.S.
We turned the Softloops off to deal with the above, and we sat in POWER_25W but we only had 10Watts, because softloops were turned off and we forgot to turn them back on. But it gave Rahul time to Damp Violin modes, which is good because the violin modes do seem big red and mad.
Violin modes are now damping down nicely using the nominal settings for 2W. I have ramped-up the gains for few of the modes in all four optics which will enable to calm them down faster. Later will move to damp violins at full power.
Been trying to get the violins down for the past 2 hours and made barely any progress. Many of the problem modes on ITMX just didn't seem to respond positively to any gains that have worked in the past. We just lost lock, so I'll try some damping on RF and see if that can somehow help.
After losing lock a few times while damping, I think I've finally found a combo that kinda works. While waiting in RF I would request the violin gaurdian to go to DAMPING_ON_SIMPLE, then change the ITMX mode 3 gain down from -40 and increase as needed, and change the ETMY mode 1 to +90 and with a gain of -0.2 as teh google doc says. This worked well and damped most of the problematic modes. I still had issues with ITMX mode 3 & 13 though. This is the limiting factor right now. These two modes just won't go down at any reasonable pace.
Just lost lock again. The lock losses have been from small earthquakes, and other reasons that I haven't figured out.
Damped in RF for a while and was able to get ITMX modes to what I thought were reasonable levels, when we transitioned to DC there were still saturations going on, so I tried damping further there but we lost lock. Each time they ring back up and I have to start almost from scratch. I thought that there must be an incorrect setting or filter on ITMX, but I haven't found anything. At this point I'm beginning to think there might be something else wrong, but I have no idea where to keep looking right now since things seem to somewhat work while damping the violins.
TITLE: 10/16 Eve Shift: 2330-0500 UTC (1630-2200 PST), all times posted in UTC
STATE of H1: Aligning
INCOMING OPERATOR: TJ
SHIFT SUMMARY:
IFO is LOCKING at CHECK_VIOLINS_BEFORE_POWERUP.
Violins:
We lost lock at 00:09 UTC (lockloss alog 80697) and have not been able to get to NLN since. A local earthquake rung violins up violently such that some are in the 8/9 zone. While the alignment is great, (DRMI locked without PRMI 5 times), we have IX saturations starting at PARK_ALS_VCO. I initially thought this was an ALS or maintenance Tuesday issue, but that doesn't seem to be the case. After chatting to Jenne, we realized that it was indeed the violins. So I started damping.
Setting all violins to their nominal damping states successfully prevented IX from saturating at ENGAGE_ASC_FOR_FULL_IFO, where it was saturating consistently. Moving to CHECK_VIOLINS_BEFORE_POWERUP results in 1 saturation/second, losing lock eventually (after 30 mins or so). Any form of powerup also loses lock immediately. I talked to Rahul, and he recommended staying at a steady state to damp for a few hours since sometimes it just takes that long. Spoke to the incoming operator, TJ and he's been informed of the unsteady state of the IFO.
I'm already past this state but my recommendation (from speaking to Rahul) would be to stay at PREP_ASC_FOR_FULL_IFO at nominal damping for a few hours.
FAMIS 27800 TCS Chiller Water Level Top-Off_Weekly
TCS CO2X Level before : 29
added 250 ml
TCS CO2X Level after : 30
TCS CO2Y Level before : 9
added 200 ml
TCS CO2Y Level after : 10
Nothing seemed out of place, I saw no leaks.
Noted in the following TCS Chiller spreadsheet:
https://docs.google.com/spreadsheets/d/1Mu7-pmjWiRQxU3rX3lI0LB4UXI9asC-efkCnS9sT58k/edit?gid=0#gid=0
Lockloss due to an EQ from Mexico. EQ mode activated but ground motion was too high and we lost lock 3 mins after EQ mode.
Ibrahim, Oli
Below are updates and promising findings concerning the most recent BBSS LHO Top Mass -4mm BP Adjustments to tackle the F1 Drift issue summarized in alog 80577.
On Friday 10/11, Oli P and I moved the blade positions (mm BP Units) to:
Front Left: Side: 0.02, Top: -4.03 Back Left: Side: -0.03, Top -3.90 Front Right: Side: 0.02, -3.91 Back Right: Side: -0.05, -3.95 Avg: Side: -0.01 Height: -3.95
Find:
The good news is that with these 4.5 days of Data, we see no sign of F1 Drift.
We will post another alog with TF to model comparisons as we find which model d1 parameter fits these -4mm BP positions best.
That's good news! What is the configuration for the addable masses on the top mass for both the bottom and top plate?
The Addable Masses on the top plate were redistributed to the Front (top). 150g and 150g as shown in the attached image. No change to the bottom plate. We did not change the total mass.
Adding this Pitch Plot (which still shows no drift!) to give a measure of how much the diurnal moves day-to-day. Plot attached shows a max of 31.8 cts trough to peak max.
This is such that future drift measurements (e.g. at LLO) can try new configurations quickly and measure the prevailing drift without getting caught in the daily pitch breathing error.
J. Kissel WP 12140 I've completed 6 SUS + 4 ISI = 10 of 12 total DOF excitations that I wanted to drive before I ran out of time this morning. Each drive was "successful" in that I was able to get plenty of coherence between the 4 DOFs of ISI drive and SUS response, and some coherence between 6 SUS drive DOFs and ISI response. As expected, the bulk of the time was spent tuning the ISI excitations. I might have time to "finish" the data set and get the last two missing DOFs, but I was at least able to get both directions of LPY to LPY transfer functions, which are definitely juicy enough to get the analysis team started. Measurement environmental/configuration differences of the HAM2 ISI from how they are nominally in observing: - PR3 M1 DAMP local damping loop gains are at -0.2, where they are nominally at -1.0. (The point of the test.) - CPS DIFF is OFF. (needed to do so for maintenance day) - Coil Driver z:p = 1:10 Hz analog low-pass (and digital compensation for it) is OFF. (need to do so to get good SNR on SUS M1 drive without saturating the SUS DACs) Interesting things to call out that are the same as observing: - The PR3 alignment sliders were ON. P = -122 [urad]; Y = 100 [urad]. (Don't *expect* dynamics to change with ON vs. OFF, but we have seen diagonal response change if close an EQ stop. Haven't ever looked, but I wouldn't be surprised of off-diagonal responses change. Also DAC range gets consumed by DC alignment request, which is important for driving transfer functions.) - Corner station sensor correction, informed by the Bier Garten "ITMY" T240 on the ground. (the h1oaf0 computer got booted this morning, so we had to re-request the SEI_CS configuration guardian to be in WINDY. The SEI_ENV guardian had been set to LIGHT_MAINTENANCE.) - PR3 is NOT under any type of ISC global control; neither L, P, or Y. (global ISC feedback for the PRC's LPY DOFs goes to PRM and PR2.) There are too many interesting transfer functions to attach, or even to export in the limited amount of time I have. So -- I leave it to the LSC team that inspired this test to look at the data, and use as needed. The data have been committed to the SVN here: /ligo/svncommon/SusSVN/sus/trunk/HLTS/H1/PR3/SAGM1/Data/ 2024-10-15_1627_H1SUSPR3_M1_WhiteNoise_L_0p02to50Hz.xml 2024-10-15_1627_H1SUSPR3_M1_WhiteNoise_T_0p02to50Hz.xml 2024-10-15_1627_H1SUSPR3_M1_WhiteNoise_V_0p02to50Hz.xml 2024-10-15_1627_H1SUSPR3_M1_WhiteNoise_R_0p02to50Hz.xml 2024-10-15_1627_H1SUSPR3_M1_WhiteNoise_P_0p02to50Hz.xml 2024-10-15_1627_H1SUSPR3_M1_WhiteNoise_Y_0p02to50Hz.xml /ligo/svncommon/SusSVN/sus/trunk/HLTS/H1/PR3/Common/Data 2024-10-15_1627_H1ISIHAM2_ST1_WhiteNoise_PR3SusPoint_L_0p02to50Hz.xml 2024-10-15_1627_H1ISIHAM2_ST1_WhiteNoise_PR3SusPoint_T_0p02to50Hz.xml [ran out of time for V] [ran out of time for R] 2024-10-15_1627_H1ISIHAM2_ST1_WhiteNoise_PR3SusPoint_P_0p02to50Hz.xml 2024-10-15_1627_H1ISIHAM2_ST1_WhiteNoise_PR3SusPoint_Y_0p02to50Hz.xml For the SUS drives templates, I gathered: Typical: - The top mass, M1, OSEM sensors, in the LTVRPY Euler Basis, calibrated into microns or microradians, [um] or [urad]. H1:SUS-PR3_M1_DAMP_?_IN1_DQ [Filtered with the 64x filter, then downsampled to to fs = 256 Hz] - The top mass, M1, OSEM sensors, in the T1T2T3LFRTSDD OSEM Sensor/Coil Basis, calibrated into microns, [um]. H1:SUS-PR3_M1_OSEMINF_??_OUT_DQ [Filtered with the 64x filter, then downsampled to to fs = 256 Hz] - The top mass, M1, OSEM coils' requested drive, in the T1T2T3LFRTSD OSEM Sensor/Coil Basis, in raw (18 bit) DAC counts, [ct_M1SUS18bitDAC]. H1:SUS-PR3_M1_MASTER_OUT_??_DQ [Filtered with the 32x filter, then downsampled to to fs = 512 Hz] For this set of templates: - The bottom mass i.e. optic, M3, OSEM sensors, in the LPY Euler Basis, calibrated into microns or microradians, [um] or [urad]. H1:SUS-PR3_M3_WIT_?_DQ [Filtered with the 64x filter, then downsampled to to fs = 256 Hz] - The bottom mass i.e. optic, M3, optical lever, in PIT YAW Euler Basis, calibrated into mircoradians, [urad]. H1:SUS-PR3_M3_OPLEV_???_OUT_DQ [Filtered with the 64x filter, then downsampled to to fs = 256 Hz] - The ISI's Stage 1 GS13 inertial sensors, projected to the PR3 suspension point LTVRPY Euler basis, calibrated into nanometers or nanoradians, [nm] or [nrad] H1:ISI-HAM2_SUSPOINT_PR3_EUL_?_DQ [Filtered with the 4x filter, then downsampled to to fs = 1024 Hz] - The ISI's Stage 1 super sensors, in the ISI's Cartesian XYZRXRYRZ basis, calibrated into nanometers or nanoradians, [nm] or [nrad] H1:ISI-HAM2_ISO_*_IN1_DQ [Filtered with the 2x filter, then downsampled to to fs = 2048 Hz] Note: The six M1 OSEM sensors in the Euler Basis are set to be the "A" channels, such that you can reconstruct the transfer function between the M1 Euler Basis to all the other response channels in the physical units stated above. As usual the excitation channel for the given drive DOF (in each template, that's H1:SUS-MC3_M1_TEST_?_EXC) is automatically stored, but these channels are in goofy "Euler Basis (18-bit) DAC counts," so tough to turn into physical units. For the brand new ISI drive templates, I gathered: - The ISI's Stage 1 super sensors, in the ISI's Cartesian XYZRXRYRZ basis, calibrated into nanometers or nanoradians, [nm] or [nrad] H1:ISI-HAM2_ISO_*_IN1_DQ [Filtered with the 2x filter, then downsampled to to fs = 2048 Hz] - The ISI's Stage 1 GS13 inertial sensors, projected to the PR3 suspension point LTVRPY Euler basis, calibrated into nanometers or nanoradians, [nm] or [nrad] H1:ISI-HAM2_SUSPOINT_PR3_EUL_?_DQ [Filtered with the 4x filter, then downsampled to to fs = 1024 Hz] - The top mass, M1, OSEM sensors, in the LTVRPY Euler Basis, calibrated into microns or microradians, [um] or [urad]. H1:SUS-PR3_M1_DAMP_?_IN1_DQ [Filtered with the 64x filter, then downsampled to to fs = 256 Hz] - The bottom mass i.e. optic, M3, OSEM sensors, in the LPY Euler Basis, calibrated into microns or microradians, [um] or [urad]. H1:SUS-PR3_M3_WIT_?_DQ [Filtered with the 64x filter, then downsampled to to fs = 256 Hz] - The bottom mass i.e. optic, M3, optical lever, in PIT YAW Euler Basis, calibrated into mircoradians, [urad]. H1:SUS-PR3_M3_OPLEV_???_OUT_DQ [Filtered with the 64x filter, then downsampled to to fs = 256 Hz] - The ISI's Stage 1 actuators' requested drive, in the H1H2H3V1V2V3 ISI actuator basis, in raw (16-bit) DAC counts, [ct_ISIST116bitDAC]. H1:ISI-HAM2_OUTF_??_OUT [Didn't realize in time that there are DQ channels H1:ISI-HAM2_MASTER_??_DRIVE_DQ stored at fs = 2048 Hz, or I would have used those.] Note: Here, I set the number of "A" channels to twelve, such that both the ISI's Cartesian basis and the PR3 Suspoint basis versions of the GS13s can be used as the transfer function reference channel.
OK ok ok. I couldn't resist and it didn't take that long. I attach the unit-full transfer functions between the ISI Sus. Point Drive DOFs (L, P, Y, and T) and the Top Mass SUS M1 OSEMs response in L, P, Y. It's.... a complicated collection of TFs; and this isn't all of them that are relevant! Just to make the point that Dan DeBra taught Brian Lantz, who taught me, and we're passing down to Edgard Bonilla: *every* DOF matters; the one you ignore is the one that will bite you. The transverse, T, DOF drive data set demonstrates this point. None of these transverse to LPY couplings nominally exist if we just consider first principles equations of rigid-body motion of an ideal suspension. But alas, the on-resonance coupling from T to L, P, Y ranges from 0.1 ... to 50 [m/m] or [rad/m]. I may need to drive the ISI with an entirely different color of excitation to resolve these transfer functions above 5 Hz, where it's perhaps most interesting for DARM, but this is a good start. The ISI drive templates have been re-committed to the repo with the calibrations of each channel in place. (It was really easy: just multiplying each channel by the appropriate 1e-9 [m/nm] or 1e-6 [m/um] in translation, and similar 1e-9 [rad/nrad] or 1e-6 [rad/urad].)
Thank Jeff!
You were right - this looks much more interesting than I had hoped. We'll run the scripts for the SUS to SUS TFs and put them up here, too.
Transverse to Pitch at 50 rad/m on resonance. Maybe "only" 10 when you turn up the damping to nominal? Ug.
I've also taken a look at how much the ISI moves when Jeff drives the BOSEMs on the top stage of PR3. The answer is "not very much". I've attached two plots, one for the top mass Yaw drive and the other for the top mass length drive. note - The ISI reponses need to be divided by 1000 - they are showing nm or nrad/drive, while the SUS is showing microns or microradians/drive.
So - the back reaction of the osem drives can be safely ignored for PR3, and probably all the triples, as expected. (maybe not for the TMs, not that it matters right now).
It raises 2 questions
1. How do I divide a line by 1000 in a dtt plot? (I feel so old)
2. Why does the green line (SUSPoint) look so much noiser that the cart-basis blend signals? I would expect these to look nearly identical above about 1/2 Hz, because the blend signal is mostly GS-13. The calibrations look right, so why does the TF to the GS-13 signal look so much worse than the TF to the blend output?
These plots are at {SUS_SVN}/HLTS/H1/PR3/SAGM1/Results/
2024-10-15_length_to_length_plot.pdf
2024-10-15_yaw_to_yaw_plot.pdf
I grabbed the remaining ISI drive degrees of freedom this morning, V and R. The color and strength of the excitation was the same as it was on Oct 15th, where I used the L drive excitation params for V, and the P drive excitation params for R. PR3 damping loops gains were at -0.2 again, Sensor correction is ON, CPS DIFF is OFF. PR3 alignment offsets are ON. For these two data sets, the PR3 top mass coil driver low pass was still ON (unlike the Oct 15th data), but with the damping loop gains at -0.2, there's no danger of saturation at all, and the low pass filter's response is well compensated, so it has no impact on any of the ISI excitation transfer functions to SUS-PR3_M1_DAMP_?_IN1_DQ response channels. It's only really important to have the LP filter OFF when driving the SUS. There was the remnants of an earthquake happening, but the excitations were loud enough that we still got coherence above at least 0.05 Hz. Just for consistency's sake of having a complete data set, I saved the files with virtually the same file name: /ligo/svncommon/SusSVN/sus/trunk/HLTS/H1/PR3/Common/Data/ 2024-10-15_1627_H1ISIHAM2_ST1_WhiteNoise_PR3SusPoint_L_0p02to50Hz.xml 2024-10-15_1627_H1ISIHAM2_ST1_WhiteNoise_PR3SusPoint_T_0p02to50Hz.xml 2024-10-15_1627_H1ISIHAM2_ST1_WhiteNoise_PR3SusPoint_V_0p02to50Hz.xml # New as of Oct 23 2024-10-15_1627_H1ISIHAM2_ST1_WhiteNoise_PR3SusPoint_R_0p02to50Hz.xml # New as of Oct 23 2024-10-15_1627_H1ISIHAM2_ST1_WhiteNoise_PR3SusPoint_P_0p02to50Hz.xml 2024-10-15_1627_H1ISIHAM2_ST1_WhiteNoise_PR3SusPoint_Y_0p02to50Hz.xml
Today I also gathered another round of all six DOFs of ISI excitation, but this time changing the color of the excitation to get more coherence between 1 to 20 Hz -- since this is where the OSEM noise matters the most for the IFO. In the end, the future fitter may have to end up combining the two data sets to get the best estimate of the plant. In the same folder, you'll find /ligo/svncommon/SusSVN/sus/trunk/HLTS/H1/PR3/Common/Data 2024-10-23_1739_H1ISIHAM2_ST1_WhiteNoise_PR3SusPoint_L_0p02to50Hz.xml 2024-10-23_1739_H1ISIHAM2_ST1_WhiteNoise_PR3SusPoint_P_0p02to50Hz.xml 2024-10-23_1739_H1ISIHAM2_ST1_WhiteNoise_PR3SusPoint_R_0p02to50Hz.xml 2024-10-23_1739_H1ISIHAM2_ST1_WhiteNoise_PR3SusPoint_T_0p02to50Hz.xml 2024-10-23_1739_H1ISIHAM2_ST1_WhiteNoise_PR3SusPoint_V_0p02to50Hz.xml 2024-10-23_1739_H1ISIHAM2_ST1_WhiteNoise_PR3SusPoint_Y_0p02to50Hz.xml Happy fitting!
Here is the set of plots generated by {SUSsvn}/Common/MatlabTools/plotHLTS_dtttfs_M1 for the data Jeff collected on Oct 15.
(see above, the data set is in 6 text file with names like 2024-10-15_1627_H1SUSPR3_M1_WhiteNoise_L_0p02to50Hz_tf.txt (L, P, Y, etc)
These are funny looking because the damping loops are only running at 1/5 of the normal gain. This gives higher-Q peaks and less OSEM noise coupling. This is done as part of an exercise to run the detector with a combination of real OSEM signals (ie the ones here) PLUS model-based OSEM estimators. I've set the script to show all the cross terms, and these are clearly present. It remains to be seen how much the various cross terms will matter. This is the data we will use to help answer that question.
I've also attached a slimmed-down version of the cross-coupling plots which just shows the coupling to yaw. These are the same plots as above with some of the lines removed so that I can see what is happening to yaw more easily. In each plot the red is the measured cross-coupling from dof-drive to Yaw-response. For reference, these also include the light-blue yaw-to-yaw and the grey dof-to-dof measurements.
These plots and the .mat file are in the SUS SVN at {SUS_SVN}/HLTS/H1/PR3/SAGM1/Results/
2024-10-15_1627_H1SUSPR3_M1.mat
2024-10-15_1627_H1SUSPR3_TFs_lightdamping_yawonly.pdf
2024-10-15_1627_H1SUSPR4_M1_ALL_TFs_lightdamping.pdf
On a side note, the ISI to ISI TFs are not unity between 0.1 and 1 Hz. I think they should be. This is a drive from the blended input of the control loop (well, several, because it's in the EUL basis) to the signal seen on the GS-13, in the same EUL basis, converted to displacement (so it will roll off below 30 mHz, because the the realtime calibration of the GS-13s in displacement rolls off, and it has a bump at 30 Hz because this is really the complementary sensitivity, and that has a bump because of the servo bump)
But it should be really close to 1 from 0.1 to 3 Hz. The rotational DOFs (right side, red line) look pretty good, but the translations (L, V, T) all show a similar non-unity response. Jim and Brian should discuss. They look similar to each other, so maybe it's a blend which isn't quite complementary?
I've plotted the TFs from the SUSpoint drive to the M1 EUL basis TFs. Note that in the plots, I've adjusted the on-diagonal model plots to be -1 + model. The model is the INERTIAL motion of the top stage, the measured TFs all show the RELATIVE motion between the ISI and top stage. So you want to model Top/ISI - ISI/ISI or -1 + model. This is only true for the on-diagonal TFs.
The code to do this lives in {SUSsvn}/HLTS/Common/MatlabTools/plotHLTS_ISI_dtttfs_M1.m
I've attached a big set of pdfs. The cross couplings look not-so-great. See the last 5 plots for the cross-couplings of dof->Yaw. in particular, L->Y is about the same as Y->Y. (pg 22)
The pdfs and the .mat file have been committed to the SVN at
{SUSsvn}/HLTS/H1/PR3/SAGM1/Results/
2024-10-15_1627_H1SUSPR3_M1_SUSpointDrive.mat
2024-10-15_1627_H1SUSPR3_M1_ALL_TFs_lightdamping_SUSpointDrive.pdf
(Also, see in the previous comments, there was a file which I named ...PR4... this is now corrected to ...PR3... )
Gerardo, Janos Reacting to the issue in aLog https://alog.ligo-wa.caltech.edu/aLOG/index.php?callRep=80619, the GV10 AIP was swapped, as the pump broke down. The AIP was swapped with a noble diode pump, as a lesson learnt from the latest AIP swap: https://alog.ligo-wa.caltech.edu/aLOG/index.php?callRep=80411. The only difficulty was after swapping the pump and then pumping on the Annulus line, the old Varian controller did not work (the reason for its malfunction is now supposedly diagnosed), and so now the Ion pump runs with an Agilent IPC Mini controller. The downside of this is that the wiring of its data cable is not compatible with the current CDS setup, and therefore on the MEDM screen the AIP still appears as faulty - see picture attached. The controller will be replaced shortly, after the Varian controller is fixed. Until then, the Agilent controller will be periodically checked. Nevertheless, the Noble-diode pump proved to be an excellent choice again, as it pumped the Annulus volume down pretty quickly (in about 7 minutes) below 1E-6 Torr.
Gerardo replaced the IPC Mini controller with a Varian controller back on yesterday, so now the MEDM screen is also clear.
(Dave, Vicky, Daniel)
The necessary filter modules for the ZM2/4/5 strain gauge servos were booted into the h1tcscs model, and the medm updated. We added some channels to the copy guardian, since the strain gauge channels are acquired in the TwinCAT system. The new filter modules were loaded with a -1/f filter and then engaged with a gain of 1. The output limiter were set to 50V.
We played around with the new servos by stepping the target strain gauge settings. The response time seems to be about 7-8 sec. All working fine.
So when running the PSAMS servo, to change PSAMS ROC, set H1:AWC-ZM{2,4,5}_M2_STRAIN_VOLTAGE_TARGET instead of adjusting the applied voltage offset slider H1:AWC-ZM{2,4,5}_M2_SAMS_OFFSET.
Attaching some trends of the PSAMS servo working overnight -
Screenshot 1 - For ZM4, servo filter bank settings and ndscope trends of a step in the servo setpoint. The PSAMS servo output adjusts the applied voltage (see PZT DC voltage readback, eg H1:AWC-ZM4_PSAMS_VOLTAGE_DC) to bring the strain gauge voltage readback (H1:AWC-ZM4_PSAMS_STRAIN_VOLTAGE) to the target setpoint voltage (H1:AWC-ZM4_M2_STRAIN_VOLTAGE_TARGET).
Screenshot 2 - ZM2,4,5 PSAMS strain gauge voltage trends before/after servo. Before PSAMS servo (last few days) - the applied PSAMS PZT voltage is static, and the PSAMS strain gauge voltage readbacks drifts (small amount). After turning on PSAMS servos, the applied PSAMS PZT voltages are servo'd to stabilize the strain gauge readbacks to the "TARGET" values.
Screenshot 3 - ZM5 suspension MEDM screen, showing where the PSAMS servo filter bank and target setpoints are. This ZM5 suspension medm screen is in $(userapps)/sus/common/medm/hxds/SUS_CUST_HPDS_OVERVIEW.adl (Sheila helped us svn-commit this screen from LLO, then Daniel pulled it for use at LHO).
Daniel updated the PSAMS servo parts in the AWC block of h1tcscs.mdl, found in userapps/trunk/tcs/h1/models. The SDF's appeared in the h1tcscs table (in the "OAF" box on the sdf screen). Daniel has sdf-monitored the PSAMS filter banks, and left the ZM PSAMS PZT offsets sdf-monitored. Note these pzt offset values are basically meaningless when the servo is running. The ZM2/4/5 offsets are now all SDF'd around 100V, so they would come back to ~nominal values after any resets.
This follows up on Adam's llo73464 "Adding SAMS servo to HPDS common part" (from LLO: WP 11839, IIET ticket 32287, and ECR E2400361) to pull the psams servo for LHO.
TITLE: 10/15 Day Shift: 1430-2330 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Aligning
OUTGOING OPERATOR: TJ
CURRENT ENVIRONMENT:
SEI_ENV state: CALM
Wind: 4mph Gusts, 3mph 3min avg
Primary useism: 0.03 μm/s
Secondary useism: 0.38 μm/s
QUICK SUMMARY:
When I Arrived ISC_LOCK was in Inintial_alignment, Init_Align was in Locking Green Arms, and ALSY arm has no light on it.
Last lockloss was 2024-10-15_13:01:37Z ISC_LOCK NOMINAL_LOW_NOISE -> LOCKLOSS
TJ Said he got called by H1 Manny just before 7:30.
I will be running Oli's script as described in Alog 76606 to save all slider values before the CDS team does their DAQ Restart thing.
Output of Oli's script:
anthony.sanchez@cdsws29: python3 update_sus_safesnap.py
No optics or groups entered. -h or --help to display opt-ions.
anthony.sanchez@cdsws29: python3 update_sus_safesnap.py -h
usage: update_sus_safesnap [-h] [-p] [-o [OPTICS ...]]
Reads the current OPTICALIGN_{P,Y}_OFFSET values and uses those to overwrite
the OPTICALIGN_{P,Y}_OFFSET values in the burt files linked from their
respective safe.snap files.
options:
-h, --help show this help message and exit
-p, --print-only Use -p or --print-only to only print the beforeand
after values without updating the values saved in
safe.snap. (default: False)
-o [OPTICS ...], --optics [OPTICS ...]
Type the names of optic groups (ex. itm) or individual
optic names (ex. pr2), with spaces in between. Case
does not matter.
OptGroup | Optics OptGroup | Optics
itm ITMX etm ETMX
ITMY ETMY
bs BS tms TMSX
TMSY
rm RM1
RM2 pr PRM
PR2
im IM1 PR3
IM2
IM3 mc MC1
IM4 MC2
MC3
sr SRM
SR2 ifo_out OFI
SR3 (om if w/o OFI) OMC
OM1
fc FC1 OM2
FC2 OM3
zm_in OPO zm_out ZM4
ZM1 ZM5
ZM1 ZM6
ZM3
(default: none)
anthony.sanchez@cdsws29: python3 update_sus_safesnap.py -o itm bs rm im sr fc zm_in etm tms pr mc ifo_out zm_out
Running $(USERAPPS)/isc/h1/guardian/update_sus_safesnap.py
Updating and printing out saved OPTICALIGN_{P,Y}_OFFSET values from safe.snap vs current values for these optics:
ITMX ITMY BS RM1 RM2 IM1 IM2 IM3 IM4 SRM SR2 SR3 FC1 FC2 OPO ZM1 ZM2 ZM3 ETMX ETMY TMSX TMSY PRM PR2 PR3 MC1 MC2 MC3 OFI OMC OM1 OM2 OM3 ZM4 ZM5 ZM6
Traceback (most recent call last):
File "/opt/rtcds/userapps/trunk/isc/h1/scripts/update_sus_safesnap.py", line 318, in <module>
old_new = replace_offsets(opt_dicts(optics), print_only=print_only)
File "/opt/rtcds/userapps/trunk/isc/h1/scripts/update_sus_safesnap.py", line 201, in replace_offsets
cur_vals.append(ezca[pchanname])
File "/var/opt/conda/base/envs/cds/lib/python3.10/site-packages/ezca/ezca.py", line 304, in __getitem__
return self.read(channel)
File "/var/opt/conda/base/envs/cds/lib/python3.10/site-packages/ezca/ezca.py", line 294, in read
pv = self.connect(channel)
File "/var/opt/conda/base/envs/cds/lib/python3.10/site-packages/ezca/ezca.py", line 272, in connect
raise EzcaConnectError("Could not connect to channel (timeout=%ds): %s" % (self._timeout, name))
ezca.errors.EzcaConnectError: Could not connect to channel (timeout=2s): H1:SUS-OFI_M1_OPTICALIGN_P_OFFSET
anthony.sanchez@cdsws29: python3 update_sus_safesnap.py -o zm_out
Running $(USERAPPS)/isc/h1/guardian/update_sus_safesnap.py
Updating and printing out saved OPTICALIGN_{P,Y}_OFFSET values from safe.snap vs current values for these optics:
ZM4 ZM5 ZM6
SUS-ZM4_M1_OPTICALIGN_P_OFFSET
Old Saved: -7.92342523045482380439e+02
New Saved: -772.2246009467159
SUS-ZM4_M1_OPTICALIGN_Y_OFFSET
Old Saved: -9.85740674423158566242e+02
New Saved: -981.3613025567112
SUS-ZM5_M1_OPTICALIGN_P_OFFSET
Old Saved: -1.15000000000000000000e+02
New Saved: -115.0
SUS-ZM5_M1_OPTICALIGN_Y_OFFSET
Old Saved: -4.60000000000000000000e+02
New Saved: -460.0
SUS-ZM6_M1_OPTICALIGN_P_OFFSET
Old Saved: 1.39848934620929139783e+03
New Saved: 1408.6829424213722
SUS-ZM6_M1_OPTICALIGN_Y_OFFSET
Old Saved: -2.83802124439147348767e+02
New Saved: -260.05899996129443
anthony.sanchez@cdsws29: python3 update_sus_safesnap.py -o ifo_out
Running $(USERAPPS)/isc/h1/guardian/update_sus_safesnap.py
Updating and printing out saved OPTICALIGN_{P,Y}_OFFSET values from safe.snap vs current values for these optics:
OFI OMC OM1 OM2 OM3
Traceback (most recent call last):
File "/opt/rtcds/userapps/trunk/isc/h1/scripts/update_sus_safesnap.py", line 318, in <module>
old_new = replace_offsets(opt_dicts(optics), print_only=print_only)
File "/opt/rtcds/userapps/trunk/isc/h1/scripts/update_sus_safesnap.py", line 201, in replace_offsets
cur_vals.append(ezca[pchanname])
File "/var/opt/conda/base/envs/cds/lib/python3.10/site-packages/ezca/ezca.py", line 304, in __getitem__
return self.read(channel)
File "/var/opt/conda/base/envs/cds/lib/python3.10/site-packages/ezca/ezca.py", line 294, in read
pv = self.connect(channel)
File "/var/opt/conda/base/envs/cds/lib/python3.10/site-packages/ezca/ezca.py", line 272, in connect
raise EzcaConnectError("Could not connect to channel (timeout=%ds): %s" % (self._timeout, name))
ezca.errors.EzcaConnectError: Could not connect to channel (timeout=2s): H1:SUS-OFI_M1_OPTICALIGN_P_OFFSET
anthony.sanchez@cdsws29:
That error to my update_safe_snap script shouldn't happen again - I had put the OFI as an option in there for overwriting the OPTICALIGN offset settings, but it turns out that the OFI doesn't have opticalign offsets! Neither does the OPO, so I've removed both of those from the code.
It seems to now be working correctly (but it's tricky to test) so hopefully there are no more issues with running it.