For the last UTC day (30th Sept 00:00 UTC - 1st Oct 00:00 UTC) the RF45 flag only removed 60 seconds of science data. Since the swap it has only marked 180 seconds of time. This could mean things are better or I need to retrain the flag since the swap, investigating...
Activity Log: All Times in UTC (PT)
15:00 (08:00) Take over from TJ
15:15 (08:15) Jodi – Driving to Sea Container to put things in storage
15:33 (08:33) Jodi – Finished at Sea Container
15:40 (08:40) Richard – Going into Garbing room
17:15 (10:15) LLO called – They are dropping out of Observing to make some improvements
17:43 (10:43) Set Intent bit to Commissioning – LLO is down Keita going into CRE to work on 45Mhz
17:47 (10:47) Lockloss – Possible EQ activity NOTE: Keita did not make into CRE before lockloss
18:17 (11:17) IFO locked at NOMINAL_LOW_NOISE, 22.5W, 61Mpc
18:18 (11:18) Set the Intent bit to Observing
18:23 (11:23) Set Intent bit to Commissioning
18:23 (11:23) Sheila – Running some measurements while LLO is recovering from Lockloss
18:36 (11:36) Karen – Swifting in the Mechanical building
18:55 (11:55) Karen - Finished in Mechanical building
19:41 (12:41) Set the Intent bit back to Observing
21:05 (14:05) Filiberto & Manny – Going to Mid-Y to recover parts
21:14 (14:14) Set Intent bit to Commissioning – Jeff K running hardware injections
22:20 (15:20) Lockloss – Unknown
22:48 (15:48) IFO locked at NOMINAL_LOW_NOISE, 22.4W, 70Mpc
22:51 (15:51) Set Intent bit to Observing
23:00 (16:00) Handoff to Travis
End of Shift Summary:
Title: 09/30/2015, Day Shift 15:00 – 23:00 (08:00 – 16:00) All times in UTC (PT)
Support: Sheila, Dave B.
Incoming Operator: Travis
Shift Summary:
- 15:00 IFO locked. Intent Bit = Observing Mode. Wind is calm, no seismic activity. All appears normal.
- 17:25 (10:25) 5.1 mag EQ in Mexico – Lost lock at 17:47 (10:47).
-18:00 (11:00) Keita working on 45Mhz modulator during lockloss/recovery.
-18:23 (11:23) Set Intent bit to Commissioning – Jeff K & Sheila running measurements while LLO is down.
There were two lockloss events today. The IFO recovered and relocked without much difficulty. The range has been good and environmental conditions were quiet (except for the EQ in Mexico) all day.
J. Kissel, C. Biwer, S. Karki We tested using PCAL as a hardware injector. We did 3 injections into the traditional H1:CAL-INJ_TRANSINET_EXC used for hardware injections in the past and 3 into H1:PCALX_SWEPT_SINE_EXC to test using PCAL for hardware injections. All injections used the 15Hz test waveform from aLog 21838. The first injection into H1:CAL-INJ_TRANSINET_EXC was successful. The command line was: awgstream H1:CAL-INJ_TRANSIENT_EXC 16384 coherenttest1from15hz_1126257408.out 1.0 -d -d >> 2015-09-30_PCALInjTest_DARMCTRLEXC.txt We then tried an injection into H1:PCALX_SWEPT_SINE_EXC but it was unsuccessful because the injection channel list for the hinj account was restricted and did not include this channel. The command line was: awgstream H1:CAL-PCALX_SWEPT_SINE_EXC 16384 coherenttest1from15hz_1126257408.out 1.0 -d -d >> 2015-09-30_PCALInjTest_PCALINJ.txt D. Barker added H1:PCALX_SWEPT_SINE_EXC to the allowed excitation channels list for the hinj account and we had a successful set of injections: awgstream H1:CAL-PCALX_SWEPT_SINE_EXC 16384 coherenttest1from15hz_1126257408.out 1.0 -d -d >> 2015-09-30_PCALInjTest_PCALINJ.txt awgstream H1:CAL-PCALX_SWEPT_SINE_EXC 16384 coherenttest1from15hz_1126257408.out 1.0 -d -d >> 2015-09-30_PCALInjTest_PCALINJ_Trial2.txt awgstream H1:CAL-PCALX_SWEPT_SINE_EXC 16384 coherenttest1from15hz_1126257408.out 1.0 -d -d >> 2015-09-30_PCALInjTest_PCALINJ_Trial3.txt awgstream H1:CAL-INJ_TRANSIENT_EXC 16384 coherenttest1from15hz_1126257408.out 1.0 -d -d >> 2015-09-30_PCALInjTest_DARMCTRLEXC_Trial2.txt We then tried another injection but NDS happened to fail as we tried the injection and the injection was unsuccessful: awgstream H1:CAL-INJ_TRANSIENT_EXC 16384 coherenttest1from15hz_1126257408.out 1.0 -d -d >> 2015-09-30_PCALInjTest_DARMCTRLEXC_Trial3.txt The problem was quickly fixed and we set up to retry the injection. It was successful: awgstream H1:CAL-INJ_TRANSIENT_EXC 16384 coherenttest1from15hz_1126257408.out 1.0 -d -d >> 2015-09-30_PCALInjTest_DARMCTRLEXC_Trial4.txt The logs are attached. The end times of the injections should be: DARM 1 1127683334.985681295 PCAL 1 1127683905.985681295 PCAL 2 1127684170.985681295 PCAL 3 1127684464.985681295 DARM 2 1127684765.985681295 DARM 3 1127685142.985681295 As we were doing the injections we made omega scans, they can be found in aLog 22123.
I've recovered the injections by match filtering using the injection template. Label GPS time SNR chi-squared newSNR DARM1 1127683334.986 17.99 24.70 17.99 DARM2 1127685142.986 17.97 33.40 17.46 DARM3 1127685142.986 17.04 23.94 17.04 PCAL1 1127683905.986 9.61 44.27 8.48 PCAL2 1127684170.985 10.10 41.44 9.14 PCAL3 1127684464,986 10.54 73.52 7.48 It looks like PCAL injections were a bit quieter in SNR.
I see a factor of two missing in my transfer function measurement as well in the same direction that would produce low SNR through Pcal. Some clues but investigation ongoing.
The PCAL injections (numbers 2,3,4 in the set of 6) appear to be inverted, besides being too small by close to a factor of 2 -- see the attached plots. The ESD injections look rather good by comparison.
C. Biwer, J. Kissel Taking advantange of single IFO time to run PCAL vs DARM hardware injections. More details later.
PCAL Injection tests complete. PCAL X has been restored to nominal configuration. Injection Approx End time (GPS) DARM 1 1127683335 PCAL 1 1127683906 PCAL 2 1127684171 PCAL 3 1127684465 DARM 2 1127684766 DARM 3 1127685143 More details and analysis to come. These were run from the hwinjection machine as hinj. Usual DARM Command awgstream H1:CAL-INJ_TRANSIENT_EXC 16384 coherenttest1from15hz_1126257408.out 1.0 -d -d PCAL Command: awgstream H1:CAL-PCALX_SWEPT_SINE_EXC 16384 coherenttest1from15hz_1126257408.out 1.0 -d -d We turned OFF the 3 [kHz] PCAL line during the excitation. We're holding off on observation mode to confir about other single IFO tests we can do while L1 is down.
I've attached omega scans of the PCAL and DARM injections. All injections used the 15Hz template from aLog 21838.
The SNRs of the Pcal injections seem a bit lower than intended. Omega reports SNR 10.5 for the injection through the normal path, which is about right. But for the Pcal injections, the SNRs are 5.5, 7.6, and 7.2. Note that these are the SNRs in CAL-DELTAL; someone should check in GDS strain as well. Links to scans below: Standard path Pcal 1 Pcal 1 Pcal 1
*** Cross-reference: See alog 22124 for summary and analysis
C. Biwer, J. Kissel Taking advantange of single IFO time to run PCAL vs DARM hardware injections. More details later.
Tuesday 29 September 2015 John and Gately replaced the vibration isolators on end instrument air compressors. So here I follow up the correlation between the glitches and the EX_SEIS_VEA_FLOOR_[X,Y,Z]_DQ commented by Joshua (21470). I have analyzed data from the 09/29 10.00 UTC before the repair and the glitches are totally visible. The data after the repair 09/30 10.00 UTC shows no trace of the glitches. I attach two images to show these.
Now that we've cleaned up all of our systematics from the DARM model and released the O1 version (see LHO aLOG 22056, I've updated the diagram that explains how the actuation path clock cycle delay is derived, and also shows that the current value of 7 [clock cycles] or 427.3 [us] that was recently installed at both sites (LHO aLOG 21788) still does a fine job at approximating the total delay between the inverse sensing and actuation chains.
A good diagram on the timing of a hardware injection through the DARM path: LLO aLOG 22361
[Aidan, Alastair]
We ran a calculation of the coupling of intensity noise to displacement noise for the CO2X laser at LHO. The details are as follows:
"The absolute coupling is very low right now due to the small amount of power being used to heat the test masses. The transfer function has not been directly measured but we have an estimate for it in the following document:
One lock loss today due to an earthquake in Mexico. LLO also lost lock around the same time. The IFO recovered and relocked with relative ease. We have been locked at NOMINAL_LOW_NOISE for the past 2.25 hours. The Intent Bit was set to commissioning from 18:23 to 19:41 while Sheila was running some tests. The Intent Bit was set back to Observing at 19:41 (12:41)
When DTT gets data from NDS2, it apparently gets the wrong sample rate if the sample rate has changed. The plot shows the result. Notice that the 60 Hz magnetic peak appears at 30 Hz in the NDS2 data displayed with DTT. This is because the sample rate was changed from 4 to 8k last February. Keita pointed out discrepancies between his periscope data and Peter F's. The plot shows that the periscope signal, whose rate was also changed, has the same problem, which may explain the discrepancy if one person was looking at NDS and the other at NDS2. The plot shows data from the CIT NDS2. Anamaria tried this comparison for the LLO data and the LLO NDS2 and found the same type of problem. But the LHO NDS2 just crashes with a Test timed-out message.
Robert, Anamaria, Dave, Jonathan
It can be a factor of 8 (or 2 or 4 or 16) using DTT with NDS2 (Robert, Keita)
In the attached, the top panel shows the LLO PEM channel pulled off of CIT NDS2 server, and at the bottom is the same channel from LLO NDS2 server, both from the exact same time. LLO server result happens to be correct, but the frequency axis of CIT result is a factor of 8 too small while Y axis of the CIT result is a factor of sqrt(8) too large.
Jonathan explained this to me:
keita.kawabe@opsws7:~ 0$ nds_query -l -n nds.ligo.caltech.edu L1:PEM-CS_ACC_PSL_PERISCOPE_X_DQ
Number of channels received = 2
Channel Rate chan_type
L1:PEM-CS_ACC_PSL_PERISCOPE_X_DQ 2048 raw real_4
L1:PEM-CS_ACC_PSL_PERISCOPE_X_DQ 16384 raw real_4
keita.kawabe@opsws7:~ 0$ nds_query -l -n nds.ligo-la.caltech.edu L1:PEM-CS_ACC_PSL_PERISCOPE_X_DQ
Number of channels received = 3
Channel Rate chan_type
L1:PEM-CS_ACC_PSL_PERISCOPE_X_DQ 16384 online real_4
L1:PEM-CS_ACC_PSL_PERISCOPE_X_DQ 2048 raw real_4
L1:PEM-CS_ACC_PSL_PERISCOPE_X_DQ 16384 raw real_4
As you can see, both at CIT and LLO the raw channel sampling rate was changed from 2048Hz to 16384Hz, and raw is the only thing available at CIT. However, at LLO, there's also "online" channel type available at 16k, which is listed prior to "raw".
Jonathan told me that DTT probably takes the sampling rate number in the first one in the channel list regardless of the actual epoch each sampling rate was used. In this case dtt takes 2048Hz from CIT but 16384Hz from LLO, but obtains the 16kHz data. If that's true there is a frequency scaling of 1/8 as well as the amplitude scaling of sqrt(8) for the CIT result.
FYI, for the corresponding H1 channel in CIT and LHO NDS2 server, you'll get this:
keita.kawabe@opsws7:~ 0$ nds_query -l -n nds.ligo.caltech.edu H1:PEM-CS_ACC_PSL_PERISCOPE_X_DQ
Number of channels received = 2
Channel Rate chan_type
H1:PEM-CS_ACC_PSL_PERISCOPE_X_DQ 8192 raw real_4
H1:PEM-CS_ACC_PSL_PERISCOPE_X_DQ 16384 raw real_4
keita.kawabe@opsws7:~ 0$ nds_query -l -n nds.ligo-wa.caltech.edu H1:PEM-CS_ACC_PSL_PERISCOPE_X_DQ
Number of channels received = 3
Channel Rate chan_type
H1:PEM-CS_ACC_PSL_PERISCOPE_X_DQ 16384 online real_4
H1:PEM-CS_ACC_PSL_PERISCOPE_X_DQ 8192 raw real_4
H1:PEM-CS_ACC_PSL_PERISCOPE_X_DQ 16384 raw real_4
In this case, the data from LHO happens to be good, but CIT frequency is a factor of 2 too small and magnitude a factor of sqrt(2) too large.
Part of this that DTT does not handle the case of a channel changing sample rate over time.
DTT retreives a channel list from NDS2 that includes all the channels with sample rates, it takes the first entry for each channel name and ignores any following entries in the list with different sample rates. It uses the first sample rate it receives ans the sample rate for the channel at all possible times. So when it retreives data it may be 8k data, but it looks at it as 4k data and interprets the data wrong.
I worked up a band-aid that inserts a layer between DTT and NDS2 and essentially makes it ignore specified channel/sample rate combinations. This has let Robert do some work. We are not sure how this scales and are investigating a fix to DTT.
As followup we have gone through two approaches to fix this:
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.
Adding SEI tag, so people see it.
Is the STS signal calibrated correctly above 30 Hz or are you just assuming its a flat velocity sensor?
If its really close, you should be able to add the seismic data streams with the right signs and then take the coherence between this pseudo-channel and DARM and see something more than we expect by just the seismic model estimates.
Hmmm, good point Rana. I should have thought of that - it looks like the STS calibration doesn't compensate for the roll-off, so I'll put that in, and redo the traces.
Jenne, The estimate you're getting in the 15-20 Hz region is an order of magnitude or more higher than the estimate made by Jan Harms for L1, found in T1500284.
Can you post the ground noise spectra you are using so we can compare with what Jan used for L1?
The originally posted NN estimate spectra is totally wrong. I forgot to take the sqrt of the seismic spectra after pwelching, before calibrating to meters.
This corrected plot is much more consistent with Jan's estimates from T1500284.
EDIT, 3:15pm: Calibration was missing a factor of 2*pi. Plot has been updated.
Great. I like consistent results. Another remark; seismic displacement measured at a test mass has vanishing correlation with its NN. This is true at least for seismic surface fields. So if you want to proceed with correlation measurements, then the pseudo-channel needs to be constructed from an array of seismometers, with non of these seismometers being located at the test mass.
Here I include a version of the Newtonian noise estimate plot, with the GWINC estimate of aLIGO's sensitivity, in addition to the current LHO sensitivity.
The trace "GWINC with NN term" is just the regular output of Gwinc, assuming no Newtonian noise cancellation. The trace "GWINC no NN term" is all terms in gwinc except for the Newtonian noise. In particular, recall that the Gwinc NN term is not identical to the NN estimate I plot here.
The point here is to show that, although at our current sensitivity we are not limited by Newtonian noise, if we can eliminate the LSC and ASC control noise terms from our latest noise budget (aLog 21162), we likely will be.
EDIT: a further version of this plot now includes the GWINC NN curve.
