TITLE: 12/13 EVE Shift: 00:00-08:00UTC (16:00-00:00PDT), all times posted in UTC
STATE of H1: 4+ Hrs of locking (Almost 3hrs in Observing) at around 80Mpc.
Incoming Operator: Jeff B.
Support: Sheila On Phone at beginning of shift
Quick Summary:
Shift Log:
We shook the PSL table and all chambers at the corner station except ITMY individually. By far the greatest up-conversion was at the BS. The figure shows that even a 20% increase in 1-80 Hz GS13 BLRMS produces bumps at higher frequencies. The up-conversion from injected peaks is not broadband like magnet domain changing noise, and is not a harmonic series like from scattering or saturation, but, instead produces peaks that look like intermodulation products.
Robert, Jordan
After the Initial Alignment, it took about 60-90min of attempts with H1 falling out at various points (as noted in newsreel posts earlier). Finally made it on this current attempt. No real issues, other than needing to engage the ISS 2nd ISS Loop by hand (per Kiwamu's alog 22449). So, the latter causes the range to look low (~30Mpc a few minutes) while engaging 2nd Loop. I actually took a little time here to read the alog, and put the output channel on a striptool, so I would have a better idea of when to turn ON the 2nd Loop.
range is has been hovering at a shy 80Mpc. NO SDF diffs
Observatory Mode is now: COMMISSIONING (this is due to Robert beginning chamber-shaking injections; he said on the order of ~1hr.)
Off to make supper.
Making notes from Initial Alignement work, locking and chatting with Sheila:
Initial Alignment:
Locking
DRMI locking: POP18 & 90 looked good with flashes flashing up to 150-200 on dataviewer, BUT the AS camera would have some ugly modes every min or so. Have had a DRMI lock...but only for a about 20sec and then 18 & 90 dropped. Might look at PRMI....oh wait, DRMI LOCKED....Stay tuned!
Comepleted CARM_5PM, dropped while in RESONANCE Guaridan state:
2015-12-14T02:22:27.22172 ISC_LOCK executing state: REFL_TRANS (409)
2015-12-14T02:22:27.22198 ISC_LOCK [REFL_TRANS.enter]
2015-12-14T02:22:27.48413 ISC_LOCK [REFL_TRANS.main] ezca: H1:LSC-REFLBIAS => ON: FM2
2015-12-14T02:22:27.52074 ISC_LOCK [REFL_TRANS.main] ezca: H1:LSC-TR_REFLAIR9_TRAMP => 0
2015-12-14T02:22:33.39102 ISC_LOCK [REFL_TRANS.main] ezca: H1:LSC-TR_REFLAIR9_OFFSET => -0.112938329577
2015-12-14T02:22:33.78661 ISC_LOCK [REFL_TRANS.main] ezca: H1:LSC-TR_REFLAIR9 => ON: FM1, FM2, FM5, OFFSET
2015-12-14T02:22:33.79052 ISC_LOCK [REFL_TRANS.main] ezca: H1:LSC-PD_DOF_MTRX_SETTING_9_27 => 3.0
2015-12-14T02:22:33.79147 ISC_LOCK [REFL_TRANS.main] ezca: H1:LSC-PD_DOF_MTRX_SETTING_9_26 => 0.0
2015-12-14T02:22:33.79198 ISC_LOCK [REFL_TRANS.main] ezca: H1:LSC-TR_REFLAIR9_TRAMP => 2
2015-12-14T02:22:33.79250 ISC_LOCK [REFL_TRANS.main] ezca: H1:LSC-PD_DOF_MTRX_TRAMP => 0.2
2015-12-14T02:22:33.79846 ISC_LOCK [REFL_TRANS.main] ezca: H1:LSC-PD_DOF_MTRX_LOAD_MATRIX => 1
2015-12-14T02:22:33.80202 ISC_LOCK [REFL_TRANS.main] ezca: H1:LSC-ARM_INPUT_MTRX_LOAD_MATRIX => 1
2015-12-14T02:22:33.88079 ISC_LOCK [REFL_TRANS.run] USERMSG: Input matrix not ready.
2015-12-14T02:22:33.88557 ISC_LOCK [REFL_TRANS.run] ezca: H1:LSC-PD_DOF_MTRX_LOAD_MATRIX => 1.0
2015-12-14T02:22:33.89565 ISC_LOCK [REFL_TRANS.run] ezca: H1:LSC-ARM_INPUT_MTRX_LOAD_MATRIX => 1.0
2015-12-14T02:22:35.14264 ISC_LOCK [REFL_TRANS.run] MC not locked
2015-12-14T02:22:35.19776 ISC_LOCK state returned jump target: LOCKLOSS
2015-12-14T02:22:35.19798 ISC_LOCK [REFL_TRANS.exit]
Contacted LLO, and sounds like they are possibly just past the peak of noisy storm activity....and the forecast may lead to them being back online sooner (few hours) rather than later (tomorrow). Robert's determining a game plan for his injections.
I did try an attempt with ETMX with 45mHz on x & ETMy with 45mHz on y for the Blends, but no change. So I went back to having both x & y axis 45mHz blends for both etms.
TITLE: 12/13 EVE Shift: 00:00-08:00UTC (16:00-00:00PDT), all times posted in UTC
STATE of H1: DOWN
Outgoing Operator: TJ
Quick Summary:
After getting hand-off from TJ, will take another look at Input Alignment (will watch x-arm power on DV & also the AS camera to look for obvious misalignment...if needed, will tweak PR2. Will also increase XARM digital gain to see if this helps as well [these were suggestions Sheila gave me over the phone]). If this does not work, I might look at Input Pointing over the last few weeks/months to see what our current state looks like compared to the past.
Conditions look decent (no winds, under 10mph), but useism is still roaring (LVEA is hovering around 1um/s).
Currently, all ISIs have their 45mHz Blend Filters ON. When we are dealing with noisy useism, Jim mentioned we should keep the 90mHz Blends on for the ETM off-axis Blends (i.e. ETMx ISI has 45mHz for X-axis & 90mHz for Y-axis, and similarly for ETMy ISI). But since we are dealing with pretty noisy conditions, Sheila thought we should run with all 45mHz on. She checked the recent locklosses from home to confirm we weren't ringing up the ISIs due to doing this---> and we weren't, so she suggested we continue to stay with all the Blends ON.
OK, onto Initial Alignment!
TITLE: 12/13 Day Shift: 16:00-00:00UTC (08:00-16:00 PDT), all times posted in UTC"
STATE Of H1: Down
SHIFT SUMMARY: I managed to relock the IFO for about 4hrs, but then after I haven't had such a good time. Robert and Jordan went in to relocate some shakers, but this tripped the ISI's for ITMX, BS, and HAM3. After that I had to redo the initial alignment, but I couldn't get INPUT_ALIGN to work. I have trended values to see where they were before the WD trip but this hasn't made anything better (worse probably). Hopefully Corey has some more tricks up his sleeve.
INCOMING OPERATOR: Corey
ACTIVITY LOG:
Really similar to alog24151 from yesterday. Saw the oscillation buid up and had no idea how to stop it.
We've left the ETMX ISI on 45 mHz blends in both X and Y on ST1, so I was worried that these locklosses could be reappearance of the problem described in 23674 . At least this one seems to be a different problem, this is a pitch oscialtion at around 0.4 Hz that shows up in all test mass oplevs, and seems to be in common soft if all the signs on these oplevs are right. It rings up over the last 2 minutes of the lock or so. It doesn't show up in any of the arm ASC control signals. It does show up in SRC1 (AS36I->SRM)
Pat Meyers, Nelson Christensen, and I have been investigating coherence lines between H1 and L1 in the 20-45 Hz band (data generated from stochmon, found here). We cross-referenced these lines with using results from STAMP-PEM and the coherence tool.
You can find results for our analysis around 25 Hz here. Attached is an analysis of coherence lines at H1 from 36-42 Hz. There are interesting lines at approximately 41 Hz and 38.7 Hz.
Our corresponding results at L1 can be found here.
Pat, Nathaniel, Nelson
Back to Observing, Robert is done for now. Wind <20mph, useism 1um/s, lights off, CW inj running, 21.9 W.
LLO is still down and will probably be for some time, they have a large storm coming through.
C. Cahillane Here is the uncertainty budget for LHO. PDF 1 contains the C01 uncertainty budget. PDF 2 contains the C02 uncertainty budget. C01 leaves the kappas uncorrected, while C02 is the "perfect" calibration with kappas corrected. Both C01 and C02 have the static systematic errors corrected. C00 is the so-called "Nominal" model. To see the differences between C01 and C02, see PDF 5. The uncertainty budget is dominated by the magnitude sensing function. This is due to its nonlinear systematic error at low frequencies. You can see this in PDF 4. The actuation fits are in PDF 3. LHO has strain uncertainty of under 5% and 3 degrees. (See Plots 8 and 9 in PDF 1 or 2)
Made it to NLN, I think I got lucky with the winds dropping to 20mph.
Robert will start his inj here in a min.
Went into Observing until Robert is ready, to do that I had to accept an SDF diff for the PSL-ISS_LOOP_STATE_REQUEST. SDF reports that it should be OFF, it is currently ON. Peter K says that this is for the integrator for the autolock and should be on, so I have accepted it and we are in Observing.
The diffracted power for the ISS was going from 0 to 20% on the MEDM screen and both Travis and Jeff were having problems getting the servo to lock. I tried the following steps to see what the behaviour was: - the autolock was dis-engaged - decreased the gain from 16.0 dB to 3.0 dB -> no effect - increased the magnitude of REFSIGNAL from -2.02 to about -2.30 -> no real improvement - turned off the integrator -> no real improvement - turned off the second loop -> no improvement Then it was onward to some signal tracing ... The ISS acousto-optic modulator (AOM) gets its 80 MHz RF input from one of the oscillators in the ISC. According to the ISC_CUST_REMOTERACKS MEDM screen it'd be the VCO in slots 24 and 25. Its output is amplified by the amplifier in slot 23. The output of the RF amplifier was relatively stable, so it was not the cause of the behaviour observed with the diffracted power. From the ISS MEDM screen, there were no indications of any signal injections. Switched AUTOLOCK off and went to manual mode. Turned off the integrator. If it were a loop oscillation, reducing the gain slider ought to help. The gain slider was reduced back down to 3.0 dB. The output AC of PD B indicated that the loop was sporadically locked but the diffracted power was still varying wildly. Moved REFSIGNAL in the other direction, dropping it as low as ~ -0.8. It was here that the loop showed signs of it being solidly locked according to the output AC of PDB. However the diffracted power was around 50%. REFSIGNAL was then slowly adjusted to bring the diffracted power to about 16%. The servo gain was then increased back to its nominal value of 16 dB. Everything seemed fine at this point, so the reference signal was adjusted to -1.98 which brought the diffracted power to ~ 7%. The integrator was engaged, which resulted in a decrease in the diffracted power. The second loop was turned on, but not engaged, without any detrimental effects. AUTOLOCK was restored. (see ISS-Summary1.png) At one point the diffracted power did vary and this coincided with the IMC dropping out of lock (see ISS-medm1.png and ISS-Summary2.png). One can see in the summary plot three small peaks in the diffracted power, AOM driver monitor output and PD B output that coincide with when the IMC dropped out of lock. So now the question remains as to why this was happening. The location of the photodetectors for the first loop ISS is after the pre-modecleaner. Obviously in order for them to see light, the pre-modecleaner must be locked. Which in turn relies on laser frequency excursions to be slower than the response time of the PZT and its high voltage driver. Left to itself, the laser frequency does not change much however it is driven by the need for the IMC to be resonant. This is split between the frequency shifting AOM in the FSS and the IMC suspensions. So if the IMC length changes, for whatever reason, one would expect to see changes in the ISS. A quick inspection of H1:IMC-L_OUTPUT to me suggests that it spent a fair amount of time swinging (see IMC-L.png).
In digging around the MEDM screens for the IMC, I noticed that all channels on the IMC-X_M1 MEDM screen did not resolve. A PV Info on any of the channels said that the IOC was disconnected.
I have edited the ISC_LOCK guardian so that it now turns violin mode damping off before the interferometer reaches nominal low noise. This will hopefully allow us to collect ringdown data on the violin mode fundamentals.
Violin mode damping is still turned on as usual in BOUNCE_VIOLIN_MODE_DAMPING, but it now is turned off in the COIL_DRIVERS state. Thus the modes will still receive a few minutes of damping before DARM is switched to dc readout.
If this behavior needs to be reverted, there is a flag in the main() function of COIL_DRIVERS called self.turnOffViolinDamping which can be set to False.
Violin mode damping in full lock will be re-enabled once sufficient data have been collected.
Are there any observable results from this? For example, does this mean we will now see these on the running power spectrum on nuc3? And is this the reason we now have the red boxes on the violin mode medm on nuc0? I hadn't noticed the latter before, so I was wondering why these were flashing red.
Since turning the damping off, the violin mode fundamentals seem to appear on the DARM FOM at the level of 10−16 m/Hz1/2 or so. Before turning the damping off, they would eventually damp down below 10−18 m/Hz1/2 after a few hours.
I'm guessing this is why the violin mode monitors are red, but I don't know what Nutsinee set the monitor thresholds to.
Also, since writing the above alog I changed the Guardian code for turning off the damping. It is no longer executed inside an if statement; it's just executed directly in the main() function of COIL_DRIVERS.