We fixed Daniel's channel naming problem with the ALS addition to the ASC, actually the problem went away. So I restarted the new h1asc model at 12:41 and restarted the DAQ at 12:44 to install the new model and DAQ channels associated with it.
Noticed some fluid in the bottom of the SW SEI Pier at the BS. Cleaned up the mess in the Pier yesterday and this morning found fresh fluid. Climbed up to Housing and found the Vertical Actuator Fluid Catch overflowing. I can see drips coming off the Parker Valve. Can't tell if it is coming out of the Valve itself or just the Valve/Manifold seal. It looks like it could be the former. I'd like to clean up the catch and tighten the valve to manifold screws and see what it looks like in a couple days.
This may require a valve change which would briefly glitch the fluid pressures twice and in between have the BS HEPI uncontrolled for a few hours as we bleed after the valve change.
"Noisy" scroll pump located outside of building near LN2 dewar
Going to HAM 4 to prepare SR2 Pre-installation Plate (Cookie cutter) and hardware– Jeff B.
Starting Stiffener rings and o ring protectors installation on HAM4 - Apollo
Work completed!
(Alexa, Daniel, Keita)
After changing the RF frequency to 24.389319 MHz and adjusting the delay line phase to 257 steps, we took open loop transfer functions of the PDH loop.
PLL Board Settings:
PDH Board Settings (Nominal):
EX_PDH_OpenLoopTF_phase/mag_Nom.txt corresponds to the data collected with the above nominal settings.
EX_PDH_OpenLoopTF_phase/mah_Boost2On.txt corresponds to the data collected wiith the above settings with the addition of Boost 2 ON
EX_PDH_OpenLoopTF_phase/mag_6dBFast.txt corresponds to the data collected with the same as the nominal settings with the addition of 6dB gain in the fast path
Heading into the LVEA to check a dust monitor (location #9) which has lost communication - Patrick
Work completed!
Moving, cleaning, and organizing elements for SR2 installation (HAM4 LVEA) - Jeff.B/Jodi
PSL Check: Laser Status: SysStat is good Output power is 29.3 W (should be around 30 W) FRONTEND WATCH is Active PMC: It has been locked 2 day, 16 hr 11 minutes (should be days/weeks) Reflected power is 1.1 Watts and PowerSum = 12.16 Watts. (Reflected Power should be <= 10% of PowerSum) FSS: It has been locked for 11 h and 22 min (should be days/weeks) Threshold on transmitted photo-detector PD = 0.94V (should be 0.9V) ISS: The diffracted power is around 5.4% (should be 5-15%) Last saturation event was 11 h and 28 minutes ago (should be days/weeks)
Disconnected temporary cabling that were used for testing of SR2 next to HAM4. Connected permanent cables to satellite units in SUS H1-R3. Permanent cabling were already pulled and connected at chamber side: Cables were connected at chamber side according to D1101814. D6-1C1: Cable SUS_HAM4-32 SR2 BOTTOM D6-1C2: Cable SUS_HAM4-31 SR2 MIDDLE D6-2C1: Cable SUS_HAM4-10 SR2 TOP D6-2C2: Cable SUS_HAM4-11 SR2 RIGHT/LEFT Filiberto Clara
Work completed!
I saw a big RAM offset in REFLAIR_RF45 and didn't like it. So I changed the modulation frequency to 9099170 Hz where the RAM offset became zero. This frequency is consisent to what Alexa got (see alog 9679) in her IMC length measurement.
Before this change, the mod frequency was at 9099471 Hz and the RAM offset was 3000 counts in REFLAIR_RF45_Q with its whitening gain at 21 dB and with PRM aligned.
We have seen that the arm cavity can sometimes lock quite stably (for example the 6 hours starting UTC Jan 24 1:40) alog 9518, and that sometimes it mode hops constantly (alog 9653). I used the scripts Keita used in alof 9653 to make a comparision of the two times. For the stable time I am using 20 minutes of data starting at 1/24/14 1:40 UTC, for a bit less stable time I am using 1hr 20min starting at 1/24/14 6:30 UTC and a slightly less stable time of Keita's plots use 5 minutes of data.
First histograms of the transmitted counts: the stable time, the somewhat less stable time, and Kieta's data:
On the 24 (first two plots) the SHG was off, so there is no 850-900 count offset on COMM_A_LF that you see in Keita's data from this morning. The transmitted power this morning was only 80% of what it was durring the stable times, even when locked to the 00 mode (if you take into account the offset from the SHG).
You can see that there was mode hopping in Keita's data. Although it seems like the "less stable" (middle) histogram has a bimodal distribution, I don't think that the small hump aroung 550 counts is due to mode hopping because it has about 80% of the power that the 00 mode has. The mode matching should not have changed between the 24th and today, and we know we didn't have more than about 30% of our power in mode mismatch (alog 9518). These are most likely drops in the transmitted 00 mode power due to alignment excursions.
Here are plots of where the PIT oplevs spent most of their time, made using Ketia's script. This morning there was about 2-3 times more pitch motion in the ETM than on the 24th (see Jeff's alog).
These are plots made using Keita's script, of the transmitted power for different oplev positions. (I didn't use the threshold to distinuish mode hopping since there isn't really mode hopping in the first two plots, and I used a smaller bin spacing of 0.1urad) In the first two plots, we seem to be exploring a plateu where the transmitted power doesn't change dramatically over 1urad in ETM pitch and 1/2 urad in ITM pitch. This morning though we were misaligned, and even with less optic motion we would have been right on the edge of the mode hopping. It seems as though we can't rely on the dither alignment when we are this misalinged, and need to tune up the alignment by hand, probably by unlocking and watching the fringes.
The first two plots suggest we can stay locked to the zero zero mode with around 1 urad pp in the ETM, maybe more. The plot from this morning seems to show that while the optic motion was large, our main problem was a DC misalingment.
Aidan, Thomas, Eric G.
We installed the TCS HWS HAM4 optics this afternoon per D1201098. We've finished using that area and the chamber is covered again.
Full details tomorrow.
Here are the full details ...
We had to place ten optics/opto-mechanics assemblies. The D1201098 installation kit (cookie cuters) parts were placed to facilitate placement and alignment of optic assemblies. The assemblies were then bolted into position, summarized below:
Photos are attached below. Complete set is on ResourceSpace
We plan on installing the 4x 2" lens mounts and optics during the alignment of these optics or earlier.
(Correction Jan/31: Sheila's made a similar plot for a period (https://alog.ligo-wa.caltech.edu/aLOG/index.php?callRep=9691) where the cavity was locked all the time, and it seems like the plot presented here was sampling only a small edge of the 00 lock range.)
As of now, it seems like both ETM and ITM should be within 0.3 urad pk-pk from the optimal alignment to stay locked on 00 mode.
Plot 1: I took OL and green transmission data for 5 minutes when the cavity was going back and forth between 00 and 01 mostly without losing lock.
In the top panel, the transmission time series is actually the sum of the SHG and the transmission, but it's on 00 mode when it was 1400 counts, 01 when it was between 1000 and 1200 counts.
Plot 2: 2D color map of the above data.
X axis is ITM OL PIT, Y is ETM. I arbitrary set the threshold of 1300 counts for green transmission and subtracted that from the transmission data, and set the color map such that orange-red color is above 0 (i.e. locked to 00 mode), yellow-green is negative (01 mode).
Each cell is normalized by the number of data points in that cell. Blue means there's no data point in that cell.
Sorry that X and Y axis scaling is different. To aid your eyes, I put white and pink diagonal lines showing the direction of common (soft) and differential (hard) misalignment.
Plot 3: 2D plot of where the OLs were staying.
You cannot tell from plot 2 where the OL was staying the most, so here is the number of data points in each cell divided by the total number of data points. Adding everything on this map together you'll get 1.
On average EX=-28.12, IX=-6.28.
Conclusion:
Note that this is dependent on RF sideband frequency.
Note the bogus or inconsistent sign convention of OLs.
For ETM, when the optic tilts down (increase in PIT slider), OL PIT increases, while for ITM OL PIT decreases.
That's the reason why the hard (differential) mode is parallel to the line ETMX=ITMX.
In preparation for acceptance review of the ETMX quadruple suspension, I took a set of ASD of the osems in the local and euler basis. ETMX is in chamber, under vacuum and the ISI was in its level 1 isolated state (ST1 = T100mHz blend on X and Y, T750mHz for the other DOF, ST2 = 750mHz blend). Measurement was taken successively with suspension damping on and off.
The main resonnances of main and reaction chains are well damped for all degrees of freedom.
The minor things to notice are :
Damping for the vertical DOF of the reaction chain is not having much effect on the first resonnance (@~ 0.56Hz) (see p9 of 2nd pdf).
The upper left osem of L2 level has its noise floor above the usual sensor noise we see on other osems (see p34 of 3rd pdf).
Otherwise everything else looks good.
The results attached are :
1) Comparison damping off/on for the top mass sensors of the main chain
2) Same for the reaction chain
3) Comparison between different quads (H1 ETMX H1 ETMY L1 ITMY L1 ITMX) of all osem sensors in local and euler basis.
A safe snapshot will need to be taken when possible since I found the normV/R/P filters disengaged, and a gain of 10 in the L2L L1 sensalign matrix. I also corrected the channel list of the plotquadspectra.m since it was requesting two times the L1_WIT_L channels. The modified script was commited to the svn
EULER DOF H1:SUS−ETMX_L1_WIT_L_DQ (pg 29 of third attachment) also shows excess noise, which is due to the factor of 10 in the sensalign matrix (was corrected this week and snapshot was saved)
I cleaned up the Catch Pan and checked the Valve to Manifold screws. They were plenty tight. When I look again (Monday, tomorrow?) I'll be pretty confident about from whence the leak comes but I fairly sure now that is is from the Valve itself.