WP 6584
Continued work from last week, see alog 3564. Final temperature sensor cable was pulled from HAM3 over to HAM2. This completes work for WP 6584.
At the request of the control room and as outlined in WP #6607 the new nds client package has been made the default on the debian 8 workstations. You no longer need to source an additional environment file or do a javaaddpath in matlab.
The default matlab (2012b) for the debian 8 workstations will pick up the new client by default.
This does not affect the remaining Ubuntu12 systems (including the guardian).
Gerardo, Chandra
Soft closed GV 5,7 this morning in preparation for craning over large cleanroom. Unfortunately there were some issues with the cleanroom so it didn't get moved today. We opened valves at 2:30 pm local.
We've also reserved three hours for calibration on Thu. Apr. 27, 1600-1900 UTC (0900-1200 Pacific) in coincidence with LLO.
Keita writing as Corey.
ASC -> Jenne, Sheila and others. Locked IFO needed.
EY oplev -> Jason. IFO status doesn't matter.
Additionally, the following might happen.
OMC jitter measurement -> Sheila, locked IFO.
Removing/putting on Hartman plate on the end station HWF camera when the IFO is unlocked -> Nutsinee.
J. Kissel I've taken this week's effective bias voltage measurements that track accumulated charge on the test mass/reaction mass electrostatic drive system. The standard metrics: - Monitoring the single-frequency actuation strength of each quadrant as a function of requested bias voltage using Pitch and Yaw optical optical lever signals to measure the response. - Monitoring the overall longitudinal strength comparing an ESD excitation against a photon calibrator excitation at adjacent single frequencies. The conclusions from both these metrics have not changed from the last two measurements (LHO aLOGs 35553, 35366): Just before we vent on May 8th, during last minute preparations as we bring the IFO down, let's - Turn OFF the ETMX ESD bias completely, and leave it OFF - Leave the ETMY bias ON at +400 [V], with the opposite sign as in observation (Negative in NLN, switch to Positive for vent) for the duration of the vent (i.e. until we open back up to the arms)
Sheila, Jason, Evan G, Krishna
Mode hoping of the ETMY oplev has been showing up in hveto since April 19th, although the oplev damping is off. The glitches that show up are definitely glitches in the sum, and the oplev is well centered, so the issue is not that the optic is moving. There is a population of DARM glitches around 30 Hz that is present on days when the oplev is glitching but not on other days. We are curious about the coupling mechanism for these glitches and wonder if this coupling could be causing problems even when the oplev is not glitching loudly .
Evan, Jason and I connected the monitor on the oplev laser diode power to one of the PEM ADC channels used to monitor sus rack power (we used H1:PEM-EY_ADC0_14_OUT_DQ, which was monitoring the +24V power and is channel 7 on the field rack patch pannel. Jason can make the laser glitch by tapping it, with this test we saw clear glitches in the sum but no sign of anything in the monitor so this monitor might not be very useful. Plugging this in means that the lid of the cooler is slightly open.
We also unplugged the fiber, so that for the time being there is no light going into the chamber from the oplev. If these glitches are coupling to DARM electromagnetically, we expect to keep seeing them in DARM. If they were somehow coupling through the light (radiation pressure, something else), we would expect them to go away now. One glitch that we looked at is about a 75 uW drop in the laser power on the optic. (A=2P/(c*m*omega^2)= 3e-19 meters if all the power were at 20 Hz). We don't really know how centered the beam is on the optic, or what the reflectivity is for the oplev laser, but it seems like radiation pressure could be at the right level to explain this.
Using an ASD of the oplev sum during a time when the oplev is quiet, this noise is more than 3 orders of magnitude below DARM at 30 Hz.
The fiber was disconnected at ~19:05:00 25 April 2017 UTC. There will not be any Hveto correlations after this time because the OpLev QPD will not be receiving any light. We will be looking at Omicron histograms from the summary pages to determine whether this is the cause of noise.
With this test over, I have reverted the above changes; the ETMy oplev is now fully functional again, as of ~18:30 UTC (11:30 PDT). I also unplugged the cable we used for the laser diode monitor port and reconnected H1:PEM-EY_ADC0_14_OUT_DQ so it is now once again monitoring the +24V power on the SUS rack.
To address the glitching, I increased the oplev laser output power; using the Current Mon port on the back of the laser:
The laser will need several hours to come to thermal equilibrium, as the cooler was left open overnight (as a result of the above test). Once this is done I can assess the need for further output power tweaks.
If the glitch happens tonight while Jason is unavailable, leave it until tomorrow when Jason can make another attempt to tune the temperature.
Even when H1 is observing, operators can go out of observing, let Jason work for a short while, and go back into observation as soon as he's done.
But it's clear that we need a long term solution that doesn't include intensive babysitting like this.
As I noted here, the oplev laser SN 191 was found to be running very warm; this in turn made it very difficult to eliminate glitches. In light of this, as per WP 6591, this morning I re-installed laser SN 189-1 into the ITMy oplev. The laser will need a few hours to come to thermal equilibrium, then I can assess whether or not further tweaks to the laser output power are needed to obtain glitch-free operation. I will leave WP 6591 open until the laser is operating glitch-free.
SUM counts for this laser have been very low; ~2.8k versus the ~30k the last time this laser was used (March 2017). Today I pulled the laser out of the cooler and tested it in the Pcal lab and found the output power to be very low; at the setting being used I measured 0.11 mW versus the 2.35 mW I measured before I installed the laser. By tweaking the lens alignment (lens that couples light from the laser diode into the internal 1m fiber) I was able to increase the output power to ~0.2 mW. There is clearly something not quite right with this laser, my suspicion being either a gross misalignment of the coupling assembly (which takes longer than a maintenance period to correct) or something is going bad with the laser diode. Knowing the history of these lasers, both are equally probably in my opinion.
Unfortunately there is not a spare currently ready for install. In light of this, since the laser is currently working, I reinstalled SN 189-1 into the ITMy optical lever so at least we have a functional ITMy oplev. Once I get a spare ready for install this laser will be swapped out at the earliest opportunity. I have closed WP 6591.
[Greg Mendell, Aaron Viets] Due to the bug found in gstlal-calibration-1.1.5, the DMT machines have been reverted to version 1.1.4. Primary and redundant pipelines, as well as the DMTDQ processes, were restarted at 1177181448. Output looks normal so far.
Aggregation of calibration hoft has been restarted on DCS, with these channels removed,
H1:GDS-CALIB_F_S
H1:GDS-CALIB_F_S_NOGATE
H1:GDS-CALIB_SRC_Q_INVERSE
H1:GDS-CALIB_SRC_Q_INVERSE_NOGATE
starting from 1177181608 == Apr 25 2017 11:53:10 PDT == Apr 25 2017 18:53:10 UTC
As per WP #6594 I have installed the latest nds2 client on the Debian 8 workstations in the control room. It is not selected as the default nds2-client. It has not been build for the Ubuntu12 systems as the workstations are being retired as quickly as possible. It is not being deployed on IFO infrastructure systems.
To use this from python you need to setup your paths first (from your bash prompt):
To use this from Matlab you need to add the nds2.jar file to your javaclasspath (from matlab):
For a quick demonstration of the client w/ gap handling enabled in matlab. This sample connects to the nds2 server, gets a channel count, enables a gap handler (fill gaps with a 1.0) and retreives data that happens to start with a gap.
>> c.countChannels('*PEM*')
ans =
124731
>> c.setParameter('GAP_HANDLER', 'STATIC_HANDLER_ONE');
>> data = c.fetch(1171743295, 1171743298, {'H1:SUS-ETMX_L3_OPLEV_BLRMS_P_300M_1'})
data =
nds2.buffer[]:
[nds2.buffer]
>> data(1).getData()
ans =
1.0000
1.0000
1.0000
1.0000
1.0000
1.0000
1.0000
1.0000
1.0000
1.0000
1.0000
1.0000
1.0000
1.0000
1.0000
1.0000
0.0199
0.0198
0.0198
0.0198
...
While this is not enabled as the default nds2-client, it does fix a number of bugs in the 0.13.2 release. Please let me know if there problems.
Lowered to 16% open as the Dewar is being filled right now.
Jim, Krishna
We disconnected, locked the c-BRS instrument and moved it and it's foam box out of the way from ITMX chamber door to provide access for the upcoming vent. It is still in the bier garten, but hopefully sufficiently out of the way. It is still in the locked position so it can be moved further if needed, but should be handled carefully after consulting Jim or me.
I reset the both PSL power watchdogs at 15:52 UTC (8:52 PDT). This completes FAMIS 3647.
This morning I adjusted the HPO pump diode currents. All currents were raised by 0.1A. The new and old values are summarized in the table below:
| Old (A) | New (A) | |
| DB1 | 52.4 | 52.5 |
| DB2 | 51.9 | 52.0 |
| DB3 | 51.9 | 52.0 |
| DB4 | 51.9 | 52.0 |
All work was done with the ISS OFF. The HPO is outputting ~169.2W, the ISS was turned back ON.
Main laser Beckhoff screen.
TITLE: 04/25 Owl Shift: 07:00-15:00 UTC (00:00-08:00 PST), all times posted in UTC
STATE of H1: Observing at 62Mpc
INCOMING OPERATOR: Jim
SHIFT SUMMARY:
Decent night with very low seismic & H1 locked for ~ 13.5hrs. And now for Maintenance Day.
LOG:
All is quiet. H1 locked for almost 10hrs (over 8.5hrs of double-coincidence).
TITLE: 04/25 Owl Shift: 07:00-15:00 UTC (00:00-08:00 PST), all times posted in UTC
STATE of H1: Observing at 62Mpc
OUTGOING OPERATOR: Cheryl
CURRENT ENVIRONMENT:
Wind: 7mph Gusts, 6mph 5min avg
Primary useism: 0.01 μm/s
Secondary useism: 0.17 μm/s
QUICK SUMMARY:
After the afternoon rumblings we are in a quiet state with a range of 60-65Mpc and are approaching a lock of 6hrs.
Everything looks normal. The pressure change follows an across-the-board flow change; the change is not very large and everything returned to normal. At this point it does not appear to be worrying, but we will keep an eye on it nonetheless.
[Jenne, Vaishali, Karl]
We have replaced the razor beam dump on ISCT1 that was causing scattered light problems (see alog 35538) with an Arai-style black glass dump, provided by the 40m (see 40m log 8089, first style). You can see the new dump just to the left of the PD in the attached photo. I was thinking about sending the reflection from this dump (after several black glass bounces) to the razor dump, but I can't see any reflection with just a card, so skipped this step for now. We can come back to it with an IR viewer if we have more time in the future.
We're on our way to NLN, so maybe we'll see if this helps any, if we happen to get high ground motion sometime.
[Jenne, Vaishali, Karl, Betsy]
Koji pointed out to me that even though the new black glass beam dump had been sitting on a HEPA table at the 40m, since it has been so long since it was cleaned, it could accumulate a bit of dust or film.
So, we temporarily put the razor dump back, disassembled the black glass dump, and with Betsy's guidance cleaned the surfaces of the black glass with first contact. We then reassembled the dump and put it back on the table.
Taking advantage of a few minutes while those working on the cleanroom took a short break, we transitioned to laser hazard so that we could do a fine alignment of the beam dump with the DRMI flashing. The LVEA was transitioned back to laser safe after this brief work was completed, so that the cleanroom team could work more easily.
Pressure build at the vertex due to closure of GVs.