TITLE: 04/14 Eve Shift: 23:00-07:00 UTC (16:00-00:00 PST), all times posted in UTC
STATE of H1: Observing at 63Mpc
OUTGOING OPERATOR: Jeff
CURRENT ENVIRONMENT:
Wind: 14mph Gusts, 11mph 5min avg
Primary useism: 0.03 μm/s
Secondary useism: 0.13 μm/s
A little breezy, but has been coming down over last 5hrs. useism is also very quiet as well.
QUICK SUMMARY:
Shift Summary: Run A2L check script. Pitch is at or below the reference; Yaw is up to 0.6. Took the opportunity in the afternoon to run the A2L repair script, while LLO was addressing rung up violin modes.
Overall a good day of Observing. No significant problems or issues to report.
Drop out of Observing at 21:20 (14:20) to run A2L repair script. LLO is out of Observing while they damp their violin modes. LHO is back in Observing as of 20:26 (14:26).
J. Kissel I'd collected charge measurement data this past Tuesday (4/11); here's the processed data. Conclusions: - ETMX continues to hover around an un-impactful 10-20 [V], because we have a relative high observing duty cycle. (see attachments 1 & 2) We shut off the ETMX ESD's bias voltage during observation, which means stray charge in the vacuum system is only attracted by the ~10-20 [V] instead of the ~400 [V] in place when we're down or acquiring lock. As long as we continue doing so, we should be fine for the foreseeable future. - ETMY continues to accumulate charge. (see attachments 1, 2, & 3) While we flip the sign of ~400 [V] bias of the ETMY ESD while down and during acquisition, the high observation duty-cycle means it's essentially always one sign. That means we're accumulating charge at a relatively fast rate of 5 [V/month] -- as reported by the *angular* effective bias voltage (see 3rd and 4th attachment). What *really* matters is the relative longitudinal actuation strength -- relative to when we last reset the clock (in this case January) -- and with this we're still in the greener side of the yellow zone (see 5th attachment). As such, my recommendations from last week (LHO aLOG 35366) are now solidified: Just before we vent on May 8th, during last minute preparations as we bring the IFO down, let's - Turn OFF the ETMX ESD bias completely, and leave it OFF - Leave the ETMY bias ON at 400 [V], with the opposite sign as in observation (Negative in NLN, switch to Positive for vent) for the duration of the vent (i.e. until we open back up to the arms)
Locked and Observing for past 24.5 hours. Range is 67.2Mpc. The wind is increasing into the mid teens with gusts over 20 mph, with a corresponding rise in microseism. Ran A2L and Pitch in up to 0.65 and Yaw is below the reference. No other problems noted.
Starting CP3 fill. LLCV enabled. LLCV set to manual control. LLCV set to 50% open. Fill completed in 72 seconds. LLCV set back to 20.0% open. Starting CP4 fill. LLCV enabled. LLCV set to manual control. LLCV set to 70% open. Fill completed in 1984 seconds. TC A did not register fill. LLCV set back to 37.0% open.
Raised CP4 to 38% open.
J. Kissel Over the past few days, I've been filling in the infrastructure I'd installed on Tuesday to use the 7.93 Hz PCAL line to calculate the SRC Detuning Spring frequency, f_s, and Quality Factor, Q_s, as a function of time. The message: the output is functional, the spring frequency is reported as ~7.5 +/- 1.5 and the Q is ~0 +/- 20 (by eye, via StripTool; see 1st attachment). This agrees with results previously shown with reference measurement sweeps (e.g. LHO aLOG 35361), and with prototype results from the gst-lal pipeline (e.g. LHO aLOG 35041). The new sping frequency and Q can be tracked with the following EPICs (16 Hz) channels: H1:CAL-CS_TDEP_F_S_OUTPUT H1:CAL-CS_TDEP_Q_S_OUTPUT Details: ---------- (1) Filling out the infrastructure The signal flow for the SRC detuning goes as follows: DARM_ERR (uncalibrated) and PCALY_RX_PD (calibrated into "m", save for a missing two, 1 Hz poles and "high-frequency" corrections) are fed into two demodulators, respectively (with the PCAL signal filtered to multiply in the missing 1 Hz poles). The complex ratio of these demodulator output is then passed into a calculation block that follows math from section 2.4 of T1700106, absorbing reference DARM loop model parameters calculated at 7.93 Hz (stored as EPICs records), and other pre-calculated time-dependent correction factors, kappa_TST, kappa_PU, kappa_C, and f_c. For most of the infrastructure, I mostly copied pre-existing filters, - a two, 1 Hz poles filter to finalize the calibration of the PCALY RXPD signal into [m] of DARM in the H1:CAL-CS_TDEP_PCALY_LINE4_LINE_CALIB bank, designed as ":1,1" zpk([],[1;1],-1,"n") - all demodulators get a 7.93 Hz, 6th order band pass in their H1:CAL-CS_TDEP_PCALY_LINE4_[EXT,PCAL,ERR]_DEMOD_SIG banks, designed as "BP7.93" butter("BandPass",6,7.7,8.1) (different from the other band-passes only in frequency and pass-band, for obvious reasons) - all demodulators get a 1 [ct] CLK, SIN and COS GAIN just so these digital demodulators spit out a synchronized clock signal against which the generating oscillators are compared - all demodulators get a 10 sec low-pass on their I and Q demodulated signals in the H1:CAL-CS_TDEP_PCALY_LINE4_[EXT,PCAL,ERR]_DEMOD_[I,Q] banks, designed as "LP10s" butter("LowPass",4,0.1) - the final output of the spring frequency and Q calculations get a 128 sec 4th order butterworth low-pass in the H1:CAL-CS_TDEP_[F_S,Q_S] bans, designed as "LP128s" butter("LowPass",4,0.0078125) For the demodulation phase of the H1:CAL-CS_TDEP_PCALY_LINE4_PCAL_DEMOD_PHASE, I resurrected the script used for the other line frequencies, /ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/ER10/H1/Scripts/PCAL/getPcalCorrForCALCSdemod.m updating it to use the modern DARM model infrastructure and to calculate a value for the 7.93 Hz line. It has subsequently been committed. Recall that this phase is the remaining "high-frequency" corrections to the PCAL RXPD signal that are the result of AA filters and delays in the signal path that are, by convention alone, not included in the ":1,1" calibration filter mentioned above. Finally, I reproduced the calibration line frequency in the EPICs record H1:CAL-CS_TDEP_D2N_SPRING_PCAL_FREQ which is yet another copy of that's buried in the TDEP_D2N_SPRING corner of the h1calcs.mdl simulink model. If I were to make this model again, I would pipe the first copy of these records in the H1:CAL-CS_TDEP_${LINE_NAME}_COMPARISON_OSC_FREQ out and up and through the model over to where ever else they're needed. All EPICs changes (including turning on all new filters) have been accepted into the SDF system. (2) Re-drawing the MEDM infrastructre The TDEP overview has been begging for an upgrade for quite some time. With the new version, I've - (hopefully) created a clear signal flow blocking out the order of operations - added some (hopefully) helpful math and diagrams, - buried the math and calculations in sub-sub blocks - showed as many EPICs records as possible to help the user walk through the math and debug - reduced the precision on the EPICs records that are reproductions of the DARM loop model for cleanliness (and 5 sig-figs aren't really needed for this kind of display) - displayed the "final answer" with all the calculated time dependent correction factors in one obvious block in the middle The following screens (some brand new) have been committed to the svn repo: /opt/rtcds/userapps/release/cal/common/medm CAL_CS_TDEP_OVERVIEW.adl CAL_CS_TDEP_F_C_OVERVIEW.adl CAL_CS_TDEP_F_S_OVERVIEW.adl CAL_CS_TDEP_KAPPA_PU_OVERVIEW.adl CAL_CS_TDEP_KAPPA_TST_OVERVIEW.adl CAL_CS_TDEP_OVERVIEW.adl (3) Still to do: - You may notice that there are several "FIX ME"s where EPICs records should be on the MEDM screens. These EPICs records don't exist yet because I hadn't drawn a clearly flowing MEDM screen and/or hadn't decided which EPICs records would be necessary. Now that I have a good idea of what helps the reader (and the expert debug potential problems) I'll add these records to the simulink model and reboot next Tuesday (Apr 18). - Everyone is still suspicious of the calculation of the Q. Of course a negative Q is unphysical, and when the calculation produces such a result, it's likely due to noise. We need to further investigate / improve the algorithm such that we get only physical results if we ever want to use this to do live corrections to the h(t) data stream. Stay tuned on that.
J. Kissel, A. Viets The corresponding low-latency pipeline products are found in the channels Spring Frequency H1:GDS-CALIB_F_S (Inverse) Quality Factor H1:GDS-CALIB_SRC_Q_INVERSE (Sorry, the front-end channels are the inverse of the gst-lal channels for the Q... I'll fix this on Tuesday, 4/18 with the addition of the EPICs records.) These were installed / created after the upgrade to gst-lal release 1.1.5 on Tuesday Apr 11 2017 (see LHO aLOG 35476).
No uncommitted SVN files notes.
TITLE: 04/14 Owl Shift: 07:00-15:00 UTC (00:00-08:00 PST), all times posted in UTC
STATE of H1: Observing at 68Mpc
INCOMING OPERATOR: Jeff
SHIFT SUMMARY:
LOG:
Quiet shift, lock just rolled over 20 hours and nothing much is happening.
TITLE: 04/14 Eve Shift: 23:00-07:00 UTC (16:00-00:00 PST), all times posted in UTC
STATE of H1: Observing at 69Mpc
INCOMING OPERATOR: Jim
SHIFT SUMMARY: Locked for the entire shift and 12.5 hours total. No issues.
LOG: None.
Locked for 8.5 hours. Nothing to report.
While LLO was down:
1) We shook the input beam tube at low frequencies: no significant coupling below 8 Hz was found.
2) Tapped on top of a lot of chambers to see if falling metal oxide dust might produce fast transients like blip glitches: some transients were produced, more analysis to come.
3) We shook ISCT1 at 12.5 Hz (about the sway resonance of the table) and injected at an amplitude that produced clear scattering harmonic peaks in the 200 Hz region (consistent with motion amplitude of about 1 micron). This required about 40 times background velocity (see plot). We found dumped beams that were bight in the viewer and blocked them with black glass while watching the scattering peaks. The scattering harmonics seemed to mostly go away when we blocked a particular beam hitting one of the razor blade dumps (see figure). The razor blade dump seems to dominate the scattering and may not be quite good enough. We should replace it with a black glass dump with the reflected beam dumped on a razor blade dump.
Robert, Jenne, Vaishali, Heather
From 0:04:30-0:05:30 UTC, a Ducati motorcycle could be heard pulling out from the beam tube enclosure section near the control room. As a reminder to all motorcyclists on site, according to the list of NOT Acceptable activities in T1500425, while we are in Observing there should be "no running motorcycle engines closer than the Staging Building."
Mine was in the garage all day....so wasn't me.
Mea culpa. Thx Travis, and good discrimination in L. Twin vs. Inline 4.
Everything looks fine here.
If you happen to be on one of the Debian machines, I've been working on the Python scripts for this task. They can be launched from the bottom two buttons (BSC CPS Python & HAM CPS Python) on the OPS>>WEEKLIES screen. They now plot properly calibrated spectra for the CPS with sensor noise specs and save images of the spectra directly to your Desktop folder. The script also looks at the high frequency ASD average (over 80-120 hz) and will say on the xterm window which sensors (if any) are "out of spec". Sadly, these scripts won't work on the Ubuntu machines, because their scipy.signal libraries are too old and don't include welch. Maybe if operators find this workflow easier (push 2 buttons, look at plots, check xterm, and attach images to alog, done) we can convince Hugh to change the FAMIS task.
[Vaishali, JimW, Jenne]
During maintenance, while no one needed the IMC, we tried out our new L2A decoupling filter for MC2. Recall that Jim found that it would be helpful in alog 35330, and we measured and fit TFs for it in alog 35397.
We found that (a) the pre-existing L2A decoupling was in fact worse than doing nothing at all, and (b) that our new filter works well.
In the attached screenshot, the upper left corner is the Foton Bode plot of our decoupling filter. In the other 3 DTT panels we have the coherence and transfer functions of 3 different MC2 L2A configurations. For these measurements, the IMC was unlocked, but MC2 still aligned. The red traces in all panels are with no L2A decoupling at all. The blue traces are with the old L2A "decoupling" gain. That was a flat gain, and clearly was making things worse than doing nothing at all, over a pretty broad frequency range. The green traces are with our new L2A decoupling filter on, and we win almost 20dB of isolation below a few hundred mHz.
We have accepted the new L2A settings for MC2 in the safe and observe SDF files, so they should always be on now.
I've looked at the coherence between MC2 M1 length drive and the two pitch witnesses (MC2 Trans qpd and MC2 M1 Pit) during locks before and after the install of the new L2P feedforward, and things look better. Attached plot shows the coherence between MC2 M1 L and MC2Trans (top plot, blue is before, red after) and MC2 M1 L and MC2 M1 P (bottom plot, blue is before, red after). Below .1 hz the coherence is much better, which should help for wind and earthquakes, which is what I was looking at originally anyways. Above .1hz the coherence is pretty much unchanged, not sure why, maybe the motion is dominated by the table motion at those frequencies?
Always useful to actually post promised plots...