We were seeing "frequency noise" become very apparent in DARM again.
("frequency noise" is in quotes because it is the underlying cause, but probably not the direct agent actually putting noise into DARM. That honor belongs to intensity noise.)
We've seen a continued plummet in the reference cavity transmission over the last week. We are now at the point where the ref cav transmission has dropped 47%. (Attachment 1)
Jason posted in alog 52882 about trying to fix up the alignment, with some success in recovering some transmitted power (seen in attachment 1 between -200000 and -100000 seconds ago), but not resolving the underlying issue.
Probably the best witness of FSS health is the IMC_REFL_DC signal (red trace, first and second attachment). When signal goes above ~10 mW, we are likely to be having frequency stabilization problems originating in the FSS, high high-frequency noise in DARM, and worse range.
I increased the FSS common gain from 23 to 25 dB
In the first PDF attachment, we see DARM and laser noise coherence at FSS gains of 23, 24, and 25.
After increasing from 23 to 24 dB, pretty much all the "frequency noise" we were seeing in DARM went away. There is no apparent change in laser noise coupling when increasing from 24 to 25 dB.
ASDs:
In the second PDF attachment, I plot DARM, CARM, and ISS secondloop ASDs before and after the FSS gain increase.
It's clear that the noise levels of all go down significantly.
I expected there to be significant coherence between the ISS and CARM, but this is not the case.
Coupling:
In the third PDF attachment, we see there is high coherence between the ISS secondloop and DARM with lower FSS gain, and much smaller coherence after the gain is increased by one dB.
In the fourth PDF attachment we see low coherence between DARM and CARM at all times, likely because the true frequency noise is drowned out by the high intensity noise apparent in DARM.
However, at no time is there coherence between CARM, IMC, or FSS error signals and the ISS loop. (fifth, sixth, seventh PDF attachments)
Jury is still out on why falling FSS gain causes high intensity noise. I would have thought this sort of intensity noise would be generated by the frequency noise incident on the IMC.
It is possible that this noise coupling is nonlinear, or I have looked at the incorrect witnesses.
With the FSS gain low, the ISS first loop is not performing well at all. The ISS second loop is able to compensate for the first loop's failure until about 700 Hz, where the true intensity noise begins to dominate over the second loop sensing noise. The second loop is doing the best it can under the circumstances, but cannot do the job of both loops. The below plots shows the ISS first loop sensors (out of loop = PDA, in-loop = PDB), and the ISS second loop sensors (out-of-loop = OUTER, in-loop = INNER) with the FSS gain at 23 dB and 24 dB.
Posting the ASDs I made trying to look into this problem. Probably the most interesting plot is PDF 1, which suggests ISS SECONDLOOP ERR1 DC coupling changed somehow. Overall, we see increased noise everywhere in the ISS and IMC and CARM error signals, and not much in the control signals as the high loop gains impress the high noise on the loop. Still not clear where the source of the noise is.
Out of observing for about a minute due to the squeezer. Otherwise have remained locked and in observing. No issues.
TITLE: 11/02 Eve Shift: 23:00-07:00 UTC (16:00-00:00 PST), all times posted in UTC
STATE of H1: Observing at 115Mpc
OUTGOING OPERATOR: Cheryl
CURRENT ENVIRONMENT:
SEI_CONF state: WINDY
Wind: 5mph Gusts, 4mph 5min avg
Primary useism: 0.01 μm/s
Secondary useism: 0.12 μm/s
QUICK SUMMARY: Late entry. Locked and in observing. No issues at present.
Plot of 11 hours attached, ITMX MODE13 gain was 0, damping gain first set to +5, then +10, and left at +10. In the past the gain has been as high as +25 with success. MODE13 is at 998.08Hz, and MODE19 is at 998.02Hz.
TITLE: 11/02 Day Shift: 15:00-23:00 UTC (08:00-16:00 PST), all times posted in UTC
STATE of H1: Observing at 115Mpc
INCOMING OPERATOR: Patrick
SHIFT SUMMARY: H1 locked in NLN all day, SQZ restored, noise from 2 sources found, mitigated, H1 range increased
LOG:
Craig, Robert, Cao, Dan
We came in today to pull off all the data we had on the phase camera as it'd been switched off yesterday. Everything but the CMOS camera on ISCT1 was switched off. When logging in to the computer controlling the connection to the camera to get the data, the service restarts the camera connection which toggled the internal fan. When the connection opened I just happened to notice that the scattering appeared in DARM. This was happening ~2700s looking back through the POPX DC channels. We had told the camera to always keep the fan off, however it seems to have a feature that will forcibly turn it on if the sensor gets hot to stop any damage from ocurring. Running the camera for multiple days outside of ISCT1 we had never noticed it turning on, but the tables having no substantial air flow get warm enough for it to trigger it.
Dropping out of observe we checked it was the camera by stopping the PRC2 feedback and switching on the camera fan, we saw nothing. Robert wanted to see if it was the turbulence or the vibrations itself. We went out and blocked the fan vents and switched the fan on and off (1256770963 for 60s). The block removed all the DARM scattering shelves we were seeing so it was indeed the turbulence. The CMOS camera is now unplugged.
Keita approved two Corrective Maintenance activities proposed by Craig and DanB, so H1 is out of Observe, still locked in NLN.
Activities are:
Prior to proposing these fixes, the periodic noise shelf was disrupted while H1 was in Observe, starting around 1256768150.
Locked mostly in Observe, some SQZ intervention needed, delay of 25 minutes after second intervention before H1 range increased
Current Acctivities/Events:
TITLE: 11/02 Day Shift: 15:00-23:00 UTC (08:00-16:00 PST), all times posted in UTC
STATE of H1: Observing at 102Mpc
OUTGOING OPERATOR: Jeff
CURRENT ENVIRONMENT:
SEI_CONF state: WINDY
Wind: 6mph Gusts, 5mph 5min avg
Primary useism: 0.02 μm/s
Secondary useism: 0.12 μm/s
QUICK SUMMARY: Locked for almost 10 hours, it looks like we lost SQZ
All good so far. The IFO has been locked and observing for the past 5 hours. The current range is 112.7Mpc. Environmental conditions are favorable. No issues of problems to report.
TITLE: 11/01 Eve Shift: 23:00-07:00 UTC (16:00-00:00 PST), all times posted in UTC STATE of H1: Observing at 113Mpc INCOMING OPERATOR: Jeff SHIFT SUMMARY: One lock loss, no immediately apparent cause. Only required intervention was to adjust ETMX, TMSX and ETMY for LOCKING_ARMS_GREEN. LOG: 23:37 UTC Kyle, Robert, Chandra to LVEA to adjust pressure on gate valves 23:40 UTC Dropped out of observing. Changed observatory mode to preventative maintenance. 23:44 UTC Sheila and Keita changing FSS fast gain 00:07 UTC Robert, Chandra back 00:12 UTC Back to observing 00:46 UTC Lock loss Waited for 5 minutes for green arms to lock. Neither arm locked on its own. Flashes are around .4. Set both arms to UNLOCKED. Moved ETMX and TMSX. The starting values were: ETMX: 64.4 P, -132.5 Y TMSX: -84.2 P, -50.6 Y I lost the ending values when I set the arm to ETM_TMS_WFS_OFFLOADED. Moved only ETMY: 130.5 P. -136.7 Y -> 132.1 P, -137.1 Y Set Y arm to ETM_TMS_WFS_OFFLOADED. Both arms locked. FIND_IR appears to be failing, taking a really long time with no flashes. Lock loss waiting for FIND_IR Both arms locked on green on their own FIND_IR worked this time Green arms still appear locked even after going through ARMS_OFF_RESONANCE. Can't remember if that is normal. DRMI failed and it automatically went to PRMI. PRMI locked very poorly, but ASC fixed it. DRMI locked. 06:10 UTC NLN 06:13 UTC Observing
I'm just following up on what patrick logged here about th eneed to intervene in x arm alignment. I think that there is probably a typo above and the lockloss that Patrick is talking about is at 4:46 UTC.
Starts at the time of the lockloss (ALS_XARM state goes from 100 (shuttered) to the various locking states). You can see that the optics get kicked when the ASC control signals turn off, and that this is a DC alignment shift for them, bringing the arm closer to the alignment at which it can lock.
The changes from the free swining alignment after the lock to the alignment after the arm is locked and WFS engaged:
| PIT | YAW | |
| ITM | not much change | not much |
| ETM | +1.5 | not much |
| TMS | +1.8 | +1.4 |
The sliders are in pretty good agreement with the witness sensors about these shifts. I've added the ndscope that I used to make this, and a similar one for the Y arm, to the ALS overview screen, to help make it easier for operators to find and report this kind of information.
06:13 UTC Accepted attached SDF differences.
The first plot on the first page of the figure shows that the seismic signal from the instrument air compressor was reduced today by seismic isolation. But the huge DARM noise, with close to the same periodicity, is still occurring. Our manipulation of the on and off pressures for the compressor, and the new GV5 and 7 pressure settings, see previous entries, did not seem to affect the DARM noise – see end of first page time series. This and the observation that the noise does not occur at exactly the same part of the compressor cycle every time, is evidence that they are causally unrelated, though they have similar periods. On the other hand, the second plot seems to show that the period of the DARM noise changed with the period of the compressor a couple of days ago…. Chandra, Kyle and I were in the LVEA from UTC 23:40 to 00:06 on Nov 1 and 2.
Associated with FRS Ticket 13809.
Have remained locked. Briefly out of observing for noise investigations. No issues to report.
Operators Note:
As part of an ongoing investigation that is looking at correlated IFO noise to the pressure cycling? value? of the instrument air, the pressure band (High - Low) has been changed. Expect PT199 "LOW" alarms all weekend. Please pass this on to the incoming operator.
Can we change the thresholds on the control room alarm handler? If so, what would be good upper and lower limits?
You can reduce the lower threshold to 54 psi until we can make adjustment next week. 50 psi is when the pneumatic GVs start to sag.
Temporarily changed low alarm limit through EPICS: vacuum@vacuum1:~$ caput H0:VAC-MR_INSTAIR_PT199_PRESS_PSIG.LOW 54 Old : H0:VAC-MR_INSTAIR_PT199_PRESS_PSIG.LOW 59 New : H0:VAC-MR_INSTAIR_PT199_PRESS_PSIG.LOW 59 vacuum@vacuum1:~$ caget H0:VAC-MR_INSTAIR_PT199_PRESS_PSIG.LOW H0:VAC-MR_INSTAIR_PT199_PRESS_PSIG.LOW 54
TITLE: 10/31 Day Shift: 15:00-23:00 UTC (08:00-16:00 PST), all times posted in UTC
STATE of H1: Planned Engineering
INCOMING OPERATOR: Niko
SHIFT SUMMARY: commissioning, restoring H1 for O3b, as of 23:29UTC, taking an hour break for multiple pre-aproved activities, relocking starts at 0:30UTC Nov. 1
LOG:
CORRECTION:
L. Sun
The hourly C01 uncertainty budget plots and txt files (0611-1001) are stored here: https://ldas-jobs.ligo.caltech.edu/~ling.sun/Calibration/Uncertainty/O3C01_190611-191001/LHO/
(Note: the dir for batch 1 is kept as O3C01)
Since LHO has an IFO change on 0828 (SRC offset), the results are shown in separate chunks.
The scripts live in:
/home/ling.sun/Calibration/offlineJobs/run_C01_LHO_chunk2.py
/home/ling.sun/Calibration/offlineJobs/run_C01_LHO_chunk3.py
The submission files are:
/home/ling.sun/Calibration/offlineJobs/sub_C01_LHO_chunk2.sub
/home/ling.sun/Calibration/offlineJobs/sub_C01_LHO_chunk3.sub
------------------
LHO Chunk 2
------------------
1244307456 == Jun 11 2019 16:57:18 UTC
to
1251071403 == Aug 28 2019 23:49:45 UTC
(num of jobs: 1879)
------------------
LHO Chunk 3
------------------
1251071403 == Aug 28 2019 23:49:45 UTC
to
1253982208 == Oct 01 2019 16:23:10 UTC
(num of jobs: 809)
Results cover ~77% of the total number of hours. The current results are based on an overall PCAL uncertainty of 0.79%. The percentile and max bound plots are attached. They are generated using the following commands:
python RRNomStat.py --statDir=/home/ling.sun/public_html/Calibration/Uncertainty/O3C01_190611-191001/LHO/ --IFO=LHO --nameTag=O3_C01_190611-190828 --gpsStart=1244307450 --gpsEnd=1251071403
python RRNomStat.py --statDir=/home/ling.sun/public_html/Calibration/Uncertainty/O3C01_190611-191001/LHO/ --IFO=LHO --nameTag=O3_C01_190828-191001 --gpsStart=1251071402
The attachment demonstrates that the variation of the envelopes is negligible.
- White dashed curve: median of the median values from all the hourly data
- White solid curve: median of the +/- 1 sigma values from all the hourly data
- Color: percentiles of the +/- 1 sigma curves (i.e., variation of the envelope)
The PCAL corrections for O3a chunk 2+3 (alog LHO 52837) are applied in RRNom.py. The scripts and commands above remain the same.
The hourly uncertainty results are updated in the same dir. The new percentile plots are attached.