| 30 Jul 2015 | 29 Jun 2017 | |
| mc1 p | 0 | -34 |
| mc1 y | 0 | 50 |
| mc2 p | 0 | 10 |
| mc2 y | 0 | 7 |
| mc3 p | 0 | 114 |
| mc3 y | 0 | 85 |
FAMIS 4734 The script to plot the optical lever trends is returning an error: patrick.thomas@zotws1:/opt/rtcds/userapps/release/sys/h1/scripts$ python oplev_trends.py Traceback (most recent call last): File "oplev_trends.py", line 29, inbuffers= conn.fetch(start,stop,channels_pit) RuntimeError: Requested data were not found.
It works as controls. Images attached. The BS Yaw may be close to +10.
I can also run the script and get the plots. Patrick thinks an environment variable is mis-configured in his account.
The nds2 client paths (amongst others) are totally out-of-date. These should not even be in your account's startup, but instead using the cdscfg script as (I assume) called in the controls account.
I think I was given these at one point to try an experimental nds client with gap handling.
When importing either cdsutils or gpstime into python we were getting the warning message:
>>> import gpstime
/ligo/apps/linux-x86_64/gpstime/lib/python2.7/site-packages/gpstime-0.1.2-py2.7.egg/gpstime/__init__.py:150: RuntimeWarning: Leap second data is expired.
Run 'update_leapdata()' to download the latest bulletin from the IETF
RuntimeWarning, stacklevel=1)
The local leap second data files had expired 28th June 2017. The updated file from IETF has a new expiration 28th Dec 2017 (and no leap second to be applied at the end of the year).
The packaged debian machines (just one on H1 at the moment) load a new local copy of the file into the user's home directory when the expiration is detected. For all the non-packaged machines (most of them) I have updated the leap-seconds.txt file in the /ligo/apps/[linux-x86_64, debian8] areas.
Drifting but not out of the range that's acceptable.
TITLE: 06/30 Day Shift: 15:00-23:00 UTC (08:00-16:00 PST), all times posted in UTC
STATE of H1: Observing at 54Mpc
OUTGOING OPERATOR: TJ
CURRENT ENVIRONMENT:
Wind: 3mph Gusts, 2mph 5min avg
Primary useism: 0.01 μm/s
Secondary useism: 0.07 μm/s
QUICK SUMMARY:
TITLE: 06/30 Owl Shift: 07:00-15:00 UTC (00:00-08:00 PST), all times posted in UTC
STATE of H1: Observing at 65Mpc
INCOMING OPERATOR: Cheryl
SHIFT SUMMARY: A mysterious lock loss and some trouble getting back up. An initial alignment helped, but it still lost lock at NOMINAL_LOW_NOISE after a min, but then came back up with no issues after that.
LOG:
No obvious cause.
Observing 09:15 UTC for 1min and 12sec. I did an initial alignment after failing a few times, and that helped, at least till it broke lock a minute in.
Back to Observing at 09:47 UTC
TITLE: 06/30 Eve Shift: 23:00-07:00 UTC (16:00-00:00 PST), all times posted in UTC
STATE of H1: Observing at 68Mpc
OUTGOING OPERATOR: Travis
CURRENT ENVIRONMENT:
Wind: 5mph Gusts, 3mph 5min avg
Primary useism: 0.01 μm/s
Secondary useism: 0.07 μm/s
QUICK SUMMARY: 2 hour lock after recovering from an earthquake.
TITLE: 06/30 Eve Shift: 23:00-07:00 UTC (16:00-00:00 PST), all times posted in UTC
STATE of H1: Observing at 69Mpc
INCOMING OPERATOR: TJ
SHIFT SUMMARY: Some trouble after the EQ lockloss, but all seems to be well now. Lock is ~2 hours old.
LOG:
6:34 Accidentally went out of Observe for less than 1 minute
I ran A2L again which seemed to clear a bunch of SDF diffs in ASC (maybe it didn't complete the previous time I ran it), but not all of them. I accepted the remaining diffs (sorry, no screenshot). DARM spectrum looks normal again and we are at ~70 MPc.
When running A2L the past couple of times, I have noticed that the terminal is displaying errors about 'Leap second data expired' that I don't recall seeing before. See screenshot.
Although it seems to have stopped on its own, and Keita had a look at the code and didn't see any issues, IMC_LOCK went into an error state and reported something like "Cannot connect to ISS_THIRD_LOOP_SERVO_GAIN". Maybe someone in CDS-land can have a look at this and tell me if it was user error or otherwise.
It happened again when we got to NLN. See screenshot.
guardlog --today IMC_LOCK |grep THIRDLOOP_SERVO_GAIN
2017-06-30_03:06:41.523790Z IMC_LOCK [POWER_UP_TR_CLOSED.main] ezca: H1:PSL-ISS_THIRDLOOP_SERVO_GAIN => 0
2017-06-30_03:06:41.890790Z IMC_LOCK [POWER_UP_TR_CLOSED.main] ezca: H1:PSL-ISS_THIRDLOOP_SERVO_GAIN => 0.5
2017-06-30_03:25:46.604890Z IMC_LOCK [POWER_UP_TR_CLOSED.main] ezca: H1:PSL-ISS_THIRDLOOP_SERVO_GAIN => 0
2017-06-30_03:25:46.994710Z IMC_LOCK [POWER_UP_TR_CLOSED.main] ezca: H1:PSL-ISS_THIRDLOOP_SERVO_GAIN => 0.5
2017-06-30_03:31:43.967770Z IMC_LOCK [ISS_DC_COUPLED.main] USERMSG 0: EZCA CONNECTION ERROR: Could not connect to channel (timeout=2s): H1:PSL_ISS_THIRDLOOP_SERVO_GAIN
2017-06-30_03:50:27.959750Z IMC_LOCK [ISS_DC_COUPLED.main] USERMSG 0: EZCA CONNECTION ERROR: Could not connect to channel (timeout=2s): H1:PSL_ISS_THIRDLOOP_SERVO_GAIN
2017-06-30_03:54:58.400950Z IMC_LOCK [ISS_DC_COUPLED.main] USERMSG 0: EZCA CONNECTION ERROR: Could not connect to channel (timeout=2s): H1:PSL_ISS_THIRDLOOP_SERVO_GAIN
2017-06-30_04:17:24.381530Z IMC_LOCK [POWER_UP_TR_CLOSED.main] ezca: H1:PSL-ISS_THIRDLOOP_SERVO_GAIN => 0
2017-06-30_04:17:24.765150Z IMC_LOCK [POWER_UP_TR_CLOSED.main] ezca: H1:PSL-ISS_THIRDLOOP_SERVO_GAIN => 0.5
2017-06-30_04:23:40.218410Z IMC_LOCK [ISS_DC_COUPLED.main] USERMSG 0: EZCA CONNECTION ERROR: Could not connect to channel (timeout=2s): H1:PSL_ISS_THIRDLOOP_SERVO_GAIN
Is this a network problem or what? I can read the number using caget almost immediately as of now, though.
This has happened the past 2 brief locks. During these locks, the DARM spectrum is ~ an order of magnitude above the reference traces from ~300Hz to several kHz. The max range reported during these locks was ~30MPc.
Called Dave at Keita's request. He noticed that the error reported contained an typo for the channel name (should be PSL-ISS rather than PSL_ISS). I found the typo in the guardian code, fixed it, and reloaded the IMC_LOCK guardian. Hopefully this fixes it. Thanks Dave!
