Jennie W, Sheila
Summary: We need to rerun this test with slightly different starting QPD offsets and a different amplitude to get a meaningful measurement of how the optical gain would be affected by changing the OMC alignment.
I started an injection into the OMC ASC loops (which feed back to the OMC and the OM3 pitch and yaw to keep the beams centred to specific offsets on OMC QPD A and B.
With this we can raster the OMC alignment and find which QPD offsets allow us to maximise optical gain.
The injection started at about 20:30 UTC while no squeezing was injected.
I used this template at /ligo/home/jennifer.wright/Documents/OMC_Alignment/20240419_OMC_Alignment_EXC.xml with amplitudes of 3 counts in all four degrees of freedom.
Within one cycle the OMC suspension saturated.
Why did we saturate with an injection amplitude of 3 as this ran the last time we did this test without any saturations?
Decreased amplitude to 1 to run it without saturating the OMC suspension.
Restarted at 20:39:07 UTC roughly.
Stopped injecting after 21:06:00 UTC.
Results inconclusive as changing the QPD in offset does not seem to change the noise injected around the calibration line between 410 to 411 Hz, so maybe we need to have higher injection amplitudes but start raster from different QPD offset set points so we don't staurate the suspension.
Looking at ndscope of the channels when they saturated.
OMC T2 and T3 saturated (this is an18 bit DAC). This is OMC pitch degree of freedom, which corresponds to Y direction in the OMC ASC loop basis.
Looking at the top left plot the POS Y DOF seems to correspond to the time of saturation and is the highest Y channel so we want to put in a +0.5 offset to this before the next time we run this raster to bring the input to the POS Y loop down in magnitude.
I forgot to post the the results from yesterday.
As can be seen from the spectrogram while we were doing the OMC alignment scan, there were a lot of glitches during this period which may limit us in using the BLRMS as a measurement of optical gain as some of these glitches were at both BLRMS frequencies we look at - ie. 410 - 411, 800 - 900 Hz.
Looking at zoomed in time series of GDS calib strain and OMC DCPD these glitches can also be seen.
The plot of OMC DCPD BLRMS at the calibration line frequency against QPD offsets seems to show they are quite flat in frequency and so we can't get any gain from adjusting the QPD offsets at this alignment into the OFI.
TITLE: 05/29 Day Shift: 1430-2330 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Observing at 145Mpc
INCOMING OPERATOR: Corey
SHIFT SUMMARY:
IFO is in NLN since 17:45 UTC
IFO States for the day has been:
14:25 UTC: OBSERVING
14:45 UTC: Lockloss - after initial alignment, we went into planned comissioning from 16:00 UTC to 19:00 UTC. IFO stayed in down during this time for comissioning tasks. After these, we began to lock again.
17:45 UTC: Reached NLN and went into COMISSIONING
19:11 UTC: OBSERVING after comissioning tasks wrapped up
20:30 UTC: COMMISSIONING impromptu comissioning time coinciding with LLO since neither site had a fully locked IFO during the original alotted time. An hour of comissioning time was agreed upon.
21:34 UTC: OBSERVING
23:30 UTC: Shift End - OBSERVING
LOG:
Start Time | System | Name | Location | Lazer_Haz | Task | Time End |
---|---|---|---|---|---|---|
15:53 | SYS | Jeff | LVEA | N | Grabbing 786 by HAM6 | 16:02 |
16:02 | FAC | Karen | MY | N | Technical Cleaning | 16:02 |
16:03 | FAC | Kim | MX | N | Technical Cleaning | 16:51 |
18:22 | SAF | Ryan | LVEA | Y | Transition to laser hazard | 18:38 |
18:23 | PEM | Robert | LVEA | Y | Stray beam force measurements | 19:11 |
19:13 | SAF | LVEA | IS | LASER | HAZARD | 05:53 |
20:41 | PEM | Robert | LVEA | Y | Stray beam force measurements | 21:28 |
21:04 | TCS | Camilla | Opt Lab | Local | CO2 laser testing | 23:04 |
21:04 | SEI | Mitchell, Jim | MX | N | Looking at in-air cables | 21:40 |
23:09 | TCS | Camilla, Terry | Opt Lab | Local | CO2 Laser Testing | 02:10 |
TITLE: 05/29 Eve Shift: 2300-0800 UTC (1600-0100 PST), all times posted in UTC
STATE of H1: Observing at 148Mpc
OUTGOING OPERATOR: Ibrahim
CURRENT ENVIRONMENT:
SEI_ENV state: CALM
Wind: 18mph Gusts, 12mph 5min avg
Primary useism: 0.06 μm/s
Secondary useism: 0.09 μm/s
QUICK SUMMARY:
H1's been locked almost 5.5hrs and seem a little calmer than yesterday at this time, althought we've had some gusts approaching 30mph. No items to hand over from Ibrahim for locking tonight (other than possibly proactively run an Initial Alignment if there are ALS or DRMI/PRMI issues
FAMIS 26304, last checked in alog77997
Only notable change was yesterday, where the new fan bearing on CS fan 6 looks to have lowered the noise picked up by the vibrometer.
Sheila, Camilla
Checking SQZ:
Checking IFO:
Naoki, Sheila, Camilla
We tried this alignment and the middle, mainly changing pitch alignment. Both of these were considerable worse. We went back to yesterdays alignment, hand adjusted ZM4/6 in ASQZ then ran SCAN_SQZALIGN. Sdf's attached accepted.
Back to 4.5dB of SQZ above 1kHz and our reference 100-100Hz. SQZ seems to still be injecting low frequency noise.
Kappa_C is 0.5% better in this new SRC spot, plot attached.
Last night and today we are in a different spot through the OFI. See Sheila's alog 78096 for the move that was made.
Overall, SR2 and SRM yaw are much closer to center in this position, however SRM pitch is farther from center. I did a quick double check of the SRM pit, and indeed this is where it wants to be.
The previous spots (with the previous SR3 alignment) are recorded in alog 77443.
ampl [cts] of line at 31.0 Hz | A2L gain step size when minimizing | CAL-DELTAL line reduction factor | Final A2L gain | Inferred new spot position [mm] | Change from alog 77443 position | |
SR2 P2L | 1.0 | 0.1 | 100x | -1.0 | -2.0 | 13.1 mm other side of center |
SR2 Y2L | 1.0 | 0.1 | 100x | +0.3 | 0.6 | 9.7 mm other side of center |
SRM P2L | 2.0 | 0.1 | 50x | -5.5 | -11.1 | 4.3 mm farther from center |
SRM Y2L | 2.0 | 0.1 | 30x | +1.85 | 3.7 | 3.5 mm closer to center |
Attached are the saved SDF diffs for both Observe and Safe snap files.
Sheila and Keita have recently found and fixed sign convention errors. Please see alog 78393 for the corrected interpretation of A2L gains.
Sheila, Camilla. During this May 28th/29th SRC alignment, the OFI sees larger than usual temperature swings on locklosses and powerups. See plot attached. We saw similar larger OFI temperature swings on the re-locking attempts after our April 22nd optical gain drop before we changes alignments, shown in 78399 and second attached plot. Is the beam in this alignment hitting something in the OFI? Could be more likely the yaw alignment as that is common in both alignments with larger temperature swings.
FAMIS 25993, last checked in alog77948
No appreciable difference that I can see compared to last check.
Sheila added a new boost in DHARD to the guardian, and we relocked with it successfully, so I have accepted the SDF diff in Observe.
Wed May 29 10:15:30 2024 INFO: Fill completed in 15min 25secs
Gerardo confirmed a good fill curbside.
FAMIS 28354, last checked in alog77843
Late alog for the in-lock charge measurement taken last Tuesday before maintenance (May 21st). There was no measurement taken this week (IFO was unlocked before maintenance this Tuesday).
J. Kissel Remeasured the same remote, DAC-driven measurement of the whole OMC DCPD sensing chain -- the transimpedance amplifier, the whitening chassis, and the front-end compensation for the frequency response of those -- as yesterday, now 24-ish hours after the DCPD transimpedance amplifiers were powered on. Finally -- some good news! As suspected, after the giant inductors thermalized, the low frequency response has restored to the same post-2024-vent ~0.3% magnitude drop below 25 Hz. Yesterday, I'd only waited 20 minutes after turning them on when I took the data from LHO:78095. So -- clearly the thermal time constant for the inductors is longer than 20 minutes!
As I logged in this morning, the SQZ ASC and FC ASC offload and graceful clear history scripts that I ran and left open yesterday (whoops) reran. 15:16UTC. Before I could save sdf diffs, we went though DOWN SDF revert. There was nothing in SQZ ASC, but FC ASC got cleared. As squeezing hasn't been in a good alignment over the last 12 hours, this doesn't really matter. But if we were in observing it would have knocked us out.
Reminder to close scripts once used. CDS is there a way we can disable this from happening?
Currently these scripts are called from medm via command 'xterm -g 80x15 -hold -e python3 clear_FC_ASC.py &' or simular
After speaking with Dave and Joanthan there's two things to be done to avoid this in future:
-hold
'print("done")
time.sleep(60)
sys.exit(0)
TITLE: 05/29 Day Shift: 1430-2330 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Observing at 142Mpc
OUTGOING OPERATOR: Ryan S
CURRENT ENVIRONMENT:
SEI_ENV state: CALM
Wind: 5mph Gusts, 4mph 5min avg
Primary useism: 0.01 μm/s
Secondary useism: 0.08 μm/s
QUICK SUMMARY:
IFO just lost lock 14:47 UTC and now relocking
Dust monitors also have a few warnings:
*H1:PEM-CS_DUST_LVEA6 WARNING: dust counts did not change, please investigate
*H1:PEM-CS_DUST_LVEA10 WARNING: dust counts did not change, please investigate
*H1:PEM-CS_DUST_PSL101 WARNING: dust counts did not change, please investigate
*H1:PEM-CS_DUST_PSL102 WARNING: dust counts did not change, please investigate
BLRMs through our locks last night attached. Low frequency noise changes, this doesn't seem related to the wind.
TITLE: 05/29 Eve Shift: 2300-0800 UTC (1600-0100 PST), all times posted in UTC
STATE of H1: Wind
INCOMING OPERATOR: Ryan S
SHIFT SUMMARY:
A bit of a wind storm at the beginning of the shift but luckily strongest winds only lasted about an hour and allowed for locking shortly thereafter. Had about 4-5hrs of observing during this shift (with another lockloss minutes before the end of the shift).
LOG:
LATE Squeezer Entry For Yesterday!
Yesterday for the lock at the beginning of the shift (NLN around 100utc after the winds), the Squeezer did not lock on its own and also needed to run the scan_alignment_fds + sqz_angle states; also Naoki tweaked ZM4 a little before H1 eventually went to Observing. Below are the SDF diffs screenshots which were accepted:
J. Kissel EDIT :: False Alarm -- see comment below! Since I'm at the "what does it all mean?" stage of madness with the OMC DCPD Transimpedance Amplifier (TIA), I decided to make it worse -- I remeasured the original transfer function that triggered me worrying about the TIA response in after the OMC swap (see LHO:75986). I did this to try to corroborate whether there is a change in the DCPDA response above 1 kHz as mentioned in LHO:78090. This transfer function is the remote, DAC-driven measurement of the whole DCPD sensing chain -- the transimpedance amplifier, the whitening chassis, and the front-end compensation for the frequency response of those -- this has been described most recently in LHO:71225. I *don't* see a difference above 1 kHz, but I *do* see more difference in response below 25 Hz than I had in 2024-Feb-26. See the attached transfer functions of the DCPDA chain and the DCPDB chain. Black is pre-OMC swap, 2023-Jul-11. Brown is post-OMC swap, 2024-Feb-26. Red is today, also-post OMC swap, 2024-May-28. All measurements use the S2300003 whitening chassis, and the compensation from the 2023-Mar era compensation we've been using throughout O4. The only "oh, well it could just be" that I can think of immediately is that the DCPDs had been powered down from 10:10a to 11:30a PDT today to characterize the measurement setup in analog (see LHO:78090), and these were measured "only" 20 minutes after being powered back on at 11:50a. So -- we'll have to take the measurement again at the next opportunity -- such that the TIA electronics have what we think it the appropriate amount of time to thermalize -- a few hours. Just maddening. Data lives in /ligo/svncommon/CalSVN/aligocalibration/trunk/Common/Electronics/H1/SensingFunction/OMCA/Data/ 20240528_H1_TIAxWC_OMCA_S2100832_S2300003_DCPDA_RemoteTestChainEXC.xml 20240528_H1_TIAxWC_OMCA_S2100832_S2300003_DCPDB_RemoteTestChainEXC.xml
False alarm! It appears indeed that I had inadvertently captured a thermal transient of the transimpedance amplifiers -- since it had only been 20 minutes since I'd turned on the power to the preamps. See LHO:78112, where I took this same measurement again, and the response restored to the same post-2024-OMC-swap-vent response.
Andrei, Sheila
We've analyzed the time-traces of the effective range (H1:CDS-SENSMON_CAL_SNSW_EFFECTIVE_RANGE_MPC
) along with the alignment channels FC_WFC_A(B)
and AS_A(B)_RF42
(see attached figures). We found no observable dependance between those.
During the time period being investigated in this alog on May 27, LASSO flags H1:TCS-ITMX_CO2_ISS_CTRL2_OUT_DQ as strongly correlated with the range. This channel and other related channels have been flagged as highly correlated to the range in recent days, but this time period shows the strongest correlation.
Jumps in this TCS channel correlate with range jumps, as shown in the attached comparison of the TCS and range trends on May 27.
Tagging TCS
This TCSX ISS correlation is a bit odd since we aren't using the ISS and the AOM, I believe, is completely unplugged. That said, I looked at some of the channels in that system and there is some extra noise seen around the times Derek posted (see May 16th example). I wonder if this points to a larger grounding issue or some other electrical problem that is seen more broadly.
These range fluctuations that we think are related to the squeezer started (I think) on May 16th: 77869
The first time cursor in the attached screeshot shows that range drip which I thought was traffic related at the time. Looking at the long term trend of this CO2 ISS control signal, there is a chance in charachter at this time, with more drifts in the signal level since. The second screenshot shows that this channel had a large jump on May 17th around 20:04-22:33 UTC.
There is a DARM BLRMS that may be more useful for tracking this noise than just looking at range, H1:OAF-RANGE_RLP_3_OUTPUT. (third screenshot shows this also had a change point and drifts more since May 16th.)
On May 13th (as part of my DQ shift), I noticed a line of 4kHz glitches in the glitchgram, and they have appeared every day since then. Checking the summary pages revealed they’ve been intermittently present since Apr 8, 2024 but not previously (I checked from Dec 1, 2023 onwards). Fig. 1 shows an example glitchgram from May 13th. Figs. 2-4 show Omegascans for some of these glitches. I also created a spreadsheet to characterize these glitches, and did not find any pattern or regularity to their appearance.
I checked the aLogs for possible sources and found the SQZ angle was being tuned around the time the glitches started (aLog). I then compared the timing of the glitches to the SQZ: FC ASC channels and found a correlation between the deviation in the output and the strength of the glitches. See Figs 5-7 for examples, as well as the spreadsheet. I will be meeting with the LSC fellows on Tuesday to discuss these.
Since May 24, the 4kHz glitches looked somewhat mitigated.
The correlation between the deviations of SQZ channels and the loud glitches at 4kHz has been hardly seen since May 24.
(The attachments are Omicron trigger plot and SQZ FC ASC channel on May 26)
There were SQZ commissioning works on May 24, and there are 2 alogs (alog 77980, alog 78033) related to SQZ alignment and the low frequency noises.
The 4kHz glitches are back on May 29, and the correlation between the glitches and the deviation of SQZ FC ASC channels looks apparent again.