Displaying reports 61601-61620 of 82999.Go to page Start 3077 3078 3079 3080 3081 3082 3083 3084 3085 End
Reports until 23:55, Friday 25 September 2015
H1 General
patrick.thomas@LIGO.ORG - posted 23:55, Friday 25 September 2015 - last comment - 23:58, Friday 25 September 2015(21966)
Ops Eve End Shift Summary
TITLE: 09/25 [EVE Shift]: 23:00-07:00 UTC (16:00-00:00 PDT), all times posted in UTC
STATE Of H1: Observing, ~67 MPc
SHIFT SUMMARY: Recovered from two lock losses. The cause of the first is unclear. The second was likely from a 6.2 magnitude earthquake in Chile. After recovering from the earthquake I put it into commissioning mode to allow Chris to do hardware injections while LLO was down. He is done and we are back to observing.
INCOMING OPERATOR: Ed
Comments related to this report
patrick.thomas@LIGO.ORG - 23:58, Friday 25 September 2015 (21967)
Terramon and GW Stat on nuc1 are down due to some kind of authentication issue.
H1 INJ (DetChar, INJ)
christopher.biwer@LIGO.ORG - posted 23:53, Friday 25 September 2015 - last comment - 07:38, Monday 28 September 2015(21965)
Hardware injection testing for lower frequency waveforms
We tested a set of waveforms to see if they would saturation the ETMY ESD.

Test the 15Hz waveform

Previously we have tested a waveform that began at 30Hz, see aLog 21838. It was requested we try it from 15Hz instead of 30Hz.

Here are the commands I ran for testing the 15Hz waveform:
ezcawrite H1:CAL-INJ_TINJ_TYPE 1
awgstream H1:CAL-INJ_TRANSIENT_EXC 16384 ../H1/coherenttest1from15hz_1126257408.out 0.1 -d -d >> log3.txt
awgstream H1:CAL-INJ_TRANSIENT_EXC 16384 ../H1/coherenttest1from15hz_1126257408.out 0.25 -d -d >> log3.txt
awgstream H1:CAL-INJ_TRANSIENT_EXC 16384 ../H1/coherenttest1from15hz_1126257408.out 0.5 -d -d >> log3.txt
awgstream H1:CAL-INJ_TRANSIENT_EXC 16384 ../H1/coherenttest1from15hz_1126257408.out 1.0 -d -d >> log3.txt 
awgstream H1:CAL-INJ_TRANSIENT_EXC 16384 ../H1/coherenttest1from15hz_1126257408.out 1.0 -d -d >> log3.txt 
awgstream H1:CAL-INJ_TRANSIENT_EXC 16384 ../H1/coherenttest1from15hz_1126257408.out 1.0 -d -d >> log3.txt

The start times of the injections from the log file (log3.txt):
SIStrOpen: Waveform starts at GPS=1127276638, epoch=0, sample=0
SIStrOpen: Waveform starts at GPS=1127276799, epoch=0, sample=0
SIStrOpen: Waveform starts at GPS=1127277026, epoch=0, sample=0
SIStrOpen: Waveform starts at GPS=1127277293, epoch=0, sample=0
SIStrOpen: Waveform starts at GPS=1127277517, epoch=0, sample=0
SIStrOpen: Waveform starts at GPS=1127277840, epoch=0, sample=0

I did not notice any ESD saturations.

John's waveforms

John V. has also provided 10 waveforms that I tested, see aLog 21964.

Cautiously testing the first waveform

Here are the command I entered as I slowly scaled up the first waveform's amplitude: 
awgstream H1:CAL-INJ_TRANSIENT_EXC 16384 ../H1/posterior0_1126259455.out 0.2 -d -d >> log3.txt
awgstream H1:CAL-INJ_TRANSIENT_EXC 16384 ../H1/posterior0_1126259455.out 0.3333 -d -d >> log3.txt
awgstream H1:CAL-INJ_TRANSIENT_EXC 16384 ../H1/posterior0_1126259455.out 0.5 -d -d >> log3.txt 
awgstream H1:CAL-INJ_TRANSIENT_EXC 16384 ../H1/posterior0_1126259455.out 0.6666 -d -d >> log3.txt
awgstream H1:CAL-INJ_TRANSIENT_EXC 16384 ../H1/posterior0_1126259455.out 0.75 -d -d >> log3.txt
awgstream H1:CAL-INJ_TRANSIENT_EXC 16384 ../H1/posterior0_1126259455.out 0.85 -d -d >> log3.txt
awgstream H1:CAL-INJ_TRANSIENT_EXC 16384 ../H1/posterior0_1126259455.out 1.0 -d -d >> log3.txt
awgstream H1:CAL-INJ_TRANSIENT_EXC 16384 ../H1/posterior0_1126259455.out 1.0 -d -d >> log3.txt

The start times for these injections:
SIStrOpen: Waveform starts at GPS=1127278105, epoch=0, sample=0
SIStrOpen: Waveform starts at GPS=1127278209, epoch=0, sample=0
SIStrOpen: Waveform starts at GPS=1127278748, epoch=0, sample=0
SIStrOpen: Waveform starts at GPS=1127279093, epoch=0, sample=0
SIStrOpen: Waveform starts at GPS=1127279520, epoch=0, sample=0
SIStrOpen: Waveform starts at GPS=1127279644, epoch=0, sample=0
SIStrOpen: Waveform starts at GPS=1127280123, epoch=0, sample=0
SIStrOpen: Waveform starts at GPS=1127280433, epoch=0, sample=0
SIStrOpen: Waveform starts at GPS=1127281232, epoch=0, sample=0

The injection that began at 1127280433 was near an ETMY alert from the robot voice. The ETMY alert happened a bit after the injection happened. SO I waited, I repeated the same injection, and there was no alert.

I did one of these injections with a padding of 10 minutes so if the search groups are going to followup one of these injections in more detail this would be a good choice:
awgstream H1:CAL-INJ_TRANSIENT_EXC 16384 ../H1/posterior0_1126259455.out 1.0 -d -d >> log3.txt # gave this guy a bit of time

The start time of this injection is:
SIStrOpen: Waveform starts at GPS=1127281956, epoch=0, sample=0

Testing the other nine waveforms

Then I tested the remaining 9 waveforms by beginning with a scale factor of 0.3333 and incrementing to 1.0. I did these with little spacing between the injections so I do not think this set is worth the analysis groups following up. However, I think the injections with scale factor 1.0 should be looked at for ESD saturation (I believe Andy has a script for that):
awgstream H1:CAL-INJ_TRANSIENT_EXC 16384 ../H1/posterior1_1126259455.out 0.3333 -d -d >> log3.txt
awgstream H1:CAL-INJ_TRANSIENT_EXC 16384 ../H1/posterior1_1126259455.out 0.6666 -d -d >> log3.txt
awgstream H1:CAL-INJ_TRANSIENT_EXC 16384 ../H1/posterior1_1126259455.out 1.0 -d -d >> log3.txt
awgstream H1:CAL-INJ_TRANSIENT_EXC 16384 ../H1/posterior2_1126259455.out 0.3333 -d -d >> log3.txt
awgstream H1:CAL-INJ_TRANSIENT_EXC 16384 ../H1/posterior2_1126259455.out 0.6666 -d -d >> log3.txt
awgstream H1:CAL-INJ_TRANSIENT_EXC 16384 ../H1/posterior2_1126259455.out 1.0 -d -d >> log3.txt
awgstream H1:CAL-INJ_TRANSIENT_EXC 16384 ../H1/posterior3_1126259455.out 0.3333 -d -d >> log3.txt
awgstream H1:CAL-INJ_TRANSIENT_EXC 16384 ../H1/posterior3_1126259455.out 0.6666 -d -d >> log3.txt
awgstream H1:CAL-INJ_TRANSIENT_EXC 16384 ../H1/posterior3_1126259455.out 1.0 -d -d >> log3.txt
awgstream H1:CAL-INJ_TRANSIENT_EXC 16384 ../H1/posterior4_1126259455.out 0.3333 -d -d >> log3.txt
awgstream H1:CAL-INJ_TRANSIENT_EXC 16384 ../H1/posterior4_1126259455.out 0.6666 -d -d >> log3.txt
awgstream H1:CAL-INJ_TRANSIENT_EXC 16384 ../H1/posterior4_1126259455.out 1.0 -d -d >> log3.txt
awgstream H1:CAL-INJ_TRANSIENT_EXC 16384 ../H1/posterior5_1126259455.out 0.3333 -d -d >> log3.txt
awgstream H1:CAL-INJ_TRANSIENT_EXC 16384 ../H1/posterior5_1126259455.out 0.6666 -d -d >> log3.txt
awgstream H1:CAL-INJ_TRANSIENT_EXC 16384 ../H1/posterior5_1126259455.out 1.0 -d -d >> log3.txt
awgstream H1:CAL-INJ_TRANSIENT_EXC 16384 ../H1/posterior6_1126259455.out 0.3333 -d -d >> log3.txt
awgstream H1:CAL-INJ_TRANSIENT_EXC 16384 ../H1/posterior6_1126259455.out 0.6666 -d -d >> log3.txt
awgstream H1:CAL-INJ_TRANSIENT_EXC 16384 ../H1/posterior6_1126259455.out 1.0 -d -d >> log3.txt
awgstream H1:CAL-INJ_TRANSIENT_EXC 16384 ../H1/posterior7_1126259455.out 0.3333 -d -d >> log3.txt
awgstream H1:CAL-INJ_TRANSIENT_EXC 16384 ../H1/posterior7_1126259455.out 0.6666 -d -d >> log3.txt
awgstream H1:CAL-INJ_TRANSIENT_EXC 16384 ../H1/posterior7_1126259455.out 1.0 -d -d >> log3.txt
awgstream H1:CAL-INJ_TRANSIENT_EXC 16384 ../H1/posterior8_1126259455.out 0.3333 -d -d >> log3.txt
awgstream H1:CAL-INJ_TRANSIENT_EXC 16384 ../H1/posterior8_1126259455.out 0.6666 -d -d >> log3.txt
awgstream H1:CAL-INJ_TRANSIENT_EXC 16384 ../H1/posterior8_1126259455.out 1.0 -d -d >> log3.txt
awgstream H1:CAL-INJ_TRANSIENT_EXC 16384 ../H1/posterior9_1126259455.out 0.3333 -d -d >> log3.txt
awgstream H1:CAL-INJ_TRANSIENT_EXC 16384 ../H1/posterior9_1126259455.out 0.6666 -d -d >> log3.txt
awgstream H1:CAL-INJ_TRANSIENT_EXC 16384 ../H1/posterior9_1126259455.out 1.0 -d -d >> log3.txt

The start times of these injections:
SIStrOpen: Waveform starts at GPS=1127282013, epoch=0, sample=0
SIStrOpen: Waveform starts at GPS=1127282066, epoch=0, sample=0
SIStrOpen: Waveform starts at GPS=1127282120, epoch=0, sample=0
SIStrOpen: Waveform starts at GPS=1127282173, epoch=0, sample=0
SIStrOpen: Waveform starts at GPS=1127282226, epoch=0, sample=0
SIStrOpen: Waveform starts at GPS=1127282278, epoch=0, sample=0
SIStrOpen: Waveform starts at GPS=1127282326, epoch=0, sample=0
SIStrOpen: Waveform starts at GPS=1127282377, epoch=0, sample=0
SIStrOpen: Waveform starts at GPS=1127282422, epoch=0, sample=0
SIStrOpen: Waveform starts at GPS=1127282476, epoch=0, sample=0
SIStrOpen: Waveform starts at GPS=1127282517, epoch=0, sample=0
SIStrOpen: Waveform starts at GPS=1127282577, epoch=0, sample=0
SIStrOpen: Waveform starts at GPS=1127282631, epoch=0, sample=0
SIStrOpen: Waveform starts at GPS=1127282681, epoch=0, sample=0
SIStrOpen: Waveform starts at GPS=1127282727, epoch=0, sample=0
SIStrOpen: Waveform starts at GPS=1127282770, epoch=0, sample=0
SIStrOpen: Waveform starts at GPS=1127282819, epoch=0, sample=0
SIStrOpen: Waveform starts at GPS=1127282964, epoch=0, sample=0
SIStrOpen: Waveform starts at GPS=1127283007, epoch=0, sample=0
SIStrOpen: Waveform starts at GPS=1127283048, epoch=0, sample=0
SIStrOpen: Waveform starts at GPS=1127283089, epoch=0, sample=0
SIStrOpen: Waveform starts at GPS=1127283160, epoch=0, sample=0
SIStrOpen: Waveform starts at GPS=1127283204, epoch=0, sample=0
SIStrOpen: Waveform starts at GPS=1127283245, epoch=0, sample=0
SIStrOpen: Waveform starts at GPS=1127283292, epoch=0, sample=0
SIStrOpen: Waveform starts at GPS=1127283338, epoch=0, sample=0
SIStrOpen: Waveform starts at GPS=1127283440, epoch=0, sample=0

As I did these injections I had the SUS-ETMY_L3_ESDOUTF_LL_OUT channel open in dataviewer. I did not see any injection go above the 90000 counts. The highest was posterior0*.out which was near 80000 counts.
Non-image files attached to this report
Comments related to this report
john.veitch@LIGO.ORG - 02:28, Saturday 26 September 2015 (21969)

I am going to follow up the injections I passed to Chris. Assuming the "start time" is the time at the 1st sample of the injection file (and not the 1st non-zero sample) the end times of the increasing amplitude posterior0 injections should be around

[1127278112.46, 1127278216.46, 1127278755.46, 1127279100.46, 1127279527.46, 1127279651.46, 1127280130.46, 1127280440.46, 1127281239.46, 1127281963.46]
 
and for the scan through posterior injections 1-9 with increasing amplitude they are
[1127282020.46, 1127282073.46, 1127282127.46, 1127282180.46, 1127282233.46, 1127282285.46, 1127282333.46, 1127282384.46, 1127282429.46, 1127282483.46, 1127282524.46, 1127282584.46, 1127282638.46, 1127282688.46, 1127282734.46, 1127282777.46, 1127282826.46, 1127282971.46, 1127283014.46, 1127283055.46, 1127283096.46, 1127283167.46, 1127283211.46, 1127283252.46, 1127283299.46, 1127283345.46, 1127283447.46]
 
I'm going to just run all of these since they should be quite cheap to do. I'll post an update when the runs complete.
andrew.lundgren@LIGO.ORG - 07:38, Monday 28 September 2015 (22015)DetChar, INJ
The only ETMY overflows during the injection periods were:

1127278436.8
1127280154.9 (also overflowed ETMY L2 and OMC DCPD)
1127282847.5

None were related to the injections.
H1 INJ (DetChar, INJ)
christopher.biwer@LIGO.ORG - posted 23:45, Friday 25 September 2015 (21964)
Set of waveforms for testing hardware injections
John V. has also provided 10 waveforms that I used for testing. The waveform single-column ASCII files that contain the h(t) time series can be found in the hardware injection SVN here: https://daqsvn.ligo-la.caltech.edu/svn/injection/hwinj/Details/Inspiral/${IFO}/posterior*.out

And the corresponding XML parameter files can be found here: https://daqsvn.ligo-la.caltech.edu/svn/injection/hwinj/Details/Inspiral/posterior*.xml

I will post time series plots of the waveforms as a comment later.
H1 General
patrick.thomas@LIGO.ORG - posted 23:21, Friday 25 September 2015 (21963)
Back to Observing mode
06:20 UTC Chris is done with hardware injections, back to observing mode
H1 INJ (DetChar, INJ)
christopher.biwer@LIGO.ORG - posted 23:17, Friday 25 September 2015 (21962)
Done with hardware injection tests
I'm done with the hardware injection tests. More details in upcoming aLog entry.
H1 General
patrick.thomas@LIGO.ORG - posted 21:22, Friday 25 September 2015 (21961)
Out of observing for hw injection
04:20 UTC Taking out of observing to allow Chris to test hardware injections
H1 INJ (DetChar, INJ)
christopher.biwer@LIGO.ORG - posted 21:21, Friday 25 September 2015 (21960)
starting single-IFO hardware injection test
L1 is down at the moment. I am beginning some single-IFO hardware injection tests at H1 now.
H1 General
patrick.thomas@LIGO.ORG - posted 21:19, Friday 25 September 2015 (21959)
Back to Observing mode
03:28 UTC locked on DRMI briefly, loss lock, tripped BS ISI stage 2 GS13
04:09 UTC Back to low noise
04:16 UTC Back to observing mode
H1 General
patrick.thomas@LIGO.ORG - posted 20:18, Friday 25 September 2015 (21958)
lockloss
03:15 UTC lockloss, 6.2 Mag Earthquake, 30km SW of Ovalle, Chile, 02:51:18 UTC
H1 General
patrick.thomas@LIGO.ORG - posted 20:01, Friday 25 September 2015 (21957)
Ops Eve Mid Shift Summary
23:48 UTC tour in control room
23:58 UTC video3 frozen, rebooted
00:26 UTC last of tour left control room
01:10 UTC problems with operator0 workstation, rebooted twice
02:06 - 02:11 UTC stepped out of control room

Still in observing mode at ~ 70 MPc.
H1 PEM (DetChar)
dale.ingram@LIGO.ORG - posted 17:32, Friday 25 September 2015 (21956)
Outreach activity report
A tour group was on site this afternoon.  Arrival time at LSB = ~3:00 PM.  Departure time = ~5:15 PM.  Group size = ~26 adults.  Vehicles at the LSB = ~12 passenger cars.  The group walked to the overpass near 4:15 PM and visited the control room near 4:45 PM.
H1 General
patrick.thomas@LIGO.ORG - posted 16:41, Friday 25 September 2015 (21955)
Back to Observing mode
23:23 UTC Back to observing. Only intervention required was moving the BS in pitch at LOCK_DRMI_1F. Cheryl states that it is acceptable that the 'Continuous Wave Inj Signal' on the Ops Overview is red and stating 'No Injection'.
LHO General
patrick.thomas@LIGO.ORG - posted 16:36, Friday 25 September 2015 (21954)
Ops Eve Beginning Shift Summary
TITLE: 09/25 [EVE Shift]: 23:00-07:00 UTC (16:00-00:00 PDT), all times posted in UTC
STATE Of H1: Lock loss 10 minutes prior to start of shift.
OUTGOING OPERATOR: Cheryl
QUICK SUMMARY: Lights appear off in the LVEA, PSL enclosure, end X, end Y and mid X. I can not tell from the camera if they are off at mid Y. Seismic in 0.03 - 0.1 Hz band is between 10^-2 and 10^-1 um/s at end X and end Y. It is around 10^-2 um/s at the corner station. Seismic in 0.1 - 0.3 Hz band is around 10^-1 um/s. Wind speeds are ranging up to 20mph.
H1 General
cheryl.vorvick@LIGO.ORG - posted 16:16, Friday 25 September 2015 (21951)
OPS Day Shift: Sept 25 15:00-2300UTC, 8:00-16:00PT

SUMMARY:

IFO relocked and was in Observe most of the shift.

4 large ETMY glitches in the second half of the lock.

IFO lost lock about 10 minutes before the end of the shift.

Currently relocked and on it's way to Low Noise.

 

TIMELINE:

 

18:42:56UTC - IFO to Observe

20:28:09UTC - ETMY saturation

20:31:19UTC - airplane heard in CR

20:36:45UTC - airplane heard in CR again

22:00:00UTC - or about that... Gerardo drives to Mid-Y

22:15UTC - Gerardo left Mid-Y

22:20UTC - Gerardo arrived Corner Station

22:50UTC - lock loss

H1 ISC (ISC, SUS)
cheryl.vorvick@LIGO.ORG - posted 16:09, Friday 25 September 2015 (21949)
lock loss 13:47:02UTC Sept 25

I made 4 plots, and on the control side, it's subtle but looks to me like OM1 M1 DAMP Y deviated first at lock loss, and on the optics side, all of Y arm optics were already oscillating and then lock loss.

Plot 1: last 33 seconds of the lock - control signals

Plot 2: last 33 seconds of the lock - optics

Plot 3: last 3 seconds of the lock - control signals

Plot 4: last 10 seconds of the lock - optics

Plot 5: fist big glitch at 13:45:47

Images attached to this report
H1 SUS
betsy.weaver@LIGO.ORG - posted 13:22, Friday 25 September 2015 (21948)
ETM Charge measurements from last Fri

During the large earthquake last Friday, Jeff K took the opportunity to run a set of charge measurements on the ETMs.  While the ETMy data did not yield successful plots (am looking into matlab), the ETMx results are posted below in trends from July to now.  Note, we last changed the bias signs (on both ETMX and ETMY) on July 22nd - alog 19848.

Images attached to this report
H1 AOS (CAL, INJ, ISC)
sudarshan.karki@LIGO.ORG - posted 10:45, Friday 25 September 2015 - last comment - 13:52, Tuesday 29 September 2015(21944)
Pcal Inverse Actuation Filter

Summary:

In an effort to create a inverse actuation filter for Hardware injection through Pcal infrastructure, we use the transfer function between RxPD  and excitation of which RxPD is calibrated in terms of metres of displacement. . Using this RxPD calibration and the measured transfer fumction we calibrate the excitation [cts]  in terms of metres and use it to create the inverse actuation filter. This will be installed in one of the excitation channel, possibly swept sine channel, for testing purpose.

Detail:

In the above plot, the two left plots are the actual magnitude and phase of the measurement and different fits. The red plot is the inverse of measured transfer function between calibrated RxPD and pcal excitation. In short, it is cts of excitation to metres of test mass displacement. The rest of the plots are fit to that measured TF. In this case, the residual plots on the right side are more informative. The blue plot is the residual between measured TF and the fit that includes two zeros. The residual looks pretty good for this case but we do not have the luxury of only using two zeros. We need equal or greater number of poles to roll off the signal at higher frequency. For this we use a complex pole pair at 7 Khz and an additional real pole at same frequency. This creates some magnitude and significant phase distortion at higher frequencies as seen in the green residual plot but this is a systematic and we can account for this in our analysis later.


The magenta plot is the foton implementation of our two zeros and three pole fit plotted in green. There is a difference between the actual matlab generated filter and the foton version of it at frequencies above KHz. This is a known effect and is described in detail in G1501013.

I have written a litlle more detail technical note  and can be found at T1500496.

Images attached to this report
Comments related to this report
sudarshan.karki@LIGO.ORG - 13:52, Tuesday 29 September 2015 (22074)

The script used to generate the plots above is committed to the SVN:

/ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/O1/H1/Scripts/INVACT_PCAL/

The measuremnt files are in the following location

/ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/O1/H1/Measurement/INVACT_PCAL/

H1 SEI
hugh.radkins@LIGO.ORG - posted 10:22, Friday 25 September 2015 (21945)
Looking for alternative to HEPI Offline Valve-Check Test

To assess the health of the HEPI Actuator Parker Valves, which are very susceptable to blockage from fluid contaminants, LLO has regularly done the "Valve_Check" test.  I have never successfully managed to make this work at LHO mainly because of missing files and lack of understanding of all the components to the test.

It also requires the HEPIs to be deisolated as 3hz sines waves are driven to the valves to assess the health of the valve.  The results are posted on a plot and compared to previous values and trends and dramatic changes are spotted indicating a valve problem.  Again, since we don't like taking the HEPI platforms down, and, I haven't been able to get the valve check to run here, an alternative which doesn't require de-isolating the platform is being searched for.

As we are looking for changes in the valve's effectiveness, it seems simple enough to look at the postion of the Actuator (IPS) in response to the Actuator Drive (OUTF.)  So in dataviewer, I was just going to plot the local basis IPS INMON and the OUTF_OUTPUT.  Upon further study, we might find it better to extract from other points of the chain such as IPS OUTPUT to get nm but for now I just grabbed the overview elements which is counts (0.001"/655cts) and the OUTF_OUTPUT...which should be nm in IPS space, not drive to make nm, I think...  Anyway, at this point we are just looking for bad trends or steps that can not be explained.

I was going to start with 14 days of data (LLO runs the valve check weekly) but there was some zero elements that I can't figure out how to remove with DV so I'm getting divide by zero errors.  So here is just a week's data for the BS.

In the attached plot I put the 8 each IPS reading and OUTF drive pairs adjacent (H1 in Chs 1 & 2, H2 in Chs 3 & 4, etc.)  I then made the ratio of reading to drive and put it in the Ch1 graph hiding the original IPS reading.  So the graphs with the brown traces are the ratios between the IPS not seen and the red trace drive in the graph just above.

So what stands out?

Regarding valve health...there are no monotonic trends but it is only a week so maybe not useful.

There is a shift in all vertical channels but they are all about the same magnitude in OUTPUT.  I'd think a bad valve would stand out as a larger shift and the other are just making up a smaller portion of the total load.  While the shift is clear on the Drive OUTF, on the IPS reading it is at the few counts level, related to IFO state maybe and otherwise insignificant?

The ratios are much closer to unity for the verticals but this is just a function of the larger vertical drives as we have a nearly 1/2 mm offset on the vertical hold position on the BS.

For the Horizontal channels, the ratios for all but H4 drift, swing, oscilate around 1 or 2 units whereas H4 swings around 5 to 15 units.  Does this indicate something different about H4? Other than just the zero position of the IPS or conspiring cartesian positions yielding a smaller drive to H4?

Given that the zero IPS reading is not necessarily zero, any conclusion depending on that is biased and so must be salted.

Conclusion, no changes in valve performance in the past week.  More work needed to look at longer time periods.  MIT(tlemen) is looking at this too.

Images attached to this report
H1 INJ (DetChar, INJ)
christopher.biwer@LIGO.ORG - posted 13:53, Wednesday 23 September 2015 - last comment - 12:53, Friday 25 September 2015(21852)
single-IFO hardware injection tests at H1
L1 went out of lock. At H1 we turned off the intent bit and injected some hardware injections.

The hardware injections were the same waveform that was injected on September 21. For more information about those injections see aLog entry 21759

For information about the waveform see aLog entry 21774.

tinj was not used to do the injections.The commands to do the injections were:
awgstream H1:CAL-INJ_TRANSIENT_EXC 16384 H1-HWINJ_CBC-1126257410-12.txt 0.5 -d -d >> log2.txt
awgstream H1:CAL-INJ_TRANSIENT_EXC 16384 H1-HWINJ_CBC-1126257410-12.txt 1.0 -d -d >> log2.txt
ezcawrite H1:CAL-INJ_TINJ_TYPE 1
awgstream H1:CAL-INJ_TRANSIENT_EXC 16384 H1-HWINJ_CBC-1126257410-12.txt 1.0 -d -d >> log2.txt
awgstream H1:CAL-INJ_TRANSIENT_EXC 16384 H1-HWINJ_CBC-1126257410-12.txt 1.0 -d -d >> log2.txt

To my chagrin the first two injections were labeled as burst injections.

Taken from the awgstream log the corresponding times are approximates of the injection time:

1127074640.002463000
1127074773.002417000
1127075235.002141000
1127075742.002100000

The expected SNR of the injection is ~18 without any scaling factor.

I've attached omegascans of the injections. There is no sign of the "pre-glitch" that was seen on September 21.
Images attached to this report
Comments related to this report
christopher.biwer@LIGO.ORG - 13:57, Wednesday 23 September 2015 (21855)DetChar, INJ
Attached stdout of command line.
Non-image files attached to this comment
david.shoemaker@LIGO.ORG - 14:04, Wednesday 23 September 2015 (21857)
Neat! looks good.
john.veitch@LIGO.ORG - 01:37, Thursday 24 September 2015 (21878)
Hi Chris,
It looks like there is a 1s offset between the times you report and the rough coalescence time of the signal. Do you know if it is exactly 1s difference?
peter.shawhan@LIGO.ORG - 09:19, Thursday 24 September 2015 (21887)INJ
Yes, as John said, all of the end times of the waveforms are just about 1 second later that what's in the original post.

I ran a version my simple bandpass-filtered overlay script for these waveforms.  Filtering both the model (strain waveform injected into the system) and the data from 70-260 Hz, it overlays them, and also does a crude (non-optimal) matched filter to estimate the relative amplitude and time offset.  The four plots attached are for the four injected signals; note that the first one was injected with a scale factor of 0.5 and is not "reconstructed" by my code very accurately.  The others actually look rather good, with reasonably consistent amplitudes and time delays.  Note that the sign of the signal came out correctly!
Images attached to this comment
Non-image files attached to this comment
christopher.biwer@LIGO.ORG - 09:47, Thursday 24 September 2015 (21890)
I ran the daily BBH search with the injected template on the last two injections (1127075235 and 1127075742).

For 1127075235; the recovered end time was 1127075235.986, the SNR was 20.42, the chi-squared was 29.17, and the newSNR was 19.19.
For 1127075242; the recovered end time was 1127075242.986, the SNR was 20.04, the chi-squared was 35.07, and the newSNR was 19.19.
reed.essick@LIGO.ORG - 14:19, Thursday 24 September 2015 (21896)
KW sees all the injections with the +1 sec delay, some of them in multiple frequency bands.
From 
  /gds-h1/dmt/triggers/H-KW_RHOFT/H-KW_RHOFT-11270/H-KW_RHOFT-1127074624-64.trg
  /gds-h1/dmt/triggers/H-KW_RHOFT/H-KW_RHOFT-11270/H-KW_RHOFT-1127074752-64.trg
  /gds-h1/dmt/triggers/H-KW_RHOFT/H-KW_RHOFT-11270/H-KW_RHOFT-1127075200-64.trg
  /gds-h1/dmt/triggers/H-KW_RHOFT/H-KW_RHOFT-11270/H-KW_RHOFT-1127075712-64.trg

    tcent         fcent significance channel
1127074640.979948   146    26.34      H1_GDS-CALIB_STRAIN_32_2048
1127074774.015977   119    41.17      H1_GDS-CALIB_STRAIN_8_128
1127074773.978134   165   104.42      H1_GDS-CALIB_STRAIN_32_2048
1127075235.980545   199   136.82      H1_GDS-CALIB_STRAIN_32_2048
1127075743.018279   102    74.87      H1_GDS-CALIB_STRAIN_8_128
1127075742.982020   162   113.65      H1_GDS-CALIB_STRAIN_32_2048

Omicron also sees them with the same delay
From :
  /home/reed.essick/Omicron/test/triggers/H-11270/H1:GDS-CALIB_STRAIN/H1-GDS_CALIB_STRAIN_Omicron-1127074621-30.xml
  /home/reed.essick/Omicron/test/triggers/H-11270/H1:GDS-CALIB_STRAIN/H1-GDS_CALIB_STRAIN_Omicron-1127074771-30.xml
  /home/reed.essick/Omicron/test/triggers/H-11270/H1:GDS-CALIB_STRAIN/H1-GDS_CALIB_STRAIN_Omicron-1127075221-30.xml
  /home/reed.essick/Omicron/test/triggers/H-11270/H1:GDS-CALIB_STRAIN/H1-GDS_CALIB_STRAIN_Omicron-1127075731-30.xml

    peak time          fcent      snr
1127074640.977539062  88.77163  6.3716
1127074773.983397960 648.78342 11.41002  <- surprisingly high fcent, could be due to clustering
1127075235.981445074 181.39816 13.09279
1127075742.983397960 181.39816 12.39437

LIB single-IFO jobs also found all the events. Post-proc pages can be found here:

 https://ldas-jobs.ligo.caltech.edu/~reed.essick/O1/2015_09_23-HWINJ/1127074640.98-0/H1L1/H1/posplots.html
 https://ldas-jobs.ligo.caltech.edu/~reed.essick/O1/2015_09_23-HWINJ/1127074773.98-1/H1L1/H1/posplots.html
 https://ldas-jobs.ligo.caltech.edu/~reed.essick/O1/2015_09_23-HWINJ/1127075235.98-2/H1L1/H1/posplots.html
 https://ldas-jobs.ligo.caltech.edu/~reed.essick/O1/2015_09_23-HWINJ/1127075742.98-3/H1L1/H1/posplots.html

all runs appear to have reasonable posteriors.
florent.robinet@LIGO.ORG - 23:17, Thursday 24 September 2015 (21935)DetChar
Here is how Omicron detects these injections:

https://ldas-jobs.ligo-wa.caltech.edu/~frobinet/scans/hd/1127074641/
https://ldas-jobs.ligo-wa.caltech.edu/~frobinet/scans/hd/1127074774/
https://ldas-jobs.ligo-wa.caltech.edu/~frobinet/scans/hd/1127075236/
https://ldas-jobs.ligo-wa.caltech.edu/~frobinet/scans/hd/1127075743/

Here are the parameters measured by Omicron (loudest tile):
1127074640: t=1127074640.981, f=119.9 Hz, SNR=6.7
1127074773: t=1127074773.981, f=135.3 Hz, SNR=11.8
1127075235: t=1127075235.981, f=114.9 Hz, SNR=12.8
1127075742: t=1127075742.981, f=135.3 Hz, SNR=12.4
joey.key@LIGO.ORG - 12:53, Friday 25 September 2015 (21947)
The BayesWave single IFO (glitch only) analysis recovers these injections with the following SNRs:
4640: 8.65535
4773: 19.2185
5253: 20.5258
5742: 20.1666
The results are posted here:
https://ldas-jobs.ligo.caltech.edu/~meg.millhouse/O1/CBC_hwinj/
Images attached to this comment
H1 CAL (CAL)
darkhan.tuyenbayev@LIGO.ORG - posted 01:10, Wednesday 23 September 2015 - last comment - 15:41, Friday 25 September 2015(21827)
Comparing ER8, O1 and kappa corrected O1 models

JeffreyK, SudarshanK, DarkhanT,

Overview

We made comparison plots of a DARM OLG TF and PCAL to DARM TF measurements taken at LHO with H1DARMmodel_ER8 and H1DARMmodel_O1 (uncorrected and corrected with kappa factors).

One of the main changes in the DARM model update for O1 compared to ER8 was that in the actuation function for ER8 model we did not account for an analog anti-imaging filter. We included that filter into the O1 model. Adding previously missing analog AI filter into the actuation function model increased the (measurement / model) residual to about 1% in magnitude and to ~6 deg around 500 Hz (~10 deg around 900 Hz). Initally some of the ER8 model parameter estimations (ESD/CD gains) were done to best fit the measurments for actuation function that does not include an analog AI.

We also took kappas calculated from calibration lines within about 20 minutes from DARM OLG TF measurement and plotted DARM model for O1 corrected with kappas in two different ways against the measurement to see how kappa corrections will take care of systematics in the model. At this point we don't have comparison results of the DARM OLG TF and PCAL2DARM TF measurements and kappa estimations to make a distinct statement. For this particular measurement from Sep 10, the DARM model that was corrected with κtst and κC produced smaller DARM OLG TF residual and actuation function residual compared to uncorrected model, but the sensing function residual was did not improve by the correction (see attached pdf's for actuation and sensing residuals).

Details

Some of the known issues / systematics in our DARM OLG TF model include:

- inverse actuation filters need to accout for an extra -1 sign (was fixed, see LHO alog 21703);

- CAL-CS reproduction should have a sign that's opposite from DARM output matrix (at LHO we had this correct, but it needed to be fixed at LLO).

This issue affects EP1 value that's written into Epics record and used for estimation of DARM time-dependent parameters (T1500377). At LHO in the DARM model for ER8 we manually rotated phase of EP1 to +44.4 degrees to account for this discrepancy; we modified both the paramter file and the DARM model script to account for the DAQ downsampling filter TF calculated at the xtst line frequency.

- residuals of actuation function and total DARM OLG TF (systemaic error);

- EP1-9 that are used for estimation of DARM temporal variations.

This variable might have been used in GDS calibration, we need to verify with MaddieW to make sure that this extra time delay is not included into GDS code.

One of the possible sources of systematic error in the sensing function model is using a single-pole TF to approximate IFO response.

Some of the parameters of the actuation functions were estimated without taking into account an analog AI filter (one of the issues listed above). We need to revisit ER8/O1 actuation function analysis results.

A comparison script, an updated DARM model script and DARM paramter files were committed calibration SVN:

CalSVN/aligocalibration/trunk/Runs/O1/H1/Scripts/DARMOLGTFs/

Plots were committed to:

CalSVN/aligocalibration/trunk/Runs/O1/H1/Results/DARMOLGTFs/

 

P.S. I'll add references later.

Images attached to this report
Non-image files attached to this report
Comments related to this report
jeffrey.kissel@LIGO.ORG - 15:41, Friday 25 September 2015 (21950)
Maddie has confirmed that she has used the matlab model parameter par.t.actuation to inform the high-frequency and time-delay corrections to the output of the CAL-CS pipeline.

This confirms that there is a systematic error in the output of the GDS pipeline output at both observatories -- an extra IOP (65 [kHz]) clock cycle, 15 [us] delay on the actuation path, which results in a ~0.5 [deg] phase mismatch between the reconstructed and true actuation and sensing paths at 100 [Hz]. This is small effect, but given our dwindling person-power, and continued pressure to have been done yesterday, we will not quantitatively assess the impact this has on systematic errors. We will instead, merely update the GDS pipeline to use the correct actuation delay (hopefully next Tuesday), and use that as our stopping point for when we stop re-calibrating prior data.

 
Displaying reports 61601-61620 of 82999.Go to page Start 3077 3078 3079 3080 3081 3082 3083 3084 3085 End