5.2M Nikol'skoye, Russia
Was it reported by Terramon, USGS, SEISMON? Yes, Yes, No
Magnitude (according to Terramon, USGS, SEISMO): 5.2, 5.2, NA
Location 79km W of Nikol'skoye, Russia; LAT: 55.3, LON: 164.7
Starting time of event (ie. when BLRMS started to increase on DMT on the wall): 16:30 UTC
Lock status? Still locked
EQ reported by Terramon BEFORE it actually arrived? I noticed the EQ band BLRMS coming up before checking Terramon.
H1 is locked and running at 73Mpc. Coincidental time with Livingston is approaching 5 hours and 20 minutes. The BNS range plot indicates features that are consistent with glitches but no glitches have been reported. Winds are calm. µSeism appears to be trending downward with the mean still riding at the 90%ile. EQ activity has been negligible. Steady as she goes.
TITLE: 12/22 Eve Shift: 00:00-08:00 UTC (16:00-00:00 PST), all times posted in UTC
STATE of H1: Observing at 70.6784Mpc
INCOMING OPERATOR: Ed
SHIFT SUMMARY: Jim had it locked for me when I arrived. Nothing exciting to report. Bounce and roll came back high when I relocked so I increased the ITMY gain a bit and accepted the SDF.
LOG:
16:00 Kyle to mid Y
16:45 Kyle back
6:11 Lockloss. Cause not obvious from the FOMs.
7:21 Observe again.
H1 locked for almost 9 hours and counting. LLO is down so I'll take this opportunity to run a2l (high coherence in pitch).
After pumping on the clogged level sensing line for a short period this morning, I isolated the line by closing the in-line ball valve that is part of the adapting hardware. Next, I removed the vacuum line and connected the actively flowing/purging UHP N2 line in its place (10 psi @ 1 lpm). The clogged line then can be back-filled with dry N2. Once back-filled, the adapting hardware is removed and the (slightly positive pressure) line then equalizes to room pressure. The open line then gets connected to its nominal plumbing (local mechanical magnahelic differential pressure gauge in parallel with CDS pressure transducers). At this point, the pattern is for a buildup of pressure until both the mechanical pressure gauge and CDS transducers "rail" at 100% Keep in mind when looking at the data that the rate of this pressure build-up has been sporadic due to my inconsistent making up of the plumbing compression fittings - sometimes by hand, sometimes with wrenches - it turns out that even small leaks into the room confuse the issue. Regardless something WONDERFUL is happening in all instances. That is, gas is building up above room pressure after the equalized line gets connected to the "closed" non-leaking plumbing. Each time the plumbing fitting is loosened, I can hear and feel a significant amount of built up gas being released into the room. The only explanation the I can come up with is that LN2 is getting past the plug and vaporizing in the warm section of the sensing tube or the plug is comprised of a high vapor pressure material and is "inching" up the sensing line and getting warmed. I was only able to try two iterations today and am leaving the line connected to the UHP N2 (10 psi @ 0.5 LPM) over night. Will try some more tomorrow.
J. Kissel I haven't processed them yet, but for the record, I was able to grab a collection of measurements of the pas few days that should be a nice reference for (a) The PUM driver fiasco, and (b) a before vs. after the Holiday shut down The data lives here: FullIFOActuatorTFs/2016-12-20/2016-12-20_H1SUSETMY_L1_iEXC2DARM.xml FullIFOActuatorTFs/2016-12-20/2016-12-20_H1SUSETMY_L1_PCAL2DARM.xml FullIFOActuatorTFs/2016-12-20/2016-12-20_H1SUSETMY_L2_iEXC2DARM.xml << During temporarily swapped PUM Driver FullIFOActuatorTFs/2016-12-20/2016-12-20_H1SUSETMY_L2_PCAL2DARM.xml << During temporarily swapped PUM Driver FullIFOActuatorTFs/2016-12-20/2016-12-20_H1SUSETMY_L3_iEXC2DARM.xml FullIFOActuatorTFs/2016-12-20/2016-12-20_H1SUSETMY_L3_PCAL2DARM.xml FullIFOActuatorTFs/2016-12-21/2016-12-21_H1SUSETMY_L2_iEXC2DARM.xml << After PUM driver was reverted FullIFOActuatorTFs/2016-12-21/2016-12-21_H1SUSETMY_L2_PCAL2DARM.xml << After PUM driver was reverted SensingFunctionTFs/2016-12-20_H1DARM_OLGTF_4to1200Hz.xml << During swapped driver SensingFunctionTFs/2016-12-20_H1_PCAL2DARMTF_4to1200Hz.xml << During swapped driver -- unfortunately incomplete due to lock loss SensingFunctionTFs/2016-12-21_H1DARM_OLGTF_4to1200Hz_25min.xml << After PUM driver was reverted SensingFunctionTFs/2016-12-21_H1_PCAL2DARMTF_4to1200Hz_8min.xml << After PUM driver was reverted We'll process this data of the next few weeks and get back to you.
J. Kissel Yesterday, after seeing little-to-no impact from replacing the H1 SUS ETMY PUM driver, we have reverted to the original driver. - Spare Driver (s/n S1102648) swapped in: LHO aLOG 32745 - Original Driver (s/n S1102652) reverted in: LHO aLOG 32780 The only H1 observational stretch that includes this temporary PUM driver: Dec 20 2016 10:44:28 UTC - Dec 20 2016 13:43:44 UTC Dec 20 2016 02:44:28 PST - Dec 20 2016 05:43:44 PST GPS 1166265885 - GPS 1166276641 Duration: 10756[sec] or 2.99 [hr] During this time, L1 only had a short 22 minute lock stretch, Dec 20 2016 12:31:15 UTC - Dec 20 2016 12:53:34 UTC Dec 20 2016 04:31:15 PST - Dec 20 2016 04:53:34 PST GPS 1166272292 - GPS 1166273631 Duration: 1336 [sec] or 0.37 [hr] Note: While reverting the coil driver, Fil also power cycled the respective AI chassis, so observational stretches after Dec 20 2016 13:43:44 UTC, if they have an improved glitch rate, are likely due to either reseating / reconnecting the original PUM driver (s/n S1102652), or are perhaps more likely related to the power cycle of the AI chassis. --------- Characterization Measurement Comparison between Temporary Spare Original (S1102648) and Original Driver (S1102652) Using the same entirely digital measurement technique we used to determine the compensating poles and zeros for the coil drivers before O1 (i.e. using the coil driver monitor circuits; see LHO aLOG 20846), I measured the PUM driver's frequency response before and after we swapped out the driver for a spare. Results are attached. The .png attachments focus on State 3, which is the state used in nominal low noise and therefore would affect calibration, coil balancing, and length-to-angle decoupling filters. The .pdf attachments cover all four states for all four coils that were measured (because we do transition between states during lock-acquisition -- important for duty cycle, not sensitivity). The analysis process is as follows (in order of .png attachments): (1) In order to get coherence across the entire relevant frequency band**, I took both swept sine and white noise transfer functions. These were each filtered for high coherence (a threshold of 0.99), and then concatenated. The .png shows one coil (LR), in one state (state 3), for the original driver (S1102652) as an example to illustrate the process. (2) Once this data is gathered and concatenated for the two drivers, for all 4 states of all 4 coils, I take the ratio of the original vs. the temporary driver. The .png shows an example of this again for the LR coil in state 3, but for both drivers and their ratio. (3) The ratio of driver response for all four coils is shown in the same plot in the 3rd .png. (4) To compute the impact of these changes on the longitudinal response of the stage, we show two traces in the 4th .png. Mathematically similar but not identical, I show (a) the "average" (more accurately, the sum of each coil multiplied by 1/4) of the ratios from plot (3), and (b) the ratio of the "average" of each driver's coils. Plot 4 shows that, if we had left the temporary driver in place, then we would have a frequency dependent, +/- 4% / 5 [deg] systematic error in the IFO's response to gravitational waves in the 10 - 30 Hz region. It also means, that for that 3 [hr] observation stretch on Dec 20th, we have this +/- 4% / 5 [deg] systematic error in the IFO's response in the 10 - 30 Hz region. For this reason, if at all reasonable, I suggest we create a data quality flag for that observation stretch. Otherwise, the librarian's nightmare of creating a new DARM model for just those 3 [hrs] would divert the calibration group's energy away from where I think our priorities lie in the foreseeable future. * This actuator authority comparison was generated by Evan, originally in LHO aLOG 28746. The script to generate these plot lives here: /ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/PreER9/H1/Scripts/HeirarchicalFilterDesign/HeirarchicalFilterDesign.m and the plots from the entry live in the same directory. ** This data was taken when I expected that we were going to stick with the S1102648 PUM driver and needed to readjust the coil compensation filters (see LHO aLOG 21232). As such, the relevant frequencies are from 0.1 [Hz] -- enough below the lowest pole frequencies it can be separated from DC transconductance in fitting -- to 10 kHz where the impact of coil impedance begins to flatten out. ------------ The templates and exported data from this aLOG live in: /ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/O2/H1/Measurements/Electronics/ The script to analyze the data lives in: /ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/O2/H1/Scripts/Electronics/ The .pdfs of the attached plots live in: /ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/O2/H1/Results/Electronics/
Starting CP3 fill. LLCV enabled. LLCV set to manual control. LLCV set to 50% open. Fill completed in 1476 seconds. TC B did not register fill. LLCV set back to 19.0% open. Starting CP4 fill. LLCV enabled. LLCV set to manual control. LLCV set to 70% open. Fill completed in 36 seconds. TC B did not register fill. LLCV set back to 34.0% open.
this robo-posting is the final in today's test. It was generated by a crontab running on script0. In future it will run every Mon, Wed, Fri at 12:10 and report on the 11am CP3,4 autofills.
The H1 PSL Detailed Screens link from the LHO MEDM Screens web page now displays additional screens for TCSX and TCSY.
Starting CP3 fill. LLCV enabled. LLCV set to manual control. LLCV set to 50% open. Fill completed in 1476 seconds. TC B did not register fill. LLCV set back to 19.0% open. Starting CP4 fill. LLCV enabled. LLCV set to manual control. LLCV set to 70% open. Fill completed in 36 seconds. TC B did not register fill. LLCV set back to 34.0% open.
our reporting script now shows both cp3 and cp4 fills. We will change the format of the text slightly to show the start/stop times because the reporting is delayed beyond the time-out period of one hour.
For CP3:
Increased the LLCV to 20 from 19, due to amount of time it took to overfill CP3 (1476 seconds).
Starting CP3 fill. LLCV enabled. LLCV set to manual control. LLCV set to 50% open. Fill completed in 1476 seconds. TC B did not register fill. LLCV set back to 19.0% open.
5.9M Northern Mariana
Was it reported by Terramon, USGS, SEISMON? Yes, Yes, No
Magnitude (according to Terramon, USGS, SEISMO): 5.9, 5.9, NA
Location 120km NNE of Farallon de Pajaros, Northern Mariana Islands; LAT: 21.5, LON: 145.4
Starting time of event (ie. when BLRMS started to increase on DMT on the wall): 17:00 UTC
Lock status? Lockloss due to earthquake
EQ reported by Terramon BEFORE it actually arrived? Terramon reported before the lockloss, but I noticed the EQ band BLRMS coming up before checking Terramon
Re EX temperatures;
I have made adjustments at both EX and EY (lowered heater settings by 1ma). Bubba will adjust chilled water settings tomorrow morning.
Carlos, Jim B, Dave, Nutsinee
Follow up of WP6382
I took advantage of the earlier down time to test the HWS stream images script and swapping CLink around. The original set up after Carlos installed the second PCI-e card was HWSY CLink was plugged into the new card and HWSX CLink remained the same (plugged to old card). HWSX streamed live images without problem while HWSY can't get any sensible image at all (see attachment). So I tried a few more configurations:
We have come to the conclusion that the spare card might be busted. The next thing to try is to order a new card and try again. This way we will know for sure that the card actually works. We don't know where the spare card came from and whether or not it has been tested.
Only HWSX code is left running for now.
The cards were all ordered at the same time for aLIGO but were not individually tested.
It's probably the capture card but It might also be the actual PCI slot on the bus. Have you tried swapping the two cards around?
We just lost lock, but I think it's pretty clearly not from the earthquake. The PSL is down, Peter is taking a look at it.