Displaying reports 51741-51760 of 83224.Go to page Start 2584 2585 2586 2587 2588 2589 2590 2591 2592 End
Reports until 10:49, Thursday 08 December 2016
H1 General
jeffrey.bartlett@LIGO.ORG - posted 10:49, Thursday 08 December 2016 (32362)
IFO Down - Earthquake Activity

After things started to settle down from the California eaethquake, we were hit by another mag 7.8 earthquake in the Solomon Islands. Put the SEI_CONF to LARGE_EQ_NOBRSXY. All ISI and several SUS have tripped many times. Microseism is over 300um/s.

IFO in down while we ride through the rumbling earth.  

H1 General
jeffrey.bartlett@LIGO.ORG - posted 08:43, Thursday 08 December 2016 (32359)
Ops Day Shift Transition

Ops Shift Transition: 12/08/2016, Day Shift 16:00 – 00:00 (08:00 - 16:00) -  UTC (PT)

State of H1: IFO unlocked due to earthquake in California.
Intent Bit: Environment
Weather: Wind is a Gentle to Moderate Breeze (4- 12mph), cold and clear, snow expected
Primary 0.03 – 0.1Hz: Currently at 0.7um/s 
Secondary 0.1 – 0.3Hz: Currently at 0.5um/s
Quick Summary: IFO is unlocked due to Mag 6.8 earthquake in California. When the microseism clams down a bit more will start to relock.  
Outgoing Operator: TJ
LHO General
thomas.shaffer@LIGO.ORG - posted 08:07, Thursday 08 December 2016 (32347)
Ops Owl Shift Summary

TITLE: 12/08 Owl Shift: 08:00-16:00 UTC (00:00-08:00 PST), all times posted in UTC
STATE of H1: Earthquake
INCOMING OPERATOR: Jeff
SHIFT SUMMARY: I had a few locklosses due to PIs, but I eventually wrangled them and got it locked for almost 2 hours before a 6.5M earthquake off of California knocked us out.
LOG:

LHO General
thomas.shaffer@LIGO.ORG - posted 06:56, Thursday 08 December 2016 - last comment - 06:58, Thursday 08 December 2016(32357)
Lockloss @ 14:52

A very nearby earthquake just tripped basically everything. It hasn't shown up on USGS yet, but the BLRMS are off the displays.

Comments related to this report
thomas.shaffer@LIGO.ORG - 06:58, Thursday 08 December 2016 (32358)
H1 SUS
thomas.shaffer@LIGO.ORG - posted 05:15, Thursday 08 December 2016 - last comment - 15:31, Friday 09 December 2016(32354)
PI slightly rung up modes that we are not damping

It seems like there are some PI modes that we are no longer damping that are slightly run up according to the dtt. I also wonder if the peaks at around 13000hz are modes that we had not had issues with before, or maybe something else entirely? I don't see any mention of them on the PI medm and they are currently the highest. I will try to damp some of the other ones if they get any higher.

The attached shows the PI dtt just after reaching low noise.

Images attached to this report
Comments related to this report
thomas.shaffer@LIGO.ORG - 06:01, Thursday 08 December 2016 (32356)

Well I think things are stable now. I ended up flipping the sign for the both the phase and gain on mode 27. Mode 26 also came up and changing the phase got it to, very slowly, go down. I took some screen shots of the dtt template at 20min, 26min, and 32min into the lock. The modes that the Striptools said were ringing up, didnt necessarily agree with the dtt. I dont remember how much the modes can shift in frequency, but it seems like some of them were off by a couple of hz. 

Images attached to this comment
terra.hardwick@LIGO.ORG - 11:58, Thursday 08 December 2016 (32364)OpsInfo

A couple things:

  • I'm not sure what you're referencing that seems 'a couple Hz off', could you elaborate? I checked the band pass filters against the frequency of the peaks at the times you listed and the most I found was Mode28 was off by 1 Hz. I have since changed the BP filter to account for this shift. 
  • Remember that if a peak's frequency in DTT is different than the bandpass filter frequency, you should switch to a different band pass. There are explicit directions in the PI Wiki (which you can open from the PI medm screen and which I just updated to make more clear) and I've walked through this process individually with each operator. If something is still unclear, you can always still call me at anytime (number on the whiteboard). This shouldn't be much of an issue these days but is worth checking if you're having damping problems.
  • Modes 27 and 29 have to be carefully watched during the first hour of lock. These have been successfully damped for weeks now but must be reacted to immediately. 
  • Again, if you lose lock from a PI, you must wait in DC readout to give that mode time to ring down. You can watch the ringdown in DTT. If you try locking again, the mode will still be rung up.
  • There are some modes that always have higher amp, such as the 13kHz modes TJ noted, that are not unstable - TJ that DTT from low noise you first posted is totally normal. You can always look at a reference from an eariler stable lock time to compare the amplitudes. I will add a good reference to the PI DTT in the background so it's easy to see what's 'good'
  • Regarding DTT and StripTool not seeming to match - we use different error signals for different modes, while the DTT is just looking at one of those signals. The result is that Modes 27,28 look very rung up on the StripTool but their peaks in the DTT dont look so high. This is done on purpose, because those modes need to be damped faster. 

Please any operator contact me at any time if help/explanations/etc is needed.

thomas.shaffer@LIGO.ORG - 15:31, Friday 09 December 2016 (32401)

For the couple hz off thing, I was mainly refering to the frequencies listed on the medm above the modes. I'm not sure how accurate these are suppose to be, but like mode 27 says 18041, and the dtt was saying that 18038 seemed to be more rung up (see second attached). I didn't remember how much they shifted, and I did not look at the actual filters themselves at the time.

I was able to make it work (on the second try) with just changing phase and gain so I didn't look into it too much after that. But, yes, following your instructions and changing the BP would have been next on the list.

In alog32385 you mention that you will put a reference trace to show what is normal and what is not. I would love this because I looked at the dtt picture that is on the wiki and saw that it was much different. Either way, it was a good learnign process for me since I have only ever had to change phases for PI modes.

H1 General
thomas.shaffer@LIGO.ORG - posted 03:11, Thursday 08 December 2016 - last comment - 05:10, Thursday 08 December 2016(32350)
Lockloss @ 11:07

PI mode 27. I damped mode 28 then, thinking that I defeated it, went to get a cup of water. When I returned, mode 27 was quickly rising and I got it to level out but couldn't damp it before it broke.

Comments related to this report
thomas.shaffer@LIGO.ORG - 03:46, Thursday 08 December 2016 (32351)

Back to Observing at 11:45

thomas.shaffer@LIGO.ORG - 04:13, Thursday 08 December 2016 (32352)

Another lockloss at 12:10 due to PI mode 27. I couldn't seem to get it to go down. I could get it to almost level out, but never bring it down. I did not try changing the gain, I will next time.

thomas.shaffer@LIGO.ORG - 05:10, Thursday 08 December 2016 (32353)

Observing again at 13:07. Range says 79Mpc!

H1 General
thomas.shaffer@LIGO.ORG - posted 02:12, Thursday 08 December 2016 - last comment - 02:45, Thursday 08 December 2016(32348)
Lockloss @09:54

It was very sudden. There was no indication form any of the FOMs that anything was, and the environment looks good. There may be the smallest bump on the BLRMS, but nothing that ever should have dropped it. SR3 lockloss template attached, doesn't seem to be the cause (I zoomed in this time unlike before). Also attached the generic lockloss plots, which I can't tell if any of it is out of the norm. Myabe MICH was a bit more active a few seconds before it dropped, but it does sometimes seem to do that normally.

IMC is having trouble staying locked, I should stop writing here and get back to that.

Images attached to this report
Comments related to this report
thomas.shaffer@LIGO.ORG - 02:45, Thursday 08 December 2016 (32349)

Back to Observing @ 10:45

LHO General
thomas.shaffer@LIGO.ORG - posted 00:06, Thursday 08 December 2016 (32346)
Ops Owl Shift Transition

TITLE: 12/08 Owl Shift: 08:00-16:00 UTC (00:00-08:00 PST), all times posted in UTC
STATE of H1: Observing at 75.5915Mpc
OUTGOING OPERATOR: Travis
CURRENT ENVIRONMENT:
    Wind: 11mph Gusts, 7mph 5min avg
    Primary useism: 0.04 μm/s
    Secondary useism: 0.24 μm/s
QUICK SUMMARY: Travis delivers a locked IFO again after recovering from an earthquake in China. LLO is currently down. Snow expected in the morning sp be safe driving in.

H1 General
travis.sadecki@LIGO.ORG - posted 00:01, Thursday 08 December 2016 (32345)
Ops Eve Shift Summary

TITLE: 12/08 Eve Shift: 00:00-08:00 UTC (16:00-00:00 PST), all times posted in UTC
STATE of H1: Observing at 78.082Mpc
INCOMING OPERATOR: TJ
SHIFT SUMMARY:  Locked for most of the shift with ~1.5 hour downtime due to EQ.
LOG:

See previous logs for pertinent events.

 

H1 CAL (DetChar, OpsInfo)
jeffrey.kissel@LIGO.ORG - posted 11:02, Wednesday 07 December 2016 - last comment - 09:14, Thursday 22 December 2016(32307)
PCALX Roaming Calibration Line Frequency Changed to 4001.3 to 4301.3 Hz
J. Kissel for S. Karki
WP #6368

I've moved the PCALX roaming line, its long duration sweep, from 4001.3 Hz to 4301.3 Hz. See schedule status below.

Since it looks like we'll have the duty cycle to just finish the schedule within a week, I'm just going to continue to re-gathering the highest frequency data. As such, Sudarshan has something consistent and straightforward with which to work instead of data with a bunch details or qualifications. 


Frequency    Planned Amplitude        Planned Duration      Actual Amplitude    Start Time                 Stop Time                    Achieved Duration
(Hz)         (ct)                     (hh:mm)                   (ct)               (UTC)                    (UTC)                         (hh:mm)
---------------------------------------------------------------------------------------------------------------------------------------------------------
1001.3       35k                      02:00                   39322.0           Nov 28 2016 17:20:44 UTC  Nov 30 2016 17:16:00 UTC         days    @ 30 W  
1501.3       35k                      02:00                   39322.0           Nov 30 2016 17:27:00 UTC  Nov 30 2016 19:36:00 UTC         02:09   @ 30 W         
2001.3       35k                      02:00                   39322.0           Nov 30 2016 19:36:00 UTC  Nov 30 2016 22:07:00 UTC         02:31   @ 30 W
2501.3       35k                      05:00                   39322.0           Nov 30 2016 22:08:00 UTC  Dec 02 2016 20:16:00 UTC         days    @ 30 W
3001.3       35k                      05:00                   39322.0           Dec 02 2016 20:17:00 UTC  Dec 05 2016 16:58:57 UTC         days    @ 30 W
3501.3       35k                      05:00                   39322.0           Dec 05 2016 16:58:57 UTC  Dec 06 2016 21:09:56 UTC         ~15:00  @ 30 W
4001.3       40k                      10:00                   39322.0           Dec 06 2016 21:09:56 UTC  Dec 07 2016 18:50:09 UTC         ~20:00  @ 30 W
4301.3       40k                      10:00                   39322.0           Dec 07 2016 18:50:09 UTC
4501.3       40k                      10:00                   39322.0           
4801.3       40k                      10:00                   39222.0           
5001.3       40k                      10:00                   39222.0         

Frequency    Planned Amplitude        Planned Duration      Actual Amplitude    Start Time                 Stop Time                    Achieved Duration
(Hz)         (ct)                     (hh:mm)                   (ct)               (UTC)                    (UTC)                         (hh:mm)
---------------------------------------------------------------------------------------------------------------------------------------------------------
1001.3       35k                      02:00                   39322.0           Nov 11 2016 21:37:50 UTC    Nov 12 2016 03:28:21 UTC      ~several hours @ 25 W
1501.3       35k                      02:00                   39322.0           Oct 24 2016 15:26:57 UTC    Oct 31 2016 15:44:29 UTC      ~week @ 25 W
2001.3       35k                      02:00                   39322.0           Oct 17 2016 21:22:03 UTC    Oct 24 2016 15:26:57 UTC      several days (at both 50W and 25 W)
2501.3       35k                      05:00                   39322.0           Oct 12 2016 03:20:41 UTC    Oct 17 2016 21:22:03 UTC      days     @ 50 W
3001.3       35k                      05:00                   39322.0           Oct 06 2016 18:39:26 UTC    Oct 12 2016 03:20:41 UTC      days     @ 50 W
3501.3       35k                      05:00                   39322.0           Jul 06 2016 18:56:13 UTC    Oct 06 2016 18:39:26 UTC      months   @ 50 W
4001.3       40k                      10:00                   39322.0           Nov 12 2016 03:28:21 UTC    Nov 16 2016 22:17:29 UTC      days     @ 30 W (see LHO aLOG 31546 for caveats)
4301.3       40k                      10:00                   39322.0           Nov 16 2016 22:17:29 UTC    Nov 18 2016 17:08:49 UTC      days     @ 30 W          
4501.3       40k                      10:00                   39322.0           Nov 18 2016 17:08:49 UTC    Nov 20 2016 16:54:32 UTC      days     @ 30 W (see LHO aLOG 31610 for caveats)   
4801.3       40k                      10:00                   39222.0           Nov 20 2016 16:54:32 UTC    Nov 22 2016 23:56:06 UTC      days     @ 30 W
5001.3       40k                      10:00                   39222.0           Nov 22 2016 23:56:06 UTC    Nov 28 2016 17:20:44 UTC      days     @ 30 W (line was OFF and ON for Hardware INJ)  
Images attached to this report
Comments related to this report
jeffrey.kissel@LIGO.ORG - 09:05, Thursday 08 December 2016 (32360)
Note, PCALX was briefly turned OFF during this 4301.3 Hz stretch. See LHO aLOG 32323.
sudarshan.karki@LIGO.ORG - 10:25, Tuesday 13 December 2016 (32512)

Progress on Analysis:

The Pcal to DARM ratio for these individual lines were calculated using SLM Tool and the result is tabulated below. The Cavity pole and the optical gain on the last column are eyeballed measurement from the CalMon Tool . These time dependent corrections havenot been applied to the sensing function analysis yet.

Freq      Start Time               End Time            FFT       Real       Complex       Coh       CC Pole (O. Gain)

---------------------------------------------------------------------------------------------------------------------

1001.3  30-Nov-2016 09:16:44    30-Nov-2016 13:47:04    10       0.022149   -0.358814   0.999589    346.05(0.9863)

---------------------------------------------------------------------------------------------------------------------

1501.3  30-Nov-2016 17:28:11    30-Nov-2016 19:36:18    10      -0.017951   -0.109817   0.999943    346.05(0.9863)

---------------------------------------------------------------------------------------------------------------------

2001.3  30-Nov-2016 19:36:53    30-Nov-2016 21:01:35    10      -0.015679   -0.044511   0.999391    346.05(0.9863)

---------------------------------------------------------------------------------------------------------------------

2501.3  02-Dec-2016 07:52:51    02-Dec-2016 20:16:47    30      -0.011385   -0.020594   0.998321    347.69(0.9703)

---------------------------------------------------------------------------------------------------------------------

3001.3  04-Dec-2016 02:27:58    05-Dec-2016 00:00:17    30      -0.007719   -0.010563   0.999057    347.06(0.9614)

---------------------------------------------------------------------------------------------------------------------

3501.3  06-Dec-2016 02:27:26    06-Dec-2016 06:10:11    30      -0.005708   -0.005431   0.988492    350.70(0.9793)

3501.3  06-Dec-2016 10:36:18    06-Dec-2016 15:03:35    30                                          350.70(0.9793)

---------------------------------------------------------------------------------------------------------------------

4001.3  12-Nov-2016 17:20:18    12-Nov-2016 20:49:17    60      -0.004374   -0.003211   0.996350    350.00(0.9966)

4001.3  12-Nov-2016 09:48:25    12-Nov-2016 16:40:53    60                                          350.00(0.9966)

---------------------------------------------------------------------------------------------------------------------

4301.3  18-Nov-2016 05:20:00    18-Nov-2016 12:44:49    60      -0.003607   -0.002212   0.985922    345.04(0.9748)

4301.3  17-Nov-2016 14:26:40    17-Nov-2016 17:20:13    60                                          347.00(0.9730)

4301.3  17-Nov-2016 08:56:40    17-Nov-2016 11:07:35    60                                          347.00(0.9730)

---------------------------------------------------------------------------------------------------------------------

4501.3  20-Nov-2016 05:00:00    20-Nov-2016 13:24:30    60      -0.003366   -0.002162   0.990728    350.76(0.9985)

4501.3  19-Nov-2016 15:40:00    19-Nov-2016 23:48:16    60                                          350.21(1.0017)

---------------------------------------------------------------------------------------------------------------------

4801.3  22-Nov-2016 07:43:20    22-Nov-2016 16:01:44    60      -0.002883   -0.001369   0.959987    346.89(0.9890)

4801.3  21-Nov-2016 15:20:00    21-Nov-2016 18:22:20    60                                          346.71(0.9979)

4801.3  21-Nov-2016 04:36:40    21-Nov-2016 09:28:48    60                                          346.71(0.9979)

---------------------------------------------------------------------------------------------------------------------

5001.3  25-Nov-2016 07:43:17    25-Nov-2016 14:52:54    60      -0.002634   -0.000904   0.973928    348.94(0.9625)

5001.3  27-Nov-2016 11:44:40    27-Nov-2016 18:04:12    60                                          345.48(0.9724)

---------------------------------------------------------------------------------------------------------------------

 
Data Files:
aligocalibration/trunk/Runs/ER10/H1/Measurements/DARMOLGTFs/HF_2016-11-12_H1_DARM_OLGTF_A_DARMIN2_B_DARMIN1_coh.txt
aligocalibration/trunk/Runs/ER10/H1/Measurements/DARMOLGTFs/HF_2016-11-12_H1_DARM_OLGTF_A_DARMIN2_B_DARMIN1_tf.txt
aligocalibration/trunk/Runs/ER10/H1/Measurements/PCAL/HF_2016-11-12_H1_PCAL2DARMTF_A_PCALYRX_B_DARMIN1_tf.txt
aligocalibration/trunk/Runs/ER10/H1/Measurements/PCAL/HF_2016-11-12_H1_PCAL2DARMTF_A_PCALYRX_B_DARMIN1_coh.txt
 
Parameter Files:
aligocalibration/trunk/Runs/ER10/H1/params/HF_2016-11-12/
 
Script:
aligocalibration/trunk/Runs/ER10/H1/Scripts/SensingFunction/compareSensingHF.m
Non-image files attached to this comment
sudarshan.karki@LIGO.ORG - 09:14, Thursday 22 December 2016 (32833)

More detailed Analysis.

Non-image files attached to this comment
H1 ISC (DetChar)
keith.riles@LIGO.ORG - posted 21:28, Tuesday 06 December 2016 - last comment - 05:48, Thursday 08 December 2016(32289)
Narrow lines in H1 ER10 data
As a benchmark against which to compare upcoming O2 data, I have compiled a list
of narrow lines seen in the H1 DARM spectrum up to 2000 Hz, using 107 hours of
ER10 FScan 30-minute SFTs. There are no big surprises relative to the lines and combs
Ansel and I have reported on previously from ER9 and later data, but below are some
observations. 

Attached figures show  selected band spectra, and a zipped attachment
contains a much larger set of bands. Also attached for reference is a plaintext list of combs, 
isolated lines, PEM-associated lines. etc. In the attached spectra, the red curve is the
ER10 data, and the black curve is the full-O1 data. The label annotations are keyed to
the height of the red curve, but in some cases, those labels refer to lines in the O1 data
that are not (yet) visible in accumulated current data. For the most part, lines seen in 
O1 that don't show up in ER10 nonetheless remain for now in the lines list and still
have labels on the graphs that end up in the red fuzz. If they fail to emerge in O2
data, they will be deleted from future line lists.

Observations:
  • As noted previously, the 8-Hz / 16-Hz combs seen in O1 are blessedly gone
  • Thanks to interventions to upgrade timing electronics firmware, the previously dominant low-frequency comb with 1-Hz spacing and 0.5-Hz offset is greatly reduced (but not eliminated)
  • Compared to O1, the non-linear upconversion around quad violin modes and harmonics is much worse in ER10, and it appears that at least some violin mode excitations are affecting the low frequency band in that one sees there a multitude of sparsely distributed doublets, triples and quadruplets of lines with a spacing of about 0.0468 Hz. Andy Lundgren pointed out that this spacing coincides closely with a beat between two 2nd-harmonic violin modes he reported on last week. If I measure / eyeball those frequencies as seen in the ER10 data set, I get 1009.4414 and 1009.4881 Hz, giving a beat of 0.0467 Hz (but with an uncertainty of a few tenths of a mHz), consistent with the explanation. Further credence comes from the proliferation of such doublets / triplets / quadruplets seen in the wings of the quad harmonics (fundamental and higher).
  • There are so many upconverted lines around the quad harmonics that I didn't bother cataloguing them in those regions on the assumption that they will go away in O2 with improved damping (but cataloguing can be revisited later, if needed).
  • With the exception of the violin mode regions, the higher frequency spectrum is generally free of narrow lines (unlike the region below 100 Hz), but one disturbing feature is the presence of non-Gaussian broad disturbances that were not visible in O1. The infamous region around 1083 Hz is one example, as is the 100-200 Hz band.
Figures: [ER10 in red and O1 in black; labels are attached to peaks in the ER10 data] Fig 1 - 0-1000 Hz Fig 2 - 1000-2000 Hz Fig 3 - 2-20 Hz Fig 4 - 20-50 Hz Fig 5 - 50-100 Hz Fig 6 - 100-200 Hz Fig 7 - 490-535 Hz Fig 8 - 1000-1000 Hz Fig 9 - 1800-1900 Hz Other attachments: * zipped file with full set of sub-band spectra * Lines list with label definitions
Images attached to this report
Non-image files attached to this report
Comments related to this report
sheila.dwyer@LIGO.ORG - 12:39, Wednesday 07 December 2016 (32311)DetChar

Here is a plot of the violin mode harmonics around 1kHz, comparing the amplitudes today to the amplitudes right after the damping efforts of Nov 30th. 

We don't actively damp these by default, only when someone manually engages damping do they get damped.   Durring the first part of ER10 ISI trips caused by tidal problems were ringing them up, but that problem is fixed now and most modes are ringing down.  ETMX modes (between 1003 and 1006Hz) have increased in amplitude since the 30th.  

The largest peak here is the pair on ETMY that Keith points out, we have settings that work to damp both of these modes using the mode9 filter bank on ETMY, and it would not be difficult to turn this damping on automatically in the guardian.  

Our question for Keith and detchar is is this (the current spectrum) good enough?  Or should we continue to try to add automatic damping for some of these modes?  

Images attached to this comment
keith.riles@LIGO.ORG - 05:48, Thursday 08 December 2016 (32355)
Automatically damping the violin modes would reduce up-conversion contamination at the starts of
lock stretches, making more data usable for CW searches. Even small excess powers in narrow bins
leads to unnecessary outliers in analysis that waste computing and manpower. Unless there is a 
downside to such damping, it seems warranted.

thanks,
Keith
H1 ISC
evan.hall@LIGO.ORG - posted 14:41, Tuesday 06 December 2016 - last comment - 11:36, Thursday 08 December 2016(32257)
CPY ghost beams on the SRM

Keita, Rana, Evan

After refocusing the HAM5 camera, we see in full lock that there are at least two ghost beams hitting the SRM composite mass. These ghost beams move when CPY (but not CPX) is moved.

The attached plots show the DARM spectrum for different CPY alignments. There is no obvious sweet spot, but perhaps we will find one by looking at some long-term DARM BLRMS.

This image shows the HAM5 camera with the nominal CPY alignment (-150 µrad in pitch, 0 µrad in yaw). The two bright, vertically aligned spots on the left-hand side are the CPY ghost beams.

Images attached to this report
Non-image files attached to this report
Comments related to this report
evan.hall@LIGO.ORG - 14:42, Tuesday 06 December 2016 (32258)

Also, the take snapshot button for camera 17 just saves blank images.

 

sheila.dwyer@LIGO.ORG - 15:23, Tuesday 06 December 2016 (32263)PEM

Here are 2 other old alogs that are relevant if you are worried about scatter from CPs:

Robert saw scattering from CPY in the PR2 camera:  31243

I saw that 6 times higher drive was needed on CPX than CPY to make noise show up in DARM, and the noise that did show up was clear fringe wrapping shelves for CPX and a broad shelf for CPY.  30979

CPY scattering seemed like it is not an immediate problem since the drive reuiqred to see noise in DARM was 100 um at the error point of the damping loop at 0.1 Hz.  I don't know the gain of the damping loop, but assume that it is not less than -20 dB at 0.1 Hz, so that we are pushing the mass at least 10 um, probably more. This should be larger than the normal path length modulation.  It would be good to look at what the gain of the damping loop actually is to see if this is really a much larger path length modulation than what we would normally expect.  

denis.martynov@LIGO.ORG - 11:36, Thursday 08 December 2016 (32365)

SRC model shows that CPY is installed parallel to HR surface of ITMY (misalignment angle of 0.07 degrees). This number gives a vertical offset of the ghost beam on SR2 of 2 cm and on SRM of 10 cm. This is how I read the camera image. One might also suggest that the plate is misaligned even further from the nominal position — by 0.14 degrees. In this case ghost beams swap and we can’t tell a difference.

H1 CAL (CAL)
craig.cahillane@LIGO.ORG - posted 17:42, Sunday 04 December 2016 - last comment - 10:25, Thursday 08 December 2016(32169)
LHO ER10 Gaussian Process Actuation Uncertainty Budget
C. Cahillane

The ER10 LHO Actuation Uncertainty Budget

What has been done:
(1) Gathering all the Newtons/count actuation function measurements for the three stages (UIM, PUM, TST) from November 8th, 9th, 11th, 12th, and 18th.  
(2) Running an MCMC over the physical parameters gain and delay for all three stages.  (Only used freq < 10 Hz for UIM, freq < 100 Hz for PUM)
(3) Plot MCMC cornerplots and resulting residuals uncertainty budget from the MCMC PDFs.  
(4) Take the residuals from the MCMC physical parameters' fit, and plug them into a Gaussian Process with kernel k(x,y) = a + b * exp(-0.5*(x-y)**2/l**2), where a, b, and l are the hyperparameters of the GP.
(5) Train the GP on the residuals, and produce a mean posterior fit and an uncertainty budget from the trained kernel.

TL:DR : Take measurements -> Physical MCMC -> Unmodeled GP -> Frequency-Dependent Systematic Error +- Uncertainty Budget

The mean posterior fit is the frequency-dependent systematic error.  The uncertainty budget is also frequency-dependent.  
The Gaussian Process results are shown in Plots 1, 2, and 3 for the UIM, PUM, and TST stages.  The 1-sigma, 68% confidence intervals are plotted.

I want to call attention to how small the uncertainty is in the bucket.
The frequency-dependent uncertainty in the bucket is on the order of 0.1%

This is exciting, but is it real?  
Points in favor:
(1) We have five sets of measurements, and uncertainty roughly goes as 1/sqrt(N) where N = measurement number.  This allows us to win a lot where the measurements are nearly the same and the errorbars are small.
(2) The GP fit hits most of the measurement errorbars.
(3) Uncertainty expands where we have less information.
Points against:
(1) Overfitting might be a problem.  There seem to be unphysical wiggles that nail our data in the bucket. 
(2) This uncertainty budget is lower than ever before by a factor of 10.  This requires extraordinary proof.   
Rebuttals:
(1) We might be able to combat overfitting by lengthening the kernel length-scale and adding more noise to our measurements.  Also, the whole point of this method is to capture unmodeled wiggles.  
(2) The data analysis methods used are more advanced and designed to handle frequency-dependence.  

Plots 4, 5, and 6 are the UIM, PUM, and TST physical model MCMC fits with the measurements.  
Plots 7, 8, and 9 are the UIM, PUM, and TST physical model MCMC parameter cornerplots.

A couple of points: 
(1) The GP uncertainty doesn't take into account the uncertainty from the MCMC physical parameters.  The GP uncertainty dominates nearly everywhere, since the MCMC uncertainty is so tiny (See plots 4, 5, 6).  I may try to incorporate the MCMC uncertainty directly into the measurement errorbars that I input into the GP.
(2) A lot remains to be done.  LLO actuation, sensing at both sites, and final response uncertainty.  
(3) If these results hold, we may have uncertainty dominated by time-dependence.  Stay tuned.
Images attached to this report
Comments related to this report
craig.cahillane@LIGO.ORG - 10:25, Thursday 08 December 2016 (32361)
C. Cahillane

I have changed the kernel the Gaussian Process runs on in order to get more realistic errorbars.

The plots for the UIM stage have a dot product kernel: k(x,y) = 1.0 + x.y + noise
The plots for the PUM and TST stage have a squared dot product kernel: k(x,y) = 1.0 + x.y + (x.y)**2 + noise

The results show a much more simplistic and physically realistic correlation between measurement points. (No more overfitting wiggles, slightly expanded uncertainty bars, no instabilities in the GP results)

Our minimum uncertainty in the TST stage in the bucket is on the order of ~0.6% and 0.3 degrees.  So still very good uncertainty.

Still to do:
(1) Remove time-dependence from the measurements by modifying the .conf files with the relevant kappas.
(2) MCMC to find physical parameters on only the reference measurement.
(3) LLO Actuation, LHO and LLO Sensing.
Images attached to this comment
Displaying reports 51741-51760 of 83224.Go to page Start 2584 2585 2586 2587 2588 2589 2590 2591 2592 End