Displaying report 1-1 of 1.
Reports until 11:22, Friday 01 January 2016
H1 General (OpsInfo)
corey.gray@LIGO.ORG - posted 11:22, Friday 01 January 2016 - last comment - 12:13, Friday 01 January 2016(24609)
H1 Back To Observing (Post Quake)

As I walked in on shift, TJ was working on bringing H1 back.  I'm fairly certain he was just going for locking H1 back up without trying an alignment.  As Guardian was in the first few steps, TJ was touching up arm powers.  A pretty cool thing was seeing DRMI lock within seconds(!), and then Guardian continued taking H1 up, until,...

Guardian Message:  "OMC not ready" In DC_READOUT_TRANSITION

I had heard other operators having to deal with an issue with the OMC not locking over recent weeks, but I had not personally dealt with this.  So, when Guardian gave the message "OMC not ready" in DC_READOUT_TRANSITION, I had to do an alog search (and also left a voicemail with the on-call commissioner).  I eventually found some alogs which gave some things to try which are basically:

  1. On OMC_LOCK Guardian node, "READY_FOR_HANDOFF" will already be selected.  I re-selected  "READY_FOR_HANDOFF".  BUT, this didn't work.
  2. Then I took OMC_LOCK to Auto.  This just had Guardian repeatedly try (and fail) to lock the OMC by sweeping the OMC PZT to find the three high peaks (2 sideband, 1 carrier).  So this didn't work.
  3. I then found a TJ alog (& Kiwamu's earlier alog), which pointed to how to change the PZT sweep starting voltage.  Basically I changed the PZT starting voltage from -24 to -30 (seems like these values have been used a few times over the last few weeks) in the parameter file (omcparams.py).  I saved this file, and then hit LOAD on OMC_LOCK.  NOTE:  I did not know how to check this file into the SVN, so omcparams.py is not checked into SVN.
    • This worked!  And then ISC_LOCK immediately took over and continued on (paused at the usual Engage ISS).
    • Additional NOTE:  Since I was logged in as ops on the operator0 workstation, I was not able to Edit the OMC_LOCK code.  So I went to another workstation, logged in as corey.gray, and then editted/saved the omcparams.py file.  Is there a reason why Guardian files are ReadOnly when logged in as ops....oh, actually, it's probably because we want to keep track of who makes changes to files, yes?

Made it to NLN.  

Guardian Addtional Notes:  (with TJ's help on the phone)

Did get an ISC_LOCK user message of:  "node OMC_LOCK:  STOLEN (by USER)".  This is due to my taking OMC_LOCK to Auto (#2 above).   To clear this message, one can go to the ISC_LOCK, click MANUAL, select INIT.  (this should take OMC_LOCK back to being managed by IMC_LOCK).

Additionally, I also happen to notice some red values for OMC_LOCK & IMC_LOCK, which were the *_LOCK_EXECTIME_LAST channels.  TJ said these are normally red, so I didn't worry about them.

FINALLY:  Back to Observing at 17:08 roughly about 80min after the EQ (could have been much quicker if I didn't have the OMC issue!)!  Had a few big glitches at the beginning of the lock, but this could have been related to my issues noted above (maybe?).  But over the last few hours, H1 has been running with a nice range around the usual 80Mpc.

Comments related to this report
corey.gray@LIGO.ORG - 12:13, Friday 01 January 2016 (24612)OpsInfo

Sheila walked me through how to check a the file I changed to the SVN.

Since I was logged in as ops on the operator0 work station, I had to ssh into another computer:

  • ssh corey.gray@opsws1
  • [entered password]
  • userapps
  • cd omc/h1/guardian
  • svn ci -m "changed pzt voltage to -30 from -24"
Displaying report 1-1 of 1.