This change now shows in the ASCIMC SDF Table.

This is my own reckoning of the loss measurements we've performed after the ETMs were cleaned in December. Note that these visibility measurements do not independently measure losses from the ITMs or the ETMs; they just give the total arm loss from scatter and absorption.

If these measurements are not satisfactory, we could always repeat them.

We could also repeat the ringdown measurements, but we would need to be more careful when collecting the data. Last time, the incident IR power on the arm fluctuated from lock to lock, which made the uncertainties in the inferred losses much too big for the measurements to be usable.

X arm

Y arm

The IFO was down, so we hit the load coeff on MC2 during it's walk back up to LSC_FF lock.  The IFO didn't waiver so all seems fine.

First, some details, the injection is actually a sine-Gaussian with parameters:

SineGaussian t0 = 1116964989.435322284 q = 28.4183770634 f0 = 1134.57994534

The t0 can be safely ignored since this injection would have no counterpart in L1, but it should be noted that this injection *does* have all relevant antenna patterns and polarization factors applied to it (e.g. it is made to look like a "real" GW signal).

I attach the time and frequency domain plots of the waveform --- however they are relative to an O1 type spectrum and so may not be indicative of the actual performance of the instrument at this period of time. Given the most recent spectra and frequency content of the injection, this could be weaker up to a factor of ~2-3. The characteristic SNRs I calculated using the O1 type spectrum:

Waveform SineGaussian at 1116964989.435 has SNR in H1 of 7.673043
Waveform SineGaussian at 1116964989.435 has SNR in L1 of 20.470634
Network SNR for SineGaussian at 1116964989.435 is 21.861438

So, it's possible that this injection had an SNR as low as ~2, not accounting for variance from the noise.

The excitation channel (H1:CAL-INJ_TRANSIENT_EXCMON, trended) does show a non-zero value, and the "count" value is consistent with the amplitude of the strain, another monitor (H1:CAL-INJ_HARDWARE_OUT_DQ, at a higher sample rate) also shows the full injection, though it is not calibrated. So, the injection was successfully scheduled and looks to have been made. I also did an omega scan of the latter channel, and the signal is at the correct frequency (but has, notably, a very long duration).

I did a little poking around to see if this showed up in h(t) (using H1:GDS-CALIB_STRAIN). Unfortunately, it is not visible in the spectrogram of H1:GDS-CALIB_STRAIN (attached). It may be some peculiarity of the scheduling, but it's interesting to note that the non-zero excitation occurs about a second after the GPS time that Eric quotes. More interestingly, this does not seem to have fired off the proper bits in the state vector. H1:GDS-CALIB_STATE_VECTOR reports the value 456 for this period, which corresponds to the data being okay, gamma being okay, but no injection taking place. it also appears to mean that no calibration was taking place (bits 3 and 4 are off). I'm guessing I'm just misinterpreting the meaning of this.

I'd recommend, for future testing, a scale factor of 3 or 4, to make it *clearly* visible and give us a point of reference. We should also close the loop with the ODC / calibration folks to see if something was missed.

I can see that burst injections have been occurring on schedule, generally.  The schedule file (which you currently have to log into h1hwinj1 to view) reads, in part:
...
1117411713 1 1 burst_test_
1117419952 1 1 burst_test_
1117427152 1 1 burst_test_
...
Compare that to the bit transitions in CAL-INJ_ODC:
pshawhan@> ./FrBitmaskTransitions -c H1:CAL-INJ_ODC_CHANNEL_OUT_DQ /archive/frames/ER7/raw/H1/H-H1_R-11174/*.gwf -m fffffff
1117400000.000000  0x00003f9e  Data starts
1117400027.625000  0x00003fde  6 on
1117400028.621093  0x00003fff  0 on, 5 on
1117406895.000000  0x00003e7f  7 off, 8 off
1117411714.394531  0x0000347f  9 off, 11 off
1117411714.480468  0x00003e7f  9 on, 11 on
1117419953.394531  0x0000347f  9 off, 11 off
1117419953.480468  0x00003e7f  9 on, 11 on
1117427153.394531  0x0000347f  9 off, 11 off
1117427153.480468  0x00003e7f  9 on, 11 on
...
Bits 9 and 11 go ON when a burst injection begins, and off when it ends. The offset of start time is because the waveform file initially contains zeroes. To be specific, the first 22507 samples in the waveform file (=1.37372 sec) are all exactly zero; then the next several samples are vanishingly small, e.g. 1e-74 .  At t=1.39453 sec = 22848 samples into the waveform file, the strain amplitude of the waveform is about 1e-42.  At the end time of the injection (according to the bitmask transition), the strain amplitude has dropped to about 1e-53, but I believe the filtering extends the waveform some.  To give an idea of how much, the end time is about 130 samples, or ~8 msec, after the strain amplitude drops below 1e-42.

Earlier in the record, bit 6 went on to indicate that the transient filter gain was OK, bit 5 went on to indicate that the transient filter state was OK, and bit 0 went on at the same time to indicate a good summary.  Somewhat later, bit 8 went off when CW injections began, and bit 7 went off at the same time to indicate the presence of any hardware injection signal.

Note that tinj seems to have been stopped (or died) at about GPS 1117456410, according to the tinj.log file, and that's consistent with a lack of bit transitions in CAL-INJ_ODC after that time.

Checking the other bitmask channels, there's a curious pattern in how the hardware injection bits from CAL-INJ_ODC are getting summarized in ODC-MASTER:
pshawhan@> ./FrBitmaskTransitions -c H1:ODC-MASTER_CHANNEL_OUT_DQ -m 7000000 /archive/frames/ER7/raw/H1/H-H1_R-11174/H-H1_R-11174[12345]*.gwf
1117410048.000000  0x07000000  Data starts
1117411714.391540  0x05000000  25 off
1117411714.391723  0x07000000  25 on
1117411714.391845  0x05000000  25 off
1117411714.475463  0x07000000  25 on
1117419953.391540  0x05000000  25 off
1117419953.391723  0x07000000  25 on
1117419953.391845  0x05000000  25 off
1117419953.475463  0x07000000  25 on
1117427153.391540  0x05000000  25 off
1117427153.391723  0x07000000  25 on
1117427153.391845  0x05000000  25 off
1117427153.475463  0x07000000  25 on
...
The same pattern continues for all 7 of the injections.  We can see that there's a brief interval (0.000183 s = 3 samples at 16384 Hz) which is marked as a burst injection, then "no injection" for 2 samples, then back on for 0.083618 s = 1370 samples.  Knowing how the sine-Gaussian ramps up from vanishingly small amplitude, I think this is the real in the sense that the first whisper of a nonzero cycle returns to effectively zero for a couple of samples before it grows enough to be consistently "on". It is also interesting to see that the interval ends in ODC-MASTER slightly (5.0 ms) earlier than it does in CAL-INJ_ODC.  I suspect that this is OK and the model really runs at 16384 Hz, but CAL-INJ_ODC is a down-sampled record of the real bit activity.

I also confirmed that the injection bit got carried over to CALIB-STATE_VECTOR:
pshawhan@> ./FrBitmaskTransitions -c H1:GDS-CALIB_STATE_VECTOR -m 1ff /archive/frames/ER7/hoft/H1/H-H1_HOFT_C00-11174/H-H1_HOFT_C00-11174[012]*.gwf 
1117401088.000000  0x000001c8  Data starts
1117408113.375000  0x000001cc  2 on
1117408119.375000  0x000001dd  0 on, 4 on
1117408143.750000  0x000001df  1 on
1117408494.812500  0x000001dd  1 off
1117408494.937500  0x000001c8  0 off, 2 off, 4 off
1117411714.375000  0x00000148  7 off
1117411714.500000  0x000001c8  7 on
1117419953.375000  0x00000148  7 off
1117419953.500000  0x000001c8  7 on
1117420916.625000  0x000001cc  2 on
1117420922.625000  0x000001dd  0 on, 4 on
1117421174.000000  0x000001df  1 on
1117424707.062500  0x000001dd  1 off
1117424954.437500  0x000001c8  0 off, 2 off, 4 off
1117426693.000000  0x000001cc  2 on
1117426699.000000  0x000001dd  0 on, 4 on
1117426833.625000  0x000001df  1 on
1117427153.375000  0x0000015f  7 off
1117427153.500000  0x000001df  7 on
...
Bit 7 indicates burst injections.  It comes on for 2 16-Hz samples at the appropriate times.

As of 7:00am PDT on Friday, June 5, there have been 13 burst hardware injections at LHO over the last two days.  All of these are represented by segments (each 1 second long) in the DQ segment database, and can be retrieved using a command like:
pshawhan@> ligolw_segment_query_dqsegdb --segment-url https://dqsegdb5.phy.syr.edu --query-segments --include-segments H1:ODC-INJECTION_BURST --gps-start-time 1117300000 --gps-end-time 'lalapps_tconvert now' | ligolw_print -t segment -c start_time -c end_time -d ' '
These time intervals also agree with the bits in the H1:GDS-CALIB_STATE_VECTOR channel in the H1_HOFT_C00 frame data on the Caltech cluster, except that there is a gap in the h(t) frame data (due to filters being updated and the h(t) process being restarted, as noted in an email from Maddie).

Similar DB queries show no H1 CBC injection segments yet, but H1 CW injections are ongoing:
pshawhan@> ligolw_segment_query_dqsegdb --segment-url https://dqsegdb5.phy.syr.edu --query-segments --include-segments H1:ODC-INJECTION_CW --gps-start-time 1117400000 --gps-end-time 'lalapps_tconvert now' | ligolw_print -t segment -c start_time -c end_time -d ' '
1117406895 1117552800
By the way, by repeating that query I observed that the CW segment span was extended by 304 seconds about 130 segments after the segment ended.  Therefore, the latency of obtaining this information from the segment database ranges from 130 to 434 seconds, depending on when you query it.  (At least under current conditions.)

I also did similar checks at LLO, which revealed a bug in tinj -- see https://alog.ligo-la.caltech.edu/aLOG/index.php?callRep=18517 .