Sudarshan, Darkhan, We have swapped Pcal line frequencies (EX <--> EY) and plan to keep them this way until the end of the ER7. Before swapping we had Pcal lines at following frequencies: PCALX at 33.1 Hz and 534.7 Hz PCALY at 36.7 Hz and 540.7 Hz For the rest of ER7 we will have lines at: PCALX at 36.7 Hz and 540.7 Hz PCALY at 33.1 Hz and 534.7 Hz SDF_OVERVIEW monitors have been updated accordingly.
00:00 Jim left the interferometer locked for me!
EY dust monitor went off. > 0.3 u has 914.3 counts/ft^3, >0.5 u has 57.1 counts/ft^3
2:42 Lock loss
3:00 AS 90 too low. Adjusted BS yaw did the job.
3:11 Lock loss at BOUNCE_VIOLIN_MODE_DAMPING. Redo the initial alignment.
3:20 LSC-TR_X Not flashing. Realigned SR2, SR3, and PR2 pitch and yaw.
04:30 Locking at LSC_FF. Intent bit switched to Undisturbed. Guardian worked fine at LOWNOISE_ESD_ETMY step (I was told that it might not work properly). I think it worked at BOUNCE_VIOLIN_MODE_DAMPING as well (after running the code by hand I accidentally let the Guardian run through this state. It didn't lose lock).
6:06 Intent bit switched to Commissioning. Get ready for the hardware injection (scheduled to start at 1117890580 GPS time)
6:09 Injection started
6:13 Injection finished. Intent bit switched to Undisturbed.
6:17 Intent bit switched to Commissioning. Another injection scheduled to start at 1117891250 GPS time. Same injection with gain increased.
6:24 Injection finished. Intent bit switched to Undisturbed.
8:00 Handling off the ifo to Jeff.
ER7 Data Taking started 2015 June 3 at 14:00:00 pdt, 21:00:00 utc, 1117400416 gps.
As of this morning, 2015 June 9, we have accumulated approximately 33 hours of "analysis-ready" coincident data between LHO and LLO. H1 has collected approximately 77 hours of analysis-ready data. L1 has collected approximately 37 hours of analysis-ready data. We have approximately 5 days left in the run plan for ER7.
At the beginning of ER7 Data Taking, H1 was configured and calibrated for operation at ~17 W of input power. Over the weekend its input power was raised to 24 W. This resulted in a few percent error in the calibration and operating configuration. We have restored the input power for H1 back to 17 W and will operate it in this configuration for the remainder of ER7. This is to deliver data to the analysis groups from a known characterization of the detector.
Where we are with regard the JRPC ER7 page (https://wiki.ligo.org/LSC/JRPComm/EngRun7):
Requirements
Detectors
Stable and reliable locking of H1 and L1 in configurations that could plausibly serve in an observing run
Best effort to have similar sensitivities, but no requirement stated
State reporting by Guardian and ODC
Calibrated h(t) channel (see T1300950 for O1 requirements)
Expect L1 calibration accuracy of 20% amplitude & 10-20deg phase from 10 Hz to 2kHz. Aiming for 20% amplitude and 20 deg phase from 2kHz to 5 kHz.
Expect H1 calibration accuracy within a factor of 2 in amplitude; no phase requirement. - delivered 2015 June 2
Sufficient automation to be controllable by operators - achieved, guardian is working well
Hardware injections - hardware and software installed, injections have been carried out and confirmed by analysis groups
Blind Injections Implementation and Testing
approximately 7 days of data taking - in progress, the most stringent is the CBC coincidence requirement of 48 hours, of which we have 33 hours to date
Requirements checklist for ending the run:
CBC:
Would like >2 days coincident science data
Lock periods >4 hours benficial for CBC detchar investigations
(Request) Test H1 and L1 coherent HW injections
CW:
CW hardware injections for at least one interferometer
More than 75 hours of L1 DC-readout data and more than 50 hours of H1 DC-readout data
Stochastic:
Carry out and recover a stochastic injection.
Burst:
Would like >2 days coincident science data
Test EM follow-up infrastructure (EM Processor, PE codes, ...) with coherent HW injection in H1 and L1.
Detailed progress in acheiving these goals is discussed every day at 1:00 pm pdt at the JRPC ER7 Run Status meeting on teamspeak JRPC channel, during the period of the run.
09:55PDT h1oaf - all filter coefficients loaded
10:14PDT cdsegw0 - epics gateway between H1FE and H1SLOW VLANs restarted to permit h1guardian0 connection to h1ecatx1 (which was restarted)
10:25PDT h1sush2a - restart all models to perform a DAC-AUTOCAL
10:30PDT h1sush2b - restart all models to perform a DAC-AUTOCAL
10:34PDT h1sush34 - restart all models to perform a DAC-AUTOCAL
10:43PDT h1broadcast0 - reboot to clear potential network error
11:50PDT h1susb123 - restart all models to perform a DAC-AUTOCAL
Other than h1broadcast0, no DAQ restart today.
Diffracted power was up to ~9.3%, brought it back down to 6.7% with a refsignal of -2.06V
809 - Richard to both ends
809 - Jeff B to LVEA then to ends setting up dust mons
811 - Christina fork lifting to OSB receiving and opening door
814 - Rick to manifolds on both arms
820 - Kyle to EY
823 - Jodi to LVEA to put signs up, then to MY
826 - Christina/Karen to EY to clean
827 - Beam tube cleaning start
832 - Robert to EY to move coils
832 - Patrick to restart EX Beckhoff
835 - Jodi and Rick out of LVEA
838 - Andres to LVEA to move parts around
845 EX Beckhoff back up
853 - Fil/Peter K to LVEA
900 - Kingsoft on site for RO work
905 - Praxair truck on site
907 - Fil/Peter out of LVEA
909 - Jodi leaving MY
917 - Andres out
921 - Gerardo to LVEA for wrenches
923 - Mitch to ends for serial number hunt
927 - Karen/Christina leaving EY for EX
928 - Gerardo out and to EY
947 - Robert out of LVEA
1000 - Praxair truck #2 on site
1006 - Daniel to EY to look at TCS setup
1010 - Richard back fomr Ends
1020 - Robert to LVEA
1020 - Karen/ Christina leaving EX
1020 - Fil to EY
1027 - Ed to CER
1036 - Ed out
1040 - RIchard to EY
1049 - Rick LVEA fit check
1052 - Daniel back, for a moment
1057 - Richard to LVEA looking at Cosmic Ray Detector
1105 - Christina/Karen to LVEA
1107 - Patrick restarting PEMEY
1128 - Mitch back
1128 - Daniel back
1133 - Jeff B back
Log for second half of the day: 11:48 Beam Tube cleaning crew breaking for lunch 12:00 Start both dust monitors at End-Y 12:00 Kyle – Back from End-X – Note: Fan and power supply running while turbo pump spins down 12:27 Bubba & Gerardo – Back from End-Y 13:35 Beam tube cleaning restarted HNWX2 14:48 Kyle – Going to End-X to shut off turbo pump fans and power supply 15:16 Kyle – Back from End-X 15:30 Beam cleaning team done for the day
The ring heater for ETMY was disconnected from the chassis. The power of the chassis was already off, since we were not using it. A special cable which shorts all ring heater segments together was connected to the output of an SR560. The SR560 ground was connected to the ESD driver ground, while its input is driven by the PEM DAC (H1:PEM-EY_GDS_1_EXC). A drive of 12000 counts corresponds to about 1.8Vpp.
Got disconnected as part of dust monitor work at end Y. Burtrestored.
J. Kissel In the H1:CAL-INJ_HARDWARE and H1:CAL-INJ_BLIND filter banks, I've turned ON the updated inverse actuation filter for ER7 (which lives in FM2 of both banks), turned OFF the mini-run filter (which *still* lives in FM1) and accepted the changes in the SDF system. See LHO aLOG 18997 for design details of the new filter.
J. Kissel Over the weekend, Evan, Stefan and Kiwamu has explored running the IFO at 24 [W] request PSL input power (see e.g. LHO aLOG 18923) instead of 17 [W] for which the interferometer had been calibrated (see LHO aLOGs 18769 and 18813). Because we do not yet have automatic optical gain scaling built into the IFO's control system, the calibration will be incorrect for the following science segments: Seg Num GPS Start GPS End Duration [s] UTC Start UTC End 1 1117601338 1117665437 64099 Jun 06 2015 04:48:42 Jun 06 2015 22:37:01 2 1117667359 1117702258 34899 Jun 06 2015 23:09:03 Jun 07 2015 08:50:42 3 1117709888 1117743019 33131 Jun 07 2015 10:57:52 Jun 07 2015 20:10:03 4 1117748054 1117773188 15134 Jun 07 2015 21:33:58 Jun 08 2015 04:32:52 5 1117803358 1117814235 10877 Jun 08 2015 12:55:42 Jun 08 2015 15:56:59 6 1117814313 1117815464 1151 Jun 08 2015 15:58:17 Jun 08 2015 16:17:28 7 1117829201 1117833161 3960 Jun 08 2015 20:06:25 Jun 08 2015 21:12:25 --- Total Time Uptime@23[W] Single IFO Duty Factor During These Segments 64.40 hr 45.27 hr 70.3% Offline optical gain calculations are being made by the GDS calibration pipeline, but they are not being applied directly since this is the first time they've been calculated. However, evidence still suggests that LHO's DARM coupled cavity pole frequency (i.e. the single-pole approximation to the interferometer's response to gravitational waves / displacement noise) is still a moving target, so the calibration error (not uncertainty, but actual error) may not only just be a scale factor, but a frequency-dependent error. We should* have enough information from PCAL and DARM calibration lines to make an estimate of how the frequency dependence is changing over time. *"should" is still "in principle;" we have not yet finished the commissioning of processing PCAL / DARM calibration lines to a point where we can determine at what precision the 6 lines will be able to determine the optical transfer function. This work is on-going.
"Incorrect" sounds too strong to me.
I would say it was incorrect only in the sense that the cavity pole frequency was uncertain which is the case not only for the 24 W configuration but also for the 17 W. Otherwise we believe that the calibration had remained valid both in GDS and CAL-CS at 24 W (though, rememeber CAL-CS has not fully updated to the equivalent of GDS, alog 1880 and hence the descrepancy between them). The OMC has a power-scaling functionality (alog 18470) and therefore, ideally it does not change the optical gain as we change the PSL power. As for the cavity pole frequency, the Pcal lines should be able to tell us how stable it has been.
As reported in alog 18293, the optical gain seemed to have dropped by 4% in this particualr lock according to the Pcal line at 540 Hz. Sudartian is currently analyzing the Pcal trend, but it seems that the optical gain typically changes by 4-5 % in every lock stretch probably due to different OMC error gain (which is computed in every RF->OMC transition) and perhaps different alignment somewhere. We compensated it by increasing OMC-READOUT_ERR_GAIN by 4 % at the beggining of this particular lock and therefore we thought the calibration was good assuming the cavity pole stayed at the same frequency, 355 Hz.
I suspect there is a lingering source of error in the gain of the OMC-DCPD --> DARM_IN1 path. This may be due to the initial gain-matching calculation between DCPD_SUM and RF-DARM, but it could also be due a scaling error as we adjust the overall gain during the power-up step. We initially set the gain at a DARM offset of ~40pm, but as we power up to 23W we reduce the offset to ~15pm. The current gain-scaling calculation that Kiwamu links to does not account for the small static DARM offset that we have observed (it's a fraction of a picometer, see here). I will post a note about this today -- the overall effect should be very small, but may account for the ~4% change that we have observed. (If this is the source of the gain error it will be proportional to DARM offset, which is the same as power level since we change both at the same time.)
Biweekly crash recovery. Burtrestored to 06/08/2015 00:10.
Out of Science mode.
I flipped the intent bit because with Tuesday maintenance comes lots of noise.
Lock broke, we will keep it this way till the maintenance period is over or until we hear otherwise.
Peter Shawhan, Andy Lundgren, Nutsinee Kijbunchoo We did a first -- and successful! -- test of the "detchar" or "safety" hardware injections shortly after 6:00 PDT this morning, at the time recommended by Jeff (work permit 5262). The detchar injections are a sequence of loud sine-gaussians at a range of frequencies, primarily intended to check for couplings from the GW strain channel to auxiliary channels. (See https://dcc.ligo.org/LIGO-G1500713 .) For now, at least, we are using a set of 14 frequencies logarithmically spaced from 30 Hz to 2000 Hz, each injected at 3 different amplitudes to try to get target SNR values, spaced 5 seconds apart. Here is the full list with times relative to the start time of the injection:Matlab> GenerateSGSequence('H1','H1_ASD_at_1117710916.txt'); __time__ __freq__ __SNR__ __AMP__ 0.50 30.0 25.0 2.22e-20 5.50 41.4 25.0 7.54e-21 10.50 57.2 25.0 2.86e-21 15.50 79.1 25.0 1.72e-21 20.50 109.2 25.0 1.52e-21 25.50 150.9 25.0 1.7e-21 30.50 208.4 25.0 1.97e-21 35.50 287.9 25.0 2.92e-21 40.50 397.7 25.0 3.73e-21 45.50 549.3 25.0 5.42e-21 50.50 758.8 25.0 6.95e-21 55.50 1048.2 25.0 1.1e-20 60.50 1447.9 25.0 1.71e-20 65.50 2000.0 25.0 2.68e-20 70.50 30.0 50.0 4.44e-20 75.50 41.4 50.0 1.51e-20 80.50 57.2 50.0 5.71e-21 85.50 79.1 50.0 3.44e-21 90.50 109.2 50.0 3.03e-21 95.50 150.9 50.0 3.41e-21 100.50 208.4 50.0 3.94e-21 105.50 287.9 50.0 5.85e-21 110.50 397.7 50.0 7.47e-21 115.50 549.3 50.0 1.08e-20 120.50 758.8 50.0 1.39e-20 125.50 1048.2 50.0 2.2e-20 130.50 1447.9 50.0 3.41e-20 135.50 2000.0 30.0 3.22e-20 140.50 30.0 100.0 8.88e-20 145.50 41.4 100.0 3.02e-20 150.50 57.2 100.0 1.14e-20 155.50 79.1 100.0 6.87e-21 160.50 109.2 100.0 6.06e-21 165.50 150.9 100.0 6.81e-21 170.50 208.4 100.0 7.87e-21 175.50 287.9 100.0 1.17e-20 180.50 397.7 100.0 1.49e-20 185.50 549.3 100.0 2.17e-20 190.50 758.8 100.0 2.78e-20 195.50 1048.2 100.0 4.41e-20 200.50 1447.9 75.0 5.12e-20 205.50 2000.0 30.0 3.22e-20The file, on h1hwinj, is /data/scirun/O1/HardwareInjection/Details/config/Burst/Waveform/detchar_1117890580_3_H1.txt . With H1 running in good low-noise mode, Nutsinee switched the intent bit to 'commissioning' and we first injected the sequence starting at 1117890580 with an overall scale factor of 0.25 -- so the target SNRs/amplitudes are a factor of 4 smaller than in the table above. Nutsinee didn't see anything obvious appearing in the live spectrum initially, but Andy looked at Omicron output afterward and say that it had picked up at least some of the louder signals. We then injected the sequence again starting at 1117891250, this time with an overall scale factor of 1.0 . Nutsinee saw the signals clearly peak up in the live spectrogram, and Andy's quick check with Omicron showed many signals found with large SNR. The interferometer appeared to handle the injections fine, staying in lock. Afterward (and also in between the two injections), Nutsinee set the intent bit back to 'science'. Note: In the future, we expect detchar safety injections such as these to be marked with the DetChar bit in the CAL-INJ_ODC bitmask, but for the test today we treated it as a burst injection -- it will be marked in ODC (and GDS-CALIB_STATE) as a burst injection, and should produce ODC-INJECTION_BURST segments in the DQ segment database.
I've done a few checks of the injections. The first attachment is the spectrum before the first injections were started compared to the spectrum just after the last one finished. The spectrum is the same before as after, so I don't think anything got rung up. Maybe we can check the violin modes more carefully. There was a fairly big glitch two minutes later (Omega scan) but I don't think it was related. The other four attachments are the injections of the first round of the injection set, done at normal gain. These are meant to have SNR of about 25, but that varies with the spectrum. Most look fine. However, the injections at 1 kHz and above are not correct. They look to be anti-aliased down, or maybe there's a saturation or something wrong with the actuation. We'll check our code to see if there's something wrong with the file we generated.
When Andy presented this on the ER7 call and talked about the higher-frequency injections not appearing correctly, Jeff asked if we were hitting the software limit at +-200 counts. That limit had been set based on some CBC injection studies; we don't really know the level at which unavoidable saturation in the software or hardware chain would set in. Duncan M quickly confirmed that the H1:CAL-INJ_HARDWARE_OUT_DQ channel was hitting +-200 for some of the injections. I took a look too and estimated what SNR value hits that software limit:At 549 Hz, SNR=80 hits 200 counts 759 Hz SNR=33 1048 Hz SNR=10.4 1448 Hz SNR<6.25 (saturated even for the weakest one we injected) 2000 Hz SNR<6.25 (saturated even for the weakest one we injected)So this tells us how much that (currently rather arbitrary) software limit would need to be relaxed to put in larger-SNR injections at those higher frequencies, if it's important to do so.
Using two hours of undisturbed data from last night's 66 Mpc lock, I repeated Den's sum/null stream analysis in order to see if we have a similar 1/f1/2 excess in our residual.
I took the OMC sum/null data (calibrated into milliamps), undid the effect of the DARM OLTF in order to get an estimate for the freerunning OMC current, and then scaled by the DARM optical gain (3.5 mA/pm, with a pole at 355 Hz) to get the equivalent freerunning DARM displacement. The residual is then the quadrature difference between the sum and null ASDs.
The attachment shows the sum, null, and residual ASDs, along with the anticipated coating Brownian noise from GWINC. [Just to be clear: the "sum" trace on this plot corresponds to our usual freerunning DARM estimate, although in this case it comes purely from the error signal rather than a combination of the error and control signals.]
If there is some kind of excess 1/f1/2 noise here, it is not yet large enough to dominate the residual. Right now it looks like the residual is at least a factor of 2.2 higher than the expected coating noise at all frequencies. We already know some of this is intensity noise.
The other thing to note here is that we are evidently not completely dominated by shot noise above 1 kHz.
I repeated this on a lock stretch from 2015-06-07 00:00:00Z to 02:00:00Z, but the result is pretty much the same. The best constraint we can put on coating noise right now from the residual is about a factor of 2.2 higher than the GWINC prediction. I also think the residual is not yet clean enough in this frequency band to make an inference about its spectral shape.
I tried increasing the CARM gain by 3 dB to see if the residual would decrease, but it does not (except maybe round 6 kHz; see the attached dtt pdf). So this broadband excess in the sum may not be frequency noise.
There is an error in the above plots.
Only the DCPD sum should be corrected by the DARM OLTF to get the equivalent freerunning noise. The DCPD null should not be corrected. To refer to noise to DARM displacement, however, all these quantities must be corrected by the DARM cavity pole.
This time I've included the DCPD dark noise (sum of A and B), also not corrected by the loop gain.
A few more corrections and additions:
Stefan, Kiwamu,
In this morning, DARM had many numbers of glitches which were visible in the DARM spectrum as wide band noise. We looked at various channels to see what caused the glitches, but we were not able to identify them.
The lock stretch which had a high glitch rate is the one starting at 2015-06-05 17:17 -sh to 18:00 -ish UTC. I attach an example time series of the glitches shown in OMC-DCPD A and B. We know that some of the loud ones were so large that they saturated the ADCs of the OMC DCPD.
Note that in the same lock stretch, we changed the DARM offset multiple times which changed the amount of the carrier light resonating in OMC. We do not think our activity with the DARM offset caused the high glitch rate.
Here is also a DARM spectrum and time series, as well as the summary page range graph. The glitches occur in the short science segment just before 18h.
We need to do some more thorough follow-up, but I can give some quick feedback that might give some hints. The initial signs seem to suggest that the problem might be due to input pointing glitches or alignment fluctuations in the PRC.
The loudest glitches in that short science segments were coincident with ASC-REFL_A_RF9_I_PIT_OUT_DQ, which looks like it was being used as the error signal for INP1 and PRC2 loops, feeding back onto IM4 and PR2. The corresponding YAW channel was also significant, but not quite as much so. We also saw ASC-REFL_B_RF9_I_PIT_OUT_DQ as somewhat significant, which looks like it was being used in both the INP1, INP2, and PRC2 loops and feeding back on IM4 and PR2.
So, we now start believing that these loud glitches were related to the cleaning activity on the X arm vacuum tube (alog 18992). Here I show glitch wave forms in time series from three glitch events (out of many) that were observed in this past Friday, 5th of June.
Typically the glitches were very fast and I am guessing that the glitch itself happens on a time scale of 10 ms or maybe less. Usually the OMC DC signals or the DARM error follows with a relatively slow oscillation with a period of roughly 100 msec which I believe is an impulse response of the DARM control. All the three events showed a power drop in the carrier light everywhere ( TRX, TRY and POP) indicating that the power recycling gain dropped simultaneously. For some reason POP_A_LF showed slower power drop which I do not understand. Also, in all three events that I looked at, the OMC DCPDs showed small fluctuation roughly 20 ms before the big transient happens.
(This one contains two glitch events apart only by roughly 200 msec)
(all the time series are high-passed with zpk([0], [40], 1) ). You can see a glitchy behavior in REFL WFS (as reported by TJ) as well as TRX QPD (and a little bit in TRY QPD).