model restarts logged for Wed 11/Feb/2015
2015_02_11 11:28 h1fw1
2015_02_11 12:23 h1susetmy
2015_02_11 12:31 h1fw1
2015_02_11 13:16 h1susetmx
2015_02_11 13:20 h1susitmx
2015_02_11 13:20 h1susitmy
2015_02_11 13:27 h1broadcast0
2015_02_11 13:27 h1dc0
2015_02_11 13:27 h1fw0
2015_02_11 13:27 h1fw1
2015_02_11 13:27 h1nds0
2015_02_11 13:27 h1nds1
2015_02_11 13:37 h1calcs
2015_02_11 13:40 h1calcs
2015_02_11 13:42 h1broadcast0
2015_02_11 13:42 h1dc0
2015_02_11 13:42 h1fw0
2015_02_11 13:42 h1fw1
2015_02_11 13:42 h1nds0
2015_02_11 13:42 h1nds1
2015_02_11 14:27 h1fw1
2015_02_11 16:52 h1calcs
2015_02_11 17:07 h1iopoaf0
2015_02_11 17:07 h1oaf
2015_02_11 17:07 h1pemcs
2015_02_11 17:08 h1iopoaf0
2015_02_11 17:08 h1oaf
2015_02_11 17:08 h1pemcs
2015_02_11 17:09 h1calcs
2015_02_11 17:09 h1odcmaster
2015_02_11 17:09 h1tcscs
2015_02_11 17:11 h1broadcast0
2015_02_11 17:11 h1dc0
2015_02_11 17:11 h1fw0
2015_02_11 17:11 h1fw1
2015_02_11 17:11 h1nds0
2015_02_11 17:11 h1nds1

three unexpected h1fw1 restarts. New QUAD SUS code. Install of the h1calcs model. Several related DAQ restarts. Power cycle of h1oaf0 to remove ADC noise from PEM.

I ran my brute force coherence script for the almost 2 hours lock of two days ago (the coherence for last night 2+ hours is running, you guys are locking too often!). Basically this script computes the coherence of the LSC-DARM_IN1 signal with *ALL* available channels. Some channels are supposed to be coherent (for example DARM_OUT), so I have a list of excluded channels. For the moment being I used the same list as for LLO, then I'll see if I need to fine tune it.

The full report is available here:

https://ldas-jobs.ligo.caltech.edu/~gabriele.vajente/bruco_1107680416/

Some preliminary comments:

• noise below ~40 Hz shows a lot of coherence with LSC-ASAIR_A_LF_OUT and other DC channels at AS. I guess this is normal, since these channels are sensing the main beam before the OMC, and the DARM signal is read after the OMC. It is just abuit strange that the power before and after the OMC is fluctuating in a coherent way, but this might simply mean that the low frequency DARM is very noisy and the TEM00 fluctuations dominate over the HOMs. This hypotesis seems to be confirmed by the coherence with signals like SUS-ETMX_L1_WIT_L and similar
• noise below 100 Hz is very coherent with SUS-ETMX_L2_OLDAMP_P_OUT. If I interpreter correctly this name, it should be an optical level damping on ETMX. This coherence is basically enough to explain all the noise up to 50 Hz and most of the noise up to 100 Hz
• In the low frequencies (below 40 Hz) there is coherence with many angular signals at AS port, but interestingly the coherences with those channels have a very similar shape of the coherence with LSC-POPAIR_A_LF. I can't be sure, but maybe this is an indication of large RIN at low frequency?
• Between 40 ans 200 Hz there is some coherence with the MICH control, for example LSC-MICH_IN1_DQ. In the same region (50-300 Hz) there is even more coherence with SRCL control: LSC-SRCL_OUT.
• Above 100 hz there is significant amount of coherence with ISS signals: PSL-ISS_SECONDLOOP_SUM14_REL_OUT

Basically, so far there is nothing new with respect to what Dan reported.

The attached plots are taken direclty from the report, and they show the coherence with some of the channels I discussed above. The top panel shows the coherence, in log scale for both x and y axis. The dashed red line in this panel corresponds to the level of coherence you expect for completely uncorrelated signals, given the resolution and the number of averages. Any coherence at this level or below is completely accidental. The bottom panel shows the spectrum of DARM signal and the noise projection for the auxisliary channel, based on the coherence. It gives a good indication of how significant the coherence is, but of course must be taken "cum grano salis".

The data was transferred to the new hardware per WP 5044. There is a gap in the data from around 8:15 am to 12:10 pm on Feb. 11.

After we broke the 2+ hour lock, I got greedy and tried to re-lock the IFO myself (at least to RF), after having been shown the ropes by Sheila and Evan earlier in the day. 

- I could get past finding the IR steps in the ALS COMM guardian when the COMM vco failed or needed some hand holding,
- Could get past tweaking of the H1:ALS-C_DIFF_PLL_CTRL_OFFSET when ALS DIFF couldn't find IR, 
- tried tweaking the Beam Splitter alignment while stuck in the DRMI lock acquisition, and 
- managed to survive a few quick breaks of the DRMI during the initial 1F to 3F transition ~ 10 seconds after catching a DRMI lock
- Can get all the way through the CARM offset reduction, but 
on of the first steps of the "RF DARM" state breaks the lock consistently.

The last example of which I'd stayed for was at Feb 12 2015, 09:23:57 UTC

I feel like I'm playing a 1980's Atari game, and can't get past a mid-level boss!

Ah well. Good night all!

I've left the ISC LOCK guardian in the requested state "RF_DARM."

Today I measured the balancing of the OMC DCPDs, using an excitation at 103Hz into the OMC length servo, and measuring the height of the second harmonic in the nullstream channel.  The DCPDs are only, as far as I can tell, 1% misbalanced.  In the attached plot data are in red, the blue is a by-eye fit.  I have set the balance to be 50.5% PDA, 49.5% PDB (1% towards PDA on the slider).

 Evan, Dan, Jeff, Peter, Daniel, Lisa 

 2+ hours lock on DC readout, this time for real! 

* Feb 12, 5:33 UTC lock on DC readout, engaged ISS loops shortly afterwards

* Feb 12, 7:00 UTC improved low frequency noise by turning off ETMs optical lever damping

* Feb 12, 7:35 UTC still lock on DC readout, starting alignment tests (intentionally changing BS alignment; also reduced the BS optical lever damping gain by a factor of 10

*  Feb 12, 7:48 UTC unlocked by closing the AS beam diverter 

 Positive news of the day 

- Thanks to the  improved bounce mode damping , we can now reliably damp the bounce mode, and it is not a limiting problem anymore;

- ETMX and ETMY optical lever PITCH damping loops have been reduced by a factor of 100; it turned out that these loops were responsible for the huge excess of noise that we saw yesterday below 40 Hz, and that was causing the OMC transmission to shake painfully. Now the OMC is quiet and happy  (the Guardian has been updated to reflect this change). 

- We turned off the QPD alignment of the OMC, and replace it with dither alignment;

- We turned on the ISS first and second loops: the positive news is that we improved the high frequency noise by a factor of 10.



 Negative news of the day 

- While we have improved noise at low and high frequency,  we now have a new bump of noise around 100 Hz which was not there yesterday . 

- Our wonderful BS WFS loops, so effective yesterday, were not working today. However, today the BS alignment was not critical, and we have barely had to touch the BS anyway, but we need to figure out what happened. Right now we commented out the BS WFS in the locking sequence;

- Yesterday the locking sequence was very reliable, and worked 5 times in a raw..today it has been less robust, despite similar environmental conditions..

- The RF of in-vac POP is somehow broken - no signal there. It is probably not a big deal right now at low power. 

- We also closed the OMC REFL beam diverter (level 2 of "Valera's levels of awesome": it works, but it doesn't do anything)  

J. Kissel, S. Dwyer

After both Keita and Sheila had recited the H1 SUS ETMY's measured highest vertical, "bounce," mode frequency was 9.7305+/-0.0002 [Hz], I was glancing around at the various notching done in the control filters for H1 SUS ETMY. I'd found that the optical lever's pitch loop had a bandstop filter of
ellip("BandStop",4,1,60,9.7,9.9)ellip("BandStop",4,1,40,13.4,14.2)gain(1.25893)
i.e. just missing the ETMY frequency. Thus, we adjusted the filter to better match 9.7 [Hz], i.e.
ellip("BandStop",4,1,60,9.6,9.8)ellip("BandStop",4,1,40,13.4,14.2)gain(1.25893)

This reduces the gain of the loop at 9.73 [Hz] by a factor of 76.9231 (37.7 dB).

This was done well before locking activity go started this evening. The pitch loop remains on. As with the DARM DAMP filters, this change was individually loaded into the bank.

S. Dwyer, J. Kissel, K. Kawabe

After installation of the infrastructure (LHO aLOG 16655), and copying of LLO's filters (and adjusting for the specific frequency of 9.7305 [Hz]; LHO aLOG 16658), we tried damping the H1 SUS ETMY's highest vertical mode (a.k.a. "bounce" mode). 

For the first attempt, the IFO was locked only using ALS diff, with Sheila in the driver's seat. At the time, the mode had been rung up to ~7e-12 (DARM) [m/rtHz] @ 9.7 [Hz]. We had tried a few configurations of the filter bank, and only adjust the gain. We'd found how to ring *up* the mode with a positive gain, with the +60 [deg] (FM2) and bp9.73 (FM4) filters engaged -- then flipped the gain sign (i.e. flipped the phase 180 [deg]), and immediately could see reduction. We had the gain as high as -64, using ~50% of the DAC range, after which took about ~10 [min] for the mode to cool down to the ALS DIFF noise floor of ~1e-12 [m/rtHz] @ 9.7 [Hz]. 

After a lock loss of two, we were able to get as high the IFO guardian state "RESONANCE," with CARM controlled using digitally normalized RELFAIR9, and DARM has been transitioned to AS45 Q. At this point we saw the mode was still quite run up, so we again turned on the DARM DAMP V filter -- same filter combo, and we could see just as quick a reduction with a gain of -64. This time however, we were using much less of the DAC range, so I went up to a gain of -100, and the mode was quickly damped to the RESONANCE noise floor of ~1e-13 [m/rtHz] @ 9.7 [Hz] within a minute or three. 

With these two victories, I'm reasonably confident that this will be our ticket to future bounce-free success.

Design strings:
FM1 "+60dg"  zpk([0],[2.16667+i*12.8182;2.16667-i*12.8182],1,"n")gain(0.0523988)
FM2 "-60dg"  zpk([0],[1.21667+i*7.1979;1.21667-i*7.1979],1,"n")gain(0.0911865)
FM4 "bp9.73" butter("BandPass", 4, 9.3, 10.4)gain(120, "dB")
with all filters set to an input switching of "zero history" and output switching of "immediately." Attached is a bode plot of the final good set of filters together, FM2 and FM4. Note that these filters were loaded individually from each bank, Keita did *not* load the the whole foton file.

J. Kissel, J. Betzweiser, K. Izumi, M. Fays
Integration Issue 913, ECR E1400257, Work Permit #5048

Dave and my initial install of the h1calcs.mdl (for H1 CALibration [model]; Corner Station -- to avoid confusion with the PCAL models at the end station, which are h1calex.mdl and h1caley.mdl) model did not have the latest and greatest updates from LLO. After speaking with Joe Betz, he committed work he'd recently done with the l1calcs.mdl model, which now uses the following library part and c-code:
/opt/rtcds/userapps/release/cal/common/models/CAL_CS_MASTER.mdl
/opt/rtcds/userapps/release/cds/common/src/RING_BUFFER.c

As such, I updated the appropriate corners of the userapps repo, copied over
/opt/rtcds/userapps/release/cal/l1/models/l1calcs.mdl
and search and replaced l1calcs>h1calcs, l1oaf0>h1oaf0, llo>lho, L1:>H1:,=L1>=H1. The model is now re-compiled, re-installed, and restarted.

Kiwamu is working on filling in the infrastructure, but we're waiting for more information from LLO.

The CAL overview has been added to the sitemap, and relevant screenshots of the model and medm screens are attached. Max stresses that the MEDM screens are preliminary, and I agree.

The attached PDFs show the resistance measurements for all RHs and the relative resistance vs time for the RHs as 1W is applied to each segment. All segments are operating within nominal parameters.

The resistances for the segments are:

I have measured the violin mode using the most recent lock data (February 10th ~5pm). Due to the lack of precisions in the existing information and the mismatch in values I was not able to identify any of the peak except for the ITMX BR (Back Right) at 499.9 Hz. The violin mode found in the recent lock data are as follow:

499.9, 505.58, 505.71, 505.80, 505.85, 505.92, 506.92, 507.16, 507.20, 507.36, 508.01, 508.15, 508.20, 508.85 Hz 

The (fundamental harmonic) violin mode is expected to be somewhere between 500Hz and 520 Hz. Not every line is present - possibly due to high noise floor.

The violin mode has been previously identified as follow:

Positions of the wire:

BL = Back Left

BR = Back Right

FL = Front Left

FR = Front Right

Where's left and where's right you ask? I'm trying to find the answer myself!