- commissioning / testing long locks all shift

- alginment investigation ongoing

--- good test to run today: with IMC locked, change IM(1-3) by some small amount, look for the change on IM4 Trans, alog results

- EY is dusty!

Some random commissioning tasks from tonight:

LSC rephasing

In full lock, the phases of POP9 and POP45 were adjusted to minimize the appearance of PRCL in POP9Q and the appearance of SRCL in POP45Q. Then the input matrix element for POP9I→SRCL was tuned to minimize the appearance of a PRCL excitation in the SRCL error signal. New settings attached.

We should take a sensing matrix measurement sometime soon.

LSC OLTFs

I took OLTFs of PRCL, MICH, and SRCL. The data are attached.

[I also did some noise injections into CARM for frequency budgeting purposes. Those are attached too.]

Front-end LSC triggering

Jamie and I started this a few weeks ago, and now it is completed.

There are occasions when the DOWN state of the ISC_LOCK guardian (which, among other things, turns off feedback to the suspensions) is not run immediately after a lockloss (e.g., because the guardian is paused or in manual mode). Therefore, Jamie and I set up the LSC trigger matrix so that PRCL, MICH, SRCL, DARM, and MCL are turned off if POP DC goes below 100 normalized counts. This is set in the DRMI_ON_POP state.

CARM gain redistribution in the Guardian

The state REFL_IN_VACUO now redistributes the CARM gain slightly in order to improve the noise performance of the CARM loop. This state has not been tested and has been left commented out.

Dan, Cheryl, Evan

Sometime after 6 am local yesterday, we lost the ability to have stable locks with full input power.

It's not clear what about the interferometer changed, but the symptom again seems to be a slow drift of the AS36→SRM yaw loop which causes a sudden lockloss after a few minutes at full power.

In the end we simply retuned the input matrix elements for this loop in order to keep AS90 and POP90 from drifting downward at high power.

Before, the matrix elements were

ASA36I→SRC1: −3

ASB36I→SRC1: +1,

and now they are

ASA36I→SRC1: −3

ASB36I→SRC1: +0.5.

This combination was not chosen particularly carefully, but it is good enough to get to high power. We may want to see if there is a better combination.

The attachment shows the behavior of the four AS36 signals during power up and the subsequent full-power lock.

10 day plot of dust at EY - do we know why EY is so dusty?

Annoying dust alarm at EY silenced with alarm level changes:

- old: 2000 (yellow, dashed line), 3000 (red dahsed line), note that EY routinely goes above these alarm levels

- new (not saved but running tonight): 5000 (yellow solid line), 10000 (red solid line)

Jenne, Sheila, Terra, Cheryl, Corey

Tonight we worked on some ASC (the wind was gusting to 30mph when we started this, the IFO locked just fine but the buildups were fluctating at low frequencies).  At first we wanted to check on CHARD.  We increased the gain for CHARD P by 6dB, and then were able to add a gentle boost (the same MSboost used in DHARD) to increase the gain at low frequencies.  The attched screenshot and template were measured at 3Watts, with the new configuration (which is in guardian) and the ITM oplevs on.  For an old measurement taken at 23 Watts see Evan's alog 19934

Jenne did a similar job for yaw, adding the same gentle boost, and including the 20dB in the guardian. Both the pitch and Yaw loops could have ugfs below 1 Hz as the power increases, but they should be stable.

Once we increased the power to 24 Watts, we found we weren't stable for more than 5 minutes.  This happened both before and after the CHARD changes.  We ran Hang's lockloss script which picked MICH ASC loops as a suspicous channel.  We locked at 15 Watts were we seemed to be indefintely stable, and measured both MICH loops.  They look fine, I'm just attaching them here so we have the templates. 

Travis, Sudarshan

We calibrated the EndY photon calibrator today. We have started reporting the final calibration factors in Newtons/Volt of PD  readout as per our new calibration scheme detailed in alog # 20334. The new calibration factors compared to the the last calibration is tabulated below and is also uploaded to T1500252.

A detail comparison that includes physical parameters, intermediate ratios, optical efficiency  is attached.

• Started off the shift watching TJ working on bringing back up H1 post-Maintenance.
• Have made several attempts to get H1 locking (although it was dropping out at various points.)
• Given walk-thru of Lockloss templates by Jenne & also Hung's Lockloss tool
• Commissioners team have continued working on getting H1 back up.

Locates at SITEMAP > SUS > VIOLINS. This monitor simply turns the log RMS output of the violin monitor into a bar chart. One bar chart monitors two frequencies due to the lack of filter bank space (only those that have known to cause trouble get its own narrow BP filter). Low value is 0 and high is 4. The green marks indicate the violin (RMS) amplitudes after 10 minutes of a lock stretch. Healty violin modes shouldn't go pass the green marks and some should get better as time passes. More fine-tuning can be done but it's good for now. I will put in the first harmonics once we know more about them.

Roughly from last night (5:00UTC [10pmPT]), EY has been steadily increasing in dust levels (and obviously alarming constantly the whole time).  0.3um counts are over 10,000.  No other VEAs are seeing an increase in dust like this building.  I don't see a temperature increase.  Could a door be open?  HVAC issue?  Something burning? 

(Will send an email to Bubba, Jeff B, John)

V. Sandberg & R. McCarthy

The SUS-TMSX OSEM Satellite Box was driving a ~2kHz oscillation on its DC power line again. (See https://alog.ligo-wa.caltech.edu/aLOG/index.php?callRep=20428) This time we replaced the satellite box.  Verified that H1:SUS-TMSX_M1_OSEMINF_RT_IN1 and H1:SUS-TMSX_M1_OSEMINF_SD_IN1 were behaving themselves.  Work was done during the interval 18:00 - 18:45 UTC (11:00am - 11:45am PDT).

Apologie: I failed to follow my own rules and neglected to notify the operator on duty before we left and changed out the satellite box at End X.  Shame and humiliation duly noted.  :-(  Fortunately, no damage was done.

h1susex re-install original computer WP5430

Dave, Carlos, Jim:

The original h1susex front end computer was re-installed at EX to fix the glitching seen with the newer faster computers. The script which was clearing the EX glitch errors has been stopped, any FEC errors will now latch on until cleared by the operator.

h1tcscs model change WP5422

Duncan, Nutsinee, Dave:

The new L1 TCS model was installed on h1tcscs. A new TCS_MASTER.mdl was used. The h1tcscs.mdl file was modified to: add the ez_ca_read parts to get TCS CO2 and Ring Heater channels from the Beckhoff computers (corner and end stations) into the model; add new inputs to the CO2 parts for RH input; add ODC output from the CO2 parts; add new ODC block; add SHMEM ODC sender (to be injested by h1odcmaster model).

I discovered that there is a naming mis-match in the Beckhoff Ring Heater channels in the corner station slow controls system. There is no mismatch in the end station Beckhoff systems. I modified h1tcscs use use the H1 names.

Conlog channel reconfiguration

Dave:

After the TCS, CAL and ASC model changes I rescanned the channel lists for Conlog. It still showed a disconnection for the Guardian LSC_CONFIG node, which I tracked down to a very out-of-date autoBurt.req file for h1guardian0 target. I updated the autoBurt.req file and reconfigured Conlog, it is now happy.

H1LSCAUX filter coeff load

Dave:

The h1lscaux model was reporting a modified filter file. I took a look and could not see any difference between the current file and the archived file. I pushed the coeff-load button to clear this.

DAQ Restart

Dave:

After the TCS, CAL and ASC model changes, the DAQ was restarted. There were no GDS frame broadcaster changes made today (ECR is pending).

I looked into the glitches created by Robert's dust injections. In brief: some of the glitches, but not all of them, look very similar to the loud glitches we are hunting down

Here is the procedure:

1. select all drops of the range in the two hours of injection
2. for each one, load three minutes of data, compute the 30-300 Hz BLRMS and find the glitch tims as the maximum of the BLRMS peaks

In this way I could detect a total of 42 glitches. The last plot shows the time of each glitch (circles) compared with the time of Robert's taps (horizontal lines). They match quite well, so we can confidently conclude that all the 41 glitches are due to dust. The times of my detected glitches are reported in the attached text file, together with a rough classification (see below)

I then looked at all the glitches, one by one, to classify them based on the shape. My goal was to see if they are similar to the glitches we've been hunting.

A few of them (4) are not clear (class 0), some others (14) are somehow slower than what we are looking for (class 3). Seven of them have a shape very close to the loud glitches we are looking for (class 1), and 16 more are less obvious but they could still be of the same kind, just larger (class 2).

See the attached plots for some examples of classes.

Evan's script to automatically take frequency and intensity transfer functions is now running. 

As a reminder, the summing note B path was repurposed for this run. The interferometer won't relock unless we reconnect them. 

At 4:20 UTC we started changing the TCS X CO2 power from 0.23W to 0.4W. The rotation stage took us on some full circles, but by 04:23 we reached 0.4W. 

At 4:45 I increased the frequency noise drive by a factor of 5 to gain back coherence.

At 6:04 I decreased the power to 0.35W - trying to find the minimal frequency noise point. (The coupling sign had changed.)

At 6:34 I reduced it to 0.3W.

• SR3 20 Hz elliptic LPF (for M2 oplev coupling) was replaced with a more gentle 8 Hz LPF with slightly less attenuation in the stopband, but more attenuation around 20 Hz. [Attachment.] This was done without knowledge of the SR3 oplev OLTF, so it is possible we can design a more aggressive filter.
• dHard pitch gain is turned up by a factor of 2 (to 20 ct/ct), since it seems like it is able to kill that abominable 1 Hz pitch oscillation.
• cHard pitch gain turned down by 20 dB (by turning on FM1), and a 9 Hz LPF is engaged to kill angular control noise that can be seen in DARM between 10 and 20 Hz.