HFD reports a power outage (? I could barely hear him... gate phone,ftl) and they need to check some boxes. He's currently driving down the X-arm very slowly, so I've flipped the intent bit. Will revert when I see he's off site.
The ISC_LOCK guardian now has a state HIGH_RANGE_ESD_ETMX, which is intended to be used to transition control of DARM from ETMY back to ETMX.
However, in the interest of maximizing the amount of coincident locking time with L1, this state has not yet been tested.
Pankow, Biwer, Thrane We restarted burst injections as LHO starting at GPS= 1117850177. We scheduled one ad hoc waveform to make sure tinj could find the burst waveforms after we switched waveform naming convention so that they end in .txt rather than .dat. This injection was successful: GPS=1117850363. Chris Biwer will be posting a similar entry on the LLO alog. The new burst injections are not all identical sine Gaussians. Each one is different. The upcoming schedule is: 1117854141 2 1.000000 hwinj_1117854141_3_ 1117856256 2 1.000000 hwinj_1117856256_3_ 1117869607 2 1.000000 hwinj_1117869607_3_ 1117878979 2 1.000000 hwinj_1117878979_3_ 1117906195 2 1.000000 hwinj_1117906195_3_ 1117912758 2 1.000000 hwinj_1117912758_3_ 1117929505 2 1.000000 hwinj_1117929505_3_ 1117949327 2 1.000000 hwinj_1117949327_3_ 1117959237 2 1.000000 hwinj_1117959237_3_ 1117966570 2 1.000000 hwinj_1117966570_3_ 1117973881 2 1.000000 hwinj_1117973881_3_
J. Kissel Using the DARM OLGTF model that we've updated the CAL-CS and GDS low-latency calibrations, I've generated an inverse actuation function for the hardware injections. This is an update to the filter designed for the LHO mini-run (see LHO aLOG 18115). The updated filter has been loaded into FM2 of the H1:CAL-INJ_HARDWARE filter bank, as well as the H1:CAL-INJ_BLIND filter bank, BUT NOT YET TURNED ON. It will be turned on tomorrow during maintenance. Recall that this filter should be assigned the same uncertainty as is true for the DARM Open Loop Gain transfer function (see LHO aLOG 18769) -- 50% and 20 [deg], mostly because of the frequency dependent discrepancy between the model vs measured DARM open loop gain transfer function. Indeed we are now quite certain that the model vs. measurement discrepancies / features seen at ~500, ~1000, ~1500 [Hz] are inaccurately modeled violin modes of the ETMY QUAD. Further, we're confident that we can *remove* these features from future actuation functions by retuning the ETMY UIM / PUM / TST control authority, which we will do immediately following ER7. Er, well, immediately following the vent that immediately follows ER7. So we expect future DARM OLGTFs and therefore inverse actuation function uncertainty to be much less. Details ----------- I've used the following DARM OLGTF model, /ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/PreER7/H1/Scripts/DARMOLGTFs/H1DARMOLGTFmodel_ER7.m with the following parameter set /ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/PreER7/H1/Scripts/DARMOLGTFs/H1DARMparams_1116990382.m to produce a new Inverse Actuation Function for the HARDWARE Injection path, ultimately created by and plotted with /ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/PreER7/H1/Scripts/DARMOLGTFs/CompareDARMOLGTFs.m The attached plots show bode plots of the design. As expected, because of the update to (a) the overall reduction of actuation scale factor (in [m/ct]), and (b) the frequency dependence of the actuation function to account for the new PUM / TST cross of ETMY, which is regrettably very feature full, the filter is significantly more complicated. The poles and zeros are toyModel.poles_Hz = [ pair(300,89.9) pair(300,89.9) pair(482,88.5) pair(1040,89.5) pair(3.2e3,0) pair(4e3,51) pair(6.5e3,60)]; toyModel.zeros_Hz = [0.01 0.01 pair(290,89) pair(310,88.9) pair(509,89.5) pair(1030,89.8) pair(3.2e3,70) 6.8e3]; The 300 [Hz] feature are the notches for the beam splitter violin mode (so we don't excite them via DARM), the ~500 and ~1000 [Hz] features are for the actual ETMY violin modes (which now leak through the L3 to L3 transfer function because of the inadequate roll off of the L2 to L3 transfer function), and the features at 2500, 3000, 3500, and 4000 [Hz] (which I did NOT both to include in the inverse filter) are to notch out further harmonics of the ETMY QUAD's violin modes. Finally, the > 4000 [Hz] poles are to roll-off the filter before the Nyquist frequency. The foton design string is zpk([0.01;0.01;5.0612+i*289.956;5.0612-i*289.956;5.95121+i*309.943;5.95121-i*309.943; 4.44181+i*508.981;4.44181-i*508.981;3.59537+i*1029.99;3.59537-i*1029.99;1094.46+i*3007.02; 1094.46-i*3007.02;6800],[0.523599+i*300;0.523599-i*300;0.523599+i*300;0.523599-i*300; 12.6173+i*481.835;12.6173-i*481.835;9.0756+i*1039.96;9.0756-i*1039.96;2517.28+i*3108.58; 2517.28-i*3108.58;3250+i*5629.17;3250-i*5629.17;3200;3200],1,"n")gain(1.27879e+09) where I've forced foton to use a gain of 1.14e17 [ct/m] at 100 [Hz], as shown in the plots, to avoid all the confusion about pole/zero normalization.
- locked when I arrived, ETMX ESD drive still "not quite off", counts in the hundreds
- went out of Intent and turned ETMX ESD drive really mostly off, counts less that 10, and range went up
- lock loss, relocked, and IFO very glitchy
- about 11AM local all glitches stop, I called Bubba, and started and investigation, around 1:30 local glitches from cleaning crew were confirmed, and Robert took over the investigation. Cleaning crew was at
- 17:39UTC, Ellie asked to have the ETMX lower RH turned down from 0.5 to 0.4, and it remains at 0.4
- ETMX roll mode damping gain turned up to 200, from 60, and turned on the -30dg filter, which seemed to work better today
- Evan changes to turn ETMX ESD drive really off automatically
- MEDM chages to ETMX ESD drive screen to have 3 colors for the ETMX ESD drive's 3 states
To Do:
- in the process of an initial alignment
This morning there was some confusion over whether or not the EX ESD was completely off. Since the latest technique for getting some more mpc's is to turn off the EX ESD after the ifo has achieved full lock, it is important for operators to know if it is all the way off or not. After talking with Evan, he cleared up some of my confusions and this is what I've found
There are three different states that the ESD can be in:
The confusion this morning arose from the ESD medm screen's "Active" light. The light was red but the Analog Monitors still had a few hundred counts to them. This is because the ESD DC Bias was OFF and the driver was on. To avoid this in the future, I added a third light to ESD Active. If the Active light is:
(Legend on the medm so you don't have to memorize that, screenshot attached)
Hopefully this will eliminate any future bewilderment.
Also, we updated the guardian to turn the EX ESD on and off as appropriate.
In LSC_FF, if the EX bias has been ramped to zero, the guardian will write 1 to H1:ISC-EXTRA_X_BO_3. This is then reset to 0 after a few seconds (by Beckhoff?). This will inactivate the driver.
In DOWN, if the analog readbacks for the driver are close to zero, the guardian will again write 1 to H1:ISC-EXTRA_X_BO_3. This is again reset to 0 after a few seconds. This activates the driver.
Occasonally it seems that the reset mechanism freezes, so that cycling BO_3 does not do anything. In this case, it usually works to do the following:
caput H1:ISC-EXTRA_X_BO_4 0
caput H1:ISC-EXTRA_X_BO_4 1
And then write 1 to H1:ISC-EXTRA_X_BO_3.
Glitches have been showing up in the IFO range since the lock that started at about 17:00UTC, and the rate of glitches has been about the same throughout the morning.
The crew took a break at 11:00 local time, and all glitches stopped. I verified that no one in the CR had made a change. Glitches resumed about 40 minutes later, which coincides with the crew starting to clean again.
20:22:00 UTC, beam tube cleaning starts.
The first IFO glitch in this lock happens within one minute.
Bubba has had the crew mark where they were working at the time.
Robert is heading down to investigate.
Glitch at 17:45:25UTC - H1:ASC-Y_TR_A_NSUM_OUT_DQ and H1:ASC-X_TR_A_NSUM_OUT_DQ gltich first.
The attached plot shows the tidal feedback to the ETM HEPIs. The available range is ±250µm. The maximum used drive so far was ~170µm. There seems to be a couple of times where the X end HEPI walked away between lock stretches.
https://alog.ligo-wa.caltech.edu/aLOG/index.php?callRep=16970
Since there's some chance that we're not going to go in EX in the upcoming vent, I checked the trend of X green QPD SUM over the past 5 months.
They only changed by 1% or so, and there's no reason to believe that it's getting worse. Certainly we will survive O1 without fixing it.
The quad matlab model generate_QUAD_Model_Production.m script has 3 new features:
1) reading in live damping filters
2) reading customized parameter files for the suspensions
3) building models with fiber violin modes based on the measured frequencies and Qs
svn up the following directory: ../SusSVN/sus/trunk/QUAD/Common/MatlabTools/QuadModel_Production/
Here is an example of how to build a model with all 3 features:
quadModel = generate_QUAD_Model_Production(frequency_vector,'h1etmy',[],0,true,'liveh1etmy',0,0,true,8);
* frequency_vector is some frequency vector you specify.
* 'h1etmy' is the customized H1 ETMY parameter file (quadopt_fiber is the general quad file). All other quads have parameter files now too, but h1etmy is the only unique one at this point.
* true (the first one) says you want damping
* 'liveh1etmy' says you want live filters from H1 ETMY. The 'live' prefix is what triggers the flag to read live filters. The code imports the filters from 5 minutes in the past, to allow for some latency.
* true (the second one) says you want violin modes
* 8 says you want the first 8 violin modes in the model (2 is the default if not specified)
The h1etmy.m parameter file includes the measured mode frequencies for the first 8 violin modes at the bottom of the file. More can be added as desired. There is also a place holder for the measured Qs, but I am not aware of any measured values. The violin mode script (called by the generate script) will incorporate any measured values found in the parameter file. It will use modeled values for those that are not specified.
I'll leave the testing of the live filter reading to the people at the sites, since this is harder to do off site. Please let me know if something doesn't work properly. I've only gone as far as checking that it compiles (on my laptop) and that the closed loop system is stable.
The generate script has instructions for setting up your computer to run the live filters. This text is copied here:
> Follow noise budget SVN checkout instructions here
https://awiki.ligo-wa.caltech.edu/aLIGO/NoiseBudget
Checkout the following addpath paths:
svnDir = '../NbSVN/aligonoisebudget/trunk/' (the '..' must be the same as for the SusSVN, e.g. /ligo/svncommon/)
addpath(genpath([svnDir 'Externals/SimulinkNb/']))
addpath([svnDir 'Common/Utils/NoiseModel/'])
addpath([svnDir 'Common/Utils/'])
> Follow NDS2 install instructions here
https://wiki.ligo.org/viewauth/RemoteAccess
Matlab should be pointed to this version of liveparts.m:
../NbSVN/aligonoisebudget/trunk/Externals/SimulinkNb/SimulinkNb/liveParts.m
Corey noted the watchdog trip of the BS ISI early Sunday morning. As he said, this was just a State3 trip where the stage Isolation and Feedforward are blocked but the Damping remains engaged. Again, this is the normal state of operation for the BS ISI so this trip had no impact on the performance of the platform or the IFO. A state3 watchdog trip is entered if the motion level returns to okay magnitude within 2 seconds.
Attached is the wave form as seen by the GS13 on the BS. It looks like it could be an earthquake but I can't be positive as velocities and arrival times between different waves for teleseismic events is not simple.
The candidate Earthquake would appear to be the 4.5Mag event at the far northwest end of the Aleutian Trench. The low-latency online Earthquake Monitor, does not put the arrival of any of the EQ wave types at the site at the time of this watchdog trip. They are all predicted to arrive 10s of minutes before so either this is not an earthquake response or the velocities and distances travelled for this monitor are not correct enough.
Okay--after looking at other platforms (GS13s on other BSC ISIs are inloop,) HEPI L4Cs and the ground STS2, none of which sees this same signal which tripped the BS stage2, nor does any of these see any thing resembling an EQ in the predicted arrival time, I'm going to say this is not a EQ trip of the BS and it possibly came from the platform itself. More investigation required.
This is all a good thing as we'd be in tough shape if we were vulnerable to a 4.5EQ 5000 km away.
So this trip occurred when the IFO was not locked and based on the MICH_CTRL signal, Kiwamu sees this as an attempt to lock MICH before the alignment was close enough.
This first attached shows MICH_CTRL, LSC-TR signal (not locked) and the GS13s. The second attachment is zoomed into the start of the event and you can see that the MICH event begins before the GS13 response. The second vertical black bar is the watchdog trip time.
An audible alarm on this would have allowed the operator to untrip the watchdog before being in Science Mode [sic].
Detchar
Conclusion: Now with three data points, when PRM M2 coils get a mean value close to 2^16 (it has some RMS too, not shown) we see low frequency glitches in DARM. Second conclusion, today's lockloss at 4:45 UTC was likely caused by PRM M2 hitting the DAC limit of 2^17. So the tidal offset that was tried before should fix that at least.
Dan Hoak on the call pointed us to that there were two more times with PRCL/SRCL glitches seen in hveto. I used these three times to make the attached plot as an update to previous studies. Back then we were not able to make a smoking gun correlation between 2^16 crossings in PRM and these glitches, whcih is unsettling. We will look at these new times to see if it's more convincing.
Today: LLO is recovering from a power outage Hugh looking at cause of BS trip over weekend Kingsoft will be on site to replace RO filters John may change chilled water setpoint if IFO loses lock There will be a vent planning meeting at noon Tuesday: Betsy to run charging measurement Jim B. to perform filesystem maintenance on framewriters Richard to look at cosmic ray detector Kyle to work on TMDS piping and run pumps at end X Jeff B. to set up dust monitors at end stations
When one makes a "comment" to an entry, there is a "Title" field (default-filled with "Comment to [original entry's title]"), but one could change the Title. However, whatever is in the title field for the comment does not show up with the Comment entry. It would be nice to tag your comment/sub-entry with Title.
I've noticed that as well. I would suggest filing a bug against the "alog" product in the CDS bugzilla:
https://bugzilla.ligo-wa.caltech.edu/bugzilla3/enter_bug.cgi?product=alog
You should also make the "Section" of this log entry be "Logbook Admin".
This is already an open issue in the aLOG product of the bugzilla Jamie mentions: Bugzilla Entry 870. This bug had been open by Keith based on the original aLOG that did as Jamie suggested LHO aLOG 3728.
Attached is the output from dmesg on h1broadcast0. It is reporting an divide error on the daqd process and suggesting a reboot. We should consider scheduling this for tomorrow's maintenance.
The failure mode of the GDS broadcaster (no updates to GPS time, etc.) are consistent with a failure of the 'myri10ge' network driver. That driver controls the 10G adapter taking in data (at 16Hz) from the data concentrator. If it gets no data, it does not update GPS time, etc. that are in the data packet. As for solutions, perhaps restarting machines more often that once every 9 months will help. We are also look at updating the OS on the DAQ computers, which would include newer drivers - they are built into the kernel in Linux 3.2.
Starting right around 21:00 local, the 25.4 hz (well, DTT says something like 25.37) peak showed back up, creating a nasty looking comb in the DARM spectra (first image). Unsure of what else to do, I turned the power down to 16 watts, the peak has now kind of subsided(second image). I'll wait to see if the peak settles down any more, then maybe turn the power back up.
Dan called in and helped me look for a PI with a template he had ready. There were 2 peaks rung up at 15516 and 15540, see attached plot. The main culprit causes the big bump in the RMS, the little peak next to it was also rung up more than Dan's quiet reference. We were trouble shooting when the IFO lost lock. Guardian is bringing everything back up.
Thanks, Jim!
The channel H1:IOP-LSC0_MADC0_TP_CH12 is the 64kHz-sampled IOP input for OMC DCPD A.
Recall that the frequency of this mode matches what Elli measured for our parametric instability.
The other approach would be to change your ring heater power. I guess you in the same situation as us from the fact that the previous step up in ring heater power was effective. So you need to increase your ring heater up from 0.5W per segment, which is what I think it was set to after your first observation of parametric instability. At Livingston if we increase the ring heater too much we then ring up a 15004Hz mode. There is a new wiki here for operators as we had an apparent change in the parametric gain after last vent and we are still in the process of finding a new operating point for the ring heater.
The two acoustic modes appear to ring up with a similar time constant see image, there is also a peak in DARM a bit further down ldvw link any idea if this is related? It's a bit big for an acoustic mode that is not ringing up.
I would guess that these two modes are ETMY and ETMX ringing up with the vertically oriented mode, as that is what we mostly see at Livingston. You could look at the transmission QPD channels for more information if you are interested.
At Livingston these channels are L1:IOP-ISC_EY_MADC1_TP_CH0-7 for X and Y end, pitch and yaw orientations can be derived.
[Daniel, Paul]
We have updated our LHO FINESSE file (https://dcc.ligo.org/LIGO-T1300904) to compute an estimate of the DCCP as requested by Jeff.
The DCCP value we calculated was 369 Hz. This is for a well mode matched and aligned setup.
The optics details were taken from the galaxy page for the various mirrors installed at LHO. We also tried to get some more accurate losses in the arms taken from the following documents:
| Optic | Loss [ppm] | LHO aLOG ref. |
| ITMX | 42 | N.A. |
| ETMX | 78 | 16082 |
| XARM | 120 | 16579 |
| ITMY | 30 | N.A. |
| ETMY | 125 | 15919 |
| YARM | 155 | 15937 |
The caveat here is that the DCCP value has been seen to wander depending on alignment, as was reproduced in some of Gabriele's simulations, https://dcc.ligo.org/LIGO-G1500641. Here Gabriele found a slightly higher well aligned DCCP value of ~380Hz. We know that the DDCP value depends on many variables (alignment, mode mismatch in SRC, arm losses etc.), some of which are not yet well constrained with measurements.
Attached is a plot of the DARM TF from the Finesse model, which is well described by a single pole at 369 Hz.
This is my own reckoning of the loss measurements we've performed after the ETMs were cleaned in December. Note that these visibility measurements do not independently measure losses from the ITMs or the ETMs; they just give the total arm loss from scatter and absorption.
If these measurements are not satisfactory, we could always repeat them.
We could also repeat the ringdown measurements, but we would need to be more careful when collecting the data. Last time, the incident IR power on the arm fluctuated from lock to lock, which made the uncertainties in the inferred losses much too big for the measurements to be usable.
| Loss | Date | Method | alog | Notes |
| 78(18) | 2015-01-14 | Visibility | 16082 | — |
| Loss | Date | Method | alog | Notes |
| 286(33) | 2015-01-05 | Visibility | 15874 | Green WFS not on |
| 125(19) | 2015-01-07 | Visibility | 15919 | — |
| 155(19) | 2015-01-08 | Visibility | 15937 | — |
| 140(16) | 2015-01-09 | Visibility | 15991 | — |
Elvis has left the building. HFD off site at 23:55.