Displaying reports 35621-35640 of 89220.Go to page Start 1778 1779 1780 1781 1782 1783 1784 1785 1786 End
Reports until 16:16, Thursday 20 February 2020
LHO General
thomas.shaffer@LIGO.ORG - posted 16:16, Thursday 20 February 2020 - last comment - 16:29, Thursday 20 February 2020(55208)
Ops Eve Shift Transition

TITLE: 02/21 Eve Shift: 00:00-08:00 UTC (16:00-00:00 PST), all times posted in UTC
STATE of H1: Lock Acquisition
OUTGOING OPERATOR: Jeff
CURRENT ENVIRONMENT:
    SEI_CONF state: WINDY
    Wind: 5mph Gusts, 3mph 5min avg
    Primary useism: 0.02 μm/s
    Secondary useism: 0.29 μm/s
QUICK SUMMARY: Relocking, but it is looking hopeful. Still no intervention.

Comments related to this report
thomas.shaffer@LIGO.ORG - 16:29, Thursday 20 February 2020 (55211)
Link

Observing 0027 UTC

One SDF diff from commissioning earlier.

Images attached to this comment
H1 General
jeffrey.bartlett@LIGO.ORG - posted 16:07, Thursday 20 February 2020 - last comment - 09:49, Friday 21 February 2020(55206)
Ops Day Shift Summary
Ops Shift Log: 02/20/2020, Day Shift 16:00 – 00:00 (08:00 - 16:00) Time - UTC (PT)
State of H1: Unlocked  
Intent Bit: Locking
Support: N/A
Incoming Operator: Jenne, Sheila
Shift Summary: IFO is recovering from a lock loss. Have not had to intervene, but have lost lock at various places after DRMI_1F.  
 
Activity Log: Time - UTC (PT)
08:00 (00:00) Take over from Jim
17:54 (09:54) Damped ETM-X Mode 13 – Changed gain from 0 to 15
17:57 (09:57) Drop out of Observing due to TCS-X laser glitch
18:00 (10:00) Turn over IFO to Jenne & Sheila for commissioning
18:05 (10:05) Vanessa – Cleaning at Mid-X
18:31 (10:31) Set ETM-X Mode 13 gain back to 0
                       Mode had damped from 5.5 to 0.39
19:12 (11:12) Switch to EARTHQUAKE mode for incoming mag 5.9 from Russia
19:21 (11:21) Lock Loss – Earthquake from Russia
19:42 (11:42) Sheila – Going into LVEA to tweak the ALS DIFF Beat note
20:00 (12:00) Two tours through control room
20:02 (12:02) Sheila – Out of the LVEA
20:15 (12:15) Chandra – Escorting Praxair vacuum repair tech to CP1
20:58 (12:58) Niko – Going into the Optics Lab
21:29 (13:29) Lock loss - Unknown
21:41 (13:41) Praxair finished and off site
22:07 (14:07) Relocked at NLN and back in Observing
23:00 (15:00) Lock loss – Unknown
00:00 (16:00) Turn over to TJ
Comments related to this report
jeffrey.kissel@LIGO.ORG - 16:24, Thursday 20 February 2020 (55209)DetChar, ISC, Lockloss, OpsInfo
Link 

J. Kissel, J. Driggers

We've been having trouble losing lock during the MOVE_SPOTS portion of the IFO "for the past day or two" (annecdotal), and there were two more instances today at 2020-02-20 23:28 UTC and 2020-02-20 23:49 UTC. These were on the way up from the "unknown" lockloss that Jeff mentions at 23:00 -- though, note: we are blaming today's change in DARM offset for these two lock losses at 21:29 and 23:00 (see LHO aLOG 55204).

Anyways -- looking for clues as to what's going on, I remembered the "good catch" that Georgia had back in July 2019 regarding the spots falling off the transmon QPDs (see LHO aLOG 50810), and thought this problem might be that. After conferring with Jenne, she informs me that we're now moving the transmon itself by centering on the B QPDs in order to prevent exactly this. This was done in November 2019 (see LHO aLOG 53362). 

So it *should* no longer be a problem.

But Jenne and I agree it's worth a check to confirm, so I attach screenshots of the QPDs during these two acquisition attempts.

As one can see, while the ISC_LOCK guardian state is cooking between 430 (ENGAGE_ASC_FOR_FULL_IFO) and 506 (MOVE_SPOTS), the transmon QPD's centering is well within the +/- 1.0 range, happily centered.

NOT IT! OH well...
Images attached to this comment
sheila.dwyer@LIGO.ORG - 09:49, Friday 21 February 2020 (55219)
Link

Remember that if you are wondering about what the history is of locklosses from a certain state, you can very easily obtain reliable information using the lockloss website. 

  • look up the number of the guardian state you are interested in by typing in control room terminal: guardutil states ISC_LOCK 
  • open up the website: lockloss
  • type the state number (506 for MOVE SPOTS) into the guardian state field in the row labeled filter events and hit submitt.  

In this case, I changed the state numbers when I rearranged the states on Jan 1st (see  54240, and 54219 for the story of how move spots stopped working during the computer crash and tumblegeddon), we had 3 locklosses from move_spots between then and Feb 6th when Jenne removed the accidental 2 minute wait I'd introduced when moving the states around 54949.  We had the two minute wait removed from Feb 6th until Feb 11th, we had 9 locklosses from MOVE_SPOTS durring those 5 days.  In the 6 days since I added a 2 minute pause back 55029, we've had 3 locklosses, 1 of which happened yesterday. 

 

H1 DetChar (ISC)
jenne.driggers@LIGO.ORG - posted 15:40, Thursday 20 February 2020 - last comment - 16:33, Thursday 20 February 2020(55204)
2 short observing stretches with higher DARM offset

An explicit alog to notify / remind folks that we had two short observing stretches this afternoon with a higher DARM offset (more details on the test in a later alog).  This was intended to be our new nominal configuration, however it appears that this has us locked too close to the edge of the range of our OMC DCPDs and we are not able to hold lock through a glitch, so the change has been backed out.

Comments related to this report
jeffrey.kissel@LIGO.ORG - 16:33, Thursday 20 February 2020 (55212)CAL, DetChar, ISC, Lockloss
Link 

The two observation periods with the larger DARM offset stretches were 
    2020-02-20 between 21:08 - 21:29 UTC
    2020-02-20 between 22:07 - 23:00 UTC

This will be of interest much later when the calibration group is reviewing the data and sees this funky 2-3% outlier in \kappa_C, and/or the brief period when the inspiral range on the summary pages as computed by CAL-DELTAL_EXTERNAL and GDS-CALIB_STRAIN actually agree for a brief moment. (see attached copy of the range plot for today...)
Images attached to this comment
H1 CDS
david.barker@LIGO.ORG - posted 15:10, Thursday 20 February 2020 (55202)
Lock Loss Alert system can now make phone calls

The Lock Loss alerting system now provides the user with the option of no cell phone alerts, text message alerts or a phone call. Actually if a voice call is selected, then any phone number can be used (for example a land line).

The contact MEDM now shows three 'CELL CONTACT' options: no, text, voice. The user's phone information is now contained in two records, the phone number (including area code, no spaces or characters) and their cell provider. If a text message is selected, the code looks up the appropriate email address (e.g. @vtext.com for verizon). If a voice call is selected, the phone number is sent to our TTS (text to speech)  service provider. Their phone call originates from New Jersey.

 

Images attached to this report
LHO VE
chandra.romel@LIGO.ORG - posted 14:26, Thursday 20 February 2020 (55200)
CP1 Dewar fill line repair and plans for overdue skid maintenance

A leaky braze joint was repaired under warranty on CP1 Dewar fill line by brazing over the pin hole leak (new field braze joint at components added last summer) . The joints at MY were inspected by vendor and deemed OK. The others looked fine to me with visual inspection.

We are overdue for skid maintenance listed below. As far as I know all of these components are original and should be replaced every five years. I plan to collect quotes and have this work contracted after O3 ends.


1. Replace Dewar pressure relief valve + burst disk, install a diverter valve, and add redundant pressure relief and burst disk (the new standard); this will require depressurizing the Dewar and thus may take a couple of hours per Dewar.

2. Replace all pressure relief valves in fill line.

3. Replace male fill line connector that has been deformed over the years from truckers pounding on it. The new standard is SS piping at connector with a Cu transition.
Images attached to this report
H1 General
jeffrey.bartlett@LIGO.ORG - posted 13:17, Thursday 20 February 2020 (55199)
Accepted SDF Diffs After Relock 
   Accepted the SDF DIFFs listed below after relock. These were due to the commissioning work that was underway when we lost lock.
Images attached to this report
H1 General
jeffrey.bartlett@LIGO.ORG - posted 12:30, Thursday 20 February 2020 (55198)
Ops Day Mid-Shift Summary 
   IFO is relocking after earthquake (in Russia). The commissioning team is doing commissioning work.
H1 ISC
sheila.dwyer@LIGO.ORG - posted 12:12, Thursday 20 February 2020 (55197)
diff beatnote adjusted

After we lost lock because of the Japan EQ, the guardian got stuck because the diff beatnote wasn't high enough for the threshold that we added.  The trend of the last 1.5 years is attached, this just has to be readjusted every once in a while.  The beatnote is back to -10dBm now, I moved only the last steering mirror before the diff beamsplitter. 

Images attached to this report
H1 General
jeffrey.bartlett@LIGO.ORG - posted 08:16, Thursday 20 February 2020 (55196)
Ops Day Shift Transition
Ops Shift Transition: 02/20/2020, Day Shift 16:00 – 00:00 (08:00 -16:00) - UTC (PT)
State of H1: Locked at NLN, Range is 117.6Mpc
Intent Bit: Observing
Weather:  Skies are clear, with no rain or snow in the forecast. The temperatures are in the low 20s. The wind is Calm.       
Primary 0.03 – 0.1Hz: 0.02um/s
Secondary 0.1 – 0.3Hz: 0.3um/s
Outgoing Operator: Jim
Quick Summary: The IFO has been observing for the past 15 hours. Environmental conditions are good for observing. No concerns at this time.   
H1 General
jim.warner@LIGO.ORG - posted 07:55, Thursday 20 February 2020 (55195)
Shift Summary

TITLE: 02/20 Owl Shift: 08:00-16:00 UTC (00:00-08:00 PST), all times posted in UTC
STATE of H1: Observing at 119Mpc
INCOMING OPERATOR: Jeff
SHIFT SUMMARY: Quiet shift, nothing to report
LOG:
 

LHO General
thomas.shaffer@LIGO.ORG - posted 00:00, Thursday 20 February 2020 (55187)
Ops Eve Shift Summary

TITLE: 02/20 Eve Shift: 00:00-08:00 UTC (16:00-00:00 PST), all times posted in UTC
STATE of H1: Observing at 120Mpc
INCOMING OPERATOR: Jim
SHIFT SUMMARY: Quiet shift, no issies to report.
LOG:

H1 AOS
cheryl.vorvick@LIGO.ORG - posted 20:38, Wednesday 19 February 2020 (55194)
updated plot H1:ASC-AS_A_RF36_Q_PIT_OFFSET values when relocking H1

Following up on my alog 55023, I've replotted the data for the H1:ASC-AS_A_RF36_Q_PIT_OFFSET being set and zeroed during relocking.  The new plot more clearly identifies the sequence of events, and now includes:

Attached:

Images attached to this report
H1 General
thomas.shaffer@LIGO.ORG - posted 20:02, Wednesday 19 February 2020 (55193)
Ops Mid Shift Report

Locked for 4 hours. We stepped out of Observing briefly for planned commissioning from 0030-0106 UTC.

H1 SUS
rahul.kumar@LIGO.ORG - posted 17:35, Wednesday 19 February 2020 - last comment - 09:18, Monday 24 February 2020(55190)
Monitor filter

Sheila, Jenne, Rahul

I went through all the monitor filters for the violin modes to confirm the following,

The band pass filter has a gain of 120db and the bandwidth is 0.02Hz. The bandwidth at 80db is 0.04Hz.

With this boundary condition, I found 4 modes (ETMY 1,6 and ETMY 18,20) which are very close to each other (or are pairs), i.e. within 0.04Hz. The bode plots for all  4 modes are attached below. 

In fact mode 1 and mode 6 and only 0.011 Hz apart and they are sitting on the flat top of the band pass filter (which is not good, since they are creating beating and hence Guardian cannot effectively damp them). Sheila suggested that we can use notch filters to reject signals in this case.

Images attached to this report
Comments related to this report
rahul.kumar@LIGO.ORG - 09:18, Monday 24 February 2020 (55256)
Link

...adding a few more lines to bring clarity to the above alog,

The aim was to hunt for pair modes in the monitor filter which are very close in frequencies and hence could be crossing over into the narrow band pass filter of each other. Since the gain for the narrow band pass filter was defined as 120db, we looked for modes which are crossing over at 80db and above. The bandwidth has been user defined and is consistent for all the violin mode monitor filters. Below 80db, the beating of the two modes won't be that significant and hence can be ignored.

H1 ISC
jenne.driggers@LIGO.ORG - posted 17:26, Wednesday 19 February 2020 - last comment - 16:12, Thursday 20 February 2020(55189)
SRCL feedforward filters designed for 14pm DARM offset, new cutoff filter for SRCL

On Friday (alog 55108) I measured the LSC feedforward filters that we'll need when we re-try increasing our DARM offset.  I've now got some candidate SRCL FF filters, although as usual they are tricky to fit. 

This SRCL FF filter would inject excess SRCL control into DARM above ~150 Hz, since the fit is not good above there.  It's hard to convince the fit of the feedforward to maintain high fidelity in the mid frequencies (where we really care) and also roll off the high frequencies.  So, an alternate solution might be to more sharply cutoff the SRCL LSC loop.  According to our most recent SRCL OLG measurement (albeit from May 2019) we have more than 50 degrees of phase margin in SRCL, so should have some room for additional rolloff. 

I have created a candidate new SRCL LSC cutoff, and calculated how the change in gain peaking we will expect to see.  It seems not so bad, so I propose that before we start our DARM offset test tomorrow morning we measure the SRCL OLG (to confirm that that phase margin is correct), and put in the new cutoff filter.  Then we will increase the DARM offset, turn on the new SRCL FF filter, do a quick scan to ensure that we're at the optimal squeezing angle, and then compare this 14 pm DARM offset configuration with our current nominal 10 pm DARM offset configuration.

In the first attachment I show the current SRCL LSC cutoff in red versus the candidate cutoff in blue [ ellip("LowPass",4,0.3,20,150)ellip("LowPass",2,1,20,650)gain(1.16145) ].  The candidate filter takes away an additional 13 degrees of phase margin than the current filter.

In the second attachment I show the SRCL OLG measurement from May 2019 in red/orange, and then what that measurement would look like if the cutoff were replaced with the candidate cutoff in blue.

In the third attachment I show G / (1 - G) for both of the cases from the second attachment (current situation in red/orange, and candidate situation in blue). 

I think that it should be fine to try the new SRCL cutoff. 

All that said, the fourth attachment is my candidate fit for SRCL FF at the higher DARM offset. This is an iterative filter, so if the currently in-use filter were perfect, this iterative filter should be unity.  The blue points are the measured TF to fit, and the green is the filter output (IIRrational plus some hand adjustments to make the low frequency and high frequency less egregiously bad).  The fit above 150 Hz isn't good, which is why I'm interested in making the SRCL loop cutoff more sharp.  The fit also isn't so great below 10 Hz, but at least that part is out of the GW band, and shouldn't hurt us too much when testing the higher DARM offset. The bottom half of the 4th attachment is a representation of how good or poor the fit is to the data.

Images attached to this report
Comments related to this report
jenne.driggers@LIGO.ORG - 16:12, Thursday 20 February 2020 (55207)
Link

Before changing the cutoff filter, I measured SRCL in NomLowNoise, since the reference measurement I was working from was from May 2019.  It seems like the reference measurement was from a time before we lower the SRCL gain, not actually in nominal low noise.

We run SRCL near the very low end of the phase bubble, and so can't afford the phase loss from my proposed new cutoff filter.  We tried SRCL FF with higher DARM offset today without any change to the cutoff, and it's mostly fine.  Even though there is a teensy bit more coherenece with DARM at ~300Hz, it's still at the 1e-2 level and so shouldn't be a big problem, at least for checking the efficacy of the higher DARM offset.

 

Images attached to this comment
H1 CAL
jeffrey.kissel@LIGO.ORG - posted 17:30, Tuesday 11 February 2020 - last comment - 15:20, Thursday 20 February 2020(55055)
2020-01-03 Calibration Model Uncertainty Update: Adding 2020-02-10 Data Sets Improve Uncertainty, But Don't Reveal Discrepancy Between Overall Systematic Error Prediction vs. Measurement 
J. Kissel

I've processed yesterday's measurement suite (see LHO aLOG 55018) to the point where I've been able to add it to the collection of measurements used to produce an estimate of the unknown, frequency-dependent (but time independent) systematic error in the model (i.e. the Gaussian Process Regression of the measurement collection's residual frequency dependence after the model has been divided out of the measurement, and the measurement has been compensated for time dependence).

I've done this for four reasons:
    (1) To confirm that most of the response function uncertainty in the middle frequency range (20-300 Hz) is dominated by the uncertainty in this estimate of unknown systematic error
    (2) I've always been curious how much "one more data set" gathered improves the overall uncertainty (you would guess it should improve by sqrt(N), but N is different for each of the four model components -- C, A_UIM, A_PUM, and A_TST -- and the digital filtering on each of these components means that the contribute to the uncertainty in a sophisticated, frequency dependent way that is in no way easy to predict)
    (3) In the event that we *do* throw away the data prior to 2020-11-12's fix to the known PCAL systematic error (aka PCALSYSERR) because it's easier than figuring out how to salvage the data prior, as alluded to in LHO aLOG 55007, then I'd like to see as much PCALSYSERR-free data included in the estimate as possible
    (4) To see if adding "one more data set" would help us "resolve" the discrepancy we see between a processed GDS-CALIB_STRAIN in the presence of a broad-band PCALY injection.

The results satisfy (1) through (3) positively, but they leave (4) unresolved.

See the attached figure, which shows the two uncertainty envelopes from 2020-02-07 (i.e. LHO aLOG 55007) and 2020-02-11 (today, this aLOG) compare against the same 2020-01-13 pre-processed GDS transfer function data (from LHO aLOG 54565).

We see improvement (frequency dependent, of course) with the addition of the 2020-02-10 measurement suite. This confirms (1), and demonstrates (2) that we're still in the "winning" region of 1/sqrt(N) for the actuator, given that the number of measurements, N, is 5 to 6 for each stage. Since we measure it every week, the sensing function measurement number 13, so we don't see "as much" improvement above ~100 Hz where the sensing function's contribution to the response function is dominant.
Addressing (3) the improvement (again, it's frequency dependent -- look at the plot -- so in this sentence I'm just using "verbal" numbers to describe what I see) at ~50 Hz is about 0.5% / 0.25 deg -- and when you're talking about a budget that is achieving a 3-4% / 1-2 degree level, that's pretty substantial. 
So, for the next few calibration measurement days, I might start getting actuator data too (i.e., until N gets large, increase the frequency of measuring the actuator suite from ~twice a month to once a week).

As far as (4) -- In the region that we're seeing the largest discrepancy between median predicted systematic error (plus uncertainty) and the measured systematic error between PCAL and the final product -- between 40 Hz and 150 Hz -- the uncertainty remains too large to "resolve" the discrepancy. In fact -- if we focus on exactly 100 Hz, I'm now pretty confident that we're limited by the overall PCAL uncertainty (a frequency independent 0.54%) and *not* the GPR uncertainty, so this discrepancy may never get resolved.

I still would like to see 
    - a different day's broad band injection process and put on this plot, and 
    - all of the swept sine transfer functions for which we only have CAL-DELTAL_EXTERNAL, but properly corrected for time-dependence, such that the comparison with this "reference time" envelope is valid and we can see how the envelope compares to measurement across all frequencies from 5 to 5000 Hz,
before declaring that "it won't get any better than this -- let's release this envelope!"

Stay tuned for the results of that work.

Also -- remember, this envelope will likely *not* be valid for the first 2 hours of every lock stretch. 
Analysis of showing the systematic error as the IFO thermalizes (based on the data from LHO aLOG 53951) is underway.
Non-image files attached to this report
2020-02-11_H1_PCAL2GDS_BB_meas1262990871_on_2020-01-13_vs_model_uncertainty_for_2020-01-03.pdf
Comments related to this report
jeffrey.kissel@LIGO.ORG - 17:33, Tuesday 11 February 2020 (55056)
Link 

Information about how the 2020-02-11 uncertainty envelope was created:

To produce the new GPR fits:
/ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/O3/H1/Scripts/Uncertainty
        process_allmeas_writeGPRHDF5_20200211_A_meas20191204-20200210_model20200103_NOPCALSYSERR.py
        process_allmeas_writeGPRHDF5_20200211_C_meas20191120-20200210_model20200103_NOPCALSYSERR_withHF.py
    committed to rev 9412.
    
The new HDF5 files from the fit:
        2020-02-11_GPR_Run_H1_A_O3B_meas20191204-20200210_collection_model20200103_NOPCALSYSERR_ALL_UIM_f7-250Hz_L0p1_PUM_f7-500Hz_L0p2_TST_f10-1000Hz_L0p5_posteriors.hdf5
        2020-02-11_GPR_Run_H1_C_O3B_meas20191120-20200210_collection_model20200103_NOPCALSYSERR_nofsQcorr_MCMCfmin20Hz_GPRfmin20_lengthscale0p35_withPCALXHFdata_model20200103_posteriors.hdf5
    committed to rev 9413.

The updated call to RRNom.py:
python3.5 /ligo/svncommon/CalSVN/aligocalibration/trunk/Common/pyDARM/RRNom.py --IFO=LHO --HDF5_A_MCMCresults=/ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/O3/H1/Results/Uncertainty/O3B_H1_A_MCMC_20200103Model_REF.hdf5 --HDF5_A_GPRresults=/ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/O3/H1/Results/Uncertainty/2020-02-11_GPR_Run_H1_A_O3B_meas20191204-20200210_collection_model20200103_NOPCALSYSERR_ALL_UIM_f7-250Hz_L0p1_PUM_f7-500Hz_L0p2_TST_f10-1000Hz_L0p5_posteriors.hdf5 --HDF5_C_MCMCresults=/ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/O3/H1/Results/Uncertainty/O3_H1_C_MCMC_2019-12-26_forreference_fmin20Hz.hdf5 --HDF5_C_GPRresults=/ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/O3/H1/Results/Uncertainty/2020-02-11_GPR_Run_H1_C_O3B_meas20191120-20200210_collection_model20200103_NOPCALSYSERR_nofsQcorr_MCMCfmin20Hz_GPRfmin20_lengthscale0p35_withPCALXHFdata_model20200103_posteriors.hdf5 --modelPath=/ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/O3/H1/params/ --modelFilename=modelparams_H1_20200103 --IFOmodel=modelPars --sampleNumber=1000 --seed=1111 --version=ref --outDir=/ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/O3/H1/Results/Uncertainty/  --plot1SigmaUncs --saveSummaries --gpsTime=1261415486

The resulting uncertainty envelope:
/ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/O3/H1/Results/Uncertainty
        2020-02-11_O3_LHO_GPSTime_1261415486_ref_RelativeResponse1SigmaUncertainty.png
        2020-02-11_O3_LHO_GPSTime_1261415486_ref_RelativeResponseUncertainty_FinalResults.txt
        2020-02-11_O3_LHO_GPSTime_1261415486_ref_RelativeResponseUncertainty_MinMax.txt
    committed to rev 9414.

The script to produce the attached plot:
/ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/O3/H1/Scripts/FullIFOSensingTFs
        plot_GDS_BB_vs_Uncertainty_20200211.py        rev 9415
jeffrey.kissel@LIGO.ORG - 14:53, Thursday 20 February 2020 (55201)
Link 

Just trying gather some further clues -- today, I thought "I know that the measured broadband injection shown in these plots has been corrected for TDCFs as per LHO aLOG 54676. That means the measurement has been 'propogated' back to the reference time and is directly comparable to the RRNom-produce uncertainty envelope, using the argument version=ref. But what if we correct the *envelope* for the TDCFs surrounding the reference time?"

The results are the *incorrect* thing to do, but they do help in understanding how much impact the TDCFs can make on the estimate.

I envoked RRnom with --version=C00, and set the --gpsTime=1261411218 (2019-12-26 16:00 UTC, just *before* the *reference* measurement was taken -- not when the broadband injection was taken), and the data gathering method to --GetData=GWPY, with otherwise everything else identical,
python3.5 /ligo/svncommon/CalSVN/aligocalibration/trunk/Common/pyDARM/RRNom.py --IFO=LHO --HDF5_A_MCMCresults=/ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/O3/H1/Results/Uncertainty/O3B_H1_A_MCMC_20200103Model_REF.hdf5 --HDF5_A_GPRresults=/ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/O3/H1/Results/Uncertainty/2020-02-11_GPR_Run_H1_A_O3B_meas20191204-20200210_collection_model20200103_NOPCALSYSERR_ALL_UIM_f7-250Hz_L0p1_PUM_f7-500Hz_L0p2_TST_f10-1000Hz_L0p5_posteriors.hdf5 --HDF5_C_MCMCresults=/ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/O3/H1/Results/Uncertainty/O3_H1_C_MCMC_2019-12-26_forreference_fmin20Hz.hdf5 --HDF5_C_GPRresults=/ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/O3/H1/Results/Uncertainty/2020-02-11_GPR_Run_H1_C_O3B_meas20191120-20200210_collection_model20200103_NOPCALSYSERR_nofsQcorr_MCMCfmin20Hz_GPRfmin20_lengthscale0p35_withPCALXHFdata_model20200103_posteriors.hdf5 --modelPath=/ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/O3/H1/params/ --modelFilename=modelparams_H1_20200103 --IFOmodel=modelPars --sampleNumber=1000 --seed=1111 --version=C00 --outDir=/ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/O3/H1/Results/Uncertainty/  --plot1SigmaUncs --saveSummaries --gpsTime=1261411218 --GetData=GWPY


This plot is flawed, because at 2019-12-26 16:00 UTC, GDS was still using the 2019-09-09 model parameter set. That means the TDCFs were computed against the 2019-09-09 model, when we know that the interferometer was behaving more like the 2020-01-03 model parameter set. So, the uncertainty envelope has been corrected for by the *the wrong thing*. In order to truly make this comparison, we should find the uncertainty envelop for a time *after* the CAL-CS / GDS calibration was updated on the 2020-01-13.

I compared the uncertainty envelopes against the data just to show what it looks like.

We should run this comparison again once we have C01, where all the O3B data has been calibrated with the 2020-01-03 model.
Images attached to this comment
Non-image files attached to this comment
jeffrey.kissel@LIGO.ORG - 15:20, Thursday 20 February 2020 (55203)
Link 

J. Kissel

I've re-run the uncertainty estimate at 1263000618, Jan 14 2020 01:30:00 UTC, just after the broad band injection and compared *that* against the reference time envelope (i.e. one with no TDCFs applied). I also attach screenshots of the values of the TDCFs at *this* time, so we can compare them against what Aaron reported the GDS TDCFs that were used to correct the broadband injection in LHO aLOG 54676.

One can see that the envelope disagrees with the data.

HOWEVER -- an aLOG is still pending -- but Aaron believes he's uncovered a systematic error in the TST stage of the actuator. You can see a sneak peak of the preliminary investigation here. 
That plot shows the response function with (in blue) and without (in maroon) the systematic error present.
You could convince yourself that the discrepancy between the GDS measurement (which would have this TST flaw) and the uncertainty envelope is *about* what you see as the blue curve in that preliminary plot. But, stay tuned for the analysis to be done right -- applying the correction in "the right direction" and putting these things on the same plot.

Anyways, just wanted to show this data as well, given that this is actually a *legit* comparison as far as we know it -- and now I have a clue that points my finger back at GDS. It's still impressive how different the TDCF-applied envelope is from the reference envelope, but I suppose we shouldn't be surprised as the reference envelope is based on data from 2019-12-26 (for sensing) and 2019-04-03 (for the actuator).

Stay tuned!

The command to create this uncertainty envelope is 
python3.5 /ligo/svncommon/CalSVN/aligocalibration/trunk/Common/pyDARM/RRNom.py --IFO=LHO --HDF5_A_MCMCresults=/ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/O3/H1/Results/Uncertainty/O3B_H1_A_MCMC_20200103Model_REF.hdf5 --HDF5_A_GPRresults=/ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/O3/H1/Results/Uncertainty/2020-02-11_GPR_Run_H1_A_O3B_meas20191204-20200210_collection_model20200103_NOPCALSYSERR_ALL_UIM_f7-250Hz_L0p1_PUM_f7-500Hz_L0p2_TST_f10-1000Hz_L0p5_posteriors.hdf5 --HDF5_C_MCMCresults=/ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/O3/H1/Results/Uncertainty/O3_H1_C_MCMC_2019-12-26_forreference_fmin20Hz.hdf5 --HDF5_C_GPRresults=/ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/O3/H1/Results/Uncertainty/2020-02-11_GPR_Run_H1_C_O3B_meas20191120-20200210_collection_model20200103_NOPCALSYSERR_nofsQcorr_MCMCfmin20Hz_GPRfmin20_lengthscale0p35_withPCALXHFdata_model20200103_posteriors.hdf5 --modelPath=/ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/O3/H1/params/ --modelFilename=modelparams_H1_20200103 --IFOmodel=modelPars --sampleNumber=1000 --seed=1111 --version=C00 --outDir=/ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/O3/H1/Results/Uncertainty/  --plot1SigmaUncs --saveSummaries --gpsTime=1263000618 --GetData=GWPY
Images attached to this comment
Non-image files attached to this comment
Displaying reports 35621-35640 of 89220.Go to page Start 1778 1779 1780 1781 1782 1783 1784 1785 1786 End