After the LHO IFO dropped lock around 1pm, Leo and I jumped on making more charge measurements of ETMx and ETMy via the oplev/ESDs.  However, we immediately recreated that there seemed to be no coherence in the ETMy measurements.  We fumbled around for a while looking at no coherence with signals here and there and then invoked Kissel.  Sure'nuf, the ESD drive on ETMy wasn't driving in "LO" or "HI" voltage mode.  Richard headed to end Y and re-discovered that turning things off and reterminating the DAC cable fixed the problem - see alog 13335 "Lock up of the DAC channels".

The ETMy measurements are now in progress.  Again.

Meanwhile, we attempted to look at why the ETMx LL ESD drive wasn't working and confirmed what Keita saw last night - it doesn't work.  We see the requested drive in the monitor channels which means that the signal goes bad somewhere beyond the chassis (toward the chamber).  As usual, "no one has been down there" but we're not sure how we can use this ESD to lock the IFO with a dead channel.  Richard reports that he will go there tomorrow to investigate.

Observation Bit: Undisturbed 

08:00 – Take over from Nutsinee – IFO locked at LSC_FF 
08:07 Robert – Working at End-Y, but not in the VEA
08:29 - Adjust ISS Diffracted power from 11.1% -2.06v to 8.3% -2.09v
09:32 - Beam tube cleaning crew start work on X-Arm
09:55 Christina & Karen – Open/close rollup door to OBS receiving
10:00 Christina & Karen – Staging garb in the OSB cleaning area
11:52 – Beam cleaning crew stopping for lunch 
13:05 - Lockloss
13:10 IFO in down state for ETM charge testing
13:30 Richard – Going to End-X
13:31 – Beam tube cleaning crew start work on X-Arm
13:50 Gerardo – Going to Mid-Y to get a cable
14:12 Gerardo – Back from Mid-Y
14:25 Richard – Back from End-X
14:36 Richard – Going to End-Y to check cabling for ETM charge testing
15:25 Robert – Going to Beam tube near Mid-Y
15:46 – Beam tube cleaning crew finished for the day
16:00 – Hand over to Travis

Andy, Jess

Since the 79.2 MHz fixed frequency source was powered off alog, we have not seen any RF beatnote/whistles in DARM at Hanford. We see them in DARM at Livingston, however, but the mechanism is much more complicated than Hanford. The mechanism is not the PSL VCO beating against a fixed frequency.

Since we still see whistles at Hanford in auxiliary channels, we thought we'd revisit them, to see if that gives us clues for L1. We looked at the lock of Jun 11 starting at 6 UTC. We see whistles in PRCL, LSC-MCL, and sometimes in SRCL. Choosing two times, we find that the whistles correspond exactly to a beatnote of the PSL VCO frequency with a fixed frequency of 78.5 MHz (or something within a few hundred Hz of that). So it's the same simple mechanism as before, just against a different frequency.

Attached are plots of two times in PRCL where we predict the exact shape of the whistle, using IMC-F as a proxy for the PSL VCO frequency. SRCL and MCL are similar. We'll go back and check other locks to see if there's any evidence for other frequencies or shifts in the frequency.

I've taken a look at guardian state information from the last week, with the goal of getting an idea of what we can do to improve our duty cycle. The main messages is that we spent 63% of our time in the nominal low noise state, 13% in the down state, (mostly because the DOWN state was requested), and 8.7% of the week trying to lock DRMI. 

Details

I have not taken into account if the intent bit was set or not during this time, I'm only considering the guardian state.  These are based on 7 days of data, starting at 19:24:48 UTC on June3rd.  The first pie chart shows the percentage of the time during the week the guardian was in a certain state.  For legibility states that took up less than 1% of the week are unlabeled, some of the labels are slightly in the wrong position but you can figure out where they should be if you care. The first two charts show the percentage of the time during the week we were in a particular state, the second chart shows only the unlocked time. 

DOWN as the requested state

We were requesting DOWN for 12.13% of the week, or 20.4 hours.  Down could be the requested state because operators were doing initial alignment, we were in the middle of maintainece (4 hours ), or it was too windy for locking.  Although I haven't done any careful study, I would guess that most of this time was spent on inital alingment.

There are probably three ways to reduce the time spent on initial alignment:

• reducing the number of times that we do initial alignment.  We don't really know how often we need to be doing this, and we might be able to do some offloading in full lock before powering up and see if that gives us an alignment that is good for lock acquisition.
• There are a few improvements to the ALIGN_IFO guardian that might help a little. 
• Last, as the operators get more experience with the alignment procedure it should become faster.

Bounce and roll mode damping

We spent 5.3% of the week waiting in states between lock DRMI and LSC FF, when the state was already the requested state.  Most of this was after RF DARM, and is probably because people were trying to damp bounce and roll or waiting for them to damp.  A more careful study of how well we can tolerate these modes being rung up will tell us it is really necessary to wait, and better automation using the monitors can probably help us damp them more efficiently. 

Locking DRMI

we spent 8.7% of the week locking DRMI, 14.6 hours.  During this time we made 109 attempts to lock it, (10 of these ended in ALS locklosses), and the median time per lock attempt was 5.4 minutes.  From the histogram of time for DRMI locking attempts(3rd attachment), you can see that the mean locking time is increased by 6 attempts that took more than a half hour, presumably either because DRMI was not well aligned or because the wind was high. It is probably worth checking if these were really due to wind or something else.  This histogram includes unsuccessful as well as successful attempts.  

Probably the most effective way to reduce the time we spend locking DRMI would be to prevent locklosses later in the lock acquisition sequence, which we have had many of this week.

Locklosses

A more careful study of locklosses during ER7 needs to be done. The last plot attached here shows from which guardian state we lost lock, they are fairly well distributed throughout the lock acquisition process. The locklosses from states after DRMI has locked are more costly to us, while locklosses from the state "locking arms green" don't cost us much time and are expect as the optics swing after a lockloss. 

If you look at the Online EarthQuake Arrival Predictor, it shows the 5.7 mag EQ in Japan, along with many others.  This is just the largest in the last day or so.  I've overlayed the predicted arrival time of the Rayleigh waves on the STS2 ground seismometers and the BS stage2 inertial sensors--see attached.  Unfortunately the IFO was not in lock at the time.

Anyway, need a bigger EQ still to assess the prediction as the Ground sensors.  Just to be more thorough, I shifted and extended the plot a little and now include the predicted arrival times of the P & S waves, second attachment.  I got rid of the Z ground seismometer and added the transmitted arm power for a IFO indicator.  Did the arrival of the p wave ring up the BS ISI?  Ehh I don't think so given the ground seismo unless the prediction is off by ~90 seconds.  But I think the prediction could be off by that much given the complexity of travel paths and assumptions of the velocitys.  With this data set I'd say the ISI is being beat around by the locking attempts, not by this red earthquake.

Adjust the ISS diffracted power from 11.1% -2.06v to 8.3% -2.09v 

Cleared the HEPI L4C watchdog counter for ITMY. All others were green and clear.

Scott L. Ed P.
6/8/15
The following are some of the dirtiest area we have seen on the X-arm.
Cleaned 58 meters ending 8.4 meters north of HNW-4-068.

6/9/15
 Maintenance day which means we can use the Hilti HEPA vacuum, the most effective vacuum for cleaning out the support tubes. We have been holding off on using this vacuum during ER7 because of the loud thump emitted from the internal cleaning system of the hepa filter.
We will go back and clean 2 sets of support tubes and cap them, as well as move forward to clean as many supports as reasonable before the end of maintenance day at noon.
Cleaned 30 meters of tube ending at HNW-4-070. Test results posted on this A-log.
 
Robert Schofield came out to the area where we are cleaning to look at our procedure and methods of actual cleaning of the tube to investigate possible glitches seen by the control room operators during lock.

6/10/15
Remove lights, cords, vacuum machines, and all related equipment from enclosure and thoroughly clean all equipment, then relocate to next section north.
Started cleaning at HNW-4-070, cleaned 15 meters of tube.

To date we have cleaned a total of 3418 meters of tube. 

Since we got a few coincident burst hardware injections this morning, and the rest of ER7 (now through Sunday 8:00 PDT) will be split between local measurements/commissioning and running, I have disabled the scheduled burst hardware injections for the rest of ER7.  To be precise, I left the next few dozen in the schedule but I set their amplitudes to zero, in order to test the long-term behavior and stability of tinj; tinj will call awgstream to inject them, but because awgstream will just add zero strain to the instrument, these should have no effect and will not appear in ODC bits or database segments.

There is still a plan to add a stochastic injection sometime before ER7 ends, if time permits.

00:00 The ifo locked right before I came in. Wind speed is <20 mph. 90 mHz blend filter is used for BSC2.

           I noticed the BS oplev sum is saturated (> 80000 counts). Is this alright? It's been around this value for 10+ days.

01:55 There's a big bump at ~30 Hz that caused a big dip in the BNS range. SUS Oplev plots didn't show anything suspicious. The bump at this frequency happened through out the night, just not as big.

02:00 A 4.7 MAG earthquake in Ecuador shook PR3 a little and BNS range dropped slightly (from 61 Mpc to 60 Mpc), but that's all it did. No WD tripped. 

08:00 We've been locked for 8+ hours and still going strong at 61 Mpc! We had 5+ hours of coincidence with Livingston tonight. Handling the ifo to Jeff B.

Jim must have switched these.  The 90mHz blends are on for X & Y rather than the 45s.  The SDF is red for this reason.

model restarts logged for Wed 10/Jun/2015

no restarts reported

Dave Barker created a shared 'hinj' account for running hardware injections (alog 19057), and we restarted tinj (the transient injection process) under that account yesterday.  Unfortunately, the injections failed overnight due to awgstream errors.  That was puzzling because executing awgstream on the command line (with zero amplitude or extremely small amplitude) worked fine.  It turns out that different versions of the gds, awgstream and root packages are installed on the LHO injection machine compared to the LLO injection machine, so the environment setup that was copied over from LLO caused awgstream to fail when executed by tinj.  I made a separate environment setup script for LHO and restarted tinj under that, and now it seems to be working fine.

After doing a zero-amplitude test injection at 1118063333 (which should have had no effect on anything), I modified the schedule to more promptly do som burst injections (coincident at both sites), at GPS times 1118063933, 1118067123, and 1118067543.  (The actual signal comes a second or two later than those waveform file start times.  As of this writing, the first of those was picked up by the burst pipelines: see https://gracedb.ligo.org/events/view/G159516 .  We'll see about the others.

Related:

Den's alog 16624

Den's alog 16727

Summary:

Many things are dubious.

1. EX LL ESD is broken as the ESD to length response is 3 orders of magnitude smaller than the others. Probably shoddy connection somewhere between the driver and the ESD electrode, as the voltage readback looks normal.
2. It looks as if either the sign of EX ESD output is flipped (positive digital out induces negative voltage) or the sign of EY ESD output is flipped but not both.
3. I'm just assuming that the sign convention for CAL-CS_DARM_EXTERNAL_DQ is length(X)-length(Y), and that it's correct, without any confirmation.

Despite these things, it seems as if the charges on the back are on the same order as reported in Den's alog 16624.

If we assume that the sign of EY ESD is wrong and we still take 1. into account, the charges are calculated as:

This looks semi-reasonable.

If we assume that the sign of EX ESD is wrong and we still take 1. into account, the charges are:

I don't like that the signs are all over the place.

If we assume that everything is correct except that the EX LL is broken (i.e. we ignore the 2. above but take 1. into account), the charges based on are:

Again the signs are all over the place.

These are based on the same calculation as Den's alog 16624.

I'm assuming that the sign convention of CAL-CS_DARM_EXTERNAL_DQ is length(X)-length(Y) (i.e. positive when X stretches and Y shrinks).

Anyway, no matter how you look at the data, the back surface charges are quite similar to what was reported in Den's alog (except for the signs that don't make much sense for the latter two tables).

We tried similar measurements as described in Den's alog 16727 but the angle data for X was unusable (no coherence at all). If you're interested in Y data, all measurements were saved in Betsy's template directory.

The gist of the measurements:

• Lock the IFO in DC using EX ESD for EY injections (or using EY ESD for EX injections). Use a correct-ish CAL-CS configuration.
• Ring heater upper and lower sections were bundled together and connected to one of GDS DACs via SR560 while the drive ground was connected to the ESD ground.
• Set the EY ESD bias to zero for EY injections (or EX bias for EX injections).
• Inject 5 lines (each one corresponding to LL, LR, UL, UR and ring heater), all at around 80Hz, and measure the transfer coefficients from injections to CAL-CS_DARM_EXTERNAL_DQ and IR QPDs on the TMS. CAL_CS thing was dewhitened using the calibration in the dtt template used for the control room FOM.

Differences between EX and EY measurements:

• Low noise driver, no low pass for EY. This gives a DC gain of 2, and a pole at 152Hz from PI summing node. For EX, high voltage driver with DC gain of 40 and a pole at 2kHz.
• High power for EY injections. Low power (3W) for EX injections because we needed to disable EX ring heater and I was worried if the PI becomes the problem if the measurement takes too long.
• In EY a large DC analog offset was observed in all GDS testpoints. To block this, SR560 was set to AC coupling which should have zero effect at 80Hz. (Later it turned out that the offset was already in the digital, so probably it's a digital offset problem but that doesn't change the conclusion either.)
• No meaningful coherence for the QPDs in EX. Don't know why, maybe we really need high power.

Fishy sign of ESDs (Go to the floor and figure out):

EY ESD length drivealign matrix has a negative DC gain while the corresponding matrix for EX is positive even though the LSC DARM output matrix already takes care of the sign difference necessary for DARM control for EX and EY.

It looks as if either the bias line has a wrong sign for one ETM but not the other, or LL/LR/UL/UR lines have a wrong sign for one ETM but not the other.

Raw-ish data and calculations:

Measured the zero-bias transfer coefficients from ESD segments and the ring heater (top and bottom combined) to the calibrated DARM channel in meters/volts at around 80Hz. After taking the TF of the drivers and the DAC V/cts into account, they are:

Positive data is actually about 24 deg (Y arm) or 30 deg (X arm) delayed, while negative data is about 210 deg (X arm) delayed.

EX LL is not working. Coherence is very large, the voltage readback looks OK, but it has 3 orders of magnitude smaller response than the others. EX LL did not change much when the nominal EX ESD bias was put back on.

I multiplied the ESD combined data by 4/3 only for EX to take into account that the EX LL driver is not working.

Force to length transfer function at 80Hz is -1/M/(2*pi*80Hz)^2 = -1E-7[m/N] (negative as the phase is 180 degrees relative to DC).

Also, the above is the TF to DARM, which is supposed to be X length - Y length. In order to move to a sign convention where positive means that the ETM moves closer to ITM, the sign of the X data should be flipped.

Combining these, the above raw-ish data is converted to N/V as:

The signs of this table don't really make sense (positive ESD electrode potential should move ETMX and ETMY in the same direction if the charge has the same sign).

Anyway, from here, you solve Den's rough formula:

F_RH / V_RH = A_front Q_front + A_back Q_back

F_ESD / V_ESD = B_front Q_front + B_back Q_back

A_front = 1 / 0.20 [1/m] ; A_back = -1 / 0.04 [1/m] 

B_front = 1 / 0.20 [1/m] ; B_back = 1 / 0.04 [1/m]

~16:00 Locked IFO

~16:45 Winds pick up, lock loss

Many frustrating hours of lock losses at REFL_TRANS or there abouts

23:15 Lock IFO again.

Sudarshan, Kiwamu, Darkhan,

Abstract

According to the PCALY line at 540.7 Hz, the DARM cavity pole frequency dropped by roughly 7 Hz from the 17 W configuration to the 23 W (alog 18923). The frequency remained constant after the power increment to 23 W. This certainly impacts on the GDS and CAL-CS calibration by 2 % or so above 350 Hz.

Method

Today we've extracted CAL-DELTAL data from ER7 (June 3 - June 8) to track cavity pole frequency shift in this period. The portion of data that can be used are only then DARM had stable lock, so for our calculation we've used a filtered data taking only data at GPS_TIME when guardian flag was > 501.

From an FFT at a single frequency it is possible to obtain DARM gain and the cavity pole frequency from the phase of the DARM line at a particular frequency at which the drive phase is known or not changing. Since the phase of the resultant FFT does not depend on the optical gain but the cavity pole, looking at the phase essentially gives us information about the cavity pole (see for example alog 18436). However we do not know the phase offset due to time-delay and perhaps for some uncompensated filter. We've decided to focus on cavity pole frequency fluctuations (Delta f_p), rather than trying to find actual cavity pole. In our calculations we have assumed that the change in phase come entirely from cavity pole frequency fluctuations.

The phase of the DARM optical plant can be written as

phi = arctan(- f / f_p),

where          f is the Pcal line frequency;

                     f_p - the cavity pole frequency.

Since this equation does not include any dependence on optical gain, the technique we use, according to our knowledge, the measured value of phi does not get disturbed by the change of the optical gain. Introducing a first order perturbation in f_p, one can linearize the above equation to the following:

               f_p^2 + f^2
(Delta f_p) = ------------- (Delta phi)
                    f

An advantage of using this linearized form is that we don't have to do an absolute calibation of the cavity pole frequency since it focues on fluctuations rather than the absolute values.

Results

Using f_p = 355 Hz, the frequency of the cavity pole measured at the particular time (see alog 18420), and f = 540.7 Hz (Pcal EY line freq.), we can write Delta f_p as

Delta f_p = 773.78 * (Delta phi)

Delta f_p trend based on ER7 data is given in the attached plot: "Delta phi" (in degrees) in the upper subplot and "Delta f_p" (in Hz) in the lower subplot.

Judging by overall trend in Delta f_p we can say that the cavity pole frequency dropped to about 7 Hz after June 6, 3:00 UTC, this correspond to a time when PSL power was changed from 17 W to 23 W (see lho alog 18923, [WP] 5252)

Delta phi also show fast fluctuations of about +/-3 degrees, and right now we do not know the reason that causes this "fuzzyness" of the measured phase.

Filtered channel data was saved into:

aligocalibration/trunk/Runs/ER7/H1/Measurements/PCAL_TRENDS/H1-calib_1117324816-1117670416_501above.txt (@ r737)

Scripts and results were saved into:

aligocalibration/trunk/Runs/ER7/H1/Scripts/PCAL_TRENDS (@ r736)

Posted are data for the two long term storage dry boxes (DB1 & DB4) in use in the VPW. Measurement data looks good, with no issues or problems being noted. I will collect the data from the desiccant cabinet in the LVEA during the next maintenance window.   

After a measurement of charge on each ETM yesterday, I took a few more on each today.  Attached show the results trended with the measurements taken in April and Jan of this year.  There appears to be more charge on the ETMs than in previous measurements, although there is quite a spread in the measurements.  The ion pumps at the end stations are valved in.