PSL Report FAMIS report:
Laser Status:
Front End Power is 31.95W (should be around 30 W)
70W Output Power is 70.37W
Front End Watch is GREEN
70W Watch is GREEN
PMC:
It has been locked 6 days, 4 hr 11 minutes (should be days/weeks)
Reflected power = 11.9Watts
Transmitted power = 51.87Watts
PowerSum = 63.77Watts.
FSS:
It has been locked for 0 days 23 hr and 22 min (should be days/weeks)
TPD[V] = 4.38V (min 0.9V)
ISS:
The diffracted power is around 2.5%
Last saturation event was 0 days 23 hours and 22 minutes ago (should be days/weeks)
Possible Issues: None
45-day trends for HEPI Pump channels. All signals look fairly steady/flat.
The following CPSs are listed as over threshold (all others OK & all spectra attached):
* This CPS has been listed as noisy the last few weeks.
J. Kissel I've gathered the full, regular calibration measurement suite today -- importantly -- *after* the OMC whitening chassis' filter configuration change (see LHO aLOG 55620). These measurements may end up being the reference measurements for a future calibration model parameter set. Data is committed here /ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/O3/H1/Measurements/FullIFOSensingTFs/ 2020-03-16_H1_DARM_OLGTF_LF_SS_5to1100Hz_15min.xml 2020-03-16_H1_PCALY2DARMTF_LF_SS_5t1100Hz_10min.xml 2020-03-16_H1_PCALY2DARMTF_BB_3min.xml << Contains before (reference) and after (live) OMC whitening filter change. "Before change" measurement started at 2020-03-16 18:30:31 UTC, "after changes" started at 2020-03-16 18:35:14 UTC. /ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/O3/H1/Measurements/FullIFOActuationTFs/ 2020-03-16_H1SUSETMX_L1_iEXC2DARM_8min.xml 2020-03-16_H1SUSETMX_L1_PCAL2DARM_5min.xml 2020-03-16_H1SUSETMX_L2_iEXC2DARM_12min.xml 2020-03-16_H1SUSETMX_L2_PCAL2DARM_6min.xml 2020-03-16_H1SUSETMX_L3_iEXC2DARM_12min.xml 2020-03-16_H1SUSETMX_L3_PCAL2DARM_6min.xml Analysis to come.
Richard, Patrick
Richard notified me that the medm was unresponsive. I logged into the screen session on opslogin and found this error message:
CAS: client cdsdell5.cds.ligo-wa.caltech.edu:57744 disconnected because "No route to host"
Exception in thread Thread-1:
Traceback (most recent call last):
File "/usr/lib/python2.7/threading.py", line 801, in __bootstrap_inner
self.run()
File "/usr/lib/python2.7/threading.py", line 754, in run
self.__target(*self.__args, **self.__kwargs)
File "h1_unifi_ioc.py", line 199, in scan
json_response_data = r.json()['data']
File "/usr/lib/python2.7/dist-packages/requests/models.py", line 850, in json
return complexjson.loads(self.text, **kwargs)
File "/usr/lib/python2.7/json/__init__.py", line 339, in loads
return _default_decoder.decode(s)
File "/usr/lib/python2.7/json/decoder.py", line 364, in decode
obj, end = self.raw_decode(s, idx=_w(s, 0).end())
File "/usr/lib/python2.7/json/decoder.py", line 382, in raw_decode
raise ValueError("No JSON object could be decoded")
ValueError: No JSON object could be decoded
I restarted the code and will look into it.
J. Kissel, J. Driggers More to come, but OMC Whitening Configuration change (using 1 whitening stage instead of 2 whitening stages and a low pass) is in testing now. Quick answer from PCAL to DELTAL EXTERNAL broaband TF shows ~1.0-1.5% frequency dependent addition systematic error with the new configuration. Magenta is nominal configuration (2 whitening stages and a low pass), and red is test configuration. Sweeping now...
I have accepted in SDF the differences that this caused for the digital and analog filters (see screenshots of sdf files).
I have also modified the ISC_LOCK and OMC_LOCK guardians such that when we next acquire lock, it should come back to this state of only 1 stage of analog filtering.
Calibration measurement suite sweeps are complete, and we are back in nominal low noise, but Robert has taken over the IFO for commissioning. We are remaining in this 1 stage of whitening only configuration. We have resolved that it is not prudent to change the compensation filters, and/or update the calibration model parameter set, and we'll therefore just live with this increased systematic error in the low latency h(t). Eventually, after the systematic error is well quantified, we will create a new model parameter set, and re-calibrate the data -- starting at the next observation ready segment today. I'll post the official time as to when we've gone back in to observation ready, so as to clearly define the first observation ready segment with this new change.
The first observation ready segment that includes the above described OMC whitening chassis filter configuration change started at Mar 16 2020 21:18:54 UTC (GPS time 1268428752)
Not that there is anything profound here, but I caught a glitch. This is the first one that I've caught to grab a screenshot of after our change this morning of the OMC DCPD whitening filter configuration.
Note to self: compare the _OUT_DQ of this glitch with other glitches in the old nominal config that I have screenshots of, to (try to) see if these glitches were attenuated due to the new analog configuration.
The summary pages are reporting a significantly reduced range, but I'm not totally sure why.
In the attachment, I've plotted ~an hour of data each for observing times this morning before we changed the whitening configuration, and for an observing segment after we made the change. This is H1:GDS-CALIB_STRAIN, so has time dependent correction factors applied (although, as Jeff points out earlier in this thread those won't fully account for the small frequency dependent change that we've acquired).
Blue is an old nominal (3 analog filters) time, starting at 16 Mar 2020 16:24:40 UTC. Orange is the new nominal (1 analog filter), starting at 16 Mar 2020 22:19:30 UTC. The darker lines are the 50th %-ile, and the shaded regions are the 5th and 95th %-iles. I can't tell much of a difference by eye. Also, when I calculate the range from these median spectra, I get less than a 0.5 Mpc difference. So, I'm not sure why the GDS range on the summary pages is so different now than it was this morning.
I've used measurements of this OMC whitening chassis from (Sunday!) 2019-03-03 to predict the systematic error that transpired as a result of this configuration change. See further discussion in "PART II" of G2000527. Making a *very* long story short, (a) the systematic error incurred on the final DCS C01 calibration amounts to (a frequency dependent, but at maximum) 0.5% and 0.25 deg error at 100 Hz and 50 Hz, respectively. (b) the error arises from - poor modeling of the super-Nyquist response of this chassis in the calibration pipeline, - previously poor understanding of the circuit resulting in a poorly informed fit of the measurements, and finally - the original data set only was taken down to 5 Hz, where the chassis (namely the first and third filters, which are the whitening stages) has response at 1 Hz and thus *any* fit (be it Stefan's original fit to update the compensation filters, or Lilli's fit for super-Nyquist poles) is fundamentally limited by the data. Attached is a comparison of - the ratio between the 2020-03-09 (pre-change) and 2020-03-16 (post-change) broad-band PCAL injections -- and thus the *measured* systematic error incurred by the change, and - the estimated systematic error derived from a re-fit to the original data. Again, for further explanation of how this modeled error estimate was derived, see "PART II" of G2000527. The script the accompanies the analysis for G2000527, from which all plots come, lives in /ligo/svncommon/CalSVN/aligocalibration/trunk/Common/Electronics/H1/Scripts/ fit_OMCDCPDWhiteningChassis_20190304_forG2000527.py
Cheryl noted last night that the seismic system transitioned to earthquake last night without warning. This actually happened twice last night, I think the two attached earthquakes from USGS were the culprits. They were far enough away that we should have gotten some warning (5600 km, the closest seismon will give us early warning for is about 2000 km), but maybe the fact they were out in the middle of the ocean delayed the USGS reports. The later one is still on seismon, and gets a deceptive eq response "score", falling well into the blue region, so a good reminder to be kind of skeptical about what the plot tells you. Still, SEI_ENV caught both earthquakes and transitioned properly, and we stayed locked for both earthquakes.
Second attached plot shows SEI_ENV (in blue) jumping from CALM (index 10) to EARTHQUAKE (index 20), as both earthquakes cross 1000 nm/s on peakmon (in yellow). SEI_CONF (green) goes from WINDY to EARTH_QUAKE both times, in the IFO stayed locked for both earthquakes. It's possible that we could have ridden both of these earthquakes out without doing anything, but these earthquakes were both on the top end of the kind of earthquakes we were able to ride out for O2 before we had an actual earthquake control scheme. Both of these earthquakes would have been a challenge for a person to first realize what was happening, then make the decision to switch the seismic system before the earthquakes had come and gone.
Great news! Well done SEI_ENV state!
- 68.5% duty cycle with a consistent range between 115-118 Mpc, with the exception of ~ 85 Mpc between 08:30-12:20 on Friday. - On Friday, the ETMY violin modes rung up to exceptional levels until lock loss, dropping the range, creating n*500 Hz glitches, and also low frequency scatter (as confirmed by hveto). This is due to the violin guardian begin turned off earlier in the day. This is all documented in aLog 55578 and responses. - Earthquakes and wind were the causes of several lock losses. - H1:LSC-POP_A_LF_OUT_DQ was a round winner every day of this shift and was effective at removing glitches from the "tail" (high SNR). Of all of the channels that picked up high SNR triggers, these triggers were usually extremely loud glitches. The complete DQ Shift documentation is available here.
TITLE: 03/16 Day Shift: 15:00-23:00 UTC (08:00-16:00 PST), all times posted in UTC
STATE of H1: Observing at 117Mpc
OUTGOING OPERATOR: Corey
CURRENT ENVIRONMENT:
SEI_CONF state: WINDY
Wind: 11mph Gusts, 7mph 5min avg
Primary useism: 0.02 μm/s
Secondary useism: 0.28 μm/s
QUICK SUMMARY: Observing for 16.5 hours. No issues to report.
TITLE: 03/16 Eve Shift: 23:00-07:00 UTC (16:00-00:00 PST), all times posted in UTC
STATE of H1: Observing at 118Mpc
INCOMING OPERATOR: Corey
SHIFT SUMMARY: H1 in Observe, SEI in Earthquake, switched on it's own
LOG:
These violin modes cannot be damped without changing the dampig filters: EMTY modes 6, 12 and 20, and ITMX mode 2
For ETMY we are currently damping ETMY mode 11, and mode 18, but mode 12 is only being prevented from ringing up, and is consistantly in DARM, however the bigger issue is that the mode 12 filter crosses the mode 20 peak, so it is currently impossible to damp both modes 12 and 20, thus mode 20 has gone undamped. For ETMY modes 1 and 6, the mode 6 peak is not in the flat top of it's damping filter (though not far from the flat top), so it seems that mode 6 may have shifted down in frequency, and while mode 1 filter seems ok in foton, it's not possibe to damp both modes 1 and 6 at the same time, so both filters are a priority. Currently ITMX mode 2 peak is damped enough to not ring up, but it's filter overlaps other 504Hz peak damping filters, so without a filter change, the mode 2 peak cannot be damped. On ITMX, modes 2, 3, and 4 filters are updated to reduce their interfearance.
attached: 1) ETMY modes 11, 18, 20, 12 (left to right) current, 2) ETMY modes 11, 18, 20, 12 (left to right) new, 3)ITMX modes 2, 3, 4 current, 4)ITMX modes 2, 3, 4 new, 5) ETMY modes 1, 6, current, 6) ETMY modes 1, 6, new, 7) text file, ETMY filters old and new, 8) text file, ITMX filters old and new
H1 in Observe, winds below 20mph, temperatures around 35.6F, aka 2.0C.
TITLE: 03/15 Eve Shift: 23:00-07: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: WINDY
Wind: 19mph Gusts, 13mph 5min avg
Primary useism: 0.09 μm/s
Secondary useism: 0.19 μm/s
QUICK SUMMARY: H1 is locked in Observe
TITLE: 03/15 Day Shift: 15:00-23:00 UTC (08:00-16:00 PST), all times posted in UTC
STATE of H1: Observing at 118Mpc
INCOMING OPERATOR: Cheryl
SHIFT SUMMARY: Long lock acquisition- I expect that the optics were quite misaligned as we have had a pretty long lock strength and some dramatic temperature changes.
LOG:
Had to move both ETMY and TMSY a decent way to get light onto the camera (20 counts on the slider for ETMX Pit and 15 for TMSY Pit).
Had dragged TMSY too far away from it's normal position so that we were not getting enough light on the QPD's and had ALS_Y in fault with message "PZT trig servo not on". I think this is a different problem to the one disrupted by TJ in alog alog 54526 but it may be related.
Keita helped me to get light back on the QPDs:
From sitemap>ALS> End Y overview > QPD_A (FE) and QPD_B (FE), the NSUM should be ~1 for green arms locking, was closer to 0.05. after deciding that the suspensions had bee moved too much, we the QPD NSUMs and the alignment sliders and reverted them to their values at the time of last green arms locking, then did the same for the BIAS on the PZT1 and PZT2 PIT and YAW filters. NSUMS then came up to 1. Rs-adjusted the PZT filter bias numbers to be closer to their outputs and then continued locking.
We have just lost PRMI lock (not total lock) 3 times after I noticed that the FIND_IR TR_Y trace was way higher than it should be attached photo (20 rather than 1). Something strange must have happened so I will try and initial alignment.
DRMI locked straight away after a smooth initial alignment. Unsure what went on before!
At the start of this locking acquisition, there was no light on ALS-Y_QPD_B (NSUM ~ 0.05). ALSY PZT1 and PZT2 were then not adjusted. It can be seen from the top 2 plots of the attached image that they were being significantly adjusted at the start of each green arms locking to maximize QPD light. Keita helped me move the PZT1 and PZT2 values closer to the values which maximized NSUM in the past so in future they should not be so far away.
It's still not clear why there was no light on QPD_B to start with. The values of PZT1 and PZT2 do drift over time to give the maximum light on the QPDs so it's possible that to was just out of range. Maybe these biases should be checked and adjusted more regularly. Tagging ISC
TITLE: 03/15 Eve Shift: 23:00-07:00 UTC (16:00-00:00 PST), all times posted in UTC
STATE of H1: Observing at 114Mpc
INCOMING OPERATOR: Corey
SHIFT SUMMARY: Locked in Observe, range trending downward, no obvious reason
LOG:
After Rhaul loaded his change to the guardian code on Friday 55575, I expected that the guardian would no longer be setting gains to 0. It looks like we have lost lock and relocked since the guardian change was loaded so it should have gone into place. Did you find the gain set to 0?
Here Guardian is setting it to max gain which is 0 for ITMY 12 (nominal is 1200).