Jenne, Sheila, Hang

We wrote a piece of code to automate the measurement of ASC sensing matrix (using method described in alog 25648). It is available at

/opt/rtcds/userapps/release/isc/h1/scripts/SenMtrx

This is a complementary code to the existing one. The new one does not connect to the nds server but only uses ezca, so it may be more stable. On the other hand it can only do elementary measurement right now.

=============================================================================================================

We used this code to measure the sensing matrix with only DRMI locked. The values are

The secondary microseism is back down, bring the blends back.

Kyle, Joe D. 

The plan now is to splice-in the longest piece of the excess good cable left over from the initial install.  The resulting o.a.l of this repaired cable will be very close to what is needed but may require routing through a, yet-to-be-created, wall penetration into the adjacent room where the pump controller resides - or not.  

I broke away to give a tour to Perry Technical College of Yakima from 10am -noon.  (Jeff B covered me during this time.)

After the h1bootserver issue, DRMI locking looked bad, so I did an initial alignment (everything except ALS since they looked good).  After this DRMI locked within 10min & it looked noisy at first, and also needed to be touched up.  Handed to commissioners for ASC work....but quickly after this...

...Alignment went to La La Land.  Helped Jenne work on restoring groups of optics to where they were when we last locked DRMI.  She's still working on alignment.

LVEA Laser Hazard late morning

EX Laser Safe late morning

All times in UTC below

• 15:20 Forklift moved from LVEA to MX (Chris S)
• 16:00 Beam sealing work (Chris S)
• 16:00-17:55 Craning items in LVEA & Gate Valves cycled (Bubba & Kyle)
• 16:02 HEPI Guardian work (Hugh)
• 16:12 - 17:20 HAM3 SUS Sattelite boxes (Richard)
• 17:17 GRB acknowledged---> H1 was down.
• 17:40-17:55 Cable measurements in Beer Garden (Filiberto)
• 17:45  EX, MX, MY cleaning (Karen, Christina)
• 17:45 Corner Station Beckhoff Update (Daniel)
• 17:50-18:22 Hartman Table near HAM4 (Elli & Cao)
• 17:57 Transition LVEA to SAFE (Sheila)
• 19:00 DRMI for Jenne
• 19:30 H1 Boot Server work to address computers being froze.  (CDS)----->90min down FRS!
• 19:40-19:50 EX transitioned to Laser Safe
• Morning time:  Fire Dept has been around the site doing panel work 
• 21:55 Begin ASC work with DRMI (Hang, Jenne, ...)
• 22:54 EY Magnetometer measurements (Brynley running down there)
• 23:24 Mid station entry after talking with Bartlett.  (Rick)
• ? - 23:59 Finished measuring VAC cables at EY (Kyle & JoeD)
• Reservation system froze earlier today....TJ will fix it tonight.

DAY Checksheet Notes:

• On FOMs the ETMx camera continues to be down on video5
• MX VEA camera continues to be noisy
• On CDS DAQ Detail, h1tw0 continues to be INVALID(white-boxed)

I have written a script which provides the list of guardian nodes which use any specified file. This will aid in restarting all the Guardian nodes impacted by a python script change.

The command is called which_guardian_nodes_are_using_this_file. It takes the file name (full or partial path) as an argument.

Because scanning all 80 Guardian nodes and generated the list of files they use is time consuming (about 30 seconds), there is an optional second argument (-s) to skip this step and use the results of previous invocations.

The list of files are in the /ligo/data/guardian/files directory. There is a file gnodes.txt which lists all the guardian nodes. For each node there is a file named by the node. Here is an example call to the script

which_guardian_nodes_are_using_this_file /opt/rtcds/userapps/release/sus/h1/guardian/sustools2.py -s

Checking which Guardian node(s) use the file /opt/rtcds/userapps/release/sus/h1/guardian/sustools2.py
Guardian Node(s) using this file:
SUS_BS
SUS_ETMX
...
SUS_TMSX
SUS_TMSY
 

Using SUS-BS as an example here is a way to get the files its Guardian uses:

cat /ligo/data/guardian/files/SUS_BS

/opt/rtcds/userapps/release/sus/common/guardian/burt.py
/opt/rtcds/userapps/release/sus/common/guardian/SUS_BS.py
/opt/rtcds/userapps/release/sus/h1/guardian/susconst.py
/opt/rtcds/userapps/release/sus/h1/guardian/SUS.py
/opt/rtcds/userapps/release/sus/h1/guardian/sustools2.py
 

Thursday: AS WFS 90MHz centering (afternnon), Noise hunting afterwards

Friday: HWS/TCS morning, OMC noise/noise hunting afterwards

Saturday: SRC work

Sunday: -

Monday: Noise hunting

Tuesday: TCS work

I wanted to try using the buried STS at ETMY for sensor correction when it wasn't windy, to see if it worked. On the 22nd, for half an hour or so I switched it, and it seems to work. Attached spectra shows that using the buried STS gives similar performance to the STS in the building, at least when the wind is low, and we are using sensor correction at the micrseism. Red and pink are the ST1 T240 and buried STS when using the buried STS, dark blue and light blue are the ST1 T240 and the inside STS when running in our normal configuration. Both measurements were taken with the 90mhz blends, so all of the isolation between the T240 and ground between .1 and ~.2 hz is due to the sensor correction.

Unfortunately, when I tried this when it was windy, I got no isolation at all. I'm still looking into that.

at 11:10 PST h1boot generated an nfsd error (see below). All front end computers have locked up. We tried rebooting h1susauxh2 but h1boot is no longer permitting this (missing root file system). We need to first reboot h1boot, then all front end computers.

Cao, Elli

In order to use the ITMX HWS during TCS commissioning, we have removed the polarization sensor optics which were placed in the HWSX path on the HWS table by HAM 4.  (Placement of the polarization sensors is detailed in alog 24046.)  We removed the PBS and the HWSX_ALIGN_M1 mirror from next to the periscope and have bolted them out of the way behind the HWSX camera for the time being.  We also dumped the two sled beams coming through HWS_ALIGN_BS.  We can see the sled beam on the HWS.  I adjusted HWS STEER M10 (the mirror right before the camera) to center the beam on the camera, and did not touch the periscope mirrors.

Updated the corner Beckhoff code to incoporate the tidal servo engagement delay and the new EOM driver readback calibration.

Looks like there is a failing CPS at ETMY. I noticed on the Detchar sumary page, ETMY was not performing as well as the other BSCs above 1 hz, and has been for a little while (since about Feb 2nd). When I started looking at spectra, I saw that the Y CPS blend in was high at high frequency, digging down to individual sensors, it looks like ST2 H3 is to blame. LLO had a similar failure last year sometime. We should be able to stick a new card in and still run okay, or maybe we just need to check some connections. Probably not a big deal for now, but we should address this soon. Attached plots shows the CPS for St2 (first plot) and St1(second). Green on the first plot is the bad sensor. The St1 sensors look okay, though H2 (blue, second plot) looks a little high as well.

Evan, Den

Tonight we asked ourselves a question whether 1/f (or 1/f^2) noise, seen in DARM around 100Hz, comes from the OMC or not. We put a bandstop filter to the DARM control loop at 92-127Hz and made a correlation measurement between AS 45 WFS SUM and OMC PDs at this frequency band. The idea is that if there is any OMC noise coherent between 2 OMC PDs, it should not be present at the RF detector.

Attached plot shows the results of the measurement. Cross-spectrum between WFS and OMC PDs around 100Hz is almost the same (15% lower) as cross-spectrum between two OMC PDs. We integrated for 3.5 hours and AS 45 WFS SUM channels are not DQ. We can significantly improve the measurement if we record these channels and integrate for ~20 hours.

At the current precision of the correlation we can not say that noise around 100Hz comes from the OMC. Right now it looks vice versa.

Today Keita and I spent some time thinking about OMC length noise, there will be an update coming soon with more information and a noise projection.  

We spent some time looking at some nonlinear behavoir noise in the drive to PZT1.  Our dither frequency is 4100 Hz, and looking at the low voltage PZT monitor we can see a small 8 Hz and a larger 16 Hz comb.  There is also other non stationary noise in the monitor, and a broad peak at 12.7 kHz.  We have moved the dither line frequency to 4100.21 Hz, so if this was the cause of the 16 Hz comb in DARM we would now expect it to be more like a 16.84 Hz comb.  Evan Goetz tells us that we need 15 minutes or more of data in low noise to evaluate if this has changed any combs in DARM. 

We have just reached nominal low noise at 3:14:34 UTC Feb 25th, although the low frequency noise (below 50 Hz) is worse than normal.  I've temporarily changed the dither frequency in the OMC guardian, so if there is a longer lock later tonight it should also have this changed dither frequency.    (If anyone wants to double check what the dither frequency is, the channel is   H1:OMC-LSC_OSC_FREQ

Per work permit 5741 began the process of modifying all Suspension Satellite Amplifiers.  Drawing D0901284-v4 calls for the addition of Cap C601(10uF) and C602 (.1uF) between the -17V to Ground around U503 the Negative Regulator VEE1.
Today with Ed M. Soldering away in the lab we were able to complete all of Han2 units.
Complete are:
MC1, MC3, PRM, PR3, MMT1, MMT2, SM1, SM2  All Stages.

We did have a problem with two Sat Amps. One shared between MC1 and MC3 and the one for  MMT2,a trace blew when it was powered up.  So replaced SN 1100117 with SN S1000287 and SN1100068 with SN1100066.

Den, Sheila, Evan

~> We tried reverting to the old QPD offsets (the ones we used throughout O1) for the soft loops and the PRM pointing loops. These seemed to make the recycling gain slightly worse, and did not improve the jitter coupling. This indicates that (as we had suspected) these offsets are no longer good to use.

~> We measured the 9 MHz oscillator phase noise coupling into DARM. This had been done previously (19911), but with a suspicious calibration and in a way that also drove the 45 MHz phase. This time, we used the OCXO to drive both the harmonic generator (bypassing the 9 MHz distribution amplifier) and to serve as a reference for an IFR/OCXO PLL with a >40 kHz bandwidth. The IFR is used to drive the 9 MHz distribution amplifier. The error point of the PLL was offset in order to maintain the relative time delay of the 9 MHz and 45 MHz signals. When we relocked, we found that the 18 MHz and 27 MHz signals had flipped sign, but otherwise the interferometer locked normally. However, there was a great excess of 45 MHz noise in DARM (worse even than before we installed the 9 MHz bandpass). Nevertheless, we were able to drive enough to see the effect of 9 MHz phase modulation in DARM. The coupling is roughly 2–4×10⁻⁶ mA/Hz above 100 Hz.