Following up on alog 46240, we made the following mods to the ISS Second Loop, S/N S1700062, which is now installed again (PCB D1600298):

• Connect feedback of open OpAmp U2B to negative input and ground the positive input.
• Increase the gain of the sum by increasing R32 to 10K (from 1K).
• Swapped the corresponding OpAmp U3 from OP27 to OP37.
• Decrease the gain by 10 in the readback of ERR2 after the sum by changing R62 in the SUM signal block from 4.53K to 45.3K.
• Decreased the analog excitation input gain by 10 by increasing R33 to 100K (from 10K).
• Decreased the digitla excitation input gain by 10 by increasing R77 to 100K (from 10K).

To account for the increased analog gain we reduced the VGA gain to 0dB (from +20dB). We increased the REFERENCE_IN_MTRX_1_2 gain to 10 (from 1) and the REFERENCE_IN_MTRX_1_4 gain to 0.5 (from 0.05). The reference offset was also adjusted to 537 (from -35.14). At first glance, the output offset fluctuations are significantly reduced.

[PatrickT, Jenne]

We've struggled to keep Yarm ALS locked this morning since we have particularly bad ground motion today.  We started down a path of trying to figure out why.

The Yarm SUSPOINT length projection from the seismic tables doesn't seem very coherent with the power fluctuations in the Yarm.  This led us to look at the angular motion of the optics. 

In the attached ndscope figure, you can see that the oplevs for ITMY and ETMY, pitch and yaw are on the same y-axis range of 0.8 urad.  However, ITMY pit is moving more than this scale.  (Stefan has some plots up that show that a similar phenomenon is happening on the Xarm).

We took a measurement of the ITMY pit oplev loop, with a thought toward using the oplev to damp this motion.  However, before we go further down this path, we're looking with Sheila and Stefan if there are any inconsistencies in the seismic isolation or suspension top stage damping that may have potentially come in during some maintenance or computer reboot time.

Dick Gustafson, Marc Pirello​​

Today, we investigated the output of 8 Port RF Amplifiers.  We looked at 45MHz, 24MHz, 71MHz at the PSL racks, and 9MHz in the CER.  All ports have good signal with very little noise.  We also looked at the 10MHz signal in the CER which is derived from the 80MHz VCO in the CER.  This signal has a few harmonics which can be low pass filtered out.  Attached are the plots for each test, including the before and after for the 10MHz test.  The 71MHz signal also has a bump near the 80MHz which looks to be coupled from somewhere.  This signal may also benefit from a filter.

*edit: fixed some mislabeled plots

Following yesterday's Dolphin upgrade, we have seen no Dolphin IPC errors overnight. The IPC MEDM (see attached) shows a single long-range error at Jan 08 2019 18:02:27 PST from EY to h1seiproc.

Checking dust monitors for possible problems over a period of 12 hours ending 0 hours ago...
 
   *H1:PEM-CS_DUST_LVEA6      WARNING: dust counts did not change, please investigate
    H1:PEM-CS_DUST_LVEA10     OK
    H1:PEM-CS_DUST_PSL101     OK
   *H1:PEM-CS_DUST_PSL102     WARNING: dust counts did not change, please investigate
    H1:PEM-CS_DUST_DR1        OK
    H1:PEM-CS_DUST_LAB1       OK
    H1:PEM-CS_DUST_LAB2       OK
    H1:PEM-EX_DUST_VEA1       OK
    H1:PEM-EY_DUST_VEA1       OK

According to their medm screens, H1:PEM-CS_DUST_LVEA6 and H1:PEM-CS_DUST_PSL102 do not appear to be running.

We had a long maintenance day today, 46295.  Here are some steps that we took to get through initial alignment and the first few steps of locking.  We finished the basic maintenance  recovery around 8 pm, but we have been having difficulty locking, probably because of the ground motion since.  

• We had some difficulty locking the IMC because the sensor correction wasn't the same between HAM2 and HAM3 when we first started trying to lock. Jeff K fixed this. 
• As Cheryl wrote, the PSL temperature is a little high and slowly coming back to normal, 46298.  We manually adjusted the temperature of the ALSX laser to relock the PLL. 
• Some of our alingments were quite different than before maintence started.  We have a variety of scripts that are meant to restore alignments.  We could package one nicely and put a link on a screen so that we avoid spending time manually trending and restoring sliders. 
• We had some difficulty locking ALS Y, which has been an issue lately.  I reverted some settings which were changed last week, in particular the threshold for calling it locked was set to 80% of the nominal power, which is too tight a constraint when the alignment isn't great and the ground motion is high.  I reduced the threshold back to 0.6, set the locked gain back to 3dB (had been increased to 7), and increased the acquire gain back to -4dB (was changed last week to -10dB).  I also got rid of the guardian states LOCKED_NO_SLOW_NO_WFS, which were just pointing to INITAL_ALIGNMENT, which is misleading. 
• PR3 yaw slider was different by 3 urad from where it was before maintence day, so we restored it, and that brought the alignment back to the way it was.  
• Found a bug in the sus config where it would always have a notifcation that it didn't align a suspension because of a notification (even when there was no notification).  We got rid of this, it no longer checks for notifications and will always make it's request. 
• We had the guardian bug where it repeats the main state when it gets an ezca connection error. 1122  This ezca connection error was caused by the dark offsets in the trans QPDs, and in the TR_X bank, which trigger LSC-XARM filters.  These offsets frequenctly cause us confusion because they aren't set in the dark offset script, but in the guardian in PREP_TR_CARM.  To avoid this confusion in the future Georgia added the adjustment of these offsets to PREP_FOR_LOCKING.  
• We've had many ezca connection errors for channels that the guardian should have been able to connect to so far.  
• CHECK_MICH_FRINGES unlocks the interferometer sometimes.  This state now tries to lock the michelson on a dark fringe, but if the alignment is too bad it can't lock and the beamsplitter saturates eventually causing a lockloss.  We could add some checks to this state to prevent this in the future.  

Further difficulties locking. 

• The microseism is around 0.8 um/second rms, and we can see that the arm cavities when free swinging are moving at about 2 um/second.  There is also wind, it is only gusting up to 20 mph, but on the Y direction at EY the seismometer shows about 0.15 um/second of tilt, which is higher than we normally have for this wind speed.  
• We are having trouble engaging ALS_DIFF, it works every few times.  
• We have had glitches in the Y arm, but we aren't sure if that is the cause of the problems. 

Dolphin diagnostics differences before/after today's EEPROM change (left chevron after, right chevron before)

< Date   : Tue Jan  8 13:24:38 PST 2019

> Date   : Tue Jan  8 09:43:36 PST 2019

<             EEPROM version             : 97  

>             EEPROM version             : 08  

<             EEPROM development ver     : 1  

<             Topology Autodetect        : No

>             Topology Autodetect        : Yes

<             PCIe slot state            : x8, Gen1 (2.5 GT/s) 

>             PCIe slot state            : x8, Gen2 (5 GT/s) 

<             Link 0 uptime              : 11585 seconds

>             Link 0 uptime              : 4218828 seconds

<             Link 0 state               : x8, Gen1 (2.5 GT/s) 

<             Link 0 required            : x8, Gen1 (2.5 GT/s)

<             Link 0 capabilities        : x8, Gen1 (2.5 GT/s)

>             Link 0 state               : x8, Gen2 (5 GT/s) 

>             Link 0 required            : x8, Gen2 (5 GT/s)

>             Link 0 capabilities        : x8, Gen2 (5 GT/s)

< [WARN] IXH Adapter 0 - PCIe slot link speed is only Gen1 

< ==> Local adapter 0 has 1 warnings.

As requested by Chandra, I have increased the upper alarm level for the beam tube vacuum gauges at MX from 5.0e-09 to 2.0e-08 Torr and restarted the alarm system.

-<Channel name="H0:VAC-MX_X1_PT343B_PRESS_TORR" low="1.0e-10" high="5.0e-09" description="VE gauge, MX X1-beamtube, CC">

+<Channel name="H0:VAC-MX_X1_PT343B_PRESS_TORR" low="1.0e-10" high="2.0e-08" description="VE gauge, MX X1-beamtube, CC">

-<Channel name="H0:VAC-MX_X5_PT346B_PRESS_TORR" low="1.0e-10" high="5.0e-09" description="VE gauge, MX X2-beamtube, CC">

+<Channel name="H0:VAC-MX_X5_PT346B_PRESS_TORR" low="1.0e-10" high="2.0e-08" description="VE gauge, MX X2-beamtube, CC">

TITLE: 01/09 Day Shift: 16:00-00:00 UTC (08:00-16:00 PST), all times posted in UTC
STATE of H1: Commissioning
INCOMING OPERATOR: None
SHIFT SUMMARY:
LOG:

• Corey covered most of the day, see his alog 46282 here:
• continuing the log:
  • TCS: chiller swap was a no-go, current chiller remains in service until a replacement chiller pump is located/purchased
  • RF MEASUrEMENTS:  continued until MX gate valves were restored to the open position
  • SQZ: HAM6 work continue, done for today
  • EE: Fil finished the ground wire at EY, and went to EX.  Shared that he had en encounter with some ALS cables/fibers, which was very helpful for understanding changes seen during the recovery of H1
  • BOOTFEST:  is complete
    • CDS: DaveB was done early afternoon
    • SEI: Jim restored HAM and BSC ISI's by the end of the day
    • GRD: TJ completed guardian updates, and tested BIG EARTHQUAKE before departing
  • Bubba returned from the LVEA
  • Fil returned from EX
  • Nutsinee and and Terry returned from HAM6/LVEA
  • Robert went to EX to make measurements around 5PM, currently there as of 6:30PM
  • no others known to be in Mid or End Stations

Chandra R., Gerardo M., Kyle R.

Today we removed the existing (iLIGO, circa 1998) 2500 l/s ion pump and replaced it with another iLIGO one which had been rebuilt.  GV14 and GV15 were hard-closed throughout the day to facilitate this.

This exercise provided an interesting data point.  The pristinely baked, dry etc... new ion pump internals/interior, though having been vented with dry N2 this morning to prepare it for installation, was, in fact, exposed to the higher-than-normal moist air (raining today) for a few hours while the pump exchanging was taking place.  This exposing is required and purging while being exposed for this short time frame isn't typically needed.  However, today, upon pumping back down, starting the pump and combining it with the X-mid volume, I was surprised at how "wet" the resulting pump had become as a result of this brief room-air exposure.  The resulting pressure was abnormally high and I was hesitant to expose X1 and X2 to this water load.  The interesting part is how rapidly this "water source" was depleted.  What this shows is that the water accumulation on the vacuum baked surfaces while exposed to the wet room air hadn't had enough time to permeate deeply into the surface and was, thus, easily and mostly removed in a short time period upon re-exposure to vacuum - fascinating!

For 30 watts of input power:

Arm Power = 127.2 +- 5.4 kW

SRCL Dither to Arm Power Measurement:

Long ago, Peter F came to Hanford and asked me to measure the arm power by moving the SRM.  The idea is to use the SRCL dither to cause the arm power to fluctuate differentially.  When the arm power fluctuates differentially, arm radiation pressure couples to DARM.
I measured the TF from SRCL to arm power transmissions RIN and SRCL to DARM at 30 watts of input power and 43 power recycling gain and SRCL feedforward off.  (Had to divide the DARM calibration by two because our DARM is calibrated such that LDARM = Lx - Ly, but I assumed LDARM = (Lx - Ly)/2.  This was particularly hard to find.)
I then fit some constants α1 and α2 to the TFs: α2/f^2 to the SRCL_ctrl/ArmPowerTransRIN measurements and α1/f^4 to the SRCL_ctrl/DARM, and recovered arm power via the equation

Parm = α1/α2 * π2 * mq * c

where mq is the mass of the ITMs/ETMs.  See the attached PDF for a more exposition to the above equation.  In the future we can just take the TF from Arm Power Transmission RIN to DARM.

Results:
α1 = 7.11 +- 0.07 × 10-13   (Attachment 2)
α2 = 6.6  +- 0.3  × 10-7    (Attachment 1)


From this measurement we can back out an approximate arm power gain.  The power in the arms is given by 
Parm = Pin * gP2 * garm2 / 2
where gP2 ≈ 43 is the power recycling gain and garm2 is the arm power gain.  

In a perfect, lossless world we would have garm2 = 282.  
In reality, we have garm2 ≈ 197

EDIT: Gabriele comments that for this low of an arm gain, our losses would have to be incredibly high, on the order of 5000 ppm.

EDIT: Stefan asked about the SRCL to Arm RIN fit differences between the arms.

There are two QPDs (A and B) at the ends of both arms.  Names are like H1:ASC-{X,Y}_TR_{A,B}_NSUM_OUT.  These QPD sums are used for monitoring the arm powers.
In Attachment 1, I refer to H1:ASC-X_TR_A_NSUM_OUT as X1, H1:ASC-X_TR_B_NSUM_OUT as X2, etc...
In the legend, we can see the individual fit values to each ArmTransRIN/SRCL TF to a α2/f2 model.  Each of these fits were made with a MCMC and had an uncertainty of around 0.8%

                                       QPD/SRCLctrl TFs
Model Value               X1           X2           Y1           Y2
----------------------------------------------------------------------------
α2               6.94 × 10-7   6.86 × 10-7  6.43 × 10-7  6.29 × 10-7

We can see that the X1 and X2 fits are close (within 0.6%), and Y1 and Y2 fits are close (within 1%), but the X and Y arm fits together are slightly different (within 4%).  
Looking at the PDF attached, we can say that the optical response of the Y arm to the SRCL dither γ is less than the optical response of the X arm.
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------


HEPI Offloading Measurement:


Results:

Change in HEPI offload for each arm during 2 to 20 watt powerup: (see Attachment 3)
ΔHEPI_X = -3287 +- 261 nm  (or +-8%)
ΔHEPI_Y = -3587 +- 246 nm  (or +-7%)

Change in X Arm Power from 2 to 20 W Input = 95 +- 8 kW
Change in Y Arm Power from 2 to 20 W Input = 104 +- 7 kW

Total X Arm Power at 20 W = 105 +- 8 kW
Total Y Arm Power at 20 W = 115 +- 8 kW

Estimated X Arm Power at 30 W = 158 +- 13 kW
Estimated Y Arm Power at 30 W = 173 +- 12 kW

Arm Power Ratio = Px/Py = 0.9 +- 0.1


As a double check of this arm power measurement I have been looking at HEPI offloading of tidal during INCREASE_POWER.
When the input power increases from 2 to 20 watts, HEPI moves due to the increase of radiation pressure by about 3000 nanometers in each arm.  
I fit a simple trend line to capture what the tidal servo was doing anyway, then subtract it at after around 400 seconds when the offload is complete, for 10 separate INCREASE_POWERs.  (Attachment 3)

We can use these results to estimate the arm powers, assuming all other things being equal in LSC->HEPI tidal offloading, and ΔHEPI_X = ΔLXarm:

HEPI Analysis

ΔPx = ΔHEPI_X * c/(4 k),
where k = DC compliance of the quad TST stage = 2.6 × 10-3 m/N.

If we trust the measured PRG of ~46 for each of these powerups, that would correspond to an arm gain of 
gXarm2 ≈ 230
gYarm2 ≈ 250


So this measurement reports much higher arm powers, but also a huge mismatch between arms (> 10%).



We can learn a lot more about the IFO from this measurement and others like it.  The end goal of this is to understand noise couplings to DARM, many of which are governed by these hard to measure numbers like arm power, power recycling gain, signal recycling gain, SRCL detuning and optical spring, DARM offset, coupled cavity poles, etc.  If we can make a more complete picture of the IFO, hopefully we will find some things that don't add up.

EDITTED for clarity of which measurement gave me which information, added the arm power calculations from HEPI offloading done with Sheila, and added comments from Stefan and Gabriele.  

A temporary FSS chassis (S1812014) was installed on ISCT6. I connected the +/- 18VDC to the chassis as well and left it powered that way. The accompanying +/- HV power supplies were placed on the floor inside the squeezer rack and connected to the chassis. The HV supplies were set to 180VDC as per their counterparts in the CER mezzanine and then turned off until they're needed. WP#8029

K. Kawabe, J. Kissel

Keita informed me of his worries that the PCAL timing monitor system is vulnerable to corruption. Here's why: The fast channels are captured with filter modules, which have excitation points. Some of the channels stored in the frames are the OUTs, which would contain both the monitor signal and any excitation. Further, we don't monitor the excitation point: because the PCALX system is used for continuous wave hardware injections, we must ignore the CDS STATEWORD bit that says "the user model is requesting an excitation" when we check for this before going into OBSERVATION READY. This bit is also what's typically used by the low-latency pipelines know that there's an unwanted injection, but it has been ignored and nothing else was used in its place. Thus, "vulnerable" to corruption by unwanted excitation.

As such, I propose the following changes:
 (1) Replace the capture of these signals with an EPICs readback and fast TestPoint instead of standard filter module. There's no need for filtration or excitation -- this is a monitor only system.
 (2) Re-organize and rename the channels to be a little more representative of what's going on.**
 (3) Bring the IRIGB monitor into the PCAL library part.

I attach a couple of screenshots that show the before-and-after.

The channel name changes would be as follows: 
$(IFO):CAL-PCAL$(END)_ [...]
   [...] FPGA_DTONE_IN1_DQ           >>   [...] FPGA_DTONE_ADC_DQ
   [...] DAC_NONFILT_DTONE_IN1_DQ    >>   [...] FPGA_DTONE_DAC_DQ
   [...] DAC_FILT_DTONE_IN1_DQ       >>   [...] DAC_DTONE_LOOPBACK_DQ
   [...] IRIGB_OUT_DQ                >>   [...] IRIGB_DQ


These channels will need to be updated in the GDS broadcaster, and any down-stream low-latency code that uses them (for example, the matlab / python scripts that are used to perform timing diagnostics for candidate GW events).

**As a reminder of what all these channels are, and the expected delay in between them, check out Evan Goetz's I/O Chassis Timing Schematic pcal_timing_schematics_LHOaLOG29259.pdf, from G1501170 and LHO aLOG 29259.

I've requested some further approval from interested parties, but otherwise the proposal is ready-to-install during tomorrow's maintenance day. If successful, I'll file the ECR for it to be implemented at LLO.

J. Kissel
WP #8028

After in-depth investigation, Shivaraj and Saravanan ("S and S") discovered I had made a rather insidious mistake in the calculations for the time-dependent correction factors (TDCFs) for the DARM loop's optical plant. See LHO aLOG 46135 for the full story, but the message is that -- because of poorly labeled basic complex algebra blocks and my lack of careful checking -- I had inserted a multiply when I should have inserted a divide when computing a ratio in the middle of the calculations of kappa_C, f_c, f_s, and Q_s. The bug has been fixed, the model has been compiled, and the plan will be to install it tomorrow when everything is rebooted to upgrade the EEPROMs of all dolphin front-ends (see WP #8030).

In detail, I've done the following:
    (1) I've extracted the D2N_SPRING block from the CS/TDEP level of the IFO generic corner station calibration library part,
        /opt/rtcds/userapps/release/cal/common/models/CAL_CS_MASTER.mdl
        and placed it inside the 
        /opt/rtcds/userapps/release/cal/common/models/CAL_LINE_MONITOR_MASTER.mdl
        to be consistent with what's done with the ACTUATOR_KAPPA and CAVITY_POLE library blocks. Once created as a library part in CAL_LINE_MONITOR_MASTER, I then copied it back into the CS/TDEP subsystem, now as a link to library block in LINE_MONITOR_MASTER. This change is solely for consistency with how things are done for every other TDCF; it does not affect any functionality.

    (2) In the common library
        /opt/rtcds/userapps/release/cal/common/models/CAL_LINE_MONITOR_MASTER.mdl
        I've added a "Description" under the "General" tab of every block's "Properties" pop-up window (opened by right-clicking on the block and selecting "Properties..." from the right-click menu) that is identical to the library block's generic name. Further -- switching over to the "Block Annotation" tab -- I selected the Description property token and put it on the list of text and tokens for annotation. This means that now any time the block is copied from the common library to where it will be used in practice, it will retain an annotation/label showing its basic generic function, even if the block's name is changed. This is especially important for the complex algebra blocks which are used repeatedly all through out a given subsystem level and thus requiring a block name change (hence my mistake that S and S discovered). This change is solely for clarity, and doesn't affect any functionality.
    
    (3) I slowly and carefuly re-copied and re-linked all uses of these basic algebra parts into the greater library parts for the ACTUATOR_KAPPA, CAVITY_POLE, D2N_SPRING, LINE_MONITOR (for PCAL_LINE demodulation), and SYNCED_LINE_MONITOR (for SUS_LINE) in the common library
        /opt/rtcds/userapps/release/cal/common/models/CAL_LINE_MONITOR_MASTER.mdl
        During this step, I fixed the bug that Shiva and Saravanan identified by replacing the complex multiply with a complex ratio to correctly take the ratio of live C and C_res at the tail end of the computation of S in the CAVITY_POLE and D2N_SPRING library blocks.

    (4) I re-copied and re-linked all uses of the greater library parts in to the CS/TDEP generic corner station calibration library part, 
        /opt/rtcds/userapps/release/cal/common/models/CAL_CS_MASTER.mdl

New screenshots of everything are attached, and all changes the two, above-mentioned, libraries have been committed to the userapps repo.

Sheila, Nutsinee

We made a two attempts to inject squeezing today, both times we eventually unlocked the interferometer when the LO servo unlocked. These two locklosses happened at 7:59 UTC and 1:23 UTC today.  

We've made some improvements to the automation. 

[Keita, Jenne]

Keita and I have been trying to figure out what is going on with the ISS that is causing the diffracted power to oscillate so largely the past few days.  When the IMC is locked, the ISS first loop, with the slow part of the second loop board but not the "second loop" as you would normally think of it, is causing the diffracted power to oscillate more than 1.5%.  This is very large compared to what it ought to be. 

In the attached plot, I have the peak-to-peak values of the diffracted power, from August 1st 2018 through yesterday.  I'm using the max and min of minute trends, so this won't catch if some short period of time has a small pk-pk value, but will see larger trends.  Data is only plotted here if the first loop is closed, the second loop is open, but the second loop is sending signal from the slow loop over to the first loop (yes, the ISS is confusing...).  That is, this should represent times when the IMC is locked, or we're trying to acquire IFO lock, but not times when the second loop is actually feeding back using IMC transmitted power (this is engaged in guardian once DRMI is locked). 

You can see that there was a time in ~September that the diffracted power oscillations were high, but then they got better.  Since the beginning of December, the peak-to-peak value hasn't been near it's normal small value. 

It seems like the second loop board is picking up more noise somehow, somewhere, and is feeding that through the slow portion of the board to the AOM.  When we turn off the output of the second loop board, we immediately see that the diffracted power becomes nice and smooth and quiet (we tried this briefly yesterday).  Still under investigation, but something is definitely not right.