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.
The basis for the temperature fluctuation transfer function is outlined in the attached calculation.
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 |
Why are the signals from PR3 so weak and weaker than those from PR2 ? Maybe typos ?
Typo fixed
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
DAY Checksheet Notes:
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
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.
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.
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.
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
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.
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.
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.
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.
Den, which +15V signal is this that you measured?
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.
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.
Tracking Names: SM1 = IM1, PMMT1 (MMT1) = IM2, PMMT2 (MMT2) = IM3, SM2 = IM4
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
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.
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.
This line does not appear in the IOP channels for the end station QPDs. (2 W, dc readout)
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.