- Took over from TJ at 23:00 (16:00). Commissioners/Ops working on relocking IFO until 02:00 (19:00).
- Set Obs Mode to commissioning – Commissioners working while LLO is down.
- After some initial locking problems, the IFO has been stable locked at 22.9W with approximately 65Mpc. The shift is running smoothly. 
- I added 125ml water the crystal chiller. 

I've been investigating the range drops associated with loud (SNR > 1000) glitches.

During ER7, these were thought to be due to particles falling through the beam (see alogs on "dust glitches" 20276, 20354, 20355, 20328, 20395, 20484).

In ER8, we are still seeing loud glitches associated with range drops, however now there are also saturations on SUS ETMY (see alogs 19939, 19947, 20071, 20612, and almost every Ops summary since August 17).

Every Omicron trigger with SNR > 1000 (and most of those with SNR 100 – 1000 as well) is simultaneous with a range drop and an ETMY saturation during the 92 hours from September 3 - 6.

By contrast, none of the SNR > 1000 triggers from June 9 - 11 are associated with ETMY saturations.

On the other hand, OmegaScans and timeseries plots of the ER7 and ER8 glitches look similar, suggesting that all the glitches may be related.

So, if there are two distinct glitch classes, the "dust glitches" appear to have stopped occurring.

Or, if all the glitches have the same cause, then something seems to have changed to make ETMY more sensitive to them.

Has anything in the control system changed in a way that could lead to larger signals appearing on the ETMs for the same ‘glitch stimulus’?

See plots attached, and PreO1WorstGlitches page for more details.

Restarted DCS Disk2Disk and diffFrames which copies data from CDS to LDAS and checks for diffs between the science frames from the two framewriters. The restart was between 16:28 PDT and 17:19 PDT today (08 Sept. 2015). This was to fix a minor bug found in these scripts where they did not close a file used internally by the scripts to check its own run status. This change should have no impact on CDS.

I added 'H1:OMC-READOUT_ERR_GAIN' to the exclude list, since it sometimes generates 'nan' values and stops Conlog. I then regenerated the channel list and set Conlog to use it.

+ H1:OMC-FPGA_DTONE_GAIN
+ H1:OMC-FPGA_DTONE_LIMIT
+ H1:OMC-FPGA_DTONE_OFFSET
+ H1:OMC-FPGA_DTONE_RSET
+ H1:OMC-FPGA_DTONE_SW1S
+ H1:OMC-FPGA_DTONE_SW2S
+ H1:OMC-FPGA_DTONE_SWSTAT
+ H1:OMC-FPGA_DTONE_TRAMP
- H1:OMC-READOUT_ERR_GAIN
inserted 8 pv names
deleted 1 pv names

Collected OBSERVE.snap files for use in full observing configuration monitoring.

With the SDF happy (green) and Guardian Nominal (Robust Isolated) and green, I made an OBSERVE.snap file with SDF_SAVE screen

choosing EPICS DB TO FILE  & SAVE AS == OBSERVE

This saves the current values of all switches and maintains the monitor/not monitor bit into the target area, e.g.   /opt/rtcds/lho/h1/target/h1hpietmy/h1hpietmyepics/burt as OBSERVE.snap

This file is then copied to the svn: /opt/rtcds/userapps/release/hpi/h1/burtfiles as h1hpietmy_OBSERVE.snap and added/commited as needed.

The OBSERVE.snap in the target area is now deleted and a soft link is created for OBSERVE.snap to point to the svn copy:

ln -s /opt/rtcds/userapps/release/hpi/h1/burtfiles/h1hpietmy_OBSERVE.snap OBSERVE.snap

Finally, the SDF_RESTORE screen is used to select the OBSERVE.snap softlink and loaded with the LOAD TABLE button.

Now, for the HEPIs for example, the not monitored channels dealt with by the guardian will be a different value from the safe.snap but, the not monitored channels are still not monitored so the SDF remains green and happy.  And if the HEPI platform trips, it will still be happy and green because, the not monitored channels are still not monitored.

What's the use of all this you say?  Okay, I say, go to the SDF_TABLE screen and switch the MONITOR SELECT choice to ALL (vs MASK.)  Now, the not monitored channel bit flag is ignored and all records are monitored and differences (ISO filters when the platform is tripped for example) will show in the DIFF list until guardian has the platform back to nominal.

Notice too that the SDF_OVERVIEW has the pink light indicating monitor ALL is set.  This should stay this way unless Guardian is having trouble reisolating the platform and then the operator may want to reenable the bit mask to make more evident any switches that guardian isn't touching more apparent.

Tasks completed (Time in PST)

HAM1 Grouting (800-1220)

Crane TCS Chiller (-1220)

EX replace annulus ion pump (1012-1451)

Duotone Frame change (-1211)

CDS Frame Writers (831-1300)

UPS bypass repair (828-841)

PSL laser WD on Bechoff comuter (819-821)

PZT per LPF swap (1231-1321)

HWS alignment (1315-1409)

GDS channels added to DAQ (1300)

ETMX charge measurements (945-1033)

ETMY Coil Driver measurement (950-1150)

Log:

• 1500 (800 PST) - IFO --> DOWN
• 1503 - Bubba starting Grouting, he will be going in and out of the southwest door of the South Bay.
• 1504 - Karen rolling up receving bay door
• 1515 - Karen/Christina heading to ends to clean
• 1519 - Peter to Diode room to turn on laser WD on the PSL Beckhoff computer
• 1520 - Patrick restarting Conlog
• 1520 - Peter back
• 1526 - Ken in the MSR to repair UPS
• 1531 - Jim B starting Frame writer work (fw0 & fw3)
• 1534 - Elli taking the IFO to measure SRC Gouy phase
• 1541 - UPS back up and running
• 1616 - Karen/Christina going from EX to EY
• 1616 - Dick G to Optics Lab
• 1626 - Kiwamu transitioning LVEA to laser SAFE
• 1626 - Jeff K to LVEA to pick up some electronics
• 1630 - Jordan/Vinny to EY switching magnetometer filter box
• 1633 - Jim B starting fw1
• 1636 - Ken to LVEA to talk to Bubba
• 1637 - Jeff K out of LVAE
• 1640 - Elli done (because we switched to laser SAFE)
• 1645 - Betsy starting EX charge measurements
• 1650 - Jeff K to EY for UIM measurement
• 1708 - Karen/Christina done with ends
• 1712 - Ken to Y28
• 1712 - Kyle to EX to replace annulus ion pump
• 1716 - Fil/Andres to X vault to look at PEM channels
• 1724 - Jim W BS exc
• 1730 - Jodi to LVEA for 3IFO whatnots
• 1745 - Jim W done
• 1748 - Jordan/Vinny to EX to swap magnetometer filter box
• 1803 - Jodi out
• 1825 - Jordan/Vinny back
• 1832 - Jodi to LVEA to look for function generator
• 1835 - Ken back
• 1850 - Jeff K done at EY
• 1853 - Jodi out
• 1900 - Betsy starting EY charge measurements
• 1911 - Dave restarting Cal/OMC models (the Duotone work)
• 1920 - Bubba/Chris out
• 1931 - Keita/Sheila into PSL to swap PZT LPF
• 2021 - Keita/Sheila out of PSL and done with PZT peri LPF
• 2021 - Nutsinee starting HWS realignment
• 2109 - Nutsinee done
• 2123 - Sheila into the CER
• 2142 - Sheila out of the CER
• 2151 - Kyle done at EX
• 2152 - Start of Locking
• 2208 - Initial alignment

Handing off to Jeff B trying to lock DRMI_1F.

Longer maintenance Day, but no huge surprises.

Pump cart running next to BSC9 until further notice

Note, when the EXC bit in the CALCS CDS overview is in alarm, we tend to open the screen CAL_INJ_CONTROL to attempt to diagnose - This shows a big red light for some ODC Channel OK Latch, leading us to misdiagnose what is actually in alarm.  We have 2 operational problems:

1) If generically, there is a red light on the CDS screen - where do you go?  Normally, we follow the logical medm and are able to get to the bottom of the red status via logical nested reds.  This is not the case for the CALCS screen - the CDS H1:FEC-117_STATE_WORD bit is RED on the H1CALCS line of the overview screen, yet this bit is nowhere on the CALCS screen.

So, where does the info come from for specifically the EXC bit of the H1CALCS state word, such that we can do something about it?

2) Someone should rework the CAL_INJ_CONTROL.adl so that it doesn't cause us to misdiagnose actual reds.  Currently, the HARDWARE INJECTIONS are out of configuration (outstanding issue to still be sorted) and yet, there is NO INDICATION of that on the CAL_INJ_CONTROL screen...  Also, the CW injection appears to be off, but there is no "red alarm" on the screen.

BTW, the HARDWARE INJ appear to be off.  They dropped around 7pm local time last night (20 hours ago).

We have large glitches when we switch the coil driver state for PRM in every example that I've looked at.  This causes locklosses, about 5 over the weekend.  

One thing that we can do to make this less painfull is to move the switch earlier in the locking process (for example, we can try doing this right after DRMI locks rather than waiting until DRMI on POP).  

A real solution might be to change the front end model so that we can switch each coil separately.   

We could try tuning the delay, as described for the LLO BS 16295

Kiwamu, Sheila, Evan

Durring the calibration activities last week Kiwamu noticed that there was upconversion of the drive from ETMY.  Specifically when he drove in the L3 LOCK filter, he saw a second harmonic. When he drove each stage individually, through the test filter bank with a similar amplitide he saw no evidence for upconversion.  This suggests that the upconversion might come about by driving mutliple stages, or through the length 2 angle paths. 

We went back through the data and looked at the relative heights of the peaks.  We also calculated a ratio of the amplitude of the second harmonic to the square of the amplitude at the fundamental :
  ASD(2f) = alpha * (ASD(1f))^2

If we ignore other frequencies which could mix and only consider the second harmonics of DARM control, we would expect this upconversion to be something like a factor of 10 below our measured noise at 20 Hz, and near the measured noise at 10 Hz.

The next step is probably to identify which stages contribute to this upconversion, for example it seems probable that this is only noticeable for frequencies where L2 get a significant fraction of the DARM control signal. 

While Jeff and Darkhan have been trying to get the actuactor coefficients right for calibration, I worked on an orthogonal task which is to check out the latest optical gain of DARM.

Summary points are:

• They don't look crazy.
• However the magnitude at low frequencies seems too low. This is something we have been consistently suffereing from.

The plots below show the measured optical gain measured by Pcal Y with the loop suppression taken out by measuring the DARM supression within the same lock stretch. 

I used the data from Aug 28 and 29th (alog 21190 and alog 21023 respectively). The parameters were estimated by the fitting function of LISO. I have limited the frequency range of the fitting to be avove 30 Hz because the measurement does not seem to obey physics. I will metion this in the next paragraph. The cavity pole was at around 330 Hz which claims a bit lower frequency than what Evan indendently estimated from the nominal Pcal lines (alog 21210). Not sure why at this point.

One thing we have to pay attentin is a peculiar behavior of the magnitude at low frequencies -- they tend to respond lesser by 20-30 % at most while the phase does not show any evidence of extra poles or zeros. I think that this behavior has been consistently seen since ER7. For example, several DARM open loops from ER7 show very similar behavior (see open loop plots from alog 18769). Also, a recent DARM open loop measurement (see the plot from alog 20819). Keita suggested makeing another DARM open loop measurement with a smaller amplitude, for example by a factor of two at a cost of longer integation time in order to detemine whethre if this is associated with some kind of undesired nonlinearity, saturation or some sort.

Due to a crazy big offset of -0.5 in Y_TR_B_PIT (for SOFT modes sensing), Y IR QPDB is almost always railing a bit in 24W operation, and Y IR QPDA is not too far.

Next time IFO drops out of lock, somebody needs to lower the whitening gain by 3dB and set a new dark offset for each quadrant.

Eric, Cheryl

Following advice from D Shoemaker et al., we have disabled the LIMIT on the HWINJ filter bank. The change was made at approximately GPS = 1125361473. The LLO LIMIT was turned off earlier today:

https://alog.ligo-la.caltech.edu/aLOG/index.php?callRep=20249

C. Cahillane, D. Tuyenbayev I have updated the strain uncertainty calculator to use Darkhan's latest ER8 model along with ER8 data.

The ER8 model: /ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/ER8/H1/Scripts/DARMOLGTFs/H1DARMOLGTFmodel_ER8.m

The ER8 params: /ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/ER8/H1/Scripts/DARMOLGTFs/H1DARMparams_1124597103.m

The ER8 uncertainty calc: /ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/S7/Common/MatlabTools/strainUncertaintyER8.m

Again, there are slight discrepancies between Plot 1 and Plot 7. To reiterate, Plot 1 uses the full O1 calibration method and real data, while Plot 7 uses the Inverse Response TF with no data:

Plot 1:

dh = DARM_ERR / C_true + A_true * DARM_CTRL

     ------------------------------------

     DARM_ERR / C_0 + A_0 * DARM_CTRL

Plot 7:

dh = (1 + G_true) / C_true

     ----------------------

        (1 + G_0) / C_0

This time, I believe the discrepancies are a result of the as-of-yet incomplete ER8 model.  I will rerun this test when Kiwamu, Jeff, and Darkhan have all finished updating the ER8 model.

Note that the ugly spikes in uncertainty have disappeared from Plots 1-6 (as opposed to aLOG 21065). 

This is because now I do not have to interpolate my DARM_ERR and DARM_CTRL FFT frequency vector thanks to Darkhan's clever ER8 model functions par.{A,C,D,G}.getFreqResp_total(freq) where freq is a frequency vector I define.  This is possible because each portion of the ER8 model is an LTI object.  Thanks Darkhan.