Displaying reports 61241-61260 of 86301.Go to page Start 3059 3060 3061 3062 3063 3064 3065 3066 3067 End
Reports until 19:27, Thursday 25 February 2016
H1 ISC (PEM)
denis.martynov@LIGO.ORG - posted 19:27, Thursday 25 February 2016 - last comment - 06:40, Friday 26 February 2016(25737)
ambient temperature coupling to DARM

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/Hz1/2 . This projects as 1/f2 noise in DARM with ASD of 2 × 10-20 m/Hz1/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.

Non-image files attached to this report
Comments related to this report
aidan.brooks@LIGO.ORG - 06:40, Friday 26 February 2016 (25749)

The basis for the temperature fluctuation transfer function is outlined in the attached calculation.

Non-image files attached to this comment
H1 ISC (ISC)
hang.yu@LIGO.ORG - posted 17:19, Thursday 25 February 2016 - last comment - 19:54, Thursday 25 February 2016(25735)
sensing matrix with DRMI locked only

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

Optic WFS ct/ct W/rad
PR3 REFL_9A_I -3.2e-1 -6.1e+1
PR3 REFL_45A_I 1.2e-1 2.3e+1
PR3 REFL_9B_I -2.2e-1 -4.1e+1
PR3 REFL_45B_I 9.5e-2 1.8e+1
PR2 REFL_9A_I -1.1e0 -2.1e+2
PR2 REFL_45A_I 4.8e-1 9.1e+1
PR2 REFL_9B_I -7.8e-1 -1.5e+2
PR2 REFL_45B_I 3.4e-1 6.5e+1
IM4 REFL_9A_I -1.5e-1 -2.8e+1
IM4 REFL_45A_I 4.8e-2 9.1e0
IM4 REFL_9B_I 9.5e-2 1.8e+1
IM4 REFL_45B_I -4.6e-2 -8.6e0
SR3 AS_36A_I -1.7e-2 -1.6e0
SR3 AS_36A_I -1.1e-2 -1.1e0
Comments related to this report
kiwamu.izumi@LIGO.ORG - 18:54, Thursday 25 February 2016 (25736)

Why are the signals from PR3 so weak and weaker than those from PR2 ? Maybe typos ?

hang.yu@LIGO.ORG - 19:54, Thursday 25 February 2016 (25738)

Typo fixed

H1 OpsInfo
thomas.shaffer@LIGO.ORG - posted 17:10, Thursday 25 February 2016 (25732)
ISI blends changed at ETMs back to Quite_90's

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

LHO VE
kyle.ryan@LIGO.ORG - posted 16:19, Thursday 25 February 2016 (25730)
Cut out shorted section of X2-8 beam tube ion pump HV cable
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.  
LHO General
corey.gray@LIGO.ORG - posted 16:11, Thursday 25 February 2016 (25711)
Ops Summary

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

DAY Checksheet Notes:

H1 CDS (GRD)
david.barker@LIGO.ORG - posted 16:09, Thursday 25 February 2016 - last comment - 20:28, Thursday 25 February 2016(25729)
script to show which guardian nodes are using a specified file

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
 

Comments related to this report
jameson.rollins@LIGO.ORG - 20:28, Thursday 25 February 2016 (25740)

You can of course always just use guardutil directly to get this information as well:

jameson.rollins@operator1:~ 0$ guardutil files SUS_BS
/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/sustools2.py
/opt/rtcds/userapps/release/sus/common/guardian/burt.py
/opt/rtcds/userapps/release/sus/h1/guardian/SUS.py
jameson.rollins@operator1:~ 0$

This is probably preferable, since it's always up-to-date.

H1 SYS
daniel.sigg@LIGO.ORG - posted 15:40, Thursday 25 February 2016 (25728)
Commissioning Schedule

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

H1 SEI
jim.warner@LIGO.ORG - posted 12:40, Thursday 25 February 2016 (25724)
ETMY buried STS sensor correction

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.

Images attached to this report
H1 CDS
david.barker@LIGO.ORG - posted 11:35, Thursday 25 February 2016 - last comment - 14:37, Thursday 25 February 2016(25719)
h1boot problems, all front end computers have locked up

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.

Non-image files attached to this report
Comments related to this report
david.barker@LIGO.ORG - 12:01, Thursday 25 February 2016 (25720)

h1boot has gone 230 days without a file system check. An fsck on the /opt/rtcds (800GB) file system is in progress, will take almost an hour to complete.

david.barker@LIGO.ORG - 13:25, Thursday 25 February 2016 (25726)

h1boot completed its fsck and started running. Looks like all the front end real-time cores ran the entire time. This raises an interesting problem, should they run when there is no operator/guardian control of them? Did guardian keep trying to control the system and, with no feed-back, continue to 'push' the system. 

The DAQ data continued to flow for the entire time. We see evidence of some channels glitching when the front end controls was recovered.

We will test this scenario further to see if a solution is needed.

Downtime was 11:10 - 12:40 PST

corey.gray@LIGO.ORG - 14:37, Thursday 25 February 2016 (25727)

Filed an FRS for this since we lost 1.5hrs of commissioning time.  This is FRS #4429.  

Note:  it wasn't clear what units of time to enter for "Orig. Est", and I entered 90 (as in minutes), but this turned out to be an entry of 90hrs!  I believe it has been corrected to 1.5hrs.

H1 TCS
eleanor.king@LIGO.ORG - posted 11:09, Thursday 25 February 2016 (25718)
Removal of polarization sensors from HWSX Path

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.

Images attached to this report
H1 ISC
denis.martynov@LIGO.ORG - posted 03:36, Thursday 25 February 2016 - last comment - 23:06, Thursday 25 February 2016(25706)
100Hz noise investigations

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.

Non-image files attached to this report
Comments related to this report
denis.martynov@LIGO.ORG - 16:45, Thursday 25 February 2016 (25731)

We have also measured coherence between DARM and voltage noise of +15V signal going into the vacuum. Noise level is 2uV/sqHz at 100Hz and coherence is <10-3. This noise is insignificant for the current sensitivity.

rich.abbott@LIGO.ORG - 17:13, Thursday 25 February 2016 (25734)ISC
Den, which +15V signal is this that you measured?
denis.martynov@LIGO.ORG - 23:06, Thursday 25 February 2016 (25745)

Rich, we have measured the noise on pin 6 (+15V head 1, D1300502). This noise is highly coherent with noise on pin 2 (+15V on head 2) and partially coherent (0.4) with noise on pin 7 and 3 (-15V, head 1 and 2). For this reason, we did not measure DARM coherence with other pins.

H1 AOS (SUS, SYS)
richard.mccarthy@LIGO.ORG - posted 15:55, Tuesday 23 February 2016 - last comment - 11:25, Friday 26 February 2016(25685)
Add Capacitors to Ham2 SUS SAT Amp
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.


Comments related to this report
cheryl.vorvick@LIGO.ORG - 12:39, Thursday 25 February 2016 (25723)IOO

Tracking Names: SM1 = IM1, PMMT1 (MMT1) = IM2, PMMT2 (MMT2) = IM3, SM2 = IM4

edmond.merilh@LIGO.ORG - 11:25, Friday 26 February 2016 (25755)

UPDATE:

As of today all HAM3, HAM4 and EX Amps have been modified. HAM2 amps will have to be re-addressed due to an error in installation of the mod. 3IFO boxes are in process.

- Ed

H1 ISC
evan.hall@LIGO.ORG - posted 03:51, Tuesday 23 February 2016 - last comment - 13:21, Thursday 25 February 2016(25673)
QPD offsets, 9 MHz phase noise

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−6 mA/Hz above 100 Hz.

Images attached to this report
Comments related to this report
evan.hall@LIGO.ORG - 22:36, Tuesday 23 February 2016 (25692)

Also, twice last night (while locked on the IFR) we were battling a 900 Hz line in DARM that increased over the duration of the lock, and eventually caused EY to saturate.

We suspected PI, but this line was also present at 900 Hz in the DCPD IOP channels. So it is not folding around the 8 kHz Nyquist of the digital downsampling.

evan.hall@LIGO.ORG - 18:46, Wednesday 24 February 2016 (25702)

This line does not appear in the IOP channels for the end station QPDs. (2 W, dc readout)

Images attached to this comment
evan.hall@LIGO.ORG - 13:21, Thursday 25 February 2016 (25725)

It's the third harmonic of the beamsplitter violin mode. Den added a stopband filter to the BS M2 length drive, and the line went down.

Unclear why this had not been a problem before.

Displaying reports 61241-61260 of 86301.Go to page Start 3059 3060 3061 3062 3063 3064 3065 3066 3067 End