09:56:32 UTC SUS ETMY saturated. As DARM spectrum came back down, a large amplitude series of peaks has appeared up to ~ 1 kHz.
TITLE: 01/09 [OWL Shift]: 08:00-16:00 UTC (00:00-08:00 PDT), all times posted in UTC STATE Of H1: Observing @ ~ 78 MPc. OUTGOING OPERATOR: Cheryl QUICK SUMMARY: From the cameras: The lights are off in the LVEA, PSL enclosure and end Y. I can not tell if the lights are on or off at mid X, mid Y or end X. Winds are less than 10 mph. From pinging: CDS WAP is off at the LVEA, end X and end Y. CDS WAP is on at mid X and mid Y. Screenshots of the seismic bands and ISI blends are attached.
Ops Eve Summary: 00-08:00UTC, 16:00-23:59PT
State of H1: Observe
Fellow: Rick
Incoming Operator: Patrick
Shift Details:
Quiet and uneventful shift (as far as we can tell). Cheryl kept the ifo. locked the whole time at close to 80 Mpc. The range has trended down a few Mpc over the past seven hours or so.
We had a large tour group in the control room at around 7 pm.
J. Kissel, R. Savage, E. Goetz, D. Tuyenbayev We've finish the afternoon's worth of full IFO calibration measurements, including broad-band white noise excitation with PCAL into DARM (like LLO aLOG 22191) and true DARM / CARM excitations at given frequencies (like LLO aLOG 23184). We'll analyzed the data in the future, but the times for the injections are as follows: (All times are 2016-01-09 UTC day) 36.7, 331.9, and 1083.7 [Hz] excitations of CARM 02:00:30 to 02:07:00 UTC 36.7, 331.9, and 1083.7 [Hz] excitations of DARM 02:10:00 to 02:17:00 UTC Broad-Band excitation from PCALY 18:19:00 UTC to 18:34:00 UTC Although we plan to analyze the data offline looking at much longer integration times, but .xml templates live here: /ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/PostO1/H1/Measurements/PCAL/ A 2016-01-08_H1DARM_PCALY_BBEXC.xml A 2016-01-08_H1PCAL_TrueDARMCARM_Drive.xml A 2016-01-08_H1PCAL_TrueCARM_Drive.xml A 2016-01-08_H1PCAL_TrueDARM_Drive.xml In addition, we also grabbed 5 minutes of data where we drive the 331.9 [Hz] line in both PCALX and Y, again in CARM and DARM, but *much* harder than normal, such that we can calculate the PCAL's relative calibration with excellent SNR and precision. We've also turned on an X-end PCAL calibration line at 4001.3 @ 40000 [cts], which we intend to leave in place overnight (i.e. we'll accept in the SDF sysetm, and run it over night). This was turned on at roughly 04:02:00 UTC, attached is the screen shot. 331.9 excitation of CARM 03:31:00 UTC to 03:36:00 UTC 331.9 excitation of DARM 03:38:00 UTC to 03:43:00 UTC
Attached is an ASD plot of the DeltaL_external and Xend Pcal Tx PD signals (both calibrated in meters of displacement) showing the temporary injection at 4001.3 Hz.
Note that the frequency isn't quite right in this DTT plot, apparently a DTT issue - the center frequency of the peak changes slightly as a function of the integration time, but not centered around 4001.3 Hz.
The other day while Sheila and I were trying to fix the dying-POP-power situation, we opened the beam diverters to see if we could tell something about the alignment from the image of the REFL beam. However, since we usually run with the beam diverters closed, neither of us could remember the precise shape and relative brightneses of the REFL beam in full power. So, since data is currently being taken with the beam diverters open in NLN (non-observing), Cheryl and I took a photo!
Attached is a photo of the REFL beam on the upper of the 2 analog tvs in the front of the control room. Currently, POP_A_LF_OUTPUT is about 16,200 counts, which is pretty normal, and corresponds to a recycling gain of a little more than 41.
https://wiki.ligo.org/viewauth/DetChar/DataQuality/DQShiftLHO20160104
TITLE: 1/8 DAY Shift: 16:00-00:00UTC (08:00-04:00PDT), all times posted in UTC
STATE of H1: On the way to NLN
Incoming Operator: Cheryl
Support: Jenne, Evan, Kissel
Quick Summary:
Calibration work continues. In the afternoon spent some time locking H1 & this was not trivial due to:
Shift Activities:
Remember To Also LOAD Script
For the ISC_LOCK guardian, Jenne hit LOAD button this afternoon to allow Guardian to take H1 to 23W.
Last night for Sheila/Cheryl H1 troubleshooting work, the script was set to 10W, and Cheryl changed it back to 23W & saved it. But H1 was in Observing, so she was not able to hit the LOAD button (is that allowable in Observing?). Anyway, this afternoon Evan noticed H1's power was only taken to 10W. After H1 dropped lock, Jenne hit the LOAD button.
If H1 is in a safe state, one should remember to also hit the LOAD button after making changes to scripts....or flag-the-alog/let-next-operator-know to LOAD during next opportunity.
PRMI Transition Didn't Work
During locking this afternoon, DRMI took more than 15min, so I selected PRMI. PRMI locked and alignment was optimized. Requested DRMI LOCK, and H1 switched immediately from PRMI to DRMI, but unfortunately, the Guardian was stuck here. Perhaps next time we can try re-requesting DRMI LOCK?
This afternoon have noticed the Guardian screens going WHITE & have also had medm message windows saying: "virtual disconnect" for h1guardian0. Jim Batch checked this and mentioned that h1guardian0 has a scary amount of Network Connections (or something along those lines). Attached is a snapshot when I lost guardian.
An additional symptom I'm seeing is with the actual work station (logged in as ops--> ops@operator0). The desktop has frozen up a few times. I have rebooted this computer multiple times. Will send an email to cdsadmin.
This afternoon, there was a window of opportunity to take ETMX and ETMY charge measurements. Results are posted below. Kissel is suggesting that I add another plot, but since it will take a while to work through I'm deferring to Monday, sad as he now is. Charge is still accumulating and we need to think about flipping the bias soonish.
This AI chassis was removed as mentioned in the following alog entry https://alog.ligo-wa.caltech.edu/aLOG/index.php?callRep=21081 In seeking to find what was wrong with the chassis, I powered it up. The following output channels were glitchy when their respective inputs were terminated: Channels: 1, 3, 6, 8, 9, 10, 11, 14 and 16 Don't know why yet but the AA/AI boards (D070081-v6, S1103146, S1200704) are a little warmer to the touch than usual (I think). Channels [1-8] are on S1103146, channels [9-16] are on S1200704.
EvanG, Travis, Darkhan,
Today we repeated Pcal end-station measurements at EX, the procedure is described in T1500063. Rough readings from dataviewer and GPS times are given in the attached notes.
The outer beam still show a significan drop in power between Transmitter and Receiver modules, earlier we thought that the beam was not well centered at the input port of the RxPD integrating sphere, but by looking at an outer beam spot with IR viewing card it does not look to be the case (see attached picture).
Earlier this week we took a similar set of measurements, but we suspected that WS/TX when WS is inside of received module were not taken properly and today's measurements were taken as a double-check (LHO alog 24726).
We will post a full report and some conclusions soon.
A generated report (comparison with previous measurements) was uploaded to DCC T1500129-v4.
This report gives us more confidence that our measurements taken on 2016-01-05 (LHO alog 24726) were not made properly, because
on 2016-01-05 the value of RX/WS (not optical efficiency corrected one) changed by ~ 2 %, but
on 2016-01-08 this ratio was back to it's value measured earlier in O1.
The data point for 2016-01-15 will need to be removed from future end-station measurement reports.
During Pcal end-station TxPD and RxPD measurements the ETM must be aligned.
This conlog is made to confirm that ETMX was aligned during measurement process.
We've continued measuring the beam spot positions once a week as part of Tuesday maintenence.
The 2 pdfs below are different views of the same data set. The first set of plots is the data on x-y grids, so you can really see how little our spots are moving. The second set of plots is the data as a function of time. Some of the pitch values are changing more now than they were back in October, but the maximal excursions are still only about 2mm away from the means.
Here's the same data, but with more features in the presentation.
The color indicates the time between lock acquisition and the measurement. Darkest blue is 0 minutes, and brightest pink is 30+ minutes, with a gradient in between.
The marker shape now (per JimW's request) indicates the ISI blend state, as a check to see if changing the blends changes the alignment. Circles indicate both x and y axes of the ISI are on the Quite_90 blends, diamonds indicate both axes on the 45mHz blends, and square markers indicate that the beamline axis is on the 45mHz and the orthogonal axis is on the 90mHz blend. I conclude that the ISI state has no noticeable effect on the beam spots.
RickS, Darkhan,
Yesterday, Jan 5, 2016, we took Pcal end-station calibration measurements at EX using WS1 calibration standard. The measurement procedure is described in T1500063.
Rough numbers from dataviewer and GPS times were noted in the attached scan (blank form is taken from T1500062).
A generated report (comparison with previous measurements) was uploaded to DCC T1500129-v3.
At first when we started the measurements we found out that laser power in PcalX is modulated through Pcal hardware injection channels H1:CAL-PINJX_*, we had to restart the measurements after tuning off these excitations.
At first we used CAL_INJ_CONTROL medm screen to turn off injections.
When we found out that some injections are still going into PCALX, we looked into H1:CAL-PINJX_* filters using auto-generated medm screens in
/opt/rtcds/lho/h1/medm/h1calex/H1CALEX_PINJX_*.adl
We switched off outputs from these filters before taking our measurements and put them back on afterwards.
Jeff pointed out that going to /opt/rtcds/lho/h1/medm/h1calex/H1CALEX_PINJX_*.adl is not necessary, there's a MEDM screen under Sitemap -> CAL -> PINJX that gives an access to Pcal hardware injection switches.
Nutsinee had a tough time on OWL shift with H1 behaving badly until approx. 15:10 UTC, when it mysteriously improved. But the bad behavior returned around 17:00 UTC for about 30 minutes and I spent some time investigating its cause during this interval. Microseism was not too bad and wind was calm. There was no indication of excess noise on H1:LSC-MOD_RF45_AM_CTRL_OUT_DQ or coherence of that channel with DARM. Looking at a spectrogram of H1:CAL-DELTAL_EXTERNAL_DQ one can see broadband bursts across the bucket turning on and off suddenly (1-s resolution), with durations verying from a few seconds to about 30-40 seconds. Sometimes these were accompanied by loud bursts in the 10-20 Hz region, other times not. I looked for burstiness in other chnnels that was correlated with this. There was nothing well correlated in seismometers or microphones (either on the floor or in e-bays) or OPLEVs. There were strong similarities on ASC-MICH_P and _Y, weaker on DHARD_P and Y, nothing on DSOFT_P and _Y, nothing on CSOFT, very weak similarities on CHARD and SRC2 P and Y. I am not familiar enough with the LSC/ASC couplings to know if this is just leakage of the length fluctuations onto ASC channels or if alignment is causing the problem. I looked at IMC_F an _L, MC2 TRANS which showed no indication that the cause came into the IFO on the light from the IMC. I tried looking at PRC ASC signals but they looked crazy in frequency with no time dependence (??). However SUS-PRM_M3_NOISEMON has large burst in the 10-30 Hz region on all OSEMS. HVETO finds these good for veto channels. Travis was not finding anything bumping against its limits. At 19:42:12 we lost lock. This coincides with the arrival of the maximum ground shaking in the 0.03-0.1 Hz from an EQ in Afghanistan, although the 1-3 Hz region showed sharp elevated shaking several minutes earlier. We are having a hard time getting back to locking.
It looks like the RF45 monitor sometimes does not see the RF45 noise. We will consider three times on the 25th. The reference time is 4 UTC, when there was nothing bad in DARM and the RF 45 was quiet. At 7:30, the RF 45 is obviously bad as seen by the monitor channel. At 17:04, there's very similar noise in DARM, but now the RF45 monitor stays at its reference. The first plot is DARM for the three times. The shape and amplitude of the excess noise for the two bad times is very similar. The second plot is the spectra of the RF 45 monitor at these times. It easily sees the problem the first bad time, but at the second bad time (corresponding to a burst of noise in Fred's spectrogram) it stays at the reference. The ASC-MICH channels look to be good witnesses of this noise. I think they're made from RF36, but that should be sensitive to RF45 issues. The third plot is the coherence with h(t) of RF45 and MICH_Y during the reference time. It has a few lines but is otherwise zero. The next plot shows high coherence with both during the first bad time. The last plot is coherence during the second bad time. There's just a tiny bit of coherence with the RF 45 witness. The MICH_Y coherence is basically the same as the other bad time. This is worrisome because the RF 45 monitor is not always a good witness of the noise in DARM (and other channels). But it doesn't seem to be a problem with noise in the witness channel masking the RF 45 junk. Maybe this points to the problem being somewhere that the monitor is not always able to see.
The reason that there's excess noise in PRM_M3_NOISEMON is just because of the control signal from PRCL. The attached spectrum shows that PRCL gets worse during the bad times, and that's just getting fed to PRM_M3. In fact, MICH, PRC, and SRC all have a similar noise shelf up to 30 Hz during the bad time. They all involve some RF 45 signal in their production. The POP_A RF9 and RF45 photodiode signals, in the I and Q quadratures, all have similar shelves except for 9Q (second plot). That's the only one that's not used for control, so I think it's seeing the noise impressed by the MICH/PRC/SRC loops all suppressing the RF 45 noise.
