Jemie, Kiwamu,
Even though we didn't think that the change we made on the OMC model (alog 20197) would impact on locking, it actually did.
The OMC guardian kept stopping because the code tries to access an oversize index for a data array. After some investigaton, it turned out to be due to the data rate for H1:OMC-PZT1_MON_DC_OUT_DQ whose sampling rate had been changed from 16 kHz to 512 Hz in this morning. Since the OMC guardian tries to access the data with an assumption that the data sampling rate is 16 kHz, some lines in the code lead it to the bad situation. This error happened in FIND_CARRIER in which the code sweeps the OMC length and attemps to find peaks for the 45 MHz sidebands.
Jamie and I did a quick hack -- we decimated another channel, H1:OMC-DCPD_SUM_OUT_DQ, from 16 kHz to also 512 Hz using scipy.signal.deciamate() so that relavant lines are consistent for 512 Hz. We tested it once and it worked.
Somehow it still can't find the 00 mode on its own.
As for the warning message about bad filter coefficients, I changed the order of the Chebyshev from 8 to 4, and that seems to make the warning message go away.