Maintenance Timeline:
There have been several times recently when operators had trouble relocking the squeezer after it unlocks and takes us out of observing, which seemed to be solved by re-requesting different states from the squeezer guardian.
The reason the squeezer knocks us out of observing is because the SHG PZT hits it's rail, this seems to be happening ~once or twice a day.
The reason the squeezer wasn't relocking is because the beam diverter wasn't re-opening after the squeezer relocked. The problem was that the beam diverter won't respond to multiple requests to move that happen too soon after each other, and in some places the guardian was making the requests to rapidly.
Daniel added a channel for the beam diverter called "busy" which can be checked before making a request of the beam diverter. This problem should be avoided with changes to the SQZ_MANAGER for the time being, but in the future we can have a busy check for the beam diverter.
Attached below are the results for the OPLEV charge measurement for ETMX and ETMY. The bias voltage for ETMX is between 10-20V (except for one case for Yaw which is around 30V). The bias voltage at ETMY is between 0-10V. The bias voltage measured for both ETMX and ETMY are still not high enough, which would require a sign flipping.
Once the measurements were complete, all the values were restored.
WP 8105
CER network secondary power supply is now connected to -48V from UPS.
F. Clara, R. McCarthy, M. Pirello
On 04/22/19 took a set of photos of the ITM Optics. Shots were taken with the IFO locked at 35w of power.
ITM-X photo: Frame #5, 1/160, ISO 200, Focus 1625
ITM-Y photo: Frame #6, 1/250, ISO 200, Focus 1625
The shots select were a bit under exposed, which helps show the point reflections, but not so under exposed as to hide the EQ screws, which can be used as a point of reference.
We had a small leak in a PSL hose, which is fixed, and there was no damage, but it did delayed some work, which is going on right now, so we're running over the noon mark for ending Maintenance.
This morning Robert noticed water on the floor of the PSL enclosure. Inspection showed the leak to be at the barb fitting on the output side of the Diode chiller filter. There was a bulge in the hose from the hose clamp to the end of the barb. The Teflon inner liner of the hose had failed at the barb, allowing water between the Teflon and the outer rubber, which created the leak. Shutdown the laser and the Diode chiller. Cut out the bad section of hose and reconnected the hose to the filter. Powered up the system and noted no further leaks.
The Corner Station is the only building that requires a continuous instrument air supply (under normal, non-turbo pumping conditions) as the site pneumatic LN2 liquid level control valves and HVAC damper adjusters have been converted to electric. Only the pneumatic 44" gate valves in the LVEA, GV5, GV6, GV7 and GV8 still need 24/7 pneumatic air. As such, attention to this one supply has waned. The pressure is monitored by the CDS system but the dryness must be measured periodically.
So, today I measure the dew point as sampled near GV5 to be -24C.
J. Kissel
Given that
- We've recently identified that glitching around 60 Hz in certain event trigger generation metrics has been a result of the 7.93 Hz PCAL EY calibration line, (LHO aLOG 48418),
- The GDS pipeline's calculation of the time-dependent correction factors for the SRC detuned optical spring (f_s and Q_s) has stopped using the 7.93 Hz calibration line, and its results are consistent with the reference model,
- that the front-end code that duplicates this calculation has been busted since we've had a pro-spring,
there is no longer a use for this now detrimental calibration line.
Thus, today, this morning, during maintenance, I have turned off this calibration line, and it will remain so in all future observation segments.
Note, that this also reduces the RMS requested drive from 6163 DAC counts to 5043 cts.
All other lines requested from the PCAL EY remain -- 17.1 Hz, 410.3 Hz, and 1083.7 Hz.
Attached are the screenshots of the SDF capture (done in both safe and OBSERVE snaps), and an ASD of the DAC request.
Stay tuned for details from @DetChar about the reduction in glitch rates.
J. Kissel Also -- of interest to the CW group, and those investigating non-linearities in ADCs and DACs (see, e.g. LHO aLOG 48357, and LHO aLOG 48666) -- turning off this line drastically reduces several combs of harmonics in the RX and TX PD displacement spectrum. Unclear if these non-linearities are real displacement on the test mass (i.e. driven in to the light via a non-linear DAC system and making it past the optical follower servo's suppression, and then past the 1/f^2 force-to-length transfer function of the pendula), or non-linearities in the ADC for each photo-diode's electronics chain, though... I look forward to deep searches of h(t) with long FFTs comparing before vs. after this change.
Thanks for the update, Jeff. It will take some time to gather enough statistics, but it will be nice to look before and after this and other calibration line changes to see what effect they have on spectral artifacts in h(t).
Both PSL power watchdogs were reset at 16:05 UTC (9:05 PDT). This completes FAMIS 10707.
Niko - Tanking End-X to Laser hazard
All three (EX, EY, CS) vacuum pumps are running normally. Made a minor pressure adjustment at EX and CS. EY did not require any adjustments. Closing FAMIS task #8557
TITLE: 04/23 Day Shift: 15:00-23:00 UTC (08:00-16:00 PST), all times posted in UTC
STATE of H1: Preventive Maintenance
OUTGOING OPERATOR: Ed
CURRENT ENVIRONMENT:
Wind: 6mph Gusts, 5mph 5min avg
Primary useism: 0.03 μm/s
Secondary useism: 0.15 μm/s
QUICK SUMMARY: Maintenance has begun, still locked at Sheila's and then Robert's request.
TITLE: 04/23 Owl Shift: 07:00-15:00 UTC (00:00-08:00 PST), all times posted in UTC
STATE of H1: Observing at 92Mpc
INCOMING OPERATOR: Cheryl
SHIFT SUMMARY:
LOG:
14:32 Squeezer dropped out and took H1 out of Observing.
14:35 Jeff B out to Ends for dust monitor check
14:37 Squeezer recovered and intention bit reset.
14:45 taking H1 to Commissioning mode to run PEM script
14:57 Karen out to EY
15:00 Handing off to Cheryl
ran at 14:45UTC
edmond.merilh@zotws3:/opt/rtcds/userapps/release/sys/h1/scripts$ ./PEM_weekly_magnetic_injection.py
Performing PEM injections through these channels:
H1:PEM-CS_GDS_0_EXC
H1:PEM-EX_GDS_1_EXC
H1:PEM-EY_GDS_1_EXC
Use Control+C anytime to STOP ALL injections.
Performing injections with gain 500000 from 10 to 100 Hz.
Injecting through channel H1:PEM-CS_GDS_0_EXC for 45 seconds.
Waiting for 20 seconds before making the next injection.
Injecting through channel H1:PEM-EX_GDS_1_EXC for 45 seconds.
Waiting for 20 seconds before making the next injection.
Injecting through channel H1:PEM-EY_GDS_1_EXC for 45 seconds.
Waiting for 20 seconds before making the next injection.
Performing injections with gain 160000 from 100 to 1000 Hz.
Injecting through channel H1:PEM-CS_GDS_0_EXC for 45 seconds.
Waiting for 20 seconds before making the next injection.
Injecting through channel H1:PEM-EX_GDS_1_EXC for 45 seconds.
Waiting for 20 seconds before making the next injection.
Injecting through channel H1:PEM-EY_GDS_1_EXC for 45 seconds.
Waiting for 20 seconds before making the next injection.
DONE WITH ALL INJECTIONS.
Made it to NLN & handful of SDF diffs. Went through the diffs while PEM injections were going on.
1) H1:SUS-MC2_M1_DRIVEALIGN_L2L_SW1R was saved in a wrong state with this OFFSET "on".
(Note: Jenne gave guidance about this channel. It is avail to turn "on" if we are having trouble locking the IMC & want to give it a little bump to help locking. But we should remember to turn this "off" as soon as the IMC locks. So this must have been Accepted when it was accidentally left "on". Anyway, tonight this offset was in the correct "off" state, and had the diff, so we ACCEPTED. Jenne fixed this issue for the future by adding a line in ISC_LOCK to turn OFF this offset--I believe she said in the PREP_FOR_LOCKING state.)
2) ECAT PLC1 Had Diffs (SDF diffs screenshot #1 attached) Due to ALS Remote Motorized Polarization Controller (medm screenshot #2 attached)
Not really sure why we're monitoring these channels (i.e. the Paddle X, Y, & Z channels) because these channels change whenever we make remote polarization changes. So, I unmonitored these three channels.
3) SPM Diff for TRamp for ISI EY
For some reason the Stage 2 Rx & Ry TRamps were 0 and SPM had a set point of 5. Since this is benign, I changed the TRamps to 5, but this then gave us new SDF diffs---which I ACCEPTED.
As for the polarization controller: These channels should be monitored and updated when the polarization is adjusted. Keep in mind that when you turn the controller on, you loose the last value and have to restore it! Set them back to monitoring.
J. Driggers, J. Kissel, L. Sun
Today, during the calibration measurement time, we've done the following:
(1) Tuned the calibration line heights such that the uncertainty of each line is now roughly 0.2%.
2019-04-17_TuningCalibrationLineAmplitudes_Uncertainty.png shows the time series of the uncertainty for all calibration lines over many hours before and after the line amplitude change -- the middle section is where they were turned off for the standard suite of calibration sweeps; before they were at their former value, after they were at their current value.
(2) We realized the discrepancy between GDS production of kappa_C (the relative optical gain correction) and f_cc (the cavity pole frequency) and CAL-CS was because in the heat of battle yesterday, we neglected to update the value of the necessary one clock-cycle delay to 410.3 Hz in the PCAL DEMOD -- i.e. it errantly remained as the delay value at the former calibration line frequency at ~331 Hz. Fixing this error returned the time-dependent correction factors to the expected values from the reference model: kappa_C = 1.00 +/- 0.01, and f_cc = 410.6 +/- a few Hz (as opposed to the brief period yesterday between after the calibration line frequencies and now, where the cavity pole was reporting in the 425 Hz region, and the optical gain correction was reporting 0.97).
2019-04-17_FixingPCALDEMODPhase_410Hz_Fixes_TDCFs.png shows a screenshot of the current values.
(3) We gather a collection of broad-band PCAL injections, as well as the standard sensing function sweeps.
Times of broad-band PCAL injections: 2019-04-17 20:13:20 UTC for ~2 minutes, and again at Apr 17 2019 20:15:31 UTC.
/ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/O3/H1/Measurements/FullIFOSensingTFs
2019-04-17_H1_DARM_OLGTF_SS_5to1100Hz_15min.xml
2019-04-17_H1_PCAL2DARMTF_BB.xml
2019-04-17_H1_PCAL2DARMTF_SS_5t1100Hz_10min.xml
The data remains remarkably consistent with the reference model (see 2019-04-17_H1_sensingFunction_mcmcModel_vs_measurement.pdf ).
We've stacked all the recent sensing function measurements without correcting for time dependence to form an estimate of the frequency dependent, time-independent systematic erro with a Gaussian process regression, and it shows the same consistency (see 20190416_ref_model_H1_sensingFunction_GPR_on_AllSensingMeasurements.pdf)
More details to come.
Here is a look at one of the excursion that happened in the front-end estimation of kappa_tst (first one seen in this summary page). The attached plot show various estimations of kappa_tst that happens in the front-end. It also show uncertainty estimation in the calculation of calibration line ratios. We see that when the uncertainty in the estimation of calibration line ratios exceeds set threshold of 0.02, it triggers the gating function. Since the glitch happened to be in the DARM_ERR (IFO) both PCAL_LINE1/DARM_ERR and TST/DARM_ERR ratios get uncertainties higher than 0.02 as in this case. The KAPPA_TST_GATE_UNC_INPUT which is finally used, according to model, supposed to be maximum of the two uncertainties but in this case it is the minimum of the two (KAPPA_TST_GATE_UNC_INPUT is on top of SUS_LINE3_UNCERTAINTY). Since it is still larger than 0.02, gating is triggered. However the gated kappa_tst values don't make any sense. It supposed to be avoid the excursion in the raw kappa_tst but it seems to change the level values of kappa_tst. This function need to checked (this is a user defined c function block). The signals after that make sense.
Similar plot for LLO which also show similar problem with gating function block.
Turns out the switch blocks used were defaulting to a logic comparison of >= 0 instead of > 0. Which means the first input was always being passed. I'll update this in the common CAL_CS_MASTER.mdl file and we should be able to push that next Tuesday. The gating issue is a bit trickier. As far as I can tell the gate is doing what its supposed to do. At the time the uncertainty rises above threshold, it freezes then and there as shown in Shivaraj's plots. The problem is, since the uncertainty calculation is basically on a cadence of 10 seconds, there's a 10 second gap between the demodulated low pass starting to respond to a large excursion and the I think this means we need to put 10 seconds (or maybe a touch longer) buffer between the kappa value input to the gate, so that the coherence corresponds represents the data coming in instead of data that came in during the last 10 seconds. A 163840 or so sample ring buffer is doable, but I'll have to modify a C code user block to do so.
Log for remainder of shift:
22:23 (03:23) Beckhoff reboot in CS
22:29 (03:29) Beginning to relock
22:55 (03:55) Christina to MX, MY
23:00 (04:00) End of shift