I forgot to de-energize the Pfeiffer turbo controller sitting on the floor -> someone from the Vacuum group can do this the next time they are in the LVEA.
Evan G, Darkhan T
Today we wanted to know the power impinging on the ETM per volt of drive requested to the OFS in the x-arm Pcal. To measure this, we used the 3001.3 Hz calibration line and made a point transfer function from H1:CAL-PCALX_TX_PD_VOLTS_OUT to H1:CAL-PCALX_OFS_PD_OUT_DQ. The OFS PD voltage is equal and opposite sign to the requested excitation, so it is a good measure of the magnitude of the excitation that is requested in counts.
Taking the transfer function between these channels at 3001.3 Hz, we find the transfer coefficient to be 0.4605 V/V
Then we can use the TX_PD_VOLTS calibration to convert this value to watts on the ETM, accounting for the optical loss. NOTE: the x-arm Pcal is currently suffering from apparent clipping, on the reciever side. So we use value of the TXPD calibration from May/Aug 2015 (LIGO-T1500252 v6, weighted mean value). At this point, we do not quantify the uncertainty due to the optical efficiency. This calibration value is 1.322e-9 N/V. Using the force-to-power conversion c/(2*cos(8.75o)) = 1.5166e8 W/N and the calibration value, we find the OFS volts-to-ETM watts transfer coefficient to be 0.0923 W/V.
This value can be used for quantifying the Pcal to length transfer function, aka the Pcal actuation function (which I will finish tomorrow!).
C. Cahillane I have generated corner plots of the time-dependent kappas to check their covariance. There are six kappa values: 1) Kappa_tst Mag 2) Kappa_tst Phase [Rads] 3) Kappa_pu Mag 4) Kappa_pu Phase [Rads] 5) Kappa_C 6) Cavity Pole F_CC We do get some values of covariance that are comparable with variance... However, all values, including variance, are sub-percent. I anticipate that if propagated into the uncertainty budget, all covariant terms would be negligible. We cannot be sure, however, without doing the work. For the LLO Kappa Triangle Plots, please see LLO aLOG 26134
J. Kissel, C. Cahillane A couple of notes from a discussion between Craig and I about these results: (1) The "Var" and "Covar" results reported on the plots are actually the square root of the respective element in the covariance matrix, multiplied by the sign of the element. Thus the reported "Var" and "Covar" value is directly comparable to the uncertainty typically reported, but the off-diagonal elements retain the sign information of the covariance. (2) Lest ye be confused -- the (co)variances (which are actually uncertainty values) are report at the *top* of each sub-plot, and the upper most variance value (for |k_TST|) is cut off. The value is 0.00234. (3) In order to compute the statistical uncertainty of these time-dependent systematic errors for the C02 uncertainty, Craig computed a running median (where the width of the median range was 50, once-a-minute data points; +/- 25 points surrounding the given time's data point) over the entire O1 time series, subtracted that median from every given data point, and took the standard deviation of residual time-series assuming that what remains is representative of the Guassian noise on the measurement. See original results in LHO aLOG 26580, though that log reports a range of 100 (+/- 50) once-a-minute points which has since been changed to the above-mentioned +/- 25 points for a more physical time-scale (but only changes the results at the 5% of the reported already ~0.3-0.5% uncertainty, i.e. the reported relative uncertainty of 0.002 change by 0.00005). For these plots, where he went a step further and computed the full covariance matrix on all time-dependent factors in order to address the question "is there any covariance between the statistical uncertainties, given that they're computed using -- in some cases -- the same calibration line?"). In doing so, he'd first taken the exact same median-removed time-series for each time-dependent factor, but found that the data set (i.e. the 2D and 1D histograms) was artificially biased around zero. We know now this was because, often, the median *was* the given time's value and residual was zero. Thus, instead, he recomputed the running median, disallowing the given time's value to be used in the median calculation. Graphically, x x x x x x x x x x x x x x x x x x x x x x x x x x [------------\_/-------------] x Raw data \_/ Given time's central value to which a median will be assigned and subtracted. [---] Median Window As one can see in his attached plots, that successfully de-biases the histogram. (4) The following time-dependent systematic error uncertainties *are* indeed covariant: (a) kappa_TST with kappa_PU (in magnitude and phase) -- the actuation strength of the PUM and TST mass stages. (b) kappa_C with f_cc -- the IFO optical gain and cavity pole frequency We know and expect (b), as has been shown in Evan's note T1500533. What's more is that it's *negatively covariant, so what estimation of the uncertainty we have thus far been making -- ignoring the covariant terms -- is actually an over estimate, and all is "OK." We also expect (a), because of how the two terms are calculated (see T1500377) and because they're also calculated from the same pair of lines. Sadly, we see that sqrt(covariance) is *positive* and of comparable amplitude to the sqrt(variance). But -- said at little more strongly than Craig suggests -- for these terms that have positive covariance comparable to the variance, the absolute value of both variance and covariance corresponds to an uncertainty (i.e. sqrt(variance)) on the 0.3-0.5% level, which is much smaller than other dominant terms in the uncertainty, as can be seen for example in pgs 3 and 4 of the attachment "05-Jan-2016_LHO_Strain_Uncertainty_C03_All_Plots.pdf" in LHO aLOG 24709. As such, we deem it sufficient to continue to ignore all covariant terms in the statistical uncertainty of these time-dependent parameters because they're either negative or, where positive, contribute a negligible amount to the overall statistical uncertainty budget compared with other, static statistical uncertainty terms.
I have updated the dtt calibration template for the DARM spectrum that are shown in the control room. This is for correcting for the new IOP decimation filters. I already applied this update to the latest DARM template, H1_DARM_FOM_20160229.xml.
The generation script is checked in the SVN at
/ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/PreER9/H1/Scripts/ControlRoomCalib/H1DARM_FOM_correction.m
This script returns an ASCII file where the calibration transfer function is written. The ASCII file can be found at
/ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/PreER9/H1/Scripts/ControlRoomCalib/DARM_FOM_calibration_new_20160512.dat
File was H1_DARM_FOM_20160130.xml, now H1_DARM_FOM_20160229.xml.
I copied the file to nuc3 controls, and updated the launch.sh file on nuc3 to point to this file.
I rebooted nuc3 because the web screen shot was blank. Unfortunately, diaggui could not find the new .xml file on the path supplied, so I reverted the file to the original. If the displays need to be changed, the CDS admins will be happy to help, perhaps fill out an FRS so we can track it.
I updated the ETMY L3 stage digital compensation filters (FM2, FM6 and FM7 of ETMY_L3_ESDOUTF_{UL,LL,UR,LR}_GAIN) to the more accurate ones which are based on the recent measurements by Evan and Jeff. The coefficients are already loaded, but we have not gotten a chance to use the ETMY ESD yet.
To minimize possible errors for editing the foton file, I wrote a python script which automatically populate the filters, rather than editing the file by hand. The script is in the SVN at
/ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/PreER9/H1/Scripts/SUS/setETMYLVVNcompensations.py
This is to note the measured state of the ETMY ESD electronics and the compensation (7 June 2016)
Measured analog electronics:
Diff Receiver Summing Node LP1 LP2 Overall DC Gain
(z:p) [Hz] (z:p) [Hz] (z:p) [Hz] (z:p) [Hz] [V/V]
UL 117e3:25.9e3 :3158.93 42.32:2.16 54.20:2.16 1.882
LL 167e3:27.6e3 :3229.11 42.93:2.08 49.73:2.09 1.881
UR 140e3:26.0e3 :3269.85 47.79:2.15 47.87:2.16 1.881
LR 160e3:26.7e3 :3323.42 47.17:2.06 47.61:2.20 1.881
Compensation filters:
AntiLP AntiAcq
(z:p) [Hz] (z) [Hz]
UL [2.1580;2.1590], [42.3160;54.2020] 3158.9340
LL [2.0810;2.0870], [42.9260;49.7260] 3229.1150
UR [2.1500;2.1570], [47.7850;47.8680] 3269.8530
LR [2.0640;2.1970], [47.1660;47.6100] 3323.4210
So the only uncompensated part of the anlog electronics is the zero-pole pair above 20 kHz.
State of H1: locked, commissioning
Activities:
(All times are local Pacific Standard Time)
Summary:
PSL crew worked in the PSL room in the morning and then H1 was available for locking and commissioning.
SEI Notes:
H1 Locking Notes:
Day's Activities
rpn3.png shows 3 relative power noise spectra taken today with the power stabilisation
locked with the gain slider at 6 dB - with and without the integrator - and at 9 dB,
after yesterday's alignment tweak into the pre-modecleaner and re-aligning of the
photodiode box.
As can be seen the integrator has little if any effect.
Jason, Peter
By popular demand, I have added a FE_STATUS legend to the CDS overview medm screen. This is slightly different from the STATE_WORD bits shown on the GDS_TP screens, so a legend is indeed useful. The first 9 bits match, I have dropped the OVERFLOW bit, shifted the CFC bit one left and added the DAQ (as seen from the DAQ) bit to the end.
The legend is a related display, please use the "SHOW LEGEND" button at the bottom of the overview screen.
Corey again had trouble with the XARM IR not locking today, and Jenne found that the optical gain seems to be 10dB higher today than it was on May10th 27082. We compared the power on ASAIR LF which had a change in power which was small compared to the dark offset, and the position on AS_C, which had moved in pit from -0.9 to 0. However, Jenne moved SR2 around to mimic these changes, and saw no change in the loop gain. So it seems like we have a 10dB gain change that we don't understand.
As a way of getting around this, I edited the filters in XARM IR to make our phase bubble a little bit wider, moving both kHz poles to 2kHz and moving a zero from 30Hz to 10 Hz. A comparison of the filters and the OLG is in the attached screenshot. We have lowered the digital gain in the guardian to 0.05 again.
I have written a simple script called which_models_are_using_this_file
It takes one argument, the name of the file either as a full path or name only, and reports all models which use that file. This will allow a source file change to be propagated to all models which use it and prevent possible surprises the next time a model is built (e.g. during an RCG upgrade).
> which_models_are_using_this_file /opt/rtcds/userapps/release/cds/common/src/LOW_FREQ_MUX.c
Models which use file: /opt/rtcds/userapps/release/cds/common/src/LOW_FREQ_MUX.c
h1omc
h1pemex
h1pemey
The FMCS screens which appear on the MEDM web view have been modified to include a date and time string. This should provide offsite viewers some assurance the data presented is current. A side effect of this is the screens as viewed from the vacuum controls workstations will have a white block where the date and time string is, similar to what is shown on the vacuum screens on those workstations.
Josh, user EcceruElme from GravitySpy beta, Andy User EcceruElme in the GravitySpy beta (a citizen science effort to classify detector artifacts) identified a new glitch class. They pointed out here that the glitches are not quite periodic, but the shapes seem to alternate - first upwards, then downwards. See the first plot. One time when this happens is Dec 12 at 21:31 UTC. Looking at more time, we realized that these are nearly periodic when you treat them as coming in pairs - first an upward glitch, then downward. The pair have a spacing of about 2.5 sec (or 0.4 Hz). The glitches go on for minutes, and then the lock ends. Comparing to a time earlier in the lock, several mirrors develop a big peak in pitch (and to a lesser extent length) motion around 0.4 Hz, as witnessed by the OSEMs. We see this motion in the beamsplitter, SRM and SR2 but not SR3, and in the OMC tip-tilts and the OMC suspension. The BS has a pendulum mode in length at 0.4193 Hz and in pitch at 0.4683 Hz. So it seems most likely that this resonance got rung up somehow, and then SRM and SR2 are following this to try to keep the beam pointed toward the tip-tilts (SR3 is uncontrolled and has no movement). Then the three tip-tilts and the OMC are following that motion - there are two degrees of freedom to center the beams on the WFS, and two more to keep it pointed into the OMC, which is why all three tip-tilts as well as the OMC suspension itself all move. The second through fourth plots are the motions of the BS, SRs, and tip-tilts in pitch. The fifth plot is motion of various OMC DoFs. It’s not clear why the beamsplitter is moving. It seems likely that the BS pitch resonance is the primary cause of the motion, but it may instead be tracking motion upstream. If the problem is the BS, maybe something is wrong with the local control or maybe some seismic noise is driving the resonance. It’s also not clear yet exactly how this couples in. These glitches do not look like scattering arches - they are too high in frequency, have no support at lower frequency, and also there’s no top part of an arch. So it may be jitter, or clipping. The best prediction of the glitches is the pitch position of SR2 as seen by the OSEM. One kind of glitch happens at the maxima, and one at the minima. The final attachment shows this. But we haven’t looked at all channels yet. Further work can be done by looking at other times when this kind of glitch occurs (GravitySpy can provide those), looking for the cause of the BS motion, and trying to find which of the alignment channels is the best predictor of the exact glitch times.
Measured both the filtered and DC output of the power stabilisation photodiode, a measurement that was limited at low frequencies by the noise of the SR785 (S/N 77457), which seemed to be somewhat higher than normal. The broad peak at ~45 kHz present is not present in the bias voltage, nor the power supply voltages. The photodiode showed no visible signs of damage. As a result I was reluctant to remove it from the circuit, plus it had the glass window taken off which makes it even more prone to damage if one was negligent. The filtered noise is consistent with the gain of 400 from the DC output. PDTF2.png shows the measured transfer function from the test point TFIN out to the test point X5 and the filtered output. Both are as they should be. Removed some extraneous flux from both sides of the circuit board, re-assembled the photodiode box and then re-installed it on the table. The sample output of the pre-modecleaner was aligned onto the photodiodes by peaking the DC output. The beam onto the internal quadrant photodiode was then re-positioned to zero the X and Y outputs as best as possible. The alignment into the pre-modecleaner was tweaked to try and minimize the free-running peak-to-peak fluctuations. The power incident on the photodiodes was adjusted so that the filtered output was not saturated. This seemed to be with a DC output of ~7.5V. Then power stabilisation was then engaged. Further alignment tweaks for the pre-modecleaner are probably warranted. Jason, Peter
State of H1: locked earlier, even showing a range, but earthquakes in the last 2 hours are preventing lock
On site: Commissioners Sheila and Evan, Operator Cheryl
Activities:
Sheila, Evan, Cheryl
With the ISS engaged were able to lock fine.
I edited the ISC_LOCK guardian to speed up DHARD_WFS a bit, it should be fine but we didn't get to test it because of a second Taiwan EQ.
About the demod phase: maybe due to the new decimation filters?
https://dcc.ligo.org/LIGO-T1600066
Also, see the attached.
Related log(s): 21131
Summary. - Today, I have updated the first anti-whitening filters of the OMC DCPDs in the OMC digital front end model in order to make them more accurately match the actual analog circuits. The attached show screenshots of the foton filters before and after the update.
Impact. - The new OMC DCPD responses are different from what they used to be by 1% at 10 Hz in magnitude and almost no change at 100Hz and above. The O2 DARM model must take this update into account. Note that even though the qualitative behavior of the mismatched anti-whitenings is similar to the large bias we have been seeing in the DARM response (for example 24569), they do not explain the bias (which is about 10% at 10 Hz in magnitude).
DCPD balancing. - According to my calculation, the balancing should be good at a 0.1% level without introducing an artificial imbalance in the OMC front end. So I removed the existing artificitial imbalace (-0.3%) and update the OBSERVE and DOWN SDFs. However, the imbalance should be experimentally double-checked and possibly re-adjusted.
Today, while Jenne and Sheila were re-tuning the OMC dither loops, I looked at the balance of two OMC DCPDs. The attached shows the null and sum spectra, and ratio between DCPD A and B.
The isolation between null and sum is as good as 66 dB, according to a injected line at 12 Hz (OM3 pitch by Jenne and Sheila). The two PDs match each other with a 0.1% level accuracy in magnitude and 0.1 deg level for the phase. This seems good enough for the moment. Though, we should check the responses above 100 Hz at some point.
Jeff K, Evan G
We (finally!) measured the ESD driver quadrant control voltage path transfer functions, which was needed because of the change made on Feb 9 (see ECR E1500341 and LHO aLOG 25468) for calibration/compensation use. Measurements are stored under
/ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/PreER9/H1/Measurements/Electronics/2016-05-06
Measurement notes attached. Analysis to come...
The anaylsis is done.
I wrote a matlab analysis script which automatically fits all the measured transfer function by calling LISO. The script can be found in SVN at
/ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/PreER9/H1/Scripts/model_ETMY_LVLN_driver_20160511.m
The results are attached and also can be found in SVN at
/ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/PreER9/H1/Results/Electronics/2016-05-11_H1SUSETMY_ESD_LVLNDriver_*.pdf
An update:
Evan and Jeff pointed me out that I could have also subtracted the reference transfer function ( = the transfer function of the measurement setup, including SR785 and diff-to-single-ended-convertor). So I edited the code so that it subtracts the reference out of each measurement. This impacted mostly on the gain of each measruement which are now 1.88. The resulting pdfs are attached.
I have moved the analysis code to a slighlty place at:
/ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/PreER9/H1/Scripts/Electronics/model_ETMY_LVLN_driver_20160511.m
The resulting pdfs are saved at the same location as the original ones.
