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

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:

1. Driver ON, DC Bias ON
2. Driver ON, DC Bias OFF
3. Driver OFF

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:

• Green - Driver ON, DC Bias ON [ abs(H1:IOP-SUSAUX_EX_MADC4_EPICS_CH0) >= 325 and H1:ISC-EXTRA_X_BO_3 = 0]
• Orange - Driver ON, DC Bias OFF [ (abs(H1:IOP-SUSAUX_EX_MADC4_EPICS_CH0) < 325 and > 50) and H1:ISC-EXTRA_X_BO_3 = 0]
• Red - Driver Off [ abs(H1:IOP-SUSAUX_EX_MADC4_EPICS_CH0) <= 50 and H1:ISC-EXTRA_X_BO_3 = 0]

(Legend on the medm so you don't have to memorize that, screenshot attached)

Hopefully this will eliminate any future bewilderment.

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.

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.

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

Power Outage LLO just experienced a power outage around 1350 UTC. https://alog.ligo-la.caltech.edu/aLOG/index.php?callRep=18564

Comments related to this report richard.oram@LIGO.ORG - 10:21, Monday 08 June 2015 (18568) Link Power outage @LIGO was of 5 seconds duration.

DEMCO control room informed us that the main feed from Watson to the LIGO substation was interrupted unexpectedly (possibly by a tree- they are sending crews out to investigate cause).

The automatic breakers detected the momentary short and re-established connection after five second pause. DEMCO does not expect any further interruption but will not guaranty it. We have started power outage recovery procedures.

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.

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.

0:02 Came to find IFO unlocked. AS Air shows 01 mode.

0:37 Lock loss at LOCK_DRMI_1F after trying to adjust PR3 and BS (the requested state not met)

0:41 Not trusting the alignment due to the 01 mode on AS Air I saw earlier, I restarted the initial alignment.

        ALS-C_COMM_A_DEMOD_RFMON was less than 5. I adjusted PR3 until the value reached 5.

        INPUT_ALIGN gives repeated message "arm not IR locked" and " timer[ 'pause' ] = 3". LSC-TR_X not flashing. No spot on AS Air.

1:35 Got off the phone with Sheila. She suggested SR2 and SR3 alignment might be bad. I realigned them to where they were 10 hours ago (when the IFO was still locked). It didn't solve the problem. Sheila then suggested I realign PR2 and IM4 as well.

         At this point the beam is back on AS Air, but LSC-TR_X still not flashing. So I realigned PR3, BS, ETMX, and ITMX back to where they were 10 hours ago. Lost ALS-X in the process.

3:58 Relocked ALS-X. INPUT_ALIGN request state finally met (*phew*). I tweaked PR2 YAW but couldn't get LSC-TR_X to reach 1 (it was ~0.97 -- close enough?).

         Adjusted BS during MICH_DARK_LOCK. The requested state was never met. I tweaked BS until ASAIR_B_RF90 went to 0 and moved on to the next state.

5:00 ALS_DIFF told me to find IR by hand. So I tweaked VCO until IR found. If you (fellow operators) ever have to do this, the narrow peak you see in LSC-TR_Y is a lie (in a sense that you can't get LSC-TR_Y to rise and become stable from there). Tweak VCO until you get a broad peak. Then decrease the step size and adjust the VCO until LSC-TR_Y is steady around 1.

5:20 Lock loss at BOUNCE_VIOLIN_MODE_DAMPING. No obvious reason. Rt. 10 traffic is picking up though. Lockloss analysis attached.

5:50 IFO at DC_READOUT -- waited until the IFO settle before requesting LSC_FF

5:55 Locking at LSC_FF (nominal). Range ~50 Mpc. Intent bit switched to undisturbed.

6:06 Sheila suggested earlier that I turn the ring heater power down to 0.4 W after the ifo is locked (from 0.5 W). So I change the RH power to 0.4 W. The intent bit is still undisturbed at this point.

8:00 Still locking and going strong. Handling off the ifo to Patrick (Covering for Cheryl).

If lock loss again during the day, I suggest whoever has the interferometer at that point redo the initial alignment. Maybe realign the optics I haven't touched or mentioned in this alog.  AS Air spot is off to the right and the range isn't that great (I've seen the ifo stable at a better range, though Vern is happy with where it is). The drift monitor shows that OMC pitch and yaw is "Somewhat out of range" and in "Danger Zone".

[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:

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.