Displaying reports 65121-65140 of 86679.Go to page Start 3253 3254 3255 3256 3257 3258 3259 3260 3261 End
Reports until 22:07, Wednesday 30 September 2015
H1 ISC
sheila.dwyer@LIGO.ORG - posted 22:07, Wednesday 30 September 2015 - last comment - 16:55, Thursday 01 October 2015(22107)
bilinear coupling of End X motion to DARM follow up

I'm posting an early version of this alog so that people can see it, but plan to edit again with the results of the second test. 

Yesterday I took a few minutes to follow up on the meausrements in alog 21869.  This time in addition to driving TMS I drove the ISI in the beam direction to reproduce the motion caused by the backreaction to TMS motion. We also breifly had a chance to move the TMSX angle while exciting L. 

The main conclusions are:

Comparison of ISI drive to TMS drive for X and Y

The attached screenshot shows the main results of the first test (driving ISIs and TMSs).  In the top right plot you can see that I got the same amount of ISI motion for 3 cases (driving ETMX ISI, TMSX, ETMY ISI) and that driving TMSY with the same amplitude as TMSX resulted in a 50% smaller motion of the ISI.  Shaking the TMS in the L direction induces a larger motion measured by the GS13s in the direction perpendicular to the beam, than in the beam direction, which was not what I expected.  I chose the drive strength to get the same motion in the beam direction, so I have not reproduced the largest motion of the ISI with this test. If there is a chance it would be interesting to also repeat this measurement reproducing the backreaction in the direction perpendicular to the beam.  

The middle panels of the first screnshot show the motion measured by OSEMs. TMS osems see about a factor of 10 more motion when the TMS is driven than when the ISI is driven.  The signal is also visible in the quad top mass osems, but not lower down the chain.  For the X end, the longitudnal motion seen by the top mass is about a factor of 2 higher when the TMS is excited than when the ISI is excited (middle left panel), which could be because I have not reproduced the full backreaction of the ISI to the TMS motion.  However, it is strange that for ETMY the top mass osem signal produced by driving TMS is almost 2 orders of magnitude larger than the motion produced by moving the ISI. It seems more likely that this is a problem of cross coupling between the osems than real mechanical coupling. The ETMY top mass osems are noisier than ETMX, as andy lundgren pointed out (20675).  It would be interesting to see a transfer function between TMS and the quad top mass to see if this is real mechanical coupling or just cross talk. 

In the bottom left panel of the first screenshot, you can compare the TMS QPD B yaw signals.  The TMS drive produces larger QPD signals than the ISI drive, as you would expect for both end stations.  My first gues would be that driving the ISI in the beam direction could cause TMS pitch, but shouldn't cause as much yaw motion of the TMS.  However, we see the ETMX ISI drive in the yaw QPDs, but not pitch.  The Y ISI drive does not show up in the QPDs at all.  

Lastly, the first plot in the first screenshot shows that the level of noise in DARM produced by driving the ETMX ISI is nearly the same as what is produced by driving TMSX.  Since the TMS motion (seen by TMS osems) is about ten times higher when driving TMS, we can conclude that this coupling is not through TMS motion but the motion of something else that is attached to the ISI. Driving ETMY ISI produces nothing in DARM but driving TMSY produces a narrow peak in DARM. 

For future reference:

I drove ETMX-ISI_ST2_ISO_X_EXC with an amplitude of 0.0283 cnts at 75 Hz from 20:07:47 to 20:10:00UTC sept 29th

I drove 2000 cnts in TMSX test L from 20:10:30 to 20:13:30UTC 

I drove ETMY-ISI_ST2_ISO_Y_EXC with an amplitude of 0.0612 cnts at 75 Hz from 20:13:40 to 20:16:30UTC 

I drove 2000 cnts in TMSY test L from 20:17:10 to 20:20:10UTC

Driving TMSX L while rastering TMS position and angle

I put a 2000 cnt drive on TMSX L from about 2:09 UTC September 30th to 2:37 when I broke the lock. We found a ghost beam that hits QPD B when TMS is misaligned by 100 urad in the positive pitch direction.  There is about 0.5% as much power in this beam as in the main beam (not accounting for the dark offset).  I got another chance to do this this afternoon, and was able to move the beam completely off of the QPDs, which did not make the noise coupling go away or reduce it much.  We can conclude then scatter off of the QPDs is not the main problem.  There were changes in the shape of the peak in DARM as TMS moved, and changes in the noise at 78 Hz (which is normally non stationary) Plots will be added tomorrow.

Speculation

There is a feature in the ETMX top mass osems (especially P and T) around 78 Hz that is vaugely in the right place to be related to the excess noise in the QPDs and DARM. Also, Jeff showed us some B&K measurements from Arnaud (7762) that might hint at a Quad cage resonance at around 78 Hz, although the measured Q looks a little low to explain the spectrum of the TMSX QPDs or the feature in DARM. One could spectulate that the motion driving the noise at 78Hz  is the quad cage resonance, but this is not very solid.  Robert and Anamaria have data from their PEM injections that might be able to shed some light on this.

Images attached to this report
Comments related to this report
sheila.dwyer@LIGO.ORG - 16:37, Thursday 01 October 2015 (22157)

The units in the attached plots are wrong, there GS13s are calibrated into nm, not meters

sheila.dwyer@LIGO.ORG - 16:55, Thursday 01 October 2015 (22159)

This morning I got the chance to do some white noise excitations on the ETMX ISI, in the X and Y directions.  The attached screenshot shows the result, which is that for ISI motion a factor of 10-100 above the normal level, for a wide range of frequencies, no noise shows up in DARM.  SO the normal level of ISI motion in the X and Y directions is not driving the noise in DARM at 78 Hz.  We could do the same test for the other ISI DOFs to eliminate them as well.

Images attached to this comment
H1 General (DetChar)
laura.nuttall@LIGO.ORG - posted 18:44, Wednesday 30 September 2015 (22132)
RF45 flag since driver swap

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...

H1 General
jeffrey.bartlett@LIGO.ORG - posted 16:16, Wednesday 30 September 2015 (22126)
Ops Day Shift Summary
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. 

 
   
H1 INJ (CAL, DetChar, INJ)
christopher.biwer@LIGO.ORG - posted 16:12, Wednesday 30 September 2015 - last comment - 19:35, Wednesday 30 September 2015(22124)
Summary of injection tests with PCAL and DARM
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.
Non-image files attached to this report
Comments related to this report
christopher.biwer@LIGO.ORG - 17:21, Wednesday 30 September 2015 (22129)DetChar, INJ
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.
sudarshan.karki@LIGO.ORG - 17:38, Wednesday 30 September 2015 (22130)CAL, INJ

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.

peter.shawhan@LIGO.ORG - 19:35, Wednesday 30 September 2015 (22133)
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.
Images attached to this comment
Non-image files attached to this comment
H1 INJ (CAL, DetChar, ISC)
jeffrey.kissel@LIGO.ORG - posted 14:18, Wednesday 30 September 2015 - last comment - 06:21, Thursday 01 October 2015(22121)
Testing PCAL as Hardware Injector
C. Biwer, J. Kissel

Taking advantange of single IFO time to run PCAL vs DARM hardware injections. More details later.
Comments related to this report
jeffrey.kissel@LIGO.ORG - 15:11, Wednesday 30 September 2015 (22122)
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.
christopher.biwer@LIGO.ORG - 15:14, Wednesday 30 September 2015 (22123)DetChar, INJ
I've attached omega scans of the PCAL and DARM injections.

All injections used the 15Hz template from aLog 21838.
Images attached to this comment
andrew.lundgren@LIGO.ORG - 17:08, Wednesday 30 September 2015 (22127)DetChar, INJ
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
peter.shawhan@LIGO.ORG - 06:21, Thursday 01 October 2015 (22143)INJ
*** Cross-reference: See alog 22124 for summary and analysis
H1 INJ
jeffrey.kissel@LIGO.ORG - posted 14:18, Wednesday 30 September 2015 (22120)
Testing PCAL as Hardware Injector
C. Biwer, J. Kissel

Taking advantange of single IFO time to run PCAL vs DARM hardware injections. More details later.
H1 AOS
miquel.oliver@LIGO.ORG - posted 14:08, Wednesday 30 September 2015 (22119)
The 50Hz glitches in DARM

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.

Images attached to this report
H1 AOS
jeffrey.kissel@LIGO.ORG - posted 13:52, Wednesday 30 September 2015 - last comment - 10:03, Wednesday 04 November 2015(22117)
Updated CAL-CS DELTAL EXTERNAL Delay Explanation Diagram
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.
Images attached to this report
Non-image files attached to this report
Comments related to this report
jeffrey.kissel@LIGO.ORG - 10:03, Wednesday 04 November 2015 (23101)
A good diagram on the timing of a hardware injection through the DARM path:
LLO aLOG 22361
H1 TCS (TCS)
aidan.brooks@LIGO.ORG - posted 13:40, Wednesday 30 September 2015 (22116)
Calculation of CO2X coupling to displacement noise

[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:

 
T1500022-v2: CO2 RIN coupling to DARM for aLIGO TCS
 
dz = 1.2E-15 m (100Hz / f) * (P / 1Watt)* RIN(f)
 
f = frequency,
P = DC power onto the CP
RIN = relative intensity noise
 
In this case, you want eqn 5 which describes the central heating intensity noise coupling.
 
The power levels currently used for the ITMs are:
 
L1X: 0.21W         L1:TCS-ITMX_CO2_LSRPWR_MTR_OUTPUT
L1Y: 0.60W         L1:TCS-ITMY_CO2_LSRPWR_MTR_OUTPUT
H1X: 0.226W      H1:TCS-ITMX_CO2_LSRPWR_MTR_OUTPUT
H1Y: 0.054W      H1:TCS-ITMY_CO2_LSRPWR_MTR_OUTPUT

For a standard RIN > DN estimate, we pulled the TCS-ITMX_CO2_ISS_IN_AC and _ISS_IN_DC from LHO overnight (last night) to calculate the RIN. For some reason, the anti-whitening filter banks are not engaged at LHO right now. However, to get the RIN, we do the following calculations to get the signals from the ISS PD referenced back to the photodiode (but in counts, not volts and assuming that counts_AC/counts_DC is approximately equivalent to intensity_AC/intensity_DC).
 
WF = abs(f./(f - i*20))*177,800   % whitening filter of ISS photodiode AC channel
counts_AC = TCS-ITMX_CO2_ISS_IN_AC_OUT_DQ / WF
DCgain = 510;
counts_DC = TCS-ITMX_CO2_ISS_IN_DC_OUT_DQ / DCgain
 
RIN = counts_AC/counts_DC
 
And then we apply this to equation 5 to get the estimated displacement noise from the CO2 laser. The results are plotted in the attached PDF.
Non-image files attached to this report
H1 AOS
robert.schofield@LIGO.ORG - posted 20:31, Tuesday 29 September 2015 - last comment - 16:42, Thursday 01 October 2015(22094)
Danger using DTT with NDS2 data on a channel whose sampling rate has changed

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

Non-image files attached to this report
Comments related to this report
keita.kawabe@LIGO.ORG - 17:24, Wednesday 30 September 2015 (22128)

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.

Images attached to this comment
jonathan.hanks@LIGO.ORG - 17:40, Wednesday 30 September 2015 (22131)

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.

jonathan.hanks@LIGO.ORG - 16:42, Thursday 01 October 2015 (22158)

As followup we have gone through two approaches to fix this:

  1. We created a proxy we put between DTT & NDS2 for Robert that was able to strip out the versions of the channels that we are not interested in. This was done yesterday and allowed Robert to work. This has allowed Robert to work but is not a scalable solution.
  2. Jim and I investigated what DTT was doing and have a test build of DTT that allows it to present a list with multiple sample rates per channel. We have a test build of this at LHO. There are rough edges to this, but we have filed a ECR to see about rolling out a solution in this vein in production (which would include LLO).
H1 PEM
jenne.driggers@LIGO.ORG - posted 16:17, Thursday 24 September 2015 - last comment - 17:03, Wednesday 30 September 2015(21905)
Newtonian noise?

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.

Non-image files attached to this report
Comments related to this report
jim.warner@LIGO.ORG - 16:23, Thursday 24 September 2015 (21912)

Adding SEI tag, so people see it.

rana.adhikari@LIGO.ORG - 17:01, Thursday 24 September 2015 (21918)

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.

jenne.driggers@LIGO.ORG - 17:53, Thursday 24 September 2015 (21923)

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. 

peter.fritschel@LIGO.ORG - 19:45, Thursday 24 September 2015 (21930)

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?

jenne.driggers@LIGO.ORG - 15:10, Wednesday 30 September 2015 (22113)

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.

Non-image files attached to this comment
jan.harms@LIGO.ORG - 12:57, Wednesday 30 September 2015 (22114)
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.
jenne.driggers@LIGO.ORG - 17:03, Wednesday 30 September 2015 (22125)

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.

Non-image files attached to this comment
H1 ISC
evan.hall@LIGO.ORG - posted 16:51, Saturday 25 July 2015 - last comment - 20:19, Wednesday 30 September 2015(19895)
REFL9Q dark noise

Summary

Attached is the dark noise of REFL9Q, along with an estimate of the shot noise and a conversion of these noises into equivalent frequency noise in CARM.

The dark noise appears to be slightly below the shot noise level.

Details

I took the TNC that goes directly into the common-mode board and put it into an SR785. Also attached is the noise with the input of the SR785 terminated.

I also have tried to estimate how this compares to the shot noise on the diode. In full lock at 24 W, we see 3.6 mW of dc light on the PD (according to the calibrated REFL_A_LF channel). Off resonance and at 2.0 W, we have 13.6 mW of dc light. So the CARM visibility is about 98%.

The shot noise ASD (in W/rtHz) and the CARM optical plant (in W/Hz) are both given in Sigg's frequency response document. With a modulation index of 0.22 rad and an incident power of 24 W, the shot noise is 9.4×10−10 W/rtHz, the CARM optical gain is 11 W/Hz, and the CARM pole is 0.36 Hz. [Edit: I was missing some HAM1 attentuation when first calculating the shot noise level. Out of lock, the amount of power on REFL A should be 24 W × 0.1 × 0.5 × 0.5 × 0.5 = 300 mW. That gives a predicted shot noise level of 7.7×10−11 W/rtHz, assuming a sideband amplitude reflectivity of 0.44. On the other hand, from the measured in-lock power we can calulate 2(hνP)1/2 = 5.2×10−11 W/rtHz for P = 3.6 mW. This includes the factor of sqrt(2) from the frequency folding but does not include the slight cyclostationary enhancement in the noise from the sidebands (although this latter effect is not enough to explain the discrepancy).] Additionally, I use Kiwamu's measurement of overall REFL9 response (4.7×106 ct/W) in order to get the conversion from optical rf beat note power into demodulated voltage (2900 V/W). These numbers are enough to convert the demodulated dark noise of REFL9Q (and the shot noise) into an equivalent frequency noise. At 1 kHz, the shot noise is about 10 nHz/rtHz; as a phase noise this is 10 prad/rtHz (which is smaller than Stefan's estimate of 80 prad/rtHz). The dark noise, meanwhile, is about 5 nHz/rtHz.

Non-image files attached to this report
Comments related to this report
evan.hall@LIGO.ORG - 17:11, Monday 27 July 2015 (19967)

Hang, Evan

We measured the input-referred voltage noise of the summing node and common-mode boards.

  • We terminated the input of the SNB that receives REFL9Q (INA2). INA1 was disabled. On the CMB, IN1 was enabled with -22 dB, and IN2 was disabled. The 40 Hz / 4 kHz boost was engaged. The fast gain was 7 dB.
  • We measured the noise at the output of the CMB fast output.
  • We then took the TF from SNB INA2 to CMB fast out. This is sufficient to get the input referred noise.

According to this estimate, the CARM loop is not shot noise limited; rather, at 1 kHz the noise is about a factor of 3 in ASD above shot noise.

Non-image files attached to this comment
evan.hall@LIGO.ORG - 10:03, Wednesday 30 September 2015 (22104)

I looked back at the CARM sensing noise data I took (on 12 Aug) using the new gain distribution: 0 dB SNB gain, −13 dB CMB common gain, 0 dB CMB fast gain, and 107 ct/ct digital MCL gain.

[For comparison, the old CARM gain distribution was 0 dB SNB gain, −20 dB CMB common gain, 7 dB CMB fast gain, and 240 ct/ct digital MCL gain.]

☞ For those looking for a message in this alog: something about the current frequency noise budgeting doesn't hang together. The projection based on the CARM sensing noise and the measured CARM-to-DARM coupling TF suggests a CARM-induced DCPD sum noise which is higher than what can be supported by coherence measurements.

☞ Second attachment: As expected, the noise (referred to the input of the SNB) is lower; at 40 Hz, it is about 350 nV/Hz1/2. However, we are not really shot-noise (or dark-noise) limited anywhere.

☞ Third attachment: I am also including the CARM-to-DARM coupling TF from a few weeks ago. This TF was taken by injecting into the CARM excitation point and measuring the response in OMC DCPD sum, using the old CARM gain distribution. Then I referred this TF to the SNB input by multiplying by the SNB gain (0 dB), the CMB common gain (−20 dB), and the CMB common boost (40 Hz pole, 4 kHz zero, ac gain of 1).

This gives a coupling which is flat at 1.0×10−2 mA/V, transitioning to 1/f2 around 250 Hz. Or, to say it in some more meaningful units:

  • Assuming a REFL9Q demodulation coefficient of 2900 V/W, this implies a flat power coupling of 3.4×10−6 mA/W above 250 Hz, rising like 1/f2 below that.
  • Assuming a CARM optical gain of 13 W/Hz and an optical pole of 0.48 Hz, this implies a 1/f frequency coupling above 250 Hz, a 1/f3 coupling below 250 Hz, and an overall magnitude of 6.2×10−5 mA/Hz at 1 kHz.
  • Stated in terms of phase coupling (Stefan's favorite), the magnitude of the CARM optical plant is 6.2 W/rad above the cavity pole, which implies a flat phase coupling of 6.2×10−2 mA/rad above 250 Hz, rising like 1/f2 below that.

☞ Synthesis of the above: based on the measurements described above, at 40 Hz we expect a coupling into the DCPD sum of 350 nV/Hz1/2 × 0.4 mA/V = 1.4×10−7 mA/Hz1/2, which is very close to the overall DCPD sum noise of 3.2×10−7 mA/Hz1/2.

But what is wrong with this picture? If 1.4/3.2 = 44 % of the DCPD sum noise comes from CARM sensing noise, we should expect a coherence of 0.442 = 0.19 between the DCPD sum and the CARM error point.

☞ First attachment: The coherence between the CARM error point and the DCPD sum is <0.01 around 40 Hz. Now, it is almost certainly the case that not all of the CARM error point noise is captured by LSC-REFL_SERVO_ERR, since this channel is picked off in the middle of the CMB rather than the end. Conservatively, if we suppose that LSC-REFL_SERVO_ERR contains only dark noise and shot noise, this amounts to 180 nV/Hz1/2 of noise at 40 Hz referred to the SNB error point, or 0.72×10−7 mA/Hz1/2 referred to the DCPD sum. This would imply a coherence of 0.05 or so.

☞ What is going on here?: Four possibilities I can think of are:

  • I've overestimated the sensing noise.
  • I've overestimated the CARM-to-DARM coupling TF.
  • I've made an algebra mistake somewhere.
  • LSC-REFL_SERVO_ERR is corrupted by noise that is not in the CARM loop.

☞ A word about noise budgeting: In my noise budget, there was a bug in my interpolating code for the CARM-to-DARM TF, making the projection too low below 100 Hz. With the corrected TF, the projected CARM noise is much higher and begins to explain the mystery noise from 30 to 150 Hz. However, given that the above measurements don't really hang together, this is highly speculative.

Images attached to this comment
Non-image files attached to this comment
evan.hall@LIGO.ORG - 20:19, Wednesday 30 September 2015 (22134)

According to the CMB schematic and the vertex cable layout, the CARM error point monitor goes through some unity-gain op-amps and then directly into the ADC. So I don't think we have much chance of seeing the 180 nV/Hz1/2 of shot/dark noise above the 4 µV/Hz1/2 of the ADC.

According to the CMB schematic and the vertex cable layout, the CARM error point monitor goes a gain of 200 V/V and then directly into the ADC. So the 180 nV/Hz1/2 of shot/dark noise appears as 36 µV/Hz1/2 at the ADC. But as Daniel pointed out, this should be heavily suppressed by the loop. For comparison, the ADC's voltage noise is 4 µV/Hz1/2.

For the sake of curiosity, I'm attaching the latest noise budget with the corrected CARM-to-DARM coupling TF. However, I note again that this level of frequency noise coupling is not supported by the required amount of coherence in any of our digitally acquired channels. Additionally, this level of frequency noise coupling is not seen at Livingston, although they've done a better job of TCS tuning than we have. I would not be surprised to find out that this coupling is somehow an overestimate.

Non-image files attached to this comment
Displaying reports 65121-65140 of 86679.Go to page Start 3253 3254 3255 3256 3257 3258 3259 3260 3261 End