TIME: 16:39UTC, 9:39PT
STATE OF THE IFO: Unlocked
EXPLANATION: The IFO did lock and made it past ENGAGE_ASC_PART3, but then another earthquake arrived, and broke the lock, and ground motion is high.
Video0's striptools have been modified, and now they have a red background, due to the channels DHARD_Y and DHARD_P.
When making a change to a screen, it's important to test it in all situations. Maybe this addition worked quite well during our long lock, but right now with earthquakes and relocking, the change to the striptools have rendered them unusable.
FOM image attached.
This is a symptom of a rung up roll mode. Cheryl spent the last few minutes damping it (ITMY) and now these displays are back to looking normal.
Following Sheila's entry (alog 21708), I've tried to figure out which locklosses where due to Earthquakes during the week of Sep 10th (ER8).
Out of the 22 locklosses seen this week, I've counted 6 locklosses due to EQs. Sheila counted 9, I'll double check my conclusions with her.
EQ | Location | Ground Velocity at LHO | Status | Lock Loss time |
5.9 | Alaska | 5.99 microns/s | Lockloss | 1125916264.5625 |
5.2 | Mexico | 1.08 microns/s | Lockloss | 1126042739.0625 |
5.7 | New Zealand | 1.16 microns/s | Lockloss | 1126127070.8125 |
6.3 | Indonesia | 3.20 microns/s | Lockloss | 1126427496.4375 |
6.1 | Papua New Guinea | 2.90 microns/s | Lockloss | 1126448905.3125 |
8.3 | Chile | 170 microns/s | Lockloss + SEI trip | 1126480080.5625 |
The ground velocities represent the maximum amplitude predicted by the Seismon software. These predictions could be inaccurate by a few percents.
Six examples is not enough to do some accurate statistics, but the behavior observed during ER8 doesn't contradict the conclusions drawn from ER7 (see DCC T1500230). My conclusions were:
Note: among the 16 remaining locklosses, some of them are due to a high ground motion, but EQ is not the cause (wind? human activity?).
TITLE: 9/24 OWL Shift: 7:00-15:00UTC (00:00-8:00PDT), all times posted in UTC
STATE OF H1: Unlocked. Waiting out Earthquake.
SUPPORT: None (& not needed)
SHIFT SUMMARY:
More action during this shift with the end of the long lock stretch (no obvious reason for lockloss by Jim, although he said he mentioned 45MHz issues for end of that lock). Went through an alignment & then had a 4hr lock, and then had another Unknown lockloss. Then while trying to bring back H1 had some issues (noted earlier). And now handing off unlocked H1 with seismic ringing down from Vancouver EQ.
Shift Activities:
12:35 H1 Lockloss (nothing obvious: seismic quiet, and all the H1 strip tools showed nothing obvious before lockloss)
During Lock Acquisition, during 2nd locking attempt, had issues with ALS XARM:
1) You can either misalign SRM using the SUS_SRM guardian, or use a new state in ALIGN_IFO called SET_SUS_FOR_PRMI_W_ALS.
2) Request OFFLOAD_PRMI from the DRMI guardian.
3) Once PRMI locks adjust PRM and BS alignment until you get about 80 counts on POP90 and 50 counts on POP18.
4)Realign SRM by undoing whatever change you made in step 1.
5) Request DRMI_1F_OFFFLOADED from the ISC_DRMI guardian.
Waited for DRMI to lock again. Several times I had a Verbal Alarm which sounded like "Slip Mode"? What do we do about this? It looked ugly on AS-AIR video. Had "Slip Mode" alarms a few times while waiting for DRMI, and then the Vancouver earthquake arrived!
After recovering ISIs and ETMy, took ISC_LOCK to LOCKING_ALS, but haven't made it there yet (the guardian log keeps saying "Waiting for arms to settle"). The 0.03-0.1Hz seismic band was ramping down, but flattened out at 0.3um/s (which is over an order of magnitude from normal quiet levels). Perhaps we should wait for this to come down to normal levels.
At 13:54 Verbal Alarm posted Earthquake.
Looks like Magnitude 5.5 from Vancouver Island at 13:49. (Terramon did not alert us to this one.) 0.03-0.1hz seismic has increased 3 orders of magnitude (!) and 0.1-0.3Hz seismic has increased 2 orders of magnitude.
ETMy & all BSC ISIs have Watchdogs have tripped.
H1 had a ~46Hr lock that ended toward the end of Jim's shift. He noted DRMI was looking pretty ugly. I waited DRMI a little, but eventually gave Sheila's new PRMI procedure a try, but POP18 & POP90 remained at a flat zero and PRMI never locked. So went through the Initial Alignment procedure (I went slow & took notes since this is something we do rarely.). Alignment was and getting to NOMINAL_LOW_NOISE were straightforward.
Reason for Lockloss?
I saw nothing obvious from seismic signals when I walked in, everything quiet! Jim mentioned ASAir/OMC video spots took an odd move prior to lockloss. H1 was trending down over 6hrs before the lockloss, and Jim mentioned this could be the RF45 issue which has been coming up.
Initial Alignment Notes:
Accidental Slip Out Of Observation Mode: 9:04:15 - 9:04:33
While making the entry above and updating the Initial Alignment wiki, I wanted to look at a pull-down of an ISC Guardian node. Clicking on the ALS_YARM node pull-down dropped H1 out of Observation & into Commissioning. (after cursing, I quickly checked things and took H1 back to Observation)
(I didn't bother touching the Observatory Mode button during this short slip.)
TITLE: 9/24 OWL Shift: 7:00-15:00UTC (00:00-8:00PDT), all times posted in UTC
STATE OF H1: H1 in lock acquisition after ~45hr lock.
OUTGOING OPERATOR: Jim W.
SUPPORT: None
QUICK SUMMARY: DRMI looked ugly. Tried Sheila's new procedure for PRMI, but POP90 & POP18 were flat at zero. Proceeding with an Intial Alignment.
Title: 9/23 Eve Shift: 23:00-7:00UTC
State of H1: Re-locking after loss of 46 hr lock
Support: Most of the commissioning crew was here when I arrived, Jenne held out till 6 UTC
Shift Summary: Mostly quiet untill lockloss at 6:30
Activity Log:
23:00 ish JeffK doing PCAL measurements
1:00 ish I load new code for event triggers
5:00 ish RFAM starts acting up, range starts trending down more
6:30 Lock loss, no obvious cause, I start trying to recover
Durring yesterday's maintence window I made some excitations on both transmons to investigate the noise peaks around 75-85 Hz. The main conculsions are that the coupling from TMS X L drive to DARM is bilinear while the coupling from TMSY is linear, and it seems likely that TMSX motion accounts for some significant part of the unexplained noise in the H1 noise budget (21162) even at frequencies where there is no coherence between DARM and the X QPDs.
In the first attached screen shot you can see the DARM spectra durring some of my excitations in the upper panel and TMS QPD spectra in the lower panel. In the QPD spectra, you can see that the X end QPDs have some excess noise compared to Y. These spectra were from a time when I had a TMSX longitudnal injection at 75 Hz (this is the same time as the yellow DARM trace). There is a narrow line in the X QPD spectra, but in the DARM spectrum the line that appears is about 1 Hz wide, indicating there is some bilinear coupling. The excitation either did not show up or was very small in the QPD sums.
I also made a few injections into TMSY longitudnal which produced only narrow lines in DARM, both X and Y injections are shown at 100 Hz for comparison.
We can attempt to make projections of this noise into DARM using the ratio or the injection line peaks or the rms of the injection peaks to estimte the coupling. I drove longitudnally and the only good witness sensor we have is an angular sensor. If the coupling mechanism is something like scatter off the QPDs that goes directly back into the arm, DARM would be mostly sensitive to the longitudnal TMS motion and if the QPDs are only seeing the unintentional length to angle coupling the projection from the normal level of the QPD spectra to the normal level of DARM could be an overestimate. This projection does show that this would be within a factor of 10 of DARM from about 100 Hz down to at least 75 Hz.
Perhaps when we get a chance we can try misaligning TMSX to see if we can reduce the noise in DARM this way.
AS Keita suggested, I checked if some of this noise (or at least the linear coupling seen for TMSY) could be simply that my drive on TMS moves the ISI and that motion propagates down the quad to the test mass. This seems to be much too small to explain the observed coupling.
Using the GS13s, and the calibration for them that Jim told me, the table motion caused by my 75 Hz drive to TMSX was 4.9 nm/rt Hz, while my 90 Hz drive to TMS Y caused the table to move 3.4 nm/rt Hz. Using the quad model, The table motion is attenuated by 281 dB at 75 Hz and 294 dB at 90 Hz. The test mass motion induced due to my TMSX drive would be 4e-23 m/rt Hz at 75 Hz, and 6.724e-24 m/rt Hz for TMS Y. (too small to explain the lines in DARM).
Of course it is possible that the coupling mechanism is through the motion of the ISI, not TMS.
Everything quiet on site. Environment quiet. The current lock is approaching 40-some odd hours.
L1 went out of lock. At H1 we turned off the intent bit and injected some hardware injections. The hardware injections were the same waveform that was injected on September 21. For more information about those injections see aLog entry 21759 For information about the waveform see aLog entry 21774. tinj was not used to do the injections.The commands to do the injections were: awgstream H1:CAL-INJ_TRANSIENT_EXC 16384 H1-HWINJ_CBC-1126257410-12.txt 0.5 -d -d >> log2.txt awgstream H1:CAL-INJ_TRANSIENT_EXC 16384 H1-HWINJ_CBC-1126257410-12.txt 1.0 -d -d >> log2.txt ezcawrite H1:CAL-INJ_TINJ_TYPE 1 awgstream H1:CAL-INJ_TRANSIENT_EXC 16384 H1-HWINJ_CBC-1126257410-12.txt 1.0 -d -d >> log2.txt awgstream H1:CAL-INJ_TRANSIENT_EXC 16384 H1-HWINJ_CBC-1126257410-12.txt 1.0 -d -d >> log2.txt To my chagrin the first two injections were labeled as burst injections. Taken from the awgstream log the corresponding times are approximates of the injection time: 1127074640.002463000 1127074773.002417000 1127075235.002141000 1127075742.002100000 The expected SNR of the injection is ~18 without any scaling factor. I've attached omegascans of the injections. There is no sign of the "pre-glitch" that was seen on September 21.
Attached stdout of command line.
Neat! looks good.
Hi Chris, It looks like there is a 1s offset between the times you report and the rough coalescence time of the signal. Do you know if it is exactly 1s difference?
Yes, as John said, all of the end times of the waveforms are just about 1 second later that what's in the original post. I ran a version my simple bandpass-filtered overlay script for these waveforms. Filtering both the model (strain waveform injected into the system) and the data from 70-260 Hz, it overlays them, and also does a crude (non-optimal) matched filter to estimate the relative amplitude and time offset. The four plots attached are for the four injected signals; note that the first one was injected with a scale factor of 0.5 and is not "reconstructed" by my code very accurately. The others actually look rather good, with reasonably consistent amplitudes and time delays. Note that the sign of the signal came out correctly!
I ran the daily BBH search with the injected template on the last two injections (1127075235 and 1127075742). For 1127075235; the recovered end time was 1127075235.986, the SNR was 20.42, the chi-squared was 29.17, and the newSNR was 19.19. For 1127075242; the recovered end time was 1127075242.986, the SNR was 20.04, the chi-squared was 35.07, and the newSNR was 19.19.
KW sees all the injections with the +1 sec delay, some of them in multiple frequency bands. From /gds-h1/dmt/triggers/H-KW_RHOFT/H-KW_RHOFT-11270/H-KW_RHOFT-1127074624-64.trg /gds-h1/dmt/triggers/H-KW_RHOFT/H-KW_RHOFT-11270/H-KW_RHOFT-1127074752-64.trg /gds-h1/dmt/triggers/H-KW_RHOFT/H-KW_RHOFT-11270/H-KW_RHOFT-1127075200-64.trg /gds-h1/dmt/triggers/H-KW_RHOFT/H-KW_RHOFT-11270/H-KW_RHOFT-1127075712-64.trg tcent fcent significance channel 1127074640.979948 146 26.34 H1_GDS-CALIB_STRAIN_32_2048 1127074774.015977 119 41.17 H1_GDS-CALIB_STRAIN_8_128 1127074773.978134 165 104.42 H1_GDS-CALIB_STRAIN_32_2048 1127075235.980545 199 136.82 H1_GDS-CALIB_STRAIN_32_2048 1127075743.018279 102 74.87 H1_GDS-CALIB_STRAIN_8_128 1127075742.982020 162 113.65 H1_GDS-CALIB_STRAIN_32_2048 Omicron also sees them with the same delay From : /home/reed.essick/Omicron/test/triggers/H-11270/H1:GDS-CALIB_STRAIN/H1-GDS_CALIB_STRAIN_Omicron-1127074621-30.xml /home/reed.essick/Omicron/test/triggers/H-11270/H1:GDS-CALIB_STRAIN/H1-GDS_CALIB_STRAIN_Omicron-1127074771-30.xml /home/reed.essick/Omicron/test/triggers/H-11270/H1:GDS-CALIB_STRAIN/H1-GDS_CALIB_STRAIN_Omicron-1127075221-30.xml /home/reed.essick/Omicron/test/triggers/H-11270/H1:GDS-CALIB_STRAIN/H1-GDS_CALIB_STRAIN_Omicron-1127075731-30.xml peak time fcent snr 1127074640.977539062 88.77163 6.3716 1127074773.983397960 648.78342 11.41002 <- surprisingly high fcent, could be due to clustering 1127075235.981445074 181.39816 13.09279 1127075742.983397960 181.39816 12.39437 LIB single-IFO jobs also found all the events. Post-proc pages can be found here: https://ldas-jobs.ligo.caltech.edu/~reed.essick/O1/2015_09_23-HWINJ/1127074640.98-0/H1L1/H1/posplots.html https://ldas-jobs.ligo.caltech.edu/~reed.essick/O1/2015_09_23-HWINJ/1127074773.98-1/H1L1/H1/posplots.html https://ldas-jobs.ligo.caltech.edu/~reed.essick/O1/2015_09_23-HWINJ/1127075235.98-2/H1L1/H1/posplots.html https://ldas-jobs.ligo.caltech.edu/~reed.essick/O1/2015_09_23-HWINJ/1127075742.98-3/H1L1/H1/posplots.html all runs appear to have reasonable posteriors.
Here is how Omicron detects these injections: https://ldas-jobs.ligo-wa.caltech.edu/~frobinet/scans/hd/1127074641/ https://ldas-jobs.ligo-wa.caltech.edu/~frobinet/scans/hd/1127074774/ https://ldas-jobs.ligo-wa.caltech.edu/~frobinet/scans/hd/1127075236/ https://ldas-jobs.ligo-wa.caltech.edu/~frobinet/scans/hd/1127075743/ Here are the parameters measured by Omicron (loudest tile): 1127074640: t=1127074640.981, f=119.9 Hz, SNR=6.7 1127074773: t=1127074773.981, f=135.3 Hz, SNR=11.8 1127075235: t=1127075235.981, f=114.9 Hz, SNR=12.8 1127075742: t=1127075742.981, f=135.3 Hz, SNR=12.4
The BayesWave single IFO (glitch only) analysis recovers these injections with the following SNRs: 4640: 8.65535 4773: 19.2185 5253: 20.5258 5742: 20.1666 The results are posted here: https://ldas-jobs.ligo.caltech.edu/~meg.millhouse/O1/CBC_hwinj/
General Question: Does this knock us out of Observation Mode? Could I have reset this this morning?
IFO was in Commissioniing.
No, the DIAG_MAIN guardian node is NOT under the OBSERVATION READY check. It can be changed/reset/etc. without affecting OBSERVATION MODE.
I think Cheryl was talking about the diag reset button on the GDS overview screen for the front end, not the DIAG_MAIN guardian.
Durring the maintence window we left the DHARD yaw boost on (21768 and 21708). There was no evidence that it caused any problems, but I was putting excitations onto transmon at the time and there were other maintence activities going on. We'd like to check that it doesn't impact the glitch rate, so if LLO drops out of lock or if you see an earthquake on the way ( 0.1um/sec or larger predicted by terramon), it would be great if you can turn it on. You can find it under ASC overview> ASC arm cavities, DHARD YAW FM3 (labled boost). (screenshot)
It would be good to get more than an hour of data, so if you see that LLO has dropped it would be awesome if you could turn this on util they are back up.
This is just a temporary request, only for tonight or the next few days.
This is actually FM2.
I was texting with Mike to see if taking H1 out of Observation Mode (when L1 is down) for this test was OK by him, and he concurred. This work is referenced by Work Permit #5505. In the work permit, I see a time of 9/21-25 for Period of Activity. So Operators can allow this activity during this time since Mike has signed off on the work permit. (perhaps in the future, we can reference the work permit in alog entries so Operators will know this is an acceptable activity.)
I'm not totally sure about when to make the decision to preemptively turn ON this filter if we get a warning of an impending EQ. It's not totally clear to know which types of EQ will knock us out and which won't. I guess I can look to see if (1) Terramon gives us a RED warning, and also (2) watch 0.03-0.1um/s seismic signal for an order of magnitude increase. Perhaps in that case I could then end Observation Mode and turn ON the filter and stay out of Observation Mode until L1 comes back. (sorry, just trying to come up with a plan of attack in case L1 drops out)
As it stands, L1 has been locked for 10hrs, so we'll keep an eye on them. I asked William to contact me if they drop out (but I'll also watch the FOM & GWI.stat.
I believe that by switching this, while in 'Undisturbed', it will show as an SDF diff thereby automatically taking us to 'Commissioning' mode until the diff is accepted, the ODC Intent ready bit is Green(again) and we can once again click the intent bit to 'Undisturbed'. I asked this at the JRPC meeting yesterday.
Apologies for the wrong FM number, and in the future I'll try to rememver to put the WP number in the alog. Operators can probably stop toggling this filter for now. We will put this on the list of minor changes that we will make on maintence day, so that next tuesday it can be added to the guardian and the observe.snap, along with some HSTS bounce and roll notches.
SudarshanK, DarkhanT
We were using 137 degree of correction factor on kappa_tst on our time varying parameters calculation. (alog 21594). Darkhan found a negative sign that was placed at a wrong position in the DARM model which gave us back 180 degrees of phase. Additionally, Shivaraj found that we were not accounting for DAQ downsampling filter used in ESD Calibration line. These two factors gave us back almost all the phase we were missing. There was also an analog antialiasing filter missing in the actuation TF that was applied in the new model. After these corrections, Darkhan created the new upated epics variable. These epics variable are committed at:
CalSVN/Runs/O1/Scripts/CAL_EPICS
Using these new epics variable, kaapas were recalculated for LHO. For, LLO these epics variable doesnot exist yet. The new plot is attached below. The imaginary parts of all the kappa's are now close to their nominal values of 0 and real part are few percent (2-3%) from their nominal values of 1, which is within the uncertainity of the model. Cavity pole is still off from its nominal value of 341 Hz but has stayed constant over time.
The script to calculate these time varying factors is committed to SVN:
LHO: CalSVN/aligocalibration/trunk/Runs/ER8/H1/Scripts/CAL_PARAM/
LLO: CalSVN/aligocalibration/trunk/Runs/ER8/L1/Scripts/CAL_PARAM/
Recall that Stefan made changes to the OMC Power Scaling on Sunday 13 September 2015 (in the late evening PDT, which means Sept 14th UTC). One can see the difference in character (i.e. the subsequent consistency) of kappa_C after this change on Sudarshan's attached plot. Once can also see that, for a given lock stretch, that the change in optical gain is now more that ~2-3%. That means that ~5 [Mpc] trends we see on our 75 [Mpc] the in-spiral range, which we've seen evolve over long, 6+ hour long lock stretches, cannot be entirely attributed to optical gain fluctuations as we've been flippantly sure of, and claiming. However, now that we've started calculating these values in the GDS pipeline (LHO aLOGs 21795 and 21812), it will be straight-forward to make comparative plots between the calculated time dependent parameters and every other IFO metric we have. And we will! You can too! Stay tuned!
Just to drive the point home, I took 15 hours' worth of range and optical gain data from our ongoing 41+ hour lock. The optical gain fluctuates by a few percent, but the range fluctuates by more like 10 %.
These are the channels in the DMT (GDS) hoft frames, which include the calibrated strain channel (H1:GDS-CALIB_STRAIN) and the calibration factors (the kappas):
H1:GDS-CALIB_STATE_VECTOR 16
H1:ODC-MASTER_CHANNEL_OUT_DQ 16384
H1:GDS-CALIB_STRAIN 16384
H1:GDS-CALIB_KAPPA_A_REAL 16
H1:GDS-CALIB_KAPPA_A_IMAGINARY 16
H1:GDS-CALIB_KAPPA_TST_REAL 16
H1:GDS-CALIB_KAPPA_TST_IMAGINARY 16
H1:GDS-CALIB_KAPPA_PU_REAL 16
H1:GDS-CALIB_KAPPA_PU_IMAGINARY 16
H1:GDS-CALIB_KAPPA_C 16
H1:GDS-CALIB_F_CC 16
These channels should be available using NDS2.
(For LLO the channels are the same with: H1-> L1.)
I strongly suggest we add EPICS mirrors of these channels (similar to what was done for the sensemon range). This will ensure that (1) they are available in dataviewer, and (2) we have trend data of these channels. We want to be able to look at long-term (week- or month-long) fluctuations of these parameters during O1.