jason.oberling@LIGO.ORG - posted 10:37, Wednesday 25 March 2015 (17459)
PSL DBB/ISS Scans
Here are this week's PSL DBB/ISS scans.
Non-image files attached to this report
Here are this week's PSL DBB/ISS scans.
Now the whole initial alingment procedure can be done using ALIGN_IFO, which will hopefully reduce confusion and the need to init different guardians. We have replaced the ISC DOF with the new diagnostic guardian on the ISC overview screen.
Also, the states which used to be called SRM ALIGN and OFFLOAD SRM ALIGN are now SRC ALIGN ect since they are really aligning both SR2 and SRM. Nutsinee and Ed are working on updating the procedure for operators.
I've edited the operator WIki instructions to reflect this change. If anyone catches something that I missed while trying to align/lock please let me know. -E
J. Kissel Following the installation of the front-end infrastructure for calibration lines and optical gain compensation for the DELTA L EXTERNAL calibration (see LHO aLOGs 17114, 17179, and ), I've modified the CAL_CS_OVERVIEW.adl MEDM screen, and created newer lower-level screens for the details of the generation of calibration lines and the computation of the optical compensation (i.e. the "gamma" factor). See attached screen shots. Also, for the record I've started to put together documentation of this stuff, check out T1500121. Now that the MEDM interface is established, we'll begin filling out the parameters of the infrastructure, and finally get some calibration lines in the DELTA_L_EXTERNAL spectra. Stay tuned!
model restarts logged for Tue 24/Mar/2015
2015_03_24 10:15 h1asc
2015_03_24 12:22 h1sushtts
2015_03_24 12:44 h1broadcast0
2015_03_24 12:44 h1dc0
2015_03_24 12:44 h1fw0
2015_03_24 12:44 h1fw1
2015_03_24 12:44 h1nds0
2015_03_24 12:44 h1nds1
no unexpected restarts. Maintenance day: asc and sushtts cleanup, Beckhoff changes, associated DAQ restart.
Laura, Josh, Andy, Joe, Detchar
We took a look at the 28 Mpc lock on 24th March to see if there was any evidence of arches that we have seen previously at LLO (for example LLO alog 17090).
The first attachement shows a histogram of the rate of glitches (omicron triggers) binned by the value of IMC-F at the same time. The plot looks pretty Gaussian, except for a few bins specifically between IMC-F values of -37.5 to -41.7 and -45.8 and -50. Between these values we see evidence of arches in DARM. The second attachment is a pdf file showing the arches in DARM lining up with values of IMC-F in the second bin. Here are links to many spectograms confirming the arches in the IMC-F bins outlined (spectrograms for IMC-F bin -37.5 to -41.7 / spectrograms for IMC-F bin -45.8 to -50). Each spectrogram time corresponds to a glitch as seen by omicron.
LLO has dramatically reduced the effect of these arches, see LLO alog 17191.
Also the value IMC-F has when these arches appear in DARM seems to drift, i.e. there does not appear to be a specific value of IMC-F which produces the arches (this is evident in the second attachement). This is not what we have seen at LLO, does anyone know what could be causing this?
Andy, Laura, DMac Here's a look at one of the whistles, and the putative cause as an RF beatnote with IMC-F. The idea is that the IMC VCO is beating against another (nearly) fixed RF oscillator, and that's what we see in DARM. In that case, the frequency track should look like the difference between IMC-F (calibrated in kHz) with some fixed value. In fact, the whistle clearly seems to match half of the frequency difference (black trace) rather than the full difference (red trace). Perhaps this hints at the type of coupling? Here, the fixed value is about -46.9 kHz (relative to whatever IMC-F's reference is), but we think this drifts during the lock. We can look in detail at some more of these, and find out.
Why not use the frequency readbacks of the oscillators and VCOs rather than the somewhat arbitrary IMC_F? The radbacks are only once per second, but they can still tell you which units are close in frequency.
I'd be happy to look at the readbacks, as long as they are recorded and available offsite. Can tell me what the channel names are?
I put some notes about these channels in the summary of the ISC F2F last fall. ("RF crosstalk" section)
The channel names and labels are in the attached code. There, I look at the time around the event that Andy sent around to the DetChar mailing list yesterday. It's not totally obvious what VCO is beating against the PSL VCO, the closest one is ALS COMM, but it's about 400kHz away at the time of the glitch.
The first plot shows the value of all the corner station VCOs in the ten minutes around the glitch, the second plot is a zoom around the PSL VCO frequency.
It seems like H1:SYS-TIMING_C_FO_A_PORT_11_SLAVE_CFC_FREQUENCY_5, which Dan has labeled as the PSL readback, is the best candidate. This seems to be roughly equal to (1/2)*IMC-F + 79.225 MHz, delayed by one second (i.e. I can line those two things up and they overlap). Is the one second delay due to some loop or is it just a quirk of the recording system? The whistles occur whenever this readback crosses 79.2 MHz, which is the fixed fiber AOM frequency from the talk referenced in Dan's notes from above.
Kiwamu, Dan, Daniel, Elli
Today we locked SRMI using H1:LSC-REFLAIR_A_RF45_I_MON for SRCL and H1:LSC-ASAIR_A_RF45_Q_MON for MICH. This configuration is more stable than previous locks where we were locking MICH to ASAIR_A_LF and it was clearer where the locking point is. We retook transfer function of AUX laser and carrier beatnote at OMC_REFL path against AUX laser offfset with and without beam clipping. MICH offset was 20 counts of normalised H1:LSC-ASAIR_A_RF45_Q_MON so we were locked very close to the MICH dark fringe. The raw data is available in /ligo/home/controls/elli.king/SRClengthdata.
I have unlocked SRMI and I am leaving the guardians in the down state. We changed the whitening gain on REFL_A_RF45 for the measurement but I have set it back to zero and have reset the dark offsets H1:LSC-REFLAIR_A_RF45_I_OFFSET H1:LSC-REFLAIR_A_RF45_Q_OFFSET to tTuesday morning's values.
Kiwamu, Lisa, Sheila, Dan, Evan
A preliminary measurement shows that we are not quite limited by intensity noise between 50 Hz and 1 kHz, but we need to take another round of measurements in order to say anything conclusive.
This was taken before switching to the ETMY ESD and before feedforward subtraction of MICH.
This result is roughly consistent with Gabriele's conclusion that the intensity noise coupling above 100 Hz is a factor of a few below the total DARM noise.
Kiwamu wired up the extra LSC DAC channel (LSC-EXTRA_AO_2) to drive the excitation point of the ISS second loop (PSL-ISS_TRANSFER2_INJ).
Then we drove a swept sine using this DAC channel and looked at the transfer function IMC-IM4_TRANS_SUM → LSC-DARM_IN1. The data aren't great, since it seems hard to get good coherence around 120 Hz and below 50 Hz. I've attached a calibrated version of the transfer function. IM4 trans is nominally calibrated into microwatts, and the conversion to DARM_IN1 from OMC-DCPD_SUM for this lock is 5.4×10−7 ct/mA (the DCPD_SUM channel is nominally calibrated into milliamps). The transfer function looks very feature-rich, and we would greatly benefit from a more careful measurement.
A good time to look at IM4 during this lock configuration is 2015-03-24 05:08:20 to 05:10:20 UTC. Using the ASD of the IM4 sum power during this time, one can use the above TF to propagate it forward to DCPD sum photocurrent. This can be propagated foward to DARM noise using the coefficient 4.6×10−13 m/mA. I've undone the DARM pole, but not the DARM loop (since our measurement is more or less above the loop UGF).
Few months ago I did some simulations to understand the large coupling of intensity noise at Livingston. Details are in LLO alog 13768, 13963, 13985, 14091 and 14188.
At Livinston the dominant cause of increased coupling was the mismatch of the lenses in the two ITMs. At LHO the shape of the coupling seems different. It is very similar to the simulation result I got with a MICH offset, see the linked alog entry and the attached plot.
Lisa, Evan
Attached is a spectrum of the suppressed DARM error signal from last night. The RMS is about 3×10−13 m down to 0.1 Hz, and (as we've already seen) almost all of it comes from motion between 1 and 5 Hz. By looking at the recent DARM OLTF for H1 (LHO#17153), we see that we easily have more room for a boost below 10 Hz or so (and Dan is already working on this).
Also attached are spectra of recent "best" locks from H1 and L1, along with the GWINC prediction for 10 W of input power.
P.S.: The rms traces of the calibrated DARM signals in DTT appear to be completely bogus. The attached plot was done independently in python.
P.P.S.: Attempting to print these spectra in pdf, eps, or ps causes DTT to crash.
Some plots with the best L1 and H1 sensitivity curves so far.
The attached image describes the effect of the boost filter we'd like to add to DARM. The blue trace is the current set of DARM integrators, boosts, RGs, and so on (I haven't included the suscomp filter). The red trace has the new boost in FM7. The blue trace is the same as the comparison that Peter made between H1 and L1 back in February. Compare the red trace in the attached plot (the change we'd like to make) to the L1 trace in his comparison; this boost will bring us more in line with the Livingston loop shape. (The changes made two weeks ago to the DARM loop were made to the suscomp filter.)
The boost adds 20dB of gain at 3Hz, takes away ~1.5dB at 10Hz due to a pair of complex zeroes, and loses about 4deg of phase at 50Hz. The last DARM OLTF we measured says we have 45deg of phase margin at the 50Hz UGF, and probably about 30dB of gain at 3Hz, so this filter should significantly improve the suppression in the 2-5Hz band without costing too much phase.
We might want to add an RG filter at 0.45Hz to suppress the pendulum resonance, too. Or increase the existing RG in FM3.
Dan, Sheila
We had a quick look at last night's lock, it seems that the degradation in the range over time was not due to an alingment drift, since we can see that the build ups stayed high durring the lock. It seems like the wind picking up again this morning was pretty well correlated with the range decreasing. We don't know how to get DMT sensmon data (or any DMT data) from the control room. Dan made this plot by logging into the cluster to find the DMT sensmon frame files.
Dan, Sheila
The attached screenshot shows a one second trend of the beckhoff channel that is the fast shutter trigger readback, along with two RCG channels, the first is AS_C sum, this PD should be the source for the fast shutter trigger, and ASAIR_LF, which should see similar power fluctuations.
The beckhoff channel seems to be 0.2 seconds ahead of the RCG channels. This timing difference sometimes makes it appear as though the fastshutter shut first, causing the lockloss, as in the second attached screenshot.
We would like to prove definteively that the shutter is only shutting when it should, but we don't have a readback that we trust.
Dave and I looked into this somewhat and we don't think that the timestamps of the EtherCAT systems are used at all by the frame builder. As a matter of fact the internal clock of these machines was about 3 seconds off. Since it is hard to believe that the EtherCAT systems violate causality, the most likely candidates are frame builder, data concentrator or maybe the EPICS gateway. This would also mean that all data transported through EPICS to the frame builder could be affected. More investigations are pending.
Following up on my log 17295, the 10 hz CPS low pass elliptical filter is now running on all BSC ISI's. I've spent today working on ETMX trying to push the St2 filter down more and adding a similar filter to St1 but it's not ready for show time, so only the "old" filter mod is running.
First attached plot shows the X and Y St2 sensors, X is red ( gnd STS, St2 CPS& GS13), Y is blue, Y is running the "old" elliptical filter, X is running the more aggressive setup. You can see that from ~2 to 15 hz the more aggressive (red) setup does better. Unfortunately, the St1 elliptical filter interferes with the sensor correction (changing the phase of the CPS plant), so the ground STS signal doesn't cancel the CPS signal as well, increasing motion by ~2x at ~.5 hz. Or maybe the ground is a little worse, idk. I plan on tuning this a little more, maybe modifying the sensor correction as well (when I understand it better), and will try again when the opportunity presents itself.
The next two plots show changes I've made to the blends. Second plot is St1, red is stock, green is the filter I tried today(with problems at .5 hz), blue is what I will try next.
Third plot is St2 blends, red(not installed) is new, blue is the only thing running right now.
model restarts logged for Mon 23/Mar/2015
no restarts reported
Time Code Translator work at end stations, WP5116
Dave, Jim:
We racked up the missing TCT in EY, then connected it to one of the unused fiber pairs running between the VEA rack and the computer rack. We verified it was using ports 19 and 20 in the MSR (same as EX). Once connected the TCT synced to the time and the error LED on the MSR sender was extinguished.
We then ran 30 foot 50-Ohm coax, BNC terminated, between the TCT in the computer rack, through the wall, to the first port on the CER comparator. This was done at both EX and EY. The 1PPS port on the back of the TCT is a TNC connector, so we used a TNC-BNC adapter on that port for EX. We need to do the same for EY.
At EX, the comparator is now displaying a time of -22.2uS on the TCT port, roughly the time of flight between the buildings. We will revisit the TCT internal settings, they are most probably what was left from iLIGO.
Rebuild of ASC model
Daniel, Dave:
Daniel though h1asc would benefit from a clean build, install and restart. This was done, I'll see if this helped in the IPC errors.
PCAL filter modules, port from PEM file
Sudarshan, Dave:
Sudarshan discovered that I had forgotten to migrate the PCAL filters from when the CAL system shared a core with the PEM. He copied them from H1PEME[X,Y].txt to H1CALE[X,Y].txt, making a CAL_PCAL to PCAL name change in the process. The filters were then loaded into the PCAL models at both end stations.
The TNC to BNC adapter has been installed to connect the EY TCT to the timing comparator. Remaining work is calibration of the CsIII frequency standard, the time distribution system in the corner stations, and the TCT at the end stations.
(Kyle, Gerardo)
Turned off and decoupled two pump carts, from HAM1 and HAM2 annulus system.
The annulus ion pump for HAM1 still not connected to CDS, HAM2 is.
Evan, Sheila, Dan, Kiwamu, Lisa SUMMARY The wind dropped below 20 mph in the evening, and we started locking. After some roll, bounce and violin damping, we made it to DC readout @ 8W. We successfully transitioned DARM to ETMY with low noise ESD and got some MICH feed-forward cancellation going. We improved the noise between 30-200 Hz, and reached 28 Mpc (according to SensMon). The noise was more stationary than previously observed . However, the OMC is still shaking , and it is not good. Dan has a resonant gain for DARM ready to be tested to reduce the noise around 3 Hz, but we didn't manage to get that done tonight. We leave the interferometer locked at 28 Mpc starting at March 24, 2015 9:17 UTC . DARM control on ETMY with low noise ESD We did the transition from ETMX to ETMY L2 for DARM, but the interferometer was very glitchy, and we decided to abandon L2 control and try the new Den's strategy to do the feed-forward to ITM(Y) L2. Evan got about a factor of 10 subtraction (FM9 has BS plant inversion in LSC-MICHFF filter bank, gain +0.048). ASC cut-off filters Since none of the ASC loops had cut-offs, we decided to add some . They are now engaged by the Guardian. A more fine tuning will happen at some point. Started switching coil driver to low noise We started switching the coil driver to low noise . Evan will post a table later with the successful switches we did after acquiring the DRMI lock. We need to do more work on this, some failed.
Spectra attached.
Here is a plot of the lingering coherences with LSC DOFs.
Very nice progress!
Excellent news. Great progress.
This is fantastic progress, congratulations!
For anyone that would like to look at the data quality or run any DetChar tools on this data, the following GPS times can be used:
1111223896 - 1111239923
Duration: 16027 seconds
This entry should make Lisa a contender for her "best log entry" prize. Nice going, everyone!
These are the coil driver states that we've been using so far:
| OLD | PRM | PR2 | SRM | SR2 | PR3 | SR3 | BS |
| M1 | 1 | 1 | 1 | 1 | 1 | 1 | |
| M2 | 2 | 2 | 2 | 1 | 1 | 1 | |
| M3 | 2 | 2 | 2 | 1 | 1 | 2 | — |
| OLD | IX | IY | EX | EY |
| R0 | 1 | 1 | 1 | 1 |
| M0 | 1 | 1 | 1 | 1 |
| L1 | 3 | 3 | 2 | 2 |
| L2 | 2 | 1 | 1 | 1 |
Now we've managed to switch to the following configuration for acquisition (following the tables in LLO#16565):
| ACQ | PRM | PR2 | SRM | SR2 | PR3 | SR3 | BS |
| M1 | 2 | 2 | 1 | 2 | 2 | 2 | 1 |
| M2 | 2 | 3 | 2 | 3 | 3 | 3 | 2 |
| M3 | 2 | 2 | 2 | 2 | 2 | 2 | — |
| ACQ | IX | IY | EX | EY |
| R0 | 1 | 2 | 1 | 1 |
| M0 | 1 | 2 | 1 | 1 |
| L1 | 3 | 4 | 2 | 2 |
| L2 | 2 | 1 | 1 |
1 |
Green indicates a low-noise state, and red any other state. So far we have encountered the following things:
