FYI: Virgo's range plots can currently be obtained from LDAS (upper right hand plot shows all 3 IFOs)
Greg is looking into why the latest data seems to be a bit behind. We are working with John Z on adding the V1 range plot to the wall display in the control room.
FAMIS 4732
ITMX sum has dropped a decent amount, ITMY has also dropped but not as much.
Yaw: ETMX and ITMX are riding close to their nominal range, BS is approaching as well.
Pitch: ETMX and ITMX are out of nominal range, SR3 is getting close.
From 9:30 to 10:00 UTC, there was a return of the noise from the RF45 system. The RFAM monitor (LSC-MOD_RF45_AM_CTRL) sees a bunch of excess noise, and coherence with DARM. The coherence seems to have a different shape than it did previously (more toward lower frequencies), but this needs to be confirmed. There's a lot of glitchiness during this day, but it seems to have three totally different sources. The end of the day has scattering, early in the day are the susrack glitches, and there's a short period of RF45. Detchar should go back through the past few days and see if any of these started to happen earlier.
Earthquake EQ report Mag 5.7 Pacific-Antarctic Ridge Was it reported by Terramon, USGS, SEISMON? Yes, Yes, Yes Magnitude (according to Terramon, USGS, SEISMON): 5.7, 5.7, 5.7 Location: Pacific-Antarctic Ridge; LAT: 62.8S, LON: 161.1W Starting time of event (ie. when BLRMS started to increase on DMT on the wall): 13:25 UTC Lock status? H1 rode it out without a problem EQ reported by Terramon BEFORE it actually arrived? Unknown
There was a period of substantial glitchiness today (June 16) from 4 to 6:30 UTC. Hveto finds it to be related to the EX susrack magnetometers. The glitches in the susrack seem to come in bursts of a few seconds, with most power below 60 Hz. An example Omega scan is attached. Was there anything plugged in or changed at EX when doing PEM injections or during maintenance? If not, maybe something electronic has broken - we'll keep an eye on it and see when it recurs.
Andy, Josh, TJ, Laura,
When inspecting periods of poor DQ in H1 today we noticed some clear scattering that has multiple arch structures (see fig 1). When we ran scatter frequency predictions, ETMY and ETMY R0 were the two optics whose length motion most closely resembled the fringes (see figs 2,3 and link). If you gave each of them 10, 20, 30 bounces, they would line up perfectly. We observed something just like this in LLO before, see 29114. There, folks on site were able to dramatically reduce it by minimizing the scatter arches from a drive signal while introducing an offset in the reaction mass alignment, as described on slide 12 of Bryan Barr's fellow's project here. Perhaps this procedure could also be helpful for reducing this particular scatter mechanism at LHO.
J. Kissel After Bubba has changed the HVAC error signal at the X end to be only one sensor -- and the sensor that's closest to the chamber and PCAL systems -- it looks like the temperature is more stable. It's to early to tell, but signs are pointing to the systematic errors in PCALX's reported displacement also seem to have reduced in amplitude.
With strong and gusty winds the environmental conditions have not been favorable this morning. There were some glitching issues with the RF45 Mod Depth Stab Contls, which did not help. The range has mostly been in the low to mid 50Mpcs. BRS-Y has been in DAMPING all morning. Sheila switched the SEI_CONFIG state from WINDY to WINDY_NO_BRSY. After switching did not see an improvement in range. There was commissioning work between 15:30 (08:30) and 16:30 (09:30)this morning. The IFO has been in Observing mode after the commissioning work ended.
Sheila, Pep The attached plots show the comparison between H1:GDS-CALIB_STRAIN and the OpLev channel (H1:SUS-ETMY_L3_OPLEV_SUM_OUT_DQ) for different glitch events, found in HVeto in this day: https://ldas-jobs.ligo-wa.caltech.edu/~detchar/summary/day/20170419/detchar/hveto/. We also show a comparison between these channels for times when the OpLev was not glitching. To get these results, we have assumed that the only force on the mirror is the pressure radiation force of the OpLev laser. The equation is: F=2*P/c=m*a, where P is the power of the laser, c is light's velocity, m is the mass of the mirror (taken as 40 kg) and a is acceleration. In order to find the power of the laser, we have to use the relation between the counts detected by the QPD and the power, which is (DCC T1600085): P = Counts * (40 [V] / ((2^16) - 1)) * (1 / Transimpedance [Ohms]) * (1 / Whitening Gain) * (1 / Responsitivity [A/W]) = Counts * 7.6295e-09 for the H1:SUS-ETMY_L3_OPLEV_SUM_OUT_DQ channel. The transimpedance values can be found in DCC T1600085, the whitening gain values in dB can be found here in DCC T1500556-v4. These values have to be converted from dB using 10^(x/20). The responsitivity is 0.4, and can be found here: http://www.hamamatsu.com/us/en/product/alpha/S/4106/S5981/index.html#1328449179787 (the laser is at 635 nm). After calculating the acceleration, we calculated the asd of this time series using gwpy, and after that we divided by the square of the frequency to have the displacement of the mirror. To compare these values to the ones in DARM, we divided by 4000 m to get the strain.
As Keita pointed out, the plots in the previous post were wrong, due to a missing factor of 1/(2*pi)^2 when converting from acceleration to displacement. I attach the same plots with the correct factor, and five new plots that use a window of 1 second around the time of the event instead of the window of 4 seconds that was used before
Do not change RF setpoint slider H1:LSC-MOD_RF45_AM_RFSET.
It's been demonstrated again and again that this doesn't do anything good, you're just making it harder for people to investigate.
Also, if you see RF45 problem, please be more specific as to which signal seemed problematic. Sometimes RFAM monitor in the PSL room doesn't see it but the detchar detect it in some other channels.
Sheila, Keita, Jeff
Sheila noticed the BRS-Y was damping. There are high winds (in upper 20s, gusts in mid to upper 30s). Checked the BRS_Sensor_Correction_Enable_Disable instructions on the Ops Wiki about switching states. Switch the SEI_CONFIG state from WINDY to WINDY_NO_BRSY.
After scattered telephone game with Hugh, Jeff, and Shiela, I've restored the seismic configration to WINDY by requesting the BRS damping to be disabled manually, setting ISI ETMY's node to BLEND_QUITE_250_SC_BRS, then requesting the global SEI manager to go back to WINDY. We should consider re-writing / editing the configuration node so that it's fine with BRS damping. From what Hugh says, when the BRS Y damper is on, we, at most, reinject some noise at around the BRS's suspension resonance at ~6-8 mHz. I have a hard time believing this would cause problems in the observational band. @DetChar -- this would bne a good day / couple of hours to check the differnec between damping ON vs OFF, since wind has been consistently 20-30 mph for about 10 hours now. Configuration changes to as described above at 2017-06-16 20:35 UTC.
The Beam Rotation Sensor damping turns on when the velocity of the BEAM hits a threshold; Jim may have this disabled to only damp when we are not in observing. So the following plots have the BRS velocity, DAMPCTRLMON (~3000=damping on, ~8000=damping off), wind speed, Sensmon range, and (on the second plot) the SENSCOR GAIN (indicates BRS signal going into senscor)
So damping came on this morning ~1100utc. First plot shows 3 hours around this time when the wind was not quite averaging 20 but occasionally gusting to 30. The damping came on when the BRS velocity hit 2000 and rapidly brought the velocity down and shut off after less than 20 minutes. On the SENSMON Range graph is also a 500 point average of the range in green and the DAMP signal overlain. I don't see a definitive impact on the range by having the damping on but maybe one could argue that the wind velocity has chilled some too after the damping came on. Overlaying the averaged range on the wind does not suggest any strong sense at this steady wind. The BRS was NOT taken out of Sensor Correction during this damping. Hmmm
The second case seen on the 2nd plot (6 hours long) is when the wind was apparently strong enough to prevent the BRS from damping down. This damping started about 1630utc. It damped for three hours before achieving stop criteria. After 105 minutes, the operator switched the ISI_CONFIG to WINDY_NOBRSY. This is seen in the additional channel on the plot. Right about that time the range started to increase but I thought it sort of looks like the wind was also turning around. So the wind was running averaged (480sec), then inverted, multiplied by 2.5 and shifted to overlay the Range trace (purple trace). Pretty much looks like the range is directly correlated to the wind speed.
So, I don't think there is a strong argument to turn off BRS/SC when the BRS Damping comes on based on the range. Maybe when the wind is so strong that damping is not effective, the result is the same.
There are few points I want to clear up.
1. The damping does NOT get turned off while we are observing, probably a bad idea to leave this off while we are running, as the BRS will ring up on it's own. I just noticed that there was a ~8mhz signal in the arm, and when I checked BRSY, the damping was still off after Jeff's work earlier and the BRS was very rung up. If no one had caught this, the BRS could have gotten into a state where it was unusable for a long time. Unless someone has a compelling reason for us to do otherwise, we should leave the damping on. If any one is ever unsure about what to do, please call me.
2. I haven't seen any evidence yet that BRS damping has broken a lock or had any very adverse affects on the IFO. I have seen the arm length drives affected when the BRS is damping, I have no idea if this causes scattering or something. I would be interested in talking to some Detchar people about how we can find out if it's problem.
3. If the arm drive at 8mhz is an issue, we can think about modifying the sensor correction filter to more roll off at these frequencies. The simplest would be adding a notch or something to the filter, we could also tweak the damping parameters some.
This morning I moved the bright spot off of the PRM baffle by changing the ITMX compensation plate yaw offset from 0 to 250. At 200 it is still partially visible in the camera image. No new spots were visible in other camera images. No change in DARM was noticed.
A new line at 86 Hz has appeared in the DARM channels after the vent. After running BruCo, I've seen that that frequency was coherent with some PCAL channels: https://ldas-jobs.ligo-wa.caltech.edu/~pep.covas/bruco/1181560000/ I attach two different plots showing the differences between before/after the vent for the DARM channels and for three different PCALX channels . The "before" data is from 07/05/2017 09:00 UTC, and the "after" data is from 15/06/2017 09:00 UTC.
I compared the de-whitened calibrated x-end Pcal TX PD channel (applying the appropriate [;1,1] filtering) with the de-whitened CAL-DELTAL_EXTERNAL just to check that the height is about right. Indeed, this does appear about right (see attached image). When H1 drops out of lock, we will perform some quick tests to see if we can determine what is wrong.
Pep C., Evan G. We localized the time to when this line turned on, at 00:24 May 31 2017 UTC (see attached). Now we investigate what changed at that time.
Evan, the frequency of the high-frequency calibration line we are running from X-end changed at this same time (plot attached). With large amplitudes of lines we are running, due to non-linear effects, they tend to produce many other lines in the spectra. It is possible that this is due to the current line (5950 Hz) we are running. We can definitely test this by changing the frequency and see if 86 Hz goes away (the line features strongly depends on what HF line we are running).
Thanks for pointing this out, Shivaraj. It's quite weird how this is appearing, perhaps beating against other harmonics of the calibration lines?
