I noticed yesterday that Seismon was not recovered after the file system issues yesterday, but I caught it after Carlos had left for the day, so I didn't get to ask if they were still recovering. Working with Carlos this morning I was able to get it back up and running, but I wanted to capture the process here.

1. ssh onto the seismon vm as controls:

    ssh controls@seismon

2. Launch 2 screen sessions for the seismon scripts, this is not completely straight forward. The scripts live in /usr/local/seismon/seismon/bin, but 2 of them need a virtual environment, which I launched using an alias:

controls@seismon:~ 0$ cd /usr/local/seismon/seismon/bin
controls@seismon:bin 0$ screen

Activate the virtual environment for seismon:

controls@seismon:bin 0$ seismon_ve 

Then run the traveltimes script:
 (ve) controls@seismon:bin 0$ ./seismon_run_traveltimes.py

This will start outputting stuff to the terminal, so leave it running and CTRL+A+D to disconnect from the screen session, launch a new screen session and repeat for seismon_run_info, including the seismon virtualenv (seismon_ve alias).

3. The run a third screen session for the epics client seismon_epics_client_v5.py. this does NOT use the seismon virtualenv, and won't run with it set. When done there should be 3 screen sessions running.

controls@seismon:bin 0$ screen

controls@seismon:bin 0$ ./seismon_epics_client_v5.py

4. There is also an epics IOC on h1fescript0, ssh to that machine as controls and ps -elf | grep seis to see there is only one copy of seismon_epics_ioc_v3.py running.

controls@h1fescript0:~ 0$ ps -elf |grep seis
0 S controls  2952  2590  1  80   0 - 32756 poll_s  2018 pts/2    18:20:36 python ./seismon_epics_ioc_v3.py
0 S controls  4532  4301  0  80   0 -  2350 pipe_w 14:21 pts/0    00:00:00 grep --color=auto seis

That should be it.

TJ, Marie, TVo, Danny

TJ set up a temporary rail for the table to slide along to avoid the table from changing angle of incidence on the first in-vaccum mirror when shifting the table position.

After shifting the table a bit more to the left of where we nominally were trying, we were able to pass the CO2 beam through the ifo beam position in yaw (using the procedure detailed in alog 46766). I forgot to take photos of the red alignment laser position on the Zn-Se viewport and SRM-HR baffle but I'll supplement this post with those photos as a comment next Tuesday.

There was quite a bit of pitch motion/drift on the AS_A_DC and AS_B_DC pds. Not very clear why this was, but the motion made it difficult to verify the pitch alignment was still good. We might have to double check next Tuesday (or sooner if there is a need to test) but I suspect that we are nominally in a good position in pitch since we made very little changes. 

ODC removal

Keita, Jeff, Jamie, Dave:

The following models were restarted after ODC removal: h1sus{etm[x,y], tms[x,y], itm[x,y], bs, pr[m,2,3], sr[m,2,3], mc[1,2,3], omc, opo, im, htts} h1isietm[x,y], h1isce[x,y].

ISC model changes:

Jenne, Daniel, Dave:

The following models were restarted: h1ascimc, h1omc

Guardian new base code:

Jamie:

h1guardian1's guardian base was updated. Its OS was upgraded and the machine was rebooted. The EDCU to connect to the new channels.

h1odcmaster removal

Dave:

I completed the h1odcmaster model removal from the DAQ with a new H1EDCU_DAQ.ini.

DAQ Restart

Dave:

The DAQ was restarted at 11:44PST for the above changes.

After the CAL-CS model upgrade to have highpass/whitening filters on the CFTD CTRL paths, I've installed whitening filters on the CFTD paths. This is the same as we did at LLO (see LLO aLOG 42961). This has to be installed on both inverse sensing and actuation paths, but does not need to be in the CFTD_DELTAL_EXTERNAL whitening bank. We will dewhiten in DTT.

These are installed in FM1 of the CFTD_DARM_ERR bank and FM1 for each of the CFTD_DELTAL_CTRL*_HP banks.

The design string is: zpk([0.3;0.3;0.3;0.3;0.3;0.3],[30;30;30;30;30;30],1,"n")

Overnight the end station BRS enclosures at both endstations heated up about .5 degrees C. This very nearly drove BRSX out of range, which would have probably tripped the ISI. This wasn't a big issue for BRSY, but BRSX went through 8k counts of the ~28k usable range, it probably also has an effect on the noise of the BRS. The damping for the BRS also goes unstable when the ccd image goes out of range.

Attached plot shows trends for the last week of each BRS driftmon, X is the left image, Y is the right. The BRS go out of range at about +/- 15000 counts, BRSX will need adjusted immediately, unless temperatures are changing back.

Was there some change to building heating or something? Nothing was changed on either BRS enclosure.

J. Kissel
8077

Reconciling SDFs prior to the h1iscex/h1iscey model restarts, I've accepted QPD offsets that were last changed on Jan 27th 2019. see attached screenshots.

This morning I attempted to measure some transfer functions of the TTFSS out by the PSL rack.  In short, it
didn't work.  Enabling the TEST2 input did not do anything.  The switch can be enabled inside the enclosure
however.  I also took some noise measurements of the fast and EOM when the fast gain was varied between
9 dB and 19 dB.

    Unfortunately I cannot retrieve the data from the floppy disc because either my floppy drive does not
work (unlikely) or I did not pay attention as to what format the HP4395A formatted the disc to (LIF as
opposed to DOS).

    Fixing the TTFSS field box will require some laser down time, or more correctly, some FSS down time.

- There is an unsolved problem somewhere around DARM_TO_RF.  I believe it has to do with the DIFF PLL OFFSET stepper servo not quite working fast enough to keep H1:ASC-AS_A_RF45_Q_SUM_NORM near enough to 0 before the switch happens.  I am able to slowly step through the state successfully, but not request beyond it with the guardian without losing lock.

- I removed REDUCE_RF9_MODULATION_DEPTH from the guardian path because this seemed to trigger the 1.4 Hz DHARD instability.  I have been able to sit at NLN for 6 hours without problems.

- We are still controlling DARM with L1 and L2 on ETMY and L3 on ETMX.  Because of this the calibration is a complete mess at low frequency.  At high frequency it is good to one percent (assuming we trust the PCAL at this point, unclear if we do because the force coefficients are changing.)
I fiddled with the DARM calibration screens and switched the calibration back to ETMY L1 L2 such that the DARM calibration should be good to 15% according to PCAL.

Some notes about the noise with the actuator switch:

- MICH FF would need retuning, since MICH is coherent with DARM.  
- The ISS coupling to DARM was reduced at high frequencies.  However, after two hours of sitting locked at NLN, the ISS is back to limiting high frequency DARM.
- The scatter shelf is back and happens pretty consistently every two minutes.

I did a couple of ISS broadband injections and TFs to test the arm power and intensity noise.  I attached the TF template.  Some notes:
- Our ambient input RIN is ~10-8, according to ISS OUTER RIN.
- DARM is limited by the ISS at high frequency (~2k on).  DARM is not limited by the ISS anywhere else.
- Arm RIN/Input RIN goes like f-1 as expected.  
- DARM/Input RIN goes like f-5 according to my TF measurement, and not like f-3.  I do not yet understand this, I would have predicted -3, with -1 from the CARM pole filtering of the Input RIN, and -2 from the compliance of the quads coupling due to radiation pressure effects.
- DARM/Arm RIN goes like f-4.  
- All the DARM/Arm RIN TFs seem to be nearly the same magnitude.  Some fits must be applied to be able to really tell.
- To calibrate I used the DARM FOM calibration for DARM meters, and found the average value of the Arm QPDs and divided by them.  I assumed that ISS OUTER RIN was already calibrated.

While doing some of these injections I excited ETMX mode 9.  I ran ENGAGE_ALL_DAMPING in the violin mode guardian, this worked.

today it is snowing, and we have been having ALS glitches in the X arm for the last 45 minutes or so.  

We wrote a quick script to transition the green lock to the configuration where the fiber is bypassed, and switched back and forth a few times.  The attached text file can just be copied and pasted into a guardian shell, to either transition to the bypassed configuration or back to the normal configuration, you will also need to change the guardain request as the text file tells you to.  

In the attached screenshot you can see that when IN1EN is 1, we are locked with the laser to the PLL , and there is some fuzz on the X arm transmission which is a series of small fast glitches if the plot were more zoomed in.  When IN2EN is 1 we are locked directly to the arm, and in the first couple of examples this does seem to be quieter than with the laser locked to the fiber.  There was a time labeled error when we accidentally left both feedback paths on, we can ignore this. 

The arm comes unlocked fairly often when we are locked with the fiber bypassed.  Next time this happens and we have time to work on this we should go the end station and take some time to measure the transfer function of this lock to the arm. 

TITLE: 02/04 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:

14:40 (6:40) Chris traveling arms to assess tumbleweed buildup

16:00 (8:00) Start of shift

17:45 (9:45) Hugh to EX -- look at anemometer

17:46 (9:46) Terry to Optics Lab

17:55 (9:55) Marc, Fil to Vault -- PEM system calibration

18:04 (10:04) Terry back from Optics Lab

18:12 (10:12) Kyle to MY -- wiring on prototype vacuum equipment

18:18 (10:18) Hugh back from EX

18:34 (10:34) Patrick to MSR

19:07 (11:07) CALEX, CALEY restart

19:13 (11:13) Vanessa to EX, EY, MY

19:43 (11:43) Kyle back from MY

20:00 (12:00) Marc, Fil back from Vault

22:00 (14:00) Nutsinee to LVEA

23:19 (15:19) Nutsinee out of LVEA

00:00 (16:00) End of shift

In preparation for adding the second HV driver to the OMC PZT driver chassis, the OMC model was updated.

1. Remove all references to the old software trigger infrastructure.
2. Add a new filter module PZT3 to apply the bias.
3. Use the previous "fast shutter trigger" channel as the new output (chn 3 on the DB9 DAC channel).
4. Added new readback channels for DC & AC. These are chns 3 & 4 on the DB9 cable coming from the DC PD interface chassis.

Daniel, Nutsinee

We had been using OPO common mode board for the intensity servo until we swapped the scheme (now the OPO CM board is actually used to lock the OPO). The servo is now all digital with a UGF of 200Hz. H1:SQZ-OPO_TRANS_LF_NOM has to be set to 1. The output (2nd from the left of SQZ rack U16) goes through a 450 Ohms resister and to the IFR that drives the AOM.

On January 8th I tried to measure the average arm power by dithering SRCL.  Last night I did it again, this time with better TFs taken simultaneously.

Average Arm Power = 143.0 +- 5.8 kW

This time I directly fit each of the four Arm Trans QPD RINs (H1:ASC-{X,Y}_TR_{A,B}_NSUM_OUT_DQ) to DARM (H1:CAL-DELTAL_EXTERNAL_DQ), then fit a 1/f2 (attachment one).  The DARM calibration used was the stop gap made by Keita.  The average powers for the RIN calculation are as follows, and are good to +- 300 cts:
Arm Trans QPD counts
XA      145658
XB      191409
YA      207723
YB      221769


This time the math is simpler: 
P_arm = DARM/ArmTransRIN Fit × π2 × m × c


If we look at the different in the arm trans RIN response between the arms, and say that the RIN we see is entirely due to radiation pressure in the arms, we get (DARM/Y)/(DARM/X) = X/Y = 1.08, meaning there may be 8% more light in the X arm than the Y arm.  EDIT: It is actually the Y arm with 8% more light than the X arm.

If we calculate the simple power recycling coupled cavity, I find that the estimated average ETM scatter losses are around 92 ppm and the estimated PRG here is 39.  (attachment three)

The measured value of PRG at the time of the measurement is 41.8, and the true input power was 26.5 W (requested was 30W).  If we take these numbers to be true, then our arm gain according to the SRCL dither is 258.

Per Q1800019, I visually inspected H-GV12 on Dec. 19 to verify that the spindle nut and lock washer are present. Was not able to inspect torque setting without fall protection.