Matt, Hang

We ran the a2l decoupling optimization code this evening for all test masses and for both pitch and yaw. It successfully reduced the low frequency noise. Please see the attachment (darm_spectrum.png). 

The changes were:
H1:SUS-ETMX_L2_DRIVEALIGN_P2L_GAIN: 0.93 -> 1.21
H1:SUS-ETMX_L2_DRIVEALIGN_Y2L_GAIN: 0.93 -> 1.32
H1:SUS-ETMY_L2_DRIVEALIGN_P2L_GAIN: 0.00 -> -0.02
H1:SUS-ETMY_L2_DRIVEALIGN_Y2L_GAIN: -0.70 -> -0.59
H1:SUS-ITMX_L2_DRIVEALIGN_P2L_GAIN: 1.95 -> 2.04
H1:SUS-ITMX_L2_DRIVEALIGN_Y2L_GAIN: 0.63 -> 0.74
H1:SUS-ITMY_L2_DRIVEALIGN_P2L_GAIN: 1.05 -> 1.06
H1:SUS-ITMY_L2_DRIVEALIGN_Y2L_GAIN: -2.05 -> -1.48

H1:SUS-ETMX_L2_DRIVEALIGN_P2L_GAIN 
More details of the measurements could be found under:
/opt/rtcds/userapps/trunk/isc/h1/scripts/a2l/rec. 
It contained both the raw measured data (I, Q and total), and plots of our linear fits as well as rotation. The optimal a2l gains corresponded to the zeros of rotated I's. Please again note that since our data were likely to be correlated, the errorbars shown should just be treated as a rough estimation.

=================================================================================================================================================================================

Besides, we also wrapped the python code into a bash shell that could be easily called in the future. It could be found under:
/opt/rtcds/userapps/trunk/isc/h1/scripts/a2l

To rerun the optimization, you can simply enter
./run_a2l.sh
in the command line, and the code will do the optimization for all test masses and all angular dofs. 

If you just want to optimize some specific optics and, say, only their pitch to length coupling, you can just edit the 'a2l_input.in' file.

In cases that the interferometer loses lock, please press "ctrl + c" to terminate the code. With this keyboard interruption, it will automatically set the not yet optimized drive align gains back to their original values and disable the dither input. 

For more instructions, please refer to 'readme.txt' under the same directory. 

I have updated the RCG_VERSIONS MEDM screen to show the currently running versions before tomorrow's upgrade.

I have put together a few python functions which allow for briefly spawning multiple threads to switch many filters at (roughy) the same time.  The idea here is NOT to provide synchronous filter switching, but rather to speed up Guardian transitions which change the state of many filter modules (or more generally, write many channels).

The new code is in:

userapps/release/isc/h1/guardian/

fast_ezca.py - new functions for writing, switching, and generally doing things quickly

test_write_many.py - test functions for multi-thread writing

test_switch_many.py - test functions for multi-thread switching

We continue the charge measurements on ETMs.
Results for ETMX are consistent with negative trend, now the charge is from 10 to 20 [V] Effective Bias Voltage for all the quadrants.
Results for ETMY do not not show a significant trend (probably, the data are beginning to be consistent with positive trend). Charge is below the 10 [V] Effective Bias Voltage for all the quadrants.

Note:  We had positive bias on ETMX and negative bias on ETMY after discharging procedure. So it seems possible that charging is caused by the bias voltage.

The nex RCG release will fix the TrueRMS issues. For the record, here is a list of the H1 user models which use this part:

h1susetmypi, h1susetmy, h1susetmx, h1susitmx, h1susitmy, h1omc, h1susomc, h1oaf

The SUS IOP models also use the part for the Software Watchdog:

h1iopsusb123, h1iopsusex, h1iopsusey, h1iopsush2a, h1iopsush34, h1iopsush56

Times PST

9:58 Richard to EX to reconnect HEPI pump ground

10:15 Richard back

10:25 HFD on sit

11:20 Leo taking charge measurements

13:44 Joe D to both Mid stations

14:11 Joe D back

14:41 Richard to roof checking out GPS antenna work for tomorrow

Laser Status:
SysStat is good
Front End power is 32.64W (should be around 30 W)
Frontend Watch is GREEN
HPO Watch is RED

PMC:
It has been locked 6.0 days, 0.0 hr 31.0 minutes (should be days/weeks)
Reflected power is 2.464Watts and PowerSum = 25.33Watts.

FSS:
It has been locked for 0.0 days 0.0 h and 1.0 min (should be days/weeks)
TPD[V] = 1.643V (min 0.9V)

ISS:
The diffracted power is around 7.629% (should be 5-9%)
Last saturation event was 0.0 days 0.0 hours and 1.0 minutes ago (should be days/weeks)
 

J. Oberling, E. Merilh

On June 23rd we swapped the laser on the ETMx oplev, see alog 19290.  We spent the next couple weeks tweaking the operating power of the laser to get it in a stable zone; this has to be done since the thermal environment is different between the end station VEA and the LSB lab the laser was originally stabilized in.  After I got back from vacation last week I've been looking at quiet times (no apparent optic movement; I looked at the pitch & yaw oplev signals and picked times where the optics were quiet) to see if the laser is stable and glitch-free.  I've attached 3 spectrograms of quiet times during the last week

• 2015-7-13 for 3 hours starting at 11:00:00 UTC (4:00 am PDT)
• 2015-7-15 for 2 hours starting at 13:30:00 UTC (6:30 am PDT)
• 2015-7-19 for 4 hours starting at 14:00:00 UTC (7:00 am PDT)

There is no obivious glitching in the ETMx oplev laser as shown in these spectrograms.  I think it is safe to say this oplev is healthy.  I have also attached a spectrum of the ETMx oplev pitch & yaw signals for the same 4 hour stretch on 2015-7-19 as the attached spectrogram.

As usual if anyone notices anything not right with any of the optical levers, let me know.

This morning around 16:45 UTC, the ETMY ISI Stage 1 and 2 WatchDogs tripped reporting a "payload trip". Jim cleared these trips and then watched Guardian bring ISI back up in an odd way. Guardian brought the ST1 node to HIGH_ISOLATED but not all of the the preferred isolation loops on Stage1 were turned on, along with the input, output, and decimation. (Snipet of the log attached) Stage 2 proceeded to try and isolate but since stage1 was not entirely isolated the WatchDogs tripped again. This time, after clearing the WatchDogs, Guardian brought eveything back up properly and everything seems to have been working well since.

Jamie is unsure of the reason behind this, but suspects some epics connection issues.

Another odd bit to add is that the payload was never tripped...

At 17:40 UTC the ISC_DRMI Guardian had an the following error: "EzcaError: Could not get value from channel: <PV 'H1:LSC-PD_DOF_MTRX_SETTING_5_18', count=1, type=double, access=read/write>, None"

A caget of the channel yielded a value so it seems as though it was just the Guardian that was not seeing it. Reloading the code did not fix the error, and we were already on the phone with Jamie with another Guardian oddity (alog to follow). Jamie suggested that we STOP the node and then set it back to EXEC. This worked!

This has been seen before (example: https://alog.ligo-wa.caltech.edu/aLOG/index.php?callRep=19673) and seems to not be the same channels but from H1:LSC-PD_DOF_MTRX. Jamie and Dave both have their thinking caps on and are trying to solve the problem.

08:00-10:30 I got a little extra time for locking this morning.

Locking this morning was a little tricky as there was some FSS oscillation and ISS instability that was giving IMC a bit of trouble. Common Gain manipulation got that bit settled down and a bit of AOM diffracted power adjustment recitfied the remainder.

• First attemp was done without initial alignment: Green arms looked good. LOCK_DRMI_1F looked misaligned.
• In my first attempt to check PRMI alignment is when the IMC unlocked due to FSS oscillation.
• In my second attempt I decided to check out initial alignments. PRM_ALIGN looked good. MICH DARK LOCKED looked good. SRC_ALIGN looked good. LOCK_DRMI_1F did not.
• Next there was tripping of ETMY ISI. It seemed that Guardian was having some trouble. Jamie was contacted.
• Kiwamu monitored my initial alignment as I went through and checked once more and found that each caivty looked rather good. Once again, DRMI was not too bad but not too good, but it did lock.
• Notification that ASAIR_B_RF90 was too low for ASC to engage. Tweaking BS brought this level up to the ~500cts it needed for ASC to engage.
• IFO locked at ENGAGE_ASC.
• IFO brought to NOMINAL_LOW_NOISE for a short period. Lockloss. 
• Time for operator locking has lapsed at this point so Guardian remains engaged for locking unless someone needs measurements etc...
• ISC_DRMI guardian went red @ LOCK_DRMI_1F. Repeated attempts ro reload failed. Jamie corrected .
• further locking attempts result in lockloss at DRMI. Alignment doesn't look bad.

Here is a summary of the brute force coherence report already posted in a previous comment to an elog entry describing the good sensitivity lock of last Friday.

Basically, there is no large coherence anywhere, except for the well known periscope peaks that are coherent with ISS signals, IMC angular signals and PSL periscope (figure 1-3)

At low frequency, there is coherence with SUS-ETMY_L3_ESDAMON_?? signals. This was not there in the past, so I guess this coherence is just due to a change in the control strategy. If I'm not mistaken, this signal is just a monitor of the correction sent to the ESD, so coherence with DARM is normal. Please correct me if wrong... (figure 4)

In the 10-30 Hz there is coherence with ASC-MICH_P (figure 5)

In the 10-70 Hz region one dominant source of noise is longitudinal control, since there is coherence with MICH and SRCL (figures 6-7). This noise is not dominant and still a factor of few from the measured sensitivity.

In the higher frequency region (above 100 Hz), there is coherence with ISS and PSL periscope as already pointed out, but there is also some coherence with AS signal: ASC-AS_A/B_DC_SUM, ASC-AS_A_RF36_I_PIT/YAW etc... Together with the main jitter peaks, there is a broadband noise floor at about 1e-10 m/rHz from 100 to 1000 Hz. This might be intensity noise or noise in high order modes that is not completely filtered by the OMC (figure 8).

Finally, a 90 Hz bump seems to be coherent with HAM5 signals (figure 9)

Hang, Matt, Evan, Stefan, Rana

WE mostly were chasing weird locklosses and instabilities, but also managed to implement a few noise improvements:

1. SRCL FF better shaping via fitting and better measurements.
2. A2L decoupling gave us 10-30 Hz improvement.
3. MICH FF tuned up a bit. New measurments taken; fitting and filter generation yet to be done.
4. ASC tune up: hard/soft modes for CARM.
5. ETMY Butterfly mode identified and notched.

Of the locklosses, some were just due to marginal points in the transitions and loop margins. The main issue over the past few days turned out to be that the TIDAL servo was turned OFF somehow on Friday evening. After switching that back on for ETMY, we have returned to having long locks. The highpassing of SRCLFF has removed the high power pitch instabilities that we were seeing.

We were able to get > 40 Mpc with 10W input. The butterfly mode of ETMY @ 6053.81 Hz is preventing us from turning on the OMC DC whitening right now, so we don't know how good our range really is, but our low frequency

Might be nothing, but the following alarms have been going off continuously for the past few days:

EX HEPI DIFF PRESSURE (yellow)

EX DUST1, EY DUST1 (RED), and LVEA DUST

Matt, Hang

We wrote some codes to optimize a2l coupling coeffecients. The script will measure omc dcpd's response to injected angular dither, and do a linear fit (for I and Q separately) of this response as a function of a2l gain. With a proper rotation of the I-Q plane s.t. the rotated Q' stays as a constant, the minimum of the response will be at the zero of the rotated I'. 

We ran the script for ITMX, ETMX, and ETMY. Results are shown in the attachments. The errorbars were underestimated because the raw data might be correlated if the sampling frequency was not low enough, thus we just plotted them as a reference but no minimization of chi-sq in the fit. 

Based on them, we did the following changes:

H1:SUS-ITMX_L2_DRIVEALIGN_P2L_GAIN: 2.300 -> 1.947
H1:SUS-ITMX_L2_DRIVEALIGN_Y2L_GAIN: 1.350 -> 0.632

H1:SUS-ETMX_L2_DRIVEALIGN_P2L_GAIN: 1.100 -> 0.927
H1:SUS-ETMX_L2_DRIVEALIGN_Y2L_GAIN: 1.370 -> 0.927

H1:SUS-ETMY_L2_DRIVEALIGN_P2L_GAIN: -0.200 -> 0.000
H1:SUS-ETMY_L2_DRIVEALIGN_Y2L_GAIN: -0.600 -> -0.700

the probability a freeze-up does not impact at lease one dolphined FE is very small, so I'm using the h1boot dolphin node manager's logs to data mine these events. The dolphin manager was restarted when h1boot was rebooted Tuesday 7th July, so data epochs at that time.

As I was seeing with my monitoring programs, the restarts preferentially happen in the 20-40 minute block within the hour. The first histogram is the number of events within the hour, divided into 10 minute blocks.

We are also seeing more events recently, the second histogram shows number of events per day. The spike on Tue 14th is most probably due to front end computer reboots during maintenance. Friday's increase is not so easily explained.

FE IOC freeze up time listing:

controls on h1boot

grep "not reachable by ethernet" /var/log/dis_networkmgr.log |awk '{print $2r, $4}'|awk 'BEGIN{FS=":"}{print $1":"$2}'|sort -u

total events 197

minutes within the hour, divided into 10 min blocks

00-09 11  :*****

10-19 11  :*****

20-29 67  :*********************************

30-39 79  :****************************************

40-49 17  :*********

50-59 12  :******

events per day in July (start tue 07)

wed 08 09 :*****

thu 09 09 :*****

fri 10 08 :****

sat 11 07 :****

sun 12 08 :****

mon 13 09 :*****

tue 14 22 :***********

wed 15 10 :*****

thu 16 20 :**********

fri 17 38 :*******************

sat 18 16 :********

Cataloging the many ways in which we are breaking lock or failing to lock since Friday, we found this one:

Sitting quietly at 10W DC readout, there was a slow ring up of a pitch instability in several ASC signals. Perhaps its time we went back to seriously controlling the ASC in the hard/soft basis instead of the optic basis in which its currently done. The frequency is ~1 Hz and the time constant is ~1 min. It would be great if someone can look at the signs of the fluctuations in the OL and figure out if this was dHard or cHard or whatever.