Displaying reports 68061-68080 of 83041.Go to page Start 3400 3401 3402 3403 3404 3405 3406 3407 3408 End
Reports until 21:44, Tuesday 02 December 2014
H1 SUS (AOS, ISC, SUS)
evan.hall@LIGO.ORG - posted 21:44, Tuesday 02 December 2014 - last comment - 10:29, Wednesday 03 December 2014(15399)
ITMX bounce mode damping

Kiwamu, Dave, Dan, Alexa, Sheila, Elli, Evan

We have been having trouble keeping ALS DIFF locked for the past few hours. Alexa finally figured out there was a large 10 Hz peak in DIFF error spectrum and the ESD drives.

We thought it might be either the ETMX or ETMY 9.8 Hz bounce modes, since these have previously given us trouble (LHO#15118, LHO#15247). However, by looking at oplev spectra, we determined it was actually ITMX and the frequency was 9.84 Hz.

So we copied over Matt’s ETMX damping filters (pass9.8, which has the sharp gain, and phase9.8, which allows us to adjust the phase) and adjusted the frequency to 9.84 Hz. Then I turned off the oplev filters and engaged pass9.8, and played with the gain (originally −0.05) until I got damping (the necessary gain was 300). The mode was originally a factor of 5–10 above the ITMX pitch oplev noise floor, and after 10 minutes we were able to push it into the noise floor. The use of phase9.8 was not necessary.

I have restored the ITMX pitch damping, along with a 9.84 Hz elliptic stopband filter stop9.84 which is modeled after an ETMX L1 filter.

Comments related to this report
daniel.hoak@LIGO.ORG - 21:58, Tuesday 02 December 2014 (15400)

Attached is a fine-resolution spectrum of the ITM OpLev pitch signals.  ITMX bounce mode = 9.8469 Hz, ITMY = 9.8315 Hz.  Probably ITMY will be a problem someday, too.

The bounce mode peaks are very narrow - only about 2mHz wide.  One theory (from Dave) is that there might be two modes very close to one another, and only one of them couples to the oplev feedback; the other stores energy and makes the mode difficult to damp.  The list of suspension resonances says that the z2 and z3 modes are both around this frequency, but doesn't say if we expect them to be within 2mHz of each other.

Images attached to this comment
matthew.evans@LIGO.ORG - 05:29, Wednesday 03 December 2014 (15405)

The phase9.8 filter was designed to be used with the standard OpLev damping to prevent excitation of the bounce mode, not with the Pass9.8 (used with the 0:50 filter to damp the mode after it gets excited).

keita.kawabe@LIGO.ORG - 08:37, Wednesday 03 December 2014 (15407)

ITMX is supposed to be as bad as ETMY.

ETMY > ITMX >>>>>>>> ITMY > ETMX, in terms of bounce-to-length coupling.

https://alog.ligo-wa.caltech.edu/aLOG/index.php?callRep=14876

norna.robertson@LIGO.ORG - 10:29, Wednesday 03 December 2014 (15409)
I want to clarify something Dan wrote.
There is only one vertical resonance at ~ 9 Hz in the quad - it is the highest of the four vertical resonances, called modev4 in the list of resonances which can be seen at e.g.
https://awiki.ligo-wa.caltech.edu/aLIGO/Suspensions/OpsManual/QUAD/Models/20140304TMproductionTM

The reference to z2 and z3 describes the dominant motion in that mode i.e. which masses are moving and in which directions in that mode. The highest vertical resonance involves the penultimate and test masses moving out of phase with each other in vertical - hence the z2 ( which is PUM vertical motion) and z3 (test mass vertical motion).
The numbering is historical from our original MATLAB models, based on extending a triple model- masses are 0,1,2,3 from top to bottom. 
H1 ISC
alexan.staley@LIGO.ORG - posted 19:35, Tuesday 02 December 2014 (15398)
HEPI Tidal feedback restored

Sheila, Alexa

We noticed that the HEPI tidal feedback to the ETMs was not working. We found that the ISC MON outputs were off, the ISCINF_LONG offsets were off. In addition the ETMY ISCINF gain was zero and the ETMX ISCINF gain was 1000; the nominal gains should be 1. This is now in the guardian.

H1 ISC (ISC)
lisa.barsotti@LIGO.ORG - posted 18:24, Tuesday 02 December 2014 (15392)
Power trends during CARM offset reduction
We are trying to make sense of what we see during the CARM offset reduction. We believe that we are at a lower CARM offset than we estimated given our power build up.

When our power build up is ~120 (wrt single arm, as measured by the TR QPD - Sheila is checking the normalization), REFL_DC is already at ~50% of its max power, and it looks like REFL_9I is indeed already within its linear range. However, at that point we should already be close to ~500 x single arm power (or half of the total build up, nominally 1000 x single arm). POP_DC shows only a modest factor of 2.5 increase with respect to only sidebands in the recycling cavity, it should be higher than that. 

This would explain while we couldn't further increase the CARM offset, as the TR signals are becoming flat, and why we couldn't keep using the same AS WFS signal in loop, as it is changing sign at low CARM offset (  see Dan's model ).

We will try to figure out why this is happening (are we simply misaligned? low carrier recycling gain? loss in the arms?...).

The positive message is that there is no point in trying to further reduce the CARM offset in this state..so we are done with that.

Kiwamu posted  these simulation plots  as a comparison, and  LLO log 12765  is an example of the LLO sequence.
Images attached to this report
H1 ISC
keita.kawabe@LIGO.ORG - posted 18:14, Tuesday 02 December 2014 (15396)
ASC model and end station ALS models (Daniel, Keita)

ASC model (ASC_MASTER.mdl) and the end station ALS model (ALS_END.mdl) were modified and installed as a test to accomodate the TMS actuation and the ITM camera sensing in ASC.

Now ALS WFS DOF3 (which is used for ITM camera) goes to the ASC, and the ASC output matrix can act on TMS.

Relevant MEDM screes were updated.

H1 CDS
david.barker@LIGO.ORG - posted 17:43, Tuesday 02 December 2014 (15395)
CDS maintenance summary

h1guardian reboot: Dave, Patrick

At 10:06 PST I rebooted the h1guardian0 machine to test that all the nodes started automatically. The reboot proceded normally and all the guardian nodes did start automatically, SUSMC1 node was slightly delayed relative to all the other nodes. For reasons currently unknown the restart crashed the conlog master. Patrick restarted the conlog.

Model Changes: Keita, Daniel, Dan H, Dave

The following models were restarted with new code: h1susetmx, h1iscex, h1hpietmx, h1susetmy, h1iscey, h1hpietmy, h1asc, h1omc, h1susomc

Frame Writer Minute Trends Offload: Jim

h1fw0 has been busy over the past day copying its raw minute trends from the SSD array to HDD. Many restarts of h1fw0 are attributed to this loading.

h1susetmx snap files: Dave

For reasons unknown many old snap and log files in the directory target/h1susetmx/h1susetmxepics/burt/ were deleted between 10:00 and 11:00 PST this morning. This included the safe.snap symbolic link. Therefore the 11am restart of h1susetmx did not burt restore to its safe.snap, rather to the snap file created at the shutdown time. I restored the safe.snap link. Investigation continuing.

Partial loaded Filter Module Files: Dave

The following systems were discovered to have partially loaded filter files, I performed a "load all coefficients" on: h1psliss, h1susprm, h1sussrm, h1oaf, h1lsc, h1omc. The model h1asc took care of itself after it was restarted.

SVN local mods: Dave

The following front end source files have local modifications:

                           lsc/common/models/lscals.mdl  Tue Mar 11 21:57:37 2014    M      
                                lsc/h1/models/h1lsc.mdl  Mon Oct 27 15:40:01 2014    M      
                              omc/common/models/omc.mdl  Tue Dec  2 13:16:29 2014    M      
                                omc/h1/models/h1omc.mdl  Tue Dec  2 12:32:27 2014    M      
                           psl/common/models/psldbb.mdl  Fri Jan 10 19:19:47 2014    M      
                           psl/common/models/pslfss.mdl  Fri Nov 21 14:12:02 2014    M      
                           psl/common/models/psliss.mdl  Tue Nov 18 11:47:45 2014    M      
                           psl/common/models/pslpmc.mdl  Fri Nov 21 14:13:54 2014    M      
                             psl/h1/models/h1pslfss.mdl  Wed Sep 17 14:54:45 2014    M      
                             psl/h1/models/h1psliss.mdl  Fri Nov 21 14:16:00 2014    M      
                             sus/h1/models/h1susomc.mdl  Tue Dec  2 12:32:25 2014    M 

the following guardian files have local modifications:

M       common/guardian/ALS_DIFF.py
M       common/guardian/ALS_COMM.py
M       common/guardian/ALS_ARM.py
M       common/guardian/IMC_LOCK.py
M       h1/guardian/lscparams.py
M       h1/guardian/ISC_DRMI.py
M       common/guardian/LSC_PRMIsb.py
M       common/guardian/LSC_CARM.py
M       h1/guardian/lsclib/prxy/carrierlock.py
M       h1/guardian/lsclib/pdOffsetNull/pdOffsetNull.py
M       h1/guardian/lsclib/prmi/sidebandlock.py
MM      h1/guardian/LSC.py
M       common/guardian/OMC_LOCK.py
M       h1/guardian/omcparams.py
M       common/guardian/SUS.py
M       common/guardian/susconst.py
M       common/guardian/SUS_TMS.py
M       common/guardian/SUS_BS.py
M       h1/guardian/SUS.py
M       common/guardian/ifolib/CameraInterface.py
M       h1/guardian/H1ECATX1PLC2.py
M       h1/guardian/H1ISCEX.py
M       h1/guardian/CSD_LoadDatabase.cmd

DMT Broadcaster: Dave

Checked all DMT channels are in the DAQ. Found to my chagrin that two channels were duplicated in the broadcaster list. H1:PEM-EX_MIC_VEA_MINUSX_DQ and H1:PEM-EX_MIC_VEA_PLUSX_DQ. I have removed the duplication which will be applied on the next DAQ restart.

H1 ISC
alexan.staley@LIGO.ORG - posted 17:24, Tuesday 02 December 2014 (15393)
SRM ASC work in progress

Alexa, Sheila, Dan, Dave O.

 

Stefan had reported that the original SRM ASC wfs had been oscillating post TCS work (alog 15343). For SRM we had used AS_A_RF36_I as the error signal with a gain of P, Y = 0.3, 1.2. We compared this with REFL_B_RF45_Q error signal, which at one point Livingston had been using, and found this actually appeared to be a better signal. We were able to close the yaw loop with a gain of 4. I did not see any oscillations with this loop closed for about 10 minutes; and it appeared to bring the build up back whenever I misaligned SRM. We tried closing the pitch loop, but have not suceeded yet. We tried a gain of -4 and 4, which caused the loop to oscillate. I reduced the gain of -1, and did not see oscillations, but was not able to recover the build up with an SRM alignment.

For now, we decided to move on and try locking. There is still more work to be done in closing this loop. I will not update the guardian yet.

H1 SEI
sheila.dwyer@LIGO.ORG - posted 17:15, Tuesday 02 December 2014 - last comment - 18:37, Tuesday 02 December 2014(15391)
gain filters for BS ISI ST2 GS13s

Alexa, Dan, Sheila

We found the BS ISI ST2 watchdog was tripping when the DRMI was acquiring lock; big transients in the MICH control signal would show up in the ST2 GS13s and saturate the inputs.  After some dataviewer'ing, we found that these transients are always there, but today they were large enough to hit the watchdog threshold.  We suspected the GS13 gains had changed, and conlog said that yesterday the 'Gain' filter (FM4) on the BS ISI GS13INF filter banks was turned on.  (We suspect that someone turned these off during the SEI work today?)  We turned them back on; the problem seems to be fixed.

None of the other BSC chambers have these filters on, but it looks like we need them for the BS, for now.

Comments related to this report
alexan.staley@LIGO.ORG - 17:26, Tuesday 02 December 2014 (15394)

We tripped the ISI even while DRMI was locking (and luckily did not break the lock). We compared the length signal to the BS between today and yesterday, and concluded the LSC signals were not very different and were not the culprit.

Images attached to this comment
jeffrey.kissel@LIGO.ORG - 18:37, Tuesday 02 December 2014 (15397)
Note that these GS13INF gain filters are compensating for an analog switchable gain. I agree that if the GS13s are in "high gain" mode, i.e. with FM4 OFF, then they will saturate more easily. But, if you want to change the gains to "low gain" mode (with FM4 ON), you shouldn't just turn off the compensation filter. You need to use the command scripts (the dark beige button on the lower 1/3rd on the left of the overview screen -- then hit "GS13 HI / LO" button as you like, again on bottom 1/3rd of screen, but on the left) such that both the analog gain and the digital compensation are switched simultaneously. 

Good luck and god speed.
H1 ISC
kiwamu.izumi@LIGO.ORG - posted 16:34, Tuesday 02 December 2014 - last comment - 16:59, Tuesday 02 December 2014(15389)
expected DC and REFL9 signals

Here are two plots showing the ideal behavior of some DC signals and REFL9 signal during reduction of the CARM offset. They are computed by optickle with the designed optical parameters except for the modulation depths which are now 0.17 rad and 0.3 rad for 9 and 45 MHz modulations respectively.

Attachment 1:

A plot of some DC signals as a function of the CARM offset. TRX (show in red) is normalized by the single arm power. It reaches 1350 with zero CARM offset, indicating that the recycling gain is about 41. REFL_DC (shown in cyan) is normalized such that it is unity when the CARM has a large offset. The same normalization is applied to POP_DC (shown in brown) as well. The black curve is derived simply by sqrt(normalized TRX + normalized TRY).

 

Attachment 2:

A plot of REFL_DC, AS_DC and REFL9 demodulated signals as a function of the CARM offset. AS_DC is in mW while REFL_DC is in Watts. The demod signals are in an arbitrary unit.

Non-image files attached to this report
Comments related to this report
evan.hall@LIGO.ORG - 16:59, Tuesday 02 December 2014 (15390)

PDFs attached.

Non-image files attached to this comment
H1 General
travis.sadecki@LIGO.ORG - posted 16:01, Tuesday 02 December 2014 (15380)
OPS Shift Summary

7:50 Jeff in LVEA loading 3IFO storage container

8:22 Keita to EY working on green WFS

8:26 Fil and Aaron to EY working on PEM cabling

8:32 Mitch to west bay 3IFO storage work

8:37 Excavators on site

8:54 Karen to EY

8:55 Betsy to west bay 3IFO work

9:01 Cris to EX

9:03 Corey to squeezer bay 3IFO work

9:06 Sudarshan to EX, EY PEM work

9:10 Keita done

9:34 Jonathan fixing remote login system

9:41 Dave restarting guardian

9:42 Fil pulling HEPI server

10:09 Mitch done

10:10 Karen done

10:20 JoeD checking forklift batteries in LVEA

10:23 Doug to LVEA for OpLev inspections

10:36 Dave to LVEA for tour

11:04 Jonathan done

11:05 Kyle done

11:10 Sheila to optics lab and squeezer bay for cleanup work

11:19 Jeff done

11:30 Sudarshan to EX

11:48 OpLev crew to EX

12:00 Corey done

12:03 Dave restarting DAQ

12:34 Dave restarting OMC model

14:40 Sudarshan done

15:48 Trenching work between OSB and VPW is complete and patched.  Road to EY is reopen.

H1 SEI
jim.warner@LIGO.ORG - posted 15:21, Tuesday 02 December 2014 (15387)
HEPI Z sensor correction running on all TM chambers

Sheila kind of requested this (I may have pushed for it), she feels confident she can turn it off if the commissioners feel it's causing problems. Tomorrow, I'll work on a python script for the commissioners to turn this on for all chambers, to make this easier, as the HEPI MEDM screens are a bit labyrinthine.

H1 General
jeffrey.bartlett@LIGO.ORG - posted 15:17, Tuesday 02 December 2014 (15386)
3IFO Suspensions Storage Container #3
Andres R., Mitch R., and Jeff B.

    We completed the loading of the HAM ISI 3IFO Storage Container #3. The suspensions would not fit as specified on page #3 of D1300146. We rearranged the suspensions so (1) the TMS Upper Structures were centered and moved as far towards the edge as could be, (2) the Quad sleeves are still in the center of the container but two had to be rotated 90° so they would stack, and (3) the AC baffles were placed around the edges at 45°, 135°, 225°, and 315°. See photos below. We encountered no other serious issues. 
Images attached to this report
H1 SEI
jim.warner@LIGO.ORG - posted 15:00, Tuesday 02 December 2014 - last comment - 15:38, Tuesday 02 December 2014(15384)
Input matrices updated on ETMY & BS ISI's

I updated the input matrices for ETMY and the BS ISI's this morning. This required redoing the isolation loops for both chambers, so I worked through those as well and re-installed all the filters. Afterwards, both chambers came right back up. Tomorrow, I'll try to do some performance comparisons for tonight and last night. In general, the loops are 30-35hz UGF's, and not particularly aggressive.

Comments related to this report
hugh.radkins@LIGO.ORG - 15:38, Tuesday 02 December 2014 (15388)

With Jims update of the ISIs here, this puts all SEI Local to Cartesian and back conversion matrices in the correct configuration.

Attached is the output from Hugo's check script (to back me up)--all values are correct.  It reports a problem with the BSC ISI HEPI L4C2CART matrix (not the St1 L4C2CART.)  I've checked these and set them manually.  I think the problem is likely that the scipt is comparing the 8x8 HEPI L4C matrix with the 6x8 ISI HEPI L4C matrix.  The ISI matrix doesn't have the pringle modes whereas the HEPI matrix does.  This is a slightly informed guess and maybe Hugo will notice and look closer still.

Non-image files attached to this comment
X1 SUS
jeffrey.bartlett@LIGO.ORG - posted 14:35, Tuesday 02 December 2014 (15381)
Quad08 TF and Spectra Data
    These are the latest transfer function and Spectra data plots for 3IFO Quad-08 found in the repository.  
Non-image files attached to this report
H1 ISC (ISC, SUS)
daniel.hoak@LIGO.ORG - posted 13:44, Tuesday 02 December 2014 - last comment - 14:54, Tuesday 02 December 2014(15375)
OMC and OMC-SUS model changes

Dan, Dave

Today we rebuilt and restarted the OMC and OMC-SUS models to incorporate Livingston's changes to the ASC for the output mode cleaner.  These changes add outputs from the OMC model that pass ASC control signals to the OMC SUS (L,T,V,P,Y,R).

We've also incorporated a change from Livingston to the OMC master model (userapps/release/omc/common/omc.mdl) which adds a software trigger to the OMC length control signal.  This trigger shuts off the output to the HV PZT (OMC PZT2) when the HAM6 trigger is closed.  The input signal to this software trigger is the output of the PZT1_MON_DC channel; this acts as a readback for the shutter controller state.  The idea is that when the HAM6 shutter controller detects an input condition (light level above threshold), we should disable the length control signal to the OMC.  (Note that this change is somewhat redundant with the input trigger to the OMC length control signal, which enables the OMC LSC when the DCPD sum is above a threshold.)

Awkwardly, the output of PZT1_MON_DC is different between the two sites.  At H1, the PZT1_MON_DC readback out of the PZT driver box is -20V when the trigger is in the nominal/open state, and 0V when the trigger is tripped/closed.  At L1 it's apparently -5V when open and 0V when closed.  Furthermore, at H1 we calibrate the output of PZT1_MON_DC to reflect the voltage that is delivered to the PZT in the chamber: 10V in the open state, 0V in the closed.

The punchline is that I've flipped the polarity of the software trigger to work with the conditions at H1, and I've changed the threshold to be 5V instead of -3.9V.  This means the H1 version of the OMC master model is different from L1 - see the attached figure.  We'd like to understand why the output of the PZT1 DC monitor is different between the sites, but for now we'll need to remember that the master model here at H1 is slightly modified.  I have not committed these changes to the SVN.

Images attached to this report
Comments related to this report
daniel.hoak@LIGO.ORG - 14:54, Tuesday 02 December 2014 (15383)

I've updated the OMC_CONTROL, OMC_ASC_DOFT2TT, and OMC_SUS_OVERVIEW screens to include these new channels.  See attached.

These MEDM screens have been committed to the SVN.

Images attached to this comment
H1 SUS (ISC, SEI, SYS)
jeffrey.kissel@LIGO.ORG - posted 23:57, Thursday 27 November 2014 - last comment - 14:14, Wednesday 03 December 2014(15329)
How to Improve the H1 HLTS Displacement Performance (Teamwork for SEI and SUS)
J. Kissel

In summary:
(1) Turn on X, Y, and Z sensor correction for HAMs 2 and 5, using the standard Hua Filter scheme (see T1200285), with tuned gains.
(2) Use LLO's M1 OSEM Damping filters and gains.
(3) Turn off optical lever damping so we don't have worry about maintaining optical levers to as great care.

-------

This continues (and hopefully resolves) the study of why PR3 and SR3 (both HLTSs) are angularly noisy, began by Kiwamu (see LHO aLOG 15048), and continued in a prior aLOG by me (see LHO aLOG 15154). I had started today thinking that I would do the usual full modeling suite, and this time include the optical lever damping. But after a little bit of exploring, I found that the L1 HLTS, H1 PR3, and H1 SR3 were using in various, completely different damping schemes, the performance of the optical levers are radically different, so a noise projection would be difficult, and the L1 vs. H1 HAM ISIs perform significantly different. So, since a "representative" model seemed impossible, as did the thought of making an individual model for all four suspensions and comparing, I've just spent the time gathering proof of what we need to do to make them much better. Once we get all of the above three steps completed *then* I'll make a full model suite of the performance.

Here's the details explaining how I can to these conclusions. They're supported by the first and only attachment.
(3) Turn off optical lever damping.
    Pages 1 and 2 of the attached show the wide variety of performance on the optical levers. Page 3 and 4 show the H1 the levers are in loop, but only with a bandwidth from 0.4 to 1 [Hz] (see design for SR3 in LHO aLOG 14719). There seems to be some effort toward rolling off the noise, but it seems quite unrelated to the actually noise performance of the levers at high frequency.
    LLO *had* used optical lever damping sporadically on L1 PR3, but they're currently not using it and haven't since Oct 17 2014. Given that the damping is so much strong and the input motion is so much smaller, this makes sense that its not needed. Further -- even with L1 SR3 aligned, the location to which, presumably, the optical lever has been centered -- the performance of the optical lever spectra is not limited by residual ground motion of the optic. So it's most certainly unusable for control. 
    Including optical levers in the local damping scheme complicates the remaining dynamics of the suspension (and perhaps more to the point, the subsequent modeling of it), and getting used to relying on them means they'll be left on and most certainly reinject noise above their bandwidth unless the loops are custom tailored to the ever-evolving optical lever noise. So if we can achieve the same level of local damping with the top mass OSEMs, and improve the performance of the ISIs, let's do it. 

(1) Turn on X, Y, and Z sensor correction for HAMs 2 and 5, using the standard Hua Filter scheme (see T1200285), with tuned gains.
    Pages 5 through 7 compare the performance of the HAM2 and HAM5 ISIs, highlighting the degrees of freedom which contribute to L, P and Y at the optic. 
    Remember, the L at the suspension point is the dominant contributor to L *and* P at the test mass, at all frequencies (see pgs 5 and 33 of the second attachment to LLO aLOG 7907). In turn, X and RY (for PR3) and Y and RX (for SR3) are the dominant contributors to L at the suspension point. Y at the optic is all Y at the susp. point, which is all RZ of the table.
    Though I'm not sure what the H1 HAMs have worse performance than the L1 HAMs between 2 and 8 [Hz] (that should be investigated further), I certainly know that the *drastic* difference between 0.3 [Hz] and 1 [Hz] is because LLO has sensor correction for all DOFs turned on. Poking around at LLO, I've found that the sensor correction is nothing particularly fancy -- it's just the standard Hua filter scheme, with a single, gain only Match filter at the output to tune better match STS gain to the displacement sensors (those gains are a correction of ~10-20%, matched to a ridiculously high precision [where its unclear if the precision is needed]). HAM2 uses the HAM2 STS (STS A), and HAM5 uses the HAM5 STS (STS C), as expected.
    At the first L and P resonances of the HLTS, there's a possibility for the following improvement if we get to LLO's level of isolation:
Frequency [Hz]   Table DOF      Performance Ratio
    0.64          HAM2 X       6.23 / 0.11 = 56.6
                  HAM5 Y       5.29 / 0.08 = 66.1 
    0.74          HAM2 X       1.87 / 0.03 = 62.3
                  HAM5 Y       1.42 / 0.02 = 71.0
and as we know by now, its these lowest resonance frequencies that dominate the RMS motion of the optic.
    All this being said, except for between 0.2 [Hz] and 0.6 [Hz], LLO is kicking the snot out of the "requirements." Nice job! I'm very confident that we can do just as well here at LHO. The trick will be to get the HAM2 and HAM3 sensor correction up at the same time, so that we don't introduce and relative low frequency noise in the recycling cavities.

    P.S. There're some pretty nasty sharp features and associated harmonics in the L1 HAM5 ISI's RX and RZ spectrum ... we should get that fixed -- they're obviously electronic, particularly ugly, and might affect pulsar searches.

(2) Use LLO's M1 OSEM Damping filters and gains.
    Pages 8 and 9 highlight the DRASTIC difference in damping loop filters. I hesitate to call the H1 HLTS filters a "design," because I know they were copied from the QUADs (hence the 0.43 [Hz] and 0.56 [Hz] resonant gains in the L and P filters, respectively). There's no reason at all we shouldn't just switch to the LLO design immediately -- these aren't under global control so we need not worry about changing any global control transfer functions, and though I haven't modeled it (yet) the increase in gain at just about all frequencies, especially what's focused at the *actual* first L and P modes of the HLTS. With the switch, we would get a factor of 16.2 increase in gain at 0.75 [Hz] in the L loop (which presumable will hit the same mode in P as well), and a factor of 44 increase in gain at the first, 1 [Hz], Y resonance.

With steps (1) and (2) complete, that means we can expect to improve the Y and P motion at the optic, at the main resonances by as much as three orders of magnitude.
Non-image files attached to this report
Comments related to this report
jeffrey.kissel@LIGO.ORG - 15:48, Monday 01 December 2014 (15364)
I attach a screenshot of the configuration the L1 HLTS damping filters are in that replicate page 8 of the above attachment. 

Note that there are two filters in FM6 and FM7, called "Plant" and "x[number]," where "number" is the equivalent EPICs gain. These are useful to copy over because they represent, well the plant and the EPICs gain. BUT there're never meant to be turned on in-loop, they're only for offline foton study. In page 8 of the attachment, for example, I have the "x[number]" filters on for both sites, so their overall gain can be easily compared. 

We can, of course, turn on the "x[number]" filters and keep all of the EPICs gain at -1.0, which I prefer, in the future. 
Images attached to this comment
jim.warner@LIGO.ORG - 12:12, Tuesday 02 December 2014 (15374)

I've added the Hua filters to all the HAM ISI's. There was a BSC script to do this that I spent some time modifying, so we now don't have to copy and paste from other chambers. Currently the top level script lives in the HAM4 control scripts folder (called Loading_Sensor_Correction_Filters_H1_ISI_HAM4.m), but there were some subroutines from the BSC that needed modifying to work with HAM, as well as a master FIR file in the HPI userapps filterfile folder, all of which I copied and made HAM specific. None of the original files were changed, I just made HAM specific versions. I'll try turning stuff on at HAM6 first, and get some plots, then talk to commissioners about times to try turning this on elsewhere and making measurements with cavities to try to optimize, if they'll let me.

jeffrey.kissel@LIGO.ORG - 14:46, Tuesday 02 December 2014 (15382)
Jim: we do *not* want to use Hua sensor correction filters in any DOF for the BSCs, see the third item in SEI aLOG 645. So, don't worry about getting them into the BSC filter banks.
betsy.weaver@LIGO.ORG - 15:04, Tuesday 02 December 2014 (15385)

As per Jeff's suggestion (2) above, and with the commissioning crew's approval, I have loaded new filters into the empty filter bank slots on all 6 Damping DOF's of both the PR3 and SR3 M1 stages.  None of the new filters have been enabled, and the damping loops are currently unchanged.  They/we might try enabling the damping filters later tonight or tomorrow.  At Kiwamu's suggestion, I'll also look at gathering comparison data for the different damping regimes now that they are available here at LHO on PR3, as well as installing them on SR3.  Attached are the screen snapshots of the PR3 and SR3 DAMP loops with the existing set of filters enabled, and new slots filled.  Note, before they are used, the available gain filters in FM7 needs some tweeking as the LLO gains do not match the LHO loop gains.

 

I did not copy the FM1, FM2, FM5, or FM10 filters.

Images attached to this comment
evan.hall@LIGO.ORG - 14:14, Wednesday 03 December 2014 (15415)

Betsy and I have enabled the new M1 damping filters (see attachment).

The gains have not been changed.

The SR3 oplev damping has been turned off. It may have to be retuned because of the M1 changes.

Images attached to this comment
Displaying reports 68061-68080 of 83041.Go to page Start 3400 3401 3402 3403 3404 3405 3406 3407 3408 End