Kiwamu, Stefan

We noticed that in full lock (before power up) we again have questionable WFS. Indeed it seems to again be SRCL1 YAW that runs away - slowly at low power, but rapidly at high power. This is all a deja-vu, see elogs 18442, 18923, 18931.

More investigation suggested that it is actually the QPD loops that pull us into a regime where the other loops are not stable. So for now we changed the QPD loop offsets at low power to just keep us at the same location:
  New values: H1:ASC-X_TR_A_PIT_OFFSET H1:ASC-X_TR_B_PIT_OFFSET H1:ASC-X_TR_A_YAW_OFFSET H1:ASC-X_TR_B_YAW_OFFSET
   -0.084
   -0.212
   -0.023
    0.006
  Old values: H1:ASC-X_TR_A_PIT_OFFSET H1:ASC-X_TR_B_PIT_OFFSET H1:ASC-X_TR_A_YAW_OFFSET H1:ASC-X_TR_B_YAW_OFFSET
   -0.029
   -0.158
   -0.007
    0.105

However we still lost it on POWER UP. More work needed here.


We also reverted the changes from earlier today (alog 19511): ETMX ISCINF gain back to 1, and the L1 gain back to 0.28. This now gave us a lower peak-peak ESD drive and - unlike earlier today - ALS DIFF engaged just fine... (no idea why it acted up earlier...)

Evan, Nic, Stefan, Elli, Sheila

After spending some time to recover alignment, fiber polarization, turn TCS back on, ect, we have started to attempt locking. 

The first problem we ran into was that ALS DIFF was not locking, the first problem we found was that the linearization was off.  In addition, it seems that the ESD gain has been reduced by a factor of 2 after the vent and discharging.  The attached screenshots show the OLG and crossover measurements with a factor of 2 added in drivealign, they match the references well this way.  The green reference in the OLG measurement shows the gain when we managed to lock with the nominal settings from before the vent.  

We have edited the guardian to add a factor of 2 gain in ETMX ISCINF, and reduced the L1 gain from 0.28 to 0.14 to keep the crossover around 1 Hz.  The drives with DIFF locked are attached.  

We were able to lock on DC readout, but Evan found that the DARM gain was 4dB too high, so he reduced the gain in the DARM filter bank to 900 from 1200.  We made it to DC readout and lost lock durring the power up.  

More charge measurements on ETMs. Plots are attached.
Still no charges.

Earlier today, I wrote a couple out of loop feedforward filters to the BS ISI foton file using Foton. When I hit the load coefficients button (while the ISI was isolated, the ff paths were off, so it shouldn't have done anything), the ISI tripped, hard. It rang up the T240's pretty bad and I couldn't isolate the ISI for several minutes after. Worried I had inadvertantly written some other filter I ran a diff on the most recent archived file and the file created yesterday when Jeff restarted the models. This showed a whole bunch of filter coefficient differences, which shouldn't have been there (as reported by a diff of the two archive files, I don't know exactly what changed, see attached). Talking to Jim, Dave and Jeff, it sounds like the glitch was probably caused by my having used Quack recently (June 22nd) to load some blend filters. Jeff's model restart (and even a prior model restart on June 30) simply inherited that quack-written file. Today was the first time the BS's foton file was opened and saved in Foton. Quack can apparently load coefficients with higher precision than Foton will accept, so when you open and save a "too high" precision filter with Foton, it rounds the coefficients off. Sudden change in precision of SOS coefficients in the blend filters = bad for isolation loops = bad trip.

We've seen this Foton vs. Quack Rounding problem before -- see e.g. https://alog.ligo-wa.caltech.edu/aLOG/index.php?callRep=3553 -- and it's still biting us.

This sounds like a relatively easy thing to control for, I can think of two ways:

- getting Quack to check and do the rounding on it's own before writing to the Foton file.

- have the post-build script run a "foton -c" on all filter files before the model gets restarted.

Is there someone in the CDS group who can fix this? Maybe it has been? There are several versions of Quack running around, June was my first attempt with it, maybe I used the wrong one.

I used /ligo/svncommon/SeiSVN/seismic/Common/MatlabTools/autoquack.m

 https://svn.ligo.caltech.edu/svn/seismic/Common/MatlabTools/autoquack.m

Last Changed Author: brian.lantz@LIGO.ORG
Last Changed Rev: 7939
Last Changed Date: 2014-02-14 15:38:15 -0800 (Fri, 14 Feb 2014)
Text Last Updated: 2014-02-14 15:48:16 -0800 (Fri, 14 Feb 2014)

0712 - Joe Gleason to EY

0715 - J Gleason out

0858 - Jim W finished with BSC measurements

0859 - Leonid starting charge measurements EX/EY

0900 - Fil to EX for ALS fiber conduit install

0923 - Richard to EX to help Fil

0924 - Jordan, Vincent to EX for PEM cabling

0934 - Gerardo to EX prep for gate opening

0953 - Richard back

1000 - Kyle to EX

1114 - Nutsinee to EY for PCal measurments

1115 - Vincent to CER

1121 - Vincent out but then to LVEA for PEM cables

1125 - Bubba at EX (according to card reader)

1127 - Kyle, Gerardo back from EX and goin intot the LVEA to HAM6

1138 - Ed to EX to adjust OpLev

1139 - Nutsinee back

1155 - Kyle, Gerardo out

1232 - Fil to MY

1323 - Gerardo, John, Bubba at EX

1408 - HEPI alarm. Pump pressure was "Not Okay" Hugh was contacted(see alog)

1410 - Hugh to EY to investigate

1445 - Kyle to EY

1506 - Kyle back

1550 - Elli, Sheila to LVEA to turn ON CO2X laser

1558 - Elli, Shelia out of LVEA and now going to the Ends to turn ON the ring heaters

This morning when Jim B. restarted H1IOPSEIH23, I forgot to set the IMC_LOCK Guardian to OFFLINE. The IMC kept its lock but the WFS ran away with the HEPI misalignment. To avoid this in the future Jeff, Sheila, and I decided to have IMC_LOCK check that the SEI managers for HAM2/3 are ISOLATED. I added a new decorator to the IMC_LOCK  Guardian (@sei_state_checker) that will make sure HAM2 and HAM3 SEI managers are in the ISOLATED state. If they are not, it will return the MOVE_TO_OFFLINE state. OFFLINE is now a protected state(redirect = False) and has a run condition that will not allow the Guardian to move on unless the SEI managers are ISOLATED (Thank you, Jamie). The idea behind this is to allow the the node to "wait" in OFFLINE until the SEI managers are where they should nominally be.

I reloaded the Guardian with the new code and committed it to the SVN.

**EDITED Wed July 8, 2015  15:36 PST**

We are sliding backwards in our efforts to quiet the pressures at EndX.  EE's latest test in the grounding has increased the noise on the pressure signals.  As a result, I've opened up the no-alarm region of the differential pressure to +-6 psi.  Remember, a momentary pressure glitch is pretty harmless and meaningless; but, an alarm that is sustained must be addressed asap.

~1500 hrs. local -> Adjusted boil-off pressure regulator 1 full turn clockwise

My script which reads the digital video ITM green image's X,Y,SUM and writes them as EPICS values to the ALS end station model (as YAW,PIT,SUM) has been extended to run on the X-arm as well as the Y-arm.

I have created an MEDM screen (H1CDS_CAMERA_COPY.adl, see attachment) which is accessible from the SITEMAP via the CDS pull down (last item on list).

The script runs within a screen environment on h1fescript0 as user controls

The last time the OverVoltage while running at SetPoint occurred was 14 July 2014.  Restarted normally per procedure in WIKI.  The system was down for about 40 minutes.  FRS 3289.

END X has been transitioned to the NEG pump. The main turbo is isolated but still spinning.

Pressure has remained at ~2.2e-8 torr.

The dewar level for CP7 is relatively low and the LLCV % open is nearly maxed out -> The vapor head pressure is 20 < pressure < 25 psi which should be more than adequate -> Delivery isn't for 6 more days -> At this rate we will have to do something or CP7 will have to be filled manually 

IP3 lost 1 of 2 channels shortly after replacing IP1 controller -> Both of these two units are the original (circa 1997) Varian MultiVac models of which we only have one or two left now on the site -> The failure is "Over Temperature" which is the typical failure mode -> I am unsure what is left for spares but will replace this unit as I am able

~1330 hrs. local -> Installed Gamma LPC unit (No CDS signal interface to this Make/model yet.  Indicated CDS values are bogus until otherwise specified)  

Kyle, Gerardo 

Dumped unpumped gate annulus volume into pump cart -> Decoupled cart from GV20 -> Opened GV20

h1seih23 filled its internal connection tracking table yesterday and had to be rebooted. Here is the current list of conntrack counts for all front ends as of 12:14PDT (the table fills at 65,536)

h1psl0 5,382
h1seih16 4,310
h1seih23 4,329
h1seih45 5,332
h1seib1 3,293
h1seib2 3,296
h1seib3 3,296
h1sush2a 5,400
h1sush2b 2,275
h1sush34 4,355
h1sush56 4,350
h1susb123 4,372
h1susauxh2  2,266
h1susauxh34 2,263
h1susauxh56 2,261
h1susauxb123 2,266
h1oaf0 6,400
h1lsc0 4,345
h1asc0 5,378
h1pemmx 2,231
h1pemmy 2,241
h1susauxey 2,267
h1susey 3,326
h1seiey 3,292
h1iscey 5,368
h1susauxex 2,266
h1susex 3,323
h1seiex 3,296
h1iscex 5,366
 

Nic, Evan

Summary

The frequency noise in CARM is limited in part by the dark noise of REFLAIR9I between 30 Hz and 1 kHz.

Details

First, an explanation of the plot traces:

1. The first trace gives the out-of-loop CARM noise in full lock as sensed by REFL9I, taken on 2015-06-14 06:16:10.
2. The second trace is the dark noise of REFL9I, taken a few days later when the IMC was down.
3. The third trace shows the dark noise of the in-loop sensor (REFLAIR9I), taken today (out of lock, REFL shutter closed). Notes on this:
   • We had to temporarily increase the whitening gain by 30 dB in order to overcome the ADC noise.
   • We have also scaled this noise by a constant factor in order to give the equivalent amount of noise that would be seen on the out-of-loop sensor. [The total scale factor is 10^(-30/20) / 0.0525 ≈ 0.60­, where 0.0525 ct/ct was the previously measured conversion factor from REFL9I to REFLAIR9I in full lock on 2015-06-14.]
   • The detailed shape of the CARM loop is not taken into account (see explanation below about our assumptions for CARM). So above a few kilohertz, where the CARM gain is only a factor of a few, this in-loop dark noise is probably not impressed very strongly onto the OOL sensor.

In the case that the CARM loop is sensing-noise limited, the dark noise (and the in-lock shot noise) of REFLAIR9I should appear on REFL9I. The CARM ugf is about 15 to 20 kHz, and is >30 dB below 1 kHz. Additionally, the white(ish) noise in REFL9I from 30 Hz to 1 kHz strongly suggests that we are seeing some kind of sensing noise. So we believe that the sensing noise from REFLAIR9I is indeed being impressed onto the CARM loop, and is the dominant contributor to the OOL noise between 30 Hz and 1 kHz.

We would like to additionally measure the shot noise as seen in REFLAIR9I (with no lock), to see how large it is relative to the REFLAIR9I dark noise. Either way, it is probably advantageous to switch control of CARM to REFL9I.