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
Today Keita and I spent some time thinking about OMC length noise, there will be an update coming soon with more information and a noise projection.
We spent some time looking at some nonlinear behavoir noise in the drive to PZT1. Our dither frequency is 4100 Hz, and looking at the low voltage PZT monitor we can see a small 8 Hz and a larger 16 Hz comb. There is also other non stationary noise in the monitor, and a broad peak at 12.7 kHz. We have moved the dither line frequency to 4100.21 Hz, so if this was the cause of the 16 Hz comb in DARM we would now expect it to be more like a 16.84 Hz comb. Evan Goetz tells us that we need 15 minutes or more of data in low noise to evaluate if this has changed any combs in DARM.
We have just reached nominal low noise at 3:14:34 UTC Feb 25th, although the low frequency noise (below 50 Hz) is worse than normal. I've temporarily changed the dither frequency in the OMC guardian, so if there is a longer lock later tonight it should also have this changed dither frequency. (If anyone wants to double check what the dither frequency is, the channel is H1:OMC-LSC_OSC_FREQ
To quote Bill Murray in Groundhog Day, "Anything different is good." (at least in this context) The 16-Hz comb does indeed appear to have changed into a 16.84-Hz comb. A DARM spectrum from two hours (400-sec coherence time) last night in the 150-250 Hz band is attached, along with one from January on a day when the 16-Hz comb was strong. New lines are seen in this band at 151.56 Hz 168.40 Hz 185.24 Hz 202.08 Hz 218.92 Hz 235.76 Hz Some 1-Hz zooms are shown for a couple of the new lines. So...can we fix this problem?
Keita, Sheila
So that we can keep the OMC dither small while driving a reasonable level of counts out of the DAC, we added a voltage divider (somewhat creatively built) to the D-sub from the DAC to the driver chassis. This is a 11k/110 Ohm divider on pins 1 +6. We have increased the dither amplitude from 6 cnts to 600 cnts, so the round off errors will now be 100 times smaller compared to our signal.
The attached screenshots show the PZT1 AC monitor before and after this change. The lines below 1 kHz are always there, (even when there is 0 coming out of the DAC) and are not present on the analog signal coming into the driver chassis for the monitor.
We have reverted the frequency to 4100 Hz. If we get a long enough low noise lock tonight we can hope that the 16 Hz comb will be better. If things look good we should upgrade our voltage divider.
Thing is, our dither line used to be 12 counts pk-pk, so the rounding error was actually significant (signal/error ratio is something like 10 in RMS), and the error showed up as lots of lines because we're sending in only one sinusoidal signal. These lines actually drive the PZT length.
Making the dither bigger, the round off error RMS doesn't change much so RIN will become smaller.
We inserted two sets of 11k-110 Ohm resistive divider, one each for positive and negative input of the low voltage pzt driver input because it was easy. This is a temporary non-solution. A permanent solution is TBD.
The first attachment shows the spectrum of the DAC IOP channel for the dither, i.e. the very last stage of the digital, before we increased the amplitude. RMS of the forest of lines is about a factor of 10 below the RMS of the dither.
The second plot is after increasing the amplitude by a factor of 100, the rounding error RMS is still at the same level though you cannot tell from the plot, the dither to error RMS ratio should be more like 1000 now.
Three large lines in the second plot are not round off errors but imaging peaks that were previously buried in the round off errors: 12283.8kHz=16384-4100.2Hz, 20484.2Hz=16384+4100.2Hz, and 28667.8=32768-4100.2Hz.
Actually, the dither line is still at 4100.21 Hz for tonight, (I had forgotten that I put this into the guardian). We will revert it tomorow.
Splendid -- no 16-Hz or 16.84-Hz comb seen in a 2-hour stretch from last night! See attached spectrum 150-250 Hz spectrum for comparison with above plots, along with 0-1000 Hz spectra from last night and from the night before, with the 16.84-comb present. Many thanks from the CW group as we look ahead to O2.
Sheila pointed out that the noise floor for the 2nd spectrum is considerably higher than for the 1st and could be hiding residual lines due to the dither. So I tried shifting the 2-hour time window a half hour earlier, to avoid the hellacious glitch seen in the inspiral range (see 1st figure) near the end of the original Feb 26 interval. The 2nd figure shows the resulting spectrum with a noise floor closer to that on Feb 25. The 16.84-Hz comb still does not appear. So I think it's safe to say that the 100 times multiplication / divide trick did indeed suppress the 16.84 Hz (originally 16 Hz) comb a great deal, but of course, we will need long coherence times and long integrations to see if what's left causes residual trouble for CW searches.
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
