Displaying reports 64801-64820 of 83039.Go to page Start 3237 3238 3239 3240 3241 3242 3243 3244 3245 End
Reports until 20:06, Saturday 30 May 2015
H1 General
edmond.merilh@LIGO.ORG - posted 20:06, Saturday 30 May 2015 (18716)
Daily Ops Summary

On site today: Kiwamu. Jeff K, Darkhan, Sudarshan, Dale w/Tourgroup

 

08:00 Due to the 7.8 mag quake in Japan, the IFO is a RED light district. I have my morning work cut out for me!

08:12 untripped input triples and isi. Got IMC lock back. untripped remaining small suspensions and related isi on output.

08:15 begin untripping and damping quads. Then getting sei back up and isolating.

08:38 SEI back up and at nominal state(s). Time to asses the alignment.

08:40 Begin intial alignment

11:15 after fighting with SRCL and two phone calls to Sheila, it turns out my alignment was good after al and WFS finally decided to give me the lock I had been looking for!!! Kiwamu in.

11:17 initiate ISC_LOCK

11:50 Mich wouldn't lock. Kiwamu found that PR2 had drifted slightly while I had been trying to get SRC locked.

11:55 Mich finally locked for first time today! Probably won't be the la st.

11:58 Bounce mode rung up and broke the lock @ REFL_TRANS step.

12:20 Another Japan quake 6.4 @ 18:49UTC. riding the wave......

13:36 finally got DRMI locked again. There is still ringing from the quakes. We'll stay at this stage until things quiet down a bit more.

13:45 here we go again. Shooting for DC_READOUT

13:49 busted at ANALOG_CARM. Me thinks it's still a bit shaky. Gonna try and make it to resonance and camp for a bit.

14:02 no dice. Gonna try RF_DARM, a less lofty goal perhaps.

14:38 still no happy face.

15:03 Going to try to stop at CARM_10pm to try and engage some Roll/Bounce mode filters/damping

LHO FMCS
jeffrey.bartlett@LIGO.ORG - posted 19:33, Saturday 30 May 2015 - last comment - 23:55, Saturday 30 May 2015(18725)
Reset RO System
Got alarm on CS RO system.
Bubba talked me through a system reset. 
CS RO system is back up and running. 

To Reset RO System:

1). The RO system is located in the "water room", (through door to the right) in the Carpenter's shop
2). The RO Panel (OSMO 23G) is to the left just inside the door to the water room
3). Press the "mute" button to silence the alarm
4). Press the "Off" button to shutdown the RO system
5). Press the "On" button to restart the RO system
6). When the RO transfer pump starts - the pressure gauge should be reading around 58psi

   The RO transfer pump is a red vertical pump on the floor half way down the back wall.  
    

Comments related to this report
jeffrey.bartlett@LIGO.ORG - 23:55, Saturday 30 May 2015 (18728)
RO went down again an hour after reset. Left down over night - Bubba will look at it in the morning
H1 CAL (CDS, DAQ, DCS)
jeffrey.kissel@LIGO.ORG - posted 14:16, Saturday 30 May 2015 - last comment - 11:14, Monday 01 June 2015(18720)
LHO Check Out of Calibration SVN Corrupted by Discrepant Versions of SVN on CDS Laptop vs Workstations
J. Kissel, K. Kizumi, S. Karki

While trying to commit our results from last night to the CalSVN, we discovered that every folder was complaining that the it was not a working copy of svn, e.g.:

jeffrey.kissel@opsws5:/ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/PreER7/H1/Scripts$ svn st
svn: warning: '.' is not a working copy

Totally confused, we went to the trunk of the repo, and it said messages about discrepant svn client versions:

/ligo/svncommon/CalSVN/aligocalibration$ svn st
svn: The path '.' appears to be part of a Subversion 1.7 or greater
working copy.  Please upgrade your Subversion client to use this
working copy.


In order to make progress on the work stations (i.e. the h1boot server) Kiwamu made a back of the repo into 
/ligo/svncommon/CalSVN/aligocalibration_backup_20150530/
and made a fresh checkout of the repo, in the normal path:
/ligo/svncommon/CalSVN/aligocalibration
which regained its normal functionality.

He then started digging around the log history to figure out what happened and found a bunch of commits from the LHO PCAL team yesterday evening... and then Sudarshan joined us for a happy (??) Saturday discovery.

We've diagnosed the problem (a totally innocent user just doing what the computer told him to do -- he should not be blamed for any of this!!):
Sudarshan was at the End Station trying to check in pictures of PCal camera on (new? old?) CDS Laptop called cdsmbp0. He tried to do an svn st just to check on things, and an svn update before he committed (very good!), but he got the following error message:
[controls@cdsmbp0 Measurements]$ svn st
svn: E155036: Please see the 'svn upgrade' command
svn: E155036 Working copy '/ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/PreER7/H1/Measurements' is too old (format 10, created by Subversion 1.6)
[controls@cdsmbp0 Measurements]$ svn update
svn: E155036: Please see the 'svn upgrade' command
svn: E155036 Working copy '/ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/PreER7/H1/Measurements' is too old (format 10, created by Subversion 1.6)

He obediently then followed the instructions:
[controls@cdsmbp0 Measurements]$ svn upgrade
svn: E155019: Can't upgrade '/ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/PreER7/H1/Measurements' as it is not a pre-1.7 working copy root, the  root is '/ligo/svncommon/CalSVN/aligocalibration'
[controls@cdsmbp0 Measurements]$ cd ../../../
[controls@cdsmbp0 Runs]$ cd ../../
[controls@cdsmbp0 aligocalibration]$ ls
branches tages trunk
[controls@cdsmbp0 aligocalibration]$ svn upgrade
Upgraded '.'
Upgraded 'trunk'
Upgraded 'trunk/Runs/'
#etc
#etc
#HERE'S A CRAZY BIT
Upgraded 'trunk/Runs/PreER7/H1/Measurements/FreeSwingMich/2015-05-27'
Upgraded 'trunk/Runs/PreER7/H1/Measurements/FreeSwingMich/2015-05-28'
nfs server cdsfs0:/ligo: not responding                               # <<< what the heck??
nfs server cdsfs0:/ligo: is alive again
Upgraded 'trunk/Runs/PreER7/H1/Measurements/DARMASDs/'                # <<< OK... moving on... ??
Upgraded 'trunk/Runs/PreER7/H1/Measurements/ElectronicsMeasurements/'
#etc
#etc
Upgraded 'branches'
Upgraded 'tags'
[controls@cdsmbp0 aligocalibration]$

This upgraded the hidden .svn configuration file in the entire repo in a way that is incompatible with any version of the svn client prior to 1.7. YUCK!!

It turns out that every computer does not source the svn client binary from the h1boot server as I would have imagined -- so this laptop was using its own copy of the svn binary /usr/bin/svn, which was of a later version than what is normally used on the work stations:
work stations: svn, version 1.6.17 (r1128011) compiled Aug 13 2014, 20:41:52
this laptop: svn, version 1.7.10 (r1485443) compiled Aug 13 2013, 15:31:22

What's worse, is that this "upgrade" to svn version 1.7.10 caused the entire h1boot server's copy repo to fail on the work stations as shown above immediately degrading the whole repo to just a normal unrepoed directory structure and it's not at all backward compatible. Even still more confusing -- svn version 1.6.17 doesn't even have an option to svn upgrade so we didn't believe (at first) what Sudarshan did was even possible.

Thankfully
- Sudarshan left the terminal open on this laptop so we were able to document everything that happened in great detail from this laptop's terminal session
- Kiwmau has made the back up mentioned above, 
- *and* Sudarshan ran an svn st after the upgrade on this laptop, so we know everything that wasn't committed of was modified. (see attached)
So nothing should be lost, we know the status of everything, and we can work to merge the backup back into the repo and move with out too much guess work.

However -- the SysAdmins (don't worry -- this wasn't your fault either!! This is a *terrible* backward compatibility issue with the SVN clients. I blame them!!):
 We should make sure all computers on site running svn cleint 1.6.17. IF and when we want to upgrade to svn client 1.7 or higher, we need to be absolutely sure that we do it to all computers at once.
OR we should demand that all computers are using a client that is hosted on the h1boot server, such that no computer is using an individual copy of an svn client.
 
#scaryscaryscary
#yakshaving

Non-image files attached to this report
Comments related to this report
keith.thorne@LIGO.ORG - 18:13, Saturday 30 May 2015 (18724)CDS
The SVN executable for workstations would not come from the H1 boot server, as that is running Gentoo at Linux kernel 2.6.34 for the front-ends.  The workstations should be at Ubuntu 12 (kernel 3.2).   Laptops can be problematic because they tend to be off for long stretches and so it is hard for CDS sys-admins to keep them updated.   At LLO, Michael Thomas has been very good at using our Puppet server to keep the fixed workstations up to date with consistent package sets.  Not sure how the Puppet practice is doing at LHO.

We would certainly recommend users NOT use CDS laptops for SVN checkins.  There should be sufficient workstations in VEAs and electronics rooms to address this.
david.barker@LIGO.ORG - 09:10, Sunday 31 May 2015 (18732)

This is a known issue. Mac Book Air laptops and mac-mini's are running Mac OS X which has SVN 1.7. Users should only use Ubunut workstations to perform SVN activities.

brett.shapiro@LIGO.ORG - 10:30, Monday 01 June 2015 (18741)

This sounds pretty scary.

For reference, I am running SVN version 1.7.19 on my laptop. But so far I haven't had any problems committing to or updating from the SusSVN.

The SusSVN is at Subversion version 1.6.17 (r1128011), as indicated at https://redoubt.ligo-wa.caltech.edu/svn/sus/.

H1 CAL (AOS, CAL, CDS, DetChar, INJ, ISC, SUS)
jeffrey.kissel@LIGO.ORG - posted 13:36, Saturday 30 May 2015 - last comment - 16:25, Monday 01 June 2015(18718)
H1 SUS ETMY Actuator Calibration: Free-swinging Michelson Method
THIS ALOG DISAPPEARED FROM THE ALOG LAST NIGHT, THIS IS A REPOST.

J. Kissel, K. Izumi

I've finished the analysis of the calibration of the H1 SUS ETMY actuators that are involved with global DARM control, where we've used the "free swinging Michelson method" (i.e. using the IR laser's wavelength as a frequency / length reference). The results are as follows:

    'iStage'     '[m/ct] @ DC'    '1-sigma Unc.'
    'ITMX L2'    [ 3.9461e-13]    [    0.013313]
    'ETMX L3'    [ 8.0906e-14]    [    0.026998]
    'ETMY L1'    [  4.851e-11]    [    0.026588]
    'ETMY L2'    [ 3.8468e-13]    [    0.026885]
    'ETMY L3'    [ 1.4543e-15]    [    0.027057]

The messages:
- Kiwamu is still finalizing his analysis, but we can safely see that a similar calibration using the ALS DIFF VCO as a frequency / length reference agrees with the above results.
- Assuming the ETMX ESD driver's DC gain is 40 [V/V] and the new ETMY driver's DC gain is 2 [V/V], then this translates to an ESD force coefficient of
    'optic'      '[N/V^2]'
    'ETMX L3'    [2.21e-10]
    'ETMY L3'    [7.96e-11]
This means that the ETMY ESD drive strength is 2.78 times weaker than ETMX.
- Though we've used the  full complex transfer functions for transfer function ratios and multiplication to get the final answers for each stage, what discrepancies we find in the phase of the final transfer function that determines the magnitude answer are ignored. This is because we determine the phase response / frequency dependence of the DARM actuator and DARM Sensor collectively when comparing the DARM Open Loop Gain Transfer Function against a model of the full loop, e.g. LHO aLOG 18186.
Curiosities that don't affect the answer, but are none-the-less irksome:
- We need to flip the sign of the measurement of the ITMY L2 stage drive to MICH, the ETMX L3 stage drive DARM, and the ETMY L3 stage drive to DARM in order for the overall phase of the final results to make sense.
- The phase of the ETMY L2 stage is offset from the model by ~10 [deg]. 
- We'll now use the above numbers to change the DC calibration of the DARM model parameter file that has been used for creating the DARM loop model, compare against a DARM OLGTF measurement and therefore make a statement about the optical gain.
- This method of determining the actuation coefficient -- especially for the very weak ETMY L3 stage -- is *very* time consuming, cumbersome and only gets quality results in the 4 to 7 [Hz] band, therefore we should do it rarely if at all in the future. PCal should become our new standard technique of determining the actuation coefficients and these kind of measurements should be the checks!

-------
Details
-------
MEASUREMENT METHOD
A lot of the methodology for this calibration technique has been outlined before (see most recently LHO aLOG 14135, most clearly (IMHO) P0900120, and originally in T030097), but I'll repeat it briefly here, because one needs to understand how we've augmented the technique further in order to obtain the ETMY L3 actuation strength.

One begins with the measurement from which the technique gets its name:
(A) After locking and aligning the IFO into a dark Michelson configuration (with PRM, SRM, and the ETMs misaligned), break the lock and measure the AS port's demodulated Q-phase signal ("AS_Q") and DC power ("AS_DC") while the Michelson freely swings through fringes. For the aLIGO IFO, that's H1:LSC-MICH_IN1_Q (a scaled version of H1:LSC-ASAIR_A_RF45_Q_ERR_DQ) and H1:LSC-ASAIR_A_LF_OUT, and we grabbed ~300 [sec] worth of data. As the Michelson evolves through fringes the AS_Q error signal proportional to the displacement of the mirrors:

AS_Q = (1/2) * A_{pp} * sin( (4*pi/lambda) * dl )             (1)

where A_{pp} is the peak-to-peak amplitude of the signal, lambda is the laser wavelength, and dl is the Michelson displacement, (lx - ly). We assume that the displacement is small (thanks SEI team!) such that 

AS_Q ~ A_{pp} * (2*pi/lambda) * dl = k * dl                   (2)

leaving the AS_Q signal proportional to the Michelson displacement by a real constant, k, the optical gain of the Michelson. Over the years, we've found that simply taking the peak-to-peak of the fringing time-series is prone systematic errors in determining A_{pp} due to drifts in alignment during the long uncontrolled stretch. As such, we've taken advantage of the sin / cos relationship of AS_Q and AS_DC and plot the ellipse they form as the Michelson fringes. We chuck up the long time series into several smaller time series and plot the ellipses, fit each to determine the semi-major axis of the AS_Q vs. AS_DC ellipse, and take the mean of each fit's semi-major axis to determine A_{pp} (see first page of attached). Because the fit of each chunk is a measurement of the inherent value of A_{pp}, we assign the standard error of the mean (i.e. d(A_{pp}) = std( A_{pp}^{i} ) / sqrt(N) ) as the uncertainty. For this measurement, 

k = 1.112e+08 +/- 1.7181e+05 [(MICH Displacement [m])/ (MICH Sensor [ct])]


(B) We eventually want to drive a given stage of the ITMs to determine the actuation strength of that stage with our newly calibrated MICH sensor, MICH_IN1 (AS_Q). However, we need the Michelson locked on a dark fringe so that the MICH error signal remains linear. So we must measure the MICH loop suppression. Now with the MICH locked, measure the MICH_IN2 / MICH EXC loop suppression transfer function. A little bit of loop math will show that 

MICH_IN2 / MICH EXC = 1 / (1 + G_{M})                          

as desired. Note that one *could* measure the open loop gain transfer function, G_{M}, directly, as MICH_IN1 / MICH_IN2 = - G_{M}, but for ease of uncertainty propagation, we've just measured the suppression directly. The open loop gain and suppression are shown in pgs 2 and 3. The uncertainty for each frequency point is determined from the coherence of the measurement and the number of averages,

                         1 - C  
d|TF| =  |TF| *  sqrt ( ------- )  [ same units as |TF| ]
                         2 C N  
                                                              (3)
                  1 - C  
d <(TF) = sqrt ( ------- )   [ rad ]
                  2 C N   

ref LHO aLOG 10506, or originally Bendat and Piersol, "Random Data" 2nd Ed, p317.

(C) Pick any stage of either ITM and take a driven transfer function of iStage ITM drive to MICH_IN1. With the data from (1) and (2), create an absolute calibration of this [(MICH IN1 [ct])/ (iStage ITM drive [ct])] transfer function in terms of [m] by inverting the optical gain and loop suppression:

  ITM Optic disp. [m]      MICH IN1       1            
--------------------- = ( ---------- ) * --- * (1 + G)                                       (6)
iStage ITM Drive [ct]      ITM EXC        k           

                              MICH IN1 [ct]            MICH [m]        MICH IN2 [ct]  -1          
                      = ( --------------------- ) * ------------  *  ( ------------- )       (5)
                          iStage ITM Drive [ct]      MICH IN1 [ct]     MICH EXC [ct] 

Each frequency point of the loop suppression and itm drive transfer function's uncertainty is determined by Eqs. 2 & 3, and are propagated to the uncertainty in each frequency point of the overall calibration by adding the relative magnitude and phase in quadrature. To compress each frequency point into an assessment of the overall DC actuation strength of that stage, we divide the resultant transfer function by a model of the actuation from that stage to it's optic. This way, if we've modeled the actuation strength as a function of frequency correctly, each frequency point becomes an independent measure of the overall strength of the actuator. As such, the single number and uncertainty for this stage is formed by the weighted mean and chi-squared weighted variance in the weighted mean,

          sum (x_{i} * sigma_{i}^{-2}) 
bar{x} =  ----------------------------                                                       (7)
             sum ( sigma_{i}^{-2} )                                                          Wikipedia
                             1                  1             (x_{i} - 1)^2
sigma_{bar{x}}^2 = ---------------------- *  ------- * sum ( --------------- )               (8)
                   sum ( sigma_{i}^{-2} )    (N - 1)           sigma_{i}^2                   Wikipedia
     

(D) The rest of the game is just using various parts of the interferometer to propagate this known "reference" actuator's absolute calibration to other optics. This is done by locking up a configuration that involves the reference actuator and actuator / optic you want to calibrate, and measuring the response of that IFO to both drives and taking the ratio of transfer functions:

  Optic Disp [m]           MICH [m]           ITM EXC [ct]        Some IFO [ct]
------------------   = ( ----------- ) *  ( -------------- ) * ( ----------------- )          (9)
iStage Drive [ct]        ITM EXC [ct]        Some IFO [ct]       iStage Drive [ct]

and the uncertainty is propagated in the same way as described in step C -- the frequency points of each new transfer function's uncertainty is determined by the coherence and number of averages, the uncertainty in the frequency points of the resulting product are the quadrature sum of the component TFs, the absolute calibration of the stage to optic is divided by a model, and the hopefully unity magnitude residual's weighted mean and weighted uncertainty are taken as the absolution calibration.

We found out Wednesday that the former method used in prior IFOs /science runs of just using a single arm IFO and propagating directly to the ETM doesn't work for the lowest strength actuators (i.e. ETMY L3) because the frequency noise of the Single Arm pollutes the measurement enough that one cannot get any coherence. As such, we've used many measurements to propagate the the absolute calibration to the ETMY L3: using the X single-arm to propagate ITMX L2 to ETMX L3, and then the full IFO in DC readout to propogate ETMX L3 to each stage of ETMY, e.g.

   ETMY L3 [m]         MICH [m]          ITM EXC [ct]        XARM IN1 [ct]         ETMX L3 EXC [ct]     DARM IN1 [ct]
---------------- = ( ----------- ) *  ( -------------- ) * ( -------------- ) * ( -------------- ) * ( --------------- )         (10)
ETMY L3 EXC [ct]     ITM EXC [ct]        XARM IN1 [ct]        ETMX L3 [ct]         DARM IN1 [ct]       ETMY L3 EXC [ct]


So if you're keeping track, that's six transfer functions and and a time series we have to take, and the transfer functions all need to take up a lot of time to get enough coherence that the uncertainty doesn't blow up. It's an all day adventure just to get all of these transfer functions. Thankfully, because of Kiwamu's care in getting the coherence super high, we still manage to get good data with reasonable error bars between 4 and 7 [Hz]. Any higher a frequency than this, and the original ITM to MICH transfer function hits the MICH noise floor. Below 4 [hz] the ITM to ETM transfer functions with the single arm loose coherence from frequency noise. So in addition to the many transfer functions we have to take, we only get a small frequency band where we can really get any sort of precision, and MICH isn't good enough to let us measure into the gravitational wave band.

WHERE EVERY THING EXISTS
The raw .xml files live here:
/ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/PreER7/H1/Measurements/FreeSwingMich/2015-05-28/
2015-05-28_H1DARM_ETMX_L3_Drive.xml
2015-05-28_H1DARM_ETMY_L1_State1_Drive.xml
2015-05-28_H1DARM_ETMY_L2_State2_Drive.xml
2015-05-28_H1DARM_ETMY_L3_LVLP_Drive.xml
2015-05-28_H1MICH_freeswingingdata.xml
2015-05-28_H1MICH_ITMDrives.xml
2015-05-28_H1MICH_OLG.xml
2015-05-28_H1XARM_ETMandITMDrives.xml
which have been exported to .txt files with corresponding _ts, _tf, or _coh tags to indicate the contents.

The analysis is done with 
/ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/PreER7/H1/Scripts/analyze_mich_freeswinging_data_20150528.m


Stay tuned for more actuation coefficient measurement technique comparisons, and an update to the DARMmodel, and therefore the CAL-CS and GDS calibration pipelines, and therefore the DARM spectrum and Inspiral range.
Non-image files attached to this report
Comments related to this report
jeffrey.kissel@LIGO.ORG - 15:37, Saturday 30 May 2015 (18721)
A record of a Saturday afternoon conversation for future reference: 

- Things to explore if we have infinite time and feel like we need to improve this method...

Jeff: "Key Kiwamu -- I was thinking -- uncertainty in this measurement technique at high frequency (> 7 [Hz]) is limited by the fact that we can't drive the ITM above the MICH noise during the initial (MICH IN1 [cy] / ITM Drive [ct]) transfer function. Fine, not much we can do about that, short of making the Simple MICH noise better (higher power if limited by shot noise, improving sensor electronics if limited by sensor noise -- nobody's bothered to budget it). At low frequency (< 4 [Hz]), we're limited by the propagation of the ITM drive to ETM drive via the single arm, because the frequency noise is too bad (one doesn't get the Michelson rejection of this noise source; the noise is limited by ). Why can't we just skip the whole single arm step, and go straight to the Full DRFPMI IFO, then make the ITM drive comparison?"

Kiwamu: " That won't work because in the Full DRFPMI IFO lock, the ITMs are involved in every length DOF, DARM, CARM, PRCL, SRCL, and MICH. So when you make the DARM IN1 / ITM EXC transfer function, you excite the other DOFs, and because MICH and SRCL (and maybe PRCL) are inherently coupled to DARM, the results get confused.


Jeff: "Hrmm -- How about a Fabry-Perot Michelson? In that configuration, there's no PRCL or SRCL to deal with, you get the natural benefit of the Michelson to reduce frequency noise. You're still sensitive to MICH (albeit by the fixed, frequency independent, 1/286 arm cavity gain) but this perhaps can be compensated in the calculation (though it adds its own uncertainty -- the real measurement is the loss in the arm, which we know can be challenging)."

Kiwamu: "Yeah, that might work. We've never locked that configuration consciously before, because that configuration isn't involved in the lock acquisition sequence. A configuration close to it exists -- during CHECK IR, ALS COMM and DIFF bring the FP arms in and out of resonance, and MICH is freely swinging. In theory one could capture MICH on AS_Q. BUT one needs to switch control of DARM and CARM from DIFF and COMM to some better CARM sensor and DARM sensor (like REFL_I and AS_Q in normal DRFPMI IFO), otherwise, the arms swing in and out of resonance, so you get intermittent FPMI and MI. If it's not too hard, we could try it."

- What the frequency noise limitation at low frequency? IMC Length Noise.
    - AS_I is error signal for single arm
    - AS_I is a measure of the difference between 
            arm cavity length * f / (Arm L) = arm cavity "frequency" 
      and PSL frequency. 
  Once the ARM is locked, the PSL is following frequency demanded by the 
            IMC length * f / (IMC L) = IMC "frequnecy." 
  So the comparison is actually between the IMC length and the arm cavity length. Not only is the arm cavity displacement much smaller than the IMC displacement (thanks to the BSCISIs and QUADs vs. HAMISIs and Triples), but you also lose because of the ratio of cavity lengths.
  So improving the IMC displacement (say by a factor of 2 - 5, which is all the SEI team could probably get us) doesn't really help.
  Best to just use some sort of Michelson configuration!
jeffrey.kissel@LIGO.ORG - 16:25, Monday 01 June 2015 (18756)AOS, CAL, CDS, DetChar, INJ, ISC, SUS
J. Kissel, K. Izumi

While beginning the comparison between the three methods for determining the actuation strength of the DARM actuators, Kiwamu found a bug in my "print the answer for aLOG" portion of my code. Nothing else in the analysis is affected and all plots and information above are still fine, but the stated answer for the [m/ct] for a given stage in the above aLOG is wrong.

Here's the corrected result after the bug fix:
    'iStage'     '[m/ct] @ DC'    '1-sigma Relative Uncertainty'
    'ITMX L2'    [ 6.6976e-13]    [ 0.013313]
    'ETMX L3'    [ 3.3491e-13]    [ 0.026998]
    'ETMY L1'    [  4.851e-11]    [ 0.026588]
    'ETMY L2'    [ 6.5291e-13]    [ 0.026885]
    'ETMY L3'    [ 6.0201e-15]    [ 0.027057]

And also, I include the ESD scaling coefficient with absolute uncertainty as Kiwamu has in his entry:
    'Optic'      '[N/V^2] @ DC'    '1-sigma Absolute Uncertainty'
    'ETMX L3'    [    2.21e-10]    [5.9667e-12]
    'ETMY L3'    [    7.96e-11]    [2.1538e-12]
H1 ISC
jeffrey.kissel@LIGO.ORG - posted 12:52, Saturday 30 May 2015 - last comment - 15:59, Saturday 30 May 2015(18719)
H1OMC Filter Coefficients Loaded
J. Kissel, E. Merilh, D. Barker

There was an errant message for a pending filter change to be loaded in the H1OMC front-end model this morning that Ed and Dave wished to be cleared. Initially I thought this was because of Evan's changes last night who was widening a few notches for the stability high-frequency control of DARM, so reloaded the filter coefficients. However I've diffed the last three filter coefficient loads, and it appears as though there was now difference between the foton files in my load and the previous load:

jeffrey.kissel@opsws5:/opt/rtcds/lho/h1/chans/filter_archive/h1omc$ diff H1OMC_1117049961.txt H1OMC_1116981302.txt
jeffrey.kissel@opsws5:/opt/rtcds/lho/h1/chans/filter_archive/h1omc$ tconvert 1117049961
May 30 2015 19:39:05 UTC
jeffrey.kissel@opsws5:/opt/rtcds/lho/h1/chans/filter_archive/h1omc$ tconvert 1116981302
May 30 2015 00:34:46 UTC

whereas Evan's filter changes appear in the previous load:

jeffrey.kissel@opsws5:/opt/rtcds/lho/h1/chans/filter_archive/h1omc$ diff H1OMC_1116981165.txt H1OMC_1116981302.txt
132c132
< # DESIGN   LSC_DARM 5 ellip("BandStop",4,1,80,1370,1570)ellip("BandStop",4,1,80,1900,2000)gain(1.25893)
---
> # DESIGN   LSC_DARM 5 ellip("BandStop",4,1,80,1370,1570)ellip("BandStop",4,1,80,1900,2000)
137c137
< # DESIGN   LSC_DARM 8 ellip("BandStop",4,1,100,480,527)ellip("BandStop",4,1,80,965,1040)gain(1.25893)
---
> # DESIGN   LSC_DARM 8 ellip("BandStop",4,1,100,480,527)ellip("BandStop",4,1,80,965,1040)
156c156
< LSC_DARM 5 12 8  16384      0 vStop2,3       0.8566107853664323  -1.6767014787035512   0.9206465781685556  -1.7005774752522538   1.0000000000000000
---
> LSC_DARM 5 12 8  16384      0 vStop2,3         0.68042765313912  -1.6767014787035512   0.9206465781685556  -1.7005774752522538   1.0000000000000000
167c167
< LSC_DARM 8 12 8  16384      0 vStop0,1       0.9393306641627603  -1.9479818388350045   0.9800449573887594  -1.9633364657747414   0.9999999999999999
---
> LSC_DARM 8 12 8  16384      0 vStop0,1       0.7461341489699668  -1.9479818388350045   0.9800449573887594  -1.9633364657747414   0.9999999999999999
jeffrey.kissel@opsws5:/opt/rtcds/lho/h1/chans/filter_archive/h1omc$ tconvert 1116981165
May 30 2015 00:32:29 UTC
Comments related to this report
evan.hall@LIGO.ORG - 15:59, Saturday 30 May 2015 (18722)

I don't know why the most recent two files see nothing when diffed.

As for the previous load: the violin notches in LSC-DARM have no gain normalization factors. There's nothing illegal about this, but it is bad filter hygiene. Together these two filters give almost 4 dB of attentuation to the entire loop.

I fixed this, loaded the coefficients, but then decided that maybe it was not a good idea to change the DARM gain while Kiwamu and Jeff were trying to calibrate the loop. So I unfixed it and loaded the coefficients again. That's why you see these coefficients disappear in the diff posted above.

H1 CDS (DAQ)
david.barker@LIGO.ORG - posted 08:36, Saturday 30 May 2015 (18717)
CDS model and DAQ restart report, Friday 29th th May 2015

no unexpected restarts. DMT reconfigure, h1oaf model change followed by associated DAQ restart.

model restarts logged for Fri 29/May/2015
2015_05_29 13:21 h1broadcast0
2015_05_29 17:21 h1oaf
2015_05_29 17:34 h1broadcast0
2015_05_29 17:34 h1dc0
2015_05_29 17:34 h1nds0
2015_05_29 17:35 h1broadcast0
2015_05_29 17:35 h1fw0
2015_05_29 17:35 h1fw1
2015_05_29 17:35 h1nds0
2015_05_29 17:35 h1nds1

H1 ISC
daniel.hoak@LIGO.ORG - posted 03:50, Saturday 30 May 2015 - last comment - 22:28, Saturday 30 May 2015(18714)
increase power step after dc readout transition

Tonight I followed up on the work that Stefan & I started two weeks ago, and switched the power-up step in the Guardian to come after the transition to DC readout.

Now, the OMC is locked at 2.3W input power, DARM offset = 3.7e-5 counts / 52 pm.  These settings were chosen to provide 20mA at the DCPD Sum.  At the transition to DC readout, the overall OMC-READOUT_ERR_GAIN is set to match the DARM gain on AS_Q, and the power normalization is absorbed by the OMC-READOUT_PREF_OFFSET, as Stefan described in the earlier entry.

During the INCREASE_POWER step the DARM offset (which after the handoff is set via OMC-READOUT_X0_OFFSET, in picometers) is stepped down to maintain the same photocurrent out of the DCPDs.  This *should* maintain the DARM gain through the quadratic scaling of DCPD Sum as a function of DARM offset...but it's not perfect.  I tried this twice today, and after the power-up finished, the DARM loop gain was too low by 30%.  Not sure if this is due to the initial gain matching before the handoff (this step still needs some work, maybe a tdssine measurement would be better), or some non-quadratic change in the response as we go from ~50pm to 16pm.  Stefan, Keita and I observed a small static fringe offset, we should make a careful measurement of DCPDSum vs DARM offset to check that what we think is quadratic really is.

We believe this arrangement is an improvement, because locking the OMC and transitioning to DC readout is more robust at low power, and also I suspect the power-up is more stable on DC readout.  I have increased the PSL waveplate velocity during the power-up (now it's 20, it was 10, not sure about the units), this worked without any trouble.  I am leaving the IFO locked at 23W in the LSC_FF state, with the intent bit set to "Undisturbed."  The range says 65Mpc - could it be true?  Earlier tonight there was a slow angular drift that killed a 23W lock, I am not sure how long we will last.  Also the ITMX oplev loop is ringing for quite some time after each lockloss, it may be a challenge for the IFO to relock on its own.

A screenshot of the new guardian sequence is attached.  I committed the ISC_LOCK.py code before and after the change.  I tested the new sequence twice without a hitch.

Images attached to this report
Comments related to this report
evan.hall@LIGO.ORG - 22:28, Saturday 30 May 2015 (18727)

ITM oplev damping is now automated in the guardian. The down state turns the damping off. The LOCKING_ARMS_GREEN state turns it back on.

H1 INJ (INJ)
eric.thrane@LIGO.ORG - posted 03:35, Saturday 30 May 2015 - last comment - 12:49, Monday 01 June 2015(18713)
transient injection tests with svn-controlled tinj
Kiwamu, Jeff, Dan, Cheryl, Eric

We successfully tested the transient injection code tinj at LHO for the first time.  This is also the first test of tinj since we added interaction with EPICS channels and migrated to svn.  An earlier version had been previously demonstrated at LLO.  The tests were carried out between GPS = 1117004777 - 1117006270.  We scheduled the standard BNS injection (1.4 on 1.4 msun with optimal orientation at 45 Mpc) that has been used in previous tests [1].  This file, which lives in svn, is called injection_H1.out.  The goal of the test was to inject this waveform with increasing loudness until the folks at LHO could see the signal sweeping across the strain spectrum.

The first attempt failed to inject because H1:CAL-INJ_TINJ_ENABLE = 0.  We set the value to 1.  The next several attempts (GPS = 1117004777, 1117004993, 1117005152) failed to show up because the transient gain in the CAL model was set to zero.  We set it to one and started over.  The following injections were successful:

1117005396 2 1 injection_
1117005598 2 4 injection_
1117005756 2 10 injection_
1117005914 2 100 injection_
1117006170 2 100 injection_

The first column is GPS time, the second is injection type (2 = CBC), the third is scale factor, and the last column is the prefix for the injection file.  Dan and Kiwamu weren't 100% sure they were seeing the BNS signal until we injected with a scale factor of 100.  During the last injection, (scale factor = 100), Jeff and Eric watched the output of HWINJ filter bank.  At the very end, it reached a value of ~50 counts, which did not exceed the current HWINJ LIMIT  = 200.

We fixed a bug with tinj.  First, we fixed a bug, in which the value of TINJ_PAUSE was interpreted incorrectly (1 should have been 0).  Also, the binary executable for tinj included in svn yielded a library error:

tinj: error while loading shared libraries: libmwlaunchermain.so: cannot open shared object file: No such file or directory

So, we recompiled a version that works at LHO and recommitted to svn.  NOTE: we have left tinj running in the background for a stability test.  However, there are no planned injections currently scheduled.

[1] https://alog.ligo-la.caltech.edu/aLOG/index.php?callRep=17073
Comments related to this report
christopher.biwer@LIGO.ORG - 06:57, Saturday 30 May 2015 (18715)
I've attached spectrograms of the five injections. The injections at 1117005598, 1117005756, 1117005914, and 1117006170 show up visibly in spectrograms of L1:CAL-DELTAL_EXTERNAL_DQ.

The segment database uses the name H1:ODC-INJECTION_CBC to flag CBC injections. I do not see the injections in the segment database. The following command was used:

ligolw_segment_query_dqsegdb --query-segments --segment-url https://dqsegdb5.phy.syr.edu --gps-start-time 1117005296 --gps-end-time 1117006270  --include-segments H1:ODC-INJECTION_CBC
Images attached to this comment
peter.shawhan@LIGO.ORG - 12:20, Monday 01 June 2015 (18745)
Small correction to something in the original post: note that injection type (TINJ_TYPE) 2 is actually Burst, not CBC, according to https://wiki.ligo.org/Calibration/HWInjBookkeeping and as used in CAL-INJ_ODC on https://wiki.ligo.org/DetChar/DataQuality/AligoFlags.  However, that is NOT the reason that there are no corresponding segments in the database.  See next comment.
peter.shawhan@LIGO.ORG - 12:49, Monday 01 June 2015 (18749)
If everything is working properly, hardware injections of transient signals should be indicated by bits in H1:CAL-INJ_ODC_CHANNEL_OUT_DQ (256 Hz, in raw frames), H1:ODC-MASTER_CHANNEL_OUT_DQ (16384 Hz, in raw, rds, and hoft frames), and H1:GDS-CALIB_STATE_VECTOR (16 Hz, in hoft frames only).  I checked this using a program called FrBitmaskTransitions that I wrote for this purpose.  (It's a handy program and everyone is welcome to use it.  It's currently living in ~pshawhan/hwinj/monitor/ on the Caltech cluster.)

H1:CAL-INJ_ODC_CHANNEL_OUT_DQ is the most fundamental since that bitmask channel is created in the CAL model.  Here's the report for that channel:

pshawhan@> ./FrBitmaskTransitions -c H1:CAL-INJ_ODC_CHANNEL_OUT_DQ /archive/frames/ER7/raw/H1/H-H1_R-11170/H-H1_R-111700[56]*.gwf
1117005056.000000  0x30001f87  Data starts
1117005139.625000  0x20001f87  28 off
1117005139.628906  0x30001f87  28 on
1117005139.644531  0x20001f87  28 off
1117005139.648437  0x30001f87  28 on
1117005139.667968  0x20001f87  28 off
1117005139.671875  0x30001f87  28 on
1117005139.738281  0x20001f87  28 off
1117005139.742187  0x30001f87  28 on
1117005139.992187  0x20001f87  28 off
1117005140.000000  0x30001f87  28 on
1117005331.496093  0x30001f82  0 off, 2 off
1117005396.007812  0x30001faa  3 on, 5 on
1117005484.734375  0x30001f82  3 off, 5 off
1117005598.007812  0x30001faa  3 on, 5 on
1117005638.519531  0x20001faa  28 off
1117005638.523437  0x30001faa  28 on
1117005638.800781  0x20001faa  28 off
1117005638.804687  0x30001faa  28 on
1117005639.468750  0x20001faa  28 off
1117005639.472656  0x30001faa  28 on
1117005639.500000  0x20001faa  28 off
1117005639.503906  0x30001faa  28 on
1117005639.519531  0x20001faa  28 off
1117005639.523437  0x30001faa  28 on
1117005641.589843  0x20001faa  28 off
1117005641.593750  0x30001faa  28 on
1117005641.976562  0x20001faa  28 off
1117005641.980468  0x30001faa  28 on
1117005686.734375  0x30001f82  3 off, 5 off
1117005733.746093  0x30000b82  10 off, 12 off
1117005734.496093  0x30001f82  10 on, 12 on
1117005756.007812  0x30001faa  3 on, 5 on
1117005844.734375  0x30001f82  3 off, 5 off
1117005914.007812  0x30001faa  3 on, 5 on
1117006002.734375  0x30001f82  3 off, 5 off
1117006170.007812  0x30001faa  3 on, 5 on
1117006258.734375  0x30001f82  3 off, 5 off
1117007040.000000  0x30001f82  Data ends
You can see that bits 3 and 5 go on and off when they should, corresponding to the five successful injections noted above. (Bit 5 is the bit in CAL-INJ_ODC for type 2 transient injections.) The CW injections were running continuously, except that I see that someone apparently turned off the HARDWARE ACTIVE switch momentarily (bit 10), causing the "HARDWARE non-zero" bit (bit 12) to go off at the same time. I don't know what bits 28 and 29 represent in this bitmask (they aren't in the table at https://alog.ligo-la.caltech.edu/aLOG/index.php?callRep=17990), or why bit 28 flickered on and off at times. I also don't know why bits 0 and 2 went OFF at GPS 1117005331.496093; the original post said that the transient gain was initially zero and then they switched it to 1, but if that's the cause then it seems like the meaning of bit 2 is opposite from what was intended (?). The summary bit (bit 0) is probably just following that. Now, combinations of bits from CAL-INJ_ODC are supposed to be represented by summary bits in ODC-MASTER, but I find that they were NOT set:
pshawhan@> ./FrBitmaskTransitions -c H1:ODC-MASTER_CHANNEL_OUT_DQ /archive/frames/ER7/raw/H1/H-H1_R-11170/H-H1_R-111700[56]*.gwf
1117005056.000000  0x90bff0d8  Data starts
1117007040.000000  0x90bff0d8  Data ends
The summary bit calculation probably requires bit 0 and/or 2 of CAL-INJ_ODC to be on. And the injection bits weren't set in CALIB_STATE_VECTOR either, but that's not surprising since those are derived from ODC-MASTER:
pshawhan@> ./FrBitmaskTransitions -c H1:GDS-CALIB_STATE_VECTOR /archive/frames/ER7/hoft/H1/H-H1_HOFT_C00-11170/H-H1_HOFT_C00-1117003776-4096.gwf
1117003776.000000  0x00000008  Data starts
1117007750.375000  0x0000001d  0 on, 2 on, 4 on
1117007750.437500  0x00000008  0 off, 2 off, 4 off
1117007872.000000  0x00000008  Data ends
It's curious that bits 4 (FILTERS_OK), 2 (SCIENCE_QUALITY), and therefore also bit 0 (HOFT_OK) flashed on for just a brief moment during the 4096-second interval I scanned, but that's unrelated to the hardware injection tests. Finally, no segments were inserted into the segment database, but that makes sense because bit 2 in CAL-INJ_ODC was off (for some reason -- maybe a bug) and I believe that is required to be on in the SegGener configuration.
H1 CAL
kiwamu.izumi@LIGO.ORG - posted 00:59, Saturday 30 May 2015 - last comment - 17:37, Monday 01 June 2015(18711)
ETMY L1, L2, ESD and ETMX ESD responses calibrated using ALS diff VCO

Jeff, Kiwamu,

This is a summary of the calibration of the ETMY suspension responses (in meters/counts) using the ALS diff VCO.

I have not evaluated systematic errors. The errors in this summary includes only statistical errors. The "models" I mean in this alog are the ones generated by the generate_QUAD_Model_Production matlab function in the suspension SVN. The model uses the "nominal" ESD force coefficient of 2e-10 [N/V^2]. The below is a summary of the results.

- - -

ETMY ESD is weaker than the model by 0.4242 +/- 0.0030

ETMY L2 is stronger than the model by 1.0344 +/- 0.0074

ETMY L1 is stronger than the model by 1.0269 +/- 0.0083

ETMX ESD is stronger than the model by 1.187 +/- 0.012

- - -

As for the ESDs, in terms of the force coefficient, they can be translated as

ETMY ESD force coeff. = 8.484 e-11 +/- 6.0e-13 [N/V^2]

ETMX ESD force coeff. = 2.374e-10 +/- 2.3e-12 [N/V^2]

 


[ETMY suspension responses]

I start from the results. See the attached two plots shown right below:

 

The first plot is a comparison of the measured response of all three stages with the models in units of [m/cnts]. Here "cnts" refers to the digital counts at the output of the ETMY_L1(2, 3)_LOCK_L filter bank. The second plot shows the ratio between the measured and modeled transfer functions. They are ratio of (measured) / (model). As you can see, the L1 and L2 stages agree with the model qualitatively. On the other hand, it is very clear that the ESD of ETMY is much weaker than what model predicts by a factor of 0.42. We don't know why this is so weak, but this is consistent with what the MICH free swing test says (see Jeff's alog for more details). Also, the L2 stage showed a phase lag of roughly 10 degrees. We don't know why at this point.

The steps for getting these results are something like the follows.

  1. Calibrate ALS diff PLL loop in units of meters/Hz using a controllable frequency source (alog 18634 and some more details at the bottom of this entry)
  2. Lock ALS diff and measure the ETMY L2 response
  3. Take out the loop suppression from the measured L2 stage response by measuring the open loop of the ALS diff loop. This gives the absolute calibration of the L2 stage in m/cnts.
  4. Fully lock the interferomter (at 3 W, DC readout on ETMX) and measure the response of all three stages to DARM_IN1.
  5. Since we know the absolute response of L2, we can propagate it by having the ratio between L1 and L2, L3 and L2 stages that are measured in full lock.
  6. done

If the ETMY ESD was stronger and as strong as that of ETMX, the steps in full lock are unncessary because we could measure it in the ALS diff configuration. However as we learned (see alog 18656), the low-voltage ETMY ESD needs a low-noise configuration. Note that the measured responses in full lock are also used in Jeff's analysis which had started from free-swing MICH fringes. Also, from the point of view of data points, we probably can go up to about 20 Hz at which the ALS diff signal is completely covered by some sensor noise. This time the frequency bins are chosen such that we can share them with the MICH calibration technique which was severely limited to frequency below 7 Hz due to high semsor noise in the simple MIchelson configuration.

As for the statistical error analysis, we used:

 

For comparing the measured responses with the models, we assume that the models and measurements have the same transfer function shapes and therefore the scaling factor is the only parameter we estimate. Though, this assumption may not be true because we see a large differenence in the phase of the L2 stage.

For completeness, I attach all the relavant measured responses:

The ETMY suspension states (for all the measurements):


[ETMX ESD response]

At a different time, we measured the response of the ETMX ESD using a similar technique to the ETMY measurement. The steps went as follows.

  1. Calibrate the ALS diff VCO (alog 18634 and more details in the next section)
  2. Lock ALS diff and measure the ETMX ESD response
  3. Take out the loop supression by measuring the open loop.
  4. done

Since the ETMX ESD does not use a low-voltage driver, the measurement can be complete only with the ALS diff loop closed. This is a big difference from the ETMY measurement which required low-noise stage for accessing the ETMY ESD.

The two plots shown below are the main results.

As shown in the first plot, overall, the measuement qualitatively agree with the model. The second plot shows the ratio of (measured) / (modeled). The absolute magnitude was larger than what the model predicted by a factor of 1.19. As mentioned earlier, the model uses a force coefficient of 2e-10 [N/V^2]. Unlike the ETMY ESD, the phase deviation (or perhaps I should say phase lag) is a bit larger than that of the ETMY for some unknown reason. The error propragation was done in the same fashion as that of the ETMY measurement (i.e. we included only coherence-based errors and VCO calibration error).

ETMX ESD configuration:

For completeness I post all the relevant transfer functions:

 


[ALS diff VCO calibration]

 On this past Tuesday, Dick and I measured the VCO response. We hooked up an IFR 2023 A which was synchronized to a 10 MHz rf signal (which is synchronized to GPS) to the diff PLL input or the PFD rf input with an amplitude of 0 dBm in order to simulate the beat note signal. Even though we could read out the display of the IFO 2023A, we used an external frequency counter (H1:ALS-C_DIFF_VCO_FREQUENCY) which should be at least as accurate as 5 Hz (see for example alog 6972). We locked the PLL loop and manually swept the frequency of the IFR until the PLL unlocks. The speed of the sweep was roughtly 25 kHz/minutes. Then we recorded the output of the DIFF_PLL_CTRL filter bank. One thing we have to pay attention is that this filter already contaied calibration filters which were meant to calibrate the VCO into microns, but as we measured the calibration factor was wrong by roughly a factor of 3.

The setting for DIFF_PLL_CTRL

In theory FM3 should cancel the pole and zero at 1.4 and 40 Hz respectively in the VCO circuit. The meaured data is shown in the plot right below:

The data was then trancated such that the center frequency is located at 78.92 MHz with a range of +/- 30 kHz for a linear fitting purpose. Also, since we made a linear fitting at around 78.92 MHz, in any of the calibration measurement we tried to be as close as possible to this frequency by engaging the slow frequency couter servo to the ALS diff VCO, According to the fit the coefficient was of VCO -> PLL_CTRL was esimtimated to be 4.78268e-6 +-/ 0.002531e-6 [cnts/ Hz] using a least square fitting of gnuplot. These numbers were used for calibrating the ETM responses and estimating the errors.

Finally I attach a zip file which contains all the data (in ASCII not in xml), analysis codes and figures.

Images attached to this report
Non-image files attached to this report
Comments related to this report
kiwamu.izumi@LIGO.ORG - 16:07, Saturday 30 May 2015 (18723)

Now, all the relevant codes, data, xml templates and figures are checked in svn with more appropriate and organized names. They can be found in :

  • aligocalibration/trunk/Runs/PreER7/H1/Scripts/AlsDiff
  • aligocalibration/trunk/Runs/PreER7/H1/Measurements/AlsDiff
  • aligocalibration/trunk/Runs/PreER7/H1/Results/AlsDiff
kiwamu.izumi@LIGO.ORG - 17:37, Monday 01 June 2015 (18761)

Jeff asked me to turn the actuator responses into meter/counts at DC (techniqcally speaking at 1 mHz). Here are the numbers:

- - -

ETMY L1 = 5.150e-11 +/- 4.1e-13 [m/cnts]

ETMY L2 = 7.007e-13 +/- 5.0e-15 [m / cnts]

ETMY L3 = 6.432e-15 +/- 4.9e-17 [m/ cnts]

ETMX L3 = 3.593e-13 +/- 3.5e-15 [m/cnts]

LHO General
cheryl.vorvick@LIGO.ORG - posted 00:10, Saturday 30 May 2015 (18712)
Ops Eve Summary

- commissioning early in the shift

- in and out of DC Readout the last 2 hours

Currently:  Eric Thrane making injections right now

IFO locking:  DRMI is taking a long time to lock, repeatedly needing alignment

H1 SUS (ISC, SUS)
sheila.dwyer@LIGO.ORG - posted 21:25, Friday 29 May 2015 (18708)
rms monitors for bounce and roll modes

Today we added a few filter modules and True RMS parts to the h1oaf model to allow us to monitor the size of the bounce and roll modes in DARM (alog 18706).  One motivation is to allow us to automatically adjust the gains of the damping loops based on the amplitude of the signal in DARM, a second to make it easier to identify which optic is rung up.

The changes to the model were simple;  we use the existing IPC that sends DARM control to the deprecated CAL part of the oaf model.  There are 10 new filter banks, 2 are used for fairly wide bandpasses to include all the bounce or roll modes, the rest are for a specific mode on a specific optic.  I've loaded bandpasses that are 0.04 Hz wide in the single optic filter banks, and I've added gains that make the rms roughly 1 when the modes are damped well enough that they don't show up in the DARM spectrum.  I'll look forward to readjusting these gains when the noise gets better.

The medm screen is accessible from the SUS tab.

Images attached to this report
H1 CAL (CAL)
richard.savage@LIGO.ORG - posted 18:20, Friday 29 May 2015 (18706)
Reduction in amplitude of Pcal lines

SudarshanK, RickS

We have reduced the amplitude of the higher frequency Pcal lines by about a factor of five as follows:

Xend 534.7 Hz:  28570 cts. -> 6000 cts.

Yend 540.7 Hz:  23500 cts. -> 5000 cts.

H1 CAL (INJ, ISC, SUS)
evan.hall@LIGO.ORG - posted 14:54, Friday 29 May 2015 - last comment - 18:24, Friday 29 May 2015(18699)
Hardware injections turned off

Jeff, Evan

The current CW hardware injections into DARM control are too loud to allow transitioning from ETMX to ETMY. So we turned them off around 21:00:00 by turning off the input to CAL-INJ_HARDWARE.

On ETMX, the loudest line (at 1395 Hz) has an rms of about 2 counts. For ETMY (with the low-pass filter on the low-noise driver), one must actuate 50×(50/2.2)2 ­ 26000 times harder at high frequencies. That means the ESD will have to push 50000+ counts rms. The attached plot shows the DARM drive at a few points along the actuation chain (only ETMX was used as an actuator). The hardware injection does not show up in DARM_OUT, or in the version of DARM_OUT that it sent to the CAL model. It does show up in the ETM drives. The attached screenshot helps us remind ourselves of the relevant model topology.

Also note that this is happening at frequencies above the Nyquist of the quad drive DQ channels, which is currently 1 kHz. That means it would have been much harder to catch this if we had been trying to do a lockloss analysis after the fact. The same goes for instances where the drive is being saturated by higher-order violin harmonics, as has happened in the past.

Images attached to this report
Non-image files attached to this report
Comments related to this report
keith.riles@LIGO.ORG - 17:58, Friday 29 May 2015 (18705)
The line amplitudes were bumped up by a factor of 10 for last night's test. Can we remove that factor of 10
to see if you still see problems? We can go down still further for the higher-frequency lines.
evan.hall@LIGO.ORG - 18:24, Friday 29 May 2015 (18707)

Yes, factor of 10 lower is probably fine. I turned injections back on with a gain of 1 instead of 10.

H1 AOS
sheila.dwyer@LIGO.ORG - posted 04:33, Thursday 28 May 2015 - last comment - 10:07, Sunday 31 May 2015(18660)
A2L measurements tonight

Dan, Evan, Sheila

Tonight we started to look at the angle to length couplings of our test masses.  We injected lines into pitch and yaw on the PUMs, and adjusted the A2L gains to minimize them.  Using the math in the 40 meter alog and Jax's alog, we can estimate the miscentering from these measurements

  Gain P2L vertical miscentering (mm) Gain Y2L horizontal miscentering (mm)
ETMX 1.6 21 1.1 14.4
ETMY 0.69 9 -0.3 -3.9
ITMX 2.4 31.5 1.15 15
ITMY 1.5 19.7 N/A (-1.7 to -2)  

After we had adjusted these, we saw an improvement in the spectrum below 20 Hz.  The line in the attached screen shot at 16.6 Hz with sidebands at half a hertz are the excitation.  Keep in mind that this is on the new ESD driver and we haven't redone the calibration yet, but clearly this improved the noise below 20 Hz.  

Earlier in the evening we were having difficuulty powering up because of a pitch instability at the main suspension resonant frequency that showed up in all the test masses.  We moved the QPD offsets for pitch back to what they were may 15th, (they had been changed last tuesday).  We then remeasured the miscentering for pitch only, things were a little bit better.  Once we increased the power to 17 Watts, the IFO was stable and we repeated some of the measurements.  We were able to power up to 23 Watts without seeing the instability twice, but lost the lock quickly for other reasons.

  Gain P2L vertical miscentering (mm) 17 Watts P2L  
ETMX 0.7 9.18 0.8  
ETMY -0.57 -7.5 -0.49  
ITMX 2.1 27.6 2.4  
ITMY 1.2 15.7 NA  
Images attached to this report
Comments related to this report
sheila.dwyer@LIGO.ORG - 05:32, Thursday 28 May 2015 (18661)
Note that it seemed like the key to increasing our power stably tonight was to revert the transmon qpd offsets for pit to what they were before alog 18613, but we haven't reverted the green cameras, green qpd offsets or the yaw IR qpd offsets. It might be best to revert those as well if there are any difficulties durring the day time
evan.hall@LIGO.ORG - 06:31, Thursday 28 May 2015 (18662)

DARM OLTF file attached. This template has reduced drive strength so that the ESD does not saturate in the LVLN state.

At last I was able to switch the DARM actuation over to ETMY at 25 W with the LPF engaged on the LVLN driver. We had discovered that the L1 LOCK filters on the ETMs were charging up because of small amounts of ringing in the lower stage filters. Therefore, the L1 filter for ETMX is zeroed after actuation is moved to ETMY, and the lock filters for ETMY are cleared after lockloss. Also, the INCREASE_POWER state now automatically increases the power to 25 W once again.

I tried the LOWNOISE_ESD_ETMY state at 25 W once, and it seemed to work. I then turned on some pieces of the LSC_FF state (namely the SRCL gain reduction, the SRCL cutoff, and the MICH FF). I am leaving the IFO locked with the intent bit undisturbed.

Non-image files attached to this comment
sheila.dwyer@LIGO.ORG - 10:42, Thursday 28 May 2015 (18666)
One more note for the day shift - we added roll mode damping to the guardian, it was working consistently last night with settings that also worked over the weekend, but if there are any difficulties it would be a good idea to comment this out
sheila.dwyer@LIGO.ORG - 17:20, Thursday 28 May 2015 (18673)

One last note: the power was 3 Watts in the spectrum attached, and to repeat, the calibration is not updated since the actuator change.  They're working on it

sheila.dwyer@LIGO.ORG - 15:08, Friday 29 May 2015 (18701)

The displacements in mm are wrong here, we were measureing from the PUM.

evan.hall@LIGO.ORG - 21:10, Friday 29 May 2015 (18709)

Another DARM OLTF, this time with the ETMY LPF off.

Non-image files attached to this comment
jeffrey.kissel@LIGO.ORG - 10:07, Sunday 31 May 2015 (18735)ISC
There are two DARM Open Loop Gain TFs attached as comments to this entry that represent the first two DARM OLGTFs taken with the new low noise ESD driver and the new L1L2L3 hierarchical control scheme. 

I've downloaded them and submitted them to the CalSVN for use later:
- From LHO aLOG 18662, DcDarmLVLN.xml, measured starting 2015-05-28 13:17:00 UTC, has been copied to 
/ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/PreER7/H1/Measurements/DARMOLGTFs/2015-05-28_H1_DARM_OLGTF_LHOaLOG18662_ETMYL3LPON.xml
- From LHO aLOG 18709, DcDarmLVLN.xml, measured starting 2015-05-30 03:07:00 UTC, has been copied to 
/ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/PreER7/H1/Measurements/DARMOLGTFs/2015-05-30_H1_DARM_OLGTF_LHOaLOG18709_ETMYL3LPOFF.xml.

I attach conlogs of all relevant DARM filter banks and BIO switches, where the date in the file name corresponds to each measurement.
Images attached to this comment
Displaying reports 64801-64820 of 83039.Go to page Start 3237 3238 3239 3240 3241 3242 3243 3244 3245 End