Cause is yet unknown. Nothing seemed to ring up on any of the normal FOMs. Just got a sudden Verbal Alarms notification that the HAM6 ISI WD had tripped.
Locked for ~22.5 hours. No issues.
TITLE: 12/16 Owl Shift: 08:00-16:00 UTC (00:00-08:00 PST), all times posted in UTC
STATE of H1: Observing at 69.5545Mpc
OUTGOING OPERATOR: Patrick
CURRENT ENVIRONMENT:
Wind: 10mph Gusts, 8mph 5min avg
Primary useism: 0.04 μm/s
Secondary useism: 0.27 μm/s
QUICK SUMMARY: Locked in Observing for 19+ hours. No issues as of yet.
TITLE: 12/16 Eve Shift: 00:00-08:00 UTC (16:00-00:00 PST), all times posted in UTC STATE of H1: Observing at 73.1215Mpc INCOMING OPERATOR: Travis SHIFT SUMMARY: No changes to note since mid shift summary. LOG: 01:10 UTC Brief notification that HWSX code stopped running. 01:40 UTC Out of observing to run a2l. 01:48 UTC a2l done. No errors reported. Back to observing. 02:04 UTC EY started constantly saturating. 02:44 UTC Out of observing. Changed gain for H1:SUS-ETMY_L2_DAMP_MODE10 from 100 to 0.02. Turned off FM1 and turned on FM9 and FM10 (Settings at Dec 15 2016 08:46:51 UTC from conlog test machine). 4.7kHz mode has come down and saturations have stopped. 02:59 UTC Accepted SDF differences. Back to observing. 03:17 - 03:27 UTC Stepped out of control room. 03:48 UTC Changed phase to damp PI mode 26.
Out of observing twice. Once to run a2l and once to damp 4.7kHz violin mode. PI mode 26 started increasing again. This time changing the phase damped it.
Verbal alarms started alerting that EY was saturating at 02:04 UTC. It has continued since. Attached is a plot of the L3 ESD drive signals for the last 2 hours. They have been growing. Is this the violin mode at 4.7 kHz that Keita and Cheryl were investigating?
02:44 UTC Out of observing. Changed gain for H1:SUS-ETMY_L2_DAMP_MODE10 from 100 to 0.02. Turned off FM1 and turned on FM9 and FM10. 4.7kHz mode has come down and saturations have stopped. 02:59 UTC Back to observing.
Accepted SDF differences attached.
TITLE: 12/16 Eve Shift: 00:00-08:00 UTC (16:00-00:00 PST), all times posted in UTC
STATE of H1: Observing at 71.2515Mpc
OUTGOING OPERATOR: Cheryl
CURRENT ENVIRONMENT:
Wind: 0mph Gusts, 0mph 5min avg
Primary useism: 0.08 μm/s
Secondary useism: 0.20 μm/s
QUICK SUMMARY:
Locked for over 11 hours.
TITLE: 12/15 Day Shift: 16:00-00:00 UTC (08:00-16:00 PST), all times posted in UTC
STATE of H1: Observing at 70.0775Mpc
INCOMING OPERATOR: Patrick
SHIFT SUMMARY:
Activities:
additional activity before I arrived:
Just FYI.
The problem of big violin (or any big high-Q resonances) is mostly the saturation of ADC (OMC DCPD) or DAC (mostly ESD).
To tell if whatever peak is too big or not, measure the OMC DCPD A IN1 and one of the EY ESD output as shown in the attached.
First of all, you see the time series and OMC DCPD is still very far from its ADC ceiling of +-32k, and ESD output is also very far from its ceiling of +-131k, so you don't need to worry about saturations. Note that you need to set the resolution of dataviewer 16384 and observe for at least 10 seconds before making your judgement.
If these things approach the ceiling you need to damp the worst offender, which you identify by looking at the DARM spectrum, or better, by measuring the DCPD_A_IN1 and ESDOUTF_LL_OUT spectrum (second attachment). In this case, even though we already know that it's still safe, you can see that the 4.7kHz mode is the biggest offender. In DCPD it's about 100 cts RMS or 2*sqrt(2)*100 ~300 cts pp, which is totally negligible compared with DC. In ESDOUTF_LL_OUT, it's about 10k cts RMS or ~30k pp.
| Reported by | Magnitude | Location | |
| Terramon | yes | 5.3 |
LAT: -9.9, LON:160.5 |
| USGS | yes | 5.3 | 9.926°S 160.510°E |
| SEISMON | no | - |
Starting time of event on BLRMS: 22:48UTC
Lock status, did H1:
EQ reported by Terramon before it actually arrived: no
A scan of coherences can be found at the following link:
https://ldas-jobs.ligo.caltech.edu/~gabriele.vajente/bruco_lho_1165834817/
Here's my summary
Here is bruco scan on a recent time, 21:30:00 UTC (https://ldas-jobs.ligo-wa.caltech.edu/~youngmin/BruCo/ER10-O2A/H1/Dec15/H1-OMC-DCPD-1165872617-600/).
Now pitch motion is worse, see Fig1. ASC-CHARD_P_SM_DQ, Fig2. ASC-CSOFT_P_OUT_DQ
SUS-ITMY_L2_MASTER_OUT_UR_DQ shows high coherence value between 15~30Hz (Fig3..), and UL/LL/LR look similar.
is it a concern which should be handled ?
There has to be some bonus with this weather.
Looking at a few tasks on the calibration to-do list, I ended up down the rabbit hole. Sadly, it's getting late and will have to return to this tomorrow. Investigations: 1) Working on fixing the PCAL --> CAL-CS_DELTAL_EXTERNAL calibration (see LHO alog 31994). Kiwamu's original script computed a transfer function accounting for time delays caused by the DAQ and the CAL-CS whitening filter. However, this is already taken into account in the clock cycles delay in the CAL-CS model when adding the sensing and actuation paths. Since CAL-CS corrects for the phase delay caused by AA/AI filtering--analog and digital--using the delayed actuation path, then what one really wants is to correct CAL-CS for the magnitude changes of the AA/AI filtering and any CAL-CS whitening on this channel while also correcting the PCAL_RX_PD channel for the effect of AA and that we also have not applied a filter with two poles at 1 Hz (for the free-mass response): DELTAL_EXT W * [Derr/C_foton + A*Dctrl*delay] ---------- = ---------------------------------- PCAL_RX_PD m * f^2 * AA_a * AA_d m DELTAL_EXT [C_real/C_foton] / [W * abs(AA_a * AA_d * uncompensatedOMCpoles)] --- = ------------------------------------------------------------------------------ m PCAL_RX_PD / [f^2 * AA_a * AA_d] Note that the correction factors applied in the numerator of the final equation are really only to be applied to the sensing side. However, the corrections are only at high frequency (low-frequency corrections are simply unity), so the numerator term is dominated by the sensing function. Thus the calibration to be applied is thus: [C_real/C_foton] * [f^2 * AA_a * AA_d] ---------------------------------------------- [W * abs(AA_a * AA_d * uncompensatedOMCpoles)] Unfortunately, this results in a large deviation in phase at higher frequencies (~60 degrees at 1 kHz, see attached figure) while recent measurements using an incorrect calibration filter do not suffer from this large phase deviation. The phase deviation is due to application of the analog and digital AA on the Pcal. Why? 2) I constructed an O2 version of the front-end calibration time delay diagrams based on the model (see attached), but when I look at the GDS correction factors to be applied to the CAL-CS channels, I do not find matching delays. In addition, the values obtained to not mesh with the recent work done at LLO (see LLO alog 29899). This will have to be investigated further tomorrow also.
The AA (analog and digital) had to be taken into for DELTAL_EXT also, including their phase. And also we need a cycle advacne for DELTAL_EXT. Attached plot show the same comparison with the mentioned modifications and we see that the old correction factor was good to use. I have also attached the script used to make the plot. Most of these correction factors are calculated in computeSensing.m of DARM model code, so I just get these factors from there.
Thanks to Shivaraj for pointing out the 7 clock cycles adjusted the actuation path to have consistent phase with the sensing path, but that a signal measured by back CAL-CS_DELTAL_EXTERNAL would have an apparent delay of 117.6 usec (see PDF attachment to original alog entry above) + 61 usec for the delay between OMC user model and CAL-CS user model. The apparent 117.6 usec on the sensing side is a combination of optical response, AA filtering, and uncompensated, super-Nyquist OMC DCPD poles.
The correct math is as follows:
DELTAL_EXT W * [Derr/C_foton + A*Dctrl*delay]
---------- = ----------------------------------
PCAL_RX_PD m * f^2 * AA_a * AA_d
m DELTAL_EXT * [C_foton/C_real] / [W * AA_a * AA_d * OMCpoles * OMCtoCALCSdelay * lightTimeDelay * unknownSensingDelay]
--- = -----------------------------------------------------------------------------------------------------------------------
m sign * PCAL_RX_PD / [f^2 * AA_a * AA_d]
So the calibration transfer function is:
[C_foton/C_real] * f^2
-------------------------------------------------------------------------------------------
[W * sign * uncompensatedOMCpoles * OMCtoCALCSdelay * lightTimeDelay * unknownSensingDelay]
A comparison of the new transfer function is attached below. Note that the magnitude is basically unchanged, but there are changes in phase at the ~5 degree level or less from 10 Hz to 1 kHz. The new transfer function is stored at: /ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/PreER10/H1/Scripts/ControlRoomCalib/pcal2darm_calib.txt.
I also attach a comparison of DTT transfer functions using the old calibration versus the new calibration. The magnitude of the transfer function is basically unchanged. The phase is modestly affected. Unfortunately, since the transfer function wasn't perfect before and it remains imperfect (darn). I saved 2016-11-30_H1_PCAL2DARMTF_4to1200Hz_fasttemplate.xml with the new calibration transfer function.
The broad-band calibration has also been updated. The transfer function is also created by the same script,
/ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/PreER10/H1/Scripts/ControlRoomCalib/H1_pcal2darm_correction.m
The broad band transfer function is stored at: /ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/PreER10/H1/Scripts/ControlRoomCalib/caldeltal_calib.txt
I have updated the most recent DTT session with this changed calibration (see attached): /ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/ER10/H1/Measurements/PCAL/2016-11-30_H1_PCAL2DARMTF_BB_5to1000Hz.xml
Note that the DTT session calibrates the DELTAL_EXTERNAL and PCAL_RX_PD channels separately. The PCAL_RX_PD channel is calibrated by zpk([],[1;1],1,"n"); therefore, the DELTAL_EXTERNAL needs to have all the other calibration applied to it:
[C_foton/C_real]
-------------------------------------------------------------------------------------------
[W * sign * uncompensatedOMCpoles * OMCtoCALCSdelay * lightTimeDelay * unknownSensingDelay]
I've restarted the primary and redundant h(t) pipelines at Hanford at GPS second 1165664237. This restart picks up a software update to gstlal-calibration-1.1.2-v1, which contains a couple of bug fixes:
(1) The h(t) data product should now be identical between the primary and redundant pipelines when time-dependent corrections are applied (i.e., the previously observed numerical roundoff error has been addressed);
(2) The pipeline will now run properly in offline mode, which had become a serious problem after the first bug fix referred to above.
The filters file has also been changed; see this aLOG: https://alog.ligo-wa.caltech.edu/aLOG/index.php?callRep=32389
Note, time-dependent corrections to h(t) (the kappa factors) are still being applied in low latency at Hanford, with the exception of changes to the coupled cavity pole frequency.
The most recent bug fix that prevents the pipeline from hanging does so by adding a 20 second latency to the low-pass-filter used in demodulating the time-dependent calibration factors. This was necessary so the the timestamps on this stream are aligned with the timestamps of the coherence uncertainty channels. Otherwise, the gate element that receives these misaligned streams will lock up, causing the pipeline to hang. However, I have now realized that this introduces minor subtlety -- the coherence gating does not take this additional 20 seconds into account. This introduces the possibility that there could be undesirable jumps in the kappas in C01 frames produced by this version of the code that do not show up in C00 (Similar to what is discussed in https://alog.ligo-wa.caltech.edu/aLOG/index.php?callRep=31911 , which has been addressed in a recent bug fix). I have a different fix to this, for which I will request another release for next Tuesday. Instead of adding a latency to the low-pass filter, I have added queues before the gate, which allow it to run properly. (Note that we never encountered this problem online; the reason is because there are queues that have this effect when running online that were not previously in all the right places for the offline version.)