9/3 DAY Shift:  15:00-23:00UTC (08:00-16:00PDT), all times posted in UTC

Locked @Nominal_Low_Noise for ~12hrs with a range ~65Mpc.  Kept H1 in Observation Mode as much as possible (there were a few errant drops & then we stayed down for PEM Injections starting at around noon (PST).  I went through the Operator Checklist & completed most of it.  I am supposed to check the Visitor Checklist, and it looks fine.  I hesitated to check the HEPI watchdog saturation counter, for fear it might add diffs to the SDF (might try it tomorrow).

Remember: 

1. AFter lockloss, "INIT" ISC_LOCK (and possibly select DOWN).
2. Re-enable Transient Injections (to make CALCS SDF green), after PEM Injections
3. Make sure SDF is made GREEN after "Commissioning" work (I see HAM6 ISI has some diffs...& I see this is probably related to PEM injections).
4. IP-9 at MY still has HV values around 7kV.

End of shift Control Room Activities:

• PEM Injections
• Calibration work (this is post-work from last week and not touching H1).
•  

Log of Activities:

• 16:45UTC 250mL added to PSL chiller (Bartlett)
• 17:19 Robert talked with LLO to coordinate dropping out of Observation Mode (plan an hour from now)
• ~18:48 Beckhoff Timing Comparator button accidentally turned OFF/ON by Kissel (BUT, we stayed in OBSERVATION mode since we currently do NOT monitor Beckhoff channels.)  The button is at:  SITEMAP --> SYS --> Timing --> Corner A --> "11" Active Port button pushed.
• 18:30-19:30 FMCS computer went INVALID.  19:41 signals appeared to start coming back.
• 19:00 Talked with Peter regarding request for starting Transient Injection.  Since PEM Injections are starting, we decided to DISABLE the "ting".  Will ENABLE when PEM Injections are complete.
• 19:08 Dropped Out of Observation Mode due to SDF diff from DISABLING Transient Injection (!). [Peter Shawhan, Corey]
  • Stayed out of Observation Mode since PEM Injections starting (Observatory Mode taken to Commissioning.) [Robert & Anamaria]
• 19:41 Corner Station Temp is low VerbalAlarm (but this is due to FMCS going down earlier). [Bubba]
• 20:42 Load Coefficients was run for SUSITMX since there were filters added by Nutsinee/Dan for violin mode work. [Dave B]

DCS restarted the diff of the H1 science frames written by the two framewriters: Sep 03 2015 15:29:47 PDT

J. Kissel

I got sick of trying to debug the high-frequency affects UIM driver (LHO aLOG 21142), so I've moved on to the more important ESD Driver for H1 SUS ETMY. Instead of fitting the results of the remote measurements of the driver with the monitor circuit (LHO aLOG 20846), I've gone back to the measurements originally taken just after the LVLN driver was installed (LHO aLOG 18579), and fit them more precisely than Evan used to inform the current compensation filter (LHO aLOG 18596). Below are the details. 

The messages: 
- Each of the quadrants are *differently* frequency dependent at the ~5% level ~ 5 [deg] level; since we desire higher precision than this, they cannot be modeled with the same set of poles and zeros for each quadrant.
- In order to model this correctly, will have to 
    - break out the quadrants in the actuation chain model, 
    - de-compensate for the installed compensation filter, 
    - use the fit poles and zeros from each quadrant, and 
    - then sum the quadrants together (and divide by four as necessary)

--------------
The answer:
Here're the precise poles and zeros for each quadrant:

       Diff Receiver      Summing Node      LP1            LP2      Overall DC Gain                         Summary
      (one pole, [Hz])    (z:p) [Hz]      (z:p) [Hz]   (z:p) [Hz]       [V/V]                      z [Hz]: p [Hz]: k [V/V]
UL         24e3            3200:165       48.8:2.160   48.8:2.160      1.8868         (48.8 48.8 3200) : (2.16  2.16  165 24e3) : 1.8868 
LL         23e3            3050:160       47.8:2.105   47.8:2.105      1.8868         (47.8 47.8 3050) : (2.105 2.105 160 23e3) : 1.8868 
UR         24e3            3050:157       48.8:2.160   48.8:2.160      1.8868         (48.8 48.8 3050) : (2.16  2.16  157 24e3) : 1.8868 
LR         24e3            3125:160       47.8:2.130   47.8:2.130      1.8868         (47.8 47.8 3125) : (2.13  2.13  160 23e3) : 1.8868 

These poles and zeros result in a frequency dependent residal, which represents a systematic error in the fit. This systematic error is smaller that 1% and 1 [deg] over the entire frequency band for all quadrants (save for where we know the measurement is incoherent noise at ~30 and ~100 [Hz]). Rather than bothering to carry around the precise systematic error and figuring out how to propagate it correctly through the uncertainty analysis, we shall just represent this as this a statistical, 1-sigma, uncertainty of 1% and 1 [deg]. We used to call this being "conservative," but really it's a "perfect is the enemy of good enough" decision.

Open the attachment for plots demonstrating the goodness of fit (pg 1) and comparison of each quadrant against the fit and other models (pg 2-5), and a comparison of the models when the LP filter is OFF (pg 6).

The fitting process:
There are four models that I show: "Spice", "Simple Circuit", "(Compensation Filter)^-1", and PZ fit. 
"Spice:" Rich had graciously provided us with a spice model of the entire driver with both the low-pass off and engaged: 
/ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/PreER7/H1/Scripts/Spice/
LVLN_Driver_v8_PZ_Off.txt
LVLN_Driver_v8_PZ_On.txt
"Simple Circuit:" For my edification, to determine what parts of the box were determining which parts of the frequency response, I also did some simple analytical analysis of the driver accounting for all of the parts of the driver that contribute to the frequency response. 
"(Compensation Filter)^-1" These are the poles and zeroes currently used in the ESDOUTF bank, under the "antiAcq" and "antiLP" filters, a "good enough" compensation developed by Evan back when the driver was first installed.

I had started off hoping, like we always hope, that one can compensate each quadrant of the ESD driver with the same set of poles and zeros, based on those pole and zero frequency derived from some simple RC analysis of circuit. Turns out this is not the case. The frequency-depednent residual between the Spice, Simple Circuit, and (Compensation Filter)^-1 models and each quadrants' measurement for the following models is upwards of 10% and 5 [deg], different for each quadrant. 

A such, I created the PZfit model, where each quadrant's residual is tuned to as small as possible using the same number of poles and zeros as in the simple circuit model. That results in the poles and zeros quoted above.

---------
Analysis script lives here:
/ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/ER8/H1/Scripts/Electronics/model_LVLN_driver_20150902.m

(Peter Shawhan, Eric Thrane, Corey Gray)

Using waveforms created by Chris Pankow, we have set up a schedule of burst hardware injections to occur once every 10000 seconds (~2.7 hours).  The schedule runs from now through the end of ER8, but we intend to turn them off once we've obtained 10 coherent (successful at both sites) burst injections.  This series is primarily intended to check the infrastructure, the low-latency analysis, and the EM follow-up alert generation machinery; we're not yet attempting to verify the calibration.  The injections are all scheduled for GPS times 1000*n+500, i.e. the first one should happen at GPS 1125350500, the next one at 1125360500, etc.  However, an injection will be automatically skipped if ANY of the following conditions is true:
   * The detector is not locked (L1:GRD-ISC_LOCK_OK==0)
   * We are not in Observing mode (L1:ODC-MASTER_CHANNEL_LATCH bit 0 is off)
   * There has been a GRB or SNEWS alert within the past hour (L1:CAL-INJ_EXTTRIG_ALERT_TIME is a GPS time less than an hour before the current time)
   * Injections are currently disabled by the operator (the Disable button on the TINJ / Transient Injection Control medm screen has been clicked, which sets L1:CAL-INJ_TINJ_ENABLE = 0)
   * Injections have been temporarily paused by the operator using the Pause button on the TINJ / Transient Injection Control medm screen (which sets L1:CAL-INJ_TINJ_PAUSE to a future GPS time when the pausing should end)
So, it's anybody's guess how long it will take to obtain 10 coherent burst injections.

To get this started at LHO, we needed to start the 'run_tinj' process on h1hwinj1, which hasn't been running since August 25.  I talked with Corey, who asked that we not do any hardware (strain) injections right now because the PEM injection folks were about to start doing tests.  However, we worked out that the injections can be disabled for now using the Disable button on the TINJ Control medm screen.  LHO had an old version of the screen, but Dave updated it to the latest version which has the Disable button (along with Enable and Pause).  Corey clicked Disable, and I double-checked that it's disabled by doing 'ezcaread H1:CAL-INJ_TINJ_ENABLE'.  I then did "nohup run_tinj &" at about 12:44 PDT.  So tinj is running now, but injections will be skipped until an operator clicks the Enable button on the TINJ Control medm screen.  Please do that when the PEM injection folks have finished their work - thanks!

There was one side effect that I didn't expect: when Corey clicked the Disable button, it took the detector out of observation mode.  Corey said that looks like it was done by sdf, i.e. this status (injections disabled) is being considered nonstandard.  I'm not sure if that is due to checking the value of L1:CAL-INJ_TINJ_ENABLE, or to some read-back bitmask value.  We should follow up with Jamie to find out, and take the injection enable/disable out of the configuration check if possible.  However, this isn't a problem right now because the PEM injection folks wanted to be out of observation mode anyway.

J. Kissel, D. Barker

I had to look didn't I. Anamaria asked me what channel represents the IMC VCO frequency. The answer is H1:IMC-VCO_FREQUENCY, which is a Beckhoff-renamed version of the signal from the timing comparator, H1:SYS-TIMING_C_FO_A_PORT_11_SLAVE_CFC_FREQUENCY_5.

However, to find this infomration out, I knew that the VCO frequencies are generated from the corner station timing comparator, so I opened up the timing screen. I found two things:
(1) The Timing MASTER's status light was red. Dave informs me that this is because of the recent tests of the 9 and 45 MHz oscillators in the EE shop. They had stolen a sync signal from port 7 of the MASTER via fiber into the EE shop. This has since been disconnected, which made the monitor of the status channel
H1:SYS-TIMING_C_MA_A_PORT_7_ERROR_FLAG
go red.
We've hit the monitor button, 
H1:SYS-TIMING_C_MA_A_PORT_7_ACTIVE 
and the status light has gone green.

(2) In the corner A fanout, even though it's unrelated to the IMC VCO frequency, we noticed that whatever 5 MHz frequency is being measured on port 11,
H1:SYS-TIMING_C_FO_A_PORT_11_SLAVE_ISIRIGB
is blinking in and out. The last attechment shows the past hour, showing that this has been intermittently blinking in and out for long time.

Screenshots of the timing screens also explain what we saw.

-------------

For the record, all of this was done in "observation mode." Granted, all I did was turn on and off monitors, but I don't think we should go into observation mode if the timing master status light is red... I assume this is because Beckhoff as a whole has not been folded into the settings monitoring.

We have planned to do a series of burst hardware injections during ER8, but that has been held up for a long time while we sorted out how to get them properly recorded in GraceDB so that, if an event is identified by the low-latency analysis, it's known immediately if it's a hardware injection.  I finally solved this problem and have created HardwareInjection records in GraceDB for all of the burst hardware injections scheduled between now and the end of ER8.  There won't actually be injections at ALL of those times, but they're pre-marked anyway.

The next step is to actually turn on the burst hardware injections.  I will talk with the operators and, if there are no objections, turn those on.  Note that operators should free to pause or disable the burst injections (using the MEDM injection control screen) if there is any concern that they might interfere with ongoing activities; just please remember to re-enable them when it's OK for them to resume.

For reference: I did this with the new 'gracedb_burst_sync' script in HardwareInjections/Details/tinj.

ER8 Day 17

model restarts logged for Wed 02/Sep/2015
2015_09_02 06:43 h1fw0

unexpected restart of h1fw0

9/3 DAY Shift:  15:00-23:00UTC (08:00-16:00PDT), all times posted in UTC

Handed an H1 which has been locked since about 11:45utc (4:45amPT), and range is hovering around 66Mpc.  So we are GREEN with Intent Bit, Observatory Mode and even GWI.stat!  (Yesterday GWI.stat was pink since there were Hardware Injections in progress.....but see my boo-boo below.)

Seismically we look quiet and winds are under 10mph.

Jim mentioned for the next lockloss, one will have to hit INIT on the ISC_LOCK (and if nothing happens,  select DOWN).

16:10:40UTC:  Out of Observation Mode!  I accidentally hit the "Toggle hardware output on/off button", thus dropping us out of Observation mode!  (I meant to look at the Hardware Injection filter bank [button above toggle] to see what it looks like today vs. yesterday since GWI.stat is not in Injection mode.  My mistake!)  At any rate the Toggle button toggles the OUTPUT button for that filter bank.  I toggled it back to where it was (with the help of SDF), and then went back to Observation Mode.

16:12 UTC:  Back to Observation Mode!

Plan For the Day:

Will stay in Observation mode as much as possible, but know that PEM Injections will most likely be occurring at some point.  As of 16:23UTC, I had contacted LLO & they mentioned recently going down for calibration work (probably for another ~30min).  Then they'll go back to Observation for lunch, and then after they hope to do some Commissioning.

Bubba mentioned wanting to tip toe into the LVEA to make a grouting measurement (will call him during a lockloss or if it could be done in parallel with PEM injections later.)

Mostly a quiet night of commissioning.

Evan was in and out of CER, taking measurements on 9 Mhz  work. 

~13:45 Locked, concurrent with LLO 

Periodic glitches with simultaneous saturations on ETMY causing big drops in range.

Dan, Daniel, Evan

Summary

The addition of a 9.1 MHz bandpass on the OCXO output has removed the broadband excess noise between DCPD sum and null. The dashed lines in the figure show the sum and the null as they were three days ago (2015-08-31 7:00:00 Z), while the solid lines show the sum and the null after the filter was inserted.

Details and review

Since at least June (probably longer), we've had a broadband excess noise between the sum and null DCPD streams. Stefan et al. identified this as 45.5 MHz oscillator noise a few weeks ago (20182).

In parallel, we switched the 9 MHz generation from an IFR to the OCXO (19648), and we installed Daniel's RFAM driver / active suppression circuit (20392), but the excess noise remained (20403). For a while we suspected that this was 45.5 MHz phase noise (and hence not supressed by the RFAM stabilization), but the shape and magnitude of the oscillator phase noise coupling (20783) were not enough to explain the observed noise in the DCPDs, under the assumption that the OCXO phase noise is flat at high frequencies (20582). For that matter, the shape and magnitude of the oscillator amplitude noise coupling were also not enough to explain the observed noise in the DCPDs, assuming a linear coupling from the RFAM (as sensed by the EOM driver's OOL detector) (20559).

Daniel et al. looked at the 45.5 MHz spectrum directly out of the harmonic generator in CER, and found that most of the noise is actually offset from the 45.5 MHz carrier by 1 MHz or so (20930), which is above the bandwidth of the RFAM suppression circuit. This suggested that the noise we were seeing in the DCPDs could be downconvered from several megahertz into the audio band.

Yesterday there was a flurry of work by Keita, Fil, Rich, et al. to find the source of this excess noise on the 45.5 MHz (21094 et seq.). Eventually we found circumstantial evidence that this excess noise was caused by baseband noise out of the 9.1 MHz OCXO.

Tonight we installed a 9.1 MHz bandpass filter on the OCXO output. This has removed the huge 1 MHz sidebands on the 45.5 MHz signal, and it also seems to have greatly lowered the coherence between DCPD A and DCPD B above a few hundred hertz.

Loose ends

The chain from OCXO to filter to distribution amplifier currently involves some BNC, since we could not find the right combination of threaded connectors to connect the filter to the amplifier. This should be rectified.

Also, it appears that our sum is lower than our null in a few places (400 Hz in particular), which deserves some investigation.

After making a few "OBSERVE.snap" files for a few SDF nodes during the DAY shift, I tried taking the nodes back to their "safe.snap" files, but some of the nodes ended up having differences!  Since we need to have ZERO differences to allow going to OBSERVATION Mode, I did what I could to make the differences as close to a "safe" state as possible.  For the "safe" files which had differences, I looked used whatever .snap file which got us as close to GREEN as possible. 

Here are the Nodes I worked on, the .snap file they are currently running, and a note about differences observed:

    1.    SUS-ITMX:  safe & GOOD!——> but now has nutsinee differences!
    2.    SUS-ITMY:  safe & GOOD!
    3.    SUS-ETMX *:  safe_150902_124725 & (1) Diff:  H1:SUS-ETMX_L2_DAMP_MODE1_GAIN ???, set point 0 & currently 50—>violin 1004.54Hz
    4.    ISI-ITMy:  safe_150902_124924 & GOOD!
    5.    SUS-ETMY:  safe_150902_151039 & GOOD!
    6.    HPIITMY **:  safe_150810_115155 & (1) Diff (H1:HPI-ITMY_OUTF_H2_TRAMP?? , set point 60 & currently 5)—accept
    7.    ISIBS:  safe_150902_151938 & GOOD!
    8.    HPIBS:  safe & GOOD!

* The SUS-ETMx difference was a gain change Nutsinee made.  She returned the gain to 0.

** The HPIITMY difference was a Time Ramp, so I ACCEPTED.

To damp ALL 8 frequencies of the ITMX first harmonics.

MODE1 damps 996.53

MODE7 damps 995.36

MODE8 damps 995.64

MODE9 damps 992.43, 992.79, 994.28, and 994.73

MODE10 damps 996.25

MODE1, 7, 8, 10 MUST stay on if MODE9 is on.

The damp settings have been added to the table.

In this morning, I checked the OMC DCPD electronics chain (for both A and B) by injecting known sine wave analog signal. This was one of those items that Keita suggested me a while ago.

According to the data, I am concluding that our calibration model needs to add another pole at 10-ish kHz for accurately simulating the OMC whitening circuits.

Method

The measurement method is straightforward -- it is a swept sine measurement in a manual way.

I had a function generator by the HAM6 electronics rack which drove a single-ended-to-differential convertor (D1000931, technically speaking this is a coil driver test box). Then the differential signal is sent to the input of the OMC DCPD whitening board (D1002559, S1101603) by some clipping technique. By the way, the actual cable for connecting the OMC DCPDs were unplugged during the measurement. The excitation amplitude was set to 2 Vp-p at the function generator which resulted in 2 Vp-p in both positive and negative paths at the input of the whitening board as expected accroding to the schematic of the coil driver test box.

I then recorded the data in IOP at the full sample rate using dataviewer for 1 sec for a selected excitation frequency (and for some reason, diaggui did not want to run and hence dataviewer this time). Keeping the same excitation amplitude, I manually stepped the freqyency from 8 kHz to 100 Hz. After every step, I saved the time series of the IOP so that I can make a transfer function later. In addition, I had an oscilloscope with me which kept monitoring the excitation ampitude at the input of the whitening board. The scope told me that the excitation ampltude stayed constant at 2.02 Vp-p in each channel throughtout the measurement. The OMC DCPD had

Analysis and result

To get a transfer function from the data that I took in time series, I decided to do a sine-wave fitting for each data chunk to get the amplitude information. I wrote a small matlab script to do it. It can be found at:

aligocalibration/trunk/Runs/ER8/H1/Scripts/OMCDCPDs/Matlab/OMC_DCPD_AnalogChain_TimeSeries.m

The script utilizes fminsearch and spits out the best fit amplitude for each frequency measurement. Additionally, it places uncertainty or error bar by taking the standard deviation of the residual. Note that this is not a standard way to place an error bar since it does not take the number of measurement points into consideration. According to the fit, the residuals were found to be usually a few counts which is much smaller than the amplitude of signals which was about 2000 counts. So it typically places 0.1% uncertainty after all.

The result is shown in the attached pdf. By the way the lower panel in the plot says, "residual", but it should read "(measured)/(model)" instead. It shows the measured transfer function together with the expected model transfer function for comparison. It is very obvious that the measurement suggests that our model is missing some high frequency pole. The model is merely made of the analog AA response which I have already measured and fitted. Adding some random pole, I could see an extra pole at around 10.7 kHz making the fitting much better. In fact, I sort of knew that there seemed to be a high frequency pole by some other measurements which I did not post. We probably need to add this high frequency pole in our calibration model.

J. Kissel, K. Izumi

We've completed another round of the suite of actuation coefficient coefficient measurements today, very similar to what was done on Wednesday (see LHO aLOG 20940) with the same templates. There were some differences between the two days worth of measurements -- we don't expect these to have made a difference, but we've been living 1% accuracy and precision land for a week with no sleep, so we write them down anyways. They are: 
- We managed to get all of the full IFO transfer function measurements within the same lock stretch, unlike Wednesday. 
- We did Full IFO config measurements, ALS DIFF measurements, then Free-Swinging MICH (FSM) measurements, as opposed to Wednesday when we did DIFF, then Full, then FSM.
- Because we got distracted with full-frequency range DARM OLG and PCAL to DARM TFs, and there were some problems with DIFF saturating, there were about ~4 hours between when the ETMX TF was taken in full lock and when it was taken in ALS DIFF.
- On Wednesday, we ran ALS DIFF with ALS COMM OFF. Today we ran ALS DIFF with ALS COMM ON.
- We missed a MICH OLG TF for the FSM. We may try to get away with checking if the power and PD normalization levels are the same -- if they are we may just use Wednesday's data. Otherwise it means we have to scrap all of today's FSM data.

A "When will you have a number?" update: we are heavy into analyzing both of the data sets (ALS DIFF is done with the help of LHO aLOG 21001, tomorrow will be PCAL and FSM). A goal is to have a comparison between methods by Sunday.
For a sneak peak on the analysis scripts for ALS DIFF (in case LLO wants to use them), check out
/ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/ER8/H1/Scripts/ALSDiff
analyze_alsdiff_data_20150826.m
analyze_alsdiff_data_20150828.m


#NoSleepTilO1

The DTT files live here:
(2) /ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/ER8/H1/Measurements/FullIFOActuatorTFs/2015-08-28/
     2015-08-28_H1SUSETMY_PCALYtoDARM_FullLock.xml

(5) /ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/ER8/H1/Measurements/ALSDIFF/2015-08-28/
     2015-08-28_ALSDiff_ETMX_L3_HVHN.xml

(6) /ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/ER8/H1/Measurements/FreeSwingMich/2015-08-28/
     2015-08-26_H1MICH_freeswingingdata.xml

(7) Does not Exist

(8) /ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/ER8/H1/Measurements/FreeSwingMich/2015-08-28/
     2015-08-28_H1SUSITMX_L2_State2_MICH.xml

(9) /ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/ER8/H1/Measurements/FreeSwingMich/2015-08-28/
     2015-08-28_H1SUSITMX_L2_State2_XARM.xml

(10) /ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/ER8/H1/Measurements/FreeSwingMich/2015-08-28/
     2015-08-28_H1SUSETMX_L3_HVHN_XARM.xml

(X) /ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/ER8/H1/Measurements/FullIFOActuatorTFs/2015-08-28/
     2015-08-28_H1SUSETMY_L3toDARM_LVLN_LPON_FullLock.xml

(Y) /ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/ER8/H1/Measurements/FullIFOActuatorTFs/2015-08-28/
     2015-08-28_H1SUSETMY_L1toDARM_FullLock.xml
     2015-08-28_H1SUSETMY_L2toDARM_FullLock.xml

(Z) /ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/ER8/H1/Measurements/FullIFOActuatorTFs/2015-08-28/
     2015-08-28_H1SUSETMX_toDARM_FullLock.xml

Wish us luck on tomorrow's measurement suite; hopefully it'll be the last time for while!