Sheila, Dan, Daniel, Evan Jeff, Lisa, Alexa

Starting at 08:43:06 UTC Feb 11, 2015 we had a DC lock for ~1:54min. We lost lock again because of the 9 Hz bounce mode in ETMY. We had tried damping with the L2 stage, which helped a bit but still ultimately caused the lock loss.  Tomorrow we should try damping with M0, as done at LLO (LLO#16686).

We have seen in our two DC readout locks tonight what looks like it could be a fringe wrapping shelf in DARM. 

We transitioned to DC readout at 8:43:06 UTC Feb 11 and it is still locked.  If anyone could make a spectrogram of LSC-DARM_ERR durring this time, that would be interesting.  We made an attempt to do this using ldvweb, but didn't suceed yet.  

Alexa Daniel Dan Evan Jeff Lisa Sheila (+ many others)

Like a coffee hipster who won't touch beans that haven't passed through a civet, the IFO now measures DARM_ERR with the light transmitted through the OMC.

After the BS WFS were commissioned earlier today, we had several steady locks with 2.8W input power in which we attempted the handoff to DC.  We measured the DARM loop gain and set the UGF to be at the maximum of the phase bubble to make the transition as stable as possible (30Hz, ~30deg margin).  We experimented with different DARM offsets and settled on 5e-5 counts; with a preliminary calibration of 3x10^-7 m/ct this corresponds to an offset of 15pm.  The carrier TEM00 mode was somewhat larger than expected (see the attached pdf, peak at ~43 volts), about 15mA in DCPD sum, almost as much as the 45MHz sidebands.  We used this DARM offset for the rest of the evening.

We measured the OMC-DCPD_SUM --> DARM_IN1 transfer function and adjusted the OMC-READOUT_SCALE factor and LSC-OMC_DC_OFFSET to enable the handoff from AS45_Q.  The values we used are an offset of -2.33e-05 counts and a gain of -2e-6, these values were tuned at the few percent level in subsequent locking attempts to match gains as well as possible.  (Note that the gain comes before the offset, which makes trimming a little more straightforward.)  After these were applied the OMC-to-DARM noise TF looked like Fig. 1.  At this point we attempted the handoff to DC.

This blew the lock.  We realized the OMC input to DARM was subject to the normalization factor of sqrt(NPTRX).  We implemented an awkward fix by holding the output of the TR_X and correcting for the power normalization in the OMC-->DARM input matrix element.  The correction factor is 6.25, this changed by ~1% from lock to lock.

After that, the handoff to low noise worked.  The OMC DCPDs currently have no whitening enabled because the ETMY violin modes (at 508.1 and 508.2 Hz) are rung up and even a single stage of whitening will saturate the ADC.  So, we are ADC noise limited above ~400Hz.  One of our next steps will have to be the commissioning of the violin mode damping.  The ETMY bounce mode is also rung up; so far this isn't a problem, and we are nervous about turning on the damping before we're ready to end the lock.  A spectrum of the DCPD noise is in Fig. 2.

J. Kissel, B. Abbott

Over the past few weeks, I've been building up understanding of the HEPI pump servo -- more than I ever wanted to know. 

The conclusions from all this?
(1) The EPICs calculation of the PID loop (documented loosely in the EPICs manual here)
     (a) uses backwards differentiation approximation and velocity formalism to compute the *change* in control output value, which it then adds it to the previous cycle's control output value -- which turns it back into a "position" algorithm -- i.e. one *doesn't* have to differentiate the pole and two zeros of the P, I and D. Other good references I found are here, here, and here.
     (b) expects the "I" and "D" terms in [cycles / min] or [mins / cycle], respectively, i.e. it depends on the sampling rate / clock cycle turn-around time of the PID calculation. If you want to do any sane prediction of the filter shape, you've got to convert these to [rad/s] or [s/rad], again respectively, by multiplying by 60/(2*pi*Ts) [(min/sec).(rad/cycle)] or (2*pi*Ts)/60[(cycle/rad).(sec/min)].
(2) The EPICs turn-around time, or clock cycle, for the discrete PID controller calculation is longer than the requested sampling frequency, which means the sampling rate is determined by the clock-cycle. Further, it's slower in the corner station than the end stations. We should lower the EPICs record's demand of the sampling frequency from 10 [Hz] to 1 [Hz] (and check again if the PID can turn around the calculation fast enough).
(3) The HEPI Pump servo contains a second-order, 16 [Hz], Sallen-Key, anti-aliasing filter before the input to the ADC on all pressure sensor channels (see D0901559, pg 2)
(3) We should lower the PID parameters such that the UGF of the loop is ~ 1 [mHz]. Why?
     (a) The pressure sensors were never meant to be used as AC sensors. LHO aLOG 16500 hints that they shouldn't be used in a loop above a few [mHz].
     (b) The ADC noise of the Athena II, PC 104 computer is an abysmal 1e-2 [V/rtHz]. As they are currently amplified, the pressure sensor's signal gets buried in this ADC noise by ~10 [mHz].
     (c) Adding an EPICs "smoothing" parameter (a.k.a. SMOO) to the EPICs version of the pressure sensor channels adds a single-pole low-pass filter into the control loop. If sufficiently low in frequency, it'll start to creep in on your already-small phase margin. We should use this with caution, or at least be cognizant of its impact.

-------------
Details.

I attach 5 plots per pump station:

Pg 1: On the EPICs turn around time defining the sampling rate
In my perusing of the EPICs manual, I found that the PID channel, e.g. H1:HPI-PUMP_EX_PID, has sub records, one of which is "DT," which one can query with a simple caget:
jeffrey.kissel@opsws8:/$ caget H1:HPI-PUMP_EX_PID.DT
H1:HPI-PUMP_EX_PID.DT          0.312006
This is "the time difference in seconds between processing steps." Consequently, I caget'd this sub record 5000 times. This turned out to be faster than the EPICs calc record would update the number by 3, so I took every third report. Then I histogrammed the results, to find that the clock cycle is 0.55 and 0.28 [sec] (!!) for the corner station and both end stations, respectively. The end stations show some clock jitter, but I took the mode of the 1667 points and used that as the clock cycle. This immediately informs us that the features seen in all ASDs that happen at 1.8 [Hz] and 3.5 [Hz] at the corner and end stations are just a function of the terribly slow sampling rate -- even slower than the EPICs 16 [Hz], and the request calc record rate of 10 [Hz].

Pg 2: On EPICs Implementation Discrete PID Control
It's too difficult in a simple text editor to really do the explanation any justice, but check out all of the references I show above, while you wait for coherent presentation version of this aLOG. One of the many reasons why my initial guess at what the servo was doing (in LHO aLOG 16447) was incorrect was because I wasn't accounting to the time delay of the discretization. As I found out later, it turned out that the discretization was much slower that was defined in the EPICs calc record.

Pg 3: Modifying the measured plant (see LHO aLOG 16601) with the anti-aliasing filter, and an EPICs smoothing filter 
On the SMOOOOOOO at EY
Hugh's initial instinct to combat the newly-noisy differential signal was to add some EPICs sub-record defined "smoothing factor" to the supply and return channels which form the differential pressure signal. Again, from the EPICs manual, 
"The converted data value is subjected to the following algorithm:
val = newvalue * (1 - smoo) + oldvalue * smoo
SMOO should be a value between 0 and 1, with 0 meaning no smoothing and one meaning ultimate smoothing (in fact the data will never change)."
*sigh* who writes these manuals? Thank god they wrote out the algorithm. This is just the discrete realization of a first order low-pass filter. The pole frequency of which is defined by
f_{pole} = 1/(2*pi*Ts) * ln(1 / (1 / alpha))

Hugh had entered in a SMOO of 0.75, which at a dismal sampling rate of Ts = 0.28 [sec], means the pole frequency is at 0.159 [Hz], which explains *some* of the excess gain peaking that we see at EY. 

Pg 4: Loop Design figures of merit given the now-(mostly)-understood plant and controller

Pg 5: Model of closed loop ASD noise
Clearly I'm still missing some phase loss term that increases the gain peaking, but at least I get the suppression correct. I could hunt around for several more days as to why this is, and find some other nasty EPICs trickery. But I'm not gunna.

Thomas, Elli

We are interested in developing a way to measure the beam location on a test mass using camera images of the test mass. This can potentially be used for interferometer alignment.

This method is based on the PCal beam localization procedure. (See T1500039 for more details on the procedure.)

We used the Pcal camera on the ETMX to take a picture during full IFO lock. One can clearly see the red beam scattering off the test mass. To locate the center of the beam we fit a 2D gaussian to the beam scatter pattern in the image.  

The PCal camera is at a 10deg angle to the optic face.  We fit an ellipse to the image of the optic edge to work out its exact  orientation with respect to the camera. The we use this fit to locate the center of the optic, and the location of the center of the IR beam.  

Tonight we measure the IR beam location at {X,Y]=[-4.6mm,-20mm] +/- 5mm offset from the center of the optic.  This is a tentative result, we will put further thought into whether our beam fitting procedure has any sneaky assumptions in it.  
We also could reduce the uncertainty in this result by tweaking camera settings in order to better fit the optic edge.  The illuminator in BSC9 is on (it has been on since 19 December), turning this off would also help our cause.

The attached plot shows the tidal feedback signals during the 3.1 hour lock with the common correction on. There was about 150µm of motion in the y arm and about 100µm in the x arm, while the IMC stayed within a 100 KHz of nominal with no visible drift. The L1 drives of of both ETMs stay within 2µm of zero.

I have measured the violin mode using the most recent lock data (February 10th ~5pm). Due to the lack of precisions in the existing information and the mismatch in values I was not able to identify any of the peak except for the ITMX BR (Back Right) at 499.9 Hz. The violin mode found in the recent lock data are as follow:

499.9, 505.58, 505.71, 505.80, 505.85, 505.92, 506.92, 507.16, 507.20, 507.36, 508.01, 508.15, 508.20, 508.85 Hz 

The (fundamental harmonic) violin mode is expected to be somewhere between 500Hz and 520 Hz. Not every line is present - possibly due to high noise floor.

The violin mode has been previously identified as follow:

Positions of the wire:

BL = Back Left

BR = Back Right

FL = Front Left

FR = Front Right

Where's left and where's right you ask? I'm trying to find the answer myself!

I have started a SenseMon instance running on the dewhitened H1:OAF-CAL_DARM_DQ channel. The lock detection uses the guardian ISI lock channel as recommended by Jamie. I have set up a dmtviewer configuration to plot both the L1 and H1 ranges. The dmtviewer file is in 

   /opt/rtcds/userapps/release/isc/h1/scripts

and is called HL-Range.xml. I also added a script to set the DMTWEBSERVER environment variable so that it can find the web servers at both observatories. This is in the same directory and can be run from bash with 

   cd /opt/rtcds/userapps/release/isc/h1/scripts
  source dmtvsetup 

Then run dmtviewer with e.g.

  dmtviewer HL-Range.xml &

Note that this requires kerberos authentication so you must kinit and supply a key tab or username/password.

 

Lisa, Peter, Alexa, Evan

We have closed WFS loops to stabilize the angular motion of the BS during full lock.

We looked at ASA36Q and ASB36Q while giving small steps to the BS angle. We found that ASB36Q responds with the wrong sign (i.e., if the BS step gives an improvement to POPAIR18 and ASAIR90, the ASB36Q signals move away from zero), so we aren't using it. ASA36Q has the right response, so that's what we're using.

In the ASC-MICH filter banks, we are using FM1 (-20 dB), FM2+FM3 (1/f shape everywhere), and FM10 (inverse BS angular plant). The gains for both pitch and yaw are 0.3 ct/ct. The time constants of the loops are about 1 s.

On the BS suspension, we are feeding back only to M2. M1 is off. We are leaving the BS oplev damping on.

TCS slow channels

Alastair, Aidan, Dave. WP5043

The two laser setpoint channels which were temporarily added to script0's IOC last friday were removed and replaced by these plus more chanels in the h1tcscs front end model. The full list of new channels added to tcs/common/model/TCS_MASTER.mdl are

• H1:TCS-ITMX_CO2_LASERPOWER_SETPOINT
• H1:TCS-ITMX_CO2_LSRPWR_SETPOINT
• H1:TCS-ITMX_CO2_LASER_INTERLOCK
• H1:TCS-ITMX_CO2_CHILLER_TSTEP
• H1:TCS-ITMX_CO2_PZT_VOLTAGE_LCKPT
• H1:TCS-ITMY_CO2_LASERPOWER_SETPOINT
• H1:TCS-ITMY_CO2_LSRPWR_SETPOINT
• H1:TCS-ITMY_CO2_LASER_INTERLOCK
• H1:TCS-ITMY_CO2_CHILLER_TSTEP
• H1:TCS-ITMY_CO2_PZT_VOLTAGE_LCKPT

TCS_MASTER.mdl submitted to SVN r9793. This closes WP5043

PEM DAQ channels

Peter F, Robert S, Dave. WP5042

The PEM models h1pemcs, h1pemex, h1pemey, h1pemmx and h1pemmy were modified to conform with Peter and Roberts PEM data rates to frame document T1400768. There remains an inconsistency in the number of magnetometers and accelerometers, so this WP will remain open. Code was committed to SVN r9794

PCAL addition of working standard channel

Rick, Sudarshan, Dave. WP5045

An additional ADC channel was added to the PCAL model to read out the Working Standard signal. The model files pem/h1/models/h1pem[ex,ey] and cal/common/models/PCAL_MASTER.mdl were modifed. The new code went in at the same time as the above PEM restarts because CAL and PEM were merged. The PCAL_MASTER.mdl was committed to SVN r9763. This closes WP5045.

DMT Broadcaster and DAQ configuration

John Z, Dave

The following channels were added to H1BROADCAST.0.ini

• [H1:GRD-ISC_LOCK_ERROR]
• [H1:GRD-ISC_LOCK_MODE]
• [H1:GRD-ISC_LOCK_OK]
• [H1:GRD-ISC_LOCK_STATE_N]
• [H1:OAF-CAL_DARM_DQ]

The ALS testpoint par file was added to the DAQ (was accidentally left out during the ISC split last week)

DAQ Restart

Jim B, Dave

To support all the above, the DAQ was restarted. Jim delayed the startup of h1fw1 and h11nds1 to reconfigure their NFS mounts to support minute trend offloading on h1fw1.

Cleanup

Dave

I pressed all the DIAG_RESET buttons to clear accumulated ADC,IPC,etc. errors.

The following models had modified filter file warnings, I did a full filter file load on them: h1susmc2, h1iscex, h1iscey.

h1susmc2 did not seem to actually have a modified file (filter_archive files were identical).

isc end stations were a residual of the ISC split last week, so of the filters left in the isc models no actual filter changes were applied.
 

The first attachment is a time series of the HAM6 Watchdog, the Fastshutter State, and a GS-13 trace on HAM6.  The switch to low Gain is clear on this last trace.  This is a 5 day trend and the ~20 minutes needed to get the below .005Hz BW data is comfortably unmolested by the ISI or the fastshutter--the start times of the Spectra calculations begin at the vertical black lines.  As for ISI trips and shutter fires--there were none.

The High Gain Spectra period begins at 0800utc on 29 Jan, the Low Gain Spectra begins at 0800utc 1 Feb.

The second attached graph has Horizontal GS13s on HAM6 in High and Low Gain on the upper plot.  The Verticals are in the lower plot. High Gain Spectra is Dashed, Low Gain traces are Solid.  Also shown is our ADC noise in counts.

One caveat is that the ground motion is different at the two times.  The third attachment shows the Cartesian DOFs for the HAM6 GS-13s in the upper two plots and the ground noise in the bottom plot.  We've had a ground motion decrease in the microseism frequencies and below during the low gain period.  You can see the Low Gain Spectra are at the ADC level below 50mHz.  And the 10x signal reduction expected is more like 5x below these frequencies.  If this conclusion passes mustard, we'll have to revisit the GS13 triggering delays/levels.

DTT template is /ligo/svncommon/SeiSVN/seismic/Common/MatlabTools/HAM6_GS13_GainNoiseTest.xml