TITLE: 06/14 Day Shift: 15:00-23:00 UTC (08:00-16:00 PST), all times posted in UTC
STATE of H1: Lock Acquisition
SHIFT SUMMARY:
More observing than last night, but there was another shorter wind storm (winds over 30mph) which prevented locking for 3+hrs. Commissioing time was used for a Robert measurement and PRCL OLG. Squeezer knocked H1 out of Observing for about 3min toward the end of the shift, but came back on its own.
LOG:
At about 615pmPT (or 115utc), winds started peaking above 30mph (lockloss at 219utc), and have flattened out there with some peaks hitting 50mph. Not as dire as last night, but it is a windy ruckus out. Taking OBSERVATORY Mode to WIND, keeping ISC LOCK at LOCKING ARMS GREEN, and will assess in 1hr. Oh there was also a 6.2 EQ from the Phillipines, but Seismic is already back to Calm. (Time to make supper.)
If it's like yesterday, the winds started to die down after the sun went down around 9-10pm.
Jenne had me run a couple of PRCL OLG measurements this evening. Referencing Camilla's measurement from alog #70451.
Measurement #1 ~00:49utc
The first measurement was done as soon as we were at NOMINAL LOW NOISE (had to wait a few min for the Camera Servo node to complete) at 0049utc. Magnitude is 1 at 32.0Hz with phase of 24.1 deg.
(see attached 1st plot & file is at /ligo/home/corey.gray/dtt/prcl_olg_noise_full_lock_nln_0049_15062023.xml)
Measurement #2 ~01:19 utc
Second measurement was run after Robert performed PEM measurments. Magnitude is 1 at 35.0 Hz with phase of 25.1 deg.
(see attached 2nd plot & file is at /ligo/home/corey.gray/dtt/prcl_olg_noise_full_lock_nln_0119_15062023.xml)
Another pretty windy day, I've been looking at the ETMY ISI to see if any changes can be made to help staying locked. Only easy thing I've found so far is turning off the off-axis sensor correction. Watching the outputs here, it is contributing to the ISI swinging several microns. I don't think it will change much, but don't have a lot of other things to try, at the moment, and it probably can't hurt. I've accepted the diff in the observe file, so this shouldn't affect our ability to go to observe when Corey is done relocking.
Attached trend shows the St1 X cps on the top, on the bottom 2 different points of the X sensor correction path to show when I turned it off, green is the filter output, orange is the output of the downstream match bank where I turned off the output. When the sensor correction is on the CPS is mostly dominated by it at low frequency, swiinging almost 10 microns at points. With sensor correction off, when the orange trace goes to 0 on the bottom, the cps stops moving around so much.
This was turned off 06/14 23:50UTC, and will be kept off for now. Tagging DetChar.
EndX Station Measurement
During the Tuesday maintenace, the PCAL team(Rick Savage, Julianna Lewis, & Tony Sanchez) went to EndX with Working Standard Hanford aka WSH(PS4) and took an End station measurement.
The EndX Station Measurement was MOSTLY* carried out according to the procedure outlined in Document LIGO-T1500062-v15, Pcal End Station Power Sensor Responsivity Ratio Measurements: Procedures and Log, and was completed by 10:30am. LIGO-T1500062-v15 is attached. After we were done but before we left we took a new background measurement with the PCAL covers on.
First thing I do is take a picture of the beam spot before anything is touched!
Martel:
We started by setting up a Martel Voltage source to apply some voltage into the PCAL Chassis's Input 1 channel and we record the times that a -4.000V, -2.000V and a 0.000V signal was sent to the Chassis. The analysis code that we run after we return uses the GPS times, grabs the data and created the Martel_Voltage_Test.png graph. We also did a measurement of the Martel's voltages in the PCAL lab to calculate the ADC conversion factor, which is included on the document.
After the Martel measurement the procedure walks us through the steps required to make a series of plots while the Working Standard(PS4) is in the Transmitter Module. These plots are shown in WS_at_TX.png.
Next steps include: The WS in the Receiver Module, These plots are shown in WS_at_RX.png.
Followed by TX_RX.png which are plots of the Tranmitter module and the receiver module operation without the WS in the beam path at all.
The last picture is of the Beam spot after we had finished the measurement.
All of this data is then used to generate LHO_EndX_PD_ReportV2.pdf which is attached, and a work in progress in the form of a living document.
All data and Analysis has been commited to the SVN.
https://svn.ligo.caltech.edu/svn/aligocalibration/trunk/Projects/PhotonCalibrator/measurements/LHO_EndX/
*After the Normal Measurment: Rick and I put the covers back on like normal, but we shuttered the Laser again, to try and get a backgorund measurement of the Rx Sphere with all of the covers on.
The GPS StartTime for this new measurement is 1370712650.
PCAL Lab Responsivity Ratio Measurement:
A WSH/GSHL (PS4/PS5)FrontBack Responsivity Ratio Measurement was ran, analyzed, and pushed to the SVN.
The analysis of this measurement produces 4 PDF files which we use to vet the data for problems.
raw_voltages.pdf
avg_voltages.pdf
raw_ratios.pdf
avg_ratios.pdf
All data and Analysis has been commited to the SVN.
https://svn.ligo.caltech.edu/svn/aligocalibration/trunk/Projects/PhotonCalibrator/measurements/LabData/PS4_PS5/
A surpise BackFront PS4/PS5 Responsivity Ratio appeared!!
PCAL Lab Responsivity Ratio Measurement:
A WSH/GSHL (PS4/PS5)BF Responsivity Ratio measurement was ran, analyzed, and pushed to the SVN.
The analysis of this measurement produces 4 PDF files which we use to vet the data for problems.
raw_voltages2.pdf
avg_voltages2.pdf
raw_ratios2.pdf
avg_ratios2.pdf
This adventure has been brought to you by Rick Savage, Julianna Lewis, & Tony Sanchez.
TITLE: 06/14 Day Shift: 15:00-23:00 UTC (08:00-16:00 PST), all times posted in UTC
STATE of H1: Lock Acquisition
SHIFT SUMMARY: some Observing time and a commissioning period today, planned to do calibration sensing function measurements but lost lock before these started.
LOG:
IFO changes config changes today: SQZ angle 70440 and OMC DCPD balance.70453
| Start Time | System | Name | Location | Lazer_Haz | Task | Time End |
|---|---|---|---|---|---|---|
| 15:21 | FAC | Christina | OSB Receiving | N | Opening Roll up door | 15:51 |
| 16:45 | SQZ | Camilla | CR | N | SQZ angle adjustments 70440 | 17:15 |
| 17:54 | PEM | Robert | LVEA | N | checking PSL make-up air while IFO down | 18:29 |
| 18:26 | FAMIS | Tony, Brice | EY | N | Dust pumps check | 18:55 |
| 18:35 | VAC | Janos | MY | N | checking on pump outside VEA | 18:54 |
| 18:45 | Eadie | Y-arm | N | Jogging | 20:04 | |
| 18:53 | PEM | Robert | CER | N | Check while IFO locking | 18:53 |
| 21:38 | COMM | Brina | CR | N | HAM1 FF off 70450 | 21:39 |
| 21:38 | COMM | Camilla | CR | N | PRCL OLG 70451 | 21:39 |
| 21:39 | COMM | Naoki, Vicky | CR | N | PI damping changes 70452 | 22:30 |
| 21:40 | PEM | Robert | CR | N | HVAC on/off tests | 21:58 |
| 21:59 | COMM | Sheila | CR | N | DCPD balance and No-SQZ 70453 | 22:28 |
| 22:00 | CDS | Erik | Remote | N | Updating temperature ioc 70455 | 23:00 |
TITLE: 06/14 Day Shift: 15:00-23:00 UTC (08:00-16:00 PST), all times posted in UTC
STATE of H1: Commissioning
CURRENT ENVIRONMENT:
SEI_ENV state: CALM
Wind: 17mph Gusts, 9mph 5min avg
Primary useism: 0.03 μm/s
Secondary useism: 0.21 μm/s
QUICK SUMMARY:
Arrived to H1 on its way back to NOMINAL LOW NOISE and received a day shift summary from Camilla. Much better weather-wise *knock on wood*. No other notable issues while waiting for H1.
Lockloss @ 22:23 UTC 1370816616
Lockloss was at time with a peak in wind up to 30mph. We are seeing similar movement in the SRC that Brice found yesterday 70408 70418
Could be from PRCL again, hard to tell because this particular oscillation is so fast. It doesn't appear to be ASC. Tagging ISC
I updated the LVEA_TEMP ioc, which tracks rate of change for LVEA temperatures, to fix a bug in its alarm queue.
Naoki, Vicky
To try damping the 80 kHz PI recently causing locklosses (LHO:70434), today we installed a new path on PI28, with drive sent to ETMX. To phase-lock the ESD damping drive to the PI mode, we bandpassed the DCPD signal around 80.296 kHz (foton here). This frequency was chosen based on the DCPDs full-spectrum signal around 80.3 kHz, which today we saw the 3 peaks in red here between 80.295-80.301 kHz in full lock. It seems like our problem is the bigger peak around *296, where pink cursors are centered. We are trying to damp on ETMX first, since it seems like PI29 80kHz damping on ETMX could impact this mode.
The new path for PI28 has been updated and damping is guardianized, but this PI28 damping is untested, and there are no verbal alarms for PI28 yet.
Summary with the current status of PI damping:
| PI frequency | PI damping mode number | Test Mass | PI Guardian status | _DAMP_GAIN |
| 10.428 kHz | 24 | ETMY | automated | 1000 |
| 10.431 kHz | 31 | ETMY | automated | 1000 |
|
80.302 kHz (LHO:68760) |
29 | ETMX | automated, likely working (LHO:70243) |
50000 |
|
80.296 kHz (LHO:70443) |
28 | ETMX | guardianized, testing now |
50000 |
SDFs were recoinciled after, see screenshots -- mainly, we un-monitored guardian-controlled things like the damping phase and PLL integrator.
I've added in a test for PI mode 28 into verbal alarms with an RMS threshold of 1 for now (the same as mode 29).
Just checking in, looks like PI28 does at least see a mode come through ~1-2 hours into lock (RMSMON spikes just before NLN b/c OMC whitening, the second peak is the real one), but this hasn't run away yet. Then ~10 min after PI28, looks like PI29 sees something pass through.
Looking at disaggregated temperature trends across the EX VEA over the last year, it might be a bit misleading to only look at the "average EX VEA" temperature. Temperatures in some parts of the EX VEA seem to have drifted by up to 0.5-2 deg F over the past few months. Temps now seem to be returning to where they were about 6mo - 1 year ago.
I think Robert and Aidan have both made the point that, to understand temperature drifts, it's helpful to look at the individual temperature sensors across the VEA, rather than the average VEA temperature. For example, see Aidan's alog LLO:25785 where he also thought about stabilizing the VEA temperatures to a different sensor, which is better correlated with the test mass temperature. For this 80 kHz PI though, Aidan's also said that the temperature dependence of the mechanical mode freq is about 80ppm/K, so for ~0.5K (delta~1degF), the HOM frequency changes by ~3 Hz for the 80 kHz mechanical mode, and it seems unlikely we're just within 3 Hz of the PI going unstable -- so it's not totally convincing that our recent 80 kHz PI ring ups are simply b/c VEA temperature drifts. But at least, at LLO, he found their ETMY is most correlated with the EY VEA_202B sensor.
I'm not sure which of LHO's EX VEA sensors are most correlated with ETMX. But, it may be worth considering more than the average VEA temperature. Especially since the individual temperature sensors have seen some drifts over the past year, which aren't seen by trends of the average VEA temperature.
Brina, Sheila
The DCPD balance matrix is normally set by Jeff using the method described in 47217. Today I wanted to try setting the matrix so that the contribution of the two sensors to the DARM loop gain is set to be equal, because I think this will make it easier to correct for the imbalance of the PDs while doing the offline cross correlation. I compared pcal line heights in the DCPD_A and DCPD_B at 17.1 Hz (A/B = h = 1.0277) and at 410.3Hz (A/B = 1.0362). We chose the 17Hz value, and calculated the matrix elements for DCPD A to the SUM 2/(h+1) = 0.9863 and B to the sum 2h/(h+1) = 1.0137.
The attached text file has commands used to copy and paste into a guardian shell to swap the DARM loop to one DCPD, and change the matrix elements. After doing the swap we measured the DARM OLG, which is the live trace in the attached dtt template.
no sqz start: 1370816035 (Jun 14 2023 22:13:37 UTC). lockloss: 22:23:18 UTC, we were just sitting there collecting data with no SQZ. The matrix elements have been reset by SDF.
deleted
Here are some plots of the cross correlation for this time.
The first is a comparison of the pyDARM model of the OLG to the measured OLG. At 24Hz, the model was predicting 2% less gain than the measurement, so here I've scaled the model up by 2% and used that for the estiamtion of the correlated noise.
The second plot is the DCPD sum ASD loop corrected compared to the cross correlation. You can see that the cross correlation is above the DCPD sum by 7% at 24Hz, which is incorrect. I thought about if this could be because of the imbalance of the DCPDs, I will attach a note here that explains how I attempted to handle this imbalance in estimating the cross correlation. (The DCPD_A and B channels are recorded before mulitplying by the balance matrix, the sum channel is after that matrix.) In the end this did not make a significant difference, the cross correlation is still nearly 7% overestimating DARM at 24Hz when I corrected for this.
The third plot shows the cross correlation compared to an estimate of the correlated noise obtained by subtracting the calculated shot noise from the DCPD SUM asd in quadrature, this mostly agrees with the cross correlation except at low frequencies.
These plots were made using the code https://git.ligo.org/sheila-dwyer/cross-corelation commit 3c60740b I will attempt to make a comparison of this code with Craig's cross correlation code to see if this problem is still present there.
Here is a note describing how I corrected for the DCPD imbalance. Once the matrix was reset as above, things become simple. I will add a diagram to this note if I have time.
Daniel raised the point that perhaps a phase difference between the two PDs could explain a discrepancy at low frequency, in the correction I did I assumed that the two paths were only imbalanced by a scalar gain. The attached png shows a transfer function between the two DCPD channels, taken at the time of one of yesterday's broadband pcal injections. The frequency dependence of this at first glance doesn't seem right to explain what we see, ie, the error in the cross correlation doesn't have a wiggle between 20-30 Hz, although the error does seem to happen around the frequency of the cross correlation problem.
Last done in alog 70160. Measurement taken after 2h35 in NLN.
Magnitude is 1 at 26.5Hz and 26.5degrees. Plot attached.
Here is a plot showing the PRCL gain thermalization (same as from alog 70211), but with information from Camilla's measurement today added in the small grey marker at about 155 mins. It needs to be high relative to what we'd been using (pink line) since June 6th. Recall that these PRCL locklosses we've been having are likely because our PRCL gain is too low. So, I'll see if I can make another thermalization curve that increases faster.
I've got a new candidate thermalization, the yellow curve in this (becoming much too busy) plot. This won't quite get the gain as high as it wants at the 2hr35min point, but it also won't overshoot the 4 hour target from 6 June 2023 by too much. The thermalization guardian just holds the gain at the value at the end of this plot (it doesn't keep following the curve forever), so the final gain won't be very different with this new candidate (yellow) versus what we've been running with after 6 hours of lock in pink.
I'm going to implement this quickly before we get relocked. This means using a GAIN_SCALE of 5.25 (has been 5.55 for pink trace) and a TIME_CONSTANT of 5571 (has been 7800 for blue, orange, pink, green traces).
I modified and loaded the THERMALIZATION guardian, and checked it in to the svn, while we were relocking. Hopefully this will reduce the number of PRCL locklosses we're seeing.
Commissioning period,
The Ham1 FF was turned off for testing on 06/14/23 21:32:15. It stayed off for 5 minutes and was turned back on at 21:37:15.
My motivation for this test came from a bruco that I ran on the data from a long lock over the weekend: https://ldas-jobs.ligo-wa.caltech.edu/~elenna.capote/brucos/CAL_1370343461/
Specifically, the CHARD P, INP1 P and HAM1 TT L4C RY coherence were much higher than expected, and much higher than they had been in the past after successful HAM1 FF tuning and A2L gain adjustments.
The test first confirmed that we are still seeing decent subtraction of the HAM1 noise from the ASC loops, as seen in an OMC DCPD sum comparison with the feedforward on and off. I also grabbed spectra of each of the ASC loops with the feedforward on and off (in this plot the red, live traces are with the feedforward off, and the blue reference traces are with the feedforward on).
I used the feedforward off time to run the NonSENS training code and calculate a new feedforward for CHARD P, INP1 P and PRC2 P. The code also makes plots of the expected subtraction of the loops. I compared the expected subtraction plots (linked below) to the current subtraction plots linked above, and I conclude that:
I didn't check any yaw loops because there is already decent noise removal, and coherences are low. I don't expect to see much improvement there.
I will install the new INP1 P and PRC2 P feedforward filters, labeled with today's date. I think they should be engaged for the next lock if possible.
I don't understand why the coupling has changed, but I think this is a similar mystery change that changed like several other things in the IFO changed recently- perhaps some new alignment from the PR3 move? In other words, unless we have to make another big alignment change like that, I don't expect us to need to update this feedforward for a while.
Turning off the HAM1 feedforward made the CHARD and PRC2 noise signficantly larger, by about a factor 10. The effect on DARM is significant, and consistent with the fact that CHARD or PRC2 are coupling more now than before, and when the FF was on were just below the measured DARM. This is consistent with the measured coherence between DARM and CHARD or HAM1 sensors.
One possible reason for the higher coupling of HAM1 noise to DARM is that the beam spot might have moved on PR2 (where PRC2 is driven) and therefore the A2L we tuned some time ago might be wrong. It's worth and quick retuning the PR2 A2L and see if that improves the coupling of PRC2 to DARM and maybe even DARM noise.
The new filters have not yet been installed because I am getting errors from foton when I try to copy them in. I will try again tomorrow.
I have installed the new feedforward filters for INP1 and PRC2. They are labeled with "0616" for today's date. They are currently not in use, but can be quickly tested during a commissioning period. A thermalized IFO is best for the test, but they can be tried at any time.
New filters implemented and SDFed.
This commissioning period has been coordinated with LLO. Plans for the next ~2 hours:
Edited: due to lockloss we did not complete EX camera set up, or calibration sweep. Sheila only got 10 minutes of data rather than the 15 minutes wanted.
Famis Task: 23750
I wanted to just swap the pumps with the one below the table but couldn't reach the pump rebuild log https://dcc.ligo.org/LIGO-Q2200010 because i didn't have any internet at the end stations and couldn't determine if the spares had been rebuilt already or not.
EX
Dust pump number 2950 Not running and Unplugged.
I checked the Log and noticed that pump 2950 only lasted 2 months. But the pump below the table was newly built around the same time.
So I'm going to Leave the Famis Task open until I can swap out the pump.
EY
Dust pump was Running pressure was 19.5 inHg.
No temps over 151F .
Corner Station
Dust pump number 1194 Power not switched on.
Spare 1119313238 has also been rebuilt and is ready to be swapped out.
I will try to swap these out Tomorrow or Tuesday.
UPDATE!! CS Dust pump Pump Power not switched on. I spoke to TJ about it. It's on a breaker and I beleive the breaker tripped. I had to turn it off before I could turn it back on. When I turned it on It sputtered to live and puffed a rather large puff of dust out. So much so it startled our Surf student Rachel and I. It was getting vacuum pressure around -14 inHg. So I swapped it out for 3238. The Brass threaded fitting below the 4 way splitter that the gauge is afixed to in the top of the housing is stuck and I couldn't remove it for the swap. I ended up finding a good replacemet for the threaded brass fitting to go into the next pump i swapped it for. The new pump # ending in 3238 is running great and has more than enough vacuum pressure, I set the pressure to be at -19inHg. The pump that was removed was placed in the OSB receiving room to be rebuilt or otherwise just cleaned up. EX Dust pump Pump number ending in 2950 Not running Unplugged. I plugged it in and noticed that it was not getting very past -9 inHg and sounded unwell. I came back the next day to find that the pressure was still too low though it had creeped up to -13inHg. I then swapped out the pump with the one under the table Pump # ending in 2109which was newly rebuilt. This too was still too low of a pressure around -14.5inHg. I checked the filters for tightness on the front of the pump housing. I then jiggled the vacuum hose a little and saw a the pressure go back up. So I checked the hose fitting and noticed that the hose was affixed to a plastic fitting that has threads going into to the brass 4 way fitting without any plumbers tape. I then put some plumbers tape on it, put it back together and fired her back up. I still didn't see the pressure we desired it's only at -17inHg. I went back to day to check on it and it's still at 17inHg. There is not any more room for adjustment on the vacuum pressure adjuster. The old pump is in the OSB recieving room. I will try to open up those pumps next week.
Naoki, Vicky
In alog70212, Vicky stepped ZM5/6 P/Y by 100 count (-100 count for ZM6 P) to check the sensing matrix of SQZ ASC. We checked the response of AS A/B RF42 as shown in the attached ndscope. The measured sensing matrix is as follows.
| ZM5 P | ZM6 P | ZM5 Y | ZM6 Y | |
| AS A RF42 P | 0.61 | |||
| AS B RF42 P | -0.15 | 0.2 | ||
| AS A RF42 Y | 0.16 | 0.61 | ||
| AS B RF42 Y | 0.1 | 0.5 |
It seems the AS B RF42 has some P/Y cross coupling (or ZM5 driving has P/Y cross coupling?), but apart from that, the input matrix of SQZ ASC should be proportional to the inverse matrix of the measured sensing matrix, which can be calculated as follows.
| AS A RF42 P | AS B RF42 P | |
| ZM5 P | -6.7 | |
| ZM6 P | 1.6 |
| AS A RF42 Y | AS B RF42 Y | |
| ZM5 Y | 2 | |
| ZM6 Y | 1.6 | -0.52 |
The current input matrix for SQZ ASC is shown in the second attached figure. The POS and ANG correspond to the ZM5 and ZM6, respectively. Compared with the calculated matrix above, the current input matrix seems not correct. The correct input matrix should be proportional to the calculated matrix above and I propose a new input matrix as follows, which is larger than the calculated matrix by a factor of -10. This factor of -10 is chosen to have the same order of input matrix as the current one and it can be adjusted depending on the desired UGF of SQZ ASC. We will try this new input matrix soon.
| AS A RF42 P | AS B RF42 P | |
| ZM5 P | 67 | |
| ZM6 P | -16 |
| AS A RF42 Y | AS B RF42 Y | |
| ZM5 Y | -20 | |
| ZM6 Y | -16 | 5.2 |
I engaged the new input matrix around 1370378757 (2023/06/09 20:45:39 UTC). Everything seems working, but we need to compare the squeezing performance before/after this change carefully.
Tagging SUS. At the first 23:21UTC lock acquisition, the last guardian to arrive and allow us into Observing was VIOLIN_DAMPING. Can we think about reducing it's sleep timer?