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.
【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.
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.
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.
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.
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).
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).
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:
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:
DCPD saturations 20 secs before lock loss.
Looks to me likw DHARD_P started to pull away, followed by PRC2_P&Y and SRC2_P.
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.
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
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.
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.
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.
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
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
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.
This eliminated the 48 Hz peak: https://alog.ligo-wa.caltech.edu/aLOG/index.php?callRep=52184
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.
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).
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.
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.
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
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
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
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.
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.
We are undoing this change for now so that we have the option of closing the beam diverter.