kyle.ryan@LIGO.ORG - posted 15:55, Wednesday 13 May 2015 (18416)
Surveyed LVEA looking for evidience of roof leaks -> Nothing found in LVEA
We repeatedly had problems with engaging ASC loops to the bottom or penultimate mass that have a top stage relieve loop.
In a nutshell, the problem comes with engaging the loop with a relatively big initial misalignment. The fast loop to PUM or TST does the right thing, but saturates its drive stage before the top mass relieve can kick in. Increasing the top mass relief doesn't always work because different loops feed the same test mass.
The ideal approach would be a saturable integrator in the ASC filter banks. Since this this would require a front-end code change, I wrote a python version that watches filter module output and input, and simply turns the input off if the integrator exceeded the limit and the error signal would drive it further away.
The code relies on guardian decorators. I.e. it should be added to any state during which this logic should be active. The decorator is defined in ISC_library.py, and can be called as:
@FM_limit_checker_decorator(ListOfFIlterModulePrefixes_pos_gain,+1)
@FM_limit_checker_decorator(ListOfFIlterModulePrefixes_neg_gain,-1)
Example:
@FM_limit_checker_decorator({'ASC-SRC2_P','ASC-SRC2_Y','ASC-DSOFT_Y','ASC-CSOFT_Y'},+1)
@FM_limit_checker_decorator({'ASC-DSOFT_P','ASC-CSOFT_P'},-1)
Positive and negative gain characterizes the overall gain of all engaged filters, i.e.
- +1 : positive input signal leads to growing output signal and vice versa
- -1 : positive input signal leads to shrinking output signal and vice versa
Current testing:
================
- For initial testing we added the decorator to
i) DRMI guardian ENGAGE_DRMI_RUN state:
@FM_limit_checker_decorator({'ASC-SRC2_P','ASC-SRC2_Y'},+1)
ii) ISC guardian ENGAGE_ASC run state:
@FM_limit_checker_decorator({'ASC-SRC2_P','ASC-SRC2_Y','ASC-DSOFT_Y','ASC-CSOFT_Y'},+1)
@FM_limit_checker_decorator({'ASC-DSOFT_P','ASC-CSOFT_P'},-1)
Known bugs:
===========
- Currently the filter module will be left in whatever state it was when the decorator ran for the last time. It is up to the user to assure the filter module is actually on in the end.
The full code in ISC_library.py is:
---------------------------------------------------------------------------------------------------
def FM_limit_checker_decorator(FMlist,sign):
class FM_limit_checker(GuardStateDecorator):
"""Check for FM reaching limiters - if so, turn of input"""
def pre_exec(self):
for FM in FMlist:
if ((-ezca[FM+'_OUTMON'] >= ezca[FM+'_LIMIT']) and (-ezca[FM+'_INMON']*sign> 0)) or
(( ezca[FM+'_OUTMON'] >= ezca[FM+'_LIMIT']) and ( ezca[FM+'_INMON']*sign> 0)) :
ezca.switch(FM, 'INPUT', 'OFF')
else:
ezca.switch(FM, 'INPUT', 'ON')
return FM_limit_checker
Reports from Subsystems:
Scott L. Ed P. Chris S. (Cris M.1/2 day) 5/11/15 45.7 meters cleaned ending at HNW-4-040. Test results posted here. Removed lights, refilled D.I. water tank and relocated all equipment to next section north. 5/12/15 The crew began hanging lights,vacuuming support tubes and spraying bleach/water solution. Cleaned 54.9 meters ending 11.5 meters north of HNW-4-042. 5/13/15 Cleaned 67 meters ending at HNW-4-046. To date, we have cleaned a total of 2902 meters of tube.
The original PSL chiller has been fitted out with the vortex style flow sensor. In turning the crystal chiller on, we found that the controller unit was faulty and did not display the Termotek logo on start up. The controller was replaced and the chiller powered up okay. We ran the chiller with the outlet connected to the inlet without any problems. The flow sensor calibration factor was changed to 0970 to account for the vortex sensor. The exercise was repeated with the diode chiller. At the moment the chillers are in the large item access area, waiting for a convenient time for us to roll them back to the chiller room. The crystal chiller needs another pigtail cable to be made. JeffB, Peter
No real changes from the report yesterday afternoon. That data was from the afternoon after things quieted down in the LVEA. Data from this morning ~0030pdt, look pretty much the same. There are bands of elevated signal compared to the references: ITMX & BS ST2 Verticals below 20Hz. The BS Stage2 Corner2 signals are lower now by factors or 2 & 3 above 20 Hz (good thing.) The ITMX sees increased noise above 20Hz on V1 both stages and on ST2 H2 above 10Hz. In general, ITMY looks little changed and pretty good.
Happy if RichM or another well studied would look at these too.
10 day trend.
Noticed it on the way out...
Evan, Stefan
We fine-tuned the MICH correction todonight.
- Added the SB300vio BS violin stop band filter to MICH_FF to cancel their effect.
- Measured MICHFF_OUT to DARM_IN twice:
1) drive disconnected at the ITMY. This measures the MICH_OUT to DARM_IN path.
2) MICH_FF input off, driving MICH_FF. This measures the MICHFF_OUT to DARM_IN path.
This data is in plot 1.
- 1)/2) is the desired filter, shown in plot 2.
- Finally, we used a p:60:z:80 filter to fine-tune the phase a bit. (Plot 3) This significantly improved the achievable subtraction.
Attached is a comparison of the three different FF states (no FF, FI FF, and FD FF). DTT file is in my folder under Public/2015/05/Feedforward/MichFf.xml.
Attempting to print these plots as a pdf caused DTT to crash. :(
On a different note, we also tried briefly punching the ITM ring heaters (upper and lower) to 0.5 W each to see if we could do anything about the drift in POP90. I turned them on at 2015-05-13 10:56:20 Z, and then off again at 11:03:15 Z. The interferometer unlocked about 20 minutes later, we don't have enough data to say whether this helps or hurts.
I calculated the thermal lens response of the ITM to this 7-minute ring heater pulse (see attached image). After 7-minutes of heating and a further 20 minutes of waiting the total thermal lens in the ITM is around -5E-7 diopters, or an additional 0.2m added to the radius of curvature. It's unlikely this had any noticable effect.
Note: the glass elements of the RH have a time constant, tau, of around 7 minutes. That is, the power radiated to the test mass from the RH is roughly P_elec*(1-exp(-t/tau)) and P_elec is the electrical power requested.
Evan, Stefan,
Our late night work was hampered by repeated lock-losses engaging SRC2 loop during the DRMI phase. The few times we made it through that stafe, we lost it in the IFO ASC stage, when the SRCL2 loop gets extra gain.
We tried both a high SRCL offload and low SRCL offload configurations (Gain of 1 and 0.1 respectively in SRM M2 stage.) The high SRCL offload configuration resulted in a 18sec oscillation, growing to a lock-loss. The low configuration (the default) also broke the loss several times, but we are not sure why.
Sheila, Evan, Stefan We remeasured the required SRCL FF filter today. The transfer function changed significantly. The only thing we know we changed was the POP_45 phase (H1:LSC-POP_A_RF45_PHASE_R) from 66deg to 58deg - this minimized a SRCL drive in MICH. The fit functions are roughly: May 11: p:0,0 z:2.28571+31.9183i,2.28571-31.9183i,-180 (M1) May 12: p:0,0 z:2.28571+47i,2.28571-47i,-600 (M2) The 1st attached plot shows these two measurements, overplayed with the models M1 and M2. The 2nd plot shows the 4 raw measurements (2 yesterday, 2 today). We didn't try to engage this SRCL FF yet.
At the end of the day - after sitting at 10W for a while, and with the MICH FF optimized - we measured the SRCL FF transfer function again. It looked a lot closer to yesterday's measurement.
Those changes in the SRCL to DARM couplings are consistent with the simulation results for a changing SRCL offset. The reason of this changing offset can be related to many things, for example alignment.
Looking at the data and the simulation results, to have a zero at 30-50 Hz we need offsets of the order of 6-8 nm
Sheila, Stefan, We noticed the H1:ALS-X_TR_A_LF_OUT signal (Xarm green transmission) drop to zero with the cavity aligned without good reason. The first time this happened, the signal came back after a few minutes. One lock-loss later the same thing happened, and didn't come back. We went to ISCT1, and as soon as we touched the BNC cable of the x arm Green transmission photo diode, the signal jumped back. We replaced the T that was in between the PD and the BNC cable with an L. The T was removed from circulation.
Both the bounce and roll mode were rung up on ITMY.
Roll: freq 13.934Hz damped using AS WFS, a gain of -100dB, bandpass 13.9Hz, and a negative gain around 1. This was done at a CARM offset of 10 pm since the IFO wasn't stable if we tried to go on resonance.
ITMY bounce is damped at M0 with +60 degree rotator and positive gain.
At one point the mode was rung up so high that we weren't making much progress on M0, so we sat at 10 pm CARM offset for a while and instead damped by feeding a bandpassed version of DARM error onto ITMY L2 (0 degrees of phase and positive gain, but since this is the DARM error point, these settings aren't necessarily very repeatable).
Designed new filters for compensating the ITM PUM->TST P2P and Y2Y drive path.
- There filters were originally designed starting with Jeff's suspension model. They were then tested and fine-tuned using an optical lever feed-back.
- They include inversions of the two suspension poles - slightly offset in frequency to guarantee stability.
- They also have a notch to kill a rung-up suspension modes a 3.1Hz and 3.3Hz. That will prevent high BW feed-back, but that's currently not planed for the ITMs.
(I rang up the 3.31Hz mode in ITMX PIT, and thus copied that everywhere. ITMY YAW I actually rung up 3.12Hz, so I moved the notch for that one.)
- They were gain-matched to the old filters at low frequencies.
- The filters were installed in FM10 of the ASC filter banks for DSOFT and CSOFT (see below). They should replace the old lead filters in FM2.
DSOFT_P (ITMX_PIT):
zpk([0.034375+i*0.548925;0.034375-i*0.548925;0.0700002+i*1.39825;0.0700002-i*1.39825],
[6.52535+i*17.507;6.52535-i*17.507;7.32113+i*15.9155;7.32113-i*15.9155],0.236209,"n")
notch(3.311,30,20)
gain(12.044,"dB")
DSOFT_Y (ITMX_YAW):
zpk([0.035625+i*0.568886;0.035625-i*0.568886;0.0650001+i*1.29837;0.0650001-i*1.29837],
[6.52535+i*17.507;6.52535-i*17.507;7.32113+i*15.9155;7.32113-i*15.9155],0.236209,"n")
notch(3.311,30,20)
gain(13.06,"dB")
CSOFT_P (ITMY_PIT):
zpk([0.034375+i*0.548925;0.034375-i*0.548925;0.0700002+i*1.39825;0.0700002-i*1.39825],
[6.52535+i*17.507;6.52535-i*17.507;7.32113+i*15.9155;7.32113-i*15.9155],0.236209,"n")
notch(3.311,30,20)
gain(12.044,"dB")
CSOFT_Y (ITMY_YAW):
zpk([0.034375+i*0.548925;0.034375-i*0.548925;0.067+i*1.33832;0.067-i*1.33832],
[6.52535+i*17.507;6.52535-i*17.507;7.32113+i*15.9155;7.32113-i*15.9155],0.236209,"n")
notch(3.12,20,30)
gain(13.06,"dB")
Attached is a plot of old vs new TF for ITMY YAW.
Evan, Stefan, We engaged these filters successfully with gains of -0.3 in pit and 0.2 in yaw in the IFO ENGAGE_ASC state. We used a -20dB reduced gain during engaging, and then ramp up.
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.
The beta version described above failed on the turn on/off transients, amplified by the inverse plant lead filters. The solution was to a filter section with gain of 0 and ramp time for input switching. Version 1.0 now is: -------------------------------------------------------------------------------------------------------- def FM_limit_checker_decorator(FMlist,sign,action,onstate,offstate): class FM_limit_checker(GuardStateDecorator): """Check for FM reaching limiters - if so, turn of input""" def pre_exec(self): for FM in FMlist: if ((-ezca[FM+'_OUTMON'] >= ezca[FM+'_LIMIT']) and (-ezca[FM+'_INMON']*sign> 0)) or (( ezca[FM+'_OUTMON'] >= ezca[FM+'_LIMIT']) and ( ezca[FM+'_INMON']*sign> 0)) : ezca.switch(FM, action, offstate) else: ezca.switch(FM, action, onstate) return FM_limit_checker -------------------------------------------------------------------------------------------------------- We successfully used it on the ITM ASC loops. The following decorators are added for each following state: @FM_limit_checker_decorator({'ASC-DSOFT_Y','ASC-CSOFT_Y'},+1,'FM2','OFF','ON') @FM_limit_checker_decorator({'ASC-DSOFT_P','ASC-CSOFT_P'},-1,'FM2','OFF','ON') and finally, in DC_READOUT one final call of # make sure it is on now (FM2 off in all cases) @FM_limit_checker_decorator({'ASC-DSOFT_Y','ASC-CSOFT_Y'},+1,'FM2','OFF','OFF') @FM_limit_checker_decorator({'ASC-DSOFT_P','ASC-CSOFT_P'},-1,'FM2','OFF','OFF') guarantees that the loops are on, no matter what. Remarks: - The current code works best with the front end limiters turned off, but the limit set to a conservative value. The integrator will slightly overshoot the limit because of the guardian delay and the filter ramp time. But it will not produce a transient.