J. Kissel 

I've measured this week's charge assessment early, just to get it out of Tuesday's way while opportunity struck during ISS improvements this morning. 

All is well: charge continues towards zero, and it looks like in a few weeks -- at the start of ER10 -- we can try regular ESD bias flipping again. 

Impressively, but perhaps inconsequentially, the rate of charge on ETMX has increased substantially over the past few bias flips. However, this may also be a function of how much time we've spent over the past few months commissioning with the DARM drive still on ETMX. The fluctuation of actuation strength of ETMX is not important to calibration, and lock acquisition is not-so-sensitive to it, but this fast rate may confuse our assessment of the charge from week-to-week while it hovers around zero. Perhaps we should consider -- during ER10 at least, if/when we begin regular flipping -- measuring charge twice a week, just to get more that one data point per flip. 

WP6168. Daniel:

A new h1ascimc model was installed. This replaces two SPARE DAQ channels with 3 PWR_EOM channels in the commissioning frame (all at 2kHz). Additional filtermodules were added (no DAQ inclusion).

Model and DAQ were restarted at 11:55 PDT.

Pressure comparison between hot IG and cold cathode gauge on diagonal volume. Tomorrow CC will be decommissioned via WP 6166.

(green trace is hot IG; red is CC that has been flaky and turning off periodically)

J. Kissel reporting for D. Sigg, K. Kawabe, L. Barsotti, M. Evans, K. Izumi, R. Savage, P. King, J. Oberling, J. Driggers, R. McCarthy

The following ideas / action items were discussed at this mornings 9a LHO commissioning meeting to battle / reduce intensity noise; the primary high-frequency noise contribution/ limitation to the DARM sensitivity at the moment. I don't know every detail, so hopefully you can glean the action from the words I was able to capture from the meeting. The list is also in no particular order, but the hope is to accomplish most of these tasks over the next few days.

- Look at recent DBB scans for any evidence of free-running intensity noise badness.
- Reduce PSL HPO chiller flow rate from 0.7 [L/min] to 0.5 [L/min] returning to O1 level flow rate
- Remove ND filter that had been recently installed to rule out scattering noise from the 1st loop PD array
- Inspect PMC output ports for excessing scattering / badness
- Move EOM on its translation stage, checking for changes in intensity noise output.

- Install high-sensitivity electronics on EOM PD (IO_AB_PD3 in D0902114, read out as H1:IMC-PWR_EOM_OUT16) and IMC PWR IN (IO_AB_PD2 in D0902114, readout as H1:IMC-PWR_IN_OUT16)
- Install extra high-sensitivity PD in ALS path on PSL table. (This path is upstream -- toward the front-end laser -- of the EOM. The PD will be used to compare the intensity noise upstream vs. downstream of the EOM  which is currently an area of suspicion. The worry is that there is too much between the pickoff on the PSL and where this pickoff is already captured on ISCT1, which may confuse the intensity noise measurement)

- ISS front-end model reboot in order to improve channel naming conventions for ISS channels (e.g. INNERLOOP / OUTERLOOP to FIRST/SECOND LOOP-like changes)
- PEM front-end model changes to store PSL accelerometers at higher sampling rate
- ASCIMC front-end model changes / or create a new front-end model to process/store EOM PD, IMC PWR IN PD, and IM4 TRANS at higher, (4? 16 kHz?) rate. 

- Modify new ISS 2nd loop analog electronics (drill a few holes in front panels) to pull out more signals to analog BNC spigots

- Move IMC / IFO alignment offsets to find jitter coupling minimum.


Hope this helps!

No restarts over this 3 day period. Test frame writer did some restarts Friday morning, none since we installed RCG3.2-daqd (aka Jonathan's code) Friday afternoon.

• Tuesday maintenance will be a busy one, possibly taking all day. Thursday might be used as maintenance as well. 
• ER10 begins end of next week.
• SEI - Everything looks good. Nothing to report
• SUS - Nothing to report. Charge monitoring, ongoing.
• CDS ELE - Intrusive work to be done regarding end station Beckhoff. Ongoing ISS work.
• PSL - Intensity noise investigation to be don this morning
• VAC - Experimentation on CP4 (Tues). Kyle doing RGA bakeout at EX. PT140 can be turned off.
• FAC - Flushing RO system. Punch list items found during safety review to be addressed.
• GC - No internet Tues between 8:00-9:00AM PDT. Final stage of process.

I made a few guardian changes this afternoon. 

• Terra and I found that CHARD blends cannot be on durring the power up, so we are turning them off in DOWN, engage CHARD without them, and turn them on in Low noise ASC.
• I moved the step that switched off the SRM dither and moved it to WFS signals into its own state (SRM_ASC_HIGH_POWER).  Yesterday Jenne and I found that we had to wait about 10 mintes after powering up to do this step, but it has to happen before NOISE_TUNNINGS.  
• Since the ISS seems to have trouble engaging the second loop imediately after the IMC locks, I changed the request in ISC_LOCK DOWN to "LOCKED" and put a request in ISC_LOCK DRMI_LOCKED to set the MC to "ISS_ON"
• I think that I finally fixed the bug that meant that in ALIGN_IFO the dark michelson tried to grab which the optic was still swinging and woud get stuck saturating the BS. 
• In DRMI ASC I added something that makes sure the ASC on switch is on (to avoid self inflicted locklosses)

A few things about ASC

• While moving SRM at high power, I looked for an SRM yaw signal in AS36 I, AS45 I, and REFL45.  It seems like REFL 45 might be the best hope we have, but those signals are all dominated by a loop with a slow oscillation (a few second period), which might be PRC1 or a cross coupling between PRC1 and something else.  If we can fix this, we might be able to find a decent SRM signal in REFL. 
• It seems like the CHARD gain is set too low after low noise ASC, causing it to oscillate.  There might have been a mix up in the guardian, but we should just measure the loop to check anyway.  
• Our DC centerig loops have peaks with high coherence with DARM at a few hundred Hz.  This might be because they are seeing the same jitter that couples to DARM, not because they impose the noise.  

This afternoon Terra and I had a few hours long lock durring which we injected white noise in the ISS, and the IMC PZT (alternating between PIT and YAW). We found that we were able to reduce the jitter coupling by almost 8dB by moving the POP A offset for PIT, which also seems to have reduced the intensity noise coupling slightly (2 dB).  While the couplings did drift as the interferometer thermal state changed at the begining of the lock, the improvements were reproducible with an on off test.  

We started by moving SRM in both pit and yaw, but saw no impact on the jitter coupling that was reproducible with an on off test, which is different from what was seen in alog 25654 and 25657.  The POP PIT offset changed from 0.24 to 0.47.  Durring the move POP 18 improved by about 10%, while the recycling gain improved by about 1%, but neither of these were at their best in the final location. We started trying to move the yaw offset, which looks like it needs to be moved closer to 0, but lost lock due to a bounce mode. 

In the first attachement, you can see a comparison of the DARM spectrum before and after the POP move. The second screenshot shows comparisons of the couplings before and after. The third shows trends of powers durring the change, and the awg set up for the excitation.  

We had two ~12 hour locks Friday and Saturday night and ~3 hour lock today. A new PI rang up in both about 6 hours into lock; 15606 Hz on ITMX, now MODE3. I've added damping settings to medm, StripTool, and SUS_PI guardian. Currently It's set to be damped using the PLL; we'll have to wait for another long lock to see the success. 

Modes 17 & 25 (ETMX 15541.5 Hz & ETMY 15542 Hz) continue to be tricky. Friday night they were both under passive BP (after having PLL jumping problems previously). They rang up about two orders of magnitude before slowly damping (first trend). Saturday night Mode 17 was put under PLL control and there's no large ringup (only a slight upward trend over the 12 hours). Tonight, still in this configuration, I saw the same sudden ring up after about 3 hours. Switching away from PLL to BP only rang up more quickly. Again, with Mode 17 in PLL and Mode 25 in BP, we can keep the overall peak from rising more but I'd like to thwart this sudden rise if possible and know why it didn't occur Saturday night.

Leaving Mode 17 in PLL control with phase settings tweaked (damped it faster this past lock) and Mode 25 in BP. 

PMC has three transmissive output ports: EOM monitor and 2nd loop out of loop sensor are on the same main port downstream of EOM, 1st loop out of loop sensor is on another port, FSS refcav transmission monitor is on yet another port. We looked at these four sensors.

Note that this is not a conclusive entry.

Free running RIN shows all the acoustic features and all sensors agree.

Reduction of power on ISS 1st loop sensors allowed us to look at the free running intensity noise without ISS without saturation, which was impossible before. (Actually 1st loop sensors still saturate once in a while when ISS is off, but not all the time any more.)

In the attached plot of RIN, top panel is without ISS. All sensors agree with each other including acoustic structures (I'm talking about broad bumps at around 440Hz, 580 and 680Hz).

This means that, when free-running, intensity noise coming out of PMC caused by acoustics (jitter-intensity conversion by PMC, maybe some clipping upstream, intensity noise straight out of HPO, everything combined together) is far larger than the acoustic coupling downstream of PMC. But that free-running intensity noise caused by acoustics is reduced to almost nothing with ISS, and as soon as the ISS is turned on we start looking at the residual noise caused by the jitter coupling downstream of the PMC.

We should look at DBB measurements from the past to see if the measured jitter and intensity noise out of HPO are consistent with the above picture.

ISS ON, some differences show up.

On the bottom panel (with the same Y axis scale as the top) is the same set of RIN signals with the first loop on but the second loop off (solid) and with both loops on (broken).

Roughly speaking,

• EOM monitor and the second loop sensor behaves the same way.
• FSS sensor is squashed a factor of 2 more by the 1st loop than the second loop sensor, but doesn't change much by the 2nd loop.
  • (Actually FSS sensor somewhat increases by the 2nd loop.)
• When 2nd loop is turned ON, the 1st loop sensor becomes about the same as the 2nd loop sensor was when only the 1st loop was on.
  • (Actually it becomes somewhat worse than the 2nd loop sensor was.)

Let's define jitter coupling Cn (n=1, 2, E, F for 1st loop, 2nd loop, EOM and FSS sensor) as the sensitivity of a specific sensor to the jitter coming out of PMC. Jitter generated by downstream of PMC (e.g mirror shaking) could also be included in Cn assuming that the new jitter is coherent with the original jitter.

From a simple model that is shown later, we can say that  one of EQ1 and EQ2 below is true, and EQ3 is always true:

• EQ1: C2~CE
• EQ2: |C2|<<|C1|, |CE|<<|C1|
• EQ3: CF~(C1+C2)/2

What we learn.

If EQ1 is true:

There's a common coupling point upstream of EOM monitor and downstream of PMC (e.g. EOM aperture, steering mirrors, PMC enclosure window, back of the PMC mirror).

Local jitter-to-intensity coupling for each of the sensors, e.g. peri mirror causing additional jitter and IMC (with alignment offset) converting it to intensity for the 2nd loop, is much smaller than the common coupling because there's no difference between CE and C2.

We cannot say if C1 is large or small in this case except that |C2-C1| is large.

If EQ2 is true:

Jitter coupling of the first loop sensor path is the large one here (e.g. steering mirrors, PMC output window, back side of the PMC mirror, PD surface).

The EOM and the second loop sensor path jitter coupling is negligible at this level.

EQ3 is always true:

FSS path jitter coupling via REFCAV, AOM etc. happens to be about half of the first and the second loop sensor path added together.

What we should do.

ISS doesn't do anything to the jitter itself. Even if ISS is totally insensitive to the jitter, the jitter still pollutes the IFO. We need to make ISS as insensitive to the jitter as possible, but we also need to mitigate the jitter.

• See if EQ1. is true, and mitigate.
  • EOM alignment, dust particulate on the PMC enclosure window, back of the PMC mirror, and steering mirrors.
• See if EQ2 is true, and mitigate.
  • Dust particulate on the PMC enclosure window, back of the PMC mirror, steering mirrors and BS.
• Reduce jitter. It's clear that there's too much jitter.
  • Flow rate?

If jitter cannot be mitigated, and if the IFO jitter coupling as well as the IFO intensity coupling are both stable, we might be able to sense the jitter (e.g. IM4) and feed forward to ISS. Feeding back to input pointing into IMC by PZT mirror doesn't sound like a good strategy when we need to do it in wide band between 300Hz and 1kHz.

I took a quick look at six hours of 30-minute SFTs automatically
created by FScans this morning (thanks for setting the intent bit!),
to see if recent line mitigation attempts have reduced the amplitude
of the 1-Hz and other combs at low frequencies. Unfortunately, 
the low-frequency noise floor is too elevated to say much yet
about that mitigation success, but in the band 28-32 Hz, where
last night's noise is lower, there do seem to be fewer and lower-level
lines, including reduced amplitudes for the 1-Hz comb with a ~0.25-Hz offset.

Please note that the 56.84-Hz comb reported in the ER9 data
(present but weaker in O1 data)  remains quite strong.
There are other strong lines present, too, but I gather noise-hunting
is just getting started. The 56.84-Hz comb suggests a DAQ problem
somewhere, as noted before.

The attached plots show different bands of O1 data (narrow black curves)
superposed on last night's data (broad red swath). In each case, an 
inverse-noise weighting is used, to suppress periods of elevated noise.

Figure 1 - 10-2000 Hz
Figure 2 - 10-28 Hz
Figure 3 - 28-32 Hz
Figure 4 - 32-50 Hz
Figure 5 - 50-100 Hz
Figure 6 - 100-200 Hz
Figure 7 - 200-1000 Hz
Figure 8 - 1000-2000 Hz

[Sheila, Jenne]

The CHARD error signal blending is back in the guardian.  Note that I engaged it by hand while at NomLowNoise, but it's in the guardian to come on during EngageReflPopWfs.  So, it has not yet been tried during the acquisition sequence. 

Next time, it should just come on correctly with the guardian.  But, in case we need to come back to turning it on later, I used the same procedure for pit and yaw:  Engage the blend filters on the B filter banks, ramp up the gain to 1 over 10 sec.  Once it's started ramping, turn on the matching blend filter in the A filter bank, which ramps on over 10 sec.

In the attached screenshot the solid traces are before blending, and the dashed traces are after blending.  You can see that as expected, the blending significantly reduces the CHARD noise in DARM, and the coherence between CHARD out and DARM decreases dramatically.   There's still a bit of coherence left around 15 Hz with CHARD_Y, but it's much better than it was.

I leave the IFO undisturbed with the Observe bit set starting at 03:10:00UTC.

Sheila Jenne

We made some quick intensity noise injections using the second loop, and jitter using the IMC PZT.  A first look at the data suggests that several of our peaks in DAM which show coherence with the ISS sensor are due to jitter coupling, rather than intensity noise. This menas that we can't fix these peaks with more ISS gain, but we might be able to do something by changing alignment offsets.

The attached plot shows the noise in DARM (taken with MICH FF off, which causes extra noise at 100 Hz), a projection of intensity noise in DARM based on the ISS PDs, and a projection of the jitter noise in DARM based on IM4 trans yaw. I"ve used a coherence cut off of 0.5 for the transfer function measurements used here.  

Still to be done:

• pico IM4 trans so that it is centered in pitch and we can get a better pitch jitter measurement
• Cut out frequencies where IM4 is sensor noise limited (this probably won't affect the peaks of the jitter projection.)
• Repeat with MICH and SRCL FF on to see what we can learn about the noise at 100 Hz. 

I have remeasured the SRCL feedforward transfer function, and put it into the SRCLFF1 filter bank, and into the guardian.

Injections were done: SRCL1_EXC from 22:24:30-22:28:40 UTC, SRCLFF1_EXC from 22:13:20-22:17:30 (no filters engaged, input off, gain=+1).

The matlab file SRCLff.m grabs the data from the injection times, and calculates what the feedforward filter ought to be.  The matlab file Fit_SRCL_Filter.m loads that filter and uses vectfit to find the appropriate poles and zeros. 

The first image (Measured_vs_fitted_SRCLff.png) shows the agreement between the calculated transfer function that we want, and the result that vectfit gives.

The second image (New_vs_old_SRCLff_filters.png) shows the difference between the old FF filter and the new one.

I then took 3 different spectra and coherences, as shown in the third image (NewSRCLff_works.png):  Blue is without any SRCL FF, brown is the old SRCL FF with the gain of -1.3 that Lisa found yesterday, and pink is the new SRCL FF with a gain of -1.  While it's not a lot, there is improvement between 10 Hz and 30 Hz with the new filter over the old.  Either one is better than nothing though.

Note also that the old feedforward scheme was using an elliptic 4.5 Hz highpass (FM8=AC2 in SRCLFF1) while I am using a much more gentle 1 Hz highpass that was already installed (FM3=AC in SRCLFF1) so that I don't change the phase of my filter as much above 10 Hz.  Both cases have the FM6 and FM7 SBVio1 and SBVio2 filters engaged. 

Here is the current state of the H1 DAQ.

h1fw0 and h1fw1 have been completely stable for several weeks, and following the code fix on Wednesday 9/7 the frames written by both are 100% identical. These systems have the same hardware and are running the same code, but h1fw0 occasionally asks for retransmissions and h1fw0 never does. The OS install is slightly different between the machines, and we will try cloning fw0 from fw1 next week.

h1fw2 is a front end computer, running U12 with a local disk system for frames. It was running the original daqd code, but went unstable after the Sat 9/10 power outage. We upgraded it to the rcg3.2 daqd this afternoon to see if this improves stability. It is now connected to UPS power.

Now that h1fw2 has the new set of EPICS diagnostics channels I have expanded the DAQ overview medm screen to show these.

Sheila, Kiwamu, Evan, Matt, Lisa, Jenne, Corey

Tonight the locking has been stable enough that we were able to try several low noise steps.  We ended up with a range of about 20 Mpc, and were locked for 3.5 hours.

• Earlier this afternoon Matt, Evan, Kiwamu, and reduced the ISS loop gain by 4dB, to reduce the gain peaking visible in Peter King's plots (29725)
• We've used the guardian states LOW_NOISE_ASC (for reducing arm loop bandwidths, which Jenne checked out earlier), COIL DRIVERS (after a few additional bug fixes), LOWNOISE_ESD_ETMY, and ran the A2L script for the test masses.
• Kiwamu noticed that the AS WFS DC have been close to saturation at 50 Watts.  This might have been part of the reason the OMC alignment was railing in some locks.  To help with this he reduced the modulation depth for 45 MHz by 3dB, and moved the REDUCE_MODULATION_DEPTH state to before the power up. The OMC drives are not large right now.
• Kiwamu reduce the DARM gain by a factor of 2 (in guardian at DC readout) because there was gain peaking.
• We reduced CSOFT PIT back to 0.2 for the digital gain, and CSOFT Y from 3 to 2.
• We have not used the third loop tonight.  We accidentally powered up with it off, and that has been fine.  With the 3rd loop off we don't have the low frequency ISS oscillations that caused us to DC couple the ISS last night.
• I also made a few changes in the IMC LOCK guardian. After talking with Keita, we realized that if the 1st loop saturates and turns off, the second loop would not be turned off.  The guardian is now written to handle this, but I don't think this has happened tonight so we haven't tested it. 
• We measured the SRCL and MICH loops (screenshots and data attached). SRCL still has 6dB of gain peaking, the MICH loop would have been unstable with the boost that gets engages in the state NOISE_TUNNINGS, so we increased the gain by 3dB to a digital gain of 2. 
• When need to move SRM ASC loops off the dither before we reduce the gain of SRCL.  We were sucsesfull for PIT, using 4*ASA36I-ASB36I, and a gain of 3 (FM1 off).  We picked this matrix about 3 hours into a lock, after the thermal state had stabilized.  The next lock we tried it shortly after powering up, and it seemed fine.  We haven't added this to the guardian but probably could.  We tried a similar procedure for YAW, but about 2 hours into the second lock we opened the loop because SRM was slowly becoming misalinged. 
• We tried MICH and SRCL FF, MICH worked fine with the old settings, and improved the noise around 100Hz, we are now limited by SRCL at 50 Hz and below.  We tried SRCL FF, but it made things unstable so we need to check on it tomorow.
• Evan updated the calibration. It was off by 20%. 
• For our last lock, the violin mode damping was somehow off the whoel 3 hours.  Rung up violin modes ended up breaking the lock.  If tomorow's operator has a chance to lock at 2Watts and damp violins using the instructions on the wiki, that would be great.

The BRS at EY has had a long term drift requiring periodic recentering. That drift seems to have stopped or changed sign, following the power outage on Saturday. Attached image is a 60 day trend for H1:ISI-GND_BRS_ETMY_DRIFTMON. The black streaks are from when the BRS went out of range and when it was recentered during Krishna's last visit. The little blip up to zero at the end is from the power outage, before the commissioners recovered the BRS code. Second image is the last 6 days, outage is when the signal goes to zero. Definitely looks like the drift has changed sign.

I have updated the correction filter for the dtt DARM spectra that are projected in the wall and screens in the control room. I hope Evan will like it.

This does not affect the CAL-CS or GDS calibrations. This is only for display purpose in diaggui.

[The DARM spectra]

Here is a comparison of the newly corrected and previous DARM spectra.

As shown in the attached screenshot, the high frequency excess wing that has been shown above 3 kHz is now gone. The noise level at around 7 kHz now seems a bit too low compared with the f-shaped GWINC curve (shown in green). This maybe a real calibration error because I have applied the best and latest knowledge about the sensing chain for correcting the spectrum.

The correction filter is made by a matlab script:

/ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/PreER8/H1/Scripts/ControlRoomCalib/H1DARM_FOM_correction.m

This script creates a text file which contains the correction filter in [freq, dBmag, phasedeg] format from 1 Hz to 7444 Hz. The text file can be found at

/ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/PreER8/H1/Scripts/ControlRoomCalib/DARM_FOM_calibration.dat

Both script and text files are checked in to the svn. Also I updated the latest FOM dtt template, H1_DARM_FOM_20150722.xml so that it now uses the new correction filter.

[Corrections newly included]

Here is a list of what I newly included.

• Analog anti-aliasing filter
  • See this plot from alog 17951
• Unconmpensated OMC DCPD poles
  • See this plot from alog 18037
• True zpk([355], []) cavity pole, instead of zpk([355], [7000]) in the IIR filter
  • See some discussion in G1501013

Note that the previous correction was made only from the IOP down sampling filter and the numerical whitening zpk([1,1,1,1,1], [100,100,100,100,100]) which are still included in the new correction.