Displaying report 1-1 of 1.
Reports until 23:31, Thursday 13 November 2014
H1 SUS (ISC)
jeffrey.kissel@LIGO.ORG - posted 23:31, Thursday 13 November 2014 - last comment - 22:51, Monday 17 November 2014(15049)
Potentially New H1 SUS ETMY UIM (L1) L2P Filter Design
J. Kissel

I've measured new transfer functions necessary redesign of the H1SUSETMY UIM (L1) DRIVEALIGN frequency-dependent decoupling filters for L2P and L2Y. For the impatient, the last page of the last attachement shows a comparison between the proposed new design and the old, currently installed / in-use design. I have *not* installed this filter because I'd like to discuss the results with commissioners tomorrow morning (and it'll take me some time to resurrect quack to get these installed). In fact, this may argue for us to indeed just copy over ETMX's filter.

Details:
-----------------------------------------
I attach the measurement results (see 2014-11-13_H1SUSETMY_L1_drivealignfilters_rawdata.pdf), but the raw templates can be found here:

/ligo/svncommon/SusSVN/sus/trunk/QUAD/H1/ETMY/SAGL1/Results/Data/
2014-11-13_H1SUSETMY_L1_L2PY_WhiteNoise_ReactionChainTest.xml
2014-11-13_H1SUSETMY_L1_L2PY_WhiteNoise.xml
2014-11-13_H1SUSETMY_L1_P2PY_WhiteNoise.xml
2014-11-13_H1SUSETMY_L1_Y2PY_WhiteNoise.xml

Not that I drove through the TEST filter banks (instead of having to turn off all the existing filters in the LOCK and DRIVEALIGN banks), and made sure that optical lever damping was OFF, and local damping was the LLO design as described in LHO aLOG 14959.

I focus this entry solely on L2P, but the data exists for an L2Y filter if ever needed. in the first four pages, Pink curves are the current measurement, and black curves are what were used in the original design of the previous filter by Arnaud (see LHO aLOG 11832). The encouraging fact is that the data supports exactly what we'd model from the change in damping loop filter design (see green traces on pg 5 of first attachement to LHO aLOG 14959). As an aside -- just because Betsy made me think of it while chasing down slider values -- what effect does reaction chain alignment have on these off-diagonal, lower-stage transfer functions? One might guess that if the L2P cross-coupling isn't something fundamental but a result of dirt alignment affects between the coils on the reaction chain and the magnets on the main, then one would see a change in the L2P transfer function with different alignments of the reaction chain. The good news is that is doesn't have any effect -- see the last page of 2014-11-13_H1SUSETMY_L1_drivealignfilters_rawdata.pdf. I compare the same transfer function for 4 different reaction chain alignments. They still have the old dead-reckoned calibration factors installed, so we know they're not exactly [urads] but close enough for the scale of these offsets used; they use up about 1/2 the DAC range.

As far as the design goes, I used the same transfer function fitting routine and filter generation software suite that (I think) Arnaud used, namely the function
/ligo/svncommon/SusSVN/sus/trunk/QUAD/Common/FilterDesign/Scripts/Length2Angle_decoupling.m 
which is essentially a wrapper around the function,
/ligo/svncommon/SusSVN/sus/trunk/Common/MatlabTools/happyVectfit.m 
which Keita's wrapper around the function,
/ligo/svncommon/SusSVN/sus/trunk/Common/MatlabTools/vectfit3.m
All tweaking of input parameters to the fitting routine, and plots were made using the overarching script
/ligo/svncommon/SusSVN/sus/trunk/QUAD/H1/ETMY/SAGL1/design_H1SUSETMY_L1_L2P_20141113.m

Notable key additions to the design software -- a computation of the final filter's impulse response, as well as a comparison to the previous design.

As I know Arnaud had struggled, I struggled to find a fit with which I was really happy, namely because we all *know* that the L2P transfer function should fall off as some large power of frequency (again, see the models of these TFs on pg 5 of LHO aLOG 14959), but I can't find a set of parameters happyVectFit / vectfit3.m that allows for such a roll-off at high frequency. Indeed, the height of the final flat part of the L2P fit transfer function directly determines the high-frequency gain of the decoupling filter, and directly impacts the impulse response time. I settled on a filter that does a poor job at reproducing the > 2 [Hz] behavior of the L2P measurement, BUT I think it's OK because
(a) the small magnitude of the high-frequency causes a significant drop in impulse response time, and
(b) At the UIM, we're typically driving below 2 [Hz] -- especially if the crossover remains at 0.9 [Hz] as quoted in LHO aLOG 15025, so the accuracy of inversion is not so critical. Though I didn't find any design aLOGs, this seems to have been the philosophy behind the ETMX UIM L2P filter because it ends up looking strikingly similar.
I should say also that having to tune the uncertainty tolerance, the order (i.e. number of poles) in the filter, the tolerance for when to throw out adjacent poles and zeros, the frequency range over which to fit -- all free parameters into happyVectFit.m -- as one has to do to get what one wants in the end really destroys the advantage of automating the fitting process. If only there was a better way...
Non-image files attached to this report
Comments related to this report
jeffrey.kissel@LIGO.ORG - 17:55, Friday 14 November 2014 (15076)ISC, SEI
I've installed the filter into H1:SUS-ETMY_L1_DRIVEALIGN_L2P filter bank, in FMs 5&6 via autoquack. 

HOWEVER
(1) I have not tested the filter performance with transfer functions or step response
(2) I've split the L2P and (invP2P * rolloff) into two filter banks. Even with the rolloff, the (invP2P * rolloff) filter has more zeros than poles, so foton has added a whole bunch of high-frequency poles to compensate. Though the *total* filter's -- L2P * (invP2P * rolloff) --  number of poles is equal to the number of zeros, I think the high-dynamic range, zero pole, cancellation between the two filters isn't working out. This is resulting in a HUGE calculated impulse response, which may or may not be real.
(3) This is my first time using quack to install Matlab filters into foton in a *really* long time, so I'm nervous of its functionality.

I attach a series of comparisons with ETMX's filter. The bode plot, in the frequency band we care about (pgs 1 and 2) seems reasonable. Both ETMX and ETMY have some high-frequency garbage in their impulse response, but the overall amplitude of the impulse response in ETMY is many orders of magnitude larger than that of ETMX (!!!). Further, taking the transfer function out well beyond the Nyquist frequency, we see that they behave significantly differently at the Nyquist frequency (~7 [kHz]).

As such, I'm still entirely unsure that this new filter gunna work, and may require further tweaking.

Anyways, these are installed in 
FM5 "UIM_L2P"
FM6 "UIM_invP2P"
and should be turned on TOGETHER, with no other filters engaged in the module, if one would like to be bold and try it over the weekend.

P.S. in case you've forgotten, when you autoquack in a filter who's name has a space in it, and you try to load the new filter coefficients, Foton will hate you. You will, at least, get a nasty-gram on the GDS_TP screen's filter message, ${IFO}:FEC-${DCUID}_MSG saying "bad filter coeff definition on line 259 in .txt," pointing you to the exact line of the problem. So with Jim's confirmation that "Oh yeah, you DEFINITELY don't wanna do that." I changed spaces to underscores and all worked fine.
Non-image files attached to this comment
nicolas.smith@LIGO.ORG - 22:51, Monday 17 November 2014 (15117)

These filters did indeed run away and saturate the DAC. (The EPICS values were even showing “-Inf,” I’d never seen that before). I don’t think we can get away with more zeros than poles in a filter module, even if they are compensated by some other module.

I took the two filters (FM6 and 7) and viewed them in the foton “Multiple” mode, then I took the output in the “Alternate” box of foton and copied that into FM10.

When I tried this, instead of a huge mess I got a nice step response according to foton, and the frequency response was the same as the two original filters. As seen below (new is red, old is blue):

foton
However, stupid foton wouldn’t save the filter (but gave no error message). In the end, I had to take this “Alternate” output and split it up into two filters, being careful that each had more poles than zeros. This allowed me to save the foton file and load the filters into the frontend. I tested that the impulse response behaved nicely by putting an offset into the filter bank.

The two filters are in FM5 and FM10. Their names reflect my frustration.

Images attached to this comment
Displaying report 1-1 of 1.