CP3 log file DOES NOT exist! CP4 log file DOES NOT exist!
Tested that if the autofill report files do not exists for the current day (which is the case today, previous test had 21Dec hardcoded) then the alog correctly reports this.
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.
Further testing of roboalog entries reporting on CP3,CP4 autofill. This alog has an image attached, the strip tool of the autofill.
WP6412 VAC alarms, add CP1-8 discharge line pressures to cell phone texter
Dave:
The Discharge Line Pressure signals will send cell phone alarms if they remain above 2.0PSI for 5 minutes or longer. The associated Beckhoff ERROR channels will alarm if they record an error. Alarm system was restarted to install the new configuration at 11:04
Modified the LHO MEDM Screens web page to promote the TCS X and Y screens to the main page and remove them from the PSL Detailed Screens page. Clicking on the smaller images in the LHO MEDM Screens web page will open full size more readable versions of the screens.
[Borja]
This entry is to reproduce the analysis I did at L1 as described here and the associated comments.
The main idea is that currently during locklosses many control signals to the suspensions (QUAD and tripple suspension) become too large, which may have an effect on their stability and the time taken to relock. Also the control signals, in many cases, take many seconds to be turned off by GUARDIAN. An approach to deal with this could be to set limits to the range of values that these control signals are allowed, for this I have compiled a range of values these channel had during many lock segments in the range of 1.5 months.
The control channels analysed are given on the attached file 'H1_SUS_channels_for_analysis' (total of 192 channels). From these 157 channels did not have a range of zero for all lock segments.
The lock segments analysed are all those from Oct 22 2016 02:32:49 UTC to Dec 09 2016 19:23:51 UTC with DQ flag L1:DMT-GRD_ISC_LOCK_NOMINAL:1 which informs 'Guardian indicates IFO is in nominal lock state'. A total of 285 segments were retrieved but from those I only looked at lock segments lasting more than 15 secs which reduced the number of Segments to 280. From these there were abot 35 which gave errors when querying the data.
The huge ammount of results are given as figures with subplots each grouping multiple channels associated to a same suspension. The horizontal axis is always 'Number of Segment', the vertical axis it will depend on the analysis done; range during lockloss, time taken to zero de channel after lockloss and Value of the channel during lock (max, min and median).
Each figure is given as a Matlab figure file because of the possibility to turn on and off individual lines on each highly populated subplot and because of the orders of magnitude difference in the range of values that different channels for the same suspension can have (a .png version of the figures is also attached for convenience but notice that to get the full information you will have to look at the .fig file). I have also attached the matlab scripts used to generate each set of results.
Results:
1) Range values around a lockloss: for every lockloss of the analysed lock segments I requested 10 seconds before and after the relock, then the variation range is calculated for each of the analysed channel list (difference between the maximum and minimum values of the 20 seconds of data centered on the lockloss). Script named: matlab_code_range_lockloss.m, Figures named: Fig#_Lockloss_Range_10secs_beforeandafter.fig
It is not rare to see ranges during lockloss between several million to several billion counts!
I have also attached the actual DATA obtained where you can identify the time interval of the Segment number for the plots as well as the plotted ranges and channel names (DATA-Lockloss_Range_10secs_beforeandafter.m).
2) Number of seconds to turn off the channels after lockloss: Again for every lockloss on the analysed segments and channels I query up to 80 seconds after lockloss and see how many seconds it takes for the channel to be turned off. In many cases the answer is 80 seconds which means that it does not turn off during the queried time. Values of zero or negative seconds can be ignore. Figures named: Fig#_TimeToZero_after_lockloss_80secsMax.fig
Each channel plot is accompanied with a dashed line of the same colour which represents the median (not the mean) of the respective channel plot for all the segments. Therefore showing what is the most common time to zero per channel. I have also attached a summary of the median information on a single plot where the horizontal axis is in this case the channel number as per the variable SUS_channel included on the DATA-TimeToZero_after_lockloss_80secsMax.mat file (again ignore negative values). It is clear from this plot that most channels are not turned off within 80 secs after lockloss.
I have attached the Matlab script used to generate these results (matlab_code_TimeToZero_after_lockloss.m).
3) Values of the control channels during lock segments: In this case for each subplot there is a maximum of 5 channels related to the same suspension. For each channel I show the Maximum, Minimum and Median values that the respective channel has for each lock segment. I also attach the matlab cript used to generate this results (matlab_code_lock_segment.m) and a matlab file (DATA-During_lock_data_from_20161022_till_20161210.mat) with the relevant variables containing matrices; Maximum, Minimum and Median of the data. These matrices have dimensions: 'Number of Segments' x 'Number of Channels', these dimension correspond to the also included variables 'Segments' and 'SUS_channels'. Figures named: Fig#_Values_during_lock.fig
Notice that at the time of this analysis a bigger number of segments (about 180 of the 280 segments analysed) did not return data, this happened using both servers: nds.ligo.caltech.edu and nds.ligo-wa.caltech.edu. I do attach the results here but notice that the long zero stretch at the middle is due to this lack of information. To increase the number of segments with data, I also queried a more recent interval between Dec 01 2016 03:29:55 UTC till Dec 20 2016 23:32:39 UTC. This corresponds to a further 99 segments (filename: Segments_Lownoise_LOCK_NOMINAL_from_20161130_till_20161221_H1.txt). For this case the figures are named: Fig#_Values_during_lock_2ndInterval.fig, and the DATA file name is: DATA-During_lock_data_from_20161130_till_20161221.mat
Around 9 am I was told that the laser had tripped. This is the first trip in some time. Attached is a screen dump of what the Beckhoff status screen indicated. Since it indicates a head 1-4 flow problem, most likely the flow rate in head 3 dipped below the minimum flow rate. The laser came back without much ado.
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.
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.
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.
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?
J. Kissel for S. Karki WP #6368 I've moved the PCALX roaming line, its long duration sweep, from 4001.3 Hz to 4301.3 Hz. See schedule status below. Since it looks like we'll have the duty cycle to just finish the schedule within a week, I'm just going to continue to re-gathering the highest frequency data. As such, Sudarshan has something consistent and straightforward with which to work instead of data with a bunch details or qualifications. Frequency Planned Amplitude Planned Duration Actual Amplitude Start Time Stop Time Achieved Duration (Hz) (ct) (hh:mm) (ct) (UTC) (UTC) (hh:mm) --------------------------------------------------------------------------------------------------------------------------------------------------------- 1001.3 35k 02:00 39322.0 Nov 28 2016 17:20:44 UTC Nov 30 2016 17:16:00 UTC days @ 30 W 1501.3 35k 02:00 39322.0 Nov 30 2016 17:27:00 UTC Nov 30 2016 19:36:00 UTC 02:09 @ 30 W 2001.3 35k 02:00 39322.0 Nov 30 2016 19:36:00 UTC Nov 30 2016 22:07:00 UTC 02:31 @ 30 W 2501.3 35k 05:00 39322.0 Nov 30 2016 22:08:00 UTC Dec 02 2016 20:16:00 UTC days @ 30 W 3001.3 35k 05:00 39322.0 Dec 02 2016 20:17:00 UTC Dec 05 2016 16:58:57 UTC days @ 30 W 3501.3 35k 05:00 39322.0 Dec 05 2016 16:58:57 UTC Dec 06 2016 21:09:56 UTC ~15:00 @ 30 W 4001.3 40k 10:00 39322.0 Dec 06 2016 21:09:56 UTC Dec 07 2016 18:50:09 UTC ~20:00 @ 30 W 4301.3 40k 10:00 39322.0 Dec 07 2016 18:50:09 UTC 4501.3 40k 10:00 39322.0 4801.3 40k 10:00 39222.0 5001.3 40k 10:00 39222.0 Frequency Planned Amplitude Planned Duration Actual Amplitude Start Time Stop Time Achieved Duration (Hz) (ct) (hh:mm) (ct) (UTC) (UTC) (hh:mm) --------------------------------------------------------------------------------------------------------------------------------------------------------- 1001.3 35k 02:00 39322.0 Nov 11 2016 21:37:50 UTC Nov 12 2016 03:28:21 UTC ~several hours @ 25 W 1501.3 35k 02:00 39322.0 Oct 24 2016 15:26:57 UTC Oct 31 2016 15:44:29 UTC ~week @ 25 W 2001.3 35k 02:00 39322.0 Oct 17 2016 21:22:03 UTC Oct 24 2016 15:26:57 UTC several days (at both 50W and 25 W) 2501.3 35k 05:00 39322.0 Oct 12 2016 03:20:41 UTC Oct 17 2016 21:22:03 UTC days @ 50 W 3001.3 35k 05:00 39322.0 Oct 06 2016 18:39:26 UTC Oct 12 2016 03:20:41 UTC days @ 50 W 3501.3 35k 05:00 39322.0 Jul 06 2016 18:56:13 UTC Oct 06 2016 18:39:26 UTC months @ 50 W 4001.3 40k 10:00 39322.0 Nov 12 2016 03:28:21 UTC Nov 16 2016 22:17:29 UTC days @ 30 W (see LHO aLOG 31546 for caveats) 4301.3 40k 10:00 39322.0 Nov 16 2016 22:17:29 UTC Nov 18 2016 17:08:49 UTC days @ 30 W 4501.3 40k 10:00 39322.0 Nov 18 2016 17:08:49 UTC Nov 20 2016 16:54:32 UTC days @ 30 W (see LHO aLOG 31610 for caveats) 4801.3 40k 10:00 39222.0 Nov 20 2016 16:54:32 UTC Nov 22 2016 23:56:06 UTC days @ 30 W 5001.3 40k 10:00 39222.0 Nov 22 2016 23:56:06 UTC Nov 28 2016 17:20:44 UTC days @ 30 W (line was OFF and ON for Hardware INJ)
Note, PCALX was briefly turned OFF during this 4301.3 Hz stretch. See LHO aLOG 32323.
The Pcal to DARM ratio for these individual lines were calculated using SLM Tool and the result is tabulated below. The Cavity pole and the optical gain on the last column are eyeballed measurement from the CalMon Tool . These time dependent corrections havenot been applied to the sensing function analysis yet.
Freq Start Time End Time FFT Real Complex Coh CC Pole (O. Gain)
---------------------------------------------------------------------------------------------------------------------
1001.3 30-Nov-2016 09:16:44 30-Nov-2016 13:47:04 10 0.022149 -0.358814 0.999589 346.05(0.9863)
---------------------------------------------------------------------------------------------------------------------
1501.3 30-Nov-2016 17:28:11 30-Nov-2016 19:36:18 10 -0.017951 -0.109817 0.999943 346.05(0.9863)
---------------------------------------------------------------------------------------------------------------------
2001.3 30-Nov-2016 19:36:53 30-Nov-2016 21:01:35 10 -0.015679 -0.044511 0.999391 346.05(0.9863)
---------------------------------------------------------------------------------------------------------------------
2501.3 02-Dec-2016 07:52:51 02-Dec-2016 20:16:47 30 -0.011385 -0.020594 0.998321 347.69(0.9703)
---------------------------------------------------------------------------------------------------------------------
3001.3 04-Dec-2016 02:27:58 05-Dec-2016 00:00:17 30 -0.007719 -0.010563 0.999057 347.06(0.9614)
---------------------------------------------------------------------------------------------------------------------
3501.3 06-Dec-2016 02:27:26 06-Dec-2016 06:10:11 30 -0.005708 -0.005431 0.988492 350.70(0.9793)
3501.3 06-Dec-2016 10:36:18 06-Dec-2016 15:03:35 30 350.70(0.9793)
---------------------------------------------------------------------------------------------------------------------
4001.3 12-Nov-2016 17:20:18 12-Nov-2016 20:49:17 60 -0.004374 -0.003211 0.996350 350.00(0.9966)
4001.3 12-Nov-2016 09:48:25 12-Nov-2016 16:40:53 60 350.00(0.9966)
---------------------------------------------------------------------------------------------------------------------
4301.3 18-Nov-2016 05:20:00 18-Nov-2016 12:44:49 60 -0.003607 -0.002212 0.985922 345.04(0.9748)
4301.3 17-Nov-2016 14:26:40 17-Nov-2016 17:20:13 60 347.00(0.9730)
4301.3 17-Nov-2016 08:56:40 17-Nov-2016 11:07:35 60 347.00(0.9730)
---------------------------------------------------------------------------------------------------------------------
4501.3 20-Nov-2016 05:00:00 20-Nov-2016 13:24:30 60 -0.003366 -0.002162 0.990728 350.76(0.9985)
4501.3 19-Nov-2016 15:40:00 19-Nov-2016 23:48:16 60 350.21(1.0017)
---------------------------------------------------------------------------------------------------------------------
4801.3 22-Nov-2016 07:43:20 22-Nov-2016 16:01:44 60 -0.002883 -0.001369 0.959987 346.89(0.9890)
4801.3 21-Nov-2016 15:20:00 21-Nov-2016 18:22:20 60 346.71(0.9979)
4801.3 21-Nov-2016 04:36:40 21-Nov-2016 09:28:48 60 346.71(0.9979)
---------------------------------------------------------------------------------------------------------------------
5001.3 25-Nov-2016 07:43:17 25-Nov-2016 14:52:54 60 -0.002634 -0.000904 0.973928 348.94(0.9625)
5001.3 27-Nov-2016 11:44:40 27-Nov-2016 18:04:12 60 345.48(0.9724)
---------------------------------------------------------------------------------------------------------------------
More detailed Analysis.