JeffreyK, SudarshanK, DarkhanT,

Overview

We made comparison plots of a DARM OLG TF and PCAL to DARM TF measurements taken at LHO with H1DARMmodel_ER8 and H1DARMmodel_O1 (uncorrected and corrected with kappa factors).

One of the main changes in the DARM model update for O1 compared to ER8 was that in the actuation function for ER8 model we did not account for an analog anti-imaging filter. We included that filter into the O1 model. Adding previously missing analog AI filter into the actuation function model increased the (measurement / model) residual to about 1% in magnitude and to ~6 deg around 500 Hz (~10 deg around 900 Hz). Initally some of the ER8 model parameter estimations (ESD/CD gains) were done to best fit the measurments for actuation function that does not include an analog AI.

We also took kappas calculated from calibration lines within about 20 minutes from DARM OLG TF measurement and plotted DARM model for O1 corrected with kappas in two different ways against the measurement to see how kappa corrections will take care of systematics in the model. At this point we don't have comparison results of the DARM OLG TF and PCAL2DARM TF measurements and kappa estimations to make a distinct statement. For this particular measurement from Sep 10, the DARM model that was corrected with κ_tst and κ_C produced smaller DARM OLG TF residual and actuation function residual compared to uncorrected model, but the sensing function residual was did not improve by the correction (see attached pdf's for actuation and sensing residuals).

Details

Some of the known issues / systematics in our DARM OLG TF model include:

• Not all of the sign flips in ESD (due-to linearization, direction of the applied force) and PUM were explicitly specified in the model parameters (for ESD sign flips see LHO alog 21739), also the location of a sign flip in the loop that is not part of A, C and D was not identified correctly in the beginning of ER8 (for correct location of this "-1" see LHO alog 21601). These issues were fixed in Matlab parameter file and DARM model for O1. Following aspects are affected by these issues:

- inverse actuation filters need to accout for an extra -1 sign (was fixed, see LHO alog 21703);

- CAL-CS reproduction should have a sign that's opposite from DARM output matrix (at LHO we had this correct, but it needed to be fixed at LLO).

• Shivaraj found that DAQ downsampling from 16 kHz to 512 Hz has frequency dependent phase roll-off that accounted for earlier unexplained ~44 degrees of phase discrepancy between the x_tst excitation and DARM_ERR readout measurement vs. model.

This issue affects EP1 value that's written into Epics record and used for estimation of DARM time-dependent parameters (T1500377). At LHO in the DARM model for ER8 we manually rotated phase of EP1 to +44.4 degrees to account for this discrepancy; we modified both the paramter file and the DARM model script to account for the DAQ downsampling filter TF calculated at the x_tst line frequency.

• JoeB found that an analog anti-imaging filter was not included into the DARM model for ER8 at both LHO and LLO, both sites started with H1DARMmodel_ER8.m script in which we missed to add this filter. On Monday, Sep 21, this issue was fixed in both LLO and LHO DARM models. The issue affects following aspects:

- residuals of actuation function and total DARM OLG TF (systemaic error);

- EP1-9 that are used for estimation of DARM temporal variations.

• We had an extra IOP cycle delay added into "par.t.actuation", which was not present in the parameter file and was not used to generate DARM model.

This variable might have been used in GDS calibration, we need to verify with MaddieW to make sure that this extra time delay is not included into GDS code.

• Both sensing and actuation residuals in the DARM model for O1 model extra delay (time-advance). This might be caused by overcounting time-delays or incorrect estimation of some other parameters.

One of the possible sources of systematic error in the sensing function model is using a single-pole TF to approximate IFO response.

Some of the parameters of the actuation functions were estimated without taking into account an analog AI filter (one of the issues listed above). We need to revisit ER8/O1 actuation function analysis results.

A comparison script, an updated DARM model script and DARM paramter files were committed calibration SVN:

CalSVN/aligocalibration/trunk/Runs/O1/H1/Scripts/DARMOLGTFs/

Plots were committed to:

CalSVN/aligocalibration/trunk/Runs/O1/H1/Results/DARMOLGTFs/

P.S. I'll add references later.

TITLE:  9/23 OWL Shift:  7:00-15:00UTC (00:00-8:00PDT), all times posted in UTC

STATE OF H1:   OBSERVATION @ 76Mpc

OUTGOING OPERATOR:  Jim W. 

SUPPORT:  Darkhan still here (Sheila is on-call, if needed)

QUICK SUMMARY:

• H1 has been locked at Nominal Low Noise since about 8:30UTC yesterday (almost 24hrs & through a Maintenance Day!!)
• 7:08UTC:  Received a GRB
• Watch out for elk!!  Saw a large bull elk on Route 10 between parking lot & FFTF turn off while driving into work (came within 20-30' of it as it crossed the road).

Verbal Alarms notified us of a GRB at 7:08:39UTC.  We acknowledged on Verbal Alarm Terminal.  And then went through the GRB checklist (in L1500117).

1. Confirmed this is NOT a test.  on GraceDB Latest page, this event is listed as E186583 with the comment:  "This event detected by Fermi Satellite"
2. H1 is already in Observation Mode.  Will be in stand down time from 7:08 - 8:08UTC
3. Talked with LLO Operator (William Parker) & confirmed they also received the alarm.

• Title: 9/22/2015 Eve Shift: 23:00-7:00UTC 

• State of H1: Observation Mode at 70+Mpc for the last 12+hrs

• Support: None needed. Various commissioners present

• Shift Summary:Quiet shift. 

• Activity Log:

• 0:20 Kyle Gerardo returning from mid X station

J. Kissel, for the CAL team

I've created a representative ASD for the start of O1. For now -- it uses data just before the start of the updates to GDS pipeline were started, at Sep 22 2015 11:29:47 UTC, Tuesday, Sep 22 2015 04:29:47 PDT. Why not after? Because NDS2 from matlab can't get data after the pipeline has been restarted. I'll work with Jonathan and Greg tomorrow to find out the problem. Also, because the comparison with the calibrated PCAL amplitude is within our stated uncertainty thus far (LHO aLOG 21689). Of course, this is just an ASD, and I have not respected the phase. More to come on that.

The strain and displacement ASDs -- and a corresponding ASCII dump of both -- is housed permanently and publically in G1501223, as a part of the collection of ASDs from the Advanced LIGO Sensitivity Plots. 

Techniques for how the ASD was computed can be found in T1500365, but I've used essentially the exact same process as was used for the "best" ASD from ER7 (LHO aLOG 19275).

A new feature this time around is a comparison of the PCAL vs. the GDS pipeline product. Delightfully -- even though the GDS pipeline was not yet updated, and I have not corrected for any time dependence, the GDS pipeline calibration of the PCAL excitation in DARM agree with the displacement calibrated by PCAL itself at all line frequencies, 36.7, 331.9, and 1083.7 [Hz] to better than 5%, which is consistent with our current uncertainty budget (LHO aLOG 21689). 

Now be fore we get all greedy and say "then why did we bother to update the GDS pipeline and why have we bothed to even compute the time dependent factors, remember that this is one measurement, and this is only the amplitude/magnitude. We must make the same comparison over a long period of time (a few days), look at the amplitude and phase, such that we can get a feel for how these track with time and we gather a feel for our remaining systematics.

Cheryl and Jeff brought to my attention that GWIstat was reporting incorrect information today.  It turns out that the ~gstlalcbc home directory at Caltech was moved to a new filesystem today; GWIstat gets its information from a process running under that account, and apparently got into a funny state.  I have now restarted it.  For the rest of the current observing segment it will report the duration only from the time I restarted it, about 3:32 UTC.  I apologize for the problem!

Durring the maintence window we left the DHARD yaw boost on (21768 and 21708). There was no evidence that it caused any problems, but I was putting excitations onto transmon at the time and there were other maintence activities going on.  We'd like to check that it doesn't impact the glitch rate, so if LLO drops out of lock or if you see an earthquake on the way ( 0.1um/sec or larger predicted by terramon), it would be great if you can turn it on.  You can find it under ASC overview> ASC arm cavities, DHARD YAW FM3 (labled boost). (screenshot) 

It would be good to get more than an hour of data, so if you see that LLO has dropped it would be awesome if you could turn this on util they are back up.  

This is just a temporary request, only for tonight or the next few days.  

SudarshanK, DarkhanT

We were using 137 degree of correction factor on kappa_tst on our time varying parameters calculation. (alog 21594). Darkhan found a negative sign that was placed at a wrong position in the DARM model which gave us back 180 degrees of phase. Additionally, Shivaraj found that  we were not accounting for DAQ downsampling filter used in ESD Calibration line. These two factors gave us back almost all the phase we were missing. There was also an analog antialiasing filter missing in the actuation TF that was applied in the new model. After these corrections, Darkhan created the new upated epics variable. These epics variable are committed at:

CalSVN/Runs/O1/Scripts/CAL_EPICS

Using these new epics  variable, kaapas were recalculated for LHO. For, LLO these epics variable doesnot exist yet. The new plot is attached below. The imaginary parts of all the kappa's are now close to their nominal values of 0 and real part are few percent (2-3%) from their nominal values of 1, which is within the uncertainity of the model. Cavity pole is still off from its nominal value of 341 Hz but has stayed constant over time.

The script to calculate these time varying factors is committed to SVN:

LHO: CalSVN/aligocalibration/trunk/Runs/ER8/H1/Scripts/CAL_PARAM/

LLO: CalSVN/aligocalibration/trunk/Runs/ER8/L1/Scripts/CAL_PARAM/

Kyle, Gerardo 

~1000 - 1315 hrs. local 

~1540 - 1720 hrs. local 

Sprayed CF flanges between Y-1 and Y-2 excluding GV9,10,11 and 12 lead screw nipples (purposefully excluded lead screw bellows too)

SETUP
Y-mid turbo backed by LD (QDP80 running but valved-out) 6 x 10-8 torr*L/sec external calibrated leak measured 7 x 10-8 torr*L/sec  - 4-5 LPM helium flow for 25 - 100 second dwell - indicated Helium background initially at 9 x 10-9 torr*L/sec fell steadily during testing eventually going off scale < 10-11 torr*L/sec.  

RESULTS
Looked like a response when spraying near closed vent/purge valve (high pressure, O-ring side) but couldn't duplicate after lunch.  Soft-cycled IP9 isolation valve - pressure went up when closed.

Shut down pumps and leak detector - Leaving turbo controller on overnight to ensure rotor stays levitated until at rest

These are the channels in the DMT (GDS) hoft frames, which include the calibrated strain channel (H1:GDS-CALIB_STRAIN) and the calibration factors (the kappas):

H1:GDS-CALIB_STATE_VECTOR 16
H1:ODC-MASTER_CHANNEL_OUT_DQ 16384
H1:GDS-CALIB_STRAIN 16384
H1:GDS-CALIB_KAPPA_A_REAL 16
H1:GDS-CALIB_KAPPA_A_IMAGINARY 16
H1:GDS-CALIB_KAPPA_TST_REAL 16
H1:GDS-CALIB_KAPPA_TST_IMAGINARY 16
H1:GDS-CALIB_KAPPA_PU_REAL 16
H1:GDS-CALIB_KAPPA_PU_IMAGINARY 16
H1:GDS-CALIB_KAPPA_C 16
H1:GDS-CALIB_F_CC 16

These channels should be available using NDS2.

(For LLO the channels are the same with: H1-> L1.)

Two things added:

1. If the script polling GraceDB fails, a red box with "GraceDB Query Failure"  will appear in the low right corner. Please inform the CDS group if this appears, and until it is resolved the Operator should monitor GraceDB for any new events.
2. On the bottom center, a box with CW Inj signal and Transient Inj signal. The CW inj is red when there is no injection (like right now), and green when there is. The Transient inj is Purple when there is an injection and grey if there is not.

Updated CAL_INJ_CONTROL medm. It is organized a bit differently, labels have changes slightly, and even has a new button! Duncan Macleod supplied us with an updated ext_alert.py that polls GraceDB for new events (both "E" and "G" types), places the new info in some EPICS records, and then will automatically pause injections for either 3600s or 10800s depending on the event.

The Transient Injection Control now has the ability to zero out the pause inj channel. Why is this necessary? The script running in the background of this screen will automatically PAUSE the injections when a new external event alert is detected. If we are down when we get a GRB alert, the script should still pause the injections. The Operator will then need to enable the injections and zero the pause time.

One other thing for Operators to look out for is if we want the injections to stop for longer than the automatic pause time. If we disable the injections by clicking the "Disable" button, and then a new event comes in, it will automatically switch from Disabled --> Paused (this happened to us a few minutes after we started up the script). I am not 100% positive on this, but it seems that when the pause time is up the injections will continue. If this is so, it's definitely something Operators need to watch for.

We will see how this goes and make changes if necessary.

New screen shot attached.

J. Kissel

Some combination of Dave, Jim, Duncan and TJ installed updates to the GRB alert code this morning during maintenance. This updated code now hits the "pause" button on the hardware injection software TINJ when it receives a GRB alert. There is an EPICs record, H1:CAL-INJ_TINJ_PAUSE, which records the GPS time of the time in which TINJ was paused. Somehow, this record -- which is used as a read back / storage of information, not a setting -- got missed when we went through the un-monitoring of INJ settings-which-are-readbacks channels in the CAL-CS model (see LHO aLOG 21154).

So this afternoon, while in observation mode, we received a GRB alert and the updated code pushed the TINJ pause button, which then filled in the H1:CAL-INJ_TINJ_PAUSE EPICs record, which triggered an SDF difference in the CAL-CS front end, which took us out of science mode. #facepalm.

I've chosen to un-monitor this channel and accepted it in the OBSERVE.snap table of the SDF system to clear the restriction for observation mode.

Note -- when we are next out of observation mode, we need to switch to the SAFE.snap table, un-monitor this channel, and switch back to the OBSERVE.snap table. We can't do this now, because switching the table would show the DIFF again, and take us out of observation intent mode again. #doublefacepalm

Elli and Stefan showed in aLOG 20827 that the signals measured by AS 36 WFS for SRM and BS alignment appeared to be strongly dependent on the power circulating in the interferometer. This was apparently not seen to be the case in L1. As a result, I've been looking at the AS 36 sensing with a Finesse model (L1300231), to see if this variability is reproducible in simulation, and also to see what other IFO variables can affect this variability. 

In the past when looking for differences between L1 and H1 length sensing (for the SRC in particular), the mode matching of the SRC has come up as a likely candidate. This is mainly because of the relatively large uncertainties in the SR3 mirror RoC combined with the strong dependence of the SRC mode on the SR3 RoC. I thought this would therefore be a good place to start when looking at the alignment sensors at the AS port. I don't expect the SR3 RoC to be very dependent on IFO power, but having a larger SR3 RoC offset (or one in a particular direction) may increase the dependence of the AS WFS signals on the ITM thermal lenses (which are the main IFO variables we typically expect to change with IFO power). This might therefore explain why H1 sees a bigger change in the ASC signals than L1 as the IFOs heat up. 

My first step was to observe the change in AS 36 WFS signals as a function of SR3 RoC. The results for the two DOFs shown in aLOG 20827 (MICH = BS, SRC2 = SRM) are shown in the attached plots. I did not spend much time adjusting Gouy phases or demod phases at the WFS in order to match the experiment, but I did make sure that the Gouy phase difference between WFSA and WFSB was 90deg at the nominal SR3 RoC. In the attached plots we can see that the AS 36 WFS signals are definitely changing with SR3 RoC, in some cases even changing sign (e.g. SRM Yaw to ASA36I/Q and SRM Pitch to ASA36I/Q). It's difficult at this stage to compare very closely with the experimental data shown in aLOG 20827, but at least we can say that from model it's not unexpected that these ASC sensing matrix elements are changing with some IFO mode mismatches. The same plots are available for all alignment DOFs, but that's 22 in total so I'm sparing you all the ones which weren't measured during IFO warm up. 

The next step will be to look at the dependence of the same ASC matrix elements on common ITM thermal lens values, for a few different SR3 RoC offsets. This is where we might be able to see something that explains the difference between L1 and H1 in this respect. (Of course, there may be other effects which contribute here, such as differential ITM lensing, spot position offsets on the WFS, drifting of uncontrolled DOFs when the IFO heats up... but we have to start somewhere). 

J. Kissel

I've increased the actuation delay before the sum of the the RESIDUAL (sensing) and CTRL (actuation) paths in the CAL-CS reproduction of H1:CAL-CS_DARM_DELTAL_EXTERNAL from four 16 [kHz] clock cycles (244 [us]) to seven 16 [kHz] clock cycles (427 [us]). This is done by changing the H1:CAL-CS_DARM_CTRL_DELAY_CYCLES EPICs record. The change is motived in LHO aLOG 21746. Recall this only affects the reproduction of the DARM displacement signal H1:CAL-CS_DARM_DELTAL_EXTERNAL (and therefore its ASD projected on the wall). I attach screenshots of the before and after. Note that the ASDs were taken ~30 minutes apart, so I don't expect the detailed structure to be the same. However, the change in phase at the sensing / actuation cross over causes overall shap change in the bucket. Also note that the transfer function used to remove the systematics from the DELTAL EXTERNAL channel will now have to be updated (documented in LHO aLOG 20481), to avoid double counting the high frequency affects. In the attached ASD, those corrections have *not* been changed, so we are likely double counting the corrections. More on that after I reconcile what Kiwamu had done and what Peter suggests.

I've captured the updated setting in both the OBSERVE.snap and SAFE.snap SDF files, and committed each to the repository.

To ride out earthquakes better, we would like a boost in DHARD yaw (alog 21708)  I exported the DHARD YAW OLG measurement posted in alog 20084, made a fit, and tried a few different boosts (plots attched).  

I think a reasonable solution is to use a pair of complex poles at 0.35 Hz with a Q of 0.7, and a pair of complex zeros at 0.7 Hz with a Q of 1 (and of cource a high frequency gain of 1).  This gives us 12dB more gain at DC than we have now, and we still have an unconditionally stable loop with 45 degrees of phase everywhere.  

A foton design string that accomplishes this is

zpk([0.35+i*0.606218;0.35-1*0.606218],[0.25+i*0.244949;0.25-i*0.244949],9,"n")gain(0.444464)

I don't want to save the filter right now because as I learned earlier today that will cause an error on the CDS overview until the filter is loaded, but there is an unsaved version open on opsws5.  If anyone gets a chance to try this at the start of maintence tomorow it would be awesome.  Any of the boosts in the DHARD yaw filter bank currently can be overwritten. 

J. Kissel on behalf of P. Fritschel & M. Wade

Peter and Maddie have been trying to understand the discrepancies seen between the CAL-CS front-end calibraton and the (currently offline running) of the GDS pipeline -- see Maddie's comparisons in LHO aLOG 21638.

Peter put together an excellent summary on the calibration mailing list that's worth reproducing here because it motivates changing the actuation path delay in the CAL-CS model, which we intend to do tomorrow. We will change the actuation delay to it's current 4 clock cycles to Peter's suggested 7 clock cycles.

On Sep 17, 2015, at 6:39 PM, Peter Fritschel  wrote:

Maddie, et al.,

I spent some time looking into this (GDS vs CALCS) today, and I think I have a few
insights to share.

Bottom line is that I think the GDS code is doing the right thing, and that the corrections
[to the front-end calibration that are used] make sense given the way things are done. And, I think there is a simple
way to make the CAL-CS output get closer to the GDS output.

As Maddie pointed out, the amplitude corrections we are seeing from the GDS code in the
bucket (50-300 Hz or so) are caused mainly by the phase from the anti-alias (AA) and 
anti-image (AI) filters, which are accounted for in the GDS model but not in the CAL-CS one. 

Maddie already gave some numbers for 100 Hz, and pointed out that the relative phase shift
she is applying (16.4 degrees) is 8 degrees larger than the relative phase shift that
the CAL-CS model applies (8.8 degrees, from 244 usec). I’m referring to the relative 
phase shift between the DELTAL_CTRL and DELTAL_RESIDUAL signals.

The first thing to note is that this difference is going to have different effects on the
L1 and H1 GDS calibration, because they have different DARM open loop gain transfer functions. 

The simple picture for the region we are talking about is we are looking at the errors
in the sum: 1 + a*exp(i*phi), as a function of small changes in phi. Here, the ‘1’ represents
the DARM error signal, ‘a’ represents the DARM control signal, and is less than one (but 
not much smaller than 1). ‘phi’ is the relative phase between the two channels, and it is
errors in this phase (or small changes to) that we are talking about. The magnitude of the
sum is most sensitive to changes in phi for phi = 90 deg. So to bound the effect, assume
phi = 90 deg. At this point, the sensitivity is approximately:

   d|sum|/dphi = a

Sticking with 100 Hz as an example, the error in phi that GDS is correcting is 8 degrees,
or phi = 0.14 rad. ‘a’ is the DARM open loop gain at 100 Hz, which is different for L1 
and H1:

   L1, a = 0.6 —>  d|sum| = 0.084
   H1, a = 0.4  —> d|sum| = 0.056

These are the maximum possible errors, depending on ‘phi’. Maddie’s latest plots show a
correction at 100 Hz of 7% for L1, 3.5% for H1. Quite understandable.

For higher frequencies, the phase error is going to increase, but ‘a’ (open loop gain)
will decrease, so you need to look at both.

At these frequencies the phase shift/lag from the AA and AI filters (digital and analog)
is linear in frequency, so we can easily make the extrapolations. 

Maddie’s comparison plot shows that the biggest relative difference is at 250 Hz, where it
is 9%. At 250 Hz, the phase shift error is going to grow to (250/100)*8 = 20 deg = 0.35 rad.
For L1, the DARM OLG at 250 Hz is about 0.3 in magnitude (a). So the maximum error is:

  d|sum| = 0.105 = 10.5%. (vs. 9% observed)

For H1, Maddie’s plot shows a relative difference of about 8% at just below 300 Hz- say 280 Hz.
The phase shift error will be (280/100)*8 = 22.4 deg = 0.4 rad. The H1 OLG at 280 Hz is about
0.2 in magnitude. So the maximum error would be:

   d|sum| = 0.08 = 8%. (vs. 8% observed)

I think the frequencies where the differences go to very small values in Maddie’s plots, like
150 Hz for LHO, are frequencies where phi = 0 mod pi, for which |sum| is to first order
insensitive to dphi. 

OK, so now I can believe that it is realistic to see the kinds of amplitude corrections
that Maddie is seeing, in ‘the bucket’. 

However, the above picture also suggests how CAL-CS should be able to get much closer to
the GDS output. The frequencies where this is an issue is where ‘a’ (OLG magnitude) is not
too small. But at these frequencies (below ~500 Hz), the phase lags from the AA/AI filters are 
very nearly linear in frequency. Thus, they can be well approximated by a time delay.

So here’s the suggestion: Why not increase the time delay that is applied in the CAL-CS 
model to approximate the AA/AI filter effects? Adding 3 more sample delays would come close:

   3 sample delay = 183 usec; phase shift at 100 Hz = 6.6 degree