I made a new version of the Matlab iopdownsamplingfilters.m script for use by the calibration group to apply the RCGv3.0.2 digital AA filter. The new file for use is stored at:
/ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/O2/DARMmodel/Scripts/iopdownsamplingfilters.m
Minor adjustments were made to the h1dustlvea EPICS database file to try to solve some oddities in the raw count channels. The h1dustlvea IOC was restarted several times, we are done for now and it should run over the weekend. Also killed the h1dustpsl IOC as it's no longer connected to dust monitors. The PSL dust monitors were connected to the LVEA network last week, and are now controlled by the h1dustlvea IOC.
I also uncommented TCS related lines in DOWN (Ln 417, 418) and COIL_DRIVERS (ln 2755, Ln 2756)
During the wind storms this week I collected data with a second STS at locations around the BRS and the GND STS that gets corrected for tilt, ranging from a huddle between the two STSs at 47cm apart to a maximum separation of 550 cm. For each location I found a period of the storm during which the average over 1664 seconds was close to 17 MPH. The figures show data only for these 17 MPH periods. I checked that in addition to averages within ½ MPH of 17, the extremes for each period were within a few MPH of each other.
Figure 1 shows the coherences between the two STSs (top plot) as well as the spectra when the movable one was closest or furthest from the wall (bottom plot). Orange, red, blue, black and thin black traces are for increasing separation. The coherence tends to drop with distance and drops as low as 0.75 at the two sites at 2.08 and 2.54 meters, blue and black. The spectra in the lower plot show that the tilt near the wall (dotted thick black) is more than twice the tilt only 2.54 m away (black). The thin black dotted line is for the furthest location from the wall, near the far pier of the BSC, and its tilt is about half of that at the BRS. The trend for greater tilts at sites closer to the wall is consistent. A better location for the BRS and the BRS-corrected STS might have been on the opposite side of the beam tube from the wall.
The top plot of figure 2 shows coherence between the BRS and each of the two seismometers. The best coherence that I got was for the red site, as close as possible and centered on the BRS. This red dotted coherence is better than the solid red coherence for the GND STS, taken at the same time. The coherence near the bases of the near and far piers was remarkably poor. This may explain why using the BRS to correct the chamber rather than the seismometer, such as BRS RX to ISI RX, would not be very successful.
The bottom plot of figure 2 shows the coherence between the Z-axes of the GND STS and the moveable STS. I include this because the effect of tilt on the Z axis is much less than on the horizontal axes so it tends to show the coherence lengths for the real displacements that we want to subtract using a seismometer. At 2.5 m from the GND seismometer, the coherence is down to 0.5 from about 0.3 to 1 Hz. This is also the case at the far blue piers on the opposite side at about 5 m away. It is unlikely that even the corrected GND STS helps much in this frequency band. Just as we are in the near field region for wind induced tilt, we are also in the near field region for wind induced vibration. The chamber and walls are only about 3 m from the wall that is bending according to the pressure distribution outside the building and the bending scale is meters.
For 1-5, ISI was set to off-line, HPI was nominal except that sensor correction was turned off. For 6, ISI was back on set for normal IFO operation
1) Huddled, igloos touching, 47 cm +Y of GND 5/6 3:00 to 5/7 00:00; 1664 seconds starting at 14:32:17, 6-26 MPH, ave 17 MPH
2) Huddled rotated by 10 degrees 5/7 04:00 to 5/7 16:00; 1664 seconds starting 5/7 at 15:02:17, 7-25 MPH, ave 17 MPH
3) Across BRS from GND and 20 cm -Y to center on Y of BRS, 133 cm distance, had to recenter so 5/7 19:00 - 5/8 23:50; 1664 seconds starting 5/8 20:56:17 4-32 MPH, ave 17 MPH OR 5/8 14:32:17 6-27 ave 17 MPH
4) Near -Y, +X leg of BSC10, +190 Y of GND, 208 total, 11:00 5/9 UTC to 15:00 5/9 UTC, if drift in Y-axis is OK, the start time could be extended back until 5/9 at 2:00 UTC; 1664 seconds starting 5/9 4:10:17, 4-37 MPH, ave 17 MPH
5) about 30 cm from edge of slab, 254 cm distance from GND, all in +X 16:00 5/9 UTC to 5/10 0:00:00; 1664 seconds starting 5/9 16:30:00, 5-30 MPH, ave 17 MPH
6) Near far (+Y, -X) BSC pier, +510 cm Y total 550 cm distance from GND. Start time 5/11 5:00; 1664 seconds 5/13 15:12:57, 7-31 MPH, ave 17 MPH
Robert & Hugh
H1 was available for commissioning this morning, and had tried to attempt locking, but had issues with the FSS (as noted by Kiwamu below).
Current H1 tasks:
Note: SEI would like to have a locked H1 (DC Readout?) for some measurements at some point.
New SEI configuration nodes (ISI_ETMX_ST1_CONF and ISI_ETMY_ST1_CONF) are now available from the GRD Overview as well as the the H1 Blend page under O-1 on the sitemap.
These nodes will control the configuration of the blends and sensor correction for the end stations. The states try to describe both the engaged blend filter as well as the sensor correction being used:
Blend_Quite_90_SC_BRS - Uses the BRS tilt-corrected sensor correction with the Quite_90 blends. The Quite_90s are the best blends we have for high winds, but do not do as well with the useism as the 45s. Using the BRS tilt corrected signal for SC helps with the wind as well as long as the BRS does not get rung up from the wind.
Blend_Quite_90_SC_None - Quite_90 blends with no SC filters enabled. Also could be used as a good all-around configuration, but not as good in the wind as the previous.
Blend_Quite_90_SC_useism - Quite_90 blends with the sei_notch filter in the WNR bank enabled for SC. The configuration for both high wind and useism. Since the Quite_90s can handle wind but not useism very well, the addition of this SC is meant to help when we have conditions with both wind and useism.
Blend_Quite_45_SC_None - Uses the 45Mhz blends with no SC filters enabled. The 45mHz blends perform much better in high useism conditions, but do not do well with wind.
Blend_Quite_45_SC_useism - Uses the 45mHz blends with the sei_notch filter in the WNR bank enabled for SC. This may help with the useism a bit more, or it may make it a touch worse. More testing is needed.
(Disclaimer: As testing progresses these states may change and the use of the states may also need some re-evaluation in the future.)
These nodes can turn ON and OFF the BRS SC by going into and out of the Blend_Quite_90_SC_BRS state. This node will also notify if the BRS damper is on, and then an operator should inform an SEI team member or switch out of a configuration that uses it. It will not automatically turn OFF the BRS SC if the damper turns on! (maybe in the future, but not yet). It will be the job of the operator or SEI team member to take action.
A few notes:
I attached a shot of the Guardian Overview with these new nodes, the updated H1 blend page, as well as the Ops Overview that now have a BRS SC Active/Inactive light.
The attached plot has the EndY and EndX Drift monitor signals for 45 days. The drift mon represents the reflected image on the linear PD of the BRS Beam DC position.
The bottom graph has the EndX Drift which is relatively stable(compared to BRSY) showing the daily fluctuations and trends up. Maybe these are warming periods?
The middle graph has the entire invacuum period of the BRSY showing this downward trend is definitely slowing.
The upper graph is the EndY from ~3 May when we rebalanced the beam to a time where I've extrapolated the slope (only about 6 days) out to a drift level when we'll need to balance again. We expect the drift to slowly ease and I've probably overestimated the slope. The limit is +-16000 so we should be okay into early next month.
General:
PSL crew will be doing work on the Diagnostic BreadBoard this morning(which should be non-invasive); so can attempt to lock H1. Went over Work Permits.
PSL: Diagnostic bread board work in the morning.
SEI: Blends & BRS work & would like H1 locked
SUS: Address PRM FRS#5489
Facilities: Trellis work, Beam Tube enclosure work
VAC: CP alarms (playing with PID parameters)
CDS: Dust monitor IOC restart
Commissioning: nothing to report
Corey, Kiwamu,
FSS does not lock on its own as reported Cheryl (27108). In addition, this morning we found that the range of the temperature scan was not good at all so that the autolocker was not finding a 00 mode at all. We have changed the range from [-0.025 K, 0.00 K] to [0.00 K, 0.025 K]. This improved the situation, but the FSS autolocker still keep failing the acquisition.
As Cheryl reported, disabling autolocker actually catches a 00 mode successfully for some reason. Having the autolocker enabled does not acquire a resonance, but rather kicks the servo out of resonance. We than guessed that this may be due to a loo-low oscillation threshold releasing the control loop unnecessarily, and pulled up the threshold from 1 V to 2 V. This setting acquired a resonance once for the first trial, but in the later trials, it never acquired a resonance.
The FSS autolocker needs a more thorough investigation.
The FRS#5494 can be found here.
We haven’t had an interferometer yet to evaluate the damping work that went on in HAM6 last month, so I looked directly at the peaks as seen by the GS13s. The HAM6 ISI suspension, specifically the blade springs and flexures, were damped in order to reduce vibration coupling to DARM. The HAM6 table top vibrates at its suspension resonances just as the test masses vibrate orders of magnitude more at their suspension violin modes than at surrounding frequencies. These table top vibrations likely couple to the light by moving the OMs or producing relative motion of OMC mirrors, perhaps enhanced by suspension resonances that overlap with the ISI suspension resonances.
Factors of as little as two increase over ambient vibration levels at HAM6 in the 900 Hz region were shown to produce features in DARM. In addition, this coupling was particularly worrisome because it is the only site with strongly non-linear environmental coupling. These vibrations intermodulated with the OMC length dither, producing features in DARM at higher and lower frequencies. The GS13 pods were also damped as a precaution, though no features in DARM appear at pod resonances.
The first figure shows the GS13 signals before and after damping. Below it is a DARM spectrum showing the peaks excited by pre-damping vibration injections at HAM6. The upper plot shows that the GS13 peaks at these frequencies are much smaller after damping then before, even though the ambient vibration level was slightly higher for the spectrum taken after damping. In places where the black after-damping spectrum is featureless, we are seeing the GS13 noise floor, and the difference between the red and black curves underestimate the improvement. Figure 2 shows the Y and Z axes.
Final evaluation will have to wait for measurements of vibration coupling to DARM, of course.
[Sheila, Jenne, Cheryl]
We can fairly reliably lock on DC readout, and get up to 20W.
The not-so-excellent news is that we are pretty sure we don't have a good error signal right now for the SRC1 loops. The last few hours have been spent hand-aligning the SRM to minimize POP90 (with SRC1 open, all other ASC loops closed), and trying to figure out what the appropriate combination of AS36 error signals is. However, this input matrix changes with power, and isn't necessarily the same lock-to-lock. Also, with the error signals that we think are right (using only a combination of AS 36 Is, no Qs), closing the SRC1 loops (esp. yaw) make us lose lock. We've had more success opening up the SRC1 loop at DC readout, and just leaving it alone while powering up.
We tried moving the beam splitter (by putting offsets in the MICH ASC loop) but that didn't ever help improve the POP90 buildup, only hurt it, so we are pretty sure (at several powers up to 14W) that the MICH ASC error signal is good, and holding us in the correct place.
We also tried moving CSOFT rather than SRM after a power-up to minimize POP90, since CSOFT P's error signal sees a jump when we power-up, but that didn't help either. It seems like SRC1 really is the loop that's causing problems, and allowing POP90 to increase and run away to lockloss.
With the technique of letting the SRC loops converge at DC readout, then opening SRC1, we can power up (in steps of 5W) to 20W and sit there. We started to see our dP/dTheta 0.5Hz instability when we went to 25W, so we backed off to 20W, and tried to get to low noise. As Sheila notes in alog 27518, we lost lock in the Coil Drivers state. But, we think that there's no reason we can't get back to 20W and hang out there.
Earlier in the evening, we reset the AS90 WFS dark offsets (very small changes), and reset their gains (moderately small changes) such that DC and AS90 WFS both read zeros while in DRMI-only lock with the arms held off resonance. But, there seems to not be much signal at all in AS_90_B_Pit, so it's still not clear that we can use them for our centering signals.
We have some thoughts on ways forward for SRC ASC on the whiteboard, including things like: re-looking at AS45I as an error signal, actuating on SR3 rather than SRM, trying the dither-align servos with SR3 rather than SRM, and looking at suppressing other REFL45 signals more strongly, so that we could potentially see some SRC signal there.
Separately, it would be good for someone tomorrow to try engaging the ISS second loop with just the MC locked at 20W, so that we know if it functions or not before we try it in full lock.
We are able to achieve brief stretches (30 seconds or so) of interferometer operation with up to 35 W of input power (with the SRC angular loops open, as said above). We seem to be running into the usual 0.4 Hz instability. Other than that, there doesn't seem to be anything catastrophic happening with the LSC or ASC during this power up (famous last words).
The outer loop can be engaged by hand with just the IMC (we did it a few weeks ago). It requires relaxing the trigger thresholds, though.
State of H1: locking, commissioning
Activities:
It looks like we need to do something about the triple coil drivers that we switch in lock, especially PRM M3. We have lost lock a good fraction of the times that we have tried to switch in the last month or so. Screenshot is attached, I also filed an FRS ticket hoping that someone might make an attempt to tune the delays while people are in the PSL tomorrow morning. FRS ticket #5489
Is the DAC spectrum post-switch using up a large fraction of the range? If the noise in the PRC loop has change a little bit it could make this transition less risky.
Here's the PRM drive from last night's lock, in which we just skipped the PRM M3 BIO switching leaving the low pass off (BIO state 1). It seems like we should have plenty of room to turn the low pass on without saturating the DAQ.
FRS Ticket #5489 closed in favor of a long-term fix Integration Issue #5506 (which is now also in the FRS system) and for an eventual ECR. Work permit #5880 indicates we'll install the fix tomorrow. See LHO aLOG 27223.
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.
Done
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.
