Possibly after some changes made durring maintence, the lockloss tool stopped working. I can use lockloss plot, but not select.
sheila.dwyer@opsws4:~/Desktop/Locklosses$ lockloss -c channels_to_look_at_TR_CARM.txt select
Traceback (most recent call last):
File "/ligo/cds/userscripts/lockloss", line 403, in <module>
args.func(args)
File "/ligo/cds/userscripts/lockloss", line 254, in cmd_select
selected = select_lockloss_time(index=args.index, tz=args.tz)
File "/ligo/cds/userscripts/lockloss", line 137, in select_lockloss_time
times = list(get_guard_lockloss_events())[::-1]
File "/ligo/cds/userscripts/lockloss", line 112, in get_guard_lockloss_events
for t in guardutil.nds.find_transitions(GRD_LOCKING_NODE, t0, t1):
File "/ligo/apps/linux-x86_64/guardian-1.0.3/lib/python2.7/site-packages/guardutil/nds.py", line 32, in find_transitions
for buf in conn.iterate(t0, t1, [channel]):
RuntimeError: Requested data were not found.
After noticing LLO alog 28710 I tried to svn up the lockloss script (we're at rev 14462 now), but I still get the same error when I try to use select
The problem at LLO is totally different and unrelated.
The exception you're seeing is from an NDS access failure. The daq NDS1 server is saying that it can't find the data that is being requested. This can happen if you request data too recent in the past. It also used to happen because of gaps in the NDS1 lookback buffer, but those should have been mostly fixed.
Right now the lockloss tool is looking for all lock loss events from 36 hours ago to 1 second ago. The 1 second ago part could be the problem, if that's too soon for the NDS1 server to handle. But my testing has indicated that 1 second in the past should be sufficient for the data to be available. In other words I've not been able to recreate the problem.
In any event, I changed the look-back to go up to only two seconds in the past. Hopefully that fixes the issue.