[JeffK, Jenne]
With the current alignment of the IFO (same QPD setpoints for POP_A and SOFT), we reset the green initial alignment setpoints for the Xarm green WFS and camera spot.
We tried to move the Yarm input pointing QPD setpoints by hand to get the Yarm green to lock while we are locked, but couldn't get the Yarm to lock on a 00 mode without falling off the PD. So, for now, rather than pico-ing, we have left the Yarm initial alignment setpoints alone (reverted to how they were earlier today).
We're considering moving our POP and / or SOFT setpoints to get POP18 back up and more smooth, so we'll just live for now with having to engage the full ifo asc slowly.
I did two things to prep for ER13:
EXCLUDE_NODES = [
'BRSX_STAT',
'BRSY_STAT',
'BOUNCE_MODE_DAMPING',
'CDS_CA_COPY',
'DIAG_MAIN',
'HIGH_FREQ_LINES',
'INJ_TRANS',
'IMC_LOCK',
'ROLL_MODE_DAMPING',
'SEI_CONF',
'SQZ_SHG',
'SQZ_OPO',
'SQZ_PLL',
'SQZ_FREQ',
'SQZ_CLF',
'SQZ_LO',
'SQZ_BEATNOTE',
'SQZ_LOCK',
'SR3_CAGE_SERVO',
'SUS_CONFIG',
'SUS_OPO',
'SUS_PI',
'TCS_RH_MON',
'VIOLIN_DAMPER',
]
At Rana's suggestion, I'd like to have the operators or commissioners run a script I've written during sometime when the IFO is left locked on it's own (i.e. commissioners are done and leaving and the IFO is in at least DC Readout). The script just makes tweaks to the out put gains of the HAM2 & HAM3 FIR sensor correction gains. After the script is run, I'll collect data and see what settings (if any) seem to work best for the interferometer. The script will keep running while the IFO is locked, but should quit if it unlocks. Rana has said he has some stuff to add to make it quit gracefully that he plans to share in the alog.
The script is in userapps /isi/h1/scripts and can be run from the command line by typing ./imc_sc_gain_diddle.py in that folder. If someone could try running this over the engineering run, I would appreciate it.
This is just a reminder that in November, with the same TCS settings that we are currently using, we were able to power up to 28 W and be stable for about 4 hours. We were also locked at 32W input power for about 15 minutes.
If people want times to compare current power ups, ASC settings, ect to compare to these locks were Nov 11th from about 1 UTC to 14 UTC. Some trends are attached here.
TITLE: 12/13 Day Shift: 16:00-00:00 UTC (08:00-16:00 PST), all times posted in UTC
STATE of H1: Commissioning
INCOMING OPERATOR: None
SHIFT SUMMARY:
14:50 (6:50) Rick and Sudarshan to EY -- End station calibration
15:20 (7:20) Chris to MX -- scaffold setup
16:00 (8:00) Phiffer on site
16:00 (8:00) Start of shift
16:35 (8:35) Karen to EY
16:40 (8:40) Fil, Ed to EX
16:47 (8:47) Karen leaving EY
16:53 (8:53) Richard to LVEA -- check out ALS fibers
16:54 (8:54) EY back to laser safe
17:12 (9:12) Richard out of LVEA
17:17 (9:17) Karen to LVEA
17:27 (9:27) Vanessa to LVEA
17:27 (9:27) Ed, Fil back from EX
17:31 (9:31) Chris to LVEA -- grab scaffolding
17:45 (9:45) Richard to CER
17:58 (9:58) Chris out of LVEA
18:05 (10:05) Vanessa out to LVEA, going to EX, MX
18:45 (10:45) Nutsinee to ISCT6
18:56 (10:56) Chandra to LVEA
18:59 (10:59) Nutsinee out of LVEA
21:45 (13:45) Chris to MX
22:26 (14:26) Nutsinee to ISCT6
22:29 (14:29) Chris back from MX
00:00 (16:00) End of shift
Dan Brown, Danny V, TVo
Because backing off the TCS settings to a less aggressive pre-loading made DRMI locking easier, we wanted to know how different the wavefront and the spherical power readings are between the two pre-loaded states. Yesterday we were able to get approximately 5000 seconds of data before locking began where we made these TCS changes, attached is the time series and estimating the difference in spherical lensing:
Spherical power difference for ITMX: -8.0 udiopters
Spherical power difference for ITMY: +10.0 udiopters
They are seemingly small but maybe enough to be a problem in DRMI acquisition. I also attached a wavefront map which shows that ITMX has pretty good centering but ITMY shows considerable asymmetric heating, color bar is in units of optical path distortion (nm). This level of badness was not seen during our Thanksgiving tests so I'm a little perplexed on why this is so misaligned.
From looking at just the math the difference between the 50W and 30W preloading at 2W input power is (all single pass lens powers):
50W:
30W:
Overall the 50W preloading setting had slightly stronger lenses:
But the TCS guardian only tries to get the CO2 powers within +-80mW of the requested power using the rotation stage, so it doesn't seem that these preloadings are dramatically different.
The ITMY cooldown looks a bit odd because the CO2 and RH are not well aligned. This shows the interferometer beam is well aligned to the RH but the CO2 is slightly off, the red cross being the self heating deformation position during a powerup. The combined effect shows the ifo beam is in the linear looking wavefront distortion region so was probably experiencing a tilt and some higher order distortions. Could be why we were seeing a more astigmatic mode in the MICH dark with the 50W preloading. We saw after the vent they were not exactly overlapped, at the time we decided to leave it and run with the 50W loading to see how far we got.
ER13 operators can view the first 6 remote users logged into CDS from the CDS Overview MEDM (see attachment). For the full list press the "Remote Access" button.
With ALS glitching rearing its ugly head again We went through and tightened all of the connections and re dressed some of the fibers that would be vulnerable. Tightening connections at the phase box changed the phase EX from 21 to 46 degrees. Adjustment at all of the field connections glitched the system but EX settled back to 21 degrees EY went from 1 to 3 degrees. Jenne then adjusted the phase down to 16. Squeezing also saw a change from our work though we did ot change anything on that path.
With the large excursions in MC_F this morning with ALS locked, I tried increasing some gain in LSC-MCL. It seems to be good so far, but I have not yet put it in the guardian. In LSC-MCL I have a new FM7 that I've been engaging by hand, and then have been hand-increasing the digital gain from 240 to 300. Even with this high microseism and high-ish wind, I'm able to stay locked on ALS for many minutes.
J. Kissel, K. Riles
As the hardware injection team debugs problems with the hardware injection system, Keith requested I turn off the output to the PINJX HARDWARE filter bank. I've done so.
Also, while thinking about hardware injections, I added a call to the
/opt/rtcds/userapps/release/cal/common/medm/CAL_INJ_CONTROL.adl
screen with calls to the PINJY infrastructure installed in October (LHO aLOG 44264). It's output is all turned off as well.
In alog45288 we measured 44% transmission from ISCT6 fiber coupler into chamber. Attached a plot showing transmission dropped over two days from Nov 30 to Dec 2. SHG launch shows somewhat constant power going into the fiber coupler while OPO REFL dropped 40% to 23%. Also attached another plot over 20 days. Terry also recovered ISCT alignment so we now have 83% transmission to the end of 5m fiber (alog45871). We've never recovered 40% level of transmission.
Some notes on locking tonight (Rana, Craig, Dan Brown, Terra, Sebastian, Sheila, Hang, TVo, Danny Vander-Hyde)
Violin modes:
We tried Jenne's new state which turns on all the ASC at the same time, which has worked twice. We have increased the thresholds used by the convergence checker a lot.
We have also turned on the OMC DCPD low pass filter. The OMC guardian can now be used to add and remove the low pass filter while we are locked on DC readout, and to add one additional stage of whitening, although we haven't tested the additional stage of whitening while on DC readout. The low pass is now turned on when we lock the OMC, which will make our dark noise bad enough to add noise to DARM. This should help us to avoid violin mode problems while we power up, we can either remove the low pass or add the next whitening stage to recover the sensitivty.
We have had lots of trouble with ALS, it seems like we have fast glitches which might be a problem with the fiber. We also have the micro seism around 1um/sec and wind gusts up to 40mph, so that is making the locking more difficult.
DRMI locking has continued to be much better with the preloading reduced.
When we acquire DRMI (ISC_LOCK_STATE_N ~100), the PRM is badly yawed. We've lost lock tonight during ASC a couple of times, so I took Jenne's new slow route through it this time. On successful locks tonight, the PRM (PRC1) loop has been railed slowly bringing the PRM into a reasonable place. Otherwise, our POPAIR18 has been incredibly "dippy", AKA large sideband power swings, often leading to locklosses after acquiring DRMI. We need to engage PRC1 right after catching DRMI to bring the PRM into a reasonable alignment before going on.
I attach the simulated HOM spacing of the arms: you can see the rises from self heating after we power up and then we lose lock at about the same thermal state/arm cavity config each time.
I attached a screen comparing the TCS with 50 Watt pre-loading (left) vs 30 Watt pre-loading (right).
We were able to stay locked at 25 watts input for many hours with the 50 watt TCS pre-loading but with about 700 mW of CO2 power left over on both CO2X and CO2Y. The 30 Watt TCS settings seem to be unstable within a few minutes of going up to 25 Watts of PSL input power. Both of them display a drop in POPAIR_B_RF18 that seems consistent with a thermal time constant and drop lock at around 53-54 counts. So maybe this points to more room for improvement with annular heating to try and push for higher stable power operation, but not so much pre-loading that it makes DRMI difficult to lock.
EDIT:
Sheila showed me some data from Nov 9th just before the vent where there was a 27 Watt input lock for about 4 hours so it is possible with the 30 Watt TCS pre-loading settings to stay higher.
We have been having locklosses due to the glitches which seem very similar to the ones that happened when we had a laser safety tag hitting the ALS fiber in the HVAC wind. This seems to have started or gotten much worse on tuesaday. We looked at fibers in the MSR, and they are still in their protective tubes.
Does anyone know of work on Tuesday which might have changed something near the ALS fibers?
At the PSL rack, there is still a laser safety tag which is zip tied to the fiber and hanging off of it, causing strain. I temporarily set this to rest on one of the chassis, but it would be good to remove the tag from the fiber if we can.
After I touched the fiber the polarization arriving at the end station was wrong. If looks as though the polarization controller has been in error since Tuesday maintence. I am not sure what the polarization error means, but it cleared when I turned the box on and hit the reset button.
tried some arm alignments and more fiber polarization settings and different seismic guardian states, but the ALS is not keeping locked long enough to get through the DRMI sequence. Need to debug ALS glitches.
h1omcpi and h1omc were changed and compiled but not installed (that's for Tuesday).
In h1omcpi, a decimation filter was put between the drumhead mode RMS (64kHz) and shared memory as the omc model works at 16kHz.
Alignment dither oscillators are common for deacon and normal dither. An input matrix is used for selecting the source of demod. This makes it cumbersome to switch between low frequency dither for deacon and high frequency dither for normal dither, but once deacon works it won't be an issue.
Done.
For now demod matrix is set up to use old dither (H1:OMC-ASC_DEMODMAT_1_1=0, H1:OMC-ASC_DEMODMAT_1_2=1).
Assuming that deacon needs dithering on the order of Hz, I put a 3rd order Butterworth LP at 0.1Hz for power normalization.
For passing drumhead RMS from 64kHz to 16kHz frontend, I used an equivalent of x4 decimation filter in T1600059 (but the data rate is 64kHz), in this case ellip("LowPass",6,0.3,60,7372.8).
I've populated the control filters in OMC_CUST_DRUMHEAD_EXC with bandpasses around each drumhead mode (I've not set up any of the other control filters). I also cleaned up that medm screen a bit so that drives now go to all test masses correctly. In the main PI screen, I've allocated and set up the 8th downconversion and upconversion blocks for these drumheads. If I populate the BEACON_DRIVE_MTRX, I see signal in the PI drive channels, but I haven't tested beyond that yet.
Modes are: ITMX 8156.7 (A), ITMY 8163 (B), ETMX 8158.6 (C), ETMY 8153.5 (D)
Kyle and I spent the afternoon with GV11 slowly opening it and releasing gate o-rings is small incremental motions (powered the motor ~10 times up to 1000 rpm first time and then 500 rpm increments, over two days). We heard a loud noise at the top of the valve on the last incremental stroke and then continued to open the valve, observing the ball screw moving up. The status of the valve did not change from red to yellow on MEDM screen, so we suspect the limit switch broke. Therefore, we didn't want to open the valve fully to avoid utilizing the hard stops. We will investigate on Tuesday.
Prior to opening GV11, we leak checked the RGA manifold and new flanges around CP4's 10" GV. There was some sporadic He signal around the full range gauge area but nothing above 2e-9 Torr. The RGA will be rebaked later and that area will get leak checked again.
RGA was scanning before, during, and after GV11 opened. Will process and post results Tuesday.
We also burped dry N2 into GV12's gate annulus and then fully vented it to discover it is also now leak tight!
We forgot to remove a jumper in the Beckhoff rack and to reinstall fuses, upon which the MEDM status showed yellow for status transition. We were still concerned about the loud noise we heard. Kyle and Gerardo noted a misalignment in the limit switch shaft and its corresponding pulley when a straight edge is placed next to mating gear pulley. The misalignment is slight (may have always been there), and we are not concerned about the pulley belt walking off. The valve opened successfully and MEDM shows it as green.