IFO locked all shift, 4 ETMY glitches, nothing else to report.

A few thought as a follow on to Jeff's entry:

1. Injecting signals at DARM control (see G1501146) seems like a bad idea
   • while this worked in iLIGO, which had a relatively simple actuation TF, the DARM ctrl to DARM displacement TF is much more complicated now that we have a multi-stage suspension
   • the inverse TF looks like 1 / A * (B + C + D), which, by virtue of containing a sum in the denominator, can be very messy
   • not only is it messy, it is not robust against small changes in the DARM actuation path.  Think 1 / A * (g * B + C + D) and then let g vary... this will cause the poles and zeros to move.
   • Injecting directly into an actuator with a simple TF to DARM displacement (or force) would be much better (e.g., at the ESD or with PCAL).
2. I'll see what I can do to make an inverse filter, but I will be happy if a better way is found and this filter is never used.

Since turning up the bandwidth of the AS_C → SR2 loops, we had not engaged cutoff filters. There are now 18 Hz elliptic LPFs installed for both pitch and yaw. They are turned on the ISC LOCK guardian just after the final gain increase of the yaw loop.

TITLE:  9/11 EVE Shift:  23:00-7:00UTC (16:00-0:00PDT), all times posted in UTC

SUPPORT:  Evan helped me out with a question.  Others were here working throughout the night.

SHIFT SUMMARY:  

H1 at LOW_NOMINAL_NOISE for most of the shift (~43min of locking after a lockloss), and was in Commissioning for much of that time.  Range hovered around 75-80Mpc.  A couple of Mexico aftershocks barely registered here.  Other than that a fairly quiet night.  

OPERATOR OPEN ITEMS:  

• DIAG_MAIN has two BRS messages ("reboot needed" & rung up).  TJ will head out to EX to address this on Maintenance.  
• O1 CDS Overview has (1) RED H1CALCS (this is ok, it's injection-related), & (2) WHITE fw2 (Dave plans to remove fw2 from this medm).

INCOMING OPERATOR:  Cheryl

SHIFT ACTIVITIES:

• 0:46 Dick out of Optics Lab
• 3:22 Lockloss.  
• 4:06 H1 back up to NOMINAL_LOW_NOISE.
• 4:07 Evan going to start Noise Budget Injections until L1 is back in Observing
• 6:08 Double Coincidence begins:  H1 Back to Observation Mode and joining L1.

J. Kissel, D. Tuyenbayev

Although the jury is still out as to what accuracy we need for the start of O1, I've pushed forward with the plan to design an inverse actuation filter that removes the notches from the test mass stage of actuation, as discussed yesterday (LHO aLOG 21379). In doing so, I've plotted the total DARM actuation function for the first time since (a) we've an updated knowledge each stages' the actuation strength (LHO aLOG 21280), and (b) since the hierarchy filters were changed to reduce the impact of the wide-band impact of PUM violin mode resonances (LHO aLOG 20143). 

Regrettably, just like in ER7 (see pg 7 of G1500750), I've discovered that the PUM/L2 interaction with the TST/L3 stage is still very ugly, if not worse than it was. This means that even after taking out the notches in the TST/L3 stage and softening the Q of the TST/L3, 950 [Hz] L3 elliptic filter, there remains very complicated, 30%, 15 [deg] wiggles in the 100 [Hz] to 1000 [Hz] band that would require a great deal of poles and zeros to get correct.

I've found poles and zeros that could be used for a first cut filter, but it really does not do the full actuation function any justice, and is not worth installing. Matt Evans has suggested that he will give it a go tomorrow, but I really think this accelerates the need to inject hardware injections in a different place (the two options being PCAL and further upstream in the SUS actuation chain -- both of which have no notches or elliptic filters or anything complicated to invert). Either that, or we do an honest job cleaning up and rolling off the PUM with a sensible design, which means a significant change to the calibration and impact of the robustness of the IFO operation. Yes, it's just updating digital filters in the front end, but it would be a day or so of model parameter set development, coupled with verification against an open loop gain measurement, and testing whether the IFO was still stable. Kiwamu, Peter, Rick, and I are leaning towards the PCAL option, but we don't yet know what impact this will have on the hardware injection software infrastructure. 

As usual, Stay tuned. 
#NoSleepTilO1

The full story
--------------

Each page of the first pdf attachment walks you through the story of how I've attempted to go about this.

Just like before the H1 Mini-run and ER7, I've gone into the creation of this filter assuming that below the ~30 [Hz] PUM / TST cross-over frequency the PUM is the PUM stage, and above the TST is the TST stage. As such, I think "I should be able to create a simple set of poles and zeroes that roughly rise the shape of f^2, that I can roll off at high frequency, that may have a few poles and zeroes worth of complication. Certaintly something I can fit into one filter module of 10 second-order-sections. This way I don't have to deal with complicated, often buggy, fitting functions like vectfit or liso, nor with matlab-to-foton filter loading functions that are prone to errors / mistakes like autoquack. Plus I'll truely understand what I'm installing, and I can keep track of the systematic error all along the way." 

As such, I started the project as planned: take out the notches from the L3 stage, and reduce the Q of the elliptic filter. 
Pg 1 shows the progression as I reduce the complexity of the TST / L3 stage actuation authority. Blue is the full L3 actuation function, as taken directly from the canonical DARM model LHO aLOG 21386. Green is that same model, with the notches removed. Red is the same model, notches removed, and with the Q of the elliptic reduced from essentially infinity to 30.

Pg 2 shows the detail of the tailoring of the elliptic filter.

Great! This'll be nice and easy to invert.

So, I shoved the newly modified L3 / TST stage into the entire actuation function -- and I see a whole bunch of wiggles between 100 and 1000 [Hz] that are just not a part of the L3 / TST actuation (as seen on pg 1).

After quintuple checking for bugs, I plotted the decomposition of the total actuation function into all stages. This is pg 4. One can immediately see from this that there are interactions between the PUM and TST stage well-above the PUM / TST cross-over frequency. YUCK.

After digging around a little bit, I take a look at the filters that have been installed when the control authority was "reduced" in LHO aLOG 20143. I see that not only was the PUM *not* rolled off better, but the notches and elliptic filters that were put in place *instead* of just softly rolling off the stage better are just rediculous. Bode plots of the PUM notch filters and elliptic filters are shown in the second attachment for proof. 

Finally, just so I could demonstrate how a simple, 10-pole, 10-zero fit just would in no way be able to reproduce this actuation function, I put together such a function and caluculated the residuals. Pg 5 and 6 (back to the first attachment) show these residuals.

----------
The analysis script that generated these plots and the filter are here:
/ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/ER8/H1/Scripts/InvActuation/generate_invactuation_filter_ER8.m

The model and parameter file to generate the full actuation function live here:
/ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/ER8/H1/Scripts/DARMOLGTFs/
H1DARMOLGTFmodel_ER8.m
H1DARMparams_1125963332.m

The filter file that contains the digital filters in the SUS chain lives here:
/ligo/svncommon/CalSVN/aligocalibration/trunk/Common/H1CalFilterArchive/h1susetmy/H1SUSETMY_1124818267.txt

I attach the filter file and screenshots of all relavant filter banks here, for Matt's convenience, if he wants to waste a perfectly good Saturday.

C. Cahillane

I have tracked down the differences between my Two Signal ( h = 1/C * DARM_ERR + A * DARM_CTRL ) and Response function ( h = (1 + G)/C * DARM_ERR ) calibration uncertainties.

The trick lay in my weighting factors being slightly different with and without data included.  The Two Signal calibration method requires DARM_ERR and DARM_CTRL from the beginning, whereas the Response function does not.  This means that you must divide out DARM_ERR from the Two Signal method, or multiply it into your Response Function to get comparable results.  I did it both ways, and got identical plots (Shown in Plot 1). 
I found a bug in my Response function method since I was not including the hard-coded minus sign on the x_pcal line I use to calculate kappa_tst and kappa_pu.

Plot 1 and 2 are the same plot, but Plot 2 is zoomed in to show the data noise in the Two Signal method of calibration vs the smooth Response Function.
I have also included the updated components plots for Magnitude (Plot 3) and Phase (Plot 4).  Note that the uncertainty is inflated now compared to aLog 21390.

The next step is to fix the kappa_C and f_c calculations, they still yield ~0.75 and >1000 Hz respectively.  Sudarshan ought to be able to help me here relatively quickly.
Then I must inform my sigma_(param) values more intelligently.

Kiwamu, Evan

There was some discussion about whether we could improve on the current high-frequency DARM rolloff (a 950 Hz fourth-order elliptic).

We came up with a gentler filter (see attached foton plot) that has no extra phase loss below 100 Hz, but still manages to reduce the rms drive to the EY ESD by almost a factor of 2 (see attached DAC spectra) through a combination of more thoughtful shaping and judicious notching. In particular, we installed elliptic bandstops around 1237 Hz (not sure what this is), 2162 Hz (the OMC angular dither lines), and 5050 Hz (presumably a forest of upconverted violin modes). (Fotonistas will note the deliberate tuning of the elliptic notches for the OMC dither lines, although in this case it may be overkill.)

However, we have not implemented this new filter, since we do not want to disturb the current calibration efforts.

9/11 EVE Shift:  23:00-7:00UTC (16:00-0:00PDT), all times posted in UTC

3:22 H1 lockloss.  "ITMY Saturation" on VerbalAlarm.  Terramon said a 4.5 Japan quake within a minute of this, but we don't see any seismic evidence.

• Lock Attempt#1:  Slight tweaks on ETMx for ALS & then H1 went on its way.  DRMI took about 6min.  Dropped out at RF DARM.
• Attempt#2:  During this attempt, I noticed I had accidentally tweaked TMSx instead of the ETMx(!) in Attempt#1.  So with Evan's suggestion, I paused at DC_READOUT, and then carefully tweaked the TMSx back (accidentally took it to 40.085, and returned it to its nominal 41.485).  I returned TMSx with no issues.
• 4:06 H1 back up to NOMINAL_LOW_NOISE.
• 4:07 Evan going to start Noise Budget Injections (so this is why the range will look wonky from 4:15 & on....

I also talked with LLO (William on shift), and he said they were fighting roll modes.  When they get it back, Anamaria/Robert would like to do PEM Injections (they said it was late, so they might only wait it out a little longer).  So Evan will be opportunistic (WP5467) with H1 in the meantime.  

H1 has been locked since about 3:30pm with a range around 75Mpc (except for drop due to commissioning).  Evan continues DARM work with H1.  L1 was up for an hour, but is back down currently.

Minimal glitches on H1.

I believe that SRM M3 saturations caused the lockloss this afternoon that happened when the earthquakes hit us. 

In the attached plots, the data are the same, but one is zoomed in on the lockloss time and the other is not.  From the 2nd attachment ("SRMsat_longPlot.png") you can see that individual coils saturate at various times leading up to the lockloss, but we are still locked.  The first plot shows that at about 58.9 seconds, all 4 coils are simultaneously saturating (the horizontal black cursors are at +-132k).  60 msec after the first simultaneous saturation, ASAIR indicates that we have lost lock. 

Sheila saw this kind of pattern for PRM a few days ago, and fixed it by improving the offloading from PRM's M3 -> M1 (alog 21276).   I think that we should do something similar for SRM, and maybe be more robust during times of high ground motion. 

SudarshanK, GregM, RickS

The SenseMon range shows an increase in range from about 63 Mpc to about 75 Mpc from the previous to the current lock stretch.  JeffK suspected this is the result of a change in the sensing function.

GregM used the SLM too to generate 60-sec FFTs of the calibration lines and we calculated the time varying parameters (see T1500377) using these data to assess changes in the sensing function.

The resulting kappa_C, the sensing function variation, as well as f_c, the coupled cavity pole frequency, are shown in the first plot attached below.  The second plot shows the SenseMon range over the past 12 hours with the step in the IR between the current lock and the previous lock.

It seems that the change in sensitivity is indeed the result of variatioins in the sensing function which are tracked by kappa_C.

Note that we are not currently compensating for changes in the sensing function, but we plan to be soon, when the GDS calibration is up and running (and compensating for kappa_C).

SudarshanK, RickS

Now that "DeltaL_Ext" is calibrated, we can compare the estimated Pcal line heights (in meters) using the calibrated Pcal Rx and Tx PD signals with the DeltaL_Ext calibrated line heights.

There are known errors in DeltaL_Ext arising from delays, filter pre-warping, OMC DCPD poles, etc. that are not accounted for in this quick look.

The ratios between the Pcal calibrations and the DeltaL_Ext calibration for the 3001.3 Hz line (injectetd at Xend) and the 1083.7 Hz line (injected at Yend) are given in the table below.

So with a quick look the DeltaL_Ext calibration seems to agree with Pcal at the ~10% level at 3 kHz.

DTT plot attached below.

I committed all the OBSERVE.snap and a few uncommitted safe.snap files for LSC LSCAUX ASC ASCIMC OMC OAF  & TCSCS noting that in the userapps these safe.snap files are h1lsc_safe.snap for example.  Obvious to most of us but for the psl files...:

Similar for the PSLDBB PSLFSS PSLISS & PSLPMC except I found in the USERAPPS area in each of the DBB FSS ISS & PMC subfolders of the PSL area, both a safe.snap and a h1psliss_safe.snap file committed to the svn.  And the safe.snap softlink trom the frontend area, pointed to the h1psliss_safe.snap file (as it should.)  And the safe.snap and the h1psliss_safe.snap files in the USERAPPS area were not the same==> its even confusing as to how to explain except safe.snap in one area does not equal the safe.snap in the other.  And...so I removed the safe.snap from the svn.  The saving grace is that these files where a couple years old and much older than the named safe file.

There might be a few more of these that Betsy and I need to deal with in this manner.  On going.

• TITLE:  9/11 EVE Shift:  23:00-7:00UTC (16:00-0:00PDT), all times posted in UTC

• STATE Of H1: Shift started in Commissioning (Evan working on DARM) with H1 newly locked (30min) with a range of ~75Mpc.

• OUTGOING OPERATOR: TJ was on DAY shift.

• QUICK SUMMARY:  4.5Magnitude earthquake in Mexico started dying down around the time I arrived (low freq still slightly elevated).  Winds under 10mph.  TJ thought LLO was down for PEM injection work.
  

Log:

Times in UTC (PST)

• 1500 (800) Locked at Nominal Low Noise when I arrived
• 1542 Chris/Joe will be heading down the arms to do more seam sealing on the beam tube enclosures.
• 1616(916) Kyle will be breifly going past the card reader in the CS, driving around Corner Station to pick up nitrogen tanks, and then going to the X28 port.
• 1621 Taken out of Observe to allow for Kyle's driving, beam tube enclosure sealing, and Betsy doing SDF work
• 1630 Betsy done
• 1754 (1054) Dick G to the optics lab
• 1920 (1220) Jodi to MX
• 1948 Jodi back
• 2027 (1327) Joe/Chris done
• 2108 (1408) Evan doing some DARM reshaping, out of Observe
• 2110 Bubba down the Xarm to check on earlier work
• 2130 Bubba back
• 2138 Lockloss (May have been due to a few earthquakes. There was a 5.2 in Mexico and a 5.4 in Japan that should have arrived at similar times.)
• 2258 (1558) Evan starting DARM work again.

Re 21309 (HEPI) and 21346 (ISI,) I've made another change to the SDF OBSERVE.snap file TABLE and the current Monitor Select.

Even though all the HEPIs and the HAMISIs will have no differences between locks (Platform Trip and Reacquire,) which means there is always no expected differences for ALL channels, meaning the Guardian Touched DO NOT MONITOR list could be retained with the OBSERVE.snap file and the ALL MONITOR SELECT button could be used to monitor everything, since this is not the case for all SDFs, we will not do this for the HEPIs or HAM ISIs.

So for the HEPI and HAM ISIs, the OBSERVE.snap file has no NOT MONITORED channels and the MONITOR SELECT is set to MASK---Unlike the BSC-ISIs which all have 12 NOT MONITORED channels, the SETPOINT_NOW value which will change everytime those platforms trip and guardian reisolates them.  Changes have been committed.

J. Kissel, C. Biwer

At the request of Betsy (LHO aLOG 21303), I asked Chris to work with Duncan to solve that ODC state vector for hardware injections was reporting that the CAL-INJ_HARDWARE bank has been reporting the wrong status since Eric and Cheryl turned off the digital limiter on the filter bank (LHO aLOG 21198). Chris has succeeded admirably -- we merely needed to update the hexidecimal value against which the filter status is compared in the front-end ODC. We've 
(1) Changed the H1:CAL-INJ_ODC_HARDWARE_CTRL_EQ channel to be 0x1602 (instead of 0x3602) -- and the associated ODC bit went green, and subsequently the summary bit
(2) Accepted the change in the OSEBERVE.snap file in the SDF.
(3) Briefly switched to the SAFE.snap file, and accepted it there, then reverted back to using the OBSERVE.snap
(4) Copied the OBSERVE.snap over to the userapps repo, added, adn committed it there
(5) Removed the original OBSERVE.snap, and replaced it with a softlink to the userapps location,
jeffrey.kissel@opsws2:/opt/rtcds/lho/h1/target/h1calcs/h1calcsepics/burt$ ls -l OBSERVE.snap 
lrwxrwxrwx 1 jeffrey.kissel controls 65 Sep 11 14:57 OBSERVE.snap -> /opt/rtcds/userapps/release/cal/h1/burtfiles/h1calcs_OBSERVE.snap
jeffrey.kissel@opsws2:/opt/rtcds/lho/h1/target/h1calcs/h1calcsepics/burt$

Attached are screen shots of the before and after.

Next up -- an updated MEDM screen...

Chris S. Joe D.-40% each.

This week the guys had to cut 2 more of the 25# rolls into strips and punch holes. They were able to install strips on the top of 120 meters of enclosure making a total of 2280 meters completed.