• Title: 1/2 OWL Shift: 08:00-16:00UTC (00:00-8:00PDT), all times posted in UTC
  

• State of H1: Observing at 78Mpc for 6hrs
  

• Outgoing Operator: Travis S
  

• Quick Summary: Wind <8mph, useism 0.3um/s, CW inj running, PSL 21.7W.

Title: 1/1 Eve Shift 0:00-8:00 UTC (16:00-24:00 PST).  All times in UTC.

State of H1: Observing

Shift Summary: Started the shift with the PSL down and being worked on by Jason and Corey (T. Vo was covering OPS duties).  Within the first hour of my shift, they had completed their work and I began initial alignment.  After a surprisingly straightforward alignment and locking, made it to NLN at 2:29 UTC.  Other than some excess noise from 10-30 Hz, range has been the typical ~80 MPc for the past 6 hours.  Environment is calm.

Incoming operator: TJ

Activity log:

In addition to the PMC diff that Betsy took care of here, I accepted a diff for H1:IMC-REFL_SERVO_IN1GAIN (setpoint -2.00, epics -1.00) in order to proceed to Observing.  I (actually T.Vo did, since he was already logged onto another workstation) also switched the omcparams.py starting voltage back to -24, which worked to get past the same problem described by Corey here.  Note: I did NOT commit the change in omcparams.py to the SVN.

svn up at .../SusSVN/sus/trunk/QUAD/Common/MatlabTools/QuadModel_Production

All current model features are summarized in a table in G1401132.

Update to existing features

The main change in existing features is that the top mass damping now sees both the suspension and the cage, as in real life because we use OSEMs. Consequently, if you input seismic noise to a damped suspension it will enter both mechanically as usual, as well as through the damping loops. See Seismic_Noise_Propagation_2016_01_01.pdf. Page 1 shows longitudinal transfer functions from seismic noise to the test mass with and without the OSEMs seeing the cage. The second page shows the ratio of these transfer functions. Note that the ratio is greater than a factor of 2 at 4.5 Hz. Beyond 10 Hz the maximum is about 20% at about 10.5 Hz.

Two new features 

1. Additional inputs and outputs added to reflect the relative nature of the OSEMs - i.e. they measure relative displacements and actuate between two points

2. Suspension point reaction forces

The discussion above is one consequence of the first new feature. Another is that you can now make transfer functions between seismic noise and the top mass OSEMs, which is dramatically different from the seismic noise to top mass transfer function. See Seismic_to_Top_OSEMs_2016_01_01-2.pdf. These are obtainable in the model with the new 'toposem' field in the 'out' structure given by the generate_QUAD_Model_Production function.

The second new feature is that there are now outputs for the suspension point reaction forces on the ISI. These are obtainable in the model with the new 'suspoint' field in the 'out' structure given by the generate_QUAD_Model_Production function. These reaction forces allow us to dynamically couple the quad model to the ISI model. Thus, if we wanted, we can make one big ISI-SUS model.

Under-the-hood updates

This update includes significant under-the-hood modifications to how the pieces of the model are put together. Essentially, Simulink files now define the connections and signal flow, where previously this was all done with append/connect commands in the generate script. The motivation for this change is to make the model more extensible and maintanable by humans. The append/connect commands had become virtually unreadable with the dozens of inputs and outputs now in the model. Now someone can look at a more intuitive graphical representation in a simulink file to read or modify how the model is layed out.

There are 4 simulink files defining the 4 possible layouts of the quad model:

For reference, this is a summary of the history of model revisions in the svn:

* generate_QUAD_Model_Production.m

rev 7359: now reads foton files for main chain and reaction damping

rev 7436: Changed hard coded DAMP gains to get the correct values for LHO ETMX specifically.

rev 7508: Restored damping filter choice for P to level 2.1 filters as opposed to Keita's modification. Cleaned up error checking code on foton filter files, and allowed handling of filter archive files and files with the full path.

rev 7639: renaming lho etmy parameter file

rev 7642: Adding custom parameter file for each quad. Each one is a copy of h1etmy at this point, since that one has the most available data.

rev 7646: added ability to read live filters from sites, and ability to load custom parameter files for each suspension

rev 7652: updated to allow damping filters from sites from a specific gps time (in addition to the live reading option)

planned future revision - seismic noise will progate through the damping filters as in real life. i.e the OSEMs are relative sensors and measure the displacement between the cage and the suspension.

rev 7920: big update - added sus point reaction forces, top OSEMs act between cage and sus, replaced append/connect command with simulink files

* ssmake4pv2eMB5f_fiber.m

no recent (at least 4 years) functional changes have been made to this file.

* quadopt_fiber.m

- rev 2731: name of file changed to quadopt_fiber.m, removing the date to avoid confusion with Mark Barton's Mathametica files.

- rev 6374: updated based on H1ETM fit in 10089.

- rev 7392: updated pend.ln to provide as-built CM heights according to T1500046

- rev 7912: the update described in this log, where the solidworks values for the inertias of the test mass and pum were put into the model, and the model was then refit.  Same as h1etmy.m.

* h1etmy.m

- rev 7640: created the H1ETMY parameter file based on the fit discussed in 10089.

- rev 7911: the update described in this log, where the solidworks values for the inertias of the test mass and pum were put into the model, and the model was then refit. Same as quadopt_fiber.m.

Observing for 2 hours at 75-80 MPc.  There seems to be a bit of excess noise below ~30Hz in DARM which seem to correlate with some excess noise in PRCL and MICH.  Wind and seismic are both calm. 

In getting back to Low Noise, I had to change the OMC PZT starting voltage in omcparams.py back to -24 from the -30 that Corey changed it to earlier today.  I did NOT commit the changes to SVN since they seem to be in flux.

Because the H1:PSL-PMC-REF slider was adjusted to land on a value with much larger precision than the SDF file can deal with, it was in alarm out to the 10e-16 digit which could not be cleared with the ACCEPT button.  The correct way to clear this bug is to write the epics slider to a smaller precision value (truncate it to the 10 e-8 or something digit).  However, we are all the way back to Nom LOW Noise, and didn't want to risk this minute slider adjustment - SO, we set the channel to be NOT MONITORED until the next lock loss, when we should:

- Set this channel (H1:PSL-PMC-REF) to be MONITORED again in SDF

- Type in the SDF setpoint value (1.18615) into the slider value and check that it is no longer in error on SDF.

After a remarkably smooth recovery from the PSL incursion, we are back to Observing.

J. Oberling, C. Gray

After this morning's NPRO shut-off, we noticed the FSS RefCav TPD was down to ~1V (the RefCav Refl spot showed that the pitch had moved significantly as well).  At the rate of decay (see attached 7 day trend), there was a good possiblity of the TPD not surviving until maintenance Tuesday (1-1-2016), so we decided, with M. Landry's permission, to go in a adjust it.  In the interest of returning to operation quickly, we only adjusted the periscope mirrors to bring the TPD back up; no investigation as to the cause of the alignment shift was done.

We began by adjusting only pitch on the top periscope mirror.  This only got us back to half way, so I decided to include the bottom periscope mirror and walk the beam.  Walking the beam down got the TPD to ~1.47.  We then did a small yaw tweak to the top periscope mirror only, which got us to ~1.51V.  We then measured the visibility of the cavity, and then turned the ISS back ON and left the PSL enclosure.  Total time in the enclosure was ~30 minutes.

• FSS RefCav TPD (ISS OFF)
  • Before adjustment: 1.08 V
  • After adjustment: 1.51 V
• RFPD DC Voltage
  • Locked: 35 mV
  • Unlocked: 220 mV
  • Visibility: 84.1%
• FSS RefCav TPD (ISS ON): 1.50 V

J. Oberling, C. Gray

At 21:01:51 UTC the PSL NPRO shut off (see attached trend of NPRO diode power, NPRO power, and PSL power watchdog), reason unknown.  The PSL watchdog tripped 3 seconds later at 21:01:54 UTC, so the NPRO definitely shut off first.  After Corey's phone call I drove to the site to reset the PSL.  The only thing I found wrong was that the NPRO power supply was ON, but not sending power to the NPRO (key ON, power supply OFF).  The UPS the NPRO power supply is plugged into did not show an error, and there were no other obvious indications that something went wrong, so I turned the NPRO back ON.  It powered up without issue, and we turned the 35W FE laser on from the LDR.  After fiddling with the PMC and FSS (as usual after a laser shutdown), everything with the PSL was locked and operating properly.  It is still unknown why the NPRO shut off.  At this point I suspect a glitch with the UPS; we have seen this behavior before, where a glitch in the UPS causes the NPRO to shut off with no idication of what went wrong.

At this point we noticed the FSS TPD was down to ~1V, which is getting close to the point where ALS becomes unhappy.  A 7 day trend of the RefCav TPD is attached.  At that rate of decay the FSS might not have lasted until maintenance day on 1-5-2016, so we decided (with M. Landry's permission) to go in and do a quick adjustment of the RefCav alignment.  I will detail that in a follow up alog.

TITLE:  1/1 DAY Shift:  16:00-00:00UTC (08:00-04:00PDT), all times posted in UTC     

STATE of H1:   DOWN (PSL recovered, Initial Alignment by Travis)

Incoming Operator:   Travis

Support:  Chatted with TJ, Sheila on the phone, Thomas Vo helping with operator duties.

Quick Summary:

Nice first half of the shift; latter half of shift H1 went down due to the PSL NPRO power tripping.

• 20:48 - 20:53 Noticed Tidal/ASC/POP_A channels oscillating (but no seismic noise observed)
• 21:02 Lockloss due to PSL NPRO power supply trip.
• Spent the rest of the shift troubleshooting and then addressing the PSL issue.  Jason came on-site to help out & Sheila offered assistance over the phone.  Contacted LLO's operator to let them know our status.  Travis is currently running through an Initial Alignment.

After calling the control room I drove past CS @ 23:58 and arrived at Y-Mid station @ 00:01.
Started filling CP3 @ 00:03, opened the exhaust check valve bypass valve, then opened LLCV bypass valve 1/2 turn, closed the flow 25 seconds later.  5 minutes later I closed the exhaust check valve bypass valve.

Started driving back from Y-Mid @ 00:12, arrived at the CS @ 00:16.

At 23:58 UTC, Gerardo checked in about filling CP3 at the Y-mid station. He is going to Mid Y to fill the dewar.

H1 abrubtly dropped out of lock.  Did not see any obvious reasons for why at first, but then while waiting for Guardian to bring us back, noticed that we have no light from the PSL.  

IMC_LOCK Guardaian is saying:  FSS Unlocked.  (Looking for instructions/alogs about how to address this).  

But I also see that we have 0W output power for the Laser.  Might go to the Laser Diode Room to see if there are any obvious messages.

There is no light on the PSL video screens.

Talking with Jason right now.

Happy New Year all!

H1 has historically not has as bad of RF beat / whistle problems as L1 has. In fact, the last alog report is for data on October 30th. But dec 31st shows a high density of glitches above 100Hz and densest above 500Hz, which have the signature shape of RF beats we've seen before and are correlated with PRCL and SRCL, similar to one of the manifestations of whistles seen at LLO. 

• Figure 1 shows the SNR vs frequency of the glitches at H1 for December 31st. The low-SNR red triggers above 100Hz are mostly whistles that hveto found correlated to PRCL and SRCL.
• Figure 5 shows the time-frequency behavior, where I circled the red dots that include whistles, where one can see how many of these quiet whistles were happening on Dec 31. 
• Figures 2,3,4 show example omega scans of these low-SNR whistles. Note that these extend to low enough frequency to reach the CBC signal range.

Note 1: we produce auto omega scans for the loudest glitches that hveto finds, and these whistles are all very quiet. If anyone wants to follow these up in more detail, you can get GPS times for the high-frequency low-snr triggers for Dec 31 correlations with PRCL and SRCL at those links. 

Note 2: Dec 31 looks like the worst day, but there might have been some weak whistles occuring on other days too, but we'd have to follow up some low SNR triggers on those days (e.g. today Jan 1 and the past few days).

Since there can be times when one can miss recent changes to operating H1 (due to not getting your hands on H1 due to long locks or being away in between being on shift....or maybe you just don't have a great memory, like me!), there can be times when one might not be up-to-speed on the latest news, workarounds, tricks for running H1.  

This is why we have an Operator Sticky Notes wiki page.  During recent shifts, there were a few items/scenarios which were new to me.  To help reduce searching, I added several new items to the list, and here are some of the newest ones (recent - older) I noticed/came across this week:

• Input Align workaround
• CP3 Overfills daily
• Dark Michelson not locking workaround
• Latest PRMI instructions
• OMC not locking

Please help to keep this page current with any new changes you come across.

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.