With LLO down, we have some work permits to take care of.
The work consists of: Stefan increasing the power back to 23W and Kiwamu enabling a low-pass filter in SUS SR2.
At 19:28pst the Intention Bit was switched to Comissioning to reflect the work being done.
More seriously, since several people asked me how to have "real time" info about the status of the detectors, I advertize here this monitor that Peter Shawhan and Chad made, displaying basic detector status with ~30-45 seconds average latency: https://ldas-jobs.ligo.caltech.edu/~pshawhan/gwistat/
Stefan, Kiwamu,
In this morning, DARM had many numbers of glitches which were visible in the DARM spectrum as wide band noise. We looked at various channels to see what caused the glitches, but we were not able to identify them.
The lock stretch which had a high glitch rate is the one starting at 2015-06-05 17:17 -sh to 18:00 -ish UTC. I attach an example time series of the glitches shown in OMC-DCPD A and B. We know that some of the loud ones were so large that they saturated the ADCs of the OMC DCPD.
Note that in the same lock stretch, we changed the DARM offset multiple times which changed the amount of the carrier light resonating in OMC. We do not think our activity with the DARM offset caused the high glitch rate.
Here is also a DARM spectrum and time series, as well as the summary page range graph. The glitches occur in the short science segment just before 18h.
We need to do some more thorough follow-up, but I can give some quick feedback that might give some hints. The initial signs seem to suggest that the problem might be due to input pointing glitches or alignment fluctuations in the PRC.
The loudest glitches in that short science segments were coincident with ASC-REFL_A_RF9_I_PIT_OUT_DQ, which looks like it was being used as the error signal for INP1 and PRC2 loops, feeding back onto IM4 and PR2. The corresponding YAW channel was also significant, but not quite as much so. We also saw ASC-REFL_B_RF9_I_PIT_OUT_DQ as somewhat significant, which looks like it was being used in both the INP1, INP2, and PRC2 loops and feeding back on IM4 and PR2.
So, we now start believing that these loud glitches were related to the cleaning activity on the X arm vacuum tube (alog 18992). Here I show glitch wave forms in time series from three glitch events (out of many) that were observed in this past Friday, 5th of June.
Typically the glitches were very fast and I am guessing that the glitch itself happens on a time scale of 10 ms or maybe less. Usually the OMC DC signals or the DARM error follows with a relatively slow oscillation with a period of roughly 100 msec which I believe is an impulse response of the DARM control. All the three events showed a power drop in the carrier light everywhere ( TRX, TRY and POP) indicating that the power recycling gain dropped simultaneously. For some reason POP_A_LF showed slower power drop which I do not understand. Also, in all three events that I looked at, the OMC DCPDs showed small fluctuation roughly 20 ms before the big transient happens.
(This one contains two glitch events apart only by roughly 200 msec)
(all the time series are high-passed with zpk([0], [40], 1) ). You can see a glitchy behavior in REFL WFS (as reported by TJ) as well as TRX QPD (and a little bit in TRY QPD).
WP5250
I have changed the CDS STATE_WORD overview MEDM screens to show a red rectangle if any of the DAQ systems stop updating. If today's freeze up of the broadcaster were to re-occur, it should now show a red alert. I'm using the h1ioppsl0 GPS counter as the standard against which I compare the DAQ GPS counters. If they lag by 60 seconds the alert is shown.
There has been some discussion on how alogs are ordered on the web page. Here is what I learned this afternoon after speaking with Ryan.
Each page displays 20 entries. These can be new entries made recently with no comments or new entries with recent comments, in which case they are listed in chronological order of the initial post.
If any of today's entries are comments to an old post (one which would normally not be displayed in the page) then the initial post is shown in today's page, along with every comment it has garnered including today's comment(s). These "promoted" entries are shown at the bottom of the page in chronological order of the initial posting.
For example, at the bottom of today's (Friday 05 June 2015) first page there are two old posts which were commented on recently, they are in the order:
evan.hall@LIGO.ORG - posted 21:21, Thursday 04 June 2015 - last comment - 12:47, Friday 05 June 2015(18878)
kiwamu.izumi@LIGO.ORG - posted 11:16, Friday 29 May 2015 - last comment - 14:45, Friday 05 June 2015(18693)
Note the order of the initial post, not the order of the last comment.
Therefore the alog entry numbers can be out of sequence. Also some numbers may not appear at all if they were assigned to a draft entry which was subsquently abandoned.
For some guidance regarding beam centering in HAM6, I post here the estimated Gouy phase for the optical elements between SR3 and the OMC. The a la mode script that was used is attached, along with the parameters file which uses the best available positions of H1 optical elements in HAM6. This is the same material that was posted in alog:14023, here I add information and SR2, SR3, and AS_C.
| Optic / sensor | Gouy phase (deg) |
| SR3 | 47 |
| SR2 | 48 |
| AS_C | -171 |
| OM1 | 109 |
| OM2 | -149 |
| AS_A | -78 |
| AS_B | 4 |
| OM3 | -119 |
| OMC QPD A | -95 |
| OMC QPD B | -80 |
From these results there's no obvious pairings of actuator --> sensor, except for OM1 --> AS_B and OM2 --> AS_A, which is essentially what we're using right now. The OMC QPDs are degenerate, but we construct a waist basis for the OMC alignment, {OMC_A, OMC_B} --> {POS, ANG} using the known geometry of the OMC breadboard.
The plots attached show the beam propagation for the path from OM1 to AS_C, the AS WFS, and the OMC, respectively. Note that these beam propagations are for a single-bounce beam from ITMX. We know the mode from the full IFO is different (because the mode-matching into the OMC is different, between a single bounce and the full IFO), but it's not a large difference.
Anyways we shouldn't rely on simulation, we should measure the sensing matrix from {SR3,SR2, OM1, OM2, OM3} --> {AS_A, AS_B, AS_C, OMCA, OMCB} and work out a control scheme.
The a la mode script and parameters file are attached.
Apollo finished the beam tube this afternoon.
No other site related activity to report.
IFO:
Short lock around 17UTC was very glitchy, and didn't last.
I helped the DRMI alignment when relocking and while it took about two hours and more than one attempt to get the IFO back to full lock, the current lock has been going for almost 3 hours.
Intent bit was engaged and alogged earlier.
Changes during this lock are that the OMC Dither was turned off and then on again.
SDF was red but now green.
Kiwamu has an approved work permit to enable a filter on SR2, which has glitched a few time during this lock.
Stefan has an approved work permit to try for 23W locks as soon as he has an opportunity.
Chris S. Beginning 120 meters from the corner station on the X-Arm, 40 joints were cleaned and metal strips attached. Caulking still needs to be completed on those joints.
Scott L. Ed P. Cleaned 33.5 meters of tube ending 8.4 meters north of HNW-4-066. Cleaning crew left at noon, both feeling ill. A total of 3297 meters of tube cleaned to date.
With help from Betsy and Corey, and confirmation from Kiwamu and Hugh's alog, I cleared the IMC-DOF offsets - confirmed as a change from Robert's work and working well.
I also turned the OMC-ASC_DITHER_MASTER off.
And then again...
Actually, Dan would like the OMC Dither enabled as a monitoring point, and maybe use the dither alignment, so the agreemeet with Kiwamu and Dan was that we'd turn the dither on, and acept it in the SDF.
OMC Dither = ON is now acepted in SDF, and SDF overview is again all green.
I don't see any of the alogs I posted last night. I can see them if I search myself, and they show up, but they aren't showing up in the alog. BUG!!!
I see yours show up on page 2. There have been a bunch of replies posted to various entires today, so the top-level entries get bumped up to the first page (even if they have a lower alog number than some of the top-level entries on the second page). I agree it is not a very straightforward behavior.
Hannah, Stefan We quickly looked at the pretty dramatic 5Mpc (10%) range drop that occurred at 10:07 UTC on 2015/06/05. Attached are DARM spectra for 09:30 UTC (good reference, black) and 10:07 UTC (bad reference, red). We did loo for coherence with MICH_OUT and SRCL_OUT at both good and bad times, but none showed any significant coherence in the 40Hz to 150Hz frequency band. Neither do ISS_PDA or ISS_PDB.
I restarted daqd on h1broadcast0 at 13:01 PDT. Very soon afterwards all the DMT monitors started running again and we now have Sensemon and SeisBLRMS plots updating again in the control room.
H1 was locked and in science mode during the DMT outage.
here are the times when the H1 operator intent bit was set while the DAQ broadcaster was not serving data:
18:38 - 18:42 UTC
19:26 - onwards until broadaster restarted at 20:01
Some LHO DMT monitors are not running. John and Maddie have been emailed about the problem. There is no CAL SENSEMON or SEIS BLRMS data at the moment from H1.
Looks like the DAQ broadcaster has stopped sending data. Its EPICS IOC is still running, but the EPICS values are frozen. There are no recent logs in the log files. We have not seen this failure before. CPU and MEM looks good on the machine.
We should discuss restarting the broadcaster (will not affect the rest of the DAQ)
The MICH feedforward path into DARM has been retuned, since Gabriele recently found a nontrivial amount of coupling from 50 to 200 Hz.
First, the MICH → DARM and MICHFF → DARM paths were measured according to the prescription given here. Then the ratio of these TFs was vectfitted and loaded into FM4 of LSC-MICHFF. This is meant to stand in place of FM5, which is the old frequency-dependent compensation filter. The necessary feedforward gain has been absorbed into FM4, so the filter module gain should now be 1. These changes have been written into the LSC_FF state in the Guardian.
The attachment shows the performance of the new retuning compared to the old retuning. At the start of this exercise, I had already changed the FM gain of the "old" retuning from 0.038 (in the Guardian) to 0.045, as this removed a lot of the coherence near 100 Hz.
Also, I had previously widened the violin stopband in BS M2 L, but had not propagated this change to the analogous filter in LSC-MICHFF. This is now fixed. Also note that if any change is made to the invBS compensation filter in BS M3 L, this change must be propagated to LSC-MICHFF as well.
I did not have time to implement SRCL feedforward. I suspect it would be a quick job, and could be done parasitically with other tweaking activities.
Coherence between MICH and DARM before and after Evan's work. (As far as I can tell, yes, DARM got better and the range improved..although it is not evident from the SNSH channel, as it had problems around the time of Evan's work.) Let's see how much this coupling changes over time.
The LSC-MICHFF_TRAMP is now set to 3 versus the snap setting of 5 sec. This shows in the LSC SDF diff Table now and should be reverted or accepted, Evan?
Snap setting of 5 seconds is probably better.
Something is not healthy on SR2 suspension.
Recently we noticed that some DAC on SR2 suspension saturated intermittently at a rate of roughlu once per 10 minutes or so. At the begginig we thought this was due to some ISC feedback saturating some DACs when we lock the interferometer. However, it turned out that it saturates even when no ISC feedback is sent.
The attached is a one-hour trend of all the saturation motniors of the SR2 top stage actuators from the period when SR2 was aligned and damped without any ISC feedback signals yesterday. As seen in the plot, the RT and LF DACs saturated mutiple times. The LF saturated more frequently than the RF actuator. Looking at the suspension screen, Betsy and I found that the longitudinal dampig showed higher signal level at its output than every one else. It is on the order of 100 counts at the output. Betsy is currently checking the longitudinal damping loop by running a transfer function measurement.
I ran a damped L (longitudinal) loop TF which looks "healthy" when compared to previous TFs - so nothing agregious there. However, we note that we do not have a lot of damping in any of the H1 HSTS L loops as observed from looking at the other HSTS L TFs. Also the L loop output seems to be doing more work (higher numbers rolling through) than other L loops. We started looking at filter diffs in the L loops and see that in some HSTSes we have the FM10 Ellip50 engaged. We engaged this filter and see that the L loop output became much quieter (closer to zero). Kiwamu wants to see if this will improve the saturations of SR2 and imprve locking. Attached is a quick damped TF of SR2 M1 DAMP L with the FM10 engaged, as well as a screen snapshot.
For some reason, the elliptic filter that we installed at FM10 of the longitudinal damping loop was taken out on 2015-June-2 18:00. SR2 seems to be saturating again. Sad.
