Displaying reports 38461-38480 of 89074.Go to page Start 1920 1921 1922 1923 1924 1925 1926 1927 1928 End
Reports until 15:12, Thursday 26 September 2019
H1 ISC (GRD, Lockloss)
adrian.helmling-cornell@LIGO.ORG - posted 15:12, Thursday 26 September 2019 - last comment - 19:47, Saturday 26 October 2019(52150)
Lockloss Trigger Updated

Jenne Driggers, Adrian Helmling-Cornell

Today we updated the photodiode used for the frontend lockloss trigger from POP_A_DC to POPAIR_A_DC, as it responds slightly faster to the interferometer losing lock. The lockloss trigger is armed when Guardian enters the OFFLOAD_DRMI_ASC state. As Guardian goes through the CARM offset reduction sequence, if POPAIR_A normalized by the laser power falls below 2.5 the lockloss trigger will now trigger, stopping actuation. When Guardian reaches and passes the DRMI_TO_POP state, the trigger triggers if POPAIR_A normalized by the laser power falls below 108.

The appropriate SDF diffs were accepted and this change was implemented around 20:40 UTC today.

Comments related to this report
sheila.dwyer@LIGO.ORG - 19:47, Saturday 26 October 2019 (52707)

We are undoing this change for now so that we have the option of closing the beam diverter.

H1 ISC
evan.hall@LIGO.ORG - posted 14:10, Thursday 26 September 2019 - last comment - 17:49, Thursday 10 October 2019(52114)
Dark and in-lock noise in AS A RF45Q, and a comparison with DCPD sum

【Craig, Evan】

We took a look at the noise is AS A RF45Q in and out of lock. This sensor is used for dHard and we wanted to see if we could gain some insight into the cross-coupling issues between DARM and the angular loops (some previous insight here and previous decoupling work here). We mostly looked at the sum channel (essentially an rf DARM readout) rather than pitch/yaw. There aren't any stunning conclusions here, but if the sub-10 Hz noise is better understood it might provide some clues about how to make improvements.

We found some nonstationarity in the dark noise (wandering lines). With light on the diode in full lock, in the region 10 Hz to 100 Hz it seems like there is some broadband excess that is not a straightforward optical signal (from DARM or dHard).

We wonder if it would make sense to try more whitening on this sensor, as currently there is only one stage engaged (AS B RF45, which is not used for anything, has three stages engaged and hence better dark noise performance).

Dark noise

The first attachment shows the dark noise versus the in-lock noise of this sensor. During the maintenance period we unlocked the IMC and proceeded to measure the dark noise, and we were surprised to find a slowly wandering line in the vicinity of 4–7 Hz along with its harmonics (measurements in green and magenta). We were again surprised when we looked at the individual Q segments and found different responses to these lines (second attachment). For example, Q1 seems entirely insensitive to the fundamental of this line, but is the most sensitive out of the four quadrants to the harmonics. This second attachment also shows the dark noise of the AS B RF45Q quadrants, but since AS B RF45 has more whitening than AS A RF45, the two diodes do not readily lend themselves to comparison.

We also looked at some past times during maintenance days when it seemed the diodes had no light on them (although the IMC was unlocked); one such time is also plotted in the second attachment. Here there are no wandering lines, but the noise at and below 1 Hz is worse (the whitening settings have not changed, according to time machine). Maybe there was some signal since the IMC was still locked.

In-lock noise

The first attachment again shows the noise in AS A RF45Q sum during the full lock. The spectrum at and below 10 Hz is presumably optical signal (DARM plus other effects). The noise above 100 Hz is white, consistent with shot noise. Between 10 Hz and 100 Hz the high-frequency noise appears to aquire some shape that is not white. This region is not coherent with DARM except near various lines (e.g., the dither lines).

The rough calibration was reckoned as follows. Based on previous estimates of the AS port sideband content and the rough number of 250 mW of power leaving the SRM (via the calibration of AS C into milliwatts and the 800 ppm transmission of OM1), it seems that the 45 MHz beatnote signal should be of order 2 mW. Together with the dc value of the AS A RF45 sum channel in counts (about 10000), this can be used to infer that the total measured noise at high-frequency is about 10−7 mW/Hz1/2.

Comparison with DCPD sum

We also made a comparison of AS A RF45Q against the DCPD sum (third attachment). The rf sensor is scaled to match the dc sensor in the region 5–10 Hz, where the two are highly coherent. Above 10 Hz, the rf sensor's noise dominates over the dc sensor. The interpretation of the noises below 5 Hz is less straightforward. One thing that is apparent is that there are regions of high coherence (e.g., around 0.8 Hz) even though the two sensors show spectra with vastly different amplitudes. The sensors could be seeing the same noise, but with different coupling factors. Alternatively, a sensing noise peculiar to the dc readout (e.g., from the OMC) could be being impressed onto the loop and then witnessed by the rf sensor.

Plots for a longer stretch (6 hours, starting at 2019-09-21 09:00:00) of median-averaged data are also attached, with smaller binwidth. Here the large variability in the low-frequency coherence is more apparent.

A next step would be to run bruco on the DCPD sum and the RF45Q sum to see what the major contributors are at these low frequencies. I tried running bruco on Caltech ldas-pcdev12 (for only 1000 seconds), but it just hangs.

Non-image files attached to this report
Comments related to this report
evan.hall@LIGO.ORG - 15:23, Thursday 26 September 2019 (52152)

I am also attaching a comparison between AS A and AS B RF45 sums, along with some ADC count comparisions. AS B RF45Q maintains coherence with DARM up to higher frequency and has an overall lower noise floor than AS A RF45Q. AS B has not received the same careful rephasing as AS A (there is some DARM sensitivity in the I quadrature), but nonetheless is phased so that DARM mostly appears in Q.

It is also interesting to note that the low-frequency regions of high coherence with the DCPDs (0.8 Hz, 1.27 Hz, etc.) show up in both quadratures for both AS A and AS B even though (at least in the case of AS A) the phasing minimizes the appearance of DARM in I above 10 Hz.

The ADC count comparisons seem to indicate that turning on two extra whitening stages on AS A will increase the rms from 200 ct to something like 500 ct.

Non-image files attached to this comment
craig.cahillane@LIGO.ORG - 13:40, Friday 27 September 2019 (52162)
We turned on whitening stages two and three for AS_A_RF45.  

We did this in lock by switching the DHARD sensor from AS_A_RF45 to AS_B_RF45 with a gain of -1.25 in both the PIT and YAW sensing matrix.
Preliminary results suggest no DARM noise improvement, but lowered dark noise in the AS_A sensor above 10 Hz.  Noise was lowered by around a factor of 2.

Accepted this change into the SDF, and are back to observing.
evan.hall@LIGO.ORG - 17:49, Thursday 10 October 2019 (52411)

There was actually a bit of improvement in DARM between 15 and 20 Hz, though it's hard to see without sufficient averaging.

I took an hour of "before" data starting at 2019-09-27 17:30:00 and an hour of "after" data starting at 2019-09-27 20:25:00 and median-averaged it. The plots are attached (I omitted the DARM / dHard yaw coherence to keep the plot from getting overcrowded -- the overall coherence is lower than the pitch DOF). The improvement is subtle, but it's there, particularly at 19 Hz. The changes in coherence and in noise level are roughly consistent with the noise at 19 Hz being dominated by angular fluctuation.

Nothing is particularly surprising here given the previous noise budgeting injections.

Non-image files attached to this comment
H1 CDS (DAQ)
david.barker@LIGO.ORG - posted 11:45, Thursday 26 September 2019 (52148)
quick restart of h1nds1 to complete h1tw1 raw minute trend offloading process

WP8376

Dave:

At 10:50 while Robert et al were entering EY and we had just gone out of observe, I did a quick h1nds1 restart so it is now serving the past 5 months of raw minute trend data (up to 24 Sep) from its new archive location on h1ldasgw1. We did not see a repeat of control room DTT FOM issues, it looks like they reconnected to the nds.

To complete the offload I am now deleting the 256,000 files from h1tw1 SSD (ionice level 3, takes about an hour).

LHO General
corey.gray@LIGO.ORG - posted 10:56, Thursday 26 September 2019 (52147)
Morning Status (early mid-shift status)

16:34 - 17:47 Had H1 in OBSERVING.  (After a couple of locklosses, gave up and ran an alignment & made it to NOMINAL LOW NOISE on first attempt!)

Plan was to go to COMMISSIONING at 10:30amPDT (17:30utc) for EY TMS scatter work, BUT we have an S. America EQ inbound.  So plan is to now wait out the EQ and delay COMMISSIONING until we have finally ridden out the EQ. 

The EQ was a no show (so never transitioned to EARTHQUAKE!).  

17:47utc (10:47amPDT) Went to COMMISSIONING:

Talked with Tom Evans (LLO Operator) about this work over a landline (Teamspeak still down).

LHO General
corey.gray@LIGO.ORG - posted 08:01, Thursday 26 September 2019 (52144)
Transition to DAY Log

TITLE: 09/26 Day Shift: 15:00-23:00 UTC (08:00-16:00 PST), all times posted in UTC
STATE of H1: Lock Acquisition
OUTGOING OPERATOR: TJ
CURRENT ENVIRONMENT:
    SEI_CONF state: WINDY
    Wind: 18mph Gusts, 12mph 5min avg
    Primary useism: 0.02 μm/s
    Secondary useism: 0.21 μm/s

Microseism above the 50th percentile.
QUICK SUMMARY:

H1 was locking and TJ was tweaking PRMI/DRMI (currently he is optimizing DRMI for us to move H1 on).

NOTE On Summary For Yesterday:

I'm noticing my beautiful Shift Summary from yesterday is nowhere to be found!  (I don't see it in my drafts, and I remember clicking Post To Logbook last night, but maybe I did it in a rushed way...I forgot to hit submit as I was leaving, so I opened my laptop and clicked Post & then closed my laptop.)  Anyway, the only items worth noting:

LHO General
thomas.shaffer@LIGO.ORG - posted 08:00, Thursday 26 September 2019 (52141)
Ops Owl Shift Summary

TITLE: 09/26 Owl Shift: 07:00-15:00 UTC (00:00-08:00 PST), all times posted in UTC
STATE of H1: Lock Acquisition
INCOMING OPERATOR: Corey
SHIFT SUMMARY: Lock loss near the end of my shift. Just got DRMI locked but it doesn't look great...
LOG:

H1 General
thomas.shaffer@LIGO.ORG - posted 07:22, Thursday 26 September 2019 - last comment - 07:39, Thursday 26 September 2019(52142)
Lock Loss 1420 UTC

DCPD saturations 20 secs before lock loss.

Comments related to this report
thomas.shaffer@LIGO.ORG - 07:39, Thursday 26 September 2019 (52143)

Lock loss 1253542872

Looks to me likw DHARD_P started to pull away, followed by PRC2_P&Y and SRC2_P.

Images attached to this comment
LHO General
thomas.shaffer@LIGO.ORG - posted 00:05, Thursday 26 September 2019 (52140)
Ops Owl Shift Transition

TITLE: 09/26 Owl Shift: 07:00-15:00 UTC (00:00-08:00 PST), all times posted in UTC
STATE of H1: Observing at 116Mpc
OUTGOING OPERATOR: Travis
CURRENT ENVIRONMENT:
    SEI_CONF state: WINDY
    Wind: 12mph Gusts, 9mph 5min avg
    Primary useism: 0.02 μm/s
    Secondary useism: 0.24 μm/s
QUICK SUMMARY: 9 hour lock, useism seems to consistently at an elevated level.

H1 General
travis.sadecki@LIGO.ORG - posted 00:00, Thursday 26 September 2019 (52135)
Ops Eve Shift Summary

TITLE: 09/26 Eve Shift: 23:00-07:00 UTC (16:00-00:00 PST), all times posted in UTC
STATE of H1: Observing at 115Mpc
INCOMING OPERATOR: TJ
SHIFT SUMMARY:  No issues to report.
LOG:

23:14 Kyle back from MX

23:25 Dripta to PCal lab

0:13 Ethan to optics lab

0:16 Transition to EQ mode for Timor-Leste 6.5

0:24 Dripta and Ethan out

3:09 Back to WINDY

4:31 Out of Observing, Cheryl damping rung up 2nd harmonic violin modes

4:41 Observing

H1 CAL (CAL, ISC)
craig.cahillane@LIGO.ORG - posted 21:59, Wednesday 25 September 2019 (52139)
DARM calibration time constant
Jeff and I looked at thermal time constant of the calibration time dependent factors.
Soon after each lock, the GDS pipeline starts calculating some estimated cal params, including the spring frequency and DARM pole.

I looked at two-hour trends for the last six locks, and found the spring frequency settles in about 45 minutes, going from ~7 Hz to ~0 Hz.
The DARM pole was more noisy overall, going from 420 Hz to 412 Hz in about 40 minutes.

Code is in /ligo/home/craig.cahillane/Git/IFO/DARM/scripts/grab_time_dependent_factors.py and grabs the data using nds2, make sure to kinit.
Non-image files attached to this report
H1 IOO (IOO)
cheryl.vorvick@LIGO.ORG - posted 19:46, Wednesday 25 September 2019 (52138)
during H1 locking, majority of IM4 Pitch and Yaw alignment changes happen before power up

This is a follow up to my alog on September 1st, where I identified that IM4 pitch was changing by 60+urad during the H1 locking sequence, alog 51673, comment alog 51679, first plot.  In that plot, I also identified that IM4 Yaw was changing more than 20urad, and then changing back during the locking sequence.

Today I plotted IM4 pitch and yaw against the power control rotation stage, and the plots are attached, and what they show is that the majority of the alignment changes in IM4 happen before the rotation stage has taken it's first step in increasing power.

Images attached to this report
H1 CAL
jeffrey.kissel@LIGO.ORG - posted 17:49, Wednesday 25 September 2019 - last comment - 14:36, Friday 27 September 2019(52137)
Calibration Measurements: Full Suite Today, Last before the O3A Break; Some Interesting Results On Thermalization
J. Kissel

Grabbed the full suite of measurements for calibration today. This is the last collection of full sweep calibration measurements during O3A. 

Interestingly, because 13:00 UTC happened to land just after reaching nominal low noise, I was able to capture the sensing function measurements and broadband injections before the IFO had completely thermalized (typically taking about 1 hour), and after. Many more details and plots later, but here're the data files:

Sensing Function:
/ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/O3/H1/Measurements/FullIFOSensingTFs/
Pre-Thermalization:
    2019-09-25_H1_OMCDCPDSUM_to_DARMIN1.xml
    2019-09-25_H1_PCALX2DARMTF_BB_3min.xml
    2019-09-25_H1_PCALY2DARMTF_BB_3min.xml

    2019-09-25_H1_DARM_OLGTF_LF_SS_5to1100Hz_15min.xml
    2019-09-25_H1_PCALY2DARMTF_LF_SS_5t1100Hz_10min.xml
    2019-09-25_H1_PCALX2DARMTF_LF_SS_5t1100Hz_10min.xml

Post-Thermalization:
    2019-09-25_H1_PostThermalize_DARM_OLGTF_LF_SS_5to1100Hz_15min.xml
    2019-09-25_H1_PostThermalize_PCALY2DARMTF_LF_SS_5t1100Hz_10min.xml

    2019-09-25_H1_PostThermalize_PCALY2DARMTF_BB_3min.xml


Actuation Function:
/ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/O3/H1/Measurements/FullIFOActuationTFs/
    2019-09-25_H1SUSETMX_L1_iEXC2DARM_10min.xml
    2019-09-25_H1SUSETMX_L1_PCAL2DARM_8min.xml

    2019-09-25_H1SUSETMX_L2_iEXC2DARM_12min.xml
    2019-09-25_H1SUSETMX_L2_PCAL2DARM_6min.xml

    2019-09-25_H1SUSETMX_L3_iEXC2DARM_12min.xml
    2019-09-25_H1SUSETMX_L3_PCAL2DARM_6min.xml


I'll post the processed results tomorrow.
Comments related to this report
jeffrey.kissel@LIGO.ORG - 13:02, Friday 27 September 2019 (52145)DetChar, ISC
Interesting Sensing Function Results: Confirmation of Evolving Detuned SRC Optical Spring Seen By Time-Dependent Correction Factors, Impacting Response Function Systematic Error

Using the data collected above, I'm able to 
    - Confirm that the ~40 minute time constant for the regular evolution / thermalization of the signal recycling cavity's detuned optic spring frequency seen in the first attachment (an example from the 2019-09-25 summary page) and recently stacked over several re-acquisitions (see LHO aLOG 52139, because it's present at the start of every recent observation stretch) is a real effect during the interferometer's settling after powering up to 37 W. (Note: in the acquisition process, the time between "the input laser power has reached 37 W" and "we're ready for observation" is typically around 5 minutes, much less time than the thermalization takes.)

    - Though the estimate of the spring frequency squared (\xi^2 == f_s^2) from the calibration lines appears to suggest an evolution from "pro-spring" (\xi^2 == f_s^2 > 0, positive, like in August of O3) to just-barely-anti-spring (\xi^2 == f_s^2 < 0, negative, like in O1/O2) -- if any spring at all -- this contradicts the sweep data, which suggests the evolution instead goes from what we know to be an anti-spring response to just-barely-a-pro-spring.

    - At the beginning of the lock stretch, this does indeed result in significant magnitude and phase systematic error in the over all response function, contrary to popular belief that tracking this carefully ''doesn't matter, because the spring frequency is well below the DARM loop UGF.'' 

    - We also can confirm that during this evolution, that systematic error is NOT covered by our recent estimate of the time-independent, 68% confidence interval of the uncertainty budget (from LHO aLOG 52132)
   
    - Finally, once thermalized, however, the measured systematic error is remarkably consistent between lock stretches, and our propagated estimate of that error (via the guassian progress regression) is consistent with measurement.

Attachments to support this:
(1) H1-LOCKED_8DAD23_TIMESERIES-1253404818-86400_TDCFs_f_s_squared_During_Powerup.png: Again, this is an example report from the 2019-09-25 summary page for time-dependent correction factors (a.k.a. TDCFs; see full page here). However, it perfectly demonstrates one unperturbed acquisition (first decay of f_s^2), and the decay in the middle of which I was performing all of the 2019-09-25 measurements.

(2) 2019-09-25_H1_PrevsPostThermalize_sensingFunction_referenceModel_vs_allMeasurements.pdf: This is the standard analyzed plot for sensing functions, comparing against the new 2019-09-09 model -- which has no spring response in the model -- and it shows 
    (a) all of the sensing function measurements that went in to informing the 2019-09-09 model (all taken well in to a long observation stretch), and
    (b) the "Pre" and "Post" thermalized data from 2019-09-25. 
One can clearly see the anti-spring response in the 2019-09-25 Pre-thermalized data -- and note that this was taken at ~20:14 UTC, ~45 minutes after the start of the relevant observation ready segment 19:24 UTC. 

(3) 2019-09-25_H1_PreThermalize_sensingFunction.pdf Looking to gather estimates of what the spring frequency is during this already-45-minutes-thermalized anti-spring "pre-thermalized" measurement, in order to compare it against the calibration-line-reported-estimate of f_s^2, I used our standard MCMC infrastructure, and tested fits with a range from 5 to 5000, and from 20 to 5000 Hz (the latter of which we've used for thermalized data to inform the 2019-09-09 model). The results for the 5 Hz and up fit, which I believe are better are
    f_cc = 416.4 +/- 0.75 Hz
    f_s  = 2.137 +/- 0.03 Hz #anti-spring.
(Note: the optical gain / \kappa_C estimate in both cases agrees with the reference model to within 0.5%, and the Q_s estimate has always been poor / meaningless because of the remaining unknown response we think may be due to parasitic L2A2L coupling.)
This MCMC fit f_s = 2.137 Hz would correspond to an f_s^2 of 4.6 Hz^2, which is indeed roughly consistent with the typical time-series from the calibration line estimate, given that the data was taken ~2/3rd of the way down the exponential decay (and considering the time-constant analysis in LHO aLOG 52139).

(4) https://alog.ligo-wa.caltech.edu/aLOG/uploads/52145_20190926092701_2019-09-25_H1_PostThermalize_sensingFunction.pdf Now MCMC fitting the "Post Thermalization" data, taken around 21:33 UTC well after thermalization, I argue the fit using only-above-20 Hz is better, and it reveals 
     f_cc = 411.1 +/- 0.75 Hz
     f_s = 0.105 +/- 0.06 Hz #pro-spring
which is very much consistent with what's used in the 2019-09-09 model (411.3 Hz for f_cc, and 0.0 Hz for f_s, i.e. no detuning) as expected.

(5) 2019-09-26_H1_deltaL_over_pcal.pdf This is our money plot, comparing two ratios:
    (a) R_sample / R_MAP = "the uncertainty budget" = the reconstructed response function ratio, where the numerator is the 68% confidence interval of a distribution of response functions created by sampling the correlated posterior distributions of uncertainty in both the original model parameters and the estimated residual unknown systematic error (and its uncertainty), R_sample, and the denominator is the response function using the static parameters of the 2019-09-09 model. 
    (b) Delta L_PCAL / Delta L_EXT = The one-time measurements of a driven transfer function between PCAL and our front-end produced estimate of DELTAL_EXTERNAL, corrected for every known flaw of the front-end produced h(t), i.e. the ratio of R_GDS / R_CALCS. (For more details on the correction and why we need it, see T1900169).

For (b), I show 5 measurements -- 
    (i) a previous, 2019-09-16 broad-band injection when the IFO was well-thermalized. Consistent with uncertainty budget. Good!
    (ii) the broadband injection taken as soon as we went out of observing to start the 2019-09-25 calibration suite (~3 minutes of data at starting 19:51 UTC, ~25 minutes after achieving 37 W).
    (iii) the 2019-09-25 \Delta L / PCAL swept sine data taken at the exact same time as the "pre-thermalized" sensing function DARM_IN1/PCAL sweep described in (2) above that reports a spring frequency of 2.1 Hz (only!)
    (iv) the 2019-09-25 \Delta L / PCAL swept sine data taken at the exact same time as the "post-thermalized" sensing function DARM_IN1/PCAL sweep described in (2) that reports no spring.
    (v) a final broadband injection at the close of the measurement period.

(ii) shows a deviation of the systematic error on the level of 1% (at 60 Hz) to 2% (at worst at 25 Hz) in magnitude, and 1 deg in phase at 40 Hz.
(iii) shows that we're mostly "recovered" to the thermalized level of systematic error / uncertainty by 45 minutes after power up.
(i), (iv), (v) are all quite consistent.

See conclusions above. Stay tuned for further action.
    
Scripts to produce the attached plots:
    (1) is from the summary pages, as linked.
/ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/O3/H1/Scripts/FullIFOSensingTFs/
    (2) process_sensingmeas_collection_20190925_PrevsPostThermalize.py
    (3) process_sensingmeas_20190925.py
    (4) process_sensingmeas_20190925_PostThermalize.py
/ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/O3/H1/Scripts/CALCS_FE/
    (5) process_broadband_pcal2darmtf_collection_20190925.py
Images attached to this comment
Non-image files attached to this comment
jeffrey.kissel@LIGO.ORG - 14:36, Friday 27 September 2019 (52163)
Uninteresting Actuation Function Results: Much of the Same, these are another vanilla data set to be added the collection of data for Unknown Systematic Error to reduce the uncertainty.


All MCMC fits of each of the above UIM, PUM, or TST stage measurements, using the standard fit frequency range per stage, report the same answer as has been used in the model to within stated uncertainty.

Thus, we can lump these in with the collection of data used to estimate the unknown (or known but unaccounted for) systematic error to reduce the error estimates' uncertainty.

Processing scripts:
/ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/O3/H1/Scripts/FullIFOActuationTFs/
    process_actuationmeas_20190925.py
    process_actuationmeas_collection_20190925.py

Non-image files attached to this comment
H1 PEM (PEM)
adrian.helmling-cornell@LIGO.ORG - posted 17:16, Wednesday 25 September 2019 - last comment - 12:59, Tuesday 01 October 2019(52136)
Black Glass Blocking Stray Beam at HAM 3 Viewport as part of 48 Hz Investigation

Matthew Ball, Adrian Helmling-Cornell, Robert Schofield

Following up on our beating shaker injections, we found stray beams shining on the Ham 3 doors. We put black glass over the viewport with the brightest beam we observed (HAM3 illuminator viewport). More to come.

Comments related to this report
robert.schofield@LIGO.ORG - 12:59, Tuesday 01 October 2019 (52244)

This eliminated the 48 Hz peak: https://alog.ligo-wa.caltech.edu/aLOG/index.php?callRep=52184

H1 General
travis.sadecki@LIGO.ORG - posted 16:04, Wednesday 25 September 2019 (52134)
Ops Eve Shift Transition

TITLE: 09/25 Eve Shift: 23:00-07:00 UTC (16:00-00:00 PST), all times posted in UTC
STATE of H1: Observing at 115Mpc
OUTGOING OPERATOR: Corey
CURRENT ENVIRONMENT:
    SEI_CONF state: WINDY
    Wind: 16mph Gusts, 10mph 5min avg
    Primary useism: 0.03 μm/s
    Secondary useism: 0.28 μm/s
QUICK SUMMARY:  Just back to Observing after calibration measurements.  No issues to report.

H1 General
corey.gray@LIGO.ORG - posted 15:36, Wednesday 25 September 2019 (52133)
SDF Diffs: ASC Hard Loop Gains & ITM TRamps

Just made it back to NOMINAL LOW NOISE, and have  a few SDF Diffs.

1)  ASC Hard Loop Gains  (diff screenshot attached)

(Please see Jeff's specifics here.)

Evan was here, so I asked for his help.  Basically he:

Operators should be able to do this on their own, but the situation can be also be fixed by (1) touching up PSL alignment and/or changing Guardian script.

2) ITM TRamps (diff screenshot attached)

Keita and Matthew made changes to this during a Commissioning period today (REVERTED these).

Images attached to this report
H1 CAL
ling.sun@LIGO.ORG - posted 14:39, Wednesday 25 September 2019 - last comment - 14:36, Thursday 03 October 2019(52132)
Process all valid LF+HF meas for 0909 model and update uncertainty estimate

Lilli S, Jeff K,

All valid low-fre and high-freq meas for the new 0909 model are processed together (including 0821, 0828, 0904x2, 0909x2, 0916 LF meas, and 0903 HF meas).

The sensing GPR fitting results are attached in the pdf files.

The script used to generate the GPR fitting is:
^trunk/Runs/O3/H1/Scripts/Uncertainty/process_allmeas_includingPCALXHFdata_writeGPRHDF5_model20190909-C.py

The resulting hdf5 file is:
^trunk/Runs/O3/H1/Results/Uncertainty/O3_H1_C_GPR_20190909_nofsQcorr_fmin20Hz_lengthscaleZp5_withPCALXHFdata.hdf5

The uncertainty plot was generated using this command line:

python3 RRNom.py --IFO=LHO --HDF5_A_MCMCresults=/ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/O3/H1/Results/Uncertainty/O3_H1_A_MCMC_20190404.hdf5 --HDF5_A_GPRresults=/ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/O3/H1/Results/Uncertainty/O3_H1_A_GPR_20190909_multi.hdf5 --HDF5_C_MCMCresults=/ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/O3/H1/Results/Uncertainty/O3_H1_C_MCMC_20190904_nomconfig_fmin20Hz_finaltrial.hdf5 --HDF5_C_GPRresults=/ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/O3/H1/Results/Uncertainty/O3_H1_C_GPR_20190909_nofsQcorr_fmin20Hz_lengthscaleZp5_withPCALXHFdata.hdf5 --modelPath=/ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/O3/H1/params/ --modelFilename=modelparams_H1_20190909 --IFOmodel=modelPars --outDir=/ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/O3/H1/Results/Uncertainty/ --plot1SigmaUncs --sampleNumber=1000 --seed=1234 --version=ref --gpsTime=1251687618

The online uncertainty code will start to use this new hdf5 for 0909 model.

Images attached to this report
Non-image files attached to this report
Comments related to this report
ling.sun@LIGO.ORG - 10:03, Thursday 26 September 2019 (52146)

The last LF measurement before the break taken on 0925 was added to the GPR fitting. The fitting results are shown in the attached pdfs. The uncertainty budget slightly improves compared to the results posted yesterday. Here only one set of HF data is included (only the 0903 set is valid for the new model 0909). The HF part can be further improved when more HF data sets are added.

Images attached to this comment
Non-image files attached to this comment
jeffrey.kissel@LIGO.ORG - 10:28, Friday 27 September 2019 (52160)
I've re-run the RRNom.py command that Lilli indicates above, but have added the "--saveSummaries flag such that text files representing the curves above are saved:
python3 RRNom.py --IFO=LHO --HDF5_A_MCMCresults=/ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/O3/H1/Results/Uncertainty/O3_H1_A_MCMC_20190404.hdf5 --HDF5_A_GPRresults=/ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/O3/H1/Results/Uncertainty/O3_H1_A_GPR_20190909_multi.hdf5 --HDF5_C_MCMCresults=/ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/O3/H1/Results/Uncertainty/O3_H1_C_MCMC_20190904_nomconfig_fmin20Hz_finaltrial.hdf5 --HDF5_C_GPRresults=/ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/O3/H1/Results/Uncertainty/O3_H1_C_GPR_20190909_nofsQcorr_fmin20Hz_lengthscaleZp5_withPCALXHFdata.hdf5 --modelPath=/ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/O3/H1/params/ --modelFilename=modelparams_H1_20190909 --IFOmodel=modelPars --outDir=/ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/O3/H1/Results/Uncertainty/ --plot1SigmaUncs --sampleNumber=1000 --seed=1234 --version=ref --gpsTime=1251687618 --saveSummaries

The text files are now committed to the repo here:
/ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/O3/H1/Results/Uncertainty/
    2019-09-26_O3_LHO_GPSTime_1251687618_ref_RelativeResponseUncertainty_FinalResults.txt
    2019-09-26_O3_LHO_GPSTime_1251687618_ref_RelativeResponseUncertainty_MinMax.txt

ling.sun@LIGO.ORG - 14:59, Friday 27 September 2019 (52164)

Now I've added the last set of A meas (0925) to the hdf5 file: ^trunk/Runs/O3/H1/Results/Uncertainty/O3_H1_A_GPR_20190909_multi.hdf5. The resulting uncertainty budget is attached.

The GPR script is: ^trunk/Runs/O3/H1/Scripts/Uncertainty/process_allmeas_writeGPRHDF5_model20190909-A.py

The RRNom command is the same as above.

The txt summary files are ^trunk/Runs/O3/H1/Results/Uncertainty/2019-09-27_O3_LHO_GPSTime_1251687618_ref_RelativeResponseUncertainty_FinalResults.txt and 2019-09-27_O3_LHO_GPSTime_1251687618_ref_RelativeResponseUncertainty_MinMax.txt

Images attached to this comment
jeffrey.kissel@LIGO.ORG - 14:36, Thursday 03 October 2019 (52286)
To be consistent with the file name convention established in Chunks 1 and 2, I've changed the name of the script that produces the GPR estimate and committed the file name change:
/ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/O3/H1/Scripts/Uncertainty/
    process_allmeas_writeGPRHDF5_meas20190828-20191001_withHF_model20190909-C.py
H1 ISC (GRD, OpsInfo)
jeffrey.kissel@LIGO.ORG - posted 18:31, Tuesday 24 September 2019 - last comment - 15:28, Thursday 26 September 2019(52112)
Automatic Adjustment of Radiation Pressure Compensation (RPC) Gains on HARD ASC loops Based on Arbitrary Threshold of PSL Power Causes Gains Different From Normal
E. Hall, J. Kissel, E. Merilh

While clearing SDF DIFFs for the first observation ready segment after maintenance, we noticed that 4 channels on the h1asc model,
    H1:ASC-RPC_DHARD_P_GAIN
    H1:ASC-RPC_DHARD_Y_GAIN
    H1:ASC-RPC_CHARD_P_GAIN
    H1:ASC-RPC_CHARD_Y_GAIN
had diffs. These channels (loop gains) are a part of the radiation pressure compensation (RPC) system that Hang Yu designed (T1800077), to help compensate the arm angular degrees of freedom (CHARD and DHARD, Pitch and Yaw) for the change in response of these loops' at various 1064 nm arm power levels inside the arm cavities. Because the loop response depends on arm power, these gains are set based on the input power (as a proxy for arm power) by a function inside the ISC_LOCK guardian's ISC_library -- adjust_radiation_pressure_compensation (defined on line 305 of the current svn rev). Inside *that* function, there are human-set, hard-coded, input power thresholds set at 29.5, 33, 36.5, and 40 W, compared against the power in to the IMC (H1:IMC-PWR_IN_OUT16). As we know, (see e.g. LHO aLOG 51734), the input power is dropping slowly over time, and *today* for the first time, this power dropped below the 36.5 W at the time of measurement.

Thus, while cruising through the "run" portion of the INCREASE_POWER state -- just before MAXIMUM_POWER -- these gains were set based on the 33W configuration, instead of the 36.5W configuration we've running in throughout O3, i.e. some ~10% lower. This rightfully triggered the SDF warning in the h1asc comparison against its OBSERVE.snap later during NOMINAL_LOW_NOISE. However, it happened to occur in the middle of the automatic acquisition sequence when no one was otherwise touching the IFO, let alone this sophisticated, known to be carefully tuned, part of the ASC system.

Just because the PSL laser power has just so happened to drop the tiniest hair under exactly 36.5 W during the power up and this check, it didn't seem to us like a reason to change these gains. 

All that context to say that when we found this, we reverted the gains, but did it slowly and simultaneously:
    - increased the ramp time on these banks to 30 seconds
    - used a simple command line "caput" to push the gains up to their 36.5W values
    - reverted the ramp time
This went smoothly. 

The screen on which these filter banks live is a little tough to find. From the sitemap, go to ASC > Overview > "ASC ARM CAVITIES" for PITCH (in the top middle of the overview) > "HARD loop detail (rad press, blends)" button (in the middle left). This will pull up the attached screen.

All this aLOG is just in case it stumps operators again -- with the intent that one does not ACCEPT the values just because they're different, but REVERT them, slowly, with the above procedure.
Images attached to this report
Comments related to this report
corey.gray@LIGO.ORG - 15:28, Thursday 26 September 2019 (52153)GRD, PSL

Jenne updated the lscparams.py for a quick/temporary fix for this.  Basically we now request 38W (which gives us an Output Power of 37.5W). 

So now we do not have to change ASC HARD gains  which were coming up as diffs due to PSL power dropping.

Displaying reports 38461-38480 of 89074.Go to page Start 1920 1921 1922 1923 1924 1925 1926 1927 1928 End