Ops Day Shift: 16:00-23:59UTC (08:00-16:00PT)
H1 Status: unlocked and issues locking X arm in green
Shift Summary:
Other:
Currently:
We found a nasty little problem with the SDF for beckhoff. The SDF does not seem to pick up changes in the enumerated types (for example the on/off switches). It appears to hold the startup value. I am starting to look at this.
My investigation into the alignment shifts of the H1 IMs (IM1, IM2, IM3) led me to investigate the IMs at LLO in L1.
I have identified three events where the L1 IMs changed alignment for the same alignment drive.
Chart-1 shows L1 IO IM1-3 optics on Sept. 13th, Nov. 14th, and Nov. 25th, when earthquakes tripped the L1 HAM2 ISI.
The chart also shows the amount of shaking of the L1 IM optics and the L1 HAM2 ISI.
This data shows that the alignment of the IMs in L1 are vulnerable to alignment shifts after a HAM2 ISI trip.
Corresponding alogs regarding LHO H1 IO IM1-3 alignment shifts are H1alog22913, H1alog22956, H1alog23415, and H1algo25075.
Attached:
Test for the ISC whitening and anit-whitening filters to be set equivalently. Daniel and Keita asked me to do this last week and I finally got around to it today.
It has to check 156 pairs of channels, so with that many channel acces calls it slows down the exc time a bit. When I get time again I will try to make it faster.
Code sample:
omc_tups = [('OMC-DCPD_A_WHITEN_SET_{}'.format(i),'OMC-DCPD_B_WHITEN_SET_{}'.format(i)) for i in range(1,4)]
all_dem_tups = [('{}_WHITEN_FILTER_{}'.format(pre,i), '{}_AWHITEN_SET{}'.format(pre,i)) for pre in prefix for i in range(1,4)] + omc_tups
for x in all_dem_tups:
if ezca[x[0]] != ezca[x[1]]:
yield '{} and Anti-whiten not equal'.format(x[0])
Where prefix is a list of all the filter banks that share common whiten/Awhitening, but the OMC is special, apparently.
[Ellie, Kiwamu, Aidan, Cao]
From alog25766, we reported that the maximum intensity pixel value of the beamspot on HWS-X was lower than that observed on HWS-Y (~70 compared to 120) and the spherical power measured by the the HWS-X was very noisy. We suspected that this was caused by low power output of the HWS-X SLED. However, that power output for the SLEDs have not been calibrated so we couldn't rely on values of channel H1:TCS-ITMX_HWS_SLEDPOWERMON and H1:TCS-ITMY_HWS_SLEDPOWERMON.
We measured the power output of the 2 SLED's today:
SLED | Wavelength |
Power |
HWS-X | 790 nm | 175 µW |
HWS-Y | 840 nm | 2.03 mW |
This difference in powers measured between HWS-X SLED and HWS-Y SLED is as expected. The HWS-X SLED diode will need to be replaced with a new one. We are planning to do this tomorrow morning. The SLED power channels will need to be calibrated.
Friday 26th - Sunday 28th No restarts reported
model restarts logged for Thu 25/Feb/2016
2016_02_25 12:41 h1iopsusauxh2
2016_02_25 12:41 h1susauxh2
Following h1boot NFS problems, rebooted one system to verify front ends could boot.
Tuesday 23rd - Wednesday 24th No restarts reported
model restarts logged for Mon 22/Feb/2016
2016_02_22 13:23 h1ascimc
2016_02_22 13:23 h1lsc
2016_02_22 13:28 h1broadcast0
2016_02_22 13:28 h1dc0
2016_02_22 13:28 h1nds0
2016_02_22 13:28 h1nds1
2016_02_22 13:28 h1tw1
2016_02_22 13:29 h1nds0
Early maintenance day. ASC and LSC code change and associated DAQ restart.
Thursday 18th - Sunday 21st No restarts reported
Matt, Sheila, Cheryl
This morning the XARM wouldn't lock in IR, this is a pesky problem that has come and gone. It seems like the problem was that both the bounce and roll modes of MC2 were rung up. We added resonant gains in MC2 MS ISCINF that will be used durring arm IR locking only (there are already notches in M2 that are always on). We also turned up the gain a bit to put us near the high side of the gain bubble when well aligned.
IM2 position is now oscillating by 5urad in pitch and yaw after satellite module fix on Feb. 23.
Three plots attached:
That Sat amp doesn't qualify as fixed at this point. The modification is not currently installed. See Richard McCarthy for details.
3/1/2016 The modification has been added.
WP 5747 I have started copying raw minute trend files from h1tw1:/trend to h1fw1:/frames. This is a period maintenance task that is performed every 5 to 6 months. I also reconfigured h1nds1 to read the trend files for the last 5 months which were moved temporarily to allow copying. The h1nds1 has been restarted to allow access to the complete set of trend files.
I've finished adding yellow boxes around the DC sliders on the IFO_ALIGN SCREEN for all the suspensions to indicate when values are ramping as per Sheila's request. I tested some of it successfully. Please take note of any weirdness and report it to me.
Thanks
Listed below are the past 10 day trends. For further in-depth analysis, please refer to Jason O., Pete K. or Rick S.
Attached are 7 day pitch, yaw, and sum trends for all active H1 optical levers.
Adding AOS and SEI tags.
All look good here, no changes from last week's trends.
H1 status:
- CP3 short is gone, final configuration ongoing
- no crane work in the LVEA scheduled for Tuesday
- beam tube enclosure sealing continues
- staging building alarm is coming in on the fire panel
---feel free to acknowledge, not a fire concern
Tomorrow's Maintenance:
- Richard - ITMs and BS satellite amp upgrades, possibly more
- Richard - CPS timing RF cables at end stations
- JeffB - monthly envi. checks
- Kyle - VEA laser safe for soldering,
- JeffK - commit models to SVN
- Hugh - HAM4 and HAM5 model corrections
- TJ - bounce and roll guardian roll state
- TJ - psl guardian
Still chasing the SRC gouy phase. On Saturday I was looking for the beam reflected back from the SRM through the SRC, transmitted through the ITM towards the ETM. I was trying to see the beams on the ETM baffles. The bottom line is that after trying to move multiple optics including BS, ITMY, SR3, SRM, I was not able to see any beam on the ETM baffle PDs except for the propt reflection from the BS towards ETMY (which doesnt travel through the SRC).
Method:
ITMx, ETMx, ETMy, PRM were misaligned for this measurement. To split the beams travelling through the SRC an optic in the SRC must be misaligned. I could look at the beams on gige cameras ASair and cam17 and the analogue camera looking at Ham 5. I saw no beams on the ETMy gige camera, is this working currently?The baffle Pds are 35cm or 3 beam diameters apart, so was aiming the split the prompt reflection from the BS to ETMy from the beam that travels once through the SRC by at least 1.5 beam diameters.
First tried moving single optic, eg BS or SR3, by applying excitaions of different frequencies in pitch and yaw, and then looking for a signal on the baffle PDs. I saw no signal that was not the prompt reflection, which was present whther or not the SRM was aligned. ThenI tried moving BS to center the prompt reflected beam onto a baffle PD, moving it slightly off to the side and then moving the and moving SRC optics with an excitaion in pitch and yaw, one at a time.
Then tried moving SRC/ITMY optics, with no BS misalignment. I saw no beams on the baffle PDs when moving the SRC optics, anr only the prompt reflection when moving the ITM and the BS.
I could see a beam inside the SRC on the SR3 baffle, which I think was the second trip around the SRC. So I think the first trip around the SRC was making it through the ITM and it wasn't clipped, but I couldn't get it on the ETMy baffle.
As a side note:
Funnily enough, while doing this misalignment business I noticed three beams on the gige camera 'cam_17' on ISCT_6. I think these is the straight shot, the one round-trip and two-round trip beams through the SRC. The angle between these beams also tells us the SRC gouy phase. Stefan and I tried to look at these beams last year on the AS_air camera with no success, and we concluded that we couldn't split these beams without clipping on an optic. But the cam_17 is a new camera in a different part of the AS_air beam waist. And it looks like we are seeing all three beams. Interesting.
One explanation for the lack of a visible beam in the end stations from the reflection of the SRC could be a bad mode matching of the SRC to the arm cavities—which could result in the beam blowing up after 4km of travel. A bad mode matching would also reduced the RSE cavity pole; something we observed.
Vinny, Brynley Over the past 2 weeks, we used a temporary magnetometer in the CS CER and the EY CER and computer racks. We placed the magnetometer in a range of locations, and created spectra from the magnetometer at each. It had been mentioned that the timing slave card in various chassis might be the cause - as an LED with a 2 second period is fitted on each. To that end, after a first study, our follow up was aimed at those chassis with timing slave cards. The first spectral plot attached shows spectra from the EY CER. All of the traces are near the noise floor because we were not using the typical magnetometer filter box, which applies a gain of 100 above 1 Hz. Despite this the combs are easily and increasingly visible as the magnetometer gets closer to the timing racks. Each trace is made with 170 averages of .1875 Hz resolution FFTs. The second plot shows spectra from the corner station CER. This time we used an SR560 pre-amplifier to get our gain of 100 above 1 Hz. Once again the comb was stronger as the magnetometer got closer to the timing racks. Once again each trace is made from 170 averages of .1875 Hz resolution FFTs. The third figure shows the spectra taken from the CER at EY. We used the SR560 to apply gain of 100 above 1Hz. For this plot, the magnetometer was placed near to a number of instruments, some with timing slave cards, and some without. EY's TCS-1 rack RF oscillator source. The 0.5Hz combs are very strongly visible throughout the signal. The trace is made from 15 minutes of data, with 0.03125Hz resolution The fourth plot is a short segment of the magnetometer's time series associated with the spectrum in the third plot. The magnetometer was placed near to the Timing Slave card on EY's TSC-TRF Oscillator source. The time series shows that on second boundaries, the magnetometer sees a large field, quickly dieing away. No post-processing or filtering has been performed on this time series. There has been no "Observing" data during these investigations, but the detector had "DC Lock" from Feb. 20 04:00 - Feb 20 12:00 . The last image is a oherence plot (between H1:LSC-DARM_IN1_DQ and H1:PEM-CS_ADC_4_28_OUT_DQ) made from those 8 hours of data. 64 second FFTs, 899 averages. The comb is clearly visible, confirming that this is the comb appearing in DARM.
NOTE: To clarify, at EY, we temporarily usurped on the PEM TILT X channel for our magnetometer. The plots which show the TILT are in fact our temporary magnetometer. BP 02/29/2016
Robert, Sheila, Evan, Gabriele
I tried to look at one of Robert's injections from yesterday, and we noticed a dangerous bug, which had previously been reported by Annamaria and Robert 20410. This is also the subject of https://bugzilla.ligo-wa.caltech.edu/bugzilla3/show_bug.cgi?id=804
When we changed the Stop frequency on the template, without changing anything else, the noise in DARM changes.
This means we can't look at ISI, ASC, PEM, or SUS channels at the same time as DARM channels and get a proper representation of the DARM noise, which is what we need to be doing right now to improve our low frequency noise. Can we trust coherence measurements between channels that have different sampling rates?
This is not the same problem as reported by Robert and Keita alog 22094
people have looked at the DTT manual and speculate that this could be because of the aggressive whitening on this channel, and the fact that DTT downsmaples before taking the spectrum.
If there is no near term prospect for fixing the problem in DTT, then we would want to have less aggressive whitening for CAL_DELTA_L_EXTERNAL
I spent a little time looking into this and added some details to the bug report. As you said, it seems to be an issue of high frequency noise leaking through the downsampling filter in DTT.
Until this gets fixed, any reason you can't use DARM_IN1 instead of DELTAL_EXTERNAL as your DARM channel? It's better whitened, so it doesn't suffer from this problem.
The dynamic range issue in the whitened channel can be improved by switching to five zeros at 0.3 Hz and five poles at 30 Hz.
The current whitening settings (five zeros at 1 Hz, five poles at 100 Hz) produce more than 70 dB of variation from 10 Hz to 8 kHz, and 130 dB of variation from 0.05 Hz to 10 Hz.
The new whitening settings can give less than 30 dB of variation from 10 Hz to 8 kHz, and 90 dB of variation from 0.05 Hz to 10 Hz.
We could also use 6 zeros at 0.3 Hz and 6 poles at 30 Hz, which would give 30 dB of variation from 10 Hz to 8 kHz, and 66 dB of variation from 0.05 Hz to 10 Hz.
The 6x p/z solution was implemented: LHO#25778