Now we have a faster DHARD yaw loop during CARM offset reduction, analogous to the fast DHARD pitch loop that Elli, Ryan and I commissioned last week (LHO#16544, LHO#16520). Injecting a step response at the error point shows a loop time constant of a few seconds.
With the loop open, I injected ASC-DHARD_Y_EXC with bandlimited noise from 0 to 3 Hz and measured the transfer funcion ASC-DHARD_Y_EXC → ASC-DHARD_Y_IN1. Since we have no yaw oplev damping on the ETMs, the optomechanical plant has two moderately high-Q resonances, which I estimate to be at 0.6 Hz with a Q of 18, and at 1.36 Hz with a Q of 45.
The attachment shows the plant measurement, along with the analytical system used for the plant inversion. Here I've intentionally lowed the second Q from 45 to 20, to avoid excessive ringing in the filter step response.
Just to be clear, these are not truly DHARD loops, since we're not actuating on the ITMs. Really it's just the differential angular motion of the ETMs.
Both DHARD loops are meant to be engaged with FM3, FM4 (giving a 1/f shape overall), FM8 (plant inversion plus high-frequency rolloff), and F10 (30 Hz elliptic low-pass). For pitch, gain is 16 ct/ct, and for yaw, gain is 200 ct/ct. In contrast to what I said in LHO#16520, nothing should be engaged in the ETM L2 lock filter modules.
Additionally, these loops currently require us to disable the M0 and L1 pitch/yaw lock filter banks on the ETM suspensions. This prevents the DHARD control signals from being offloaded to the upper stages.
model restarts logged for Sat 07/Feb/2015
2015_02_07 10:29 h1fw1
Unexpected restart. First fw restart since 03Feb (4.8days)
During the early steps of the CARM offset reduction last night it was observed that the ALS DIFF bandwidth was a little low, causing lock losses around the arm power where the transition to the tranmsission QPD sums takes place. To continue locking work the gain was doubled, but it was noted that this should not really change. Today, the ALS diff loop was re-measured, and found to be close to the expected value (under nominal gain settings), so its not clear what happened. At the same time, it was noticed that the length control was ringing at 1.56 Hz, which is sometimes associated with mismatched L1/L3 crossover. A quick measurement of this did not reveal any problem, and somewhat incidentially it was discovered that the alignment of the reaction chain has a significant effect on the length control at this frequency (the reaction chain had previously been adjusted for a different test), potentially due to angular cross-coupling. This should be investigated further.
Attached shows the oplev spectra, showing the 1.56Hz oscillation. I have also attached a screen shot showing the green x transmission (blue line), which is clearly oscillation to begin with, and then we re-align the reaction mass and this oscillation goes away, but we see a drift in alignment of the test mass.
A core switch in the OSB hung up over night. A reboot of the offending switch returned service to wired network, wireless, and phones at approximately 12:35PM PT. After the reboot, the firmware was upgraded to the latest release of the same major version due to multiple candidate causes of the issue we are seeing having been fixed.
The HWS on ITMX was running during last night's 1 hour lock. It saw a lens of ~6 micro-diopters (double-passed) form while the IFO was locked. The transient data is in the attached plot.
HWSY is not currently operational.
At the moment, I can't reliably estimate the absorption coefficient, but the absorbed power is about 1.06 mW per micro-diopter (double-passed), so roughly 6mW of power was absorbed.
If I go with 2W requested from the PSL rotation stage and do the same calculation we did at LLO:
2W (input power) * 30 (recycling gain) * 0.5 (beam splitter) * 286 (arm cavity gain) = 8.6kW stored arm power,
which yields
I would definitely take this number with a healthy grain of salt ... I'd still like to run some diagnostics on the ITMX HWS following yesterday's code update.
(Also, the data in the attached plot was rescaled in dataviewer, by 0.00326, to what is currently displayed to account for the fact that the HWS magnification was set to 1x at the time of this measurement, rather than 17.5x. The spherical power scales as 1/M^2 = 1/17.5^2 = 0.00326).
I've added this data to the TCS actuator couplings document on the DCC.
I've calculated the stored arm power from last night's lock as 11.5kW (As calculated in post 16579).
Using this number instead of 8.6kW approximated from livingston's numbers, this brings the estimate of absorption in the ITMX coating to 520 parts per billion.
This came up a couple of times this week, and Aidan and I just figured out how to do it, so for those that don't already know:
You can scale data in plotted in dataviewer by going to menu: Data->Transformations->Geometric transforms...
Transformations are cumulative. In other words, if I select "Scale = 10.0" and hit "Accept" twice, the data is scaled by 100.
I ran the ITM RHs for twenty minutes at 2W total input power this morning to measure the resistance of the segements and the change in resistance vs time due to an increase in temperature of them. This is to confirm they are working as part of the acceptance testing.
The resistance of the RH segments was around the nominal value of 42 Ohms:
The relative resistance vs time is shown in the attached plot. There is some (~20%) variation between the different segements.
model restarts logged for Fri 06/Feb/2015
2015_02_06 01:15 h1nds1
unexpected restart of h1nds1, most probably caused by data request overload (this is the default nds). Frame writers continue to be stable (3.8 days)
Alastair, Aidan, Jamie, Dave:
To support this weekend's TCS guardian development, I have temporarily added two new EPICS channels to the alarm manager IOC on script0. Their permanent location will most probably be the h1tcscs front end model, we will schedule this install for Tuesday maintenance. The channels are:
Ryan, Lisa, Evan
We have been locked for more than 1 hour with CARM controlled by digital REFL9I (at 0 pm offset) and DARM controlled by ASAIR 45Q. The power buildup is 1100 times the single-arm buildup, giving an interferometer recycling gain of 33 W/W. The REFL_A_LF power is 1.35 ct, compared to 21 ct with the arms held off resonance. This means the interferometer visibility is about 94%.
The new element today was a higher-bandwidth DHARD pitch WFS loop. The loop time constant is a few seconds or so, and is fast enough to suppress the appearance of the microseism in ASAIR 45Q. Next steps are probably to close the analogous yaw loop. Ryan had to adjust ETM differential yaw by hand several times to keep the AS beam reasonably round. Also, Ryan had to add a DC-coupled oplev servo to ETMX L1 pitch in order to keep the optic from drifting.
Details will be posted later.
These are the plots with the transition to REFL 9I, and a trend of the 1 hour long lock (starting around Feb 7, 12.11 UTC). In the first plot, the power build up increase around 400 sec is due to the improvement of differential YAW alignment that Ryan did by hand. The lock loss happened right after a DARM loop measurement. The high wind of the afternoon was totally gone by the time we came back to the site after dinner.
Congratulations! and thanks for staying up all night once again.
Welcome news. Great job. Congratulations to everyone who has helped bring this about.
Awesome! Very pleased to see this result. Nice work everyone!
Congratulations from Delhi! Nice to see the stability of lock at this early stage. The entire team deserves credit for undaunted persistence through all the tricky issues. Y'all rock.
In my previous trends I plotted the wrong POP18 signal (before demodulation), here is the correct signal representative of the sideband power. Once the arm cavity power increases from ~ 500 to ~1000 single arm power, the sideband power decreases by ~20% in about 10 min.
If you are wondering what to do when you try to open Firefox and you get an error message which tells you "firefox is already running", but it is not, and you don't want to reboot your machine, here is the solution (from Dave & Jonathan): - cd /ligo/home/lisa.barsotti/.mozilla/firefox - rm lock - rm .parentlock
rm ~/.mozilla/firefox/{,.parent}lock
To help with this on the common login accounts (ops, controls), at LLO in eLIGO, we created a script to invoke Firefox to uses a per-workstation profile and deletes the lock files before starting, This works fine as long as you train users to invoke the script (on the desktop) instead of from the Gnome menu (or directly at the command line). The move to per-user logins has eased this problem a lot.