Locked 20h40. All quiet so far with range up to 120Mpc

TITLE: 12/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: Camilla
SHIFT SUMMARY: locked in Observe

LOG:

• 09:13 UTC - H0:VAC-EY_Y6_PT427_ERROR went into error
• 13:49 UTC - airplane heard in the CR
• 14:23 UTC - H0:VAC-EX_X6_PT527_ERROR went into error
• Violin mode damping: 08:00 to 15:30 UTC, only gain change tonight is ITMX mode 8, nominal gain = -4, currently at -20 as a test
  • ITMX modes 7 and 8, 7 is currently at nominal, 8 is at -20 (relocked with -4, and this has not changed)
  • ETMX mode 6, this mode is paired with ETMY modes 1 and 6
    • the damping filter width was 0.1Hz, and I reduced the width to 0.02Hz (which is larger than ETMY mode 6, at 0.004Hz)
    • this filter is saved, and is ready to be loaded on ETMX mode 6, at the next lockloss
    • with the current filter, it's not possible to damp ETMX mode 6 and ETMY mode 6 at the same time
    • ETMY mode 6 is at it's nominal gain of 0, and will need to stay off, until the new filter is loaded
  • ETMY modes 1 and 6, no changes, just testing tonight
    • ETMY mode 1 damping filter width is 0.006Hz, and may benefit from being reduced to 0.004Hz, like mode 6, but I did not make any changes tonight

Attachments:

1. left:ETMY mode 6 damping filter bode plot, right: ETMX mode 6 damping filter bode plot, black = previous filter, red = new filter
2. power spectra, showing ETMY modes 1 and 6
3. power spectra, showing ETMX modes 1 and 6

H1 locked in Observe

CURRENT ENVIRONMENT:
    SEI_CONF state: USEISM
    Wind: 10mph Gusts, 7mph 5min avg
    Primary useism: 0.03 μm/s
    Secondary useism: 0.72 μm/s

TITLE: 12/21 Owl Shift: 08:00-16:00 UTC (00:00-08:00 PST), all times posted in UTC
STATE of H1: Observing at 118Mpc
OUTGOING OPERATOR: Ed
CURRENT ENVIRONMENT:
    SEI_CONF state: USEISM
    Wind: 11mph Gusts, 9mph 5min avg
    Primary useism: 0.03 μm/s
    Secondary useism: 0.74 μm/s
QUICK SUMMARY: locked in Observe

TITLE: 12/21 Eve Shift: 00:00-08:00 UTC (16:00-00:00 PST), all times posted in UTC
STATE of H1: Observing at 117Mpc
INCOMING OPERATOR: Cheryl
SHIFT SUMMARY:

• Aside from 2 EX saturations and a couple of non-descript glitches, the shift was quiet and the range was quite good
• It's a bit windy and uSeism is still quite high
• previously elevated fundamental violin modes have since rung down
• Handing off to Cheryl

LOG:

I have been monitoring PT199 (CS instrument air pressure) periodically and it seems to be stuck at 84 psi since ~1900 hrs. local even though the MEDM time-of-day is updating.  Hmm...this is concievable but probably too good to be true.  There are known leaks in several of the pipe (copper) fittings in the LVEA so it is expected that the pressure will bleed off, albeit at a slow rate - but not this slowly. 

Evening Operator - could you please trend this signal so as to verify that it is updating? 

TITLE: 12/21 Eve Shift: 00:00-08:00 UTC (16:00-00:00 PST), all times posted in UTC
STATE of H1: Observing at 116Mpc
OUTGOING OPERATOR: Camilla
CURRENT ENVIRONMENT:
    SEI_CONF state: USEISM
    Wind: 10mph Gusts, 9mph 5min avg
    Primary useism: 0.04 μm/s
    Secondary useism: 0.74 μm/s
QUICK SUMMARY:

00:27 Intention bit dropped out of Observing

• Squeezer became unlocked
  • after 2 automated attempts it relocked itself
  • going to utilize Automatic Operation of GRD_IFO node in case his happens again so H1 can "right itself"
    • I don't plan to leave it this way after my shift...maybe I could/should?

TITLE: 12/20 Day Shift: 16:00-00:00 UTC (08:00-16:00 PST), all times posted in UTC
STATE of H1: Observing at 119Mpc
INCOMING OPERATOR: Ed
SHIFT SUMMARY:  Violin modes should be watched as some rang up a little over last lockloss. Locked 44mins
LOG:

• 16:34 Tyler and Scott to MY then MX (will be craning at MX)
• 17:43 Robert to EY for PEM injection and filming.
• 17:59 IFO to Commisoning for Robert's EY work.
• 18:23 Lockloss and tripped watchdogs at ETMY. Caused by commissioning.
  • Robert was sending an excitation to channel H1:ISI-ETMY_ST2_FF12_RX_EXCMON that was too big. You can see this in (lockloss20191220 image attached) where the sus watchdogs normally trip around 300,000. The excitation tried to push them well above this level.
• 18:28 VE corner station Instrument error received: Called Chandra, this was caused by Kyle adjusting some equipment..
• 18:30 Untripped the ISI ETMY watchdogs with Jeff K
• 18:35 Robert turns off his excitation which we've realized is still on.
• 18:37 Watchdogs tripped again as Robert was putting bellows back on, this wasn't completed and will now be done in a future Tuesday maintenance (see alog 54011)
• 18:44 Watchdogs untripped. T240 was already green so system has been stable for >2min and locking begins!
  • The INCREASE_FLASHES Guardian state again did a great job, bringing to Y arm flashes from 0 to 0.95!! this took ~6 minutes as can be seen by the orange trace in attached plot)
• 19:52 NLN
  • Reverted the SDF diff to keep CPS DIFF off as in Jenne's alog 53973 (screenshot attached)
• 19:57 OBSERVING
• 20:35 Into Commisioning as Squeezer unlocks.
  • Daniel and Keita adjust some offsets
• 21:10 Observing again at ~119Mpc ...I think this is the best we've seen in a while, well done squeezer!!!!!
•   Lockloss no obvious reason why but useism currently above 90th percentile.
  • During locking acquisition we had a lockloss alongside BS stage 2 Watchdog trip. (22:18 UTC)
• 23:18 NLN and OBSERVING. Accepted the same SDF diff as at 19:52 UTC
• 23:22 Kyle and Chandra to MY
• 23:36 Vlad to optics lab
• 23:59 I visited broken PSL chiller in the mechanical room which is being tested. It is still running fine.

A lot has happened since my last alog on this topic.

I presented a little presentation to the Pcal team some weeks ago, where I claimed I was able to remove all observable temperature dependence in the the Pcal Calibration tools. Unfortunately this result is valid only for the "old" style detectors, which feature a board that only has a photodiode and no other on-board electronics.

Since the WSL as been returned here, and is effectively a spare until a replacement is put together, I have been using it to investigate temperature dependence of the in-use-boards, which have a number of extra circuitry components that get really quite hot when these things are being used... Just turning on the instruments heats up the circuit board by 6.5 degC!

I will summarise contributions to observed temperature dependence as I currently know it, in order of importance (in units of HOPs/degC = hundredths of a percent/degC):

• Geometric hole expansion discussed in presentation
  • ~3-4 HOPs/degC, dependant on individual sphere
    • Rick Savage is working on a design to restrict the PD FOV to not be sensitive to this (at the cost of total observed power)
• Cross coupling of voltage from the temperature sensor to the output.
  • V_out_extra ~= 1.4 * 10^-3 V_temp . This is negligible in normal use.
  • But if FOV is restricted and incident power is 20x less, then this constitutes 1 HOP/degC
• Unknown circuit board dependence (not PD or main resistor resistivity change)
  • Seen as what is needed to explain all remaining responsivity not mentioned in the other categories:
  • 2.8 * 10^-5 V / degC (at nominal voltage of 3V) - not currently sure if it depends on voltage seen - will investigate this next.
  • ~= 0.84 HOPs/degC
  • This same dependance was seen on multiple boards of the same version of the circuit boards used in all the standards.
  • In case you are wondering: no, I didn't produce this factor just to make the plot below have zero temp. dependence.
    • I extracted this relationship from an older experiment in the presentation which I re-examined with renewed confidence in the temperature sensors (the experiment with a set current source into a board that has no PD)
• Resistance change in resistor that converts current from PD to Voltage
  • 0.1 HOPs/degC
• PD Dark current
  • ~0.01 HOPs/degC

Putting all of these aspects together, both experimentally (with reduced FOV) and numerically (subtracting known temperature dependent factors), I managed to reduce observed temperature dependence in the WSL from ~5.5 HOPs/degC (Resp_vs_Temp_Intial.png) to -0.14 HOPs/degC (Resp_vs_Temp_Final.png). There is a small change left over that goes the opposite way. I suspect this is an effective increase in responsivity due to the height dimension of the hole changing (see the presentation for an illustration).

Cheryl, Rahul

Last Tuesday (12/17/2019) changes were made to the monitor filters for ETMY mode 18, 1000.298Hz (which is very close to ETMY mode 20, 1000.301Hz). We adjusted the band pass filter (while making sure that the bandwidth is not changed) for the same.  After making the changes we clicked Load (in the violin mode medem screen). However, the next day Dave found that CDS (H1CDS_03OVERVIEW_DETAIL_CUST.adl) was complaining about the new values. To make this go away and also to make sure that the new settings were properly accepted by the Guardian, we had to click LoadCoefficients. 

CDS was also complaing (diff H1SUSPROC_126072365, see fig attached) about some difference in ETMY mode 12. However, we couldnt find any difference and later Dave just made it go away.

We also adjusted the gain for damping the follow modes ETMY: 12, 18 and 20 and/or to speed up the damping, which worked. Later in the evening Cheryl applied zero gain to some of the other modes in ETMY (filter bank 2, I will check with Cheryl on the mode number and then update this alog) since the monitor levels were low (and it seems like they were feeding noise into the IFO).

In the last week or so, several other changes have also been made in the violin mode damping settings (basically Guardian values were changed), along with adjusting the monitor filters. This is still ongoing, however I am giving a small summary (of modes which worked and the gains were modified in guardian) which will help us keep a track of things.

ETMY mode 12, 18, 20, gain = 0.5

ETMY mode 11, gain = 50

ETMY mode 6, gain = 0

ITMX mode 8, gain = -4, fliter change (moved it away from mode 7)

The problem reported by Cheryl from the owl shift (alog 54008) is the same thing as we experienced before (alog 53965), 3MHz beat note degrades as SQZ ASC tilts ZMs, eventually ASC runs away, SQZ guardian resets ASC, beat note goes back to normal, and it repeats it many, many times (1st attachment). We had the same problem in the afternoon.

We first tried to relieve the ASC output by moving ZM2 YAW manually, but the runaway behavior only got faster.

Then we checked the dark offset of ASC-AS_A_RF42 and AS_B for all I and Q channels after closing the beam diverter and some of them were 20 to 30, which is significant as the sum channel is only 150-160 counts when the beam diverter is open. Usually an offset of 20 to 30 counts is not huge, but in this case the signal is very small, therefore we want to monitor this periodically.

After adjusting this, the running away behavior was gone. 2nd and 3rd attachment shows the sdf diff (except for ZM1 P offset because it was unmonitored, we changed the setting to monitor it).

Daniel also found that the NLG was somewhat lower than before.  H1:SQZ-SHG_LAUNCH_DC_POWERMON keeps creeping up (6.9 today VS 5.2 on Dec/17) though OPO TRANS is still 1.0, and CLF REFL 6MHz monitor was ~ -30.5 instead of -29.5-ish. Daniel changed the OPO temperature (H1:SQZ-OPO_TEC_SETTEMP) from 33.246 to 33.214 degree Celsius to gain 1dB or so for H1:SQZ-CLF_REFL_RF6_DEMOD_RFMON. That doesn't mean that degradation is OK, we have to keep monitoring.

Cody Barschaw, Julian Carlin, Evan Goetz, Jack Heinzel, Sandra Hughey, Shivaraj Kandhasamy, Andrew Matas, Hannah Middleton, Lucas Mueller, Ansel Neunzert, Jay Tasson, Andres Vargas

Summary:
We have flagged and identified as many narrow spectral artifacts in the O3a averaged spectrum using ASDs of coherence length with 7200 seconds. From this flagged list, we have identified non-astrophysical lines and combs in a "vetted" list and maintain a list of unidentified lines. Overall, as reported in other aLOGs, the H1 data is much cleaner of narrow spectral artifacts than in O1 or O2. As always, nice work to commissioners and stay vigilant!

We highlight a few issues worth further investigation that impact both H1 and L1 spectra: 1) calibration line non-linearities; 2) apparent calibration line mixing with loud violin resonances; 3) weird non-physical "anti-line" features that dip below the shot noise sensitivity around certain violin resonances; 4) ASC dither lines are loud with significant sidebands. Item 3 may be due to mismatch in violin notch filtering or because of some issues damping the resonance, and item 4 is only an issue at H1.

See the linked files: Vetted list and Unidentifed list

Details:
Using standard CW tools in LALSuite, we generated 7200 s long SFTs from the C00 calibrated h(t) frames, only selecting observing times using H1:DMT-ANALYSIS_READY data from April 1 - Sept. 30. The SFTs were then averaged using noise weighting (a running median of the noise variance on a per-SFT basis) in order to generate an O3a average ASD. This provides rejection of high noise SFTs, fine frequency resolution, and a large number of averages in order to reveal narrow spectral artifacts that may remain hidden in a normal ASD.

Our team then divided the data for both H1 and L1 into broad frequency bands to flag all narrow spectral artifacts, attempting to identify combs and lines where possible. Those identified as non-astrophysical go into the vetted list, and everything else remains in the unidentified list.

Highlights:
- Calibration lines: 15.1, 15.6, 16.4, 16.7, 17.1, 17.6, 35.9, 36.7, 410.3, 1001.3, 1083.7, 1153.1, 1501.3 Hz
These are fairly obvious since they are on tenth Hz frequencies. Simple aLOG search was all that was needed. Calibration lines have been moved, but the run-average spectra see all of them. Also worth noting is that the 1153.1 Hz "cancelling" line is the same frequency as a roaming L1 line. Was this chosen on purpose? Generally we don't like to make coherent lines between detectors, so I'd advise moving this to a different frequency.

- Calibration line non-linearities occuring at 2f, f_1+f_2, or f_1-f_2: (27 lines identified in H1 so far)
Not as obvious, but has been identified at H1 as a problem (see LHO aLOG 48161) and also shows up at L1.

- Calibration line mixing with loud violin harmonics (at least 278 lines, see linked files above)
Identified at H1 (see see LHO aLOG 48161 and LHO aLOG 49281) and seen also at L1 by their spacing in concordance with the calibration line spacings (see, for example figure 1). It appears this problem is more of an issue with the violins are rung up, but they may also be present at a lower level even if the violins are not excited. Damping the violins and/or reducing calibration line amplitudes may help, but neither may be a good solution for a variety of reasons.

- Non-physical "anti-line" features in the spectra (13 features identified in H1)
These can be seen in spectra like in Figure 2 and are clearly dipping below the shot noise sensitivity of the detector around certain violin harmonics. It is not caused by the noise weighting of the SFTs; changing to a simple arithmetic average shows the same features. I speculate that this could be due to some kind of notch filter mismatch around the violin resonances or it could be due to a problem in the violin mode damping. Maybe there is a better idea for the cause. This may have escaped notice before because it's not seen in the summary page spectra or control room spectra. Other ideas?

- ASC dither lines: 18.37, 19.653, 20.131, 20.789, 21.9, 22.347 Hz
Only an issue in H1 since the L1 dither lines are all below 10 Hz and we don't yet see any issue with noise above 10 Hz caused by them. These lines are loud (some are larger in the h(t) ASD than the calibration lines) and have fairly substantial sidebands, see figure 3. It would be great if the SNR can be turned down on these lines and/or moved. I'm sure there is good reason for being where they are and as loud as they are. Maybe the commissioners could have a look at this.

Other details can be found on the main wiki page for organizing this effort, and recent presentation slides in the DCC.

We will have to check for any new lines in cleaned data. Additions or revisions can always be made in the git repo containing these lists.