As discussed at today's run meeting on Teamspeak on the JRPC channel:

The LDAS (DCS) stream of 4 s hoft generation using gstlal_compute_strain started writing to LDAS disks at 1125451520  == Sep 05 2015 01:25:03 UTC.

There already exist two redundant DMT streams of 4 s hoft writing to LDAS and DMT (GDS) disks. These are now vetted for diffs in the STRAIN and ODC channels.

Aggregation of hoft into 4096 s frame files for offline analysis is now configured (via the diskcache) to use the DMT hoft if the STRAIN and ODC channels agree in the two DMT streams; otherwise it will use the LDAS stream. (This can be easily switched back to using only the two DMT streams as it has been using prior to the time given in this alog, if problems arise).

C. Cahillane

I have been busy trying to calculate kappa_tst, kappa_pu, kappa_C,and f_c from ER8 data so I might begin finding the uncertainty associated with these numbers.  The uncertainty in all of these calibration coefficients depend heavily on our calibration line measurements (See T1500377 for the calculation of these coefficients from model params and calibration lines).  I was curious to see if uncertainty in our calibration line measurements will be a significant source of uncertainty in the total budget, or if I can ignore it for now.

I took 100 GPS times starting at 1125316818, each ten seconds apart, and computed the 10 second FFT of DARM_ERR, X_TST, X_CTRL, and X_PCAL.  Then, I found their values at the calibration line frequencies at H1:
f_tst  = 35.9 Hz
f_pcal = 36.7 Hz
f_ctrl = 37.3 Hz
f_pcal2= 331.9 Hz

and took the following ratios:
   X_TST(f_tst) / DARM_ERR(f_tst)
 X_PCAL(f_pcal) / DARM_ERR(f_pcal)
 X_CTRL(f_ctrl) / DARM_ERR(f_ctrl)
X_PCAL(f_pcal2) / DARM_ERR(f_pcal2)

and plotted their amplitudes below.  

Percent uncertainties:
   X_TST(f_tst) / DARM_ERR(f_tst)   = 0.98%
 X_PCAL(f_pcal) / DARM_ERR(f_pcal)  = 0.95%
 X_CTRL(f_ctrl) / DARM_ERR(f_ctrl)  = 0.84%
X_PCAL(f_pcal2) / DARM_ERR(f_pcal2) = 1.05%

Since I am just starting to compute the uncertainty expressions for the calibration coefficients in Mathematica, this study informed me that there is ~1% uncertainty in all of our calibration line amplitudes, which is significant enough to be included in all uncertainty calculations.

Two notes: 
(1) I am assuming for now there is no quantization noise in our digital signals DARM_ERR, DARM_CTRL, X_TST, X_CTRL, and X_PCAL.  This is almost certainty a secondary consideration in the total budget for now.
(2) The method I used for dewhitening X_PCAL is known to be incorrect, so their absolute values should not be taken too seriously.  But since all I cared about here is the statistical uncertainty, any systematic errors are a simple gain that is common to all data points, so this result is still valid.

While Jeff and Darkhan have been trying to get the actuactor coefficients right for calibration, I worked on an orthogonal task which is to check out the latest optical gain of DARM.

Summary points are:

• They don't look crazy.
• However the magnitude at low frequencies seems too low. This is something we have been consistently suffereing from.

The plots below show the measured optical gain measured by Pcal Y with the loop suppression taken out by measuring the DARM supression within the same lock stretch. 

I used the data from Aug 28 and 29th (alog 21190 and alog 21023 respectively). The parameters were estimated by the fitting function of LISO. I have limited the frequency range of the fitting to be avove 30 Hz because the measurement does not seem to obey physics. I will metion this in the next paragraph. The cavity pole was at around 330 Hz which claims a bit lower frequency than what Evan indendently estimated from the nominal Pcal lines (alog 21210). Not sure why at this point.

One thing we have to pay attentin is a peculiar behavior of the magnitude at low frequencies -- they tend to respond lesser by 20-30 % at most while the phase does not show any evidence of extra poles or zeros. I think that this behavior has been consistently seen since ER7. For example, several DARM open loops from ER7 show very similar behavior (see open loop plots from alog 18769). Also, a recent DARM open loop measurement (see the plot from alog 20819). Keita suggested makeing another DARM open loop measurement with a smaller amplitude, for example by a factor of two at a cost of longer integation time in order to detemine whethre if this is associated with some kind of undesired nonlinearity, saturation or some sort.

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

Summary:  Able to get a few hours of Observation time during the shift.  Also had a few hours of PEM Injections by Robert.  Coordinated a bit with LLO with regards to when to drop out of Observation as well.  All of this is pointing us toward a goal of having long double-coincidence duty cycles for the next week so we can get an idea of the state of our machines going into O1.

Robert plans to continue with injections into the evening so he can have a lighter day tomorrow.

Handed off a nice H1 (~70Mpc) to Nutsinee with quiet seismic and slight winds.

Poll of Control Room Work:  PCal/OMC model work, Calibration Analysis, PEM Injection analysis, Ops Script work.

Support:  Had Commissioners around, but not needed since H1 was locked the whole time (since 16UTC / 10pm PST)

Day's Activities

• Apollo due to come in this morning to deliver a compressor to Staging
• 15:33 Airflows being lowered this morning from 15,000cfm to the standard 11,000cfm (Bubba)
• 17:48 Pepsi truck arrived
• 19:20 svn up ran on CAL_INJ_CONTROL.adl to correct bug on screen (Duncan)
• 20:10 PEM INJECTIONS begin (Switched to "Commissioning"!)
• 21:19 -21:20:  Went to Observation briefly to see if hitting the "Reset WD Only" button for HEPI (to clear HEPI saturations) drops us out of Observation:  IT DOES NOT.
• 21:59:  Back to Observation (PEM Lunch Break)

ECR: https://dcc.ligo.org/LIGO-E1500373

userapps/cal/common/models/PCAL_MASTER.mdl

1. Changed it such that IN1 instead of OUT duotone channels are recorded on frame so there's no way timing information is compromised by user error.
2. FPGA duotone IN1 (not output) is in science frames at 16k. There are two end stations, so two new 16k channel in science frame per IFO.

userapps/omc/h1/models/omc.mdl

1. FPGA duotone (ADC0 CH31) is sent to OMC common block.

userapps/omc/common/models/omc.mdl

1. FPGA duotone signal is sent to cdsFilt in the omc block, and IN1 is recorded as OMC-FPGA_DTONE_IN1_DQ in science frame at 16k. The name was chosen so that the pcal and omc signals are consistent.

h1calex, h1caley and h1omc were all successfully built but not installed. These will be installed on next Tuesday.

The seized up compressor on the supplemental chiller unit for the staging building, commonly described as the AAON Unit has been replaced, charged, and is now running at 100%. 

Chris S. Joe D. Both 70%

This week the guys have cleaned the original caulking and installed metal strips on 200 meters of tube enclosure on the top side. 

They have also cleaned the caulking on an additional 60 meters of enclosure.

I had stepped out the control room for ~15min, and when I came back the first thing I noticed was a YELLOW "OK" on the GWIstat screen.  I asked around the Control Room to see if anyone knew why we were out of Science Mode (granted I should have announced my exit), but no one seemed to notice the drop from OBSERVATION. 

I took us back to Observation Mode immediately since there was no reason given for having us out.  I looked in the Verbal Alarm terminal, and did not see a note of the Intent Bit being changed.  (So, I've talked to TJ about getting this in the Verbal Alarm script.  And to also have time stamps attached to the Intention Bit alarms so we'll know when these come up.

Keita admitted he was the culprit; he opened a DTT session [which has an excitation], and then started it.  (We tested this, while in Observation mode, and we were able to open this DTT session, which had excitation selected, and this did not drop us out.  Robert & I thought that just opening a session would drop us out.  He mentioned that maybe this is the case with AWG.  We should test whether it can drop us out.).  So this is when we were out:

16:19-16:29UTC Out of OBSERVATION

Addendum:

Prior to PEM Injections, Robert and I wanted to check if AWG does in fact have a different effect with regards to staying in Observation Mode with Excitation channels.  Robert opened an AWG session (no drop), but once he merely selected an excitation in AWG, we were dropped out of Observation Mode.  This is even WITHOUT hitting the "Set/Run" button!

When you do this, the DIAG_EXC guardian Node gets an orange box and has the message:  EXC:  [system] excitation!

We were dropped out of Observation at:  20:10UTC due to this excitation being selected (and NOT run) (this was different from what DTT did).

The noise below 30 Hz looks a bit non stationary, see the zoom in of the attached spectrogram. 

The behavior of the noise reminds me very much of scattered light, but I'm not 100% positive right now.

For some reason Evan is reluctant to make a new post about it: LHO alog 21210, comment 5 (H1NB_2015-08-27_123000.pdf)

Due to a crazy big offset of -0.5 in Y_TR_B_PIT (for SOFT modes sensing), Y IR QPDB is almost always railing a bit in 24W operation, and Y IR QPDA is not too far.

Next time IFO drops out of lock, somebody needs to lower the whitening gain by 3dB and set a new dark offset for each quadrant.

The landscapers will be out this weekend-Saturday and possibly Sunday for weed control in front of the OSB, Staging Building, and the LSB.

Patrick handed off an H1 which has been at Nominal Low Noise since about 5:30utc (10:30pmPST) with a range hovering around 70Mpc.  There was a noticeable step down in range (~60Mpc) at 12:04UTC for about 30-60min (Patrick notes several ETMy saturations around 12:10UTC & Ed notes there were earthquakes aroudn 12:15UTC).

Injection around 11:15UTC?

Looks like we have been in Observation Mode since 6:00UTC, but GWIstat says we've only been in this state since about 11:15UTC (this isn't Peter's Burst from last night....maybe a Transient Injection?  Or some other injection?  Is there a schedule for these things??).

Today's Outlook:  PEM Injections for good chunk of day

Will stay in Observation a little, but Robert says he said would like to start PEM Injections within an hour or so (~16:45UTC?), and will be PEM Injecting for a good chunk of the day so he does not have to do much on Saturday.  Have just talked with Lisa at LLO and they will be interested when we go out of Observation, so they could also go out and do some much-need commissioning.

Seismically, we look fairly quiet with microseism noticeably trending down by 0.1um/s over the last 24hrs.  Winds are also quiet.

ER8 Day 18, no restarts reported.

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.

This entry is meant to survey the sensing noises of the OMC DCPDs before the EOM driver swap. However, other than the 45 MHz RFAM coupling, we have no reason to expect the couplings to change dramatically after the swap.

The DCPD sum and null data (and ISS intensity noise data) were collected from an undisturbed lock stretch on 2015-07-31.

Noise terms as follows:

• Shot noise
  • For 20.0 mA dc on the DCPD sum, we expect a shot noise of 8.0×10⁻⁸ mA/Hz^1/2.
• Dark noise
  • Dan and I measured this a few months ago. In full lock we use one stage of whitening, which amounts to a dark noise of 1.5×10⁻⁸ mA/Hz^1/2 or so above 100 Hz. We have at times experimented with two stages of whitening, but it requires some vigilance regarding the violin modes.
• Intensity noise
  • Coupling was measured à la Kiwamu by leaving the outer loop off and driving the inner-loop excitation point. For the noise estimation, I used the outer loop out-of-loop sensor. Since Sudarshan et al. previously found that this is artificially high, this estimation is an upper limit (though probably no more than a factor of 3, given Sudarshan's plot).
• Frequency noise [CARM sensing noise only]
  • Previously (i.e., when we locked CARM using the in-air REFL sensor), I estimated the coupling by looking at the TF in-vac REFL to DARM, and for the frequency noise estimation I used the noise of in-vac REFL as an upper limit for the frequency noise. Since we now lock with in-vac REFL, which has more light on it than in-air REFL does, I do not expect that the noise of in-air REFL is a particularly useful upper limit for the frequency noise.
  • Therefore, I have tried to instead estimate the sensing noise in CARM (from in-vac REFL, the summing-node board, the common-mode board, and PDH shot noise) in V/Hz^1/2 and propagate it (using the Izumi/Sigg expression) into a frequency noise in Hz/Hz^1/2. For the CARM optical TF I use 12.7 W/Hz at dc, with a pole at 0.48 Hz.
  • Then I have injected noise into CARM and looked at the TF from the residual of the excitation into DARM. This is the coupling TF needed to propagate the estimated sensing noise to DARM, assuming the CARM gain is high (this isn't quite true at high frequencies; the ugf is 17 kHz or so, and the gain does not exceed 20 dB until 3 kHz).
  • Since this includes sensing noise only (and not, for example, FSS noise), I have labeled it as a lower limit. In fact, the coherence between REFL 9Q and the DCPD sum is about 0.04 around 7 kHz, perhaps suggesting a frequency noise contribution of 2×10⁻⁸ mA/Hz^1/2 or so. More investigation required.
• Oscillator phase noise [not included here]
  • Stefan and I measured the coupling of the 9 MHz RF source into DARM, and using the expected performance of the OCXO estimated the noise in DARM should be 2.8×10⁻¹⁰ mA/Hz^1/2 at 1 kHz. This is quite low (and not shown on the plot).
  • This number should be replaced with Alexa's and Daniel's measurements of the phase noise. An even more satisfying number could be made by trying to measure the 9 MHz and 45 MHz phase noises in situ, closer to the EOM (e.g., at the output of the distribution system on the ISC rack).
• Oscillator amplitude noise [45 MHz only]
  • In this case we know that the 45 MHz RFAM is the dominant contributor (other than shot noise) to the DARM noise above a few hundred hertz. Here I use Stefan's estimate of the RFAM-induced photocurrent (1.8×10⁻⁸ mA/Hz^1/2), which (as he notes) is not enough to explain the excess between sum and null.
  • However, based on tonight's measurements using the new EOM driver readback, it seems that 45 MHz RFAM is enough to explain the excess. Perhaps Stefan's measurement is an underestimate, since it was done at the output of the distribution system and did not include the final rf amplifier before the EOM.
  • As for 9 MHz RFAM, Stefan and I made an estimate of the coupling from the 9 MHz source into DARM. Based on the specified performance of the OCXO, the expected noise in DARM is quite small. However, it would be better to look somewhere further downstream, as Stefan did (although I think he said the measurement was not that clean). This noise is not estimated in the plot.

The downward slope in the null at high frequencies is almost certainly some imperfect inversion of the AA filter, the uncompensated premap poles, or the downsampling filter.