h1fw0 is now stable after the yesterday's configuration change (it is not writing commissioning frames, only science frames). The plot below shows the restarts for h1fw1 (green) and h1fw0 (red) for Friday and today. The blue square marks the time h1fw0 stopped writing commissioning frames. We will run in this configuration over the weekend to get more statistics.
Retook the SRCFF measurement. the data is in /ligo/home/controls/sballmer/20150724/FF SrclFF20150724.xml & SRC_FFpath20150724.xml (1st measurement) SrclFF20150724v2.xml & SRC_FFpath20150724v2.xml (2nd measurement) An initial fit produced a filter (FF4) that improved the performance at high frequency, but moo0.5 (the old moo, adjusted by a gain of 0.5) was still better at low frequencies. More fitting will be done during daytime. For now, guardian uses moo0.5.
Hannah, Evan, Stefan The slightly strange sensing matrix from alog 19769 did not seem repeatable today, so we switched ASC_AS_A_RF36_I_YAW back to the settings from alog 19572: H1:ASC-AS_A_RF36_I_MTRX_2_1 0 H1:ASC-AS_A_RF36_I_MTRX_2_2 0 H1:ASC-AS_A_RF36_I_MTRX_2_3 -2 H1:ASC-AS_A_RF36_I_MTRX_2_4 2 Instead we added some of H1:ASC-AS_B_RF36_I_YAW (with the same sign as in DRMI) to the input matrix. There wasn't much signal there, but the right kind of RF offset. The new sensing matrix is asc_intrix_yaw['SRC1', 'AS_B_RF36_I'] = 1.0 asc_intrix_yaw['SRC1', 'AS_B_RF36_Q'] = 0.0 asc_intrix_yaw['SRC1', 'AS_A_RF36_I'] =-3.0 asc_intrix_yaw['SRC1', 'AS_A_RF36_Q'] = 0.0 This at least also makes some theoretical sense, so hopefully this will hold up longer.
Stefan, Evan
We temporarily switched back to the IFR as a sideband generation source, and then used it to drive the sidebands in frequency and amplitude. Then we looked at the coupling in OMC DCPD sum.
We ran the spare LSC DAC channel (LSC-EXTRA_AO_2) into ISC patch cable R1 #11-4, which goes to ISC C4 #2-4. Then we sent this into the IFR's external modulation input.
First, we did the amplitude measurement. The IFR was set to dc-coupled AM with a nominal deviation of 10%. We drove 25 mV out of the DAC and watched the response in the OMC DCPD sum. The observed AM coupling is roughly flat from 300 Hz to 5 kHz, with a level of about 0.01 mA/RIN.
Next, we did the phase measurement. The IFR was set to dc-coupled FM with a nominal deviation of 1 Hz. We drove 100 mV out of the DAC and watched the response in the OMC DCPD sum. The observed FM coupling is roughly flat from from 300 Hz to 5 kHz, with a level of about 2×10−5 mA/Hz.
[An aside about the IFR actuation calibration: The IFR is designed so that in order to get 10% peak RIN, you must supply 1 V rms at the modulation port, which 1.41 V peak. Stupid stupid stupid. Anyway, I verified with an oscilloscope that the actuation coefficient was 0.068 RIN/V, which is close enough to the expected 0.071 RIN/V.
The same nuttiness applies to the frequency calibration: to get 10 Hz peak deviation, you must supply 1.41 V peak. However, Stefan and I measured this coefficient and found that it is really 3 Hz/V rather than 7.1 Hz/V. Measurement as follows:
We can use the specified performance of the OCXO to compute the resulting oscillator AM and FM noise appearing in DARM. These couplings seem to be safely below the level of OMC DCPD sum, which is usually slightly less than 10−7 mA/rtHz above 500 Hz.
Since the specs are only given once every decade, any our measurements only have good coherence above 300 Hz and below 7 kHz, only the 1 kHz spec is really trustable here. I've tried to guess at a reasonable coupling level at 100 Hz and 10 kHz (based only on the TFs given above), but we should try to get better measurements before really trusting these numbers.
Amplitude noise:
Freq. [kHz] | RIN [dBc/Hz] | RAM [1/rtHz] | Coupling [mA/RAM] | Noise in OMC sum [mA/rtHz] |
0.1 | −150 | 4.5×10−8 | ?0.02 | ?8.9×10−10 |
1 | −150 | 4.5×10−8 | 0.011 | 4.9×10−10 |
10 | −150 | 4.5×10−8 | ?0.02 | ?8.9×10−10 |
[In the above alog, I haven't distinguished between RIN and RAM. The TF takes relative fluctuation of the sideband amplitude (not the sideband power) to photocurrent.]
Frequency noise:
Freq. [kHz] | Phase noise [dBc/Hz] | Phase noise [rad/rtHz] | Frequency noise [Hz/rtHz] | Coupling [mA/Hz] | Noise in OMC sum [mA/rtHz] |
0.1 | −140 | 1.4×10−7 | 1.4×10−5 | ?2×10−5 | ?2.8×10−10 |
1 | −160 | 1.4×10−8 | 1.4×10−5 | 2×10−5 | 2.8×10−10 |
10 | −165 | 8.0×10−9 | 8.0×10−5 | ?2×10−5 | ?1.6×10−9 |
Alexa and Daniel have also taken phase noise spectra of the OCXO, so this can be used to give a better estimate of the frequency noise.
Evan, Stefan We kept having PREP_TR_CARM issues, and again tracked it down to moving dark offsets. now the guardian measures the offsets at the beginning of PREP_TR_CARM. Let's see weather this finally eliminates those PREP_TR_CARM issues.
Morning Meeting:
- Richard, cosmic ray work continues, not in LVEA
- no SEI
- Apollo, beam tube cleaning ongoing today
- Gerardo, vacuum, High Bay area
- SUS, no work
- PSL, yesterday's work OK, no work today
- Commissioning, intensity noise, frequency noise
- Jim, Frame Writers work continues
- Peter/Jason, NPRO in OSB optics lab, started 9AM, done 10:37
- Richard, PEM/Weather Station, 9:2AM
- Gerardo, vacuum, High Bay area, Heavy Forklift, started 10:13AM
- Betsy/Travis, LVEA, start 10:50, done 11:11AM
- Dave, Frame Writers, FR0 not being written right now as a test, started at 11:40AM
- Daniel, down to EY to fix GPS clock
I have installed and made RCG2.9.6 the default build environment. I have compiled all th H1 models (102 of them) using 2.9.6, there are no errors in the build. The IPC file was created from new, it is 6 channels smaller than the old file.
This was a make only, it was not installed. I have reverted the original IPC file in case models are restarted this weekend. I'll complete the make/make-install process next Tuesday prior to H1 upgrade to 2.9.6.
The morning around 17:42UTC, PR3 moved but there was no alignment slider or other requested alignment change.
Two plots show this:
Plot 1: 3 channels
- blue trace, alignment slider, 17:09 to 17:57(end of plot) no change
- red and green traces, pmon and oplev pitch, 17:42 optic takes a step
Plot 2: 9 optic alignment channels, ISI pmon, POPAIR, TEST, and IMC power
- nothing that explains why the optic would move
Here is an update on the ongoing CDS investigations:
DAQ framewriter instability (FRS3379)
started around 14th July. We are testing reducing the disk loading of h1fw0 by only writing science frames (i.e. not also writing the larger commissioning frames). Four hours into this with no frame writer restart.
End Station SUS IOP glitching (FRS3375)
started when the end station sus computers were upgraded to the faster model (14th July). Its impact on ISI has been reduced with the installation of new ISI BSC models this week which do not watchdog trip on individual IPC errors. We will check on the BIOS settings of the SUS computers next Tuesday with LLO (requires LLO end station SUS power down). If there are any differences, LHO will be made the same as LLO. Reverting to the slower computers is an option.
Front End IOC freeze ups (FRS3279)
Not sure when this started as logging was not available, word-of-mouth suggests it became clearly noticable early in July. Monitoring of the problem has been installed. Investigation is continuing, its main impact is on Guardian nodes.
Chris S. 80% Joe D. 60% 7/20-7/24/15 The aluminum strips were installed on the upper joints of 124 meters of enclosure for a total of 1199 meters completed.
Ed P. Rodney H. Mark L. 7/22/15 The crew relocated the lights and generator after testing the previously cleaned sections, results posted in this entry. 65 meters of tube cleaned ending 3.8 meters east of HSW-2-062. 7/23/15 76.2 meters of tube cleaned today ending at HSW-2-058. The cleaned sections were tested and the generator relocated. Test results also posted here. 7/24/15 The vacuum nozzle that we originally modified for a lower noise level has lost the Viton strips that were installed. I reinstalled thicker rubber strips and reinforced these with an aluminum backing strip. This was only tried for a few hours this afternoon so time will tell. We were able to clean 79 meters today ending at HSW-2-054. We began relocating the generator and lights. Total meters of Y-Arm tube cleaned = 907.
I update the script for the 'Night' OPLEV charge measurements. If you are the last person who leaving the LHO in the night - please, run it! It works for ~ 2.5 hours. Instructions: 1. Set ISC_Lock state to DOWN 2. Set both ETMs to "ALIGNED" state 3. Run the scripts: scripts directory is /ligo/svncommon/SusSVN/sus/trunk/QUAD/Common/Scripts run the python files: ./ESD_Night_ETMX.py and the second script in another terminal: ./ESD_Night_ETMY.py 4. If you need to break it - use Ctrl-C, script restore settings even in this case. If it works, it: a) In first ~ 30 seconds sets the channels and can warn about troubles with ESD or Alignment. If you see the warning - check this system and press ENTER. b) Aligns the optical levers c) During the measurements it should once a second print "Receiving data for GPS second: 1234567" c) After all the measurements it restore all the settings back. If you need to stop the script while you have no access to that machine or don't know who start it and at which machine - just change the requested Lockstate. Script checks if the requested state is DOWN once a 30 seconds and stops if the state is changed. If something was wrong the script was stopped but settings are not restored - you can use ./ESD Restore_Settings.py . Just in case: scripts modify follow settings: 1. L3 Lock: Bias Voltage - 0 Offset - green light Ramp time - 5s 2. ESD linearization: Bypass - ON (on ETMY it is already ON) 3. For ETMY: turn on Hi-voltage driver.
David logged about the SUS IOP glitches generating IPC errors to SEI Tuesday. These sometimes (too often) would trip the ISI. SEI has a solution already for the HAM ISIs which Jim detailed in 19842 where we added it to the BSC ISI.
Attached is a duplicate of David's plot from Tuesday. This is 14 days and clearly the ISI TRIP FLAG (UpperLeft) which became very active after the SUS computer upgrade is now back to quietly sitting at zero. The trip flag doesn't always register when a glitch from the SUS occurs(UpperRight and LowerLeft) but things do look better now. A repeat of this in a few more days will prove it pretty convincingly. The ISI has had a few trips since the model change but not from the SUS.
The writing of full frames has been halted on h1fw0 for testing of frame writer stability. This does not affect science frame writing, which is still being written by both h1fw0 and h1fw1.
Kiwamu, Hang
We did an estimation of the beam position on test masses based on the a2l gains that gave us best decoupling.
The result was shown in the first image attached. The blue line indicated the boundary of L3 and the red spot the position of the beam on the test mass. It seemed that the beams were <~1 cm off center.
Trans. [mm] | Vert. [mm] | |
ITMX | 3.0 | -7.3 |
ITMY | -6.3 | -3.5 |
ETMX | 5.3 | -4.7 |
ETMY | -2.7 | 4.1 |
===================================================================================================================================
In case that you are interested in how we obtain the results:
The basic idea is to excite the pitch (yaw) motion of L2 stage, and let this excitation go through both
1): the L2->L3 P2P (Y2Y) path, and
2): L2->L2 P2L, and then L2->L3 L2L and L2P.
The ratio of L3's L over L3's P will then give us the vertical position of the beam on test masses. See the second picture for a graphic representation.
===================================================================================================================================
The code to re-run this analysis is available at:
/opt/rtcds/userapps/release/isc/h1/scripts/a2l
You can do the analysis by entering
./run_GrabBeamSpot.sh
in the command line
But isn't there a static component of L2P -> L3L that we have to worry about? If there is something like that it seems like it would be static, but it might shift the absolute beam position by some amount.
This is an update to alog 19166.
All points in the reliability and operations category have been addressed or completed. More work will be done to fine tune the alignment control and the scripting. Improvements have been made at low frequencies due to tuning of A2L, aux dof, loop shape, etc. Below is the updated list.
SudarshanS, TravisS, JoshuaF
After some investigation we did yesterday, it looks like the X-end Pcal laser is clipping on the way out (after hitting the test mass) inside the chamber.
We were aware about the slow drift in Pcal laser as observed by RxPD (receiver side photodetector) at X-end sometime before ER7. We let the pcal run without fixing it because we were sure it was clipping on the way out. This was confirmed by looking at the data from ER7 which shows the pcal induced displacement on DARM corroborates with the calibrated TxPD that is on the transmitter side of the Pcal enclosure.
Yesterday we wanted to investigate if the clipping was on the aperture of the RxPD and/or steering mirror in RxPD enclosure, which could have been an easy fix. However, its not the case. One of the beam(out of two) is clipping inside the chamber on the way out. We did measure the power of each beam individually before it enters the chamber and after it exits as follows.
Inner Beam | Outer Beam | |
Before it enters the chamber | 0.735 W | 0.715 W |
After it exits the chamber | 0.726 W | 0.077 W |
This still doesnot effect the operation of the Pcal because the displacement can be calibrated using TxPD. However, looking at the trend plot we know that this changed happen sometime around May 20 and we should be able to revert back into the old configuration after some more investigation of what changed during that time.
There was a question yesterday about the blends we are running on the the BSC-ISIs. I'm attaching plots of the Quite90/250 and Windy90/250 blends. Pages 1-3 are the 90mhz X/Y blends, 3-6 are the 250 RX/RY blends. The Quite blends are what we are running currently on St1 in XYZ (90) and RX/RY (250), and there is some evidence that we can run them during windy times as well. The Windy blends are kind of untested, and don't currently run on the end station ISIs, I don't know why and I haven't had much of a chance to look into it. The end ISIs will switch to the Windy blends, but trip after a few seconds. Pages 3 and 6 at least show that the filters as installed on ETMY are properly complementary, ETMX is the same.
For comparison, here are the Quite blends compared to the LLO blends we used previously. Pages 1-3 are the 90 mhz X and page 4-6 are the RY blends. Pages 2&5 are probably the clearest to look at.
For fun, here are the HAM 0128 blends. Page 2 shows the complementary form of the X and RY blends, page 1 is the as installed version.
I turned on the 530-545 notch in FM7 of ETMY L3 LOCK, and switched to ETMY with the ESD low pass on. As the alogs of Evan and Rana suggested, by notching the pcal lines in the drive to ETMY we can engage the low pass and still have a rms of about 3000 counts on the ESD. (screen shot of ETMY drives attached).
The resulting DARM spectrum seems slightly better at around 50-80 Hz. Things are worse below 20 Hz because I increased the gain of DHARD YAW. We can see if we are at least stable at high power with this increased gain for DHARD, and then worry about the 20 Hz noise.
We had one of the huge glitches that we have been calling beam tube glitches, at around 8:15 UTC July 24th, even though no-one is cleaning the beam tubes. I've hit the intent bit and an leaving the IFO locked.
There is currently a descrepancy of about 25 Mpc between the range displayed in the control room and the range on the summary pages.
This lock has lots of glitches at harmonics of ~505 Hz. We've seen this before, and it seems to be some kind of upconversion of the violin modes. I checked to see if these were caused by overflows in the ETMY L3 DACs. I also checked the L2 DACs on both ETMs, and a bunch of photodiodes (DCPD, POP_A, and many ASC). The only DAC/ADC overflows on any of them were during two isolated incidents or at the last second of lock. So the 505 Hz harmonics are not related to saturations in any of these. I did find that the ETMY L3 DACs started to saturate about a minute before the end of the lock. There are two isolated times in the middle of the lock with overflows, 1121762742 and 1121765852, that detchar should look into.
Here is some data from the cavity pole tracker (alog 19852) from the lock stretch of the last night ( which lasted for approximately 100 minutes):
The pole frequency was stable in the first 75 minutes or so. Then the pole frequency dopped by 50 Hz. Then it became unstable for the rest of 20 minutes, followed by a lock loss at the end. There were two glitches in the estimated cavity pole, one at 25-ish min and the other at 75-ish minutes. At the beginning, I thought they were related to the SR3 optical lever which also showed some glitchy behavior. However the cavity pole and SR3 oplev don't look coincided. So the glitches in the cavity pole must have been driven by something else.
Interestingly, after 75 minutes, the cavity pole seemed to start correlating with motion in PR3 yaw -- as PR3 oplev yaw went down the cavity pole also went down and vice versa. On the other hand I did not see a clear correlation of the cavity pole with test mass oplevs.