See attached.
I removed the (%py). This seems to have fixed it.
Just lost lock.
22:43 UTC Observing. No SDF differences.
TITLE: 02/22 Day Shift: 16:00-00:00 UTC (08:00-16:00 PST), all times posted in UTC
STATE of H1: Observing at 119Mpc
OUTGOING OPERATOR: Cheryl
CURRENT ENVIRONMENT:
SEI_CONF state: WINDY
Wind: 2mph Gusts, 1mph 5min avg
Primary useism: 0.03 μm/s
Secondary useism: 0.35 μm/s
QUICK SUMMARY: No issues.
TITLE: 02/22 Owl Shift: 08:00-16:00 UTC (00:00-08:00 PST), all times posted in UTC
STATE of H1: Observing at 120Mpc
INCOMING OPERATOR: Patrick
SHIFT SUMMARY: locked in Observe
LOG:
H1 locked in Observe.
TITLE: 02/22 Owl Shift: 08:00-16:00 UTC (00:00-08:00 PST), all times posted in UTC
STATE of H1: Observing at 121Mpc
OUTGOING OPERATOR: Ed
CURRENT ENVIRONMENT:
SEI_CONF state: WINDY
Wind: 2mph Gusts, 1mph 5min avg
Primary useism: 0.04 μm/s
Secondary useism: 0.38 μm/s
QUICK SUMMARY: H1 locked in Observe
TITLE: 02/22 Eve Shift: 00:00-08:00 UTC (16:00-00:00 PST), all times posted in UTC
STATE of H1: Observing at 120Mpc
INCOMING OPERATOR: Cheryl
SHIFT SUMMARY:
LOG:
07:12 DCPD saturation
Handing of to Cheryl
TITLE: 02/22 Eve Shift: 00:00-08:00 UTC (16:00-00:00 PST), all times posted in UTC
STATE of H1: Observing at 118Mpc
OUTGOING OPERATOR: Jeff
CURRENT ENVIRONMENT:
SEI_CONF state: WINDY
Wind: 2mph Gusts, 1mph 5min avg
Primary useism: 0.03 μm/s
Secondary useism: 0.39 μm/s
QUICK SUMMARY:
Attached below are plots of the past 2 years of operation of the BOSEMs on the BS, ITMs, ETMs, TMSs, HxTS suspensions. These plots have been zoomed to better show changes and trends in the counts. The purpose of this study was to see if there are BOSEMs which need replacing during the post O3 vent.
Tagging SUS.
I've referenced this new data in a comment to the on-going IIET ticket that tracks this issue: IIET Ticket 10093. If anyone needs a calibration of this data, take any of these "INMON" channels, which are in units of raw ADC counts, which you can convert back to current on the PD (in Amps) with the following inverse response of the sensing PD's electronics chain at "DC" (i.e. at 0 Hz so we can ignore the frequency response of the satellite amp, and approximating the voltage gain of the AA chassis at 1.0 [V_ADC/V_satAmp] and thus dropped from below): 1 [V_ADC] 1 [A_PD] PD current [A] = inmon [ct] * --------------- * -------------- = inmon [ct] * 2.54e-9 [A_PD / ct_ADC] 1638.4 [ct_ADC] 240e3 [V_satAmp] Then, if Stuart Aston (or someone as awesome as Stuart) has the spec on efficiency of the BOSEM PD to get the Watts per Amp, then the spec on the Watts per LED current, then you could map this data directly to "how much has the LED current actually decayed over this time period," to make a sanity check as to whether the calculated estimate matches the expected LED current decay rate.
Adding some more plots showing '2 year trends for BOSEM', which seems to be missing above - TMSX (F2,F3), SRM (LF), SR2 (LF), PRM (LF, RT), ITMY (UL, UR, LL, LR), ITMX (F1,F2,F3, UL, UR, LL, LR).
Note: adding links to Jeff. B's plot which will make it easier to find and look at them: BS , ETMX, ETMY, ITMX, ITMY, MC1, MC2, MC3, PR2, PR3, PRM, SR2, SR3, SRM, TMSX, TMSY,
Additional plots for ITMX and ITMY. H1:SUS-ITMX_R0_OSEMINF_F1_INMON H1:SUS-ITMX_R0_OSEMINF_F2_INMON H1:SUS-ITMX_R0_OSEMINF_F3_INMON H1:SUS-ITMX_R0_OSEMINF_LF_INMON H1:SUS-ITMX_R0_OSEMINF_RT_INMON H1:SUS-ITMX_R0_OSEMINF_SD_INMON H1:SUS-ITMY_R0_OSEMINF_F1_INMON H1:SUS-ITMY_R0_OSEMINF_F2_INMON H1:SUS-ITMY_R0_OSEMINF_F3_INMON H1:SUS-ITMY_R0_OSEMINF_LF_INMON H1:SUS-ITMY_R0_OSEMINF_RT_INMON H1:SUS-ITMY_R0_OSEMINF_SD_INMON
All good. Range is around 117.8Mpc. Wind is a Light Breeze. The microseism is declining. No problems or issues at this time. One short GRB alert (E364938).
TITLE: 02/21 Owl Shift: 08:00-16:00 UTC (00:00-08:00 PST), all times posted in UTC
STATE of H1: Observing at 118Mpc
INCOMING OPERATOR: Jeff
SHIFT SUMMARY:
Hi is locked in Observe, breiefly in EQ, useism is hovering around 0.5um/s.
TITLE: 02/21 Owl Shift: 08:00-16:00 UTC (00:00-08:00 PST), all times posted in UTC
STATE of H1: Observing at 121Mpc
OUTGOING OPERATOR: TJ
CURRENT ENVIRONMENT:
SEI_CONF state: WINDY
Wind: 5mph Gusts, 3mph 5min avg
Primary useism: 0.03 μm/s
Secondary useism: 0.49 μm/s
QUICK SUMMARY: H1 locked in Observe
TITLE: 02/21 Eve Shift: 00:00-08:00 UTC (16:00-00:00 PST), all times posted in UTC
STATE of H1: Observing at 118Mpc
INCOMING OPERATOR: Cheryl
SHIFT SUMMARY: The useism is on the rise, but other than that it has been smooth sailing at 7.5 hour lock.
LOG:
[Sheila, Jenne, Keita]
Since we thought that increasing our DARM offset would improve our sensitivity slightly (alog 55105) we wanted to do one more on/off test using online SRCL FF with the new filter (alog 55189). We took 2 sets of on/off, and then determined that although very slight, there did seem to be a consistent improvement with the higher DARM offset and so put into guardian to relock with the higher DARM offset. However it has been reverted since it seems that we can't hold lock through glitches.
After noting that I couldn't change the SRCL LSC loop's cutoff filter (alog 55207) we moved the DARM offset such that we had 40mA sum on the OMC DCPDs and turned on the iterative SRCL FF filter. Sheila did a brief scan of squeezing angle to see if there was any change to the squeezing angle from the DARM offset change (not that we expect that their should be). We left the squeezing angle 5 degrees different from how it had been, but determined that this was a pretty small change and didn't change it again when going back to check the 20mA DARM offset.
We took 2 sets of on/off spectra to (try to) convince ourselves that it was a real effect that we were seeing, and determined that we could also continue to look at more new configuration spectra after going to Observing. The difference is much more subtle than we were expecting, although it seems to be repeatable.
The first 4 attachements are all the same spectra (2 old nominal config, 2 candidate high DARM offset config) in 4 different zooms. The first attachment is over the full GW band, and the other 3 are zoomed from 10-200 Hz. The second plot is to show a zoom of the small improvement we see, and then the third and fourth plots are just to show that the spectra in each configuration are similar to one another, since they are all overlapped in the second plot. In all of these plots, the pink/red traces are from the nominal DARM offset, and the blue/cyan traces are with the higher DARM offset.
Particularly around 90 Hz, there seems to be a repeatable improvement with the higher DARM offset. There is also an improvement at higher frequencies, perhaps due to smaller influence of any intensity noise or frequency noise on the junk light.
I added a new state to the ISC_LOCK guardian to change the DARM offset just after Lownoise_length_control, and added the new iterative SRCL FF filter to the guardian, and it worked twice to relock. The 5th attachment shows the range calculated by the summary page (after the effect on calibration is taken into account), showing that we seem to have eked out a small improvement. Noteable is that with the slightly different optical gain, in the high DARM offset configuration the control room reported range number (which does not track time dependent calibration corrections) becomes a slight underestimate rather than our usual case of a slight overestimate.
The higher DARM offset does put us much closer to the edge of our ADC range when we have 2 stages of whitening on (as is our nominal configuration). We seem to not be able to survive glitches when running in this state, and have had 2 locklosses after very brief Observing segments with the higher DARM offset, and so have backed out the change by bypassing the new change_darm_offset state and taking out the iterative SRCL FF filter. The 6th figure shows the OMC DCPD inputs before they are filtered to account for the analog whitening, and you can see that just before we lost lock we came extremely close to hitting the ADC limit, although we didn't actually go over 32000 counts. Something that we may consider is what the tradeoff would be if we were to operate in the LowZ transimpedance option for the DCPDs, since that would keep us farther away from the edge.
Sheila suggested that looking at the spectra with ranges just like on the summary pages might help illuminate where we are seeing an improvement.
The first attached plot is of 2 1-hour-long stretches of data, with orange the nominal 20mA OMC DCPD sum, and blue being the candidate higher DARM offset of 40mA OMC DCPD sum. There certainly does seem to be better sensitivity with the higher DARM offset, although as we found last week we can't actually hold the lock through glitches with the higher DARM offset. Calculating the expected range improvement from the median spectra here, we expect to see about a 1.7 Mpc improvement, which is consistent with what we see in the range plot (2nd attachment).
We could consider trying to run at 30mA, although that would take time and would likely result in a minimal improvement. Right now, we're choosing to defer this in favor of measurements to help us actually understand our junk light at the AS port.
J. Kissel, J. Driggers We've been having trouble losing lock during the MOVE_SPOTS portion of the IFO "for the past day or two" (annecdotal), and there were two more instances today at 2020-02-20 23:28 UTC and 2020-02-20 23:49 UTC. These were on the way up from the "unknown" lockloss that Jeff mentions at 23:00 -- though, note: we are blaming today's change in DARM offset for these two lock losses at 21:29 and 23:00 (see LHO aLOG 55204). Anyways -- looking for clues as to what's going on, I remembered the "good catch" that Georgia had back in July 2019 regarding the spots falling off the transmon QPDs (see LHO aLOG 50810), and thought this problem might be that. After conferring with Jenne, she informs me that we're now moving the transmon itself by centering on the B QPDs in order to prevent exactly this. This was done in November 2019 (see LHO aLOG 53362). So it *should* no longer be a problem. But Jenne and I agree it's worth a check to confirm, so I attach screenshots of the QPDs during these two acquisition attempts. As one can see, while the ISC_LOCK guardian state is cooking between 430 (ENGAGE_ASC_FOR_FULL_IFO) and 506 (MOVE_SPOTS), the transmon QPD's centering is well within the +/- 1.0 range, happily centered. NOT IT! OH well...
Remember that if you are wondering about what the history is of locklosses from a certain state, you can very easily obtain reliable information using the lockloss website.
In this case, I changed the state numbers when I rearranged the states on Jan 1st (see 54240, and 54219 for the story of how move spots stopped working during the computer crash and tumblegeddon), we had 3 locklosses from move_spots between then and Feb 6th when Jenne removed the accidental 2 minute wait I'd introduced when moving the states around 54949. We had the two minute wait removed from Feb 6th until Feb 11th, we had 9 locklosses from MOVE_SPOTS durring those 5 days. In the 6 days since I added a 2 minute pause back 55029, we've had 3 locklosses, 1 of which happened yesterday.
(Kyle R, Gerardo M)
Cooling lines were attached and cooling system was tested for leaks, flow was verified. Oil was added per instruction manual to the gear and bearing chambers. Power was applied to the hepta controller.
The hepta pump was started for a few seconds and stopped manually, the ON time was enough to determine that the direction of the motor is correct, and the pump ran smooth. However we did note a red warning light ON, phase sequence, troubleshooting will be done later about what this error light means.
We did a second start, but this time we allowed for the trouble/error to shut the pump OFF, it almost took the same time as when done manually, once again the pump ran smooth but once again showing the error mentioned above.
Cooling lines were shut off and power was turned OFF for the controller.
Issue with "phase sequence" error light solved, it turns out that it was not a phase error at all.
A setting for the voltage monitor relay was tripping the system, the undervoltage was set high, see photo for code shown on relay. Setting for the undervoltage was moved to 181 volts and system did not trip anymore.
