J. Warner, A. Pele, J. Kissel

Jim has improved the isolation loop design for the HAM2, HAM3, HAM4, and HAM5 ISIs by increasing the frequency / aggression of the Level 3 isolation filters (along with tweaking the UGF and high frequency rolloff such that the aggressive boost remained stable). As such, we have a great deal more feedback gain in the 0.5 to 5 [Hz] region of all DOFs for these HAMs -- the region where the noise performance is typically loop gain limited -- and therefore the performance improvement has scaled linearly with the gain increase. See "IsoFilterComp" attachments.

We didn't have noise budget yet to prove it, but Jim had recognized that HAM6, the most recently designed chamber had much better performance, and much high boost frequency. 

Arnaud has gathered performance data comparing platform displacement before and after the change, which confirms the goodness locally. See "PerformanceComp" attachements. We didn't grab / compare the rotational degrees of freedom but these have also improved. Now that Arnaud has installed properly-matched, sensor correction, gains (see LHO aLOG 16208), we should expect a little bit better translational performance, so we'll compare again and make sure we capture rotational DOFs. Further, we plan to use calibrated DRMI cavity control signals to ensure that what we've done locally is good for the IFO.

The parameter files for these new current designs can be found here:
HAM2/Scripts/Control_Scripts/Version_3/Hori_ISO_H1_HAM2_Lv3_HR_2014_10_23.m
HAM2/Scripts/Control_Scripts/Version_3/Vert_ISO_H1_HAM2_Lv3_HR_2014_10_22.m
HAM3/Scripts/Control_Scripts/Version_3/Hori_ISO_H1_HAM3_Lv3_IMC_HP_2013_01_16.m
HAM3/Scripts/Control_Scripts/Version_3/Vert_ISO_H1_HAM3_Lv3_IMC_HP_2013_01_16.m
HAM4/Scripts/Control_Scripts/Version_3/Hori_ISO_H1_HAM4_Lv3_HR_2014_09_22.m
HAM4/Scripts/Control_Scripts/Version_3/Vert_ISO_H1_HAM4_Lv3_HR_2014_09_16.m
HAM5/Scripts/Control_Scripts/Version_3/Hori_ISO_H1_HAM5_Lv3_2014_09_25.m
HAM5/Scripts/Control_Scripts/Version_3/Vert_ISO_H1_HAM5_Lv3_2014_09_25.m

8:38 Rick to EX to pick up PCal equipment

9:30 Benton PUD on site

9:32 Fil to LVEA working on PEM mics

9:38 Karen to MY

9:40 Rick done at EX, heading to EY for PCal work

9:57 Jeff and Andres to LVEA for cleanup

10:09 Jeff and Andres out of LVEA

10:45 Benton PUD off site

11:00 Pepsi truck on site

11:10 Karen done at MY

12:23 Fil back to LVEA PEM work

14:00 Fil kicked out of LVEA by mean commissioners :(

I have turned up the preamp gain on the LSC-Y_TR photodiode (a PDA100A on ISCTEY) from 0 dB to 20 dB. The BS immediately before this PD is a BS1-1064-50-2037-45P.

The LSC-TR filter banks have been adjusted as follows:

• LSC-Y_TR_A_LF: gain changed to 0.0185 from 0.185; offset changed from -30 to -40
• LSC-X_TR_A_LF: offset changed from -180 to -171.

Reminder, if you wish to edit the site map, please do so in the /opt/rtcds/userapps/release/cds/h1/medm directory.

Please do not do it in the /opt/rtcds/lho/h1/medm directory as this breaks the symbolic link and the change does not get committed to the SVN version control repository.

I repeated the study I did on the L1 ADC hold times  ( aLOG entry 16455 ) using date from H1.  It is running the tagged RCG 2.9 and has higher thresholds (MAX_ADC_WAIT_CARD_0 of 20, MAX_ADC_WAIT_CARD_S of 3).  

Here, I record values from the IOP model proc file (i.e. cat /proc/h1ioplsc0/status on h1lsc0)

Again, in most cases ADC#0 Max + Max Delta = Max Hold.  It does appear that better limits of 23 and 5 for MAX_ADC_WAIT_CARD_0, MAX_ADC_WAIT_CARD_S (from L1 data) would work here.  The current CDS bugzilla issue is Bug 791

Last week, sts correction gains were measured and calculated on HAM4/5/6 to improve the CPS sensor correction. We measured them today for the remaning chambers.

For the BSC chambers, we locked the platforms to the ground by increasing the blends to 750mHz (cf alog) and turned off the sensor correction. We measured the ratio between the T240 (stage 1) and the STS (ground) signal (should be 1 with the platform moving with the ground). The same measurement was also carried out between STS and L4C for hepi, since IPS sensor correction is used for the Z DOF.

All the measurements using the corner station STS B as input to the sensor correction (ITMX, BS, ITMY) show a factor of two mismatch with the hepi and platform sensors in the X DOF only. There is certainly a calibration error with the STS B seismometer. I checked the calibration filter in the input filter banks and it looks correct (10.17 nm/s /cts). We should investigate more. The other chambers and dofs need a relatively small correction. 

The ISI gains (T240/STS for BSCs and GS13/STS for HAMs) are 

The BSC - HEPI gains (L4C/STS) are

Attached are examples of the transfer functions for ITMY 

To calculate the gains I wrote a script for the bscs in a similar fashion as Sebastien's : it is called BSC_gain_matching_calculation(IFO,Chamber,start_time,duration) located under /ligo/svncommon/SeiSVN/seismic/BSC-ISI/Common/Misc. The results above were obtained using the following parameters : 

start_time=tconvert('01/22/2015 15:35') ;
duration = 45*60 ;

Yesterday I dif the ETMs.  Today I did all the remainder.  All came back under guardian first time.

To help with setting up SDF files, I have created lists of channels modified by the H1 guardian nodes for the month of January up to this time. We expect this to be a fairly exhaustive list as it covers the RCG2.9 upgrade on the 13th Jan when all front ends were restarted.

There is a text file per guardian node in the directory /opt/rtcds/lho/h1/data/guardian_channels/guardian_control_channels/2015jan

Attached is a list of the number of channels controlled per guardian node. As expected it is quite small. For example: SUS_ETMX has 1,717 set point channels of which 53 were changed (3%); ISI ETMX (ST1 and ST2) have 1,952 set point channels of which 124 were changed (6%).

Found that the angular control inputs of TMSY were off since Tuesday (restore issue?)

Moved the gain of the TMSY ISC P/Y input modules into a CAL filter. This makes Y the same as X.

The safe.snap was updated.

New tidal code was loaded for both arms which delays the tidal servo by 5 seconds after the arm has locked.

Also fixed the long standing problem that some of the values in the PLL/PHD autolockers were not restored automatically after a PLC restart.

J. Kissel

While the BSC-ISIs were in an odd configuration anyway for obtaining sensor correction gain matching data (see LHO aLOG 16200), I took the opportunity to clean up, clean out, and fill in the ST1 and ST2 BLND_NXT filter banks with the correct, high performance, Ryan DeRosa, blend filters. Recall that the CUR (for "current") and NXT (for "next") filter banks should have the same exact filters in all filter modules, such that they can be used for the automatically switching between blend filters on the fly (see T1200126). 

All NXT banks for ETMX, ETMY, ITMX, ITMY, and BS now have identical filters as what's in place in the CUR banks (HAMs are already up-to-snuff). 

Further, I've cleared out all "Unknown", gain-of-one, filters which seemed to have been sporadically peppered in the higher numbered FMs. 

Finally, when transitioning back from the "Start" filters to Ryan's filters (by hand), I've left the RZ filter banks with all FMs OFF, because we don't run the RZ isolation loops.

For the record, I performed the copy and paste by-hand in foton, saved filters via foton, and reloaded all coefficients simultaneously using the GDS_TP screen. Further, I've committed all affected filter files (and any other I found different from the SVN -- the HAM's .txt files because of Jim's recent improvement of the isolation loops [aLOG pending], and HAM4 and 6's .fir files, because Jim installed them Dec 2nd [aLOG "pending"]). 

Also -- I did not have enough time to *test* whether the newly implemented filters allow for smooth switching between the low-noise filter set and any others, but my suspicion is that it *still* won't work, given that the blend switching software cannot handle filter sets that occupy two FMs, which is the case for the RX and RY filters on ST1.

J. Kissel, A. Pele

In order to gather measurement data for GND to ST1 sensor correction, I've switched all chamber's ISIs except for HAMs 4-6 to a high-frequency blend. For the HAMs this means the "750mHz" blends, and for the BSCs the "Start" filters (see attached) and turned both ISI X&Y and HEPI Z sensor correction OFF. Yesterday, worried that there still might be residual garbage from initial install in these filter banks, we've confirmed that all chambers involved have the same filters as attached.

The chambers have been set up in this fashion since 
1105975887 Jan 22 2015 15:31:11 UTC
(We blends switched by done by 15:05 UTC and 15:22 UTC in the HAMs and BSCs, respectively, but I forgot to turn OFF the sensor correction until Arnaud reminded).

model restarts logged for Wed 21/Jan/2015
2015_01_21 01:47 h1fw0
2015_01_21 13:36 h1fw1
2015_01_21 15:05 h1fw1
2015_01_21 15:29 h1fw1
2015_01_21 15:43 h1fw0
2015_01_21 17:26 h1fw1
2015_01_21 17:40 h1fw0
2015_01_21 18:43 h1fw0
2015_01_21 19:08 h1fw0
2015_01_21 19:40 h1fw0
2015_01_21 20:42 h1fw0
2015_01_21 23:03 h1fw1
2015_01_21 23:29 h1fw1
2015_01_21 23:45 h1fw0

All unexpected restarts. Inexplicably both frame writers have become unstable, starting about 24 hours after Tuesday's solaris reboots. I may try another solaris reboot today.

I've attached a trend of the h1fw0 and h1fw1 restarts for this month (h1dc0 restart is included to show intentional DAQ restarts). The instability starts 1/13 when we upgraded to RCG2.9.

Conlog frequently changing channels list attached.

Alexa, Evan, Sheila, Koji, Rana

We have been locking the arms tonight, with DRMI on 3F and trying to transition CARM to sqrt(TRX+TRY).  

So far no success, although we found several setings which were wrong.  

We tried moving the CARM offset (using the COMM VCO) to -200 Hz (green), and adding a small amount of gain, 1/10 of our nominal gain.  Rana saw that this adds a lot of high frequency noise to CARM.  

Sheila, Kiwamu, Rana, Evan, Daniel, Alexa

We had hope to explore the phase-space of DRMI and improve the lock acquistion time; however, we did not get very far. 

We began with DRMI+arms off resonance under the nominal gaurdian configuration. We acquired the lock 5 times, and found the following acquisition times:

At this point we checked the demod phases for the 1f signal, and decided to adjust the REFL45 phase from 137 deg to 142 deg. We also changed the MICH upper trigger to 5.0 from 10.0. and touched up the alignment (this probably ruins the validaty of our test). With this configuration, we repeated the above and found:

* flipped CARM offset at one point. 

Overall this test was pretty inconclusive, but I thought I would post the lock aquisition times. This evening, we have been running with the MICH upper trigger threshold at 5.0 and it takes about 15 min or so to lock again ... 

A few filter changes for the MICH / BS tonight:

1. Moved the Butterfly stop band filter from the M2 COIL filter banks into the M2 LOCK, so that we only have to use 1 filter. I think there's no danger of the  mode getting rung up by the OL loops.
2.  Removed the 300 Hz notch for the BS Violin and replaced it with a 10 Hz wide 80 dB stopband filter. There is no appreciable phase lag at the MICH UGF of 10 Hz. This catches not only the 299,5 Hz BS violin mode (which was ringing up and saturating tonight), but also a couple peaks at 302 and 303 Hz which were dominating the BS DAC range when the DRMI was locked on the 1f signals.
3. The MICH loop phase margin is only ~25 deg, due to the low freq boosts and the elliptic low pass at 40 Hz. I have made a RLP65 to replace the ELP40. This has approximately the same phase lag, but better attenuation around 100 Hz. During the 3f lock the RMS at the DAC was ~33000 counts (out of 131000). This was ~8-10x more than during the 1f locks and mostly comes from the low SNR of the BBPD used to acquire the REFL 3F signals.

My guess from the noise that we hear in the speakers is that the BS coil driver DAC channels has been lightly saturating whenever we reduce the CARM offset. Its pretty close to the rails before we start and the signals are only noisier when we're on the side of the CARM fringe.

The first attachment compares the ELP40 with the RLP65.

The second attachment compares the M2 LOCK signal with 1f lock (PURPLE), 3f lock (BROWN), and 3f lock with the new filter (BLUE). The new filter gives us a 3-4x reduction in the RMS. I think this should give us a more smooth 3f lock and a smoother CARM reduction.

J. Kissel, A. Pele

While Seb suggests that moving the HAM3 blends to the "250mHz" configuration is a good configuration to "solve" the 0.6 [Hz] feature (see LHO aLOG 16100), we argue that it would be better to live with a 0.6 [Hz], digitally-sharp, peak than to increase the X motion by the factor of several. OR we should find a different set of blend filters for RY that *don't* increase the low frequency motion.

I attach 2 supporting documents:
(1) 16196_20150121183131_H1-SEI_QUIET_3C14C7_SPECTRUM-1105747216-86400.png
The performance comparison between all HAM platforms from the Jan 20th summary pages. On this day, HAMs 2, 4, 5,and 6 are in the "nominal" LHO configuration, all using "01_28" blends on all degrees of freedom, with sensor correction ON for all DOFs, GS13s in high-gain mode, with newly improved isolation loops. HAM3 however, was in Seb's suggested configuration -- the same as the other HAMs *except* for the RY blend filter, which has been changed from "01_28" to "250mHz."

(2) 2015-01-21_H1vL1_BlendFilter_Comparison.pdf
A comparison between the H1 "01_28," H1 "250 mHz", and L1 "400" RY blend filters, as well as the H1 "01_28" and L1 "250" X blends. This shows that 
   (a) In RY, 
       (i) the H1 "01_28" and L1 "400" are virtually identical, as expected. To be precise, for some reason, the L1 GS13 filters are 8% higher in gain, but otherwise identical.
       (ii) The H1 "250mHz" blend is actually *lower* in blend frequency than the H1 "01_28" filters. This means the low-frequency roll-off of the GS13 high pass is much slower for the "250mHz" than for the "01_28".
   (b) In X, 
       (i) there is a good bit of difference in the 0.2 - 4 [Hz] region. We suspect this is because the H1 "01_28" filters were copied over from LLO in Oct 2013, before Ryan had made further tweaks to these blend filters to improve performance around the SUS resonances. The performance is most different at 0.75 [Hz], where the displacement sensor low-pass is lower by a factor of 10.
       (ii) it's concerning that the GS13 high-pass -- though 19% different in overall gain -- does *not* differ between the two site's versions of the filter. This must be what Ryan means when he suggests his filters are "almost" complementary.

While all points are interesting with respect to the sociology and history of the SEI commissioning, point (2)(a)(ii) is the key for HAM3. Because the RY GS13 filter rolls off slower and lower for the "250mHz" blends, the differential vertical GS13 noise is reinjected into the RY loop. This excess residual RY motion couples to X via tilt-horizontal coupling, which degrades the low-frequency noise performance in the same frequency region. Bad. We'd discovered this nasty cross-coupling path as far back as The Stone Ages.

We should find/design an RY filter for HAM3 that *increases* the blend frequency from the H1 "01_28" filters, if we intend to run for a while in such an odd configuration. We may try copying over a few other L1 blend filters. This is all still lower priority compared to the *rest* of the to-do list, but Arnaud and I are worried that the excess low-frequency motion in HAM3 alone might be causing problems with cavity motion.

(Kyle R, Gerardo M)

The new ion pump became railed sometime after decoupling the pump cart yesterday, and remained railed overnight.
This morning after pumping down the annulus system with the pump cart, we determined that the main valve was leaking.
So, to minimize exposure of the annulus system to atmosphere, we decided to add another valve in series with the leaky valve.
After pumping down on the system for about 25 minutes, the Ion pump started operating as it should, and is currently at 1.5 amps.