LVEA: Laser Hazard Observation Bit: Commissioning 07:00 Karen & Cris – Cleaning in the LVEA 08:06 Karen & Cris – Out of the LVEA 09:30 Sun Rentals delivery of scissor lift to Mid-X – Bubba escorted 09:43 Hugh – Going to CER to swap STS interface cables 10:00 Several small fires between Mid-X and End-X – Will monitor – Appears to be controller burning 10:13 Sun Rentals truck leaving site 11:13 Hugh – Going to CER to work on STS 13:40 Hugh – Going to CER to work on STS
SudarshanK, DarkhanT
We introduced two Pcal lines at 240 Hz and 310 Hz on photon calibrator at Y end. The Pcal lines are about a factor of 10 above the DARM sensitivity at those frequencies. We will look into any changes in the amplitude and phase of these lines to determine the the position of cavity pole frequency. The cavity-pole has been observed at frequencies listed in alog LHO #18360.
Since the pole frequency is at about 300 Hz, it would be useful to have a high frequency line, for example at about 1 kHz. This will allow a better reconstruction of the pole frequency.
If you haven't already, I recommend also putting a notch in the DARM loop at 310 Hz. That way any phase change that occurs at 310 Hz in DARM should be a direct measurement of changes in the sensing phase (which would presumably come from a chang in cavity pole). I probably would have gone a little higher with the 2nd line, closer to 400 Hz. Why did you choose what you did?
Gabriele, We also have a permanent Pcal line at around 540 Hz. We thought it should be enough. Is there any advantage of going close to1 KHz?
Peter, I will have to talk to Jeff about putting a notch on the DARM loop, I am not sure how to go about it. Regarding the choice of 240 Hz and 310 Hz, knowing we already had one line at around 540 Hz we picked a pair of line between one of the non-vetoed frequency band of pulsars. We could easily shift the second line to 400 Hz.
Larry Price did an analysis of just this situation, i.e. at what frequencies should you measure the transfer function to most optimally extract the features in the frequency response. His analysis showed that the most optimal place is at the feature itself. In other words, the best place to put your calibration line to most efficiently measure the cavity pole is at the expected cavity pole frequency. See: LIGO-G1400084
In light of this optimal, Fisher-matrix-based approach, Kiwamu and I have installed a notch in DARM at 322.1 Hz (actually an 80 dB elliptic bandstop from 321 Hz to 323 Hz). The goal is to inject a calibration line digitally into DARM control, so that we can use an LSC lock-in to demodulate the line.
We have set up LSC oscillator #3 to take OMC DC and demodulate it at 322 Hz. Both I and Q have 4th order butterworth low-pass filters. The lock-in output drives ETMX and ETMY differentially. The lock-in drive is currently 0 ct. It has not been set yet.
Better check the assumptions here. Doesn't Larry's result assume an open-loop measurement, white actuator strength, and white measurement noise (none of which holds in this case)?
Chris,
Thank you for pointing it out. We also noticed that the assumptions were not quite valid in our case. On the other hand, Larry's analysis still gives us a good idea of what frequency we should excite. According to his Fisher matrix analysis, the measured transfer coefficient exhibits a maximum response to change in the cavity pole frequency when the excitation is at the exact pole frequency. This led us to a frequency at around 322 Hz. If you take the spectral shape of sensor noise (or DARM residual) and the actuator transfer function into account, probably a slight lower frequency than the current choice may be better, but since we wanted to have a notch in DARM far from the UGF, we chose it to be close to the cavity pole.
After swapping the cables at the interface, the noise on the A seismometer was gone (see attached)--should have been now on the B channel (it has never been seen on the B channel.) Okay, one thing in common, the B cable has no shell so it has never been tightened onto the chassis and I had not tightened the A cable when connected to the B chassis. Watching a running spectra, I tightened the A cable into the B chassis--no change observed. Powered off the chassis and swapped the cables back A to A & B to B but did not tighten the screws--no noise seen once the signal settled down. Then tightened the screws slowly while watching the spectra--no change in the noise seen.
The second attachment below is after the cables were swapped back to their correct positions. Now looking closer and talking to Robert, we see that while the noise in the magnitude looks much better, it is still not as good in the coherence especially if you compare it to the Z channel. With all the swaps and tests, it may be the powering off of the interface during swaps or moves that causes the problem. This will be my next campaign; otherwise, move the HAM2 unit back into the BierGarten and swap the signals at the instruments.
Tested the shut down/restart theory. Over about an hour, I powered off the interface chassis and restarted it ~10 seconds later, five times over the course of this hour. No obvious change in the spectra observed. This power cycle is certainly quicker than the time to restart after switching cables much less to move the instrument from location to location, so, maybe, not a valid test. Maybe the 'change' requires being off longer. This morning when the extreme noise became just marginal, it was just a chassis cable swap but still probably took a couple minutes, not 10 seconds.
The Y channel signals for the HAM2 sensor have a bit worse coherence than the X channel, but the X channel too does standup to the solid coherence between ITMY & HAM5.
J. Kissel According to this morning's measurement of the DARM OLG TF (LHO aLOG 18352), comparing model against measurement -- which recall has a ~2.5%, 1 [deg] precision (see LHO aLOG 18186) -- the DARM Coupled Cavity Pole (DCCP) frequency was 303 [Hz]. Just to refresh everyone's memory, since the DCCP's frequency has been constantly evolving, I list below the measurement times and the resulting DCCP frequency for all measurements thus far. As mentioned in LHO aLOG 18352, now my goal to data mine as much information as I can, similar to what Kiwamu has done for just two of these measurements, see LHO aLOG 18298. Date UTC DCCP Frequency [Hz] 'Mar 10 2015 03:41:52 UTC' 320 'Apr 02 2015 08:34:20 UTC' 320 'Apr 06 2015 23:45:13 UTC' 320 'Apr 13 2015 04:15:43 UTC' 290 'Apr 13 2015 06:49:40 UTC' 290 'Apr 15 2015 07:53:56 UTC' 290 'May 01 2015 18:52:59 UTC' 355 'May 02 2015 20:35:54 UTC' 355 'May 06 2015 11:37:31 UTC' 270 'May 07 2015 07:08:12 UTC' 260 'May 11 2015 15:50:43 UTC' 303 The attached comparison only shows the latest 5 of these measurements for clarity, because they extend out to the largest frequency range, increasing the confidence in the DCCP frequency. Note this is also the reason why we've held off on updating the calibration of the CAL-CS (and therefore the GDS low-latency pipeline).
Last week we put the EY HWS on it's own separate power supply to see if this would reduce the 57Hz coupling of the HWS into DARM. This workes. When the EY HWS is on, we see no coupling into DARM at 57Hz. (See attached sprectum.) EX is still on the shared power supply, and the 57Hz line is clearly present. The current setup at EY is only as temporary setup. It looks like we should permanantly move all the HWS onto their own power supplies.
On Sunday evening Elli and Nutsinee logged another PSL trip here. Taking trends over this time shows that again the chillers appear to not be bringing down the PSL (first attachment). I've also attached trends over the same time period of all the flow rates: diode and crystal chillers, front end, HPO heads, and power meters. All these flow rates are where they are supposed to be. The third attachment shows all the interlock signals we capture. Only the H1:PSL-IL_OK trips, all other interlock signals indicate no problems.
Rick covered the PSL trip early Sunday morning in alog 18346.
One thing to consider is that the EtherCAT safety terminals go to their nominal safe position, if communication is interrupted. Assuming that the safe state of the terminal corresponds to the tripped state, any communication error between the safety PLC and any of its safety terminals can trigger a PSL shutdown. Maybe check the system for lost frames?
Seismic: No activities Suspensions: No activities CDS: Finish making CPS cables – Will install at BSC1, 2, & 3 during the Tuesday window. Continuing with work on AA/AI boards in H2 electronics building. PSL: Tuesday work on RefCav alignment and Laser/Chiller tripping problem. FMC: Painting in OSB Vacuum: Bake-out of RGA at End-X Software: Work on timing distribution system
Laser Status: SysStat is good Front End power is 31.8W (should be around 30 W) FRONTEND WATCH is RED HPO WATCH is RED PMC: It has been locked 0 day, 17 hr 30 minutes (should be days/weeks) Reflected power is 2.4 Watts and PowerSum = 24.4 Watts. (Reflected Power should be <= 10% of PowerSum) FSS: It has been locked for 1 h and 28 min (should be days/weeks) TPD[V] = .93V (min 0.9V) ISS: The diffracted power is around 7.8% (should be 5-9%) Last saturation event was 1 h and 29 minutes ago (should be days/weeks) NOTES:
Noise study recap for HAM2, STS2-A instrument:
STS2-A Noise identified at orignal location (not first time) aLog 18207.
STS2-A moved to BierGarten (on concrete & under igloo) with different field cable--still looked bad, 18305, 18307.
Satellite cable and box swapped with STS2-B, noisy Y channel still with HAM2 channel--18314 (comment to 18305.)
Field Cable swapped at Chassis end (STS2-A & B signals swapped--bad channel should now be seen on the B channel data): Noise goes away, not seen on either channel! Although the connector at Chassis for STS2-A had already been exercised when we moved to the new cable, this connection seems the suspect. aLog 18324.
Spent 10 minutes wiggling and straining the cable chassis connection but could not get the channel noise to come back--18326, comment to 18324. Chassis cables swapped back. Signals still look good.
Friday afternoon I moved the STS2-A back to its home igloo by HAM2 with its orignal Satellite cable and box. This morning, the noise has returned to STS2-A--see attached.
J. Kissel The last few measurements of the DARM open loop gain transfer function have revealed that the DARM coupled cavity pole has gone back down to 270 [Hz] and 260 [Hz] (not posted yet), from where it was at the mini-run at a consistent 355 [Hz]. We're at the beginning stages of tracking this change in frequency dependence "online" by comparing high and low frequency PCAL and DARM calibration lines (and considering adding a few more to increase the precision of the analysis), but until that analysis gets into full swing, I'm taking every chance I can get to measure the DARM OLG TF. Here's another data point. We're in the "LSC_FF" IFO state, with the request input power at 10.7 [W], MICH subtraction ("FF") was ON, but the SRCL FF has a gain of zero (!! -- forgive the file names "FFon," I hadn't actually checked until writing this log). I'll have some more complete analysis (and an answer of what today's DARM coupled cavity pole frequency is) shortly.
I've learned from Kiwamu this morning that the ITM control loops were OFF during the mini-run, and they're OFF now. Unclear if/when Evan & Shiela had them over the course of the measurements. On my list of things to track down during all measurements to see if they affect the DCCP and I can find a pattern: - ITM alignment loops (differential ITM alignment influence is still under suspicion) - ITM/ETM optical lever - TCS power on ITMX (for SRC mode-matching) - Transmitted Arm Cavity power (to track carrier PRC gain) - POP18 / AS90 power (to track sideband PRC gain, and decouple SRC alignment) - MICH / SRCL feed-forward status It's gunna be one heck-of-a detective's adventure. I hope it's fruitful.
Nutsinee, Elli
Today we noodled around a bit, but still don't have a measuremnt of SRC length. Once Rick had reset the PSL trip, we spent of time recovering the alignment, locked DRMI, got were ready to take a measurement when the PSL tripped again. Just like this morning, the PSL stystem status screen only showed the interlock ok bit was tripped. The diode chiller flow bit was green and the chiller was working fine. After talking to Rick, we used the PSL card in the key storage box in the control room to get into the diode room and reset the PSL. We are starting to get tired, and are calling it a day.
J. Kissel 5.6 Mag Earthquake near Japan at 2015-05-10 21:25:46 UTC. For quite some time, when an ISI's watchdog trips, it runs the equivalent of a "down" script via front-end code (see E1300685, installed circa Fall 2013). One of the many things the front-end down script does is to force the isolation feedback loop filter banks' gain to zero, 0.0. However, in the era of the Celerier system of SEI guardians, the ISI nodes are using some Jedi-Level-9 combination of the python tools in /opt/rtcds/userapps/release/isi/common/guardian/isigiardianlib/ to run the platform's isolation stages, and somewhere along the journey to "FULLY_ISOLATED," these filter banks are set to 0.1, and then 1.0 (and I don't think ever to zero, 0.0). Thus, when a watchdog trips, the new Set Point Monitor -- who thinks it's the only thing in control of these values -- sends a notification up the ladder that these gains to zero (0.0) have been changed by something other the guardian, i.e. the front end's down script. No big deal here, it just caught my eye while Elli and Nutsinee were asking me "Can I reset the SEI system... now? How about now?" after the earthquake mentioned above, and I recommended bringing the SEI manager to DAMPED (such they could regain alignment, but be robust while the EQ rings down). I presume we'd never notice, since rarely if every request this interim DAMPED state of the SEI systems these days, but in the interest of non-expert clarity, it would be good to sort this one out. I attach a screenshot of the relevant MEDM screens in this state. Also note ETMX HPI tripped which caused the ISI and SUS to go down a few seconds later, via horizontal actuators (see second attachment), and it looks to a pretty darn quick signal causing the trip. SYS_DIAG was reporting that the EX Tidal was near the edge of its range...
This is, as you say, not a big deal, and pretty easy to work around in guardian. We should modify the ISI guardians to reset the isolation gains to zero after a watchdog trip, thereby duplicating what is done in the front end watchdog reset code. Watchdog trips will then be followed by a brief SPM notifcation blip in the ISI guardians, which will go away as soon as the guardian itself sets the gain to zero, thereby achieving parity between the guardian SPM setpoint and the actual front end value. We should file this with the integration tracker.
This situation will keep happening during these kinds of watchdog trips until we make these changes to the ISI guardians.
General note: SPM notifications don't necessarily mean you need to do anything unusual or out of the ordinary. In this case the ISI guardians were telling you that something was a little strange, but overall the state was actually fine. The notification would have gone away as soon as you reset the watchdog and the ISI guardians started isolating the platforms (and changing the isolation gains). You didn't need to do anything special to deal with this situation.
The FSS was locking on a 01 mode when the resonant threshold is set to 0.55.
I raised it to 0.6 and it now locks on the 00 mode.
However, the transmission is now only 0.93, down from about 1.4.
Apparently the alignment into the RefCav continues to drift. The orientation of the 01 mode and the reflected spot indicat that is is off in both yaw and pitch.
Looks like the PMC input alignment could use a touchup too.
We should plan on touching up the alignments on Tuesday, if not before.
ElliK, NutsineeK, RickS
Looking at the CDS snapshots of PSL screens from home this morning, we realized that the laser had shut down.
As-found control room screens are shown in the snapshot below.
Epics channel trends indicate that the Beckhoff interlock (IL) transitioned about 6 hours ago, but none of the recorded inputs (including the chiller flow inputs) triggered (see trend plot below).
The External Shutter had not tripped on the PSL_laser.adl screen, and the chillers were still running.
In the Diode Room, the Status screen showed ony the "Interlock OK" field red, everything else under interlock green.
Because we had no indication that the source of the fault was the Diode Chiller Flow, I decided not to swap the Diode and Crystal chiller interlock cables.
We had some issues getting the system back on-line, apparently due to accidentally closing a screen on the Beckhoff computer. Eventually, we rebooted the computer and restarted the PSL software.
Evan, Sheila
The PSL has been working all night tonight. We got a chance to try SRCL feedforward. It works, but it doesn't improve the noise. We saw that we were able to reduce the noise coupling by 12 dB at first, but then later saw that the coupling was changing by about 6dB at most. The second time we tried it we did not get as good subtraction. Evan has new measurements of the SRCL coupling and frequency noise coupling to include in the noise budget over the weekend.
Other things:
We used the TMSY picomotors to center the beams on the QPDs, this didn't change the combination of QPDs we used for the ITM loops. We might want to check the normalization for the Y arm QPD next time we do inital alingment.
We can switch SRM coil drivers in full lock, PRM, PR2, SRM, SR2 are now in the guardian in the DRMI_ON_POP state.
We started to measure the ASC sensing matrix with all the loops closed including the ITM loops, we got a reasonable measurement for pitch, the data is all on disk although we had some trouble extracting it. We were in the middle of tuning the yaw excitations when we got another earthquake. We were moptivated to work on ASC because we have been aligning a little by hand before turning on the ASC all night, and we are hoping to find more diagonal signals so that we don't have to do this each lock.
Here are the new SRCL and frequency noise couplings projected onto DARM.
The good news is that we no longer seem to have a frequency noise coupling shelf around 100 Hz. It also seems that the SRCL feedforward pushes the SRCL noise down below 10−19 m/rtHz around 80 to 100 Hz. But somehow the noise in DARM in this region still seems to be nonstationary and (qualitatively) we haven't really seen any noticeable noise reduction here.
I repeated the SRCL injection measurement on Saturday, and got similar results as what is shown here.
The MICH and intensity noise traces are stale and need to be retaken. However, I did not see coherence between MICH control and DARM when looking at the control noises.