I reduced the amplitude of the OMC ASC dither lines today, to [33, 50, 100, 100] counts for the [P1, P2, Y1, Y2] error signals, which are injected at [575.1, 600.1, 625.1, 65.1] Hz.  Along with the ever-increasing ASC goodness, this reduced the noise around the lines.  The attached plot compares the sidebands

We didn't observe any ill effects from reducing the dither amplitude (the SIN and COS gains were increased to maintain the overall loop gain).  At some point we should measure the loops again to check that the bandwidths are still in the tenths-of-Hz range.

In other OMC news, someone merged the H1 OMC_CONTROL medm screen with the Livingston version last week; this change has been backed out.  It's not a bad idea per se, but there are some scripts and buttons used here that aren't used by L1, and vice versa, so things were a little confused.  Also, the DCPD gains had been reduced to 1, from 1000, around 2:30 in the afternoon today.  This change was also reverted (maybe from a bad burt restore?) to keep the DCPD SUM channel calibrated in milliamps (rather than amps).

For some reason the OMC-DCPD_SUM_OUT_DQ channel is no longer accessible via ezca read.  This caused problems in the OMC_LOCK Guardian.

I've posted an entry into the LLO log, comparing the audio of the 2 strain channels.

After maintence day this morning, the corner beckhoff was not restored.  The ALS SHG was not working because the temperature was not controlled.  Before we realized this we went to the table to investigate and tried to adjust the beat note alingment.  Once the SHG was back on, the beat note stregth was low.  Although this sounds impossible, the thing that seemed to fix the problem was unplugging the RF amplifier and plugging it back in.  

Sheila, Elli

This morning I noticed the IR buildup in the arms as meaured by LSC-TR_X/Y_QPD_B is read out as 10% lower in the x arm than in the y arm.  This is unexpected because we think the loss in the x-arm is lower than in the y-arm.  Because of this we wondered if the normalisation of these QPDs is a little off.  To check this, I adjusted the gains and offsets of these QPDs to get the single-arm buildup of these equal to one.

Firstly the dark offset on the LSC-TR_X/Y_QPD_B QPDs was not correct (LSC-TR_Y offsets were of by 15% of the single-arm buildup power).  It looks like there is a slow drift in these offsets, and it looks like they have been corrected multiple times in multiple places.  To remove the dark offset, we unlocked theIMC so there was no light on the arms and adjusted the LSC-TR_X/Y_QPD_SUM_SEG?_OFFSET for segment so that it read zero.    The changes to the X_TR_A_SEG?_OFFSETs are:

Once the QPD segment offsets were set to zero, we were able to remove a few rouge offsets from other places.  We turned off offsets on H1:ASC-X_TR_A_SUM_OFFSET (was 8), H1:ASC-Y_TR_A_SUM_OFFSET (was 1), H1:ASC-X_TR_A_SUM_OFFSET (was 4), H1:LSC-TR_X_QPD_B_SUM_OFFSET (was 0.5), H1:LSC-TR_Y_QPD_B_SUM_OFFSET (was -0.2).

We changed LSC-Y_TR_A_LF gain from 0.017 to 0.0188 and LSC-TR_Y_QPD gain from 0.219 to 0.231  so that the y-arm single arm buildup is equal to one.  The x-arm buildup was close to 1 so we didn't change it.

Sheila, Evan, Elli

We adjusted SR2, SR3 alignment sliders to center the beam going into the output faraday and to maximise light going into the OMC DCPDs.   This was done with a straight shot through the sorner sation with BS, ITMY aligned, SRM, PRM, ITMX misaligned.  The input laser power was 10W.  We used the ASC wfs DC centering servos and the OMC dither align.

We moved SR2 pitch, SR2 yaw, SR3 picth, SR3 yaw alignment offsets one at a time and located the alignments the power on the DCPDs started to drop off.  There is about 70 microradians of range for each degree of freedom where the power is high (see screenshot).  We picked alignment values in the center of these ranges where the OMC DCPD power is also maximised.  The maximum power on H1:OMC-DCPD_A_OUT_DQ was 7.7e-3 counts in this configuration.

Changed values are:

Sheila then used the picomotors to center ASC-AS_C qpd, so we can use this to check the alignment into the output faraday.  Afterwards, Evan and Sheila re-centered the beams on the ASAIR photodides and the ASAIR camera.

(Kyle, Gerardo)

We pumped the annulus system for 4 hours, we got down to 5.0X10^-5 torr at the pump cart.  Pumping will continue on Thursday.

Kyle, Gerardo

Accessed BSC3 annulus ion pump via Genie snorkel man lift -> Used high output high voltage supply (60 mA) in an attempt to burn up internal shorting element without success -> Removed and replaced ion pump -> will pump with all day on Thursday maintenance with pump cart 

Scott L. & Ed P.

Cleaned and vacuumed all beam tube supports from single door south to X-1-4 double door. Cleaned 34 meters of beam tube in the same direction.
Continuous monitoring of beam tube pressures by the control room operator and regular checks by the vacuum crew. 

(Times are in PST)

602 P. King - Running transfer function measurements with H1 PSL ISS

713 P. King - Finished

730 Karen, Cris - LVEA

745 Jeff - LVEA to work on storage boxes

804 Andres - LVEA to meet up with Jeff

851 Doug, Bubba - LVEA

852 P. King, Ed M., Jason - PSL

857 Corey - To Squeezer Bay and Mech Room

901 Nutsinee - ETMY

908 Filberto - LVEA by the Y arm

915 Betsy, Gary, Guido - West Bay

919 Matt H. - LVEA Looking for 3IFO parts

933 Travis - Meet up with Betsy

934 Nutsinee - Back from EY

940 Dave B. - LVEA 3IFO Inventory

943 Greg - LVEA to find parts

946 Karen - To EY

946 Cris - To MX

952 Kyle, Gerrardo - LVEA to start the annulus pump on HAM1 and to use the snorkel lift by BSC3

954 Hugh - Opening large equipment access door in LVEA

959 P. King, Ed M., Jason - Out of PSL

1000 PraxAir - Delivery

1025 Mitchell - West Bay

1039 Richard - Out of EY Vac Supply Room Emergency Egress

1057 Karen - Leaving EY

*1114 Kyle, Gerrardo bumped BSC3 with genie lift (tripped WD)

1117 Filberto - MY to drop off cables

1120 Kyle - Banging annulus pump with hammer

1125 Mitch - Out of W Bay for lunch

1146 Andres, Jeff - Out of LVEA for the day

1159 Corey - Out of the Squeezer Bay for lunch, will return after

1202 Dave B. - DAQ restart

1203 Gerrardo - EX to pick up parts

1230 Gerrardo - Back from EX

1305 Cris - To EX

1311 Gary - LVEA

1345 Mitchell - To West Bay

1417 Jeff - LVEA

1435 Jeff - Out

1441 Sudarshan - To EY

1442 Travis - Both Mids

1501 Mitchell - Out

1507 Travis - Back from Mids, to LVEA

1515 Matt H., Eric - LVEA

1517 Corey - Out of SB

1557 Matt H., Eric - Out of LVEA, to Mids

Friday morning Jim and I unlocked WHAM1 HEPI and closed the position loops.  It looks like this reduces peaks at 2.5 & ~3.75hz, may have some gain peaking reinjection around 1hz and shows good pitch & yaw motion reduction below 1hz as seen by the RM1_M1_DAMP IN1s.

The attached ASD shows the RM1_M1_DAMP_L/Y/P_IN1_DQs.  The lower plot group has a couple HAM1 L4Cs.  The thicker light colored reference traces are from Thursday 0800utc and the dark thin current traces are from Saturday 0800utc.  There is a peak in the RMs at 6hz that may be amplified in the current traces; it is hard to tell but the ISI may be amplifying that peak.

Last night lock in DC readout lasted about one hour, with good stability of build ps on the on term. However, looking at the noise spectrogram, one can find some interesting non stationarities. The first plot is a spectrogram of the high frequency part, which is mostly stationary, except for a line at about 5 kHz which seems to ring down during the lock.

Twin peaks at 800-1000 Hz

Between 800 and 1000 Hz we've always seen two broad peaks, see the second attached spectrogram. Those peaks are usually high at the beginning of some locks, and gets lower. Out first guess was that they get better because the alignment is improved. However, during last nigh lock there was no human intervention to improve the alignment, and the two peaks got smaller with a time constant of about 15 minutes. It seems unlikely that they are mechanical modes ringing down, since they are too broad. There seems to be some correlation with a much narrower peak at 300 Hz: this peak roughly decay with the same time constant.

I ran my brute force coherence, and remarkably there isn't any signal showing any significant coherence with the twin peaks.

Mid frequency non stationarity

The noise in the 100-300 Hz region is still non stationary, altough the situation is much better than before (closing DHARD with high gain helped). The third plot is a spectrogram of the region, showing the noise moving up and down in amplitude.

The fourth plot shows the band-limited RMS in the region between 100 and 200 Hz, after notching out the 120 and 180 Hz main lines. The blue trace is the measured BLRMS, while the red trace is the least square fit to it using all mirror local sensors (ETMs, ITMS, PR*, SR*, BS). The reconstruction is quite good, at least for most of the slower variations. Using the same kind of code described elsewhere, I produced a list of the channels ordered from the one that contributes most to the one less important. This is shown in the 5th attachment. The channels are listed in order of descending importance. The blue bar shows how much each channel contributes to the BLRMS fluctuations. It seems that most of the noise non stationary is caused by residual motion of the SRM and PRM.

Another way to look into what is causing the residual angular motion is to use directly the ASC signals instead of the local sensors. The advantage is that ASC signals should be much cleaner than the local sensor. The drawback is that it's more difficult to trace back to which angular d.o.f. is important. The 6th and 7th attachments shows respectively the BLRMS fit and the channel ranking using the ASC signals. First of all, the reconstruction of the BLRMS fluctuations seems to be more accurate. It looks like that most of the BLRMS fluctuation can be related to AS_B_RF45_Q_YAW, including both the linear and quadratic terms. This signal was not used for any ASC loop (we are using AS_A_RF45_Q for DHARD). This is a bit surprising, since the BLRMS fit using local sensors pointed to a picth motion as he largst contribution, while the ASC signals point to a yaw motion...

Wandering lines

Looking again the the low frequency histogram (third attachment), there are at least two narrow lines that slowly move in frequency. They are at about 168 and 249 Hz. It seems to me that they move in a correlated way. They might be generated by some fan or other spinning electromechanical device. I can't find any coherence with environmental channels, but the lines are coherent with SRCL and LSC-POP_A_RF45_I

As part of the WFS auto-centering ECR and the EOM Driver ECR a couple of new channels were added:

• LSC-MOD_RF9/45_AM_... in the LSC front end (EOM drivers)
• LSC-MOD_RF9/45_AM_... in the corner EtherCAT system PLC1 (EOM drivers)
• ALS-X/Y_WFS_AUTOC_PZT1/2_... in the end EtherCAT systems PLC1 (PZTs for auto-centering)

Since the hardware is still in manufacturing, this currently connects to nothing.

J. Kissel, D. Barker,

Hearing about LLO's miss-hap with an Dolphin PCIE, IPC error causing an errant ISI watchdog trip (LLO aLOG 17036) I was reminded of when Dave and Vincent had implemented an allowance for (what they thought was) 10 [errors / sec] during the H2OAT when such errors were triggering these types of false alarms all the time (see LHO aLOG 5373, or in WP 3698). Poking around the BSC-ISI models to see if any of that was still implemented (since it was all implemented at the top-level of the model, not a part of any library), I found that ISI ITMY still has some of this residual stuff, but the other 4 BSC-ISIs do not.

Check out the first attachment for how it's implemented for ISI ITMY: -- the error rate spigot is fed into a comparator with a constant 150, and the output of the comparator is fed into the ISIPAYLOAD block. But this is sort of bogus. You cal tell that the *idea* was to send an error if the rate (in [errors/sec]) was higher than 150. But in the front end, running at 4096, the errors per *second* will either be 0 or 4096, and it's unclear what happens on a cycle-by-cycle basis. I like the idea, but the implementation doesn't really make sense.

The second attachment shows the beam splitter's implementation, which is identical to the other 3, non-ITMY chamber's implementation -- and to how LLO has theirs implemented. The error rate is inverted, which means if the error rate zero, the payload block gets a 1 (for "running" or "OK"), and when the error rate is non-zero, the payload block gets a 0, and trips the payload flag because it thinks the model is 0xDEADBEEF. This is an OK implementation, but it only is really useful for that use case scenario, where the SUS model is permanently down, AND it's bad for the use case where there's a single drop in communication in any cycle within a second. 

Then I check to see what the HAMs are doing. Hooray! Something different! These guys have a block that I'd never seen before, an "ISI_RFM_ERROR_CONVERTER." This a part of the ${userapps}/isi/common/models/isipayloadwd.mdl library, which has the following helpful note above it:
"Dolphin RFM error logic inverter. ISIPAYLOADWD is coded to work with EZCAREAD parts which use 0 for not connected, and 1 for connected. Dolphins RFM error channel reports errors per second so 0 is good (no errors) and or more is bad (up to the rate the code is running at)."
Inside is a choice block, which passes 0 if the error rate from the IPC block is greater than 0, and 1 otherwise. So, this is really just a glorified version of what's implemented on the non-H1ISIITMY BSC chambers at LHO and LLO. And the same use-case flaws apply.

We should 
(a) Make sure all chambers at both sites are doing the same thing, and
(b) Allow for more than one cycle's worth of errors -- infact allow for several seconds worth of errors -- before tripping the ISI via the payload flag's IPC connection failure.

Added 128 channels. Removed 91.

Yesterday, after our snapshot fest from last week, I pushed all of the SUS safe.snap files to SDF.  I then cross referenced a bunch of the ISC/LSC/ALS/IMC guardians and hand-tuned out channels that are already being monitored by them.  There are still 2-6 channels showing differences on 6 of the SDF SUS monitors.  I'll look at what commissioning is doing to either remedy or ignore them.

I've committed all of the sus safe.snaps to svn.

Bottom Line--When using Guardian, engaging the RZ loop twists the MICH too far.  It may be doing the CPS Offset zeroing in a weird method.  When the loops are engaged with the old Command Scripts, the RZ input does not get driven off and no bad RZ twist occurs.

Further, with MICH locked, the X & Y ST2 ISO loops are not stable--they ring up and trip.  Without Mich Locked, the loops are stable.

Details: Let's start with the first attachment; it is 25 minutes of second trends.  The Guardian turns on the Z loop after first LOAD_CART_BIAS_FOR_ISOLATION so this is the first thing to do.  Manually one can do this on the CART_BIAS screen (Reset CPS offsets button.)  In outward appearances, there is a difference in how this button and Guardian perform this operation; however, Jamie says no it doesn't.  Maybe it is the slow ramping of the new setpoint.  Anyway, my observation is that the residuals for this platform are always small.  After the CPS offsets are Reset, the Guardian turns on the Z dof.  The gain steps and the ramp times are the same for the Command Scripts and Guardian.

Using the Command Scripts, engaging the Z dof ISO is seen at point 1.  Notice how at point 2, the RZ INMON is not doing anything awful while the Z loop is turned on and the RZ loop turns on (point 3) nicely and well behaved.  However, when Guardian does this...

When Guardian turns things on at point 4, look at what happens to the RZ INMON.  The Z_OUT16 is much larger when Guardian turns it on and the RZ_INMON is driven way off.  And, even though the RZ_INMON is much lower by the time the RZ loop comes on, turning on the RZ loop at point 5 produces a too large an output--The RZ_OUT16 looks just like the OpLev Yaw.

You can see that the manual turn on of the Z then RZ loop was repeated a few times with the same result; like wise the Guardian turn on was similarly consistent.  Of course, Guardian also turns on the X & Y DOFs when it engages the RZ loop and as I allude to in the summary above, these loops may be unstable.  However, at this point I return you to the point of how the Z_OUT is so different for Guardian and how that impacts RZ_INMON all before the X Y & RZ loops are engaged.

I left the ST2 in fully isolated and later Ellie locked the MICH.  After a minute or so, it didn't look stable and MICH was turned back off.  Shortly after that the ISI tripped.  So then we tested things.  Ellie locked MICH and then I engaged the ST2 ISO Loops.  Things were fine with the Command script turn on of Z and RZ but the ISI slowly rang up and tripped on either X or Y DOF even without the boost on.

Solution--Identify why the Command Script and Guardian do something different at the CPS Reset stage.  Identify the loop instability.

J. Kissel

While poking around the CAL-CS model after the recent changes (see LHO aLOG 17034), I noticed two things:
(1) All of the EPICs settings had been lost, even though I'd made sure to capture a safe.snap of the model before restarting the front end model. Not sure what happened there. In the mean time, I've burtrestored the model to 02:10a PST (i.e. before I got started, while DARM was locked, happy, and producing megaparsecs), which hopefully has captured / restored most of Kiwamu's hard work (LHO aLOGs 16698, 16733, 16780, 16798, and 16843).

(2) Because of a version control mix up in the CAL_CS_MASTER.mdl library part, the names for the whitened versions of the closed-loop and open-loop DARM displacement signals, i.e. (what are now) H1:CAL-CS_DARM_RESIDUAL_WHITEN and H1:CAL-CS_DARM_DELTAL_EXTERNAL_WHITEN have changed since we last updated the h1calcs model. The bank names are now typo free -- but that means I've had to re-install the 1^5 : 100^5 (5 zeros at 1 [Hz], 5 poles at 100 [Hz]) whitening filter used to get above the double precision noise in frame storage (see LLO aLOG 16789). 

Maybe I'll ask my fellow detector engineers to help me get an SDF system up and running for this model, so we can better track the changes.

Gabriele, Sheila, Alexa, Evan

Summary

We have engaged the DHARD WFS Y (and P) at 3 Hz on resonance with a reduced oplev damping gain in the ETMs. Again, to start off we closed the DHARD Y WFS  with 3 Hz BW at 50pm CARM offset. Since this loop is also stable at low BW, we will leave it in the low BW configuration at this point, so that we are at a 3 Hz BW on resonance.

Details

We had tried engaging the new DHARD Y loops as described in LHO#17006. However, we quickly found that this configuration was unstable. So, we removed the partial plant inversion FM6 and took a plant TF. We found that the plant that Gabriele had measured with the oplevs was slighlty different than the @50pm plant (see Gabriele's comment). We adjusted FM6 accordingly to compenstate for the peaks seen between 1 and 5Hz. FM6 is now zpk([-0.3303+i*15.1459;-0.3303-i*15.1459;-1.9027+i*16.6711;-1.9027-i*16.6711; -0.2672+i*19.227;-0.2672-i*19.227],[-0.6659+i*18.7;-0.6659-i*18.7;-0.509+i*11.519; -0.509-i*11.519;-1.0404+i*15.4844; -1.0404-i*15.4844], 1)gain(0.469248).

To close the loop at low BW at 50pm CARM offset, we engage FM2, FM3, FM4, FM6, FM9 with a gain of 30. FM6 is described above, and the remaining filters are the same as in LHO#17006. With a gain of 360, this gives a UGF of 3 Hz and a phase margin of 36 deg.

On resoncance with a gain of 30, we measured that the UGF is 3.5 Hz with a phase margin of 36 deg.

This is in the guardian now.