Displaying reports 35761-35780 of 89220.Go to page Start 1785 1786 1787 1788 1789 1790 1791 1792 1793 End
Reports until 16:03, Wednesday 12 February 2020
LHO General
thomas.shaffer@LIGO.ORG - posted 16:03, Wednesday 12 February 2020 (55067)
Ops Day Shift Summary

TITLE: 02/12 Day Shift: 16:00-00:00 UTC (08:00-16:00 PST), all times posted in UTC
STATE of H1: Lock Acquisition
INCOMING OPERATOR: Jim
SHIFT SUMMARY: Lost lock within this hour from some commissioning activity. Currently relocking.
LOG:

H1 General
thomas.shaffer@LIGO.ORG - posted 15:27, Wednesday 12 February 2020 (55069)
Lock Loss 2325 UTC

We were doing some PEM and sensing funtion injections, so it could have been one of those, but we are not 100% sure.

LHO General
thomas.shaffer@LIGO.ORG - posted 08:06, Wednesday 12 February 2020 (55066)
Ops Day Shift Transition

TITLE: 02/12 Day Shift: 16:00-00:00 UTC (08:00-16:00 PST), all times posted in UTC
STATE of H1: Observing at 120Mpc
OUTGOING OPERATOR: Patrick
CURRENT ENVIRONMENT:
    SEI_CONF state: WINDY
    Wind: 3mph Gusts, 1mph 5min avg
    Primary useism: 0.02 μm/s
    Secondary useism: 0.19 μm/s
QUICK SUMMARY: Locked and observing for almost 9 hours, calm environment.

LHO General
patrick.thomas@LIGO.ORG - posted 08:00, Wednesday 12 February 2020 (55065)
Ops Owl Shift Summary
TITLE: 02/12 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: TJ
SHIFT SUMMARY: Locked and in observing the entire shift. No issues.
LOG:

09:25 UTC Power cycled nuc5 (bottom eq plot had disappeared)

10:50 UTC GRB-Short
INJ_TRANS to INJECT_KILL
E363754
Fermi
Trigger ID	603197394
TRIGGER_DUR:     0.512 [sec]
Stand Down

14:05 UTC INJ_TRANS back to INJECT_SUCCESS
LHO General
patrick.thomas@LIGO.ORG - posted 04:00, Wednesday 12 February 2020 (55064)
Ops Owl Mid Shift Status
Have remained locked and in observing. No issues.
H1 ISC
cheryl.vorvick@LIGO.ORG - posted 03:59, Wednesday 12 February 2020 - last comment - 10:06, Wednesday 12 February 2020(55063)
a closer look at two recent locklosses (fast lockloss)

A lockloss on 9 Feb 2020 at 21:15 UTC, and on 12 Feb 2020 at 06:06 UTC, were both suggested as belonging to the catagory "fast lockloss."  Both show there are no saturations in ADC Overflow Plots, however both have very similare patterns in Glitch Heatmaps for H1:ASC-REFL_B_RF45_I_PIT_OUT_DQ before lockloss.

For the lockloss on 9 Feb, the downsampled PI mode peaks in DARM around 6KHz increase near the lockloss, when compared to earlier in the lock.

For the lockloss on 12 Feb, the peaks in OMC-PI_DCPD_64K around 15220Hz increase just before the lockloss when compared to earlier in the same lock, and when compared to the middle of the lock on the previous day.

Attached:

Images attached to this report
Comments related to this report
camilla.compton@LIGO.ORG - 10:06, Wednesday 12 February 2020 (55068)

Looks very interesting Cheryl!

I would suggest that the two lockloss are quite different though. 09 Feb 2020 21:15 UTC being very fast (1ms), but 12 Feb 2020 06:06 UTC actually being relatively slow (40ms with the ETMX suspension signals starting to saturate 200ms before lockloss). This can see from the attached ndscope plots (1 second in length), using the H1:LSC-POPAIR channel for measuring how long the lockloss took and the 3 bottom left plots for ETMX suspention L1, L2, L3.

When looking at the channels with high SNR in the heatmap (H1:ASC-REFL_B_RF45_I_PIT_OUT_DQ, H1:ASC-REFL_B_DC_PIT_OUT_DQ, H1:ASC-REFL_B_DC_YAW_OUT_DQ) in ndscope I can't actually see too much activity in the second before lockloss compared to the 30 seconds prior (bottom right 3 plots in attached plots). I wonder how the heatmaps are made.
Images attached to this comment
H1 General
cheryl.vorvick@LIGO.ORG - posted 00:26, Wednesday 12 February 2020 - last comment - 16:15, Thursday 13 February 2020(55061)
OPS Eve Summary:

TITLE: 02/12 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: Patrick
SHIFT SUMMARY: one lockloss
LOG:

Comments related to this report
cheryl.vorvick@LIGO.ORG - 16:15, Thursday 13 February 2020 (55088)

H1 relocked on it's own, fully automated, one attempt that made it to NLN, with a DRMI to PRMI back to DRMI automated alignment adjustment.

Today TJ and I entered survey answers manually to record the one-attempt-back-to-NLN relock.

LHO General
patrick.thomas@LIGO.ORG - posted 23:57, Tuesday 11 February 2020 (55060)
Ops Owl Shift Start
TITLE: 02/12 Owl Shift: 08:00-16:00 UTC (00:00-08:00 PST), all times posted in UTC
STATE of H1: Observing at 120Mpc
OUTGOING OPERATOR: Cheryl
CURRENT ENVIRONMENT:
    SEI_CONF state: WINDY
    Wind: 11mph Gusts, 9mph 5min avg
    Primary useism: 0.03 μm/s
    Secondary useism: 0.20 μm/s 
QUICK SUMMARY: No issues.
H1 CDS
david.barker@LIGO.ORG - posted 21:33, Tuesday 11 February 2020 (55058)
CDS Maintenance Summary: Tuesday 11th February 2020

SEIPROC add ramped mux matrix

Jim, Dave:

Jim installed a new h1seiproc, which removes the P5_FADER code section and adds four 2-element ramped mux matrix parts (one per test mass).

New guardian node IFO_NOTIFY

TJ, Dave:

The new guardian node creates a state which will permit the lock loss alerting system to notify that there are locking issues which need attention. I modified the lock-loss-alert code to service this request and the new code is being tested.

DAQ Restart:

For above changes. h1edc was restarted for the guardian node addition.

Slow Controls EX temporary photodiode removal, MEDM modified

Richard, Dave:

The EX slow controls system will run in a hardware error state for the next week. To 'UN_RED' the CDS overview screen, I have taken EX out of the condition to make the large red header block visible. The EX small red rectangle will remain RED. Image of the new nominal is attached.

Images attached to this report
H1 General
cheryl.vorvick@LIGO.ORG - posted 20:49, Tuesday 11 February 2020 - last comment - 21:56, Tuesday 11 February 2020(55057)
mid-shift update

H1 has been in Observe.  The range has been droping and recovering.  The wind has certainly had an effect on the range, however, subjectively it looks like something else is in there.  Both Robert and I independently had this observation.  I've been checking SQZ, and looking at some of the channels that grow in amplitude and show and increase in DC levels when SQZ is effecting the range, and the channels are not showing that change.  I did notice that a couple days ago when Patrick unlocked and relocked SQZ, to correct it's effect on range, the PZT1 dropped from around 80 to around 20.  The PZT is currently around 80, so maybe there's something there?  Winds have been mostly above 10mph, with some spikes up to 40mph.

Comments related to this report
cheryl.vorvick@LIGO.ORG - 21:56, Tuesday 11 February 2020 (55059)

... and after I wrote this update, SQZ started to ring up (?), now relocked, range back at 120Mpc.

  • 05:35:43 - H1 out of Observe, SQZ relocked
  • 05:37:37 - H1 back in Observe
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
Comments related to this report
jeffrey.kissel@LIGO.ORG - 17:33, Tuesday 11 February 2020 (55056)
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)
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)
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
H1 General
cheryl.vorvick@LIGO.ORG - posted 16:15, Tuesday 11 February 2020 (55052)
OPS Eve Transition

TITLE: 02/12 Eve Shift: 00:00-08:00 UTC (16:00-00:00 PST), all times posted in UTC
STATE of H1: Observing at 121Mpc
OUTGOING OPERATOR: Ed
CURRENT ENVIRONMENT:
    SEI_CONF state: WINDY
    Wind: 15mph Gusts, 11mph 5min avg
    Primary useism: 0.06 μm/s
    Secondary useism: 0.23 μm/s
QUICK SUMMARY: locked in Observe

H1 General
edmond.merilh@LIGO.ORG - posted 16:00, Tuesday 11 February 2020 (55051)
Shift Summary - Day

TITLE: 02/11 Day Shift: 16:00-00:00 UTC (08:00-16:00 PST), all times posted in UTC
STATE of H1: Observing at 119Mpc
INCOMING OPERATOR: Cheryl
SHIFT SUMMARY:

LOG:

LHO VE
chandra.romel@LIGO.ORG - posted 15:10, Tuesday 11 February 2020 - last comment - 15:49, Tuesday 11 February 2020(55047)
leak checked IP12 + chevron baffle

{Kyle, Tyler, Chandra}

In an attempt to find air leak at EX and based on some aLOGs from summer 2018 (43165 & 43184), we had reason to believe that IP12 may be leaking and so today we isolated IP12 + chevron baffle from main volume and leak checked with a background of 1.5e-9 Torr-L/s of He. We sprayed ample amounts of He and saw no rise in signal.

We also sprayed the beamtube side flange of isolation GV while Jeff Jones remotely watched the RGA screen in control room, running in MID mode with new Labview based software with no change in AMU 4. This test is inconclusive, however, because we were opened to BT.

We suspect the leak is in the e-7 Torr-L/s range.

Next opportunity to leak check with BT GV closed is March 3 when we replace the maglev turbo.

Comments related to this report
chandra.romel@LIGO.ORG - 15:41, Tuesday 11 February 2020 (55048)

Attached is RGA scan of AMUs 2,4,28,32,40,44 during leak checking. H2 rose when we isolated IP12 from main volume (no surprise). There is an ever so slight increase in He when we sprayed the tube side of GV flange.

Images attached to this comment
chandra.romel@LIGO.ORG - 15:44, Tuesday 11 February 2020 (55049)

Glad to see some things never change :)

https://alog.ligo-wa.caltech.edu/aLOG/index.php?callRep=5561

chandra.romel@LIGO.ORG - 15:49, Tuesday 11 February 2020 (55050)

Gerardo and I reported no leaks on the new IP12 GV, but we will redo this measurement, including bonnet.

https://alog.ligo-wa.caltech.edu/aLOG/index.php?callRep=42721

H1 CDS (ISC, SUS)
filiberto.clara@LIGO.ORG - posted 13:03, Tuesday 11 February 2020 - last comment - 15:21, Friday 31 July 2020(55041)
Baffle Photodiode Amplifier Powered Down At EX

The following modifications were made at EX to help with the ongoing noise hunting investigation.

1. Baffle Photodiode Amplifier moved from SUS-R1 to FAC-R1
2. Baffle Photodiode Amplifier powered down
3. Beckhoff hub isolated from rack
4. ESD current limit resistor box removed and SHV barrels installed

The removal of the current limit resistor should have no impact. The installed ETM Low Noise ESD Driver Chassis (D1500129) has built-in current limit protection.
The Baffle Photodiode Amplifier unit was powered down to see if the Beckhoff terminal might be a noise source. Unit at EX is normally not used to lock the Interferometer. Unit can be powered back on by reconnecting the ±24V power cable.

F. Clara, R. Mccarthy, R. Schofield

Comments related to this report
jeffrey.kissel@LIGO.ORG - 13:58, Tuesday 11 February 2020 (55043)CAL, DetChar
Tagging DetChar and CAL.

These changes *should* not have any *bad* effect on the detector, but
    (DETCHAR) These changes were made in order to reduce the amount of spectral features in h(t) based on Evan's studies for the CW group (e.g. LHO aLOG 53439, G1902208) and the differences between H1 and L1.
     We would appreciate any help that @DetChar can provide over the coming days/weeks in assessing whether this change made a difference (whether that be positive, negative, or even "can't tell.")

    (CAL) The change in the resistor box -- "ESD current limit resistor box removed and SHV barrels installed" -- should, nominally, NOT affect the actuation strength of the ETMX ESD, but I'll be taking a look to see if the online tracking system *of* that strength made a difference.
jeffrey.kissel@LIGO.ORG - 16:16, Tuesday 11 February 2020 (55054)CAL, DetChar
The first observation ready segment after these changes were made started on Feb 11 2020 22:25:54 UTC, at GPS time 1265495172, or 14:25:54 PST.

Upon initial investigation, the DARM actuator's time-dependent correction factors (i.e. the point-estimate of the actuation strength relative to the 2020-01-03 model installed on 2020-01-13) are the same as prior to today's maintenance activity and thus I'm 90% confident that there has been no change to the actuator as a result of the electronics activity at EX today. 

Nice!
Images attached to this comment
jeffrey.kissel@LIGO.ORG - 15:21, Friday 31 July 2020 (56346)
R. Abbott, J. Kissel

Upon further investigation of calibration measurements taken of the TST stage over the remainder of the run, there appears to be a clear bifurcation in the data between the 2020-02-10 and 2020-02-24 measurements (see attached data collection). 

The bifurcation in the data is consistent with a ~4-5 deg change at 1 kHz. 

After consulting with Rich, we agree that -- given the residual parasitic cable capacitance between the chamber feedthrough and the ESD pattern itself (we guesstimate at ~600 pF), the act of replacing the former 10k current limiting resistors on the quadrant "signal" paths with the SHV connections (which have negligible resistance) removed the voltage-divider-like, passive low-pass response of a pole at 1/(2*pi*10e3*600e-12) = 26525 kHz, which *was* incurring a phase loss at 1 kHz of 180/pi*atan(-2pi * 1000 Hz * 10e3 Ohm * 600e-12 Farad) = -2.15 deg. Given the uncertainty in the cable capacitance, we could easily imagine a phase change of 5 deg after switching to ~0 Ohm SHV barrels.

The consequence: we'll just have to split up this collection TST measurements in O3B in to two periods, and run the standard fit for unknown systematic error separately.
Non-image files attached to this comment
H1 SUS
sheila.dwyer@LIGO.ORG - posted 10:44, Tuesday 04 February 2020 - last comment - 12:23, Thursday 13 February 2020(54886)
ETM noise monitor transfer functions

Sheila, Richard,

Filiberto and Richard installed new noise monitor circuits on the ETM PUMs last week, this morning I measured some transfer functions of them.  

Attached are the dtt templates. Unfortunately I measured these TFs with the coil driver in state 3, which means that the low pass is on and the acq filter is off (the acq filter is after the noisemon pick off). In the digital noisemon filters I used the  ANTILP filter zpk([0.4915;240.0583],[5.4697;21.8761],1,"n").  

I'm also attaching the ITM measurements, which were taken in the same configuation 54614

The transfer function for ETMY LL seems significantly different from the rest.  Richard and I set the test/coil enable to 0 (seting the driver into test mode, which means no input from DAC, I'm not sure what it means about terminating or floating inputs) and looked at spectra, and LL also looks different (3rd screenshot).  

Richard is heading to the end station to check if there is something like a capacitor that wasn't swapped in that channel. 

Images attached to this report
Non-image files attached to this report
Comments related to this report
sheila.dwyer@LIGO.ORG - 17:53, Wednesday 05 February 2020 (54925)

The EE team did find a bad solder joint in the ETMY LL channel, and repaired it before the end of maintence.  Richard also re-ran the set of transfer functions for the noise monitors for EY, the attached file has his new set of measurements. The quadrants all seem to be the same now.  

This ETMY measurement was taken with coil drivers in state 2, but the antiLP filter was on.  That means that to compare these TFs to the others, we need to remove the filter  zpk([0.4915;240.0583],[5.4697;21.8761],1,"n").  

Non-image files attached to this comment
christopher.wipf@LIGO.ORG - 17:44, Wednesday 12 February 2020 (55070)

Attached are filters to calibrate the noisemon outputs in DAC counts.

They are designed by fitting the above-measured transfer functions (using IIRrational) and then inverting them.  The antiLP filter was removed from the ETMY data.  Poles at very low frequencies were nudged up to 1 Hz to limit the DC gain.

Attachment 1: plots of the data and fitted filters.
Attachment 2: filter install script

Non-image files attached to this comment
sheila.dwyer@LIGO.ORG - 12:23, Thursday 13 February 2020 (55085)

Thank you very much Chris.  

I have just run this script and turned on the new filters, because we are out of observing for ~40 minutes of commisioning time.  The new filters are turned on as of 20:22 UTC Feb 13, so the noise mon channels are all calibrated into DAC counts now.  

Displaying reports 35761-35780 of 89220.Go to page Start 1785 1786 1787 1788 1789 1790 1791 1792 1793 End