TITLE: 2/26 eve Shift: 00:00-08:00 UTC (16:00-00:00 PST), all times posted in UTC
STATE of H1: Planned Engineering
INCOMING OPERATOR: None
QUICK SUMMARY: Commissioning work as usual.

LOG:

• 00:12 Rick, Masayuki back from MY
• 00:30 Rick, Masayuki to LVEA H2 enclosure turning on lights and fans, looking for parts
• 01:57 Rick, Masayuki back
• 03:22 Keita to LVEA to plug "thingy" into OMC electronics
• 03:33 Keita out
   

Jenne, Sheila, Hang

We worked on engaging the 90 MHz centering loop tonight.

We first locked the ifo in the DRMI_LOCKED stage using the old DC centering loop. Then we opened the centering loop and the src1 loops and adjust the phases for the 90 MHz WFS. The procedure was that we first  adjusted each seg. individually such that the length signal showed in I phase of each seg., to fix the relative phases between quadrants, then we drove a line by exciting one of the OM mirrors pitch (yaw) and rotated the overall phases of 4 segments together so that the pitch (yaw) signal showed up in I phases. By doing so we were able to switch to the 90 loop and lock the ifo stablely. We could also directly lock the ifo to DRMI_LOCKED stage with this 90 MHz loop.

The new phases of the 90 WFS are:

However, we somehow kept lossing lock at the DRMI_ON_POP stage with the 90 loop.

We then measured the sensing matrix at DRMI_LOCKED stage, and the results were

So the gain increased by ~20%-40% by using 90 instead of DC centering.

We thought this was the reason of lock loss, but after decreasing the gain digitally by the same amout, we still could not proceed beyond DRMI_ON_POP. The problem remains unknown.

Nutsinee, Aidan, Den

We have looked at the temperature data during O1 with the goal to estimate coupling of the temperature fluctuations to DARM. Coupling mechanisms include radiation pressure, thermal expansion of the optic and coating. We took numbers from Stefan Ballmer's thesis and Aidan's notes for these coupling mechanism. The total coupling coefficient is

DARM = 2 × 10^-10 RTN / f, where RTN is relative temperature noise.

We measured in-vac and in-air temperature noise using TCS sensors. Attached plot shows the result of the measurement. Above 10mHz sensors are limited by electronics noise. We used spectrum analyzer to avoid ADC noise but this did not help much, electronics noise of the readout circuits still limit the measurement at high frequencies.

In-vac sensors are limited by 1/f electronics noise. But for an upper limit we can assume temperature noise of 5 × 10^-1 (10^-4 / f) K/Hz^1/2 . This projects as 1/f² noise in DARM with ASD of 2 × 10^-20 m/Hz^1/2.

The actual coupling coefficient is probably lower since one might assume that in vacuum temperature fluctuations should be smaller compare to in-air fluctuations. On a 24 hour scale in-vac flucuations are a factor of 2 smaller, compared to in-air fluctuations. In-air sensors have less noise and at 1mHz measured fluctuations are a factor of 3 lower compared to in-vac measurement. Tacking this into account we can assume that vacuum sensors overestimates temperature fluctuations by a factor of 6 above 0.01mHz.

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

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.

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

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