- TJ, Locking Operator, Cheryl, Operator Operator
- morning:
- afternoon: investigations by commissioners/others
- activities - short term
cabling in electronics room, Filiberto
Beckoff, Daniel
- activities - all day
EY, entry at 1:25PM, stayed 15 minutes
EX, entry at 2:15PM, stayed 15 minutes
CS LVEA, entry at 3:15PM, stayed 30 minutes
Currently commissioners have the IFO.
to help with getting the glitch rates, I'm running a script every minute which performs a DIAG clear on the models which are showing this issue. These models are: IOP-SUS[EX,EY], SUS-ETM[X,Y], IOP-SEI-E[X,Y], ALS-E[X,Y], ISC-E[X,Y].
Yesterday I started a cut-down version of this script which only cleared the ALS and ISC errors, however not every SUS glitch prodcues a remote IPC receive error so this was under counting.
We have noticed that in the past 20 hours only EY has glitched. We at still seeing two different types of IOP-SUS glitches either with or without a TIM bit setting.
On Monday, numerous ODC threshold values were changed, so says SDF. See attached snapshot of these diffs. I've asked around, but can't find who did made these changes... Anyone know? Are the new settings the best values to capture or do we need to revert?
The BSC's and HAM's have been handling payload watchdog trips differently for a while. The HAM's watch the SUS watchdog and do a running 10 second sum on IPC errors, so if the SUS model goes down for 10 seconds, the ISI will shut off. The BSC's have not been as smart. They watched the SUS watchdogs, but when they received a single IPC error, they would just trip. This is because the logic was incorrectly converting from an error rate. This wasn't an issue until recently because IPC errors were rare, but for now, the end station SUS computers are producing occasional IPC errors. Today, JeffK walked Hugh and I through importing the appropriate SEI library part to fix this. All BSC's have been modified at the top level, and all models compiled, we will wait until tomorrow to restart. We also cleaned up some redundant stuff on the top level. To wrap up, Hugh commit the changes to the SVN. Attached screens show the changes. Unfortunately, I didn't get a before shot, but the changes are a lot cleaner. We should get many fewer end station trips after the models are restarted.
Patrick, Daniel Accidently stopped when we logged out of the controls account. It automatically restarted when we logged back in. The settings appear to be back, so no burtrestore has been done. However this is something to check if a problem arises.
Summary
A lower-estimate of absorption in the end test masses was measured using the end-station HWS cameras. This can be used to get a lower estimate of absorption in the test masses. I only got 30mins of data with the interferometer locked at 3W, we should repeat this measurement for a longer lock stretch to get a better idea of the absorption in the end test masses. The current measurement gives an absorption of 230ppb in ETMY and 130ppb in ETMX. Becasue we only measured for a 35min lock stretch, this will be an underestimate of the true test mass absorption. Also, the ETMY HWS measurement looks untrustworthy, so it would be worth checking the PZT off sets.
Details
The EMT HWS cameras use the green als beam to measure the curvature change of the ETMs. We want a single reflection of the green beam off of the ETM, we cannot take this measurement when the green beam is resonant in the arm cavity. The green beam is usually shuttered and not present in the interferometer once the interferometer has reache DC_READOUT. To take a measurement with the HWS, once the interferometer is at DC_READOUT and the green beam is shuttered and no longer used, we re-open the ALS shutters and mislalign the green PZTs enough that the HWS sees no return beam from the ITM, only seeing a single bounce off of the ETM. I choose the PZT misalignment offsets as stated in alog 17860. Pictures of the HWS camera images are attached. Both cameras measure 22 centroids. The X-end image does not show a nice round beam, I may have to adjust the PZT alignment offset settings for this arm.
HWS reference centroids were taken before any locking started, with green PZTs in same misaligned state as we use when taking a measurement.
The ALS X/Y PZT2 are misaligned with type 'fixed', and with misalignment offsets:
H1:ALS-X_PZT2_PIT_MISALIGN_BIAS=15500
H1:ALS-X_PZT2_YAW_MISALIGN_BIAS=8300
H1:ALS-Y_PZT2_PIT_MISALIGN_BIAS=16100
H1:ALS-Y_PZT2_YAW_MISALIGN_BIAS=12000
The change in the spherical power of ETMY was 30udopters and ETMX was 11udiopters over a 35 minute lock stretch at 25.3W input power. For a change in spherical power of 1udiopter, 1.06mW of power is absorbed, according to Aidan's model of the test mass absorption (LLO alog 14634). The input power was 1.7W into the IMC, assuming 0.88 IMC-Faraday throughput efficency, 45 recycling gain, 280 arm cavity gain, 50:50 splitting ratio at BS, then 25.3*0.88*45*.50*280=140.3kW stored in the arms. Absorbed power/stored arm power = optical absorption. (Arm cavity gain is calculated using G_arm=(t_ITM/(1-r_ITM*r_ETM)).^2, where r_ETM=sqrt(1-TETM-L) and L=120ppm=loss in the arm. ) The arm power can also be caclulated using the four ASC_TR QPDs, which agree with the calulation using IMC input power, the variation between the four QPDs puts the uncertainty of the arm power at 15%.
Attached is a dataviewer plot of the HWS spherical power output during a 30min lock at 25W. The shutters are opened when the shutter value=0. I have calculated an absorption value for both test masses, but the spherical power inn the ETMY is growing in the wrong direction. Either there is a sign error in a model or script somewhere, or this HWS is not set up correctly currently. I will investigate this.
ETMX | ETMY | |
spherical power at start of lock stretch at 23Jul 17:49:00 UTC(diopters) |
2.3e-5 |
-4e-5 |
spherical power at end of lock stretch at 23Jul 18:34:00 UTC (diopters) | 3.5e-5 | -7e-5 |
change in spherical power (diopters) | 1.1e-5 | -3.0e-5 |
absorbed power in test mass | 18mW | 32mW |
power in arm | 140.3kW | 140.3kW |
test-mass absorption (ppb) | 130ppb | 230ppb |
This measurement assumes the test masses have had enough time to reach thermal equilibrum, which actually takes longer than 30 mins. This means that the absorption measurement is an underestimate. It would be desirable to get a measurement of a lock stretch of >1hr. The HWS measurement itself is quite noisy.
I've updated SDF to accept the new MISALIGN OFFSETS above.
Hannah, Stefan We were investigating some noise in the 70-100Hz range. Following up with Gabriele's alog (19756) we decided to check the RF36 channels and their coherence with the OMC-DCPD. ASC-AS_A_RF36_I_PIT and ASC-AS_B_RF36_I_YAW do appear to have some increased coherence in this range, but they also have a broadband coherence from 100 to at least 900Hz. We're still working to find a theory to explain this. There are also some peaks in the coherence between PSL-ISS and the OMC-DCPD. However, the AS RF36 channels do not seem to correlate with peaks in intensity noise, suggesting some other source of noise. We will investigate the higher frequencies during the next lock.
Summery:
DRMI_1F would not lock until I paused ISC_LOCK and ISC_DRMI
The majority of the morning was spent trying to get past DRMI_1F. What eventally did it was pausing ISC_LOCK and ISC_DRMI.
Overview:
When I arrived this morning, ISC_LOCK was stuck on CARM_ON_TR with a message saying that there was no IR in arms. Sheila had an alog from last night (alog 19821) which mentions this problem and her work around. I switched to manual and reran the PREP_TR_CARM state but that did not fix the problem.
I brought ISC_LOCK to Down and went to redo the green alignment but I couldn't get ALS_YARM to get out of the Unlocked state. To fix this I had to Unmanage ALS_YARM because it would stall and immediately go to the unlocked state.
Relocked green and then tried to lock the whole IFO again.
This time it would not get passed DRMI_1F. The AS_AIR cam looked round but it would not lock. Just incase, I tried slightly tweaking the PRs and SRs but no luck.
Went through IA since I wasn't sure what else to do. All went well there, but I had to take ALS_YARM to unmanged again.
It got through DRMI but lost lock a second time on PREP_TR_CARM. Laser powere was 1.7W , not sure if that was too big a problem.
Round 3. FIND_IR took quite a bit longer than usual but it eventually made it. Got stuck on DRMI_1F, alignment didn't look so good this time, a fair amount of pitch. I touched BS and PR2 and it almost caught a few times but no luck.
I decided to bring it back to Down and get the laser power where it should be. I found home for the rotation stage and then brought it back to 2.3W.
Round 4. FIND_IR taking its time again, but made it. Stuck on DRMI_1F again. The AS_AIR cam looked better than last time and StripTool was showing good flashes, but it wouldn't lock. Ed suggested to Misalign SRM and try to lock as a PRMI. I got it to lock as a PRMI in an odd mode, and I was able to bring the traces for ASAIR RF90 and POPAIR RF18 up. When I tried to realign SRM it broke lock. Ed talked to Kiwamu and found out that since we did not pause the Guaridans this realignment kicked it too hard.
Round 5. Stuck on DRMI_1F again so we went to pause ISC_LOCK and ISC_DRMI so that I could misalign SRM and see if I could get a PRMI again. Soon as I paused these guardians, the ASAIR cam looked like it was locked... because DRMI was locked! ASAIR RF90 and POPAIR RF18 looked good as well. Odd. I unpaused the guardians and it moved right on to DC readout no problem.
Elli said to wait at DC Readout for ~15min to allow the ASC loops to work their magic (paraphrased)
NOMINAL_LOW_NOISE @ 10:22 PST
Kiwamu broke lock loading some new filters and this time, ISC_LOCK went right through DRMI_1F.
NOMINAL_LOW_NOISE @ 11:05 PST
TJ was able to troubleshoot a few nuances from the slow locking this morning in order to bring the full lock up to NOMINAL_LOW_NOISE (more details from him later). After a Kiwamu DARM filter load broke the lock, Kissel and I took the opportunity to LOAD COEFFICIENTS on a few of the FE's that showed partial loads. In order to minimize the risk, we only performed the load coefficient on:
L1LSCAUX (benign LOCKIN and readback channel stuff)
H1TCS (Aiden filter tuning from yesterday)
H1SUSITMX and Y (Nutsinee DAMP filter tuning the other day)
H1OAF
Attached shows a picture of all FEs with the handful of other FM changes which were only locally loaded. (Local loading is ok, but it masks Dave's tool which reports dates of when full loads happen.)
LVEA: Laser Safe Observation Bit: Commissioning 06:50 Richard – To all buildings to check property 08:00 Reset TIM, IPC, and ADC errors 08:35 Earnest – From Caltech on site for property checks 09:15 Peter & Earnest – Going into H2 PSL and IOT2R table for property checks 09:20 Goodwill on site for a pickup – Bubba to escort 09:30 Richard – Going into the Optics lab to check on property 09:45 Filiberto – Cabling work in electronics room
Found the H1ASC EXC bit flag enabled this morning on the CDS overview. Since locking is slow, I went ahead and assumed this was left over from midnight work, I cleared them via
diag -l
tp clear 19 *
Attached is a 6 day trend of the H1IMC-PWR_IN showing how the rotation stage finds a variety of stopping places when executing the same request. This is a long-time known issue, so I'm just reposting to make the problem visible again. In theory the asc/lsc is supposed to compensate for power-in differences, but a it's hard to hand-wave off a ~25% difference from one down state to another - it makes troubleshooting slow acquisition more muddied than it already is.
Earnest from Caltech on site for property checks SEI: Prep for Thursday maintenance FMC: A wooden post near the chiller yard was knocked down. Bubba is repairing. Beam tube cleaning on the X-Arm continues Joint sealing continues on the Y-Arm Thursday Maintenance Activities: PSL - PMC alignment FSS – Electronics upgrade BSC-ISI – Payload watchdog fix PCAL – End-X clipping investigation LYLN – Driver commissioning Cosmic ray detector work HEPI – Accumulator fix End-Y
attached is the restart report for Tuesday maintenance. The frame writers appear to be more unstable following the fiber channel change.
J. Kissel, K. Izumi, J. Driggers This morning, we had a little trouble relocking the IMC because the initial alignment of the IMC SUS causes the light on the IMC WFS trigger PD to be just a hair too low. To solve the problem this morning, Jenne temporary decreased the trigger threshold (H1:IMC-IMC_TRIGGER_THRESH_ON) from 40 to 15 [ct], such that the IMC WFS engaged, which steered the IMC to our known good alignment (and then restored the trigger threshold once the WFS had steered the optics back to a good enough alignment that the normal trigger threshold was easily surpassed). To avoid this in the future, we said "we should offload the DC value of IMC WFS control signal to the MC SUS alignment offsets," but at the time didn't know that was the right script / button / thing to call in order to do so since there have been many in the past which had suffered from bit rot. Just now, in between lock attempts, I've asked Kiwamu what the right script is, he should me, and I ran it. This changed the alignment offsets as follows: Before After H1:SUS-MC1_M1_OPTICALIGN_P_OFFSET 1207.50 1208.3750756649936 H1:SUS-MC1_M1_OPTICALIGN_Y_OFFSET -2025.30 -2024.9455029701996 H1:SUS-MC2_M1_OPTICALIGN_P_OFFSET 527.00 525.7250127471385 H1:SUS-MC2_M1_OPTICALIGN_Y_OFFSET -534.03 -535.7085973743652 H1:SUS-MC3_M1_OPTICALIGN_P_OFFSET -722.14 -721.3522559898023 H1:SUS-MC3_M1_OPTICALIGN_Y_OFFSET -2034.10 -2034.4394052459747 I've spoken with Kiwamu about the seeminly-now-prolific issue of using double-precision python scripts to produce calculated EPICs settings to ridiculous precision, and he agreed to fix it in due time. The script that does the offloading is launched from the IMC WFS MASTER screen, from the bright blue button marked "! OFFLOAD WFS" just below the output filters in the middle-bottom right. See attached screenshot.
This alog doesn't really state it, but I assume the PZT is off loaded as well. I also assume each TM is off loaded individually.
Daniel,
RickS, Sudarshan, Darkhan
We've adjusted PCALX, PCALY and ESD calibration line drive levels to give a signal to noise ratio of about 100 (for 8 s FFT) over the mean science mode spectra from ER7.
The following lines have been adjusted:
Line | Frequency (Hz) | Old drive level (ct) | New drive level (ct) |
PCALX | 33.1 | 38 | 700 |
PCALX | 534.7 | 6000 | 19300 |
PCALY | 36.7 | 40 | 320 |
PCALY | 540.7 | 5000 | 9900 |
ESD | 34.7 | 0.50 | 0.22 |
ESD | 538.1 | 0.20 | 2.40 |
I added pcal lines at 325.1 Hz, 3000 ct for X and 331.9 Hz, 1500 ct for Y. These are maybe not optimal because they are in the region of the PSL piezo mirror mount, but I wanted to stay close to the DARM pole and out of the bottom of the bucket.
Based on noise levels around calibration lines during ER7, to get SNR of 100 (with 8 s FFT) , drive levels adjustments needed for LLO calibration lines:
I inserted a nototch filter for each of the two lines that Evan added last night. Because of the limitation in the number of the IIR coefficients, I had to put one in suscomp (in FM7) and the other in ResG (in FM3). The previous notch that we put for the cavity pole tracker (alog 18401) was removed from FM7 since we have not been using it.
J. Kissel, B. Weaver Betsy and I have updated the end-station SUSAUX top-level models to include Stuart's new library block for the HV and LV ESD analog readback monitors, as per WP 5373, ECR E1400232, II 859. with the changes as described in LHO aLOG 18819, and obeying wiring diagram D1400177 , specifically p11. They been compiled against RCG 2.9.5, we'll wait for Dave to confirm that we want 2.9.5 or 2.9.6, and will install later in the morning, as per today's schedule (LHO aLOG 19770).
This models have been installed, compiled against RCG 2.9.5 (given the issues with RCG branch 2.9; see LHO aLOG 19793). All channels appear functional, but now we see that the digital monitor channels that were in the QUAD AUX model (which are white on the AUX overview) are now in the QUAD MASTER model have turned into bits (which are now green / grey and alive); see attached. @Stuart -- should we remove these white channels from the AUX overview screen? Note -- the cable for the digital monitoring doesn't yet exist, so the new digital monitor bits are at the moment meaningless.
h1susaux ex and ey model updates as per the above have been committed to svn.
During this morning's SUS Detector telecon, Stuart pointed us to an LLO alog about similar timing glitches observed on l1susb123 (also a new fast FE machine). See LLO alog 19236.