Adam, Alex U., Chris, Mike L., Eric

With a bit of effort we have successfully scheduled and injected a coherent CBC hardware injection. We have scheduled three coherent hardware injections for later tonight at 1127179817, 1127181617, and 1127183417. Those injections are the last of the night.

Here I will summarize what has happened.

All attempted/successful injections used the H1L1 coherent waveform from aLog 21838.

The are a couple differences between the sites. LLO uses monit to run tinj, whereas LHO does not. LLO uses the new hardware injection SVN, whereas LHO uses the DAC SVN still. The directory to run tinj at both sites is /home/hinj/Details/tinj.

Note that the times below are not the end time of the inspiral but rather this is the start time of injecting the ASCII file. The end time of the inspiral is listed on the gracedb page for the hardware injection and is ~6.986 seconds after the injection was scheduled.

Adam and Chris set out to do a H1L1 coherent hardware injection. See 21901.

We initially tried to scheduled a hardware injection at 1127175848. However the first step, i.e. to upload a GraceDB entry did not work. Chris was given a permissions warning and denied to upload to the CBC group.

The second attempt was scheduled for 1127168901. This was unsuccessful.
  * A gracedb page was generated for this hardware injection H1 and L1. No explanation for why Chris had permission this time.
  * At LLO the wrong schedule file was updated so there was no injection at LLO.
  * At LHO tinj had stopped before the time of the injection so there was no injection at LHO.

We then stopped the tests and went to the hardware injection telecon.

On the hardware injection telecon we had a group debug session.

We had to get tinj running at LHO again. To do this we did:
cd /home/hinj/Details/tinj
./run_tinj &

After running this command tinj was running again with process ID 11229. We tailed the log file (/home/hinj/Details/tinj/tinj.log) and saw that it was updating again.


Even though tinj is running in the background it still prints output to stdout. So Chris logged out of h1hwinj1 and logged back into h1hwnj1. tinj was still running.

The thought for the tinj failing was that when Chris edited the schedule file (/home/hinj/Details/tinj/schedule) the MCR environment that was used for testing monit received an error. Eric had checked the run_tinj log (/home/hinj/Details/tinj/run_tinj.log); note run_tinj is a wrapper to run tinj in monit. The log said:
ERROR: Unexpected error in tinj.
GPS=1127167412

So we did another test with tinj. The tests were logged in 21911.

The third attempt was scheduled for 1127172657. This injection was unsuccessful.
  * tinj stopped. Debugging by Eric showed that we need to change the filename of the waveform single-column ASCII files. Inspiral waveform files need have _H1 or _L1 at the end. So we renamed coherenttest1_*.out to coherenttest1_*_H1.out and coherenttest1_*_H1.out.
  * We also had to include a _ at the end of the filename in the schedule. So the line should have read "1127172657 1 0.5 coherenttest1_1126257410".

We made these corrections. But LLO went out of lock.

The fourth attempt was scheduled for 1127173421 and it was H1 only. It was successful.
  * The waveform was injected and observed going through the hardware injection filterbanks.
  * It had a scale factor of 0.5 applied.
  * A gracedb page was generated for this hardware injection H1 and L1.

Now that we had tinj running and a successful injection at LHO we waited for LLO to come back.

The fifth attempt was scheduled for 1127175848 and was a H1L1 coherent injection into both detectors. It was successful.
  * This was the first scheduled coherent CBC injection in aLIGO.
  * It was observed in both detectors. There was a CWB trigger for this event in gracedb and it was flagged with the INJ tag.
  * A gracedb page was generated for this hardware injection H1 and L1.

We then scheduled three more injections for the night at 1127179817, 1127181617, and 1127183417.

The schedule file now reads:
1127168901 1 0.5 coherenttest1_1126257410
1127172657 1 0.5 coherenttest1_1126257410
1127173421 1 0.5 coherenttest1_1126257410_
1127175848 1 1.0 coherenttest1_1126257410_
1127179817 1 1.0 coherenttest1_1126257410_
1127181617 1 1.0 coherenttest1_1126257410_
1127183417 1 1.0 coherenttest1_1126257410_

More plots and followup to come later.

An action item is to update the hardware injection documentation with the correct filename format and the commands to restart tinj on the command line.

And I will add as another note, to get to the monit web browser interface. On a controls machine you can type for the URL "http://h1hwinj1/" and it will take you to the monit web browser interface. At the moment I see no way to manage tinj this way but once we switch to monit this will be a good thing to remember.

Chris Biwer is running tests of the hardware injection pipeline. When the injection went in, both the VerbalAlarms and GraceDB saw the injection properly. It wasn't clear from the verbal alarm that this was different from a GRB, but Grace made it clear pretty quickly that this was an injection.

This is a repetition of Valera's projection for how we expect the DARM spectrum to behave as we increase the laser power. The current (23 W) quantum noise estimate from GWINC was subtracted from the DARM spectrum and replaced with a set of higher-power quantum noise curves. For reference, I've also plotted the null stream and the sum/null residual. This is from 2015-09-12 06:30:00 Z.

This projection assumes, of course, that nothing else about the ISC changes. Also, I suspect that the range estimates are slightly higher than what we're used to because these spectra are median-averaged. Dan has already showed that our bucket noise is not Rayleigh distributed, so we expect the median spectral estimate to be lower than the mean estimate at these frequencies. I briefly compared a mean-estimated spectrum (from the frontend calibrated DARM channel, and from the same time) and got an inpsiral range of 75 Mpc for the 23 W spectrum.

Anyway, the message is that with our current correlated noises, we only win about 30 % more range with a factor of 5 more laser power.

We have tinj running again at LHO. We are going to test scheduling injections again.

I think it's possible that we're closer to the Newtonian gravitational noise limit than I had thought.  This is on the list of "things we knew were coming, but are perhaps here sooner than I thought they would be". 

The punch line is that we may be limited by Newtonian noise between 16-20 Hz.  Not a wide band, but reasonably consistent with the expectations from papers such as P1200017.

In the attached plot, the blue trace is the calibrated DARM spectrum (CAL-DELTAL_EXTERNAL_DQ) that we show on the wall, taken yesterday.  The green trace is my estimate of the Newtonian noise. 

For the Newtonian noise, I have taken the Z-axis STS-2 seismometer data from the sensors on the ground near each test mass.  (There is one seismometer at each end station, and one in the vertex near the ITMs - I use the same seismometer data for each ITM). The seismometers are in velocity units (I believe Jim said it's nm/s), so I pwelch to get velocity/rtHz, then apply the calibration zpk([],0, 1.6e-10) to get to meters/rtHz.  I then translate to acceleration due to Newtonian noise using eq 1 from T1100237.  Finaly, I add the 4 acceleration contributions (one from each test mass) incoherently and get to displacement by dividing the spectrum by (2*pi*f)^2. 

The Newtonian noise is touching the DARM spectrum between about 16 - 20 Hz. We're within about an order of magnitude in the band 10 - 30 Hz.  Evan will shortly re-run his noise budget code using this "measured" Newtonian noise to see if it helps explain some of the discrepancy between the measured and expected DARM spectra (this spectra is higher than the GWINC curve that is currently used in the noise budget). 

Notably, this estimate of seismically-induced Newtonian noise is somewhat larger than what we've quoted in P1200017 and T1100237.  If I use only the ETMY spectrum as an estimate for all 4 test masses, I get an answer more consistent with our past estimates.  However, using the actual seismic signals from each test mass, I'm getting this slightly higher estimate. 

The script to generate this plot is attached, as is the exported-from-DTT text file of the calibrated DARM spectrum.

Durring yesterday's maintence window I made some excitations on both transmons to investigate the noise peaks around 75-85 Hz.  The main conculsions are that the coupling from TMS X L drive to DARM is bilinear while the coupling from TMSY is linear, and it seems likely that TMSX motion accounts for some significant part of the unexplained noise in the H1 noise budget (21162) even at frequencies where there is no coherence between DARM and the X QPDs. 

In the first attached screen shot you can see the DARM spectra durring some of my excitations in the upper panel and TMS QPD spectra in the lower panel.  In the QPD spectra, you can see that the X end QPDs have some excess noise compared to Y.  These spectra were from a time when I had a TMSX longitudnal injection at 75 Hz (this is the same time as the yellow DARM trace).  There is a narrow line in the X QPD spectra, but in the DARM spectrum the line that appears is about 1 Hz wide, indicating there is some bilinear coupling.  The excitation either did not show up or was very small in the QPD sums.

I also made a few injections into TMSY longitudnal which produced only narrow lines in DARM, both X and Y injections are shown at 100 Hz for comparison.  

We can attempt to make projections of this noise into DARM using the ratio or the injection line peaks or the rms of the injection peaks to estimte the coupling.  I drove longitudnally and the only good witness sensor we have is an angular sensor.  If the coupling mechanism is something like scatter off the QPDs that goes directly back into the arm, DARM would be mostly sensitive to the longitudnal TMS motion and if the QPDs are only seeing the unintentional length to angle coupling the projection from the normal level of the QPD spectra to the normal level of DARM could be an overestimate. This projection does show that this would be within a factor of 10 of DARM from about 100 Hz down to at least 75 Hz.

Perhaps when we get a chance we can try misaligning TMSX to see if we can reduce the noise in DARM this way. 

J. Kissel

I've taken new DARM open loop gain and PCALY to DARM transfer functions to validate the current calibration. During the PCALY to DARM transfer function, I take the transfer function from PCALY's RX PD (calibrated into [m] of ETMY motion) and the CAL-CS front-end's DELTAL_EXTERNAL (calibrated into DARM [m], which -- since we're driving ETMY -- is identical to [m] of ETMY motion). These two different methods agree to within 4% and 3 [deg] over the 15 [Hz] to 1.2 [kHz] band. The calibration discrepancy expands to a whopping 9% and 4 [deg] if we look a frequencies between 5 and 15 [Hz] ;-).

I think we're in great shape, boys and girls.

Details
--------------
- CAL-CS does not correct for any slow time depedence (optical gain, test mass actuation strength, etc), so any agreement you see with the current interferometer is agreement with the reference model taken on Sep 10th 2015 (LHO aLOG 21385).

- In the previous measurement, Kiwamu had to fudge the phase by ~90 [us] to get the phase to agree. Now that we've updated the cycle delay between sensing and actuation to 7 [16 kHz clock cycles] to better approximate the high-frequency frequency response of AA, AI, and the OMC DCPD signal chain, we no longer have to fudge the phase -- AND the phase between the two metrics agree. NICE.

- I've made sure to turn OFF calibration lines *during both of these measurements, but there should be ample data just before and just after with calibration lines ON, such that we can compare our results against theirs to help refine our estimates of systematic error.

- The measurements live in
/ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/O1/H1/Measurements/DARMOLGTFs/2015-09-23_H1_DARM_OLGTF_7to1200Hz.xml
/ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/O1/H1/Measurements/PCAL$/2015-09-23_PCALY2DARMTF_7to1200Hz.xml
and have been committed to the CalSVN. We'll process these results shortly, and perform a similar analysis as Darkhan has done in yesterday's aLOG 21827.