WP 6584
Pulled new cabling for temperature sensors from the mechanical room into the LVEA. Runs in the LVEA are to the following chambers: HAM2, HAM3, HAM4, HAM5, BSC1, and BSC3. Work required climbing on chambers HAM4 and HAM5. This work is part of the HVAC upgrade being done by Apollo. Did not get to finish the HAM2 cable run. It is currently sitting next to HAM3. Will complete work next maintenance period.
Filiberto Clara
TITLE: 04/18 Eve Shift: 23:00-07:00 UTC (16:00-00:00 PST), all times posted in UTC
STATE of H1: Lock Acquisition
OUTGOING OPERATOR: Nutsinee
CURRENT ENVIRONMENT:
Wind: 24mph Gusts, 20mph 5min avg
Primary useism: 0.16 μm/s
Secondary useism: 0.16 μm/s
QUICK SUMMARY:
Nutsinee has been attempting to relock.
TITLE: 04/18 Day Shift: 15:00-23:00 UTC (08:00-16:00 PST), all times posted in UTC
STATE of H1: Lock Acquisition
INCOMING OPERATOR: Patrick
SHIFT SUMMARY: Not much activities after I took over from Cheryl. Locked at NLN briefly but lost it. Possibly due to wind (now passed 30 mph).
LOG:
19:30 Robert & Evan to End Stations -- turn off PCal camera.
20:20 Fil & Marc out (cable pulling work)
20:36 Robert & Evan back
20:53 Robert to LVEA -- align MC3 camera
20:54 Dave back
21:01 Jenne et al. to ISCT1 to place beam dump.
22:14 Robert done sweeping the LVEA
Evan G., Robert S. Looking back at Keith R.'s aLOGs documenting a changes happening on March 14 (see 35146, 35274, and 35328), we found that one cause seems to be the shuttering of the OpLev lasers on March 14. Right around this time, 17:00 UTC on March 14 at EY and 16:07 UTC at EX, there is an increase in line activity. The correlated cause is Travis' visit to the end station to take images of the Pcal spot positions. The images are taken using the Pcal camera system and needs the OpLevs to be shuttered so that a clean image can be taken without the light contamination. We spoke with Travis and he explained that he disconnected the USB interface between the DSLR and the ethernet adapter, and used a laptop to directly take images. Around this time, the lines seem to get worse in the magnetometer channels (see, for example, the plots attached to Keith's aLOG 35328). After establishing this connection, we went to the end stations to turn off the ethernet adapters for the Pcal cameras (the cameras are blocked anyway, so this active connection is not needed). I made some magnetometer spectra before and after this change (see attached). This shows that a number of lines in the magnetometers are reduced or are now down in the noise. Hopefully this will mitigate some of the recent reports of combs in h(t). We also performed a short test turning off another ethernet adapter for the H1 illuminator and PD. This was turned off at 20:05:16 18/04/2014 UTC and turned back on at 20:09:56 UTC. I'll post another aLOG with this investigation as well.
Good work! That did a lot of good in DARM. Attached are spectra in which many narrow lines went away or were reduced (comparing 22 hours of FScan SFTs before the change (Apr 18) with 10 hours of SFTs after the change (Apr 19). We will need to collect much more data to verify that all of the degradation that began March 14 has been mitigated, but this first look is very promising - many thanks! Fig 1: 20-50 Hz Fig 2: 50-100 Hz Fig 3: 100-200 Hz
Attached are post-change spectra using another 15 hours of FScan SFTs since yesterday. Things continue to look good. Fig 1: 20-50 Hz Fig 2: 50-100 Hz Fig 3: 100-200 Hz
Correction: the date is 18/04/2017 UTC.
Another follow-up with more statistics. The mitigation from turning off the ethernet adapter continues to be confirmed with greater certainty. Figures 1-3 show spectra from pre-March 14 (1210 hours), a sample of post-March 14 data (242 hours) and post-April 18 (157 hours) for 20-50 Hz, 50-100 Hz and 100-200 Hz. With enough post-April 18 statistics, one can also look more closely at the difference between pre-March 14 and and post-April 18. Figures 4-6 and 7-9 show such comparisons with different orderings and threrefore different overlays of the curves. It appears there are lines in the post-April 18 data that are stronger than in the pre-March 14 data and lines in the earlier data that are not present in the recent data. Most notably, 1-Hz combs with +0.25-Hz and 0.50-Hz offsets from integers have disappeared. Narrow low-frequency lines that are distinctly stronger in recent data include these frequencies: 21.4286 Hz 22.7882 Hz - splitting of 0.0468 Hz 27.4170 Hz 28.214 Hz 28.6100 Hz - PEM in O1 31.4127 Hz and 2nd harmonic at 62.8254 Hz 34.1840 Hz 34.909 Hz (absent in earlier data) 41.8833 Hz 43.409 Hz (absent in earlier data) 43.919 Hz 45.579 Hz 46.9496 Hz 47.6833 Hz 56.9730 Hz 57.5889 Hz 66.7502 Hz (part of 1 Hz comb in O1) 68.3677 Hz 79.763 Hz 83.315 Hz 83.335 Hz 85.7139 Hz 85.8298 Hz 88.8895 Hz 91.158 Hz 93.8995 Hz 95.995 Hz (absent in earlier data) 107.1182 Hz 114.000 Hz (absent in earlier data) Narrow low-frequency lines in the earlier data that no longer appear include these frequencies: 20.25 Hz - 50.25 Hz (1-Hz comb wiped out!) 24.50 Hz - 62.50 Hz (1-Hz comb wiped out!) 29.1957 Hz 29.969 Hz Note that I'm not claiming change points occurred for the above lines on March 14 (as I did for the original set of lines flagged) or on April 18. I'm merely noting a difference in average line strengths before March 14 vs after April 18. Change points could have occurred between March 14 and April 18, shortly before March 14 or shortly after April 18.
To pin down better when the two 1-Hz combs disappeared from DARM, I checked Ansel's handy-dandy comb tracker and found the answer immediately. The two attached figures (screen grabs) show the summed power in the teeth of those combs. The 0.5-Hz offset comb is elevated before March 14, jumps up after March 14 and drops down to normal after April 18. The 0.25-Hz offset comb is highly elevated before March 14, jumps way up after March 14 and drops down to normal after April 18. These plots raise the interesting question of what was done on April 18 that went beyond the mitigation of the problems triggered on March 14. Figure 1 - Strength of 1-Hz comb (0.5-Hz offset) vs time (March 14 is day 547 after 9/15/2014, April 18 is day 582) Figure 2 - Strength of 1-Hz comb (0.25-Hz offset) vs time
The bi-monthly End X PCal calibration was performed today. Results can be seen at https://dcc.ligo.org/T1500129. Force coefficient for TxPD is 0.02% from its mean value and force coefficient for RxPD is 0.2% from its mean value.
[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.
Jeff K, Jonathan, Dave:
h1calcs was restarted with new code at 10:15 PDT. Jonathan and I took the opportunity to update the H1EDCU_RACCESS.ini file with missing channels, and then restarted the DAQ.
This was h1calcs model change was covered under the continued work described in WP #6572 ECR E1700121 II 7828 This restart was to incorporate a few more EPICs monitor channels (24 or so) to support commissioning of the new SRC Detuning Infrastructure (see LHO aLOG 35547). In addition, I moved the pick-offs for calculated time-dependent correction factors that feed into the next subsequent calculations upstream of the final-answer 128 [sec] low pass. No change was made to the functionality of the infrastructure for h(t), these are all control-room only used redundant infrastructure. The changes to the h1calcs model is actually just changes to common library parts, which have been committed to the userapps repo: /opt/rtcds/userapps/release/cal/common/models/ CAL_CS_MASTER.mdl CAL_LINE_MONITOR_MASTER.mdl These EPICs channels have been added to the various MEDM screens, and those screens have been committed to the userapps repo under /opt/rtcds/userapps/release/cal/common/medm/ CAL_CS_TDEP_F_C_OVERVIEW.adl CAL_CS_TDEP_F_S_OVERVIEW.adl CAL_CS_TDEP_KAPPA_PU_OVERVIEW.adl CAL_CS_TDEP_KAPPA_TST_OVERVIEW.adl CAL_CS_TDEP_OVERVIEW.adl Initial results (i.e. the 30 minute NLN lock we just had) indicate that moving the pick-offs that pass one answer to the next calculation upstream of their 128 sec low-pass has cleaned up the final answers. Plots to come when we have more data.
For future reference:
with the card in the horizontal position, with the bottom tab of the PCI-e card on the left (as viewed from behind the computer), the connector's wide end is in the upper location. The port in use are:
h1hwsex: Left hand port
h1hwsey: Left hand port
h1hwsmsr: Right hand port (ITMX readout)
Nutsinee, Dave:
we had two problems in getting h1hwsex running again: It was running a new kernel which is missing the frame grabber driver, and the fiber was plugged into the wrong port on the card.
h1hwsex by default runs a later kernel (3.19.0-78-generic) than h1hwsey (3.19.0-49-generic). The '78' kernel is missing the edt kernel object needed to drive the frame grabber card. For a quick fix for today, I rebooted h1hwsex while standing in front of its console at EX and interrupted the boot to force a boot to the 3.19.0-49-generic kernel (it is under the U14 advanced options on the boot screen, using the non-recovery version of the '49') kernel.
The fiber/transceiver was plugged into the right hand side of the card in h1hwsex. When I moved it to the left, the code detected the camera. I went to EY and verified that the transceiver is also on the left port of the card in h1hwsey
We'll have a brief commissioning break from 9AM to 1PM Pacific tomorrow, coincident with LLO.
Task list (will be down selected):
Measure ASC sensing matrix, including POP WFS. (Should be quick - amplitudes all tuned already)
Now that we've got infrastructure in place for tracking SRC detuning parameters live, I'd like to repeat Evan Hall's study from LHO aLOG 27675, putting offsets into the SRCL loop and see if the infrastructure / parameters track the change in detuning as that has been confirmed to do. I request 30 minutes of full, NLN IFO time.
ascii file saved on desktop folder of RGA machine in control room
Here is a link to a Vertex scan taken a few months ago: https://alog.ligo-wa.caltech.edu/aLOG/uploads/29517_20160907141626_09062016_Vertex_SEM1500_analog.pdf Note: the apparent amplitude discrepancies are due to differing multiplier voltage settings. As such these two scans are for qualitative comparisons only.
Completed WP 6579 and then some.
*left three turbo stations and Kobelco energized, water still valved into QDP80 (#2) for cooling
Follow-up maintenance items:
I replaced the burned-out incandescent lamp with an upgraded LED version (Data Display Products, miniature, wedge-base 24-28VAC white WB200-FW4K28HD)
I de-energized Kobelco and valved out water to QDP80. Tomorrow during commissioning I will enter LVEA and de-energize turbo stations.
This completes WP #6587
Maintenance Update as of19:00UTC:
I attached all the SDFs I accepted and reverted today. Non of these have been committed to the svn yet.