I ran the current version of the calibration pipeline over a stretch of O1 data to reproduce the kappas and compare to those in the C02 frames. The filters file used was aligocalibration/trunk/Runs/O1/GDSFilters/H1DCS_1131419668.npz, as suggested by the calibration configuration page for O1: https://wiki.ligo.org/viewauth/Calibration/GDSCalibrationConfigurationsO1#LHO_AN2 The agreement looks quite good. Time series plots of the kappas and the cavity pole are attached. The start time used here was 2016-10-04 12:41:19 UTC (GPS 1127997696).
alog 30897 has links to SRCL, PRCL and MICH BruCo's. Here hare some interesting highlights from those graphs:
SRCL:
Sure looks like our SRCL sensing is limited by input YAW jitter below maybe 25Hz.
BTW: MICH sees the same noise: CAL-CS_MICH_DQ
PRCL:
This looks like all our PRCL noise is jitter in the recycling cavity...
( ASC-POP_A_NSUM_OUT_DQ ... PIT is more than SUM ...
ASC-POP_A_YAW_OUT_DQ ... or YAW. )
Also interesting:
ISI-HAM3_SUSPOINT_MC2_EUL_L_DQ
I attached all plots for archiving purposes.
Out of curiosity, I looked at coherences of channels listed above from 24Oct2016 (Stefan's data above), and 24Jan2016 (a time when Gabriele ran a BruCo, so was probably a good lock time).
In the attached screenshot, the right half is coherences, and the left half is spectra of those channels. On the coherences half, top right is SRCL vs. IMC-MC2_YAW (ASC control signal), bottom right is SRCL vs. WFS_B_Pit (ASC error signal), top left is PRCL vs. POP_PIT and bottom left is PRCL vs. POP_SUM. On the spectra half of the screenshot, the top row is the length DOF signals, and the lower 2/3 of the plots are in the same locations as the coherences plots. In all plots, green is now-ish and blue is O1 config.
[MattE, Jenne]
We put in modification filters to the IMC WFS loops to move the existing lowpass filters from ~8Hz down to ~1Hz. Both filters (FM9 and FM10 in each DoF) must be on to actually get the full lowpassing.
This didn't change the SRCL noise, but it did reduce the coherenece with the MC2 angular control signal. In the attached screenshot, red is from earlier today (note that it is much less coherent than the green traces from 24Oct2016), and brown is after turning on these new lower lowpasses. I removed the blue and green traces from earlier to avoid too many traces on the plot, but the brown now is basically just as good as the blue from January.
Ed, Patrick and Jenne
Apologies if this is a repeat, but I've never seen this and was at a noticeable loss for action to take.
After the Lockloss at 23:30UTC, there was a diag main message that indicatd that ISC_LOCK wasn't going anywhere until the Fast Shuttter was tested. I'm making a Wiki in Troubleshooting H1 to address what to do in this situation. Jenne came to the rescue. Thanks Jenne!
Took well over 60 minutes to overfill CP3 by doubling LLCV to 36% open first, then open a little bit more, then a bit more, until finally it overfilled, I will change the setting LLCV from 18 to 20%.
Matt E., Dave, Jenne, Jeff K. and I tracked the problems with PI down to settings not being restored or not being restored correctly by SDF after the reboot on Tuesday. It is unclear if the problem with SDF was human or computer error. Jeff K. and Matt reverted the PI settings to those from a week ago. It appears that mode 27 is now back under control. 15:00 UTC Robert to end X to perform injections while at NLN 15:52 UTC Lock loss (PI mode 27). Tried changing sign of gain and turning off damping to no effect. 15:52 UTC Christine and Karen to mid stations 15:54 UTC Kyle to end X 15:54 UTC Robert back 15:56 UTC Robert to end Y to pickup hardware 16:15 UTC Changed to VERY_WINDY_NO_BRSXY ? Robert back 16:19 UTC Pausing at violin mode damping 2 waiting for roll modes to damp. 16:33 UTC Kyle back. Checked that RGA does not have a leaky valve. It does not. 16:50 UTC Karen leaving mid Y 16:52 UTC mode 27 starting to rise 16:59 UTC Lockloss Changed to WINDY during CHECK_IR 17:46 UTC Stopping at VIOLIN MODE DAMPING 2 again. 17:59 UTC King soft water through gate to check RO 18:04 UTC Changed BP filter for mode 26 from FM1 to FM8. Changed the set frequency to 207.8 from 207.7 Changed set frequency for mode 27 from 244 to 240. 18:08 UTC Turned on output to mode 27 damp filter 18:15 UTC Changed BP filter for mode 26 back to FM1. Changed the set frequency to 209. 18:19 UTC Daniel to LVEA Changed set freq for mode 18 from 207.9 to 207.8 18:45 UTC Daniel back 19:02 UTC Struggling to lock PRMI. Starting initial alignment. 19:10 UTC G Wave candidate alert 19:14 UTC Daniel to floor (WP 6294). Says I am going to lose the MC. Aborting initial alignment and setting ISC_LOCK node to DOWN. 19:43 UTC Daniel back. Restarting initial alignment. 20:19 UTC Initial alignment done 20:41 UTC Stopped at DC readout. Diagnosing PI and SDF. 22:44 UTC PI settings reverted. Going to NLN.
Discovered that the error point of the first ISS loop was changed to PDB about 23 hours ago. Why? Changed it back to PDA.
J. Kissel I'm not sure why, but INJ EPICs "settings" channels that are used to store, news, state and time information have become re-monitored in the SDF system, which means that the CAL-CS model shows differences when an external alert arrives and/our when a standard hardware injection goes through. I had removed the monitoring of these channels before O1 had started last year -- see LHO aLOG 21154 -- so I don't know why these have suddenly come back into monitoring. Merp. They're back to being ignored by the SDF system as they should be.
Kyle, John In and out of X-end VEA. Energized RGA filament and ran RGA just long enough to confirm that the Kr cal-gas isolation valve wasn't leaking at that the 5 x 10-4 torr*l of Krypton that I had dumped into the X-end had dissipated below detectable limits - OK all traces of Kr are gone.
Matt Daniel Fil (WP 6294)
The MCL and MCF readbacks have a 10/100 Hz Sallen-Key whitening stage which amplifies the high frequency spectrum to get above ADC noise. Since a while we have observed a 20-50 mHz/√Hz flat noise level in the these spectra when we are locked with the IMC only. Looking with the oscilloscope we estimated about 10m V signal between 100 kHz and 1 MHz, before the whitening. This seems too much for the AA board, so we included additional low pass filters in the readbacks with cut-offs around 15 kHz. A 15/150 kHz pole-zero was added to the Sallen-Key, and another 15 kHz pole was added to the output stage.
In detail (common mode board, IMC, s/n 1102626):
The attached spectra now show a frequency noise level which is compatible with the one observed in full lock. The coherence is also improved. The ADC noise is not too far away in regions with reduced coherence.
Here is a comparison between MCF fully locked and 2W IMC only (REF traces). The changes are much smaller now, indicating that MCF sees frequency noise from the laser.
The IMC shot noise limit here should be about 1 mHz/Hz1/2, assuming 0.3 mW of light (mostly carrier) on the PD with the IMC locked, 5 mW of light on the PD with the IMC unlocked, and a modulation depth of 0.01 rad.
Nutsinee's trouble damping PI mode 27 has continued into my shift. Trouble locking PRMI after the last lock loss. Starting an initial alignment.
After today's changes to the PMC servo, which included increasing the loop gain, we noticed a familiar bump around 4.2kHz in DARM. Lowering the PMC gain from 16dB to 0dB made the bump smaller in DARM (see images). Given the coherence with REFL9, it seems that this is coupling through frequency noise.
We also made a small exploration around the already good PMC input beam alignment. This didn't have much impact, but it revealed that small changes in the alignment can change the input offset to the PMC servo. That is, the offset which maximizes the PMC throughput can be changed with small alignment tweaks. Using this effect, we made a 0mV input close to optimal (see second image).
Tagging PSL and ISC.
Notes:
0) A2L gains of order two are getting suspicious, because it essentially means some coils are shut off.
1) ITMY_Y2L was always large (~-2) , but since 10/29 7UTC it is even bigger.
2) ITMX_Y2L also got big (~2) on 10/29 7UTC
Not sure what to make of this...
Tagging SUS.We should check functionality of coils.EDIT: Checked the functionality of the coils by taking a quick transfer function between COILOUT_EXC channels (OSEM basis excitation channels closest to the DAC output), and the various coil driver monitor channels. Though I've not taken the time to calibrate or understand the signals, I see no differences between the quadrants, and plenty of coherence between all drives and responses. I don't think there's anything wrong with the ITM L2 actuators. Note to self -- next time include OSEM sensors and optical levers in your template for those who don't trust the functionality of the coil driver monitor channels. The templates (attached) live here: /ligo/home/jeffrey.kissel/2016-11-02/ (apologies for my laziness -- I figured it would be faster to just create new templates than to find the one's Ed used to characterize the monitor signals that are likely committed to the SusSVN. #slapsownwrist) Also note that - The IFO was DOWN during this measurement. - I turned off the PIT optical lever damping during the measurement so as to not confuse anything.
For both PMC locking and injection locking, servo board and field box board were modified as per FRS 6500 (FRS id=6500 and alog 31047).
After the modified boards went in, we removed the 20dB attenuator on the PSL rack RF patch panel for 35.5MHz for PSL EOM.
This seems bump up the ILS and PMC length locking optical gain by about a factor of 10 (for ILS the analog gain was changed to compensate).
We also remeasured the demod phase for ILS and PMC length locking. For ILS we didn't see much change (1ns), but PMC was significant, we ended up changing 3ns, i.e. 39 degrees for 35.5MHz.
Demod setting are shown in the first two pictures, ILS (first attachment) and PMC (second). Third picture shows that the ILS is on the left bottom of the four delay lines, and PMC is on the right bottom.
The fourth picture shows the OLTF of PMC that is pretty close to the one we have now. Note that UGF is much much higher than before simply because of the optical gain and the demod phase (might have to change).
Unfortunately the floppy for SR785 failed, so we'll remeasure the ILS loop gain again tomorrow.
Here are the spectra of HVMons and Mixer_out, both in counts at the input and in calibrated in Volts.
J. Kissel, for M. Evans, D. Sigg, K. Kawabe With these electronics changes comes new compensation filters scattered throughout the PMC model, which has resulted in SDF differences. The following filter banks now have new filters that have been accepted into the SDF system as ON: H1:PSL-PMC_INOFFSET_CALI FM3 "LP1" zpk([],[1],1,"n") H1:PSL-PMC_MIXER FM2 "aWhite" gain(-0.005) H1:PSL-ILS_MIXER FM2 "aWhite" gain(-0.005) H1:PSL-ILS_HV_MON FM10 "aWhite" zpk([100],[1],-1,"n")
WP#6255 and WP#6293 completed 0930 hrs. local -> Valved-in RGA turbo to RGA volume and energized filament. 1130 hrs. local -> Took scans of the RGA volume with and without cal-gases -> isolated RGA turbo from RGA volume -> combined RGA volume with X-end volume and took scans of the X-end with and without calibration gases (inadvertently dumped ~5 x 10-4 torr*L of Krypton or 2 hrs accumulation @ 5 x 10-8 torr*L/sec into site) -> vented RGA turbo and removed from RGA hardware -> installed 1 1/2" UHV valve in its place -> Pumped volume between two 1 1/2" valves to 10-4 torr range before decoupling and de-energizing all pumps, controllers and noise sources with the exception of the RGA electronics which was left energized and with its fan running 24/7. Leaving RGA exposed to X-end, filament off and cal-gases isolated. Will post scan data as a comment to this entry within next 24 hrs..
Here are the scans from yesterday: Note the presence of amu 7 obviously "sourced" from the N2 cal-gas bottle. I will need to revisit the noted observation of the appearance of amu 7 when the cal-gas isolation valve used with Vacuum Bake Oven C is closed and the baffling disappearance of this amu when the isolation valve is opened???.
J. Kissel We're exploring the functionality of the new features of the front-end calibration that calculates the coherence and subsequent uncertainty of the transfer function between each CAL line source and DARM. As such, I plot three, one-hour data stretches from different lock stretches in the past 24 hours. Data Set A: 2016-10-31 02:30 UTC Data Set B: 2016-10-31 07:00 UTC Data Set C: 2016-10-31 10:00 UTC Note the translation between channel names and to which line they're analyzing: H1:CAL-CS_TDEP_..._[COHERENCE/UNCERTAINTY] Frequency Used In Calculating DARM_LINE1 37.3 kappa_TST (ESD Actuation Strength) PCAL_LINE1 36.7 kappa_TST & kappa_PU (ESD and PUM/UIM Act. Strength) PCAL_LINE2 331.9 kappa_C & f_C (Optical Gain and Cavity Pole) SUS_LINE1 35.9 kappa_PU (PUM/UIM Act. Strength) where you can refer to P1600063 and T1500377 Recall also, that our goal is to have the uncertainty in the time-dependent parameters (which are calculated from combinations of these lines) to around ~0.3-5%, such that these uncertainties remain non-dominate (lines are strong enough), but non-negligible (not excessively strong). An example total response function uncertainty budget in LHO aLOG 26889, to see at what level the time-dependent parameter estimation uncertainty impacts the total uncertainty. That means the uncertainty in each line estimate should be at the 0.1-0.3% level if possible. So, we can use these data sets to tune the amplitude of the CAL lines, so as to optimize uncertainty needs vs. sensitivity pollution. There are several interesting things. It's best to look at the data sets in order B, then A, then C. In data set B -- - this is what we should expect if we manage to get a stable, O1-style interferometer in the next week or so for ER10 and O2. - With the current amplitudes, the uncertainty on the ~30 Hz lines hovers around 0.1% -- so we can probably reduce the amplitude of these lines by a factor of a few if the sensitivity stays this high. - The 331 Hz line amplitude should probably be increased by a factor of a few. In data set C -- (this is during the ghoulish lock stretch) - One can see when the data goes bad, it goes bad in weird, discrete chunks. The width of these chunks is 130 sec (almost exactly), which I suspect is a digital artifact of the 13 averages and 10 sec FFTs. The sensitivity was popping, whistling, and saturating SUS left and right during this stretch, at a much quicker timescale than 100s of seconds. In data set B -- - This is an OK sensivity stretch. The good thing is that the coherence/uncertainty appears to be independent of any fast glitching or overall sensitivity, as long as we stick in the 60-75 Mpc range. - Interestingly, there's either a data dropout, or terrible time period during this stretch (as indicated by the BNS range going to 0) -- but it's only ~120 sec. If it's a data drop out -- good, the calculation is robust against whatever happens in DMT land. If it's a period of glitchy interferometer, it's very peculiar that it doesn't affect the uncertainty calculation, unlike with data set C. Based on these data sets, I think it'll be safe to set the uncertainty threshold at 1%, and if the uncertainty exceeds that threshold, the associated parameter value gets dumped from the calculation of the average that is applied to h(t). So, in summary -- looks like the calculations are working, and their calculated value roughly makes sense when the IFO is calm. There're a few suspicious things that we need to iron out when the IFO isn't feeling so well, but I think we're very much ready to use these coherence calculations as a viable veto for time-dependent parameter calculations.
Jeff K, Darkhan T,
We investigated further the 130s drop in coherence in the data set C (see LHO alog 31040 above).
This drop was possibly caused by a bad data point(s) ("glitch") at the beginning of this drop (when first glitchy data point entered the 130s averaging buffer). A quick look at kappas calculated in PcalMon from 10s FFTs during 600s around time of the glitch indicates that outliers in κTST and κPU values are found only in one of the 10s intervals. This interval is GPS [1161968880, 1161968890) (see attachment 1).
A look at slow channels indicate that the glitch produced impulse responses lasting just under 10s before 0.1Hz low-pass filter and roughly 30s after the filter, DARM_ERR
demodulated at 35.9 Hz (see upper panes in attachment 2, ). Start of the glitch is at ~1910s (GPS 1161968887). In the coherence calculation block of the CAL-CS model (attachments 3 and 4), it can be seen that the glitch lasts 20-30s in EPICS records preceeding the 130s averaging blocks (BUFFER_AND_AVERAGE), but results in reduction of the calculated coherence value for 130s (see attachment 5).
If we use coherence values from the CAL-CS front-end model as a threshold for "bad kappas", this kind of glithces will result in unnecessarily marking 130s of kappas as "bad". GDS median kappas should not be sensitive to this kind of short glitches, however CAL-CS front-end κTST were affected for ~250s (front-end kappas are low passed with a 1/128 Hz IIR filter) (see attachment 5).
A potential (not yet tested) solution would be to replace BUFFER_AND_AVERAGE (running aveage) script with a running median. And a similar script can be used for averaging of the front-end kappas, which would also reduce discrepancies between GDS and front-end kappas.