FAMIS 4740 ETMY Pitch has hit -10 on a few oscillations.
Received the following error while running the script: patrick.thomas@zotws3:~$ cd /opt/rtcds/userapps/release/sys/h1/scripts patrick.thomas@zotws3:/opt/rtcds/userapps/release/sys/h1/scripts$ python oplev_trends.py alloc: invalid block: 0x6091080: a0 6 Aborted patrick.thomas@zotws3:/opt/rtcds/userapps/release/sys/h1/scripts$
TITLE: 08/12 Day Shift: 15:00-23:00 UTC (08:00-16:00 PST), all times posted in UTC STATE of H1: Observing at 52Mpc OUTGOING OPERATOR: Ed CURRENT ENVIRONMENT: Wind: 7mph Gusts, 5mph 5min avg Primary useism: 0.02 μm/s Secondary useism: 0.04 μm/s QUICK SUMMARY: 15:01 UTC Restarted video2 (MEDM screens not updating). 15:13 UTC Restarted alarm0 (VerbalAlarms not updating). Error message upon startup of VerbalAlarms: Could not connect to GRD-ALS_DIFF_ETMY_ESD_ERROR. PSL dust monitor 102 is in INVALID alarm. This appears to be known (alog 38142). 0.03 - 0.1 Hz seismic BLRMS is ringing down, possibly from earthquakes in Alaska.
TITLE: 08/12 Owl Shift: 07:00-15:00 UTC (00:00-08:00 PST), all times posted in UTC
STATE of H1: Observing at 51Mpc
INCOMING OPERATOR: Patrick
SHIFT SUMMARY:
Quiet shift with no incidents. Handing off to Patrick.
LOG:
TITLE: 08/12 Owl Shift: 07:00-15:00 UTC (00:00-08:00 PST), all times posted in UTC
STATE of H1: Observing at 51Mpc
OUTGOING OPERATOR: Jim
CURRENT ENVIRONMENT:
Wind: 8mph Gusts, 5mph 5min avg
Primary useism: 0.01 μm/s
Secondary useism: 0.04 μm/s
QUICK SUMMARY:
TITLE: 08/12 Eve Shift: 23:00-07:00 UTC (16:00-00:00 PST), all times posted in UTC
STATE of H1: Observing at 51Mpc
INCOMING OPERATOR: Ed
SHIFT SUMMARY: 1 unexplained lockloss, otherwise quiet shift
LOG:
Jeff had it locked when I got here.
4:16 Lockloss, environment was quiet, I couldn't really see a cause. Relocking was pretty easy. Back to observing at 4:58
PaulM, TJ, SudarshanK(remotely)
The low frequency Pcal lines running at 333.9 Hz and 1083.3 Hz were switched off during the PEM injection commissioning break and the guardian node (HIGH_FREQ_LINES) that schedules the single line injection beginning from 4501.3 Hz and ending at 1501.3 Hz with 500 Hz interval was initiated.
These changes were accepted into the SDF system -- see LHO aLOG 38144.
I've looked at 3 earthquakes and how the SEi signals changed for each.
Data for ETMX and ETMY for 3 EQs:
I've included drive signals, sensors (osems), and then subtracted the drive signals from the sensor (osem) signals (on speculation, no claim this is completely valid, outside of M0), with some interesting results.
There are a number of sensors that have large changes compared to the other osems around them, and some that are large in both sensors and sensors-drives.
This leads me to believe that further investigation into these osems may be warented.
All values the change from before to after the earthquakes, and all comments are regarding EQ2 only.
osems | osems - drive | ||
ETMX | M0 | RT: large change | RT: large change |
L1 | LL, UR: large change | all osems: no remarkable changes | |
L2 | UL, UR: large changes | all osems: inconsistent changes | |
ETMY | M0 | RT: large change | RT: large change |
M0 | SD: nothing remarkable | SD: large change | |
L1 | LL: large change | LL: large change | |
L2 | UL: large change | all osems: no remarkable changes | |
L2 | LL and UR: small change | all osems: no remarkable changes |
Run the Ops SVN file checks. Checked in several Filter Files and SNAP files in the SVN repository.
Could not reach Pcal folks to confirm SDF differences. Accepted the differences (see file below) to get back to Observing.
These changes are standard.
In other words: The temporary PCALX calibration lines that had been running for a few days (LHO aLOG 37952) were switched OFF the other day (see LHO aLOG 38148). There are many ways to do so, but that day they chose to zero out the "oscillator use" matrix which sums all PCALX oscillators as desired. Element 1_1 has been traditionally reserved for the high-frequency roaming PCAL line used for Sudarshan's thesis. It was turned back "ON" by putting a 1.0 in the matrix. However, there's no gain on the oscillator, so nothing's coming out. Elements 1_2 and 1_3 were for the 333.9 Hz and 1083.3 Hz lines, which have now been zeroed. The reason these showed up as an SDF difference in the OBSERVE snap was because these lines had been running during observation ready data for the past few days. So accepting this values above are just accepting that they are turned OFF.
PSL dust 102 has not been updating for some time, while PSL dust 101 is working fine. As a first try to fix the problem, I stopped the EPICS IOC code and restarted it. This did not fix the problem.
Before and after the restart, the IOC was reporting communication issues with PSL Dust-102
2017/08/11 12:47:22.773741 gt521s1 H1:PEM-CS_DUST_PSL102_OPSTATUS: No reply from device within 200 ms
Sheila, TVo
In attempts to switch DARM control from ETMY ESD to other methods (see aLOG-37984), we wanted to see if the ITM ESDs had enough range to be able to take on the DARM control signal during locking as well as estimate the ratio of low noise response.
Configuration:
ETMX | ITMX | |
Digital Gains | -39.2 | -7.0 |
L3 Filters | Same | Same |
Analog Driver Gains | 2 | 2 |
We can compare the respective responses by dividing out the digital and driver gains and then taking the ratio between ITMX and ETMX TFs.
The first picture is the individual TFs and the second picture is the ratio of the magnitudes as a function of frequency.
Sheila trended a lock acquisition and found a time where the ETMX ESD was driving the hardest so we made an RMS measurement to get a sense of what is needed to lock. Then we can estimate what is needed from the ITMX ESD and see if it is close to saturating the 18-bit DAC, also attached is the calculation.
Conclusions:
1) The ratio of ETMX to ITMX ESD drive is about 3.
2) The ITMX ESD range has enough range to lock with DARM, we'd only use up about 12% of DAC range.
model restarts logged for Thu 10/Aug/2017 - Fri 04/Aug/2017 No restarts reported
Based on some follow up from an HVeto journal club, I sanity-checked my claim that ETMY L1 NoiseMon channels are winning HVeto nearly every day. Attached are said results. In viewing the data from Jun-8 until Aug-9, one of the four ETMY L1 channels begins showing up as the consistent round 1 winner on June 27; it occasionally pushes back to round 3 due to other exceptionally noisy aux channels. This trend continues through until today. Also, the LL channel is the most consistent winner (about 60% of all round wins). In the attached plots, the regions where it is not a round winner (7-Jul to 13-Jul) simply have no HVeto output. I assume these channels would have continued to lead otherwise. Further time series analysis of glitches to come.
TITLE: 08/11 Owl Shift: 07:00-15:00 UTC (00:00-08:00 PST), all times posted in UTC
STATE of H1: Observing at 52Mpc
INCOMING OPERATOR: Jeff
SHIFT SUMMARY:
LOG:
Quiet shift. Nothing to report.
12:59UTC