J. Kissel, M. Landry More detailed aLOGs to come, but for those watching we've now completed all the tests we plan to do today with hardware injections and calibration measurements as of ~19:45 UTC / ~12:46 PDT. The observation intent bit is on. For the record, the "nominal" guardian state is still set to be "LSC_FF," (STATE_N = 520) but we will *not* be going to that state for not, as we still believe the MICH and SRCL subtraction are unstable and/or cause non-gaussianity. Also the cut-off filters for the CHARD and DHARD ASC loops are not engaged (because those also have not been tuned for the new higher recycling gain). We are leaving it in this state (called LOWNOISE_ESD_ETMY, STATE_N = 515) for this lock stretch, even though guardian does not think it's "nominal." Thanks for your patience! For the record, the first part of this lock stretch was glitchy (as seen on the spectrum in the wall and in the time series of DARM control). We're not sure why, but we'd convinced ourselves that it did not directly correlate with our hardware injection tests. It would be interesting to know what the problem was,
Since DC lock was achieved at 11:09 (after starting to try locking at 9:00 this morning), I've set the intent bit to Undisturbed. Injections are ongoing, the range isn't great and there have been earlier lock losses, but for now I think we can call an official start to the mini-run at LHO.
We see a swept sine in the data, but the intent bit seems to still be in undisturbed. I think the agreement on the detchar call is that the intent bit would be treated like science mode, with no excitations or other interventions. We also see some hardware injections, which are fine, since they will be flagged.
Andy, all: yep we had one calibration sweep in place during the first lock, apologies. From now on, we'll only allow for hardware injections when the intent bit is set.
Let us know if there is an interval you require (e.g. 2048s?) betwen injections.
Mike: I think that five minutes should be fine between CBC injections. But if there was a specific request from the CBC group, I don't want to override that.
We lost lock ~20 minutes ago. I've reset the intent bit. Looks like a rung up violin mode on ITMY. Jeff is working on damping it.
Now locked for the mini run, I've updated the susdrift mon to capture this lock alignment.
This morning I noticed that the SRM SDF rwas reporting some errors which I (nor Kissel) have seen before, see attached picture. Toggling the LOAD table and CONFIRM buttons did not clear the error. Will talk to Dave/Jim...
Posted below are the data files for the two Dry Box cabinets in the VPW. No issues were noted in the April data. Note: DB2 and DB3 are not in use at this time. Did not post data for these two cabinets.
With help from Richard McCarthy this morning, I was able to place the work platform on the stands allowing access to the BSC-1 annulus ion pump.
Seemingly the same symtom as ysterday (alog 18123). I did exactly the same recovery process. It is now back up and running.
Confirming that the two PSL trips recently noted by Kiwamu (alogs 18123 and 18132) were for the same reasons detailed in alog 18083: the diode chiller flow interlock H1:PSL-IL_DCHILFLOW is tripping for no apparent reason. Attached are trends from the trip events. Also, there was a third another trip, between the two Kiwamu noted, on 4/30/2015 at 4:19:43 UTC that was not in the alog; this trip did bring down the NPRO (as can be seen in PSLtrips2015-04-29to2015-05-01.png), but there is no indication in the log that the trip was manually reset. Evidence attached below (PSLtrips2015-04-29to2015-05-01.png and PSLtrip#22015-04-3004:19:43.png), same cause as the rest.
Jeff K, Kiwamu, Jim W,
As a prep for the mini run, we aimed to confirm that we can run in the low noise state. Most of the attemps were successful today and the interferometer stayed at a recycling gain of more than 35 most of the time and 39 at one point.
Here are items that we could not get done today:
Also, an earth quake hit us at around 8:20 UTC which we think is from Papua New Guinea at around 8:06 UTC with 7.1 M. This is a good execuse to go home for the night.
(ITM camera position updated)
As planned yesterday (alog 18125), we did initial alignment from scrach. We started from the classic dither-based TMS alignment which gave us well-centered beam on ITMs. Then ITMs and ETMs were manually aligned to obtain high build up in the arm cavities for the green light. After this arm alignment, we updated the ITM camera positions. Moreover, we did the Y arm red/green co-alignment again. We started from BS alignment using the ETMY baffle (see for example alog 18035) and optimized ITMY and ETMY to get high build up in red. Then steered TMSY and green QPD pointing to maximize the green transmitted light. I introduced offsets of -0.2 and 0.2 counts in QPD_A_YAW and QPD_B_YAW respectively. Note that these QPD offsets were confirmed to be good afterwords with the interferometer fully locked and optimized for high recycling gain.
The full-scratch alignment seemed to have helped increasing the recycling gain and therefore we did not have an issue in reducing the CARM offset which was very problematic yesterday seemingly due to a poor recycling gain (alog 18125). Once we fully locked the interferometer, we maximized the recycling gain by manually steering both ITMs in pitch and yaw as usual. This resulted in a recycling gain of 39 acrroding to TRX and TRY. The camera positions were then updated again for the high recycling gain condition. Also, I updated the ITMY aperture which I disabled two days ago (alog 18108) because the aperture was basically not doing a good job at all. I attach a picture of the ITMY camera with the new aperture masking. This seems to be working fine so far.
(Some udpates on ISC_LOCK guardian)
Since we have been focusing on the recycling gain issue in the past days, many commands (e.g. ASC roll offs (alog 17966) and etc.) had been commented out in ISC_LOCK which had helped the interferometer staying robust. However for the automation purpose for mini run, I uncommented all the commented lines in ENGAGE ASC so that now it engages all the loops. So far we did not see an issue with these ASC loops except for the DHARD/CHARD roll offs which apparently make the loops unstable for some reason. They remain uncommented. Also, I kept the roll mode damping commands commented out because I am worried about a situation where the modes rang up so high that the damping signals saturate the DACs. We increased the DARM offset from 2x10-5 to 3x10-5 counts in order to obtain more light on the OMC DCPDs. This gave us a total current of 10 mA when PSL was at 2.7 W.
After we edited the guardian, we confirmed that the ISC_LOCK could take us up to the low noise ETMY ESD state. This is a step far from the final state, the LSC feedforward. We did not get a chance to check out the LSC feed forward tonight.
After we got back to low noise (yay!), I spent a few hours working on the OMC. The salient points are:
OMC Length Dither Frequency
Koji recommended that the dither frequency be changed to move away from some excess noise he suspected was polluting the error signal. I scanned the dither frequency from 3300Hz to 4900Hz in 200Hz steps. Sure enough, there is a bump of excess noise around 3335Hz that had been coupling to the length error signal when the frequency was set to 3300Hz.
The first plot attached shows the sidebands and excess noise structure for these different frequencies (the channel plotted is the OMC-DCPD RIN). It's not a very convincing plot, but setting the frequency at 4100Hz gave us the cleanest spectrum. (I will post more convincing measurements later.) It would be good to do a finer scan in the future. I think the dither frequency at L1 is currently 4800Hz.
As the dither frequency was scanned I monitored an excitation at 12Hz into PZT2, this was necessary to keep track of which quadrature of the demodulated dither signal was the best measure of the length of the cavity. Here's the data keeping track of how the length excitation rotated from COS to SIN as the dither frequency was changed:
Dither Frequency | COS/EXC (mag, dB) | COS/EXC (phase, deg) | SIN/EXC (mag, dB) | SIN/EXC (phase, deg) | Demod Phase to lock the servo |
3300 | -27 | 65 | -27 | -110 | 90 |
3500 | -26 | 85 | -61 | -40 | 90 |
3700 | -27 | 65 | -27 | 65 | 90 |
3900 | -35 | 37 | -25 | 37 | 90 |
4100 | -35 | -105 | -25 | 80 | 0 |
4300 | -26 | -125 | -28 | 55 | 0 |
4500 | -25 | -95 | -50 | no coherence | -90 |
4700 | -25 | -105 | -25 | -100 | -90 |
4900 | -50 | no coherence | -25 | -70 | 180 |
Since the phase was changing it was necessary to adjust the demod phase to put the right quadrature into the length loop. (Why is the phase changing? Is it from a digital delay, or a mechanical resonance in the PZT?)
OMC Length Loop Shape
With the dither frequency set I inserted a 200Hz-wide bandpass around the dither frequency before the demodulation, and removed all of the ELPs and butterworth LPs that we had been using to suppress demodulated junk from getting into the control signal. An OLTF is attached (Fig 2), the UGF is 10Hz -- still a little high, from Koji's measurement -- and there is 67deg of phase margin. (In the legend, the green trace is the demod input highpassed, not lowpassed.)
The correct filters to use in the OMC length loop path are now:
LSC-PD_IN: FM2,5 (butterfly bandstop, 200Hz bandpass around 4100Hz)
LSC-X_COS, LSC-X_SIN: FM2 (double ELP for notch at 4100Hz)
LSC-SERVO: FM1, 2, 6, 8, 10 (boost, integrator, anti-dewhites and calibration constants)
This will give you a loop that looks like the blue trace in Fig 2. The gain of the servo is still set to 10.
OMC Alignment Dither
We've changed the alignment dither frequencies to [1675.1, 1700.1, 1725.1, 1750.1] Hz, but we never re-commissioned the loops. Today I spent quite a while trying to measure a dither sensing matrix with excitations into the QPD loops at 1.1Hz. This never produced an answer that worked upon inverting. Kiwamu mentions that things might be complicated by the actuation on the OMC SUS, and AC excitations could be exciting other DOFs than what we want to measure.
In the end I measured a sensing matrix at DC, with offsets into the QPD loops, inverted and got something that worked. We can engage the dither loops now, but I recommend ramping down the QPD loops (with the master gain slider), switching to the dither input, and then turning up the gain. It's probably good to keep the gain low, at 0.4, this gives a response to DC offsets of ~10 seconds. I didn't have a chance to measure the sensing noise to estimate the useful bandwidth. This has not been added to the OMC Guardian.
Attached are the dewpoint sensors for the 14 monitored storage containers. All data is shown since the sensors were installed and cabled.
Dan, Kiwamu,
We had trouble locking the interferometer tonight and therefore did not reach full lock.
It seems that the recycling gain is very low for some reason tonight. It seems as low as 19. Therefore the CARM reduction did not work as intended. In fact, REFL_LF dropped below 40% or less even when we were at the CARM_15PM state. Every time when we moved onto CARM_10PM it lead to lock loss. Not good. We even tried to transition to TR_REFL mutilple times by skipping a few CARM reduction steps since the REFL9 seemed passing the turn-around point. However this did not work either. Sad.
We co-aligned both red and green light in the Y arm in order to improve the recycling gain, but this did not seem to help. I am thinking of starting from the baffle PDs tomorrow in both arms just to make sure alignment is reasonable. In the course of the Y arm alignment tonight, we had to realign the ALS diff beatnote once because it went lower than -10 dBm.
PRC2 ASC loop still does not work only in yaw as reported by Dan (alog 18109).
There was a cabling error for the ETMX ESD DAC signals and this was the reason why we could not untrip the ESD driver. This is now fixed.
I drove down to EX and investigated the issue and found out that calbe #85 (see D1992741-v8) was conected to a wrong input of the AI chasis (S1102380). This must have been introduced today during the AA/AI chasis activity (see alog 18117). Since Stuart's medm screen (alog 17585) relies on the ability to see the analog signals, it was not able to tell whether the ESD driver was on or off even though the binary switches have been functional. I connected the cable back to the correct position which is the first slot (ch1-4) from the left on the front panel of the AI chasis. This fixed the issue -- now we can untrip and drive the ESD.
Seemingly due to some flow sensor issues. I reset the flow sensor indicator back to green in the control room. Then I reset the interlock and restarted the frontend from the diode room.
Nutsinee, Greg Alignment continued in two parts today. We first aligned the SLED beams to the irises on the table while waiting for a green beam to return. Once we got a green beam we attempted to align the SLEDs to the green beam. The Y side looks like it could use some continued refinement, while the X side continued to give us fits until the commissioner asked to give him back the interferometer.
Kyle, Gerardo Today we wanted to quantify the gas load "contribution" of the known leaking all-metal 2.5" Vent/Purge valve at the X-end station. SETUP X-end open to BT (GV19, GV20 open) Main Turbo backed only by the leak detector (no parallel pumping) RESULTS LD helium baseline < 10-10 torr*L/sec before valving turbo into X-end volume Helium background signal = 3 x 10-8 torr*L/sec after valving turbo into X-end volume Valved-out IP12 Removed NW50 blank from closed Vent/Purge 2.5" all-metal valve (i.e. vented air side of closed metal valve) X-end pressure responded by rising to low 10-7 torr Sprayed audible flow of helium on air side of closed valve while monitoring helium signal Helium signal rose rapidly then leveled-off and peaked at 2 x 10-5 torr*L/sec (signal peaked after ~10 seconds of spraying but I continued spraying until ~30 seconds) Spent the next few hours pumping system with the turbo pump to remove introduced helium. We also added an O-ring valve in series with the leaking valve and evacuated the air side of this valve CONCLUSION Traditionally we have only used the vendor supplied hand knobs to open/close these Vent/Purge 2.5" metal valves (1 per isolate-able volume). The allowable torque specs far exceed what can be applied using these knobs. As such, our valves are likely under-torqued as a rule and, as was demonstrated yesterday, this leak could likely be eliminated by tighing this valve using a wrench. As this particular valve has a "gappy" conflat joint on the vacuum side, we didn't want to "fix" it using a wrench (long lever) while we are open to the BT and while commissioning time is at a premium. The main take away is that all of our poor pressure level at the X-end can be attributed to this under-torqued metal valve and that we have no reason to suspect GV19 or GV20.
Helium level in vacuum system was 3 x 10-8 torr*l/sec before testing (spraying), peaked at 2 x 10-5 torr*L/sec during testing and was 5 x 10-8 torr*L/sec after 3 hours of pumping with turbo following completion of testing.
MICH feedforward seems to be doing its job, although there is room for improvement by implementing a frequency-dependent subtraction.
SRCL coupling into DARM seems to be very nonstationary. Consequently, the feedforward is not working.
We injected band-limited white noise (elliptic bandpass, 10 Hz to 1 kHz, 6 ct amplitude) first into MICH, then into SRCL, to test the feedforward that was implemented a few weeks ago.
For MICH, frequency-independent subtraction is fair to middling (red) compared to no subtraction (blue); at best we get 20 dB of subtraction around 150 Hz. Note that the TFs in this plot use the whitened DARM channel. The whitening is undone for the spectra in the fourth pad.
For SRCL, the 1/f2 feedforward via ITMY L2 gives no subtraction at all. The attachment shows the TF of SRCL control → DARM with the feedforward off and with broadband noise injected into the SRCL error point. Unlike MICH, appearance of this excitation in DARM is highly nonstationary, fluctuating by a factor of 2 or so in a frequency-dependent way. Additionally, the coherence is poor above 20 Hz, despite the excitation elevating the DARM noise by more than an order of magnitude from 20 to 100 Hz.
The shape of the excess noise is more or less the shape of the 100 Hz elliptic cutoff that we put into SRCL a few weeks ago. Is it possible that the SRCL control noise explains the nonstationary, 100 Hz "scattering" shelf that we've seen in the DARM spectrum this past week?
Using the measurements described above, here is a projection of MICH and SRCL control into DARM. It seems that these two noise sources, along with DAC→ESD noise, can explain most of the DARM noise from 10 to 70 Hz. There is still some excess from 80 to 200 Hz, and an overall excess in the high-frequency noise floor.
For MICH, I used the coherent transfer function we measured earlier. For SRCL, I estimated the TF magnitude by dividing the ASDs of DARM and SRCL (after subtracting off their quiescent values). The dtt files are in evan.hall/Public/2015/04/FullIFO/Noise
as MichNoise.xml
and SrclNoise.xml
.
Some times (all UTC):
After these measurements, I also tuned the PRCL→SRCL subtraction in the LSC input matrix from 0.005 to -0.04 (using in-vac POP). This reduced the appearance of a 122 Hz PRCL excitation in the SRCL error signal by 20 dB.
For completeness, here is the same budget as above, with intensity and frequency noises included.
We suspect that the sharp shelf at 100 Hz in the frequency noise projection might be coupling via SRCL, rather than directly to DARM. So between the frequency and SRCL projections, there may be some double-counting of noise in DARM.
Frequency, intensity, and DCPD dark noise are not enough to explain the excess noise between 200 Hz and 4 kHz. It seems they can somewhat explain the uptick in noise above 4 kHz.
Slightly updated/corrected version attached.
Could the nominal state be temporarily changed to Low noise ESD ETMY (or whichever state the IFO is most likely to be in for the mini run)?
If the Guardian isn't reporting that it's in the nominal state, the science mode bit will remain off and downstream tools that we want to test won't automatically run.