The ITMX HWS is not currently seeing a return beam. I will investigate this further in the morning.
Attached picture shows the PR2 scraper baffle when DRMI is locked.
Light blob from the right edge of the baffle hole is probably some scattering even though the scattering itself should be pretty weak.
What is strange is that the baffle hole looks offset to the left (west) by quite an amount.
I cannot prove that this is due to some parallax effect, but if anything the camera is looking at the baffle slightly from the east (right), about 16m away.
Anyway, there shouldn't be any offset, the hole is centered in the baffle (see D1000328 and especially Z-plate). If there is an offset, however, that agrees with the fact that the beam is close to the baffle edge AND that the beam was close to the center of PR2 when the clipping was worse.
We need to open viewports and see what's going on.
9:02 Ace on site inspecting septic system
9:08 Filiberto and Aaron to EX, EY for PCal cabling work
9:12 Jim B restarting HAM 4, 5 models to fix WD issue
9:40 Jonathan investigating NDS2 server
9:47 Aidan to HAM 4 area TCS work
11:04 Aidan once again to HAM 4 area
11:10 Doug to LVEA looking for circuit boards
11:12 Kyle to EY dropping off parts
12:14 Fil and Aaron back from end stations
12:35 Cris to EX
13:54 Doug to LVEA recentering SR3 OpLev
I installed the changes to the HWSY optical layout per T1400686. To do this, I:
wus command on the HWS camera to set this to the default frame rate to use whenever the camera powers on.stream_image_Y command in /opt/Hartmann_Sensor_SVN/release/bin/stream_image_Y/distrib/ to view the image from the camera in real-timeThe return beam is shown below. I still need to move the HWS to the conjugate plane of ITMY and determine the magnification between those planes.
Doug, Rana, Evan
We moved the picomotors for the SR3 oplev in order to recenter it on the QPD. Previously, the oplev was at >30 urad in both yaw and pitch; now it is at <0.5 urad.
[Stuart A, Jeff K, Jeff B] In preparation for the QUAD model updates that were recently made at LLO (see LLO aLOG entry 15323), I've today svn'd up the common model parts directory, as follows:- /opt/rtcds/userapps/trunk/sus/common/models/ U QUAD_MASTER.mdl A ESD_LINEARIZATION_WITH_CHARGE_MASTER.mdl A ESD_LINEARIZATION_WITH_CHARGE_OUTF.mdl A FOUROSEM_DAMPED_STAGE_MASTER_WITH_DAMP_MODE.mdl U HLTS_MASTER.mdl U SIXOSEM_F_STAGE_MASTER.md U BSFM_MASTER.mdl U FOUROSEM_STAGE_MASTER_OPLEV.mdl U MC_MASTER.mdl U HSSS_MASTER.mdl U HSTS_MASTER.mdl U FOUROSEM_STAGE_MASTER.mdl n.b. only the first four above model parts are necessary for the QUAD updates, however, the remaining updates include grounded unused inputs required for when updating to RCG 2.9. Checking out the following c-code was also necessary for the ESD remote reset functionality:- /opt/rtcds/userapps/release/cds/common/src A LONG_PULSE.c I then updated the local top-level wiring for all the H1 QUADs to accommodate the updated QUAD_MASTER.mdl, these will be checked in once they are rebuilt and restarted in the morning:- /opt/rtcds/userapps/release/sus/h1/models/ ? h1susetmx.mdl ? h1susetmy.mdl ? h1susitmx.mdl ? h1susitmy.mdl I test built the above models on thw h1build machine and encountered no issues for the ITMs. However, the ETMs failed to build due to missing IPC senders in the h1lsc model (H1:LSC-ETMY_DARM_ERR & H1:LSC-ETMY_DARM_ERR), which will be rectified in the morning. Screen-shots of the updated local QUAD models are attached below. All looks good to proceed with the LSC/QUAD model rebuild, install and restarts tomorrow.
The h1lsc model has been modified to add the DarmErr signals: H1:LSC-ETMY_DARM_ERR & H1:LSC-ETMY_DARM_ERR. We have test built the h1lsc model, and found no issues.
This status is reported after the adjustment/instability of the REFSIGNAL mentioned in aLog 14634. Laser Status: SysStat: Warning “VP program online” is red Output power is 29.5 W (Should be around 30 W) FRONTEND WATCH is active HPO WATCH is red PMC: It has been locked 20 days, 2 hours, 8 minutes. Reflected power is 2.1 Watts and PowerSum = 25.7 Watts. (Reflected Power should be <= 10% of PowerSum) FSS: It has been locked for 1 hour, 45 min. Threshold on transmitted photo-detector PD = 2.27 V (should be at least 0.9V) ISS: The diffracted power is around 8.8% (should be 8-10%) Last saturation event was 1 hour, 49 minutes ago
Related: https://alog.ligo-wa.caltech.edu/aLOG/index.php?callRep=14567
Summary:
We're still close to the East edge of the PR2 baffle, it may be better to go further to the left for safety but we won't gain much as far as the power recycling gain goes.
The centering on PR2 is off by a centimeter-ish (or the baffle is offset from PR2 or the baffle is smaller than it should be).
The beam seems to be somewhat larger than it should be.
There is some clipping downstream of PR2 so we need more scans to find where that is.
In the right plot, blue circle is the PR2 baffle looked down from the PR2, green circles are the IFO beam ideally located, red cross is the PRM-PR2 beam position calculated from the slider, and the red circle is the beam position calculated from the fit.
Note that red cross and red circle have +-14%-ish error bar (both position and the size), but it seems like the beam is bigger and the beam closer to the East edge than it should be.
The left plot is the same as the one in the above mentioned alog, but replotted such that the X axis was rescaled as the beam distance from the East edge of the baffle using the new calibration of the IM4 slider (explained later). This X axis itself has +-14%-ish error bar.
The curve is the fit of POP_A and POP_B combined for the left half of the plot, assuming that the baffle transmission is approximated by a beam clipped by a vertical edge. Beam radius, edge position and the overall scale were the three fitting parameters (the overall scale is necessary because we don't know if the maximum transmission corresponds to zero loss).
Green vertical line is where we were at this morning, blue is where we used to be last Tuesday.
| Distance from the edge | Radius of PRM-PR2 beam on the PR2 baffle | Loss from the clipping | Centering on PR2 | |
| Ideally | 26mm | 6.1mm | Totally negligible. | centered. |
| According to the IM4 slider | 12(1+-0.14)mm | NA |
42ppm when the radius is 6.1mm, 0.62% when the radius is 9.6mm |
14mm off |
|
According to the fit (which depends on the slider) |
16(1+-0.14)mm ??? | 9.6(1+-0.14)mm ??? | 430ppm | 10mm off |
It would appear as if we should go further to the right on the plot, but clearly there is some kind of clipping on the sled path in that direction. As far as there's no clipping in the POP_AIR path that is OK, that's yet to be seen.
IM4 slider recalibration:
IM4 YAW rotation, though the slider has some calibration in the filter, is actually smaller by a factor of 0.175 than the slider number.
Looked at PR2 camera, and moved IM4 in YAW until the beam is blocked by the baffle.
| IM4 YAW slider value | |
| Left edge | 1376.7 +- 1000 |
| Right edge | -9623.3 +- 1000 |
| Where we were this morning | -7623.3 |
The baffle looks like a 65.4mm diameter circle from when viewed from PRM.
Since IM4-baffle distance is about 17m, we can recalibrate the slider:
IM4 rotation = 65.4mm/17m /2 = 1.92 mrad.
Slider calibration = 1.92 mrad/(1376.6 + 9623.3 urad) = 0.175 [rad/rad]
Fit:
That's a simple fit using the fit function
transmission = @(coeffs_, x_) coeffs_(3)*(1/2+ erf(sqrt(2)*(x_-coeffs_(2))/coeffs_(1))/2);
The script is this:
/ligo/home/keita.kawabe/Clipping/clipping1.m
Removed power to EX tiltmeter for a few minutes to dress power cable inside rack. Work was done around 9:50 AM this morning.
Jim, Dave, Hugo
at 08:03PDT Sunday Morning, 26th Oct 2014 the h1iopseih45 dac-enable was unset (8th bit of h1iopseih45 STATE_WORD). From this point onwards until the h1iopseih45 was restarted this morning no DAC drives were being sent out of this front end. This is presumably a DAC FIFO error, similar to previous such events. We are seeing them roughly once a month.
Frequency of DAC lock out events (requiring IOP model restart to fix). One more event added since my last entryhttps://alog.ligo-wa.caltech.edu/aLOG/index.php?callRep=13930
10/26 2014 h1seih45
9/11 2014 h1seih45
9/10 2014 h1seih23
8/11 2014 h1susb123
8/9 2014 h1seih23
4/21 2014 h1sush2a
3/18 2014 h1sush2a
2/27 2014 h1seih23
12/16 2013 h1seih23
11/7 2013 h1sush2a
11/7 2013 h2sush34
8/8 2013 h1seih23
Jameson, Hugo, Hugh
Debugging the guardian, Jameson suddenly saw the guardian manage to Isolate HAM2 ISI. But then it wouldn't.. We changed the guardian to behave closer to the command script in that it Isolates RX & RY first and then Isolates the remaining dofs second. Now maybe that makes a difference but we've come to the conclusion that something (loops?) must be marginal. With limited data. maybe 4 out of 5 attempts are now isolating with guardian. If it seems to not isolate with guardian first couple times, let's just damp the ISI for a few moments before going to Isolated.
In an effort to move ahead, we corrected the matrices too and we have it under guardian control. It has isolated again with about the same robustness (4/5.)
Further, we were going to try the new controllers but the commissioners asked for the IFO while I was running the Prepare Script which loads all the new filters into the foton file. So HAM2 is ready to Load New Filters. We will do this tomorrow morning now.
Good progress was made in making the DRMI lock more frequenct, more robust and more stable. The AS36 wavefront sensors were commissioned to aligned the SRC and BS. Improvements were made in loop shape, triggering, optical levers, drive diagonalization, and clipping. All together, this reduced the mode hopping problem in the SRC greatly.
Here is the list of commissioning task for the next 7-14 days:
Locking team:
PSL ISS REFSIGNAL adjusted to -2.09V, bringing the Diffracted Power ~7.5%.
This adjustment caused the ISS loop to drop lock. The autolocker brought it back up each time. After seeing this happen several times, I readjusted the REFSIGNAL to -2.08V, bringing the diffracted power to ~9%. It has now been stable for ~1.5 hours. I'll continue to montior this during my shift.
model restarts logged for Sun 26/Oct/2014
2014_10_26 14:33 h1fw1
2014_10_26 21:43 h1fw0
both unexpected restarts
After our modifications to the DRMI LSC thresholds and loop gains on Thursday night, we had several short locks. Yesterday, we saw the same good locking behavior again. We found that the reason for the short lock duration was a typo in our trigger matrix: the PRCL boosts weren't getting turned on. After switching those and tweaking some filter shapes, the locking is fast and the locks last a long time.
The first attached plot shows the minute trend of our 4 hour lock last night. The 6 WFS loops are engaged during this time, as well as the DC centering. Near the end of the lock, there is a SRC mode hop and it stays locked like that for 1 hour. There are 20% fluctuations in the SPOP18 and SASY90. The control signal plots in the left hand column are scaled so that the full y-scale is approximately the full suspension DAC range (there is a divide by 4 from the LSC to the SUS DAC outputs). The MICH and PRCL loops are pretty calm, but there are several large transients in the SRCL loop which, I believe, corresponds to the TEM00 -> TEM01/10 mode hop.
The second PDF shows the error and control signal spectra for the DRMI LSC loops during a non-hopping epoch from last night.
PRCL: The error signal is white, so not much to be gained by changing the loop shape. The control signal is dominated by 0.05 - 0.5 Hz as is expected from the ISI performance.
MICH: The error signal is dominated by sub-Hz stuff, so we could squash it better with a 1:0.1 zero:pole stage if we found it necessary. The MICH control signal is dominated more by the sub 0.1 Hz motion than anythin else in the DRMI. Usually we think this is the seismic amplification produced by the seismic isolation system.
SRCL: Similar story to PRCL, but more noise from <0.1 Hz than 0.1-0.5 Hz.
In all spectra, the large line at 131 Hz is a calibration line used for making sensing matrix and demod phase measurements.
After the lock loss, it never got it itself together. The ASC loops stayed railed and kept it from being aligned enough to lock.
Also, the Guardian had a filter writing problem and so it stopped restoring the correct IFO state after the DOWN state
(it was trying to set a filter which was under the control of the LSC filter module trigger logic and stopped because it didn't
get the correct readback. This fault condition should be added to Guardian to make the log file more informative and we
should fix this conflict in the LSC state defs).
After clearing all of that stuff and bypassing the Guardian temporarily, the Michelson, PRMI and DRMI all locked fine.
Our DOWN state triggering during DRMI lock acquisition is probably the main holdup in acquisition times now. Watching the Guardian log files I see that it often just attempts acquisition for several seconds before it then begins a ~30 second period of switching buttons on and off until its ready to lock again. We would be better off adjusting these state triggers such that it stays in the 'trying to lock' state all the time. It should only do any of the DOWN stuff if its gone up into M2 offloading or WFS boost turn ons. We may be able to get a 2-3x speedup by trimming these downtimes.
I had tried reducing the guardian "DOWN" time by sending the guardian to "LOCK_DRMI_1F" if the locking failed as it entered the wfs centering or offloading. This seemed to work on Friday, but there were/are still certain instances where the guardian goes to the "DOWN" state. I have attached an example from the log. Both "OFFLOAD_DRMI" and "ENGAGE_DRMI_WFS_CENTERING" are now suppose to return to "LOCK_DRMI_1F", but it seems that when there is a transition between these two states, it jumps to the "DOWN" state. Jamie and I will take a look at this on Monday.
Sheila and I looked at the Guardian script this morning; I had missed an assert function that would take ISC_DRMI to the "DOWN" state, I have changed this to the "LOCK_DRMI_1F", so hopefully this fixes the problem ....
J. Kissel, J. Warner, K. Venkateswara
Based on Rich's and Jeff's SEI log entry 586 and 594, we made a second attempt at sensor correction on ETMX along X and Z on stage 1, which seems to be working better. To judge the performance I have plotted the stage 1 T240 output and also the Oplev Pitch and Yaw output. We used a slighlty modified version of Rich's sensor correction filter described in the above log.
To establish baseline, the first plot shows the Stage 1 T240_X motin (green), the ground STS (blue) and the tilt-subtracted ground super-sensor (red) with no sensor correction applied. I've also shown the coherence between some sensors and the Oplev motion. All degrees of freedom had Ryan's LLO blend filters.
The next file (SensCorrectOnBRSOff) shows the sensor correction turned on for X and Z on stage 1, but with normal gnd_STS, not the tilt-corrected super sensor.
The final file (SensCorrectOnBRSOn) shows the sensor correction with the tilt-subtracted super-sensor for X. Note that the ground motion (blue) is not the same during these data sets, but the relative differences between the lines are important.
Some comments:
1. Based on these plots, it looks like turning sensor correction On, even without tilt-subtraction, improves performance at 0.1-0.5 Hz by factors of 2-5. It's effect below 0.1 Hz is not clear - there may be small tilt amplification. Switching to the tilt-corrected super-sensor slightly improves performance below 0.1 Hz by factors of 2 ish. It is probable that we are limited by tilt-reinjection from the low X blend.
2. We are probably limited by the L4C sensor noise between 0.5 to 1 Hz. By improving the L4C blend, we may be able to get another factor of 2ish at these frequencies.
3. The Oplev motion doesnt show much improvement despite better X performance. The pitch is very sensitive to and probably limited by the RY blend.
Sensor correction for X and Z has been left on overnight, since it may help. It is easy to turn off from the ISI medm screen, if it is affecting performance.
edit: I added the Stage 1 Z performance to the plots. The sensor correction appears to improve z performance by ~10 at the microseism. But there may be more pitch motion at ~10 mHz. Not sure what is causing that.
Tomorrow, we will try HEPI sensor correction which may or may not be better.
edit: I have added another file also showing the Stage 1 RY motion (converted to displacement units), which shows good coherence with X motion confirming tilt-reinjection in X.
J. Warner, K. Venkateswara, H. Paris, J. Kissel Just to add some modeling sauce to Krishna's statements, I attach modeled performance plots comparing Rich's aggressive IIR sensor correction filter (from LHO aLOG 586) against Krishna and Jim's even more aggressive IIR sensor correction filter (from 14561). As Krishna says, we're getting better and better performance out of lowering the corner frequency of the sensor correction filter, made possible with the tilt-corrected ground sensor (despite his modest claims that it's not doing much). Indeed, as we continue to improve the residual ground motion subtraction, we get more evidence as suspected from my modeled performance in SEI aLOG 594, that we are limited by L4C sensor noise from ~0.3 [Hz] to 1 [Hz] (and re-injected RY noise between 0.1 and 0.3 [Hz]). At this point, I have no definitive proof other than a similar shape of the 0.3 [Hz] to 1 [Hz] noise to the model and how it evolves with the latest changes in sensor correction -- but with the improved subtraction, its in some sense "exposing" the L4C noise by removing the limiting residual ground motion. Check pages 1 through 5 for comparisons of the FIR filters, and modeled performance using the Ryan DeRosa blends. Suspecting we can improve the L4C noise limitation by adjusting the T240 / L4C inertial sensor blend cross-over, I asked Hugo and and Jim for some information on how that cross-over is defined in the generic control scripts (knowing full well that Ryan would have chosen something different). In response, they pointed me to Brian Lantz's code for generating this crossover, ${SeiSVN}/seismic/Common/MatlabTools/blend_T240_L4C_111012.m In this function, Brian uses the knowledge of the T240 and L4C sensor noises to "optimize" the cross-over. Assuming this cross-over is better, I (1) Reconstructed the inertial sensor half of Ryan's psuedo-complementary blend filters by adding the existing T240 and L4C filters (grabbed directly from foton using readFilterzpk.m, since there's no matlab representation of these filters) (2) Grabbed Brian's T240 and L4C complementary pair from blend_T240_L4C_111012.m (3) Multiplied Brian's T240/L4C pair by Ryan's inertial sensor blend, such that total inertial sensor blend remains pseudo-complementary to Ryan's displacement sensor blend. (4) Ran through the same model, comparing Ryan's inertial cross-over vs. Brian's inertial cross-over. Blamo! -- if we are indeed limited by L4C noise (confirmed only by eye at this point) -- we can improve the noise from 0.3 to 1 [Hz] by another factor of a few. The filter comparison and modeled improvement is shown on pages 6-8 of the attached. We'll figure out how to actually implement this in foton tomorrow (gulp), so we can demonstrate this live. Plots are and model are produced by ${SeiSVN}/seismic/BSC-ISI/Common/Sensor_Correction_Design_BSC_ISI/design_sensorcorrection_IIR_20141021.m
K. Venkateswara
I had a calibration error in the above plots. I've corrected it and attached the following files:
ST1SCoff.pdf = Stage 1 X sensor correction off.
ST1SCBRSoff.pdf = Stage 1 X sensor correction with just GND_STS, BRS not used.
ST1SCBRSon.pdf = Stage 1 X sensor correction with tilt-subtracted ground sensor.
SCCompare.pdf = Comparison of the three configurations. As ground motion was different during these measurements, this is not a good judge of performance below 0.1 Hz, but is useful above 0.1 Hz.
