WP 7758

I have linked the variables in the system manager and committed it to svn. The additional channels are now in EPICS:

H1:PEM-X_FENCE_WIND_SPEED_1_MA
H1:PEM-X_FENCE_WIND_SPEED_1_MPS
H1:PEM-X_FENCE_WIND_SPEED_2_MA
H1:PEM-X_FENCE_WIND_SPEED_2_MPS
H1:PEM-X_FENCE_WIND_SPEED_3_MA
H1:PEM-X_FENCE_WIND_SPEED_3_MPS
H1:PEM-X_FENCE_WIND_SPEED_4_MA
H1:PEM-X_FENCE_WIND_SPEED_4_MPS
H1:PEM-X_FENCE_WIND_DIR_1_MA
H1:PEM-X_FENCE_WIND_DIR_1_DEG
H1:PEM-X_FENCE_WIND_DIR_2_MA
H1:PEM-X_FENCE_WIND_DIR_2_DEG
H1:PEM-X_FENCE_WIND_DIR_3_MA
H1:PEM-X_FENCE_WIND_DIR_3_DEG
H1:PEM-X_FENCE_WIND_DIR_4_MA
H1:PEM-X_FENCE_WIND_DIR_4_DEG

Only the 1st, 2nd and 4th wind speeds and the 1st wind direction have working sensors.

Sheila, Georgia, Craig

LSC:

This afternoon we had difficulty locking the interferometer, in part because we didn't have the same alignment as we had tuned the CARM offset reduction for.  Georgia and Jenne did an initial alingment that brought us back to a similar recycling gain to what we had sunday and monday evenings.  As soon as the control room quieted down and we stopped trying to use DRMI ASC the interferometer locked easily with the same guardian sequence and settings that worked earlier. 

We manually went through the steps in DRMI_ON_POP, but based on loop gain measurements (attached) we opted not to engage the MICH boost or turn the DARM gain up by the factor of 3.5 that the guardian would have used (we have been skipping a gain reduction by 2 step in the CARM offset reduction so this mostly comes out in the wash).

ASC:

We made some changes in the PREP_ASC_FULL_IFO, (it turned on PRC1 and PRC2 by mistake, and was missing a run state. Now it is turning the gains to zero.)  Now we are able to let the gaurdian proceed to this state.  We have been manually adding gain to DHARD P by engaging FM3 and increasing the gain to -30

We went to ISCT1 and found that the beam was falling off of POP X, so Georgia centered it.  We also found that the input matrix for DC6 was used for something else.  We should add the DC6 settings to the guardian to make sure they get set. 

We moved PR3 in pitch and saw that the signal was mostly in Q, so we shifted the phases by -90 degrees.  (When I accepted this in SDF I see that there are many phase changes in the ASC SDF, it might be helpful to accept them).  We checked this with an 8 Hz dither to PR3 M3.  After that we were able to close the PRC2 loops with the gain that is in the guardian.  They are only going to M1. We did not try engaging the integrator, but it should be fine.  

We checked that the lock point of INP1 looks good, and the pitch loop seemed to turn on fine with the gain of 1 that is in guardian, but yaw went in the wrong direction.  

I think that we the most efficient way to make progress is to find an alignment that gives us a better recycling gain before we try to use the DRMI ASC.  Our locking today started to go much more smoothly as soon as we stopped trying to use the DRMI ASC.  The easiest way to search for a better alignment would be to close more of the ASC loops in full lock and try moving spot positions. 

J. Kissel

Using the lock stretch that Sheila called out in LHO aLOG 43263, I gathered data that shows the new violin mode forest after we've replaced ETMX, ETMY, and ITMX (with ITMY been exposed to air for ~9 months, which undoubtedly also changes the violin mode frequencies). Attached are comparisons of the Fundamental (~500 Hz), 1st Harmonic (~1000 Hz), and 2nd Harmonic (~1500 Hz) DARM ASDs from O2 (after the July 2017 EQ) and this most recent lock stretch.

I've begun to update the LHO violin mode table (Violin_Mode_Table_v2) in prep for identification of this new forest. I've used the in-air data from LHO aLOGs 40525, 42180, 38857.

So far, I can identify 29 of the fundamental 32 modes, with a 2 mHz resolution. They're tabulated below (and not yet in the table), since I've not yet associated them with a test mass (though some appear to be "obvious" given the large separation).

In hopes to identify the mode Sheila calls out as the worst, I've pushed a 503.085 Hz filter to all new test masses, on MODE 1. This way when we do get a decent lock stretch, we can identify the mass "passively" by turning on the filter with some small gain, to see on which test mass we get action. As before, we'll started by assuming the mode is controllable by driving in Pitch.

In order to gather this data, I just used the standard violin mode templates from O2 (see LHO aLOG 37921), which are linked off of the VIOLIN MODE monitor MEDM screen.

Summary: Both injection based noise projections of HAM1 HPI Z to DARM indicate that vertical motion was a limiting noise source for O2 from 10- 17 Hz.  These projections also suggest that there is a another coupling of HAM1Z to DARM in addition to the coupling through the refl wfs.  

The first attachment is a plot from our noise budget showing a projection of CHARD noise to DARM (based on injections made June 14ths 2017) and HAM1Z motion to DARM (based on injections made in March 2017).  The projection of HAM1 Z to DARM roughly matches the projection of CHARD to DARM up to about 13 Hz, so the coupling HAM1Z-> REFL WFS -> DARM can probably explain this noise.  However, above 15 Hz, the projection for HAM1Z is larger than the projection for CHARD.  I've also attached screenshots of the CHARD injection data, you can see that the CHARD motion was increased by 2 orders of magnitude up to 100 Hz, so the upper limit that we get from the CHARD projection is below the noise that is predicted by the L4C projection above 15 Hz.  

I also looked at coherence of CHARD and the HAM1 Z with DARM for 1000 averages on July 3 2017.  This also indicates that there is coherence with the HAM1 Z L4Cs above the frequencies where the CHARD loops can explain it. The final attachment is a projection based on these coherence of the noise in DARM.  This kind of measurement isn't as convincing as the injection based projection because there could be other explanations for the coherence, and I might be having a problem with numerical precision in DTT with the CHARD drives.

I modified the LASER_PWR guardian so that if we're doing initial alignment, it moves the rotation stage quickly (the same rate that we usually use to go back to 2W), but if we're doing regular locking, it still uses the slow rate to increase the power.  This should save us dozens of seconds during initial alignments, since we won't have to wait so long for SRY and MICH.

TVO, TJ, Hang, Danny

TJ, TVO and I had a discussion yesterday on how to better center the Hartmann beam on the ITM. We noted that we did not currently have an idea of how the HWS ITMX and HWS ITMY upper periscope picomotors are calibrated so we decided that moving those mirrors in a random (but well noted) direction, then running an ITM ring heater test should provide enough information for a decent calibration. Before we left the site we moved both HWSY and HWSX upper periscope mirrors on the corner table 100 counts to the left and 100 counts down from the previous position in alog 43288 . Hang ran the ITMX and ITMY ring heaters after for 12 minutes at 2 watts (4 watts total for each ITM) last night. Attached to this post are the contour/gradient plots as well as the prism and spherical power trend data. 

It's important to note that in these tables we use the following: Distance of the Hartmann beam from ITM center = abs((Max change in prism)/(Max change in spherical power))

8-8-2018 ring heater measurement*  (12 minute, 2 watts) 

8-7-2018 ring heater measurement (1 hour, 3 watts)

We estimate how many cms the upper periscopes move per count in each direction: 

*Note: there is a small particulate that can be seen on ITMX HWS we think that it is a bit of dust one of the on table optics. Also, there is probably clipping on the iris right before the CCD. Both of these things could be messing us up. Attempts at removing the particulate and future measurements are coming very soon.

Seems like overall we made things worse. Will probably move things back 100+ counts up and 100+ counts right to push the beam in the correct direction. 

Peter K, Georgia M

We installed anodised aluminium beam dumps behind the top mirrors of the X and Y periscopes on the corner station Hartmann table.

This dumps the ALS transmitted beam that passes through the frosted backs of the top mirrors.

The digital video camera h1cam19 has a new name: 'SQZT6 OPO GR TRANS (h1cam19)' ('GR' has been added to show this is looking at green light). The digital video MEDM overview screen was also changed. I found the new name length exceeded the space available on the MEDM window, so the buttons widgets were resized accordingly.

Marc Daniel

We added the boost/notch filters, D1000798-v2, to the slow path of all squeezer common mode boards. The measured transfer function is pretty close to the theoretical one, see T1800112-v1.

The ISC_DRMI guardian died, and it's not really clear to me why.  I append to this alog the logfile.

I did a "guardctrl restart ISC_DRMI" in a terminal window, and we seem to be back and running.  Dave is looking more into why this might have happened.

2018-08-08_17:34:06.034404Z ISC_DRMI [PREP_DRMI_ASC.main] ezca: H1:SUS-IM4_M1_LOCK_Y => ONLY ON: INPUT, FM1, FM2, OUTPUT, DECIMATION
2018-08-08_17:34:06.353868Z ISC_DRMI [PREP_DRMI_ASC.main] ezca: H1:SUS-BS_M1_LOCK_P => ONLY ON: FM1, FM2, FM9, LIMIT, OUTPUT, DECIMATION
2018-08-08_17:34:06.651603Z ISC_DRMI [PREP_DRMI_ASC.main] ezca: H1:SUS-BS_M1_LOCK_Y => ONLY ON: FM1, FM9, LIMIT, OUTPUT, DECIMATION
2018-08-08_17:34:06.785028Z ISC_DRMI [PREP_DRMI_ASC.main] ezca: H1:SUS-PRM_M1_LOCK_P_SW1S => 20
2018-08-08_17:34:07.079318Z ISC_DRMI [PREP_DRMI_ASC.main] ezca: H1:SUS-PRM_M1_LOCK_P => ONLY ON: INPUT, FM1, FM9, LIMIT, OUTPUT, DECIMATION
2018-08-08_17:34:07.821424Z ISC_DRMI stopping daemon...
2018-08-08_17:34:07.821424Z ISC_DRMI daemon stopped.
2018-08-08_17:34:07.821424Z Traceback (most recent call last):
2018-08-08_17:34:07.821424Z   File "/usr/lib/python2.7/runpy.py", line 174, in _run_module_as_main
2018-08-08_17:34:07.839717Z     "__main__", fname, loader, pkg_name)
2018-08-08_17:34:07.839717Z   File "/usr/lib/python2.7/runpy.py", line 72, in _run_code
2018-08-08_17:34:07.840626Z     exec code in run_globals
2018-08-08_17:34:07.840626Z   File "/usr/lib/python2.7/dist-packages/guardian/__main__.py", line 287, in
2018-08-08_17:34:07.851505Z     main()
2018-08-08_17:34:07.851505Z   File "/usr/lib/python2.7/dist-packages/guardian/__main__.py", line 278, in main
2018-08-08_17:34:07.852405Z     guard.run()
2018-08-08_17:34:07.852405Z   File "/usr/lib/python2.7/dist-packages/guardian/daemon.py", line 450, in run
2018-08-08_17:34:07.852405Z     raise GuardDaemonError("worker exited unexpectedly, exit code: %d" % self.worker.exitcode)
2018-08-08_17:34:07.852405Z guardian.daemon.GuardDaemonError: worker exited unexpectedly, exit code: -11
2018-08-08_17:34:08.497836Z guardian@ISC_DRMI.service: Main process exited, code=exited, status=1/FAILURE
2018-08-08_17:34:08.498048Z guardian@ISC_DRMI.service: Unit entered failed state.
2018-08-08_17:34:08.498054Z guardian@ISC_DRMI.service: Failed with result 'exit-code'.

The OPO TEC controller settings were changed to have a faster and stabler servo.

These coefficients are from LLO, which should work for both in-air and in-vacuum.

Loop Shape:

Gain: 700e-3   UGF: 60e-3 Hz

Before:

Gain: 300e-3   UGF: 60e-3 Hz

   The air quality at the site continues to be poor. Today's morning counts are higher than they have been for the past few days. In the unlikely chance there is a change in the predominate weather patterns these conditions will prevail at least until the weekend.

   07:45 - At the door of the staging this morning counts were 6.9 million at 0.3um and 618,000 at 0.5um/ft3.

   09:30 - Outside the control room door this morning counts were 6.4 million at 0.3um and 560,000 at 05.um/ft3. 

      

E1800220
T1700433

Entry for work completed on 8/7/2018

With the addition of two EP3174-0002 Beckhoff terminals (part of the wind fence study at EX), the network topology at EX was upgraded per T1700433. The following components were installed in the facility rack in the VEA:

1. CU1521 EtherCAT media converter
2. CU1128 EtherCAT hub

A MM fiber was pulled in from the ISC-C1 rack to the FAC-R1 rack. The following components were connected to the new Beckhoff hub:

1. D1400005 Illuminator Chassis - Port 2
2. D1301017 Baffle Photodiode Amplifier - Port 4
3. Wind Fence Interface Box - Port 5

F. Clara, E. Merilh, P. Thomas, D. Sigg

WP 7749 (Add GS13INF..._OUT to Frames)  FRS 11049 (HAM2 & 3 GS13 Gain Switching failure)

I've only looked at the first switch failure closely but I have many more in the can (just ask the operator JeffB) now with the model change adding the GS13INF_.._OUT channels to the frames.

My theory at the moment looking at the first trip is that the corner 2 & corner 3 switching is cross wired.  I don't know where yet as that mapping is complex--working on it.  Meanwhile...

Look at the attachment and listen to my story...

After getting the GS13INF_OUTs into the frame, I put the platforms into nominal ISOLATED state except the GS13s were in the low gain mode.  I manually toggled off every filter for the GS13 gain state and noted the success of the switch.  For HAM4, every filter switched with out bothering the platform.  On HAMs 2 & 3, corner 1 H & V all switched with out bothering the platform.  Conversely, on HAMs 2 & 3, corners 2 & 3 both H & V, every switch of FM 4 or 5 tripped the platform.  I did not repeat every switch because the trips took time to recover, and, trips of the verticals on the ISI also tripped the SUSs on board.  However, every repeat yielded the same result as noted, there was no inconsistent result.  So I zoom into the first trip when I toggled the DW filter on HAM2 H2:

1/2 second of data displayed. Note the H2 (corner 2) SWSTAT change as the FM5 Dewhitening filter changes state.  So you can see that the H2 signal (upper left green) gets more high frequency noise even compared to before the switch when the analog whitening is on and its digital DW filter is on; so the digital DW goes away but the analog whitening is still on.  Conversely, looking at the H3 GS13 signal (lower right,) the analog & digital whitening and dewhitening filters are on and then the analog whitening is disabled and the digital dewhitening remains on and the signal gets very clean.  Note that the H1 GS13 signal is unaffected.

So, bottom line, current theory: corner 2 digital filter is wired to corner 3 analog filter.

Why it could be happening.  Maybe best bet is the problem where long long ago, the PSL group asks SEI/ISI to change feedthrus on the chamber because cables they had would not reach the flange.  Normally on the ISI, corners 1 & 2 are near each other because the first CPS satellite crate has room for two corners ( there is not a separate crate for each corner on the HAMs.)  When SEI changed to a different chamber feedthru, ISI cable length limits necessitated putting corners 1 & 3 into the same CPS satellite crate.  We wanted all a corner's channels to go to the same feedthru so GS13 and coil drivers cables were also moved (see SEISMIC REFERENCE note on D1002873.)  Since the CPS channels from a crate are on the same cable, corners 1 & 3 go into the same Interface chassis and hence the model must reflect this difference.  It is around here that I suspect the problem.

The python command scripts must manage to most of the time switch the corners 2 & 3 quickly enough that it seems to work, usually.  The guardian scripts however must do it just enough more slowly that it blows up.

I'll look at the other switches done and see if this story all holds up.

Dick, Marc, Nolan

Replaced 6 baluns in ISC Racks R1 and R2. The insertion loss and phase shift through each balun was measured prior to installation, and compared to the phase shift through removed balun. Serial numbers, locations, bode plots and phase differences for each are annotated in the attached file (Doc and PDF formats). Noise measurements are attached, with most recent measurement (Aug 7, 2018) after replacement of final 6 baluns in green.