UPDATE: PSL AC, oscillating temperature

• Not yet back to stable running, so too the pointing of the beam.
• Peter mentioned having trouble with getting settings to stick on Tuesday.
• One attachment, two plots: 5 hours 4 days ago, 5 hours tonight

IO work, 9 Nov

• beam is aligned to PR2
• REFL beam is aligned going into HAM1
• PRM sliders are at pitch = -150, yaw = 100, so close to the 0,0 alignment
• at the meeting I saw that the PSL temperature was high
• this is now being corrected
• not sure when the PSL temperature / PSL beam will stabilize
• IO work to continue after
• some mechanical relief of IM alignment drives will be needed
• aux. QPD signals still to align

- Cheryl, Jeff, Ed

BSC1, 2, 3 baffle and alignment work

Yesterday, we installed the ITMY elliptical baffle to see how it looked wrt the ITMY-SR3 IFO AUX simulation beam.  Unfortunately, after suspending it and tweaking the few top weights to try to center up the EQ stops as best as possible, the baffle target showed it was misaligned by 1cm from the beam.  Between this and the mystery miscentering on the BS elliptical baffle, we decided to move away from this arm of alignment work, and move on to see what other surprises turn up in the ITMX to PR3 simulated beam alignment path.  (Will consult with baffle docs and experts to review aligning the elliptical baffles if needed after we see corroborating stories between the AUX beam and the PSL beam heading our way soon.)  We:

- moved the AUX laser setup from the ITMY chamber to the ITMX chamber

- installed and carefully aligned the centering target on the ITMX

- removed the new baffle panel from the PR3 sus frame

- installed and carefully aligned the centering target on PR3

- installed the ITMX elliptical baffle

- removed the temp laser barrier between HAM3 and BSC2

Note, we did not suspend the ell baffle since we need to finish putting the balance weights on.

...to be continued.

Betsy, Travis, Jason, Jenne, TJ

OFI Optics Table

Table is ready to be removed from its cage, all earthquake stops were removed, earthquake stop plates, and suspension wires set aside.

Tomorrow the OFI table can be removed and moved to the optics lab for testing.

PSL Enclosure Make-up Air Found OFF

During today's 1pm PST meeting it was noticed that the PSL enclosure temperature had increased to over 80 °F, and had been increasing for ~18 hours.  After the meeting (~1:30pm PST) I went out and checked the status of the environmental controls and found the HEPA fans, AC, and make-up air all OFF.  The proper setting for science mode (which the PSL was supposed to be in for the ongoing IO alignments, see alog here) is HEPA fans and AC OFF, make-up air ON at 20% fan speed.  I restored the PSL environmental controls to the proper setting and the enclosure temperature should start slowly coming back down.  Something happened yesterday evening to turn off the make-up air entirely, at this point we are not sure what.

When I went into the enclosure on Tuesday, I also noticed that the "default" speed of the
ante-room and laser room HEPA fans was set at 20% (it should always be 100%).  I changed
it from 20% to 100%, waited a few seconds (~10), scrolled back through the menu to find
that the speed was set back to 20% again.  I had to repeat this two or three times to get
the default value to stick.

    I had left the make up air at 20%, the science mode speed.  By comparison with the
HEPA fan speed settings, the make up air setting seemed well behaved.  I left the air
conditioning off, without toggling the circuit breaker.

Running mechanical pumps near GV5 overnight

Ops Day Shift Summary

Move OneStopPCIe card on h1susey, glitch mitigation investigation

WP7213 Dave:

Gerrit discovered that the fast computer glitching is possibly related to the location of the OneStop card on the pci bus. All four of the LHO fast computers have the X9SRL motherboard from Supermicro. On this board, the first PCIe slot (slot 1) is connected to the PCH (Platform Controller Hub) while slots 2-7 are directly connected to the CPU. Several of the 2-7 slots share a bus, while slot 5 has its own bus.

I confirmed that the PCIe card layout on h1susey and h1susey were identical (slot order is as seen from the rear of the computer).

slot id	7	6	5	4	3	2	1
card	empty	empty	empty	VMIC-5565	Dolphin	OneStop	IRIG-B

In this layout, the OneStop card (slot 2) shares a bus with slot 3 (Dolphin) and slot 7 (empty).

To test if the ADC/TIM glitch rate could be reduced with a card reconfiguration, on h1susey I have moved the OneStop card from slot-2 to slot-5 so it has its own bus.

Before powering down h1susey Jeff started the SWWD bypass on h1iopseiey. Unfortunately, even though I completed the hardware change in the prescribed 20 minutes, the power cycle of h1susey caused a Dolphin glitch on power up, so this was for nought. All models on h1seiey and h1iscey were subsequently restarted.

H1 ISI HAM4 Locked

J. Kissel

Since Jim has cleared a cursory look at H1 HAM4 ISI transfer functions (LHO aLOG 39340), I've relocked the table in prep for up-coming full IFO alignment activities up-and-coming in the next week. #crossfingers #touchwood

fast shutter triggering

I started to look at times when the fast shutter fired to check if there are times when more energy passed the shutter than desired (in part because of the broken beam dump in HAM6).  I wrote a script that looked at about 40 days of minute trend of the AS WFS (which are behind the shutter) and picked out times when they were high.  Attached are plots of the three events where the most energy seems to be getting past the shutter in those 40 days.  In all of these three cases, the power on the AS_C PD doesn't seem to have exceeded the threshold for the shutter to fire until there had already been several seconds of large power fluctuations at the AS port.  The shutter triggers as expected when the power goes over the threshold.

• Beckhoff channels are reporting events happening about 0.1 seconds before the front end (39329) For this reason I've shifted the time of all the channels labeled beckhoff in the attached plots by +0.125 seconds.
• I do not understand the behavior of the channel labeled Shutter G Trigger.  The best explanation I can think of for what I see is that this is somehow the shutter is triggered on AS WFS DC.  The channel labeled SHUTTER G Trigger Volts is the beckhoff channel which Koji and I believe should be a readback of the outputs labeled PD+ and PD- on sheet 2 of D1102312.  (For reference, see the diagram of the fast shutter wiring in E1300819 QPD amp is D1001974 shutter controller is D1102312 and shutter driver is D1400078)
  • The voltage read back by the Trigger Volts channel spikes and goes to zero after the trigger fires, similar to the AS WFS channels which are behind the shutter.  AS_C should not be blocked by the shutter firing, and goes to zero more slowly after the lockloss transient has passed.  I went to the floor and sent a DC voltage into the shutter controller, as you would expect the readback of the trigger volts channel is not impacted by the shutter triggering.
  • DC power:
    • This trigger comes from the sum on D1001974  I believe this should have a gain of 0.2485V/mA on the QPD (a factor of 10 smaller than what is on the schematic), because there is the transimpendance of 1kOhm, then a gain of 0.2485 before the summation.  The normal photocurrent from the diode then is about 1mA.  (I checked with a calibrator that putting 1 V into the shutter driver input results in 1V read back in beckhoff)
    • The calibration of the AS_C channel into mA is 1V/mA (TI gain)*2 (differential driver in TI amp chassis)*10^(36/20)whitening gain*1638.4 cnts/V = 2/07e5 cnts/mA.  By undoing the front end calibration into Watts into HAM6 (29078) we can estimate that AS_C has about 0.125 mA photo current. 
    • We expect about 10 times more power on the AS WFS than AS_C, since we have 800 ppm for OM1 (plus 50% splitter) and 1% transmission for OM3 (split between 2 WFS).
  • Two caveats:
    • There is a jumper in the transimpedance chassis which can be used to turn on the 0.4z40p whitening stage, (this is after the trigger spigot) we are currently compensating this in the front end but if it is not on that could explain why AS_C sometimes overshoots and goes to zero.
    • I checked the cables, and everything seems to be as it should be.

BS HR Elliotical Baffle Alignment

Since Monday, Jason, Travis and I have been working on (amongst other things) the BS elliptical baffle rebuild and realignment.  Once all parts were in hand, the rebuild was straight forward.  Travis used the removed HR and AR baffle assemblies to line up and preassemble the mounting brackets so that the new baffles went in roughly where the old ones used to be positioned on the BS suspension structure.  However when we put the target on the HR panel, we discovered one of GariLynn's earlier worries - the baffle was off center by many millimeters.  Looking at the baffle relative to the structure seemed to indicate the same thing - the beam was left and down when looking at the HR surface target (meaning, the baffle was potentially too far up and right relative to the simulated IFO beam).

Unfortunately, this target-mounted-to-the-elliptical-baffle is what was used to align the entire BS SUS/ISI cartridge in the chamber install in ~2013, as per IAS procedure E1200795.  This fact lead us to spend a day or 2 sorting out how to tell if the BS optic is misaligned in the chamber (without any IAS measurement ability), and how we possibly could have installed the elliptical baffle out on the cartridge in the first place many years ago.  During this we went back in-chamber to make "precise" measurements.  We used Class B rulers to measure where the IFO simulation beam was hitting the BS, how well the BS is centered in the structure, and exactly where the beam was hitting the target.  Attached are actual sketches and pictures with detailed numbers.

Here's what we were able to measure to within ~1mm error since it's by-eye and other knowns:

1) The beam is hitting the center of the BS optic 2mm to the left of the optic centerline.

2) The optic is suspended in the structure to within 1mm or less of error.

3) The beam is hitting the HR target baffle 5.5 mm left of the target center.

4) Our Y-arm IFO simulator beam which runs between the ITMy center and the SR3 center ran dead center on the ITMY elliptical baffle (prior to it's removal) and the HWSY path a few weeks ago when HAM4 work was checked.

5) Per IAS procedure E1200795, the BS suspension to ISI locations were performed via more direct methods which did not involve the Baffle target, so we believe the BS to ISI mounting is correct.

Point 1) and 2) give us some confidence that the error of the BS optic placement is not as bad as how the baffle target indicates.

Some consult with GariLynn and Jenne, to understand what centering is most important from various aspects (including looking at some modeling done by Hiro in T1400055) and we have come to the conclusion that we will carry on as planned.  Namely, to first order it is best to have the baffle aligned very well to the beam.  Our next steps will be to recheck the IFO simulation beam pointing again, align the HR baffle to it, and take a series of pictures to ensure that the edges of the baffle are lined up correctly with the edges of the BS optic from the beam POVs.

Also during our walkabout over the last 2 days, we re-interpreted Keita's BS centering/beam clipping alog 28196, pointed out by Sheila.  Because it is difficult to see the edges of the BS optic when the baffle is installed, it seems Keita made some geometrical analysis of the HR and AR baffle positions to determine the position of the BS center.  However, since we believe the baffle was mounted in the wrong position by a few mm, his centering numbers likely are not correct.  Still, his numbers indicate the same directions of error as we see - the beam is hitting left and low of the baffle/optic.  I think we can repeat this measurement in the future by scaling the known diameters of the baffle holes and BS optic size on the camera view pictures.  Will think on this more.

 

End Station Temperature Control

Krishna

The End Station VEA temperatures are currently locked to H0:FMC-EY_VEA_AVTEMP_DEGF, which is an average of various sensors mounted to the walls of the VEA. As has been discussed before, what we'd like to hold constant is the temperature of the suspensions or the vacuum chambers. The attached plot shows various temperature sensors (refer to Jeff's alog for calibration) in the VEA which all show a rising trend (the M0 has a negative temp coefficient), whereas the FMC average sensor shows a constant trend. The reason for this is it is getting colder outside, so the walls are cooler. Therefore to keep the walls at the same temperature, the inside has to get warmer.

Robert and others had noted this for the corner station earlier and I've been told that this was fixed at the corner station but not at the end stations. I would recommend fixing this problem for both the end-stations as well. One possible solution is to simply mount the FMC sensors on or closer to the vacuum chamber.

BRS-X upgrade: Complete. Monitoring Mean Position.

Krishna

The reconfiguring of BRS-X is complete. The new resonance frequency of BRS-X is 5.6 mHz (T ~180 s) and d is zero for all practical purposes. The BRS-X calibration filters have been modified. I have also modified the tilt-subtraction filter banks. The big change is that there is no acceleration correction for the finite d.

The pdf attachment shows the tilt-subtraction achieved under mild wind speeds of ~10-15 mph. The one noteworthy change is that the tilt-subtraction is slightly better in the 5-20 mHz frequency range, likely due to the lower resonance frequency.

I have also modified the C# code, which calculates the Beam angle, to also make an online subtraction of the reference beam angle. Previously, we did not do this since the reference beam angle noise was usually much smaller than the main Beam angle, hence it didn't help much. However, I have recently noticed that during times of excess temperature noise in the VEA, the reference beam angle noise is worse and does contribute to the main Beam angle. In order to do the subtraction (requires extra calculations), I had to reduce the update frequency of the C# code (from 140 Hz to 70 Hz). I have confirmed that this does not negatively affect the tilt-subtraction, though it does increase the high frequency noise floor slightly (by ~sqrt(2)). This code change will also be implemented at BRS-Y.

The pressure in the vacuum can (BRS_X_PumpPressure.png) is currently at ~1e-6 torr and going down steadily. The mean position (driftmon) of BRS-X was reset on Monday (see BRS_X_DriftMon.png). Acceptable range is +/- 16k counts. It seems to be stable now and I will continue monitoring.

Edit: The capacitive damper/actuator on BRS-X now works the same as that on BRS-Y. The Q is set to ~10 when the angle exceeds the high threshold (which is nominally set to 2000 = 2 micorad). Below that, the Q is set to ~100. It is time to say goodbye to the gravitational damper! It was fun while it lasted !

BRS-Y and the Platform Seismometer

Krishna

The attached pdf file shows the comparison between BRS-Y, the ground seismometer (an STS-2) and the platform seismometer (a T240), called a PEM signal in this case (since we are using spare PEM channels for it). Also shown are the online tilt-subtracted super-sensor output (online residual) and a second tilt-subtracted signal between the T240 and BRS-Y (PEM residual). Page 2 shows the coherences between various signals and Page 3 shows the wind-speeds. As I showed before, the coherence between BRS-Y and the platform seismometer (T240) is better than that between BRS-Y and the ground seismometer (STS-2).

Note that in this plot I have used the normal calibration factor for BRS-Y and STS-2. For the T240, I matched its output to the STS-2 at the secondary microseism. You'll notice that while the STS-2 and BRS-Y are coherent below 0.1 Hz, their outputs differ by 20 percent. Initially some had suspected we got our calibration wrong, but this is now known to be due to differential floor tilt. For the online tilt-subtraction we use a factor of 0.78 for BRS-Y to correct for this. However, the platform seismometer agrees very well with the raw BRS-Y calibration (we did get our calibration right!). This confirms that the two instruments are now seeing the same tilt.

The tilt-subtracted T240 signal (PEM residual) is now marginally better than the tilt-subtracted STS-2 signal in the 15-50 mHz range. It is possible that this is still limited by temperature noise on the T240, since the tilt-subtracted noise looks similar at lower wind speeds too (not shown). Hugh will attempt to improve the thermal insulation when possible.

The most important test is to now see if the two residual curves diverge even more when wind speeds pickup above 20 mph. If so, this would confirm the differential floor tilt hypothesis. If not, it would suggest some other noise/nonlinearity limits the tilt-subtraction. Unfortunately, it looks like we'll have to wait till next week for higher wind speeds.

beckhoff vs front end timing of slow channels from DAQ NDS

Sheila, Jonathan, Dave:

Sheila had a question about the relative timing of an analog event which was recorded by both a front end computer and a Beckhoff slow controls computer. When looking at the two channels from the DAQ, there was a time difference of about a tenth of a second.

As a test, I have some slow signals coming from front end models and being a acquired by the DAQ through two paths: one direct alongside the fast data, and an equivalent channel coming in via the EDCU. To show the delay, I looked at the h1ioplsc0 model's state word, and manually changed it by running an excitation to set the EXC bit. In the attached plot, the signal being sent directly to the DAQ data-concentration is the upper red plot, the signal being acquired over the network via the EDCU is the lower purple plot. As can be seen, the front end data is packetized into a 1/16th block before sending to DC, which in turn packetizes the data into a 1/16 block and adds the Beckhoff data point. This results in an apparent 2 sample delay (0.125S) in the red plot. In actuality, the red plot is timed correctly, and the Beckhoff event is incorrectly time stamped as preceding the event by 0.1 S.

We think moving the EDCU to a front end would resolve this.

The use of a front-end based EDCU (instead of the DAQ Data Concentrator) is already implemented in the CDS code base.  It has already been tested extensively on test stand and, and briefly on L1. There are installation instructions in the DCC.  This change is required to ensure EPICS data agreement when multiple Data Concentrators are used to increase redundancy.