Keita, Sheila, Kiwamu
This afternoon Keita and I did another test of opening and closing DBB shutters, since Keita realized that there are multiple shutters that matter. The results are in the screen shot. We only see two shutters on the PSL layout, (SH01 in the 35 W path to the DBB and SH02 in the 200W path) and on the photos documenting the table, but there must be a third shutter, perhaps inside the DBB box. We did not test switching to the 35W beam because that caused a lockloss last night. Apparently the shutters used here are Thorlabs SH05, which has an aluminum blade according the the thorlabs website.
When changing between shutter states today we saw a broad band change in the DARM noise throughout our 200Hz-1kHz lump, (this is a little different from what we saw last night). However, we saw 3 different noise states in DARM depending on the shutter requests, shown in the attachment.
shutter open | shutter closed | |
no beam | worst | best |
200 W |
intermediate | worst |
We guess that the shutter which is controlled by the epics channel "PSL-DBB_SHUTTER_DBB" is inside the DBB box itself and not on the layout. It is hard to explain the table above. For example, if no beam is selected, and both beams are really blocked before they reach the DBB, why would closing the shutter inside the DBB matter?
Kiwmau and I went inside the PSL, placed beam dumps in the paths to the DBB. We placed a "black hole" beam dump (no cone in the middle) in the HPO path (a 250 mW beam between M3 and M12 on the layout). Looking at that beam with an IR card, we could see a corona around it, pictures will be attached to this alog. This corona is scattered around, hitting the black baffle near the DBB apperature and other things. We also placed a black glass beam dump upstream of the front end laser beam path the the DBB, just before the shutter.
Update:
After waiting out the Japanese earthquake, we relocked. The lump was smaller in the first moments of the lock. After a few minutes the peaks reappeared, but the peaks still changed when we opened and closed the shutters, in a way that is repeatable although the plot is confusing since the overall level of noise was changing probably with the thermal state. (each time we opened the shutter, things got worse than they had been).
We do not understand how changing the shutter state impacts the DARM noise, although we think we have ruled out scattered light. Kiwamu thought that perhaps the change in the noise could be due to the change in the diffracted power when we move the shutter (see Keita's alog 30679). We tried a test of changing the diffracted power, which unlocked the IFO. It could also be through the same electrical coupling that means the diffracted power changes when we open the shutter.
One consequence of these table layout modifications is that we've lost the signal that monitors the output of the high power oscillator.
Keita suggested that one non optical way that shutter states could impact DARM is if somehow the shutters move more when open than closed. I had a look at accelerometers on the PSL table (table 1). There is coherence of around 0.3 between this accelerometer and DARM at the frqeuency of the peaks which depend on the shutter state. However, there was no difference in the coherence or the spectrum of the accelerometer when the shutters were open. It seems unlikely this is a mechanical coupling.
Also, The second attachment shows a trend of the power out of the PSL as we changed the shutters (DBB_SHUTTER controls SH01 and SH02, the two that are outside the DBB, 0 is both closed 1 is 200W beam open; DBB_SHUTTER_DBB is the one that must be inside the DBB box itself.) The two shutters we switched both reduced the output power by about 1.5Watts, and the impact is additive (both shutters closed is about twice as much power lost as either one of the shutter closed.)
However, as shown in the plot in the original post the noise impact is not additive, both shutters open is slightly less noisy than either single shutter open.
I didn't add the attachment to the above alog showing the power out of the PSL change as we opened and closed shutters on the DBB.
Here is one, which shows both the ISS diffraction changing, and a laser power monitor
TITLE: 10/20 Eve Shift: 23:00-07:00 UTC (16:00-00:00 PST), all times posted in UTC
STATE of H1: Down. Earthquake.
INCOMING OPERATOR: Patrick
SHIFT SUMMARY: Been stopping at Increase Power so far. Couple of locklosses. One was due to 9.32Hz rung up (DHARD loop related) and one due to PI mode27 (18043Hz) rung up really fast.
LOG:
01:18 Lockloss -- 9.32Hz rung up
04:05 Kiwamu and Sheila to PSL
04:25 Lockloss -- PI rung up (fast). Was able to find the right phase where the mode became stablized but it was too late.
05:34 Unable to lock due to a 6.2M earthquake in Japan. Take IFO to Down.
[Stefan, Jenne]
We looked at the cross-power spectrum at 10W and at 50W, to see if we would be able to see the smooth "lump" at several hundred Hz if we do as PeterK suggests and lock with 10W, no HPO on Monday.
Our conclusion is that at least at the beginning of a 10W lock, the answer is no lump. While the shot noise makes it difficult to see whether the lump is there or not, by taking a long cross power spectrum (DCPD_A vs. DCPD_B) we can dig down much deeper.
In the attached screenshot, we show the 50W and 10W calibrated DARM spectra (labeled "asd"), the shot noise level assuming the spectrum is shot noise limited at 1340Hz ("shot") and the cross-power-spectra calibrated to amplitude units ("cross-asd"). Note that the 10W shot noise almost limits our ability to see the lump, but the cross-asd tells us that the lump isn't there. The 10W spectra are taken with 15,000 averages, while the 50W spectra is only 1,500 averages. 10W data is from 20:56:00utc today, while the 50W is from our best time last night around 06:44:00utc.
We'll look more at the data later, but we are currently back at 10W, and at the beginning it looked like the lump was there (spectra and quick cross-power-spectra), but 10 min later it is starting to go away. This is definitely something thermal-related, and not relating to the different amount of polarization we let through the rotation stage + PBS.
TITLE: 10/18 Day Shift: 15:00-23:00 UTC (16:00-00:00 PST), all times posted in UTC
STATE of H1: Locked at Increase Power
SHIFT SUMMARY: Locking was mostly fine today. Needed some care at DRMI acquisition after high power locklosses, otherwise PI was PI
Few people went to mid stations, Peter did a test of PSL make up air, otherwise no other work done in VEAs.
PI StripTool on nuc6 now has two StripTools. Upper StripTool (PI_monitoring.stp) handles modes with frequency under 17k Hz, lower (PI2_monitoring.stp) with frequency above 17kHz.
We've seen more modes than fit on a single StripTool and with the upcoming TCS changes, it's probably best to keep an eye on all possibilities. Both StripTools are found in /opt/rtcds/userapps/release/isc/h1/scripts and can be opened from the PI Overview medm screen.
Reports:
- DBB shutter open results in a huge noise bump issue
- peaks are smaller, but still there wtih DBB closed off
- PMC high voltage noise: (HV drive coherent, better readout--> peaks visible, realignment of PMC improved peaks / but hump is still there)
- coupling mechanism from PMC length offset to DARM unclear
- PMC UGF was 600Hz instead of 5kHz. going to (nominal) 5kHz made DARM noise worse.
- Reducing PMC loop gain further is not helping enough
- projection ~x2 below noise bump.
- PMC wrong polsarization light? (would be almost resonant, and therefore sensitive to PMC length noise) not clear how the coupling downstream of PMC works.
- Jitter spectrum looks smooth - thermally diven? Is so, other modes also produced... 20 mode...!
- picomotor steering into PMC to test...
- SRM: alignment affects jitter bump... !?
======================================================================
To do:
- 9MHz missing in reflection (x5 missing: (2W-50W we are loosing 2.5x)) - > find 1W of 9MHz (what was the conclusion for REFL9 gain?)
- Low noise operaion at 12W, 24W (available in guardian)
- ER9 TCS configuration?
- PMC pole down
- Donut jitter verification? How?
Things to copy from LLO:
- Black glass for ETM camera to eliminate back-scatter
- ESD bias noise / zero crossing * run with ESD offset /reduced bias
- Compensation plate alignment ?
- PCAL switch (too much noise?)
"classical" tunings to be redone at operating point:
- A2L / ASC tuning
-Aux loops feed-forward
=======================================================================
Timeline:
- HPO: Earliest: Monday 10/24
- Option: 12W low power test first
- ER10 start LLO Oct 31 / LHO 10 days later
========================================================================
Another to-do that was discussed: Make-up air on/off test when IFO is locked.
Evan G., Chris B. After Chris fixed the GPS time issue (LHO aLOG 30669), we were able to make a successful injection test, although not in low noise mode for a complete test of injection recovery. Note, however, that the output of the TRANSIENT filter was turned off, so the ODC state information is likely incorrect.
Lockloss ~19:30 UTC was due to rapid rise (about 10 min into 50W) of new ITMY PI at 18136 Hz. It's now become MODE24 and was damped the following lock with the PLL scheme.
First saw mode in the live broadband monitor (found on PI medm screen under the StripTool button). I identified the arm by looking at SUS-ETMX/Y_PI_DOWNCONV_DC2_SIG_OUT_DQ spectrum at time right before lockloss. I identified test mass by alternating matrix elements to send damping signal to ETMY (with no result) then ITMY. Screenshot of PLL, broadband monitor, and StripTools during successful damping are attached.
Another new PI at ETMX 17771 Hz, now MODE7.
Belongs to the Xarm though test mass is unknown so far. Rang up about 2 hours into 50W lock (five orders of mag above noise floor in OMC DCPD) and rang down on it's own before I noticed it. I set up damping scheme in MODE7 and its been added to StripTool.
Here is a table showing the current LHO simulink mdl files which have local modifications not checked into svn and/or have pending updates from the svn repository.
Note that the SUS MASTER common files are currently incompatible with the H1 sus models and should not be updated until we are ready to apply Stuart's changes.
file | local mods? | pending updates from repository | comments |
sus/common MC_MASTER.mdl | no | YES | |
sus/common OMCS_MASTER.mdl | no | YES | |
sus/common HSSS_MASTER.mdl | no | YES | |
sus/common HSTS_MASTER.mdl | no | YES | |
sus/common HLTS_MASTER.mdl | no | YES | |
sus/common SIXOSEM_F_STAGE_MASTER.mdl | no | YES | |
sus/common BSFM_MASTER.mdl | no | YES | |
sus/common PI_MASTER.mdl | YES | YES | possible conflict |
sus/common TMTS_MASTER.mdl | no | YES | |
sus/common QUAD_MASTER.mdl | no | YES | |
sus/common QUAD_ITM_MASTER.mdl | no | YES | |
sus/common SIXOSEM_T_STAGE_MASTER.mdl | no | YES | |
asc/common IAL_LOCKIN.mdl | no | YES | not used by any H1 model |
isc/common LSC_TRIGGER.mdl | no | YES | |
isc/common FILTBANK_TRIGGER.mdl | no | YES | |
lsc/common lsc.mdl | YES | no | DBB jitter FF? |
lsc/h1 h1lsc.mdl | YES | no | DBB jitter FF? |
sys/common IWAVE.mdl | no | YES |
SUS MASTER files have been made read-only to prevent accidental updates
We are baking out some PMC PZTs in the countertop air bake oven in the OSB lab. The oven is sitting on the counter against the long hall-way wall from the controlroom to the bootscrubber into the LVEA. The oven has a fan in it that runs although we have never deemed this as a noisy source for interferometry. I turned it on yesterday morning around 11am PT. I will turn the second countertop oven on that is next to it today and both ovens will run over the weekend. Please holler at me you anyone sees this as a problem, or if particle counts look funny in the OSB optics lab over the next few days.
Jonathan, Satya, Jim, TJ, Dave:
This morning we installed the new x509 certificate on h1fescript0 to replace the expired cert. We were then able to restart the ext_alert code on h1fescript0. This runs under monit management.
I have created an external alert overview medm screen, it is called from the SITEMAP via the SYS->'GRB/SN External Alert' pull-down. I pulled out the ext_alert parts from the CAL overview screen to make the screen (screenshot attached).
TJ verified that the audible alarms at the operator station are announcing these alerts.
Updated Virgo logbook links at top of page per FRS# 6465.
Measurements of the pre-modecleaner high voltage monitor with the pre-modecleaner locked and unlocked (see plot legend).
Sheila Kiwamu Jenne Daniel
We measured the OLG of the PMC loop with the interferometer unlocked, and saw that it is aroun 500Hz while it is supposed to be at around 5kHz. Plotting the measured OLG as closed loop supression, we predict that this loop should have gain peaking approximately around the frequency of our lump in DARM. (second attachment). We tried increaseing and decreasing the gain by 6dB, and didn't see much of a change in DARM.
However, a driven measurement using the newly amplified HV mon as a readback predicts that this noise is about a factor of 2 below DARM in our lump. The third and fourth attachments are the same noise injections that Jenne and I posted on monday for MICH SRCL and PZT jitter, with projections based on PMC PZT HV mon. Kiwamu found an alog from april, 26538 indicating that the gain should be set to 30 dB (it has been 16 dB for the last several months). The third attachment shows the noise projection with the PMC gain at 16dB, while the 4th one shows 30dB. The 5th screenshot shows the difference in the DARM spectrum with the increased gain.
People are still invesitgating the coupling mechanism, we think that intensity noise (which we think was the explanation for the simliar noise at LLO in 2014 16186) is ruled out by the intensity noise injection, although it is interesting to note that the spectrum of this PMC HV lines up fairly well with the ISS control signal.
According to various signals when the PMC HV was excited, we are concluding that this is not a coupling through intensity or frequency of the light. We don't know how the HV noise couples to DARM.
In the attached screen shot, the right two panels show various signals with and without a broad band excitation in the HV. The PMC control gain was at 30 dB throughout the measurements. The upper right panel shows an increase in the PDA spectrum (which has been used as the sensor for the inner loop), indicating that the ISS witnesses increase in the HV noise somehow. However, the second loop sensors don't really show increase in their noise level below 1 kHz. This means that RIN at OMC DCPD should be at 1e-10 RIN/sqrtHz which is a factor of 10 lower than shot noise because our RIN to RIN coupling from the interferometer input to OMC DCPD is roughly -40 dB. So this does look like an intensity noise coupling.
As for frequency noise, the situation seems similar to intensity. The CARM loop sees higher noise level in frequency according to REFL_CTRL_OUT in the lower right panel. However POP 9I, which is an out-of-loop frequency noise sensor, did not show any elevated noise at all below 1 kHz. Based on the coupling of POP 9I measured the other day (30610), POP 9I should show higher noise level by a factor of a few in order to explain the increased noise level in DARM by frequency noise. So it does not seem to be frequency noise coupling either.
I compared nominal PMC locking gain (red, green) and 6dB lower (blue, brown).
Due to gain peaking at 240Hz the feedback signal doesn't decrease below 400Hz.
Anyway, higher than 400Hz, I see some reduction in DARM when the gain was lower, but it seems as if the reduction was mainly at around the peak of the three bumps (440, 580 and 700 Hz). For example it seems as if there's no reduction of noise at 520Hz even though the feedback signal to PMC PZT was reduced by a factor of 4.
We can also see that DARM got worse at 240Hz by reducing the gain due to gain peaking.
Changing the PMC filter to allow us to lock at much lower UGF would help but the featureless bump might stay. The second plot is the same as the first one but the PMC PZT (dashed) is put on top of the DCPD (solid). PMC PZT is arbitrarily scaled so that the DCPD with high bandwidth PMC lock (red, green) looks like the SUM of DCPD with low bandwidth PMC lock (blue, brown) and PZT with high bandwidth PMC lock(pink, orange).
https://alog.ligo-wa.caltech.edu/aLOG/index.php?callRep=30631 Satisfies FAMIS asset 364 maintenance
....just when I thought I understood FAMIS. I still need to "create request" to create a task associated with this asset created which already includes a schedule, procedure, and personnel assignment.
The first attached screenshot is a series of DCPD spectra from the last several months. When we first turned on the HPO, the noise in DARM did not get any worse. The noise stayed similar to O1 until July 16th, the lump from 200-1kHz started to appear in late July, when we started a series of changes in alignment and TCS to keep us stable with a decent recycling gain at 50 Watts.
PMC
Last night, Gabriele pointed out that the noise in DARM is coherent with the PMC HV. The HV readback had been mostly some white noise (probably ADC noise), until the last few weeks, but has been getting noisier so that some of the things jitter peaks show up in it now (SEcond attached screenshot, colors corespond to the dates in the DCPD spectrum legend. This may be related to the problem described in LLO alogs 16186 and 15986. The PMC transmision has been degrading since July, which could be a symptom of misalingment. Since July, the REFL power has nearly doubled from 22 to 38 Watts, while the transmission has dropped 28%. The PMC sum has also dropped by 4%, roughly consistent with the 3% drop in the power out of the laser. Peter and Jason are planning on realigning the PMC in the morning, so it will be interesting to see if we see any difference in the HV readback.
TCS + PRC alignment:
The other two main changes we have had in this time are changes in the alignment through the PRC, and changes to TCS. These things were done to improve our recycling gain and stability without watching the noise impact carefully. In July we were using no offsets in the POP A QPDs. We started changing the offsets on August 1st, after the lumpy noise first appeared around July 22nd. We have continued to change them every few weeks since then, but generally moving in the same direction.
The only TCS change that directly coresponds to the dates when our noise got worse was the reduction of ETMY RH from 0.75 W each on July 22nd, the other main TCS changes happened September 10th. It would be nice to undo some of these changes before turning off the HPO, even if it means reduing the power to be stable.
The HVMon signal (PMC length) shows a peak at about 600Hz/rtHz. We don't this is an indication of frequency noise from the laser, but rather an error point offset picked up in the PMC PDH signal. As such this is length noise added to the PMC and suppressed by the cavity storage time. Assuming this factor is about 1/10000, we would still get ~100mHz/rtHz which are modulated onto the laser frequency. Seems a lot.
The HVMon measure 1/50 of the voltage send to the PZT. With no whitening this is not very sensitive.
After the PSL team adjusted the PMC alignment the ~400Hz peaks are no longer visible in the HVMon spectrum. The coherence is gone as well—except for the 1kHz peak.
About the PMC:
1st screenshot shows the small improvement in DARM we got after the PMC realignment. While the coherence with PMC HV may be gone, it might just be that the PMC HV signal is now burried in the noise of the ADC. At a lockloss I went to the floor and measured HV mon, then plugged it into one of the 560s, AC coupled, 10 Hz high pass, gain of 100, and sent the output into H1:LSC-EXTRA_AI_1. We still have high coherence with this channel and DARM. (last attchment)
Also, the PMC realingment this morning did decrease the reflected power, but the transmitted power also dropped.
refl(W) | trans(W) | sum(W) | laser power out | |
July | 20 | 126W | 157 | 174 |
Yesterday | 35 | 103 | 138 | 169 |
today | 27 | 100 | 126 | 169 |
About turning the HPO on not adding noise:
Kiwamu pointed out that the uncalibrated comparison above showing that the noise did not get worse when the HPO came on was not as convincing as it should have been. This morning he and I used the pcal line hieght to scale these uncalibrated spectra to something that should be proportional to meters, although we did not worry about frequency dependent calibration. (4th screenshot) From this you can see that the noise in July was very close to what it was in March before the HPO came on, but there is some stuff in the bucket that is a little worse.
The point is made best by the last attached screenshot, which is nearly identical noise in the last good lock I could find before the HPO came on to the first decent lock after it came on. Pcal was not working at this time, so we can't use that to verify the calibration, but the input powers were similar (20Watts and 24 Watts), DCPD powers are both 20mA, and the DCPD whitening was on in both cases. (The decimation filters were changed around the same time that the HPO came on which accounts for the difference at high frequencies.)
Regarding power available to the PMC, I know this is obvious but another thing we have to consider is the ISS. Since the ISS AOM is before the PMC, it clearly also effects the amount of power available to the PMC. Peter K. can correct me if I am wrong, but it is my understanding that this happens primarily in 2 ways:
On 2016-9-21, for reasons unknown to me, the ISS control offset was changed from ~4.3 to 20. This means we are driving the ISS AOM much harder than we were previously. This then causes changes in the beam profile, which effects the PMC mode matching and lowers the cavity visibility. This is likely why, even though we have had only a 5W decrease in laser power since July, the total power into and the power transmitted by the PMC are down and the power reflected by the PMC has increased, and why we cannot return to the July PMC powers Sheila listed in her table in the above comment by simply tweaking the beam alignment into the PMC. I have attached a 120 day minute-trend of the ISS control offset (H1:PSL-ISS_CTRL_OFFSET) that shows the changes in the ISS control offset value since 2016-6-22, including the 2016-9-21 change. There are of course other reasons why the control offset changed (as can be seen on the attachment, the offset was changed several times over the last 4 months), the one on 9-21 just really stuck out.
Is there a reason why the control offset was changed so drastically? Something to do with the new ISS outer loop electronics?