At 05:19 (10:19) Lost lock due to PSL shutdown. X-Chiller down with Flow Sensor error.  

Haocun, Sheila, Keita, Jenne

We spent some time today on the POP X path, hoping that we can use this to avoid the locklosses we had last night due to sign flips in the REFL WFS signal for PR3.  

• First Haocun added a 50/50 beamsplitter to the POP air path, which reduced the light on both the POPAIR A and B diodes.  This means we don't have to be afraid of damaging POPAIR B at 50 Watts.  She then realigned both of these diodes, although we haven't checked the camera.  Jenne increased the whitening gain to account for the factor of 2, and redid the dark offsets so that we could relock PRMI.  With PRMI locked Haocun and I aligned the rest of the path to POP X, which is about 5 inches shorter than the path at LLO based on the table diagram.
• We had some trouble using the MCL PZT, with help from Keita we understood that the problem was with using long d sub cables.  Apparently, the sensors used in the internal piezo servo don't work if the cables are too long.
• Once the PZT was working, we designed a simple servo 1/f with a ugf around 1.5 Hz and the centering loops locked up imediately.  Haocun has open loop gain measurements that she will add.  
• We then quickly looked at phasing the RF by dithering PR3 pitch.  The laser turned itself off while we were doing this.   

Looking at the centering servo, Daniel and Keita realized that it would be nice to modify the model to have the same kind of integrator and triggering we have for the end station PZT servos, and modified the model.  It would be good to restart the ASC model to incorporate these changes, which will require a DAQ restart so we didn't do it tonight.  I cleaned up SDF so that it is ready to go if there is a convient time in the morning.  

[Sheila, Jenne]

These are numbers pulled from our dP/dTheta measurements from last night (mentioned in alog 27235).  I have gotten the numbers into RIN/theta, since we want to know how much the power fluctuates for a given angular motion of an optic.  The short summary is that the Yarm optics affect the power fluctuation much more significantly than the Xarm optics do, and that the ETMs affect the power more than the ITMs. 

Sum up of 2W results:

We'd like to remeasure these values at different powers - hopefully they're constant.  Of course, these are relative power fluctuations versus angle, so the overall force on the optics will be increasing as we increase the power.

The following table with more detailed results has a crazy-town amount of information, some of which I'm not totally sure what to do with yet.  The difficulty is that since we have ASC loops running, when we dither one test mass, all 4 test masses move.  So.  Here's the gory detail.  All dithers were at 0.51 Hz in pitch to the L2 stage of the test masses. Start times are UTC of 17 May 2016. The values in the table below are at our 0.51 Hz dither freq.  The numbers in the summary table above are the RIN of POP_A_LF versus the angular motion of the optic we were driving at the time.

To facilitate PI damping work with the EX ESD, I modified the guardian so that the driver is switched to low-noise mode in the noise tunings state. I also added code in the down state to go back to high-range mode after a lock loss.

Betsy, Jeff, Jim:

model changes for h1susmc[1,2,3], h1suspr[m,2] and h1sussr[m,2].

Richard, Jim:

powered down h1isce[x,y] for IO Chassis DC power reconfiguration.

Tega, Ross, Dave:

iWave C-code testing on h1susitmpi and h1susetmxpi models. No DAQ restart required.

Jenne, Sheila, Jim, Dave:

Clean load of h1asc filter modules to clear out corrupted archived file.

Jeff, Dave:

modified filter files for h1susitm[x,y] and h1susetmx were loaded, no real filter change just a reordering of the modules list. h1susetmy had filter changes, which Jeff loaded after review.

Jim Dave:

DAQ restart to sync sus model changes. H1EDCU_HWS.ini file was modified to remove ETMY channels which no longer exist in the new python hws code. DAQ EDCU is now GREEN again and operators should investigate if it goes RED.

Patrick:

conlog reconfigured to latest channel list.

J. Kissel

We've gathered our regular Tuesday measurement of the effective bias voltage as a result of charge on the end test masses. After the hiccup of settings loss a few week's ago (LHO aLOG 26793), the last three weeks of results confirm that both test masses are back on there way to zero effective bias voltage. Good! 

Also encouraging, is that the rate of charge accumulation seems to have become consistent between flips of requested bias. This didn't always used to be the case; see LHO aLOGs 22135 or 20387 in which we had evidence that the rate of charge was a crap shoot every time we flipped the requested bias sign. There's no obvious reason why it would be different between now and then, but it's good to see that it may be one less thing we have to worry about.

However, recall, the plan -- to minimize time-dependent calibration error during observing runs: after we've brought the effective bias voltage to zero, regularly flip the requested ETM bias voltage such that it *stays* at zero and never accumulates. Today's results show that we're pretty darn close to zero with ETMY, so we should write that script that automatically flips the requested bias voltage and takes care of all the collateral damage (see LHO aLOG 26826) this week or next, and exercise it. 

Only after we regularly exercise flipping and confirm nothing goes suddenly bonkers, will we say we're comfortable doing it regularly during the run.

I took advantage of today's maintenance period to do some investigation of the PCalX clipping issue.  I dithered the ETM independently in pitch and yaw: leaving yaw in the original 'aligned' position while dithering pitch, and vice versa.  See attached pic if you care about the individual data points. In summary, I found that changing ETM yaw had a much greater effect on the power received by the receiver photodiode (RxPD).  This seems to indicate that we can narrow down our search for clipping to the receiver side of the ETM.

Original 'aligned' values:

Pitch: -16.0 urad

Yaw: 78.8 urad

RxPD: 2.090 Volts

Greatest power for pitch dither:

Pitch: 150.0 urad

Yaw: 78.8 urad

RxPD: 2.315 Volts

Greatest power for yaw dither:

Pitch: -16.0 urad

Yaw: 400.0 urad

RxPD: 3.15 Volts

Combined dither:

Pitch: 100.0 urad

Yaw: 400.0 urad

RxPD: 3.16 Volts

The next chance we have to go to the end station, we'd like to try adjusting the steering mirrors in the transmitter module again (we've tried this once, but with limited success). 

Added 3055 channels. Removed 643 channels. List attached.

ITMY CO2 stopped lasing at 10:00 local and ITMX CO2 stopped lasing at 10:05 local. Both RTD/IR sens. alarms tripped. Only ITMY recovered itself successfully (still required me going to the rack and hit GATE button to restart the laser) while ITMX interlock ramped down and came right back to the tripped value (what the hell happened here?). I'm not aware of any restarts that could have caused them to trip. Both FLOW ALARMs were okay.

Jim, Dave:

Sheila and Jenne made h1asc filter changes over the weekend and we noticed today that the diff file for this system was filled with many copies on a single filter. Investigating further we noted that the problem was with the three filters ASC_CHARD_P, ASC_CHARD_P_A and ASC_CHARD_P_B. Jim noted that these consist of a core name, and filters with additional suffixes, so we suspected a potential string matching issue. In the case of h1asc, the running H1ASC.txt file in the chans/tmp directory had 638 copies of the ASC_CHARD_P filter module, with varying header names.

We were able to reproduce the problem on the DAQ Test Stand. We made changes to the three filters and loaded them individually. When the "core" named filter (ASC_CHARD_P) was loaded many copies of this were created. Further individual loads compound the problem, which is why h1asc ended up with so many copies.

A bug has been opened for this: https://bugzilla.ligo-wa.caltech.edu/bugzilla3/show_bug.cgi?id=1014

We scanned all the H1 filter modules looking for filters which are core names to additional filters. We found 65 cases in the 8900 total number of filters. These filters are distributed over the following systems:

h1alsex
h1alsey
h1asc
h1calex
h1caley
h1iscex
h1iscey
h1lsc
h1oaf
h1odcmaster
h1omc
h1psldbb
h1pslfss
h1psliss
h1pslpmc
h1susetmx
h1susetmy
h1susitmx
h1susitmy
 

Until this issue is resolved, we recommend that users do not individually load filter modules and instead perform full filter file loads from the GDS_TP MEDM screen.

I gathered some new data points from today and fine tuned the calculator. The requested power and measured power now agree within 1%. A 10-day minute trend of PMC transmitted power shows that the PSL power itself fluctuates on the daily basis which will throw off the calibration slightly. The calculator must be re-tuned based on the maximum PSL power going to the IMC, given that the minimum power angle doesn't change.

J. Kissel, B. Weaver
Work Permit: #5880
FRS Ticket: #5489
Integration Issue: #FRS 5506
ECR: E1500045

Betsy and I've installed the individual coil driver switching of HSTS M3 stages as per documentation linked above. The front-end model changes were prepared and described yesterday (see LHO aLOG 27223), though note, we found some bugs and have to recompile again this morning (LHO aLOG 27239), after making the MEDM screen modifications described in the this log.

We've made modifications to the following MEDM screens:
/opt/rtcds/userapps/release/sus/common/medm/hxts/
M       SUS_CUST_HSTS_OVERVIEW.adl         <--- made CD STATE and TEST/COIL ENABLE settings and readbacks for each quadrant independent, 
                                                and linked to new non-generic HSTS screens mentioned below
and created new screens:
/opt/rtcds/userapps/release/sus/common/medm/hxts/
?       SUS_CUST_HSTS_M3_EUL2OSEM.adl      <--- used to be generic with all HXTSs, but now specific to HSTSs
?       SUS_CUST_HSTS_BIO.adl              <--- used to be generic with all HXTSs, but now specific to HSTSs
and screen shots of each are attached. 

Unfortuanely, because the BIO settings and EUL2OSEM matrix elements are new channels for the M3 stage, one has to, by-hand, re-enter every suspension's
    - Requested coil driver state
    - The TEST/COIL ENABLE switch
    - The M3 EUL2OSEM matrix elements.
and then hit "LOAD MATRIX" on all of the M3 EUL2OSEM matrices. We used Betsy's screenshot from last night to do this (from LHO aLOG 27225).


We've also made our best attempt at updating the safe and down.snap files which had to have the former, ganged BIO channels replaced with the individual coil BIO channels. This required quite an SDF dance:
1) On SDF SAVE SCREEN for each SUS, 
    - change SAVE TABLE to "EPICS DB TO FILE" in order to update the snap file with the new epics database channel list currently running with the new model
    - change FILE OPTIONS SELECTION to "OVERWRITE" in order do this with the currently loaded snap file
    - Hit SAVE FILE
    (We did this with every safe, down, or observe snap file for a given suspension)
2) On SDF RESTORE SCREEN for each SUS,
    - SELECT REQUEST FILE that you want to load in with the new updates
    - LOAD TABLE
    This should cleared out any of the channels with have disappeared from the model and create a bunch of new channels which are NOT INITitallized.
Since keeping track of all of these channels and snap files was a bear, I don't promise that we've gotten everything right. We'll just have to keep an eye on them over the next few weeks to check if we've missed anything.

Jenne's working on updating all Guardians that controlled the M3 stages of the HSTSs, and coding up the 3-coil-motion necessary for switching the coil state one at a time like is done on the beam splitter. 

Jenne, Sheila, Evan, Kiwamu

Today we aimed to have a long stable lock at 30 Watts. We did have one lock of more than half an hour at 30 Watts, which we lost due to commisioner error.

• We measured the coupling of test mass pitch to arm power fluctuations.  More information will be coming later. 
• We noticed that we can loose lock because of the CSOFT instability driven by power fluctuations when we power up too quickly for our soft loops to keep up.  We rewrote the INCREASE POWER state to pause and wait for soft loops at 10 Watts intervals.
• In 3 out of our last 4 locking attempts, we have lost lock in DARM offset.  The one time we made it Jenne did the steps in the guardian by hand.  There don't seem to be any changes in the code for this state....
• We had a few locklosses engaging the ISS 2nd loop.  The thresholds needed to be adjusted, now it is working.
• We did some A2L tuning today.
• We had a couple of sudden locklosses, where our recycling gain was slowly decaying, and it looks like the PR2 (REFL WFS) loop and SRC2 (AS_C to SR2 and SRM) loops ran away in the last fractions of a second.  This seems like the lockloss we had because of the sign flip in the REFL WFS, because we increased the bandwidth of the PR2 loop it is now a fast lockloss.  We measured the open loop gain of PRC2 both at 30 Watts (where the recycling gain is decaying) and at 2 Watts, the optical gain is lower at the 30 Watts measurement which was taken right before one of these locklosses. 
• We decided based on this to try moving soft loop offsets, but we want to picomotor the TMSY QPDs before moving the offsets...  we are leaving this for tomorow...  We turned off the CHARD blends so that we can move picomotors, and are leaving them off for now, but should turn them back on when we are done with picomotors.

Also, the ISS 1st loop is oscillating pretty much every time we loose lock and needs to be fixed by hand. we are leaving IFO undisturbed at 23 Watts 7:50 UTC

Kiwamu, Darkhan,

We updated the ETMY L1 stage (UIM) compensation filters FM2, FM3, FM4, FM7, FM8, FM9 of ETMY_L1_ESDOUTF_{UL,LL,UR,LR} with zeros and poles more accurately fitted to the most recent measurements by Jeff K. from ER8 (LHO alogs 20846, 21283). We have not updated the acquisition circuit zero-pole pair, because the measurements do not include the response of this circuit (for details see LHO alog 21142).

We've also updated the ETMY L2 stage (PUM) compenstation filters FM1, FM2, FM3, FM6, FM7, FM8 of ETMY_L2_ESDOUTF_{UL,LL,UR,LR} to their fitted values (LHO alogs 20846, 21232).

Python scritps were used to load new vailes into the Foton file, the scripts are based on Kiwamu's script for updating filter in the L3 stage (ESD) (LHO alog 27150). The scripts are committed to CalSVN at

Runs/PreER9/H1/Scripts/SUS/setH1SUSETMY_UIMDriver_compensations.py
Runs/PreER9/H1/Scripts/SUS/setH1SUSETMY_PUMDriver_compensations.py

Notes for CAL FOLKS:

• UIM and PUM filter replicas in CAL-CS model have not been updated accordingly at the moment;
• The extra compensations (for imperfect front-end filters) in the Matlab DARM calibration model are not necessary anymore, must be removed from the model.