Nutsinee K. & Thomas Abbott

Since no one has re-calibrated the calculated power and calculated angle of the CO2 rotation stages after their performances improved so we played a little calibration game tonight. The results are attached below. Figure 1 shows the measured power vs. calculated CO2 power before and after re-calibration. Figure 2-5 show fits and improvement of calcualted vs measured power before and after the re-calibration (CO2Y power RMS improved from 0.14 to 0.08, CO2X power RMS improved from 0.88 to 0.13). Figure 6-7 show details of the fit parameters and Figure 8-9 shows the current calibration. The differences between measured power and calculated power should now agree within 0.1 W or less. Although I noticed the minimum power and the corresponding angle of CO2X can change slightly after "search for home" so if the calculated power and measured power doesn't agree within .1 this could be the reason and you would have to re-enter min angle and min power (Hint. not 0 for CO2X.).

Details:

I left "Power in" variable alone since I'm not sure where the number came from (I assume this is the power going to the ITMs). Instead I changed parameter A and D according to my fits. Parameter B and C (min angle and min power) came from observations (CO2X min power never goes to 0). I wrote down the minimum power I could get to and wrote down the corresponding angle and throw them in the calibration.

Conclusion: The calculated power and measured power should agree within 0.1 W. Whether you request an angle to go to a certain power or request wanted power directly the result is the same.

I also have screenshots of the old calibrations if anyone ever needed them.

I set up a simple prototype system to monitor the beam tube between the corner station and mid-Y for impulsive events, like stick-slip events, that might generate beam tube particulate glitches in DARM. The idea is to monitor this for a few months and, if we see events, propose a full deployment. If we don’t see events, we may move the prototype system on to another of the 4 sections of beam tube.

I originally used a microphone in the beam tube enclosure because there were many bellows that would attenuate the signal travelling on the tube. But the air signal also moves the beam tube locally, which, because it is similar to the beam tube at the impact location, likely resonates at the same frequencies that the impact excited, so I tried an accelerometer on the beam tube. This turned out to be about a factor of 2 better than the microphone at detecting distant taps when focused on a beam tube resonance at about 200 Hz. With this system I could detect light taps 2km away. My standard tap is made by holding a plastic and metal scissors 6 inches above the beam tube, then letting the scissors rotate freely around a finger so that the tip of the scissors hit the beam tube (see Figure 1). A standard tap in the control room elicited no reactions and is not as loud as dropping a scissors from the same 6 inch height. This standard tap is somewhat softer than the taps that generated DARM glitches; if it can generate glitches, it does so only rarely. At 2km this tap is just visible so I think that we are in good shape to detect anything that has a high probability of generating a glitch over the entire 2km stretch. The signal from the taps travelled at an average of just under 400 m/s.

The prototype system also includes a microphone set up just outside of the beam tube enclosure. This microphone is used to discriminate local from distant events. For example, the LN2 dewar stick-slip events that can often be heard would produce small beam tube motions, as would passing cars; these motions might, without the microphone, be confused for distant large impulsive events.

Figure 2 shows the signals from standard taps at various distances, as well as rattling the beam tube enclosure door nearest the accelerometer (happens during high wind) and impacts on the large LN2 dewar. The door and dewar signals were easy to differentiate from the BT taps because large microphone signals were present.

~4:30 (local) Peter and Jason came out. Water leak issue. No PSL = No commissioning today.

2:58 At this point everybody has gone home. I'll end my log here but will be around for a little longer.

Few notes:

HVE-LY:CP1_LT100 alarm went off due to an overflow. This is a known issue and it should correct itself.

The photo shows the new buried seismometer set up at X-end.  Figure 1 shows the signal compared to the building STS. Note that the coherence between the Y-axes is quite low even at 1 MPH. This axis also had low coherence when I huddled it with the PEM seismometer so it is likely noisy. Hugh and I noted that the Y-axis did not seem to go through the centering process when commanded like the other axes. The new Trillium should solve this.

That being said, the important axis is the X-axis. Note that the windy signal from the buried seismometer is, just below 0.1 Hz, at about the same low level as the GND STS.  I doubt that the ground seismometer would help much at this location.  It may be necessary to move it into the depression that the building sits in to make it better than the GND STS. We chose this location for a seismometer to monitor the prototype wind fence, hoping that it would also have less tilt than the building seismometer.  But it looks like we will need a second hole if we are going to use a buried seismometer in a super sensor at EX.

Figure 2 shows data for the EY seismometers for wind speeds averaging 32 MPH. The buried seismometer is at least a factor of two better than the building seismometer along the beam axis, as it was during the several other storms I studied. While we hope that we don’t need to use the buried seismometer at EY because the new EY BRS does even better, I think it is still worth testing it in a super sensor because a buried seismometer may be useful at the corner station or at LLO.

J. Oberling, P. King

Spent the day chasing water leaks.  We started by swapping the flow sensor for the Laser Head 1 water circuit (this is the one we think caused the laser shutdown on Saturday).  We brought the laser up and left it on over lunch to warm up.  When we got back in we noticed that one of the connections for the recently replaced flow sensor had begun leaking over lunch.  We shut everything down, drained the water circuit, and replaced the teflon tape for the connection.  Upon starting the chillers, the other connection for this flow sensor started leaking.  Shut everything down, drained the water circuit, and this time swapped the flow sensor entirely (We are now out of spare flow sensors.  Luckily Peter has some new ones on order, should arrive later this week.).  We started the chillers again and saw no leaks in the 10'ish minutes we observed the system running.  In the interest of protecting the laser we are leaving it shut down over night with the chillers running.  Maybe this is an abundance of caution, but we'd rather take it slow and be sure than assume it's all OK and end up really causing a problem.  We will assess whether or not we still have a water leak in the morning.

The brief time that we did have the laser up today (right before lunch), we did attempt to injection lock it.  For some reason, the injection locking was very unstable; over the course of ~20 minutes we had roughly 20 relocks.  This is a big change that we can't yet explain; previous to this the injection locking has been robust.  Add this to the list of control loops that aren't working quite right.  Will investigate this first thing tomorrow, provided we don't have another water leak to fix.

model restarts logged for Sun 17/Apr/2016 DAQ fw instability reduced, fw0 only
2016_04_17 14:37 h1fw0

model restarts logged for Sat 16/Apr/2016 DAQ fw instability reduced, fw0 only
2016_04_16 04:34 h1fw0
2016_04_16 05:05 h1fw0

model restarts logged for Fri 15/Apr/2016 DAQ fw's unstable
2016_04_15 04:39 h1fw0
2016_04_15 06:43 h1fw0
2016_04_15 08:26 h1fw1
2016_04_15 08:59 h1fw1
2016_04_15 09:07 h1fw1
2016_04_15 11:13 h1fw1
2016_04_15 11:20 h1fw1
2016_04_15 13:05 h1fw0
2016_04_15 14:31 h1fw0
2016_04_15 16:16 h1fw0
2016_04_15 17:55 h1fw0
2016_04_15 19:42 h1fw0

model restarts logged for Thu 14/Apr/2016 DAQ fw's unstable. PEM fix broken channel.
2016_04_14 00:17 h1fw0
2016_04_14 01:03 h1fw0
2016_04_14 01:55 h1fw0
2016_04_14 02:13 h1fw0
2016_04_14 04:27 h1fw0
2016_04_14 05:14 h1fw0
2016_04_14 05:24 h1fw0
2016_04_14 08:14 h1fw0
2016_04_14 09:30 h1fw0
2016_04_14 10:45 h1dc0
2016_04_14 10:45 h1pemcs
2016_04_14 10:47 h1broadcast0
2016_04_14 10:47 h1fw0
2016_04_14 10:47 h1fw1
2016_04_14 10:47 h1nds0
2016_04_14 10:47 h1nds1
2016_04_14 10:47 h1tw1
2016_04_14 10:53 h1fw1
2016_04_14 11:29 h1fw0
2016_04_14 11:43 h1fw0
2016_04_14 14:33 h1dc0
2016_04_14 14:33 h1pemcs
2016_04_14 14:35 h1broadcast0
2016_04_14 14:35 h1fw0
2016_04_14 14:35 h1fw1
2016_04_14 14:35 h1nds0
2016_04_14 14:35 h1nds1
2016_04_14 14:35 h1tw1
2016_04_14 14:38 h1fw1
2016_04_14 15:04 h1fw1
2016_04_14 15:43 h1fw1
2016_04_14 16:05 h1fw1
2016_04_14 16:10 h1fw1
2016_04_14 16:29 h1fw0
2016_04_14 16:40 h1fw0
2016_04_14 17:54 h1fw0
2016_04_14 18:04 h1fw0
2016_04_14 18:36 h1fw0
2016_04_14 18:54 h1fw0
2016_04_14 20:02 h1fw0
2016_04_14 21:06 h1fw0
2016_04_14 22:19 h1fw1

model restarts logged for Wed 13/Apr/2016 DAQ fw's unstable. PEM change channel rate. ASC model change.
2016_04_13 10:30 h1fw1
2016_04_13 10:35 h1fw1
2016_04_13 12:07 h1broadcast0
2016_04_13 12:07 h1dc0
2016_04_13 12:07 h1fw1
2016_04_13 12:07 h1nds0
2016_04_13 12:07 h1nds1
2016_04_13 12:07 h1tw1
2016_04_13 12:37 h1fw1
2016_04_13 16:04 h1fw1
2016_04_13 16:05 h1fw1
2016_04_13 16:07 h1susetmxpi
2016_04_13 16:11 h1fw1
2016_04_13 16:26 h1pemcs
2016_04_13 16:31 h1broadcast0
2016_04_13 16:31 h1dc0
2016_04_13 16:31 h1fw1
2016_04_13 16:31 h1nds0
2016_04_13 16:31 h1nds1
2016_04_13 16:31 h1tw1
2016_04_13 17:56 h1fw0
2016_04_13 18:05 h1fw0
2016_04_13 18:07 h1broadcast0
2016_04_13 18:07 h1dc0
2016_04_13 18:07 h1fw1
2016_04_13 18:07 h1nds0
2016_04_13 18:07 h1nds1
2016_04_13 18:07 h1tw1
2016_04_13 18:09 h1asc
2016_04_13 18:12 h1fw1
2016_04_13 18:17 h1dc0
2016_04_13 18:18 h1broadcast0
2016_04_13 18:18 h1fw0
2016_04_13 18:18 h1fw1
2016_04_13 18:18 h1nds0
2016_04_13 18:18 h1nds1
2016_04_13 18:18 h1tw1
2016_04_13 18:23 h1fw1
2016_04_13 19:45 h1fw0
2016_04_13 20:09 h1fw0
2016_04_13 22:55 h1fw0
2016_04_13 23:42 h1fw0

model restarts logged for Tue 12/Apr/2016 Maintenance day, PI and LSC model change. EX vacuum Beckhoff install, LDAS move of h1fw0's raids from LSB to warehouse. Both fw's unstable
2016_04_12 11:33 h1susetmxpi
2016_04_12 12:33 h1lsc
2016_04_12 12:35 h1broadcast0
2016_04_12 12:35 h1dc0
2016_04_12 12:35 h1fw0
2016_04_12 12:35 h1nds0
2016_04_12 12:35 h1nds1
2016_04_12 12:35 h1tw1
2016_04_12 12:37 h1fw1
2016_04_12 12:42 h1fw1
2016_04_12 13:10 h1fw1
2016_04_12 13:14 h1fw1
2016_04_12 13:53 h1fw1
2016_04_12 14:01 h1fw1
2016_04_12 17:39 h1broadcast0
2016_04_12 17:39 h1dc0
2016_04_12 17:39 h1fw0
2016_04_12 17:39 h1nds0
2016_04_12 17:39 h1nds1
2016_04_12 17:39 h1tw1
2016_04_12 17:40 h1fw1
2016_04_12 17:43 h1fw1
2016_04_12 17:50 h1fw0
2016_04_12 17:59 h1fw0
2016_04_12 18:04 h1fw0
2016_04_12 18:06 h1fw1
2016_04_12 18:11 h1broadcast0
2016_04_12 18:11 h1dc0
2016_04_12 18:11 h1fw0
2016_04_12 18:11 h1nds0
2016_04_12 18:11 h1nds1
2016_04_12 18:11 h1tw1
2016_04_12 18:14 h1fw1
2016_04_12 18:52 h1fw0

model restarts logged for Mon 11/Apr/2016 - model restarts logged for Sun 10/Apr/2016 No restarts reported

CO2Y is lasing at 0.1 W, and CO2X is lasing at 0.35 W.

3:15pm local time

Took 1:07 min. to overfill CP3 - half turn open on LLCV bypass valve with bypass exhaust valve open. 

Next fill due within 72 hours (by Thursday) before 4pm local.

Turbo controller left energized until tomorrow. 

First plot shows the last IMC locks before the PSL work started, and the alignment of the IMs.

Second plot shows the our first IMC lock since PSL work started, and the change in the IMs alignment (IM2 pitch, the worst offender).

TJ kindly agreed to restore the pre-PSL work alignment of the IMs, and since we don't have light, we'll need to check IM4 Trans QPD with the next IMC lock.

Ross, Tega, Terra, Ed Daw 

We have updated the h1susetmxpi model to include a linetracking filter (iwave) in order to more accurately track parametric instabilities. The filter is placed between the bandpass and damping filters in each PI mode. The basic idea of iwave is that it is a resonant filter that runs with a phase lock loop. The loop tracks changes in frequency and amplitude of the signal that it is closest to in frequency and adjusts the filter to resonate at the tracked frequency. Two parameters should be set before the line tracker is implemented, the starting frequency and tau. The starting frequency should be set to the closest known line frequency of the signal you want to track. The tau parameter sets the response time of the filter but also the bandwidth. For higher Q signals it is best to use a longer tau parameter. We have also included a phase offset to the model for the linetracker which can be tuned to ensure the ESD is damping the PI with the correct phase. The medm screens mentioned in Terra's alog have been updated to include this filter.

The SUS_CUST_PI_MODE screen should now have a link to the top screen for iwave where tau can be changed and displays a strip chart of the error signal (black), input signal (blue) and frequency tracking (red). The error signal can be used to determine how well the signal is being tracked i.e. it should get smaller as the signal is being more accurately tracked. This screen also has a link to the actual iwave filter screen where the starting frequency can be changed and output monitors including ones for frequncy and amplitude are displayed. The reset button in the filter can be used to reinitialise the filter with the selected tau and starting frequency. A bypass switch is included to allow data to be unchanged when passing through the filter if necessary. We have also updated the mode screen so that the QPD monitors are now looking at epics outputs in the h1etmxpi model rather than the filtered outputs.

We will hopefully begin testing this method of damping in comparison to just using the bandpass filters soon. This will be done by turning off the ring heater, waiting for the signal to ring up and then applying the damping signal to the ESD. We will need a 15W or higher laser power in order to ring up the 15440 Hz mode which has been seen previously.

Kyle, Chandra

Verified HAM6 IP was operating and then valved it back into HAM6 chamber at 9e-7 Torr this morning. Immediately valved out turbo pump and will monitor IP and pressure throughout the day to make sure load is not too high for IP supply. Turbo is still ON and ready to be valved back in if need be.

SEI - Fiddling with the BRS

SUS - All good

PSL - Water flow sensor issue over the weekend. Should be back after the sensor is replaced. ISS investigation.

Vac - Ready to turn on the ion pump. Change the actuator on CP-1. Mid station Beckhoff switch maybe as soon as today.

Fac = Beam tube enclosure sealing on both arms.

There will be no internet from 9-11 NEXT Tuesday. (WP5831)

TITLE: 04/18 Day Shift: 15:00-23:00 UTC (08:00-16:00 PST), all times posted in UTC
STATE of H1: Planned Engineering
OUTGOING OPERATOR: None
CURRENT ENVIRONMENT:
    Wind: 4mph Gusts, 2mph 5min avg
    Primary useism: 0.03 μm/s
    Secondary useism: 0.25 μm/s
QUICK SUMMARY: The PSL had some issues over the weekend so it seems like that will be worked on today. Many SEI WDs are tripped and a few SUSs.

 

Attached are plots of the pre-modecleaner, power stabilisation and frequency stabilisation servo
transfer functions as they were on Friday.

    I'm not sure what the dip at ~23kHz in the frequency stabilisation plot is but it might be
due to injection locking of the high power oscillator.

    The power stabilisation servo needs adjusting.  At the moment the displayed diffraction
levels are too high - it needs to be recalibrated.

    The pre-modecleaner servo is functional but also needs checking out.  Even with attenuating
the light on the locking photodiode, its output bursts into oscillation every now and then which
causes the pre-modecleaner to "blink".

I got some alignment work done, but not as much as I would have liked.

I had just finished aligning the Xarm to green, although it's flashing and not locking.  Flashes up to 0.8, so it seems fine, but the PLL is complaining about not enough beatnote signal.  I don't actually know where that PD is, so I can't check it's alignment. 

The IR flashes also looked good, so I was getting ready to misalign the ITMY, use BS to get the beam onto AS_C, and then work on aligning ISCT6.  However, the PSL decided that it had had enough, and decided to turn off.  So.  I'll come back to this Monday after the laser crew is done with their activities for the day.

Side note:  The Yarm green is complaining about beckhoff communications errors, if someone more knowledgeable than me could have a look at that Monday as well.

The PSL has turned itself off. 

I spoke with Jason, and it looks like perhaps the chiller decided to turn off, which triggered the laser interlock to shut off the PSL.  The crystal chiller reservoir looked fine, although there was water on the floor and a cap had popped off (apparently this happens as part of the chiller turn-off?). 

The H1:PSL-OSC_BOXHUM channel has been exponentially increasing over the last ~20 hours from 28 to 35, which is consistent with the air conditioners being turned off around that time. Jason tells me that when the AC isn't drying things out, the box humidity usually sits in the 35-45 range, so since it's just now getting to 35, it seems like there is NOT a water leak. 

Jason logged in remotely, and agrees that things should be safe to leave as-is until he and Peter come in on Monday morning. 

Attached is a plot of the power measured at the base of the IO periscope as a function
of the requested angle in the MEDM screen.

    The following angles may be of interest:
minimum power -25 degrees
maximum power  -70 degrees and 20 degrees

    Measurements were performed with the Ophir power meter, using 3 second averages.

    The requested angle was consistent with the scale etched on the rotation stage.
To check that the half waveplate was not slipping within its mount, angular requests
moving the waveplate from one end to the other were made and the power measurements
were consistent with previous measured values.  So there was no experimental evidence
of the waveplate slipping within its mount.




Jason, Peter