Displaying report 1-1 of 1.
Reports until 03:35, Saturday 30 May 2015
H1 INJ (INJ)
eric.thrane@LIGO.ORG - posted 03:35, Saturday 30 May 2015 - last comment - 12:49, Monday 01 June 2015(18713)
transient injection tests with svn-controlled tinj
Kiwamu, Jeff, Dan, Cheryl, Eric

We successfully tested the transient injection code tinj at LHO for the first time.  This is also the first test of tinj since we added interaction with EPICS channels and migrated to svn.  An earlier version had been previously demonstrated at LLO.  The tests were carried out between GPS = 1117004777 - 1117006270.  We scheduled the standard BNS injection (1.4 on 1.4 msun with optimal orientation at 45 Mpc) that has been used in previous tests [1].  This file, which lives in svn, is called injection_H1.out.  The goal of the test was to inject this waveform with increasing loudness until the folks at LHO could see the signal sweeping across the strain spectrum.

The first attempt failed to inject because H1:CAL-INJ_TINJ_ENABLE = 0.  We set the value to 1.  The next several attempts (GPS = 1117004777, 1117004993, 1117005152) failed to show up because the transient gain in the CAL model was set to zero.  We set it to one and started over.  The following injections were successful:

1117005396 2 1 injection_
1117005598 2 4 injection_
1117005756 2 10 injection_
1117005914 2 100 injection_
1117006170 2 100 injection_

The first column is GPS time, the second is injection type (2 = CBC), the third is scale factor, and the last column is the prefix for the injection file.  Dan and Kiwamu weren't 100% sure they were seeing the BNS signal until we injected with a scale factor of 100.  During the last injection, (scale factor = 100), Jeff and Eric watched the output of HWINJ filter bank.  At the very end, it reached a value of ~50 counts, which did not exceed the current HWINJ LIMIT  = 200.

We fixed a bug with tinj.  First, we fixed a bug, in which the value of TINJ_PAUSE was interpreted incorrectly (1 should have been 0).  Also, the binary executable for tinj included in svn yielded a library error:

tinj: error while loading shared libraries: libmwlaunchermain.so: cannot open shared object file: No such file or directory

So, we recompiled a version that works at LHO and recommitted to svn.  NOTE: we have left tinj running in the background for a stability test.  However, there are no planned injections currently scheduled.

[1] https://alog.ligo-la.caltech.edu/aLOG/index.php?callRep=17073
Comments related to this report
christopher.biwer@LIGO.ORG - 06:57, Saturday 30 May 2015 (18715)
I've attached spectrograms of the five injections. The injections at 1117005598, 1117005756, 1117005914, and 1117006170 show up visibly in spectrograms of L1:CAL-DELTAL_EXTERNAL_DQ.

The segment database uses the name H1:ODC-INJECTION_CBC to flag CBC injections. I do not see the injections in the segment database. The following command was used:

ligolw_segment_query_dqsegdb --query-segments --segment-url https://dqsegdb5.phy.syr.edu --gps-start-time 1117005296 --gps-end-time 1117006270  --include-segments H1:ODC-INJECTION_CBC
Images attached to this comment
peter.shawhan@LIGO.ORG - 12:20, Monday 01 June 2015 (18745)
Small correction to something in the original post: note that injection type (TINJ_TYPE) 2 is actually Burst, not CBC, according to https://wiki.ligo.org/Calibration/HWInjBookkeeping and as used in CAL-INJ_ODC on https://wiki.ligo.org/DetChar/DataQuality/AligoFlags.  However, that is NOT the reason that there are no corresponding segments in the database.  See next comment.
peter.shawhan@LIGO.ORG - 12:49, Monday 01 June 2015 (18749)
If everything is working properly, hardware injections of transient signals should be indicated by bits in H1:CAL-INJ_ODC_CHANNEL_OUT_DQ (256 Hz, in raw frames), H1:ODC-MASTER_CHANNEL_OUT_DQ (16384 Hz, in raw, rds, and hoft frames), and H1:GDS-CALIB_STATE_VECTOR (16 Hz, in hoft frames only).  I checked this using a program called FrBitmaskTransitions that I wrote for this purpose.  (It's a handy program and everyone is welcome to use it.  It's currently living in ~pshawhan/hwinj/monitor/ on the Caltech cluster.)

H1:CAL-INJ_ODC_CHANNEL_OUT_DQ is the most fundamental since that bitmask channel is created in the CAL model.  Here's the report for that channel:

pshawhan@> ./FrBitmaskTransitions -c H1:CAL-INJ_ODC_CHANNEL_OUT_DQ /archive/frames/ER7/raw/H1/H-H1_R-11170/H-H1_R-111700[56]*.gwf
1117005056.000000  0x30001f87  Data starts
1117005139.625000  0x20001f87  28 off
1117005139.628906  0x30001f87  28 on
1117005139.644531  0x20001f87  28 off
1117005139.648437  0x30001f87  28 on
1117005139.667968  0x20001f87  28 off
1117005139.671875  0x30001f87  28 on
1117005139.738281  0x20001f87  28 off
1117005139.742187  0x30001f87  28 on
1117005139.992187  0x20001f87  28 off
1117005140.000000  0x30001f87  28 on
1117005331.496093  0x30001f82  0 off, 2 off
1117005396.007812  0x30001faa  3 on, 5 on
1117005484.734375  0x30001f82  3 off, 5 off
1117005598.007812  0x30001faa  3 on, 5 on
1117005638.519531  0x20001faa  28 off
1117005638.523437  0x30001faa  28 on
1117005638.800781  0x20001faa  28 off
1117005638.804687  0x30001faa  28 on
1117005639.468750  0x20001faa  28 off
1117005639.472656  0x30001faa  28 on
1117005639.500000  0x20001faa  28 off
1117005639.503906  0x30001faa  28 on
1117005639.519531  0x20001faa  28 off
1117005639.523437  0x30001faa  28 on
1117005641.589843  0x20001faa  28 off
1117005641.593750  0x30001faa  28 on
1117005641.976562  0x20001faa  28 off
1117005641.980468  0x30001faa  28 on
1117005686.734375  0x30001f82  3 off, 5 off
1117005733.746093  0x30000b82  10 off, 12 off
1117005734.496093  0x30001f82  10 on, 12 on
1117005756.007812  0x30001faa  3 on, 5 on
1117005844.734375  0x30001f82  3 off, 5 off
1117005914.007812  0x30001faa  3 on, 5 on
1117006002.734375  0x30001f82  3 off, 5 off
1117006170.007812  0x30001faa  3 on, 5 on
1117006258.734375  0x30001f82  3 off, 5 off
1117007040.000000  0x30001f82  Data ends
You can see that bits 3 and 5 go on and off when they should, corresponding to the five successful injections noted above. (Bit 5 is the bit in CAL-INJ_ODC for type 2 transient injections.) The CW injections were running continuously, except that I see that someone apparently turned off the HARDWARE ACTIVE switch momentarily (bit 10), causing the "HARDWARE non-zero" bit (bit 12) to go off at the same time. I don't know what bits 28 and 29 represent in this bitmask (they aren't in the table at https://alog.ligo-la.caltech.edu/aLOG/index.php?callRep=17990), or why bit 28 flickered on and off at times. I also don't know why bits 0 and 2 went OFF at GPS 1117005331.496093; the original post said that the transient gain was initially zero and then they switched it to 1, but if that's the cause then it seems like the meaning of bit 2 is opposite from what was intended (?). The summary bit (bit 0) is probably just following that. Now, combinations of bits from CAL-INJ_ODC are supposed to be represented by summary bits in ODC-MASTER, but I find that they were NOT set:
pshawhan@> ./FrBitmaskTransitions -c H1:ODC-MASTER_CHANNEL_OUT_DQ /archive/frames/ER7/raw/H1/H-H1_R-11170/H-H1_R-111700[56]*.gwf
1117005056.000000  0x90bff0d8  Data starts
1117007040.000000  0x90bff0d8  Data ends
The summary bit calculation probably requires bit 0 and/or 2 of CAL-INJ_ODC to be on. And the injection bits weren't set in CALIB_STATE_VECTOR either, but that's not surprising since those are derived from ODC-MASTER:
pshawhan@> ./FrBitmaskTransitions -c H1:GDS-CALIB_STATE_VECTOR /archive/frames/ER7/hoft/H1/H-H1_HOFT_C00-11170/H-H1_HOFT_C00-1117003776-4096.gwf
1117003776.000000  0x00000008  Data starts
1117007750.375000  0x0000001d  0 on, 2 on, 4 on
1117007750.437500  0x00000008  0 off, 2 off, 4 off
1117007872.000000  0x00000008  Data ends
It's curious that bits 4 (FILTERS_OK), 2 (SCIENCE_QUALITY), and therefore also bit 0 (HOFT_OK) flashed on for just a brief moment during the 4096-second interval I scanned, but that's unrelated to the hardware injection tests. Finally, no segments were inserted into the segment database, but that makes sense because bit 2 in CAL-INJ_ODC was off (for some reason -- maybe a bug) and I believe that is required to be on in the SegGener configuration.
Displaying report 1-1 of 1.