I have installed RCG version tag-2.9.3 on h1build and made it the default version. Any model builds from now onwards will be using 2.9.3. I performed a "make World" on all FE models, all built except for h1ascimc. I have not performed an install. There was no modification to the H1.ipc file.
There is no DAQ update for this version, it addresses SDF and guardian issues
==================================================================================================
Changes for 2.9.3 release
==================================================================================================
- Bug Fix (850): SDF changes.
- As requested for Guardian, changed skeleton.st to read filter module ramp time values before
offsets and gains.
The vacuum control workstation, control0, was rebooted due to poor performance (extremely slow). The top command showed a load average of 1.5, which should be OK for a multicore machine. After reboot, the load average dropped to 0.15. I will clean the air filters which are near totally plugged when I can find the HEPA anti-stat vacuum cleaner.
Below is the output from TJ's script for running the "PSL Check" (No Issues were posted during this check):
Laser Status:
SysStat is good
Front End power is 33.04W (should be around 30 W)
Frontend Watch is GREEN
HPO Watch is RED
PMC:
It has been locked 0.0 days, 21.0 hr 28.0 minutes (should be days/weeks)
Reflected power is 2.287Watts and PowerSum = 25.64Watts.
FSS:
It has been locked for 0.0 days 21.0 h and 28.0 min (should be days/weeks)
TPD[V] = 1.477V (min 0.9V)
ISS:
The diffracted power is around 8.16% (should be 5-9%)
Last saturation event was 0.0 days 21.0 hours and 19.0 minutes ago (should be days/weeks)
Items from meeting
Laser Safety: For any laser safety issues or Work Permit sign-offs please see John Worden (Peter King out till 7/13)
Morning Safety Meeting (Worden)
J. Kissel, for the Calibration Team Summary: As the calibration group begins to post representative, "best" sensitivities for engineering and observing runs, we must narrow down a process for deciding what is the "best" time. As such, I outline the process by which I've chosen the "best" ASD for ER7, which is formed from a 600 [sec] stretch of data starting at Jun 09 2015 14:41:44 UTC. This resulting H1 ER7 sensitivity plot (and associated ASCII dump of it), and all future official IFO sensitivity plots, will be linked from the top-level tree for sensitivity plots, found in G1500623. ----------- First, a not-so-brief recap of ER7 (and the weeks leading up to it), with calibration group goggles: For assistance, I show the sensemon inspiral range, as computed using the GDS-CALIB_STRAIN channel taken from DetChar's ER7 Summary Page, reattached here for convenience. Also from a different tab on the same page (the Segments Tab), where I get the ER7 H1:DMT-ANALYSIS_READY segment list shown below. - 2015-Apr to 2015-May Several DARM Open Loop Gain TFs are taken to estalished that the DARM Coupled Cavity Pole is stationary at 350 pm 10 [Hz] (LHO aLOGs 18186) - 2015-May-15 OMC Readout Gain Scaling between RF DARM and OMC Readout commissioned to allow for changes to IFO Power and DARM Offset while on DC readout (LHO aLOG 18470) - 2015-May-21 We finish installation of ESD low-noise, low-voltage driver (LHO aLOGs 18568 and 18579). - 2015-May-22 Suspiciously find that we have to flip the sign of digital requested ESD BIAS voltage to get the IFO to transition from EX to the new EY driver. - 2015-May-26 to 2015-May-29 - All measurements used to inform the actuation strength are taken (LHO aLOGs 18767, 18718, 18711, 18758) - All measurements used to set the sensing function's overall gain and informed the DARM loop frequency dependent uncertainty are taken (LHO aLOG 18769) - 2015-Jun-02 - Gain matching between RF DARM and OMC Readout more robust, such that OMC Readout 18768 - Frequency domain model is finished (settling on 355 [Hz] for the cavity pole frequency, though we hadn't gotten a good measure of it due to flaws in the DARM OLG TF model) and handed off to time-domain calibrators to convert to FIR filters (LHO aLOG 18769) - 2015-Jun-03 The night before / morning of ER7 Maddie restarts the GDS calibration code with newly updated filters from DARM Model (LHO aLOG 18813) - ER7 Starts, and we transfer the timeline to annotating the segment list: Segment GPS Start GPS End Duration UTC Start PDT Start Notes Number [sec] [ 0] [1117408143] [1117408494] [ 351] 'Jun 03 2015 23:08:47 UTC' 'Jun 03 2015 16:08:47 PDT' % ^ Double-counting of AA and AI filters in GDS-CALIB_Strain [ 1] [1117421174] [1117424706] [ 3532] 'Jun 04 2015 02:45:58 UTC' 'Jun 03 2015 19:45:58 PDT' % | filters (18813 and 19219) [ 2] [1117426833] [1117433922] [ 7089] 'Jun 04 2015 04:20:17 UTC' 'Jun 03 2015 21:20:17 PDT' % | exposed a bug in decimation of channel for SenseMon [ 3] [1117433927] [1117449201] [15274] 'Jun 04 2015 06:18:31 UTC' 'Jun 03 2015 23:18:31 PDT' % | calculation (see attachments 2, 3, and 4) [ 4] [1117450992] [1117457269] [ 6277] 'Jun 04 2015 11:02:56 UTC' 'Jun 04 2015 04:02:56 PDT' % | [ 5] [1117480924] [1117490420] [ 9496] 'Jun 04 2015 19:21:48 UTC' 'Jun 04 2015 12:21:48 PDT' % | [ 6] [1117493328] [1117499527] [ 6199] 'Jun 04 2015 22:48:32 UTC' 'Jun 04 2015 15:48:32 PDT' % V GDS filters are fixed after this segment [ 7] [1117507669] [1117545165] [37496] 'Jun 05 2015 02:47:33 UTC' 'Jun 04 2015 19:47:33 PDT' % --- [ 8] [1117561284] [1117562229] [ 945] 'Jun 05 2015 17:41:08 UTC' 'Jun 05 2015 10:41:08 PDT' % | Viable Calibration of GDS-CALIB_STRAIN [ 9] [1117570100] [1117592884] [22784] 'Jun 05 2015 20:08:04 UTC' 'Jun 05 2015 13:08:04 PDT' % --- [10] [1117601338] [1117665437] [64099] 'Jun 06 2015 04:48:42 UTC' 'Jun 05 2015 21:48:42 PDT' % --- IFO Configuration Changes! [11] [1117667359] [1117702258] [34899] 'Jun 06 2015 23:09:03 UTC' 'Jun 06 2015 16:09:03 PDT' % | Lots of things: [12] [1117709888] [1117743019] [33131] 'Jun 07 2015 10:57:52 UTC' 'Jun 07 2015 03:57:52 PDT' % | - IFO Input Power to 23 [W] :: Cause for Calibration Uncertainty (LHO aLOGs 18923 and 19031) [13] [1117748054] [1117773188] [25134] 'Jun 07 2015 21:33:58 UTC' 'Jun 07 2015 14:33:58 PDT' % | - ASC tuned for higher power (LHO aLOG 18923) [14] [1117803358] [1117814235] [10877] 'Jun 08 2015 12:55:42 UTC' 'Jun 08 2015 05:55:42 PDT' % | - ~300 [Hz] performance improved by changing IMC DC Alignment (LHO aLOGs 18877, 18894, 18929) [15] [1117814313] [1117815464] [ 1151] 'Jun 08 2015 15:58:17 UTC' 'Jun 08 2015 08:58:17 PDT' % | - MICH FF is retuned (LHO aLOG 18878) [16] [1117829201] [1117833161] [ 3960] 'Jun 08 2015 20:06:25 UTC' 'Jun 08 2015 13:06:25 PDT' % --- [17] [1117853451] [1117854502] [ 1051] 'Jun 09 2015 02:50:35 UTC' 'Jun 08 2015 19:50:35 PDT' % --- % Lock stretched polluted by Beam Tube Cleaning Glitches [18] [1117861010] [1117866838] [ 5828] 'Jun 09 2015 04:56:34 UTC' 'Jun 08 2015 21:56:34 PDT' % | [19] [1117868188] [1117878119] [ 9931] 'Jun 09 2015 06:56:12 UTC' 'Jun 08 2015 23:56:12 PDT' % | [20] [1117884319] [1117890432] [ 6113] 'Jun 09 2015 11:25:03 UTC' 'Jun 09 2015 04:25:03 PDT' % | Power restored to 17 [W] (though all above noise tunings remain, so sensitivity is better) [21] [1117890837] [1117891071] [ 234] 'Jun 09 2015 13:13:41 UTC' 'Jun 09 2015 06:13:41 PDT' % | Calibration Validity Returns [22] [1117891490] [1117897783] [ 6293] 'Jun 09 2015 13:24:34 UTC' 'Jun 09 2015 06:24:34 PDT' % | %%% <<< 600 [sec] OF THIS SEGMENT IS USED FOR "BEST" ER7 ASD %%% [23] [1117930374] [1117936993] [ 6619] 'Jun 10 2015 00:12:38 UTC' 'Jun 09 2015 17:12:38 PDT' % | [24] [1117937002] [1117940975] [ 3973] 'Jun 10 2015 02:03:06 UTC' 'Jun 09 2015 19:03:06 PDT' % | [25] [1117941598] [1117946873] [ 5275] 'Jun 10 2015 03:19:42 UTC' 'Jun 09 2015 20:19:42 PDT' % | [26] [1117984389] [1117987778] [ 3389] 'Jun 10 2015 15:12:53 UTC' 'Jun 10 2015 08:12:53 PDT' % | [27] [1118009073] [1118009809] [ 736] 'Jun 10 2015 22:04:17 UTC' 'Jun 10 2015 15:04:17 PDT' % | [28] [1118019595] [1118022123] [ 2528] 'Jun 11 2015 00:59:39 UTC' 'Jun 10 2015 17:59:39 PDT' % | [29] [1118038511] [1118088249] [49738] 'Jun 11 2015 06:14:55 UTC' 'Jun 10 2015 23:14:55 PDT' % --- END OF FOCUS DATA TAKING during this lock stretch, at 1118070016 (LHO aLOG 19085) % --- ESD Driver is RESET for charge testing, (LHO aLOG 19095) % | This inadvertently changes bias voltage and actuation strength (LHO aLOG 19110) % --- Reset driver's digital bias properly compensated before this lock stretch [30] [1118207683] [1118207892] [ 209] 'Jun 13 2015 05:14:27 UTC' 'Jun 12 2015 22:14:27 PDT' % --- [31] [1118212512] [1118213354] [ 842] 'Jun 13 2015 06:34:56 UTC' 'Jun 12 2015 23:34:56 PDT' % | Remaining locks have wrong and uncertain actuation strength [32] [1118268553] [1118269137] [ 584] 'Jun 13 2015 22:08:57 UTC' 'Jun 13 2015 15:08:57 PDT' % | between reality and GDS-CALIB_STRAIN [33] [1118303427] [1118329216] [25789] 'Jun 14 2015 07:50:11 UTC' 'Jun 14 2015 00:50:11 PDT' % --- ---------------- Now that I've established which lock stretches I can use that are calibrated to within the stated uncertainty of 50% in amplitude and 20 [deg] in phase (as stated in LHO aLOG 18769), which are segments viableSegments = [7:9 17:29]; I began to search for the best lock stretch. To do so, I plotted a time series of the sensemon BNS inspiral range produced from H1:GDS-CALIB_STRAIN, i.e. 'H1:DMT-SNSH_EFFECTIVE_RANGE_MPC.mean,m-trend' (SNSW is calculated from CAL-CS, which we know is in-accurate; see G1500750), and can immediately found that the sensitivity of the latter segments were better (again, because of Robert's tuning of the IMC alignment to reduce the coupling of angular jitter on the beam from the PSL, which happened during the 23 [W] segments LHO aLOG 18929), viableSegments_wGoodRange = [17:29]; This plot is shown in the first page of the attached .pdf, and was generated by the script, /ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/ER7/H1/Scripts/segments_ER7.m Looking for the longest lock stretch with most consistently high range, I chose the 22nd segment, starting at 1117891490, 'Jun 09 2015 13:24:34 UTC', 'Jun 09 2015 06:24:34 PDT'. Once I had this lock stretch, I used /ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/ER7/H1/Scripts/produceofficialstrainasds.m which narrows down the lock stretch into a "best" 600 seconds, where the length of the time-series, 600 [sec], is chosen because I desired a binwidth of 0.185 [Hz] and many-many averages (it works out to be 111 averages, using asd2.m), so the end-resulting ASD is nice and clean looking. Here's how I narrowed down which 600 [sec] of the 6293 [sec] long lock stretch (follow along with pg 2 of the .pdf attachment): - Zoom in on the SNSH-calculated, inspiral range time series over the entire lock stretch. (shown in blue) - Take the median of the SNSH-calculated, inspiral range time series over the entire lock stretch. The median for this lock stretch is 66.8 [Mpc] (shown as the green dotted line). I chose the median (instead of the mean) so as to not be influenced by the outlying drops in range due to glitches. - Take a rolling median equivalent to 600 sec (i.e. 10 of the 60 [sec] minute trends points), and find the rolling median which differs the least from the overall mean. (the red squares) - Set the start time of the time series to be at the time of the first point of that best rolling median. At first, I had merely selected the maximum range in the overall lock stretch (the pink point), but quickly realized that 600 [sec] of data included one of the 8 [Mpc] glitches in the time series, and wanted to avoid such things. Finally, on pages 3, 4, and 5 of the attached pdf, I show the selected, calibrated time series, and the corresponding, 111 averages, 0.185 [Hz] frequency binwidth, strain and displacement amplitude spectral densities. Note, the displacement ASD is merely the strain ASD multiplied by the exact mean arm length used in the DARM Open Loop Gain Model: mean([model.C.armLength.x model.C.armLength.y]) = 3994.4698 [m] The BNS sensemon inspiral range and horizon distance were computed by /ligo/svncommon/CalSVN/aligocalibration/trunk/Common/MatlabTools/BNS_range.m a new matlab function which uses exactly what the CBC group uses, as defined in the final S6 performance paper T1100338, and expanded in gory detail in T1500309.
Stefan, Dave:
we temporarily hooked up two timing signals in EY this morning and early afternoon. After acquiring data we have reverted the system back to its original configuration.
IRIG-B signal in frame.
To acquire the IRIG-B signal into the DAQ frame, we used the PEM channel H1:PEM-EY_MIC_VEA_MINUSY_DQ for this measurement. This channel was recording the IRIG-B signal between the times:
19:45 - 21:53 UTC.
To route the IRIG-B from the computer rack we borrowed the BNC coax cable which normally routes the 1PPS from the TCT to the first channel of the timing comparator. Therefore this comparator channel did not have any useful signal between the times 19:45 to 22:45 UTC. It is now restored to its running condition.
Local GPS receiver into Comparator.
To check what would happen if a local GPS receiver's 1PPS were to be connected to the timing comparator, we hooked the Symmetricom GPS receiver (which is in the VEA CDS rack and connected to an iLIGO GPS antenna on the roof) to the second comparator port. To acheive the connection, we found a long BNC coax cable which runs under the roll-up door between the CER/EBAY and the VEA. It was disconnected both ends. The GPS receiver was already powered on and had green LED indicators, so we assumed it has good satellite coverage. The comparator recorded a time difference of about 100nS. After the conclusion of the test, the long BNC coax cable was disconnected both ends and re-coiled.
Ops Day Summary:
As of 2:00PM
as of 2:06PM
as of 4:00OM
I updated the fmcs alarm config file to put the RO Water system in it's own catagory, so it's easier to see, and easier to differentiate RO Water from alarms that are truely CRITICAL the moment they trigger.
New RO_WATER Guidance:
$GUIDANCE
Reverse Osmosis Water System is in alarm.
The site may have potable water for
a while, but eventually will run out.
Call John or Bubba
$END
Channels removed per John's OK:
CHANNEL CRITICAL H0:FMC-MY_CY_H2O_SUP_DEGF
$ALARMCOUNTFILTER 300 300
CHANNEL CRITICAL H0:FMC-MY_CY_H2O_RET_DEGF
$ALARMCOUNTFILTER 300 300
CHANNEL CRITICAL H0:FMC-MX_CY_H2O_SUP_DEGF
$ALARMCOUNTFILTER 300 300
CHANNEL CRITICAL H0:FMC-MX_CY_H2O_RET_DEGF
$ALARMCOUNTFILTER 300 300
No longer CRITCAL alarms, and do not need to be in the fmcs alarm handler.
The high-voltage power supplies for the PSL servos ( in rack PSL-R2 ) were relocated to the CER mezzanine. Effected boards are: PSL Injection Lock Servo - T0900577 PMC Locking Servo - T0900577 TTFSS Fieldbox - D1100367 Peter King was able to lock PMC after our work was complete.
In an email conversation Norna had asked what we could do to reduce motion on the HAM's in the RX/RY dofs at 25-35 hz. This morning I took a few measurements to design a FF filter. I've taken a first pass at it and I think I have something that works. Attached spectra are of the ground STS X and GS13s in RY the first png, then both sensors in X on the second plot. The live measurements are with FF on, references are from a quiet time last night, FF off.
The third attachment is a plot from the script I used to do the filter fit. Blue is the filter, green is the ideal fit from the St0 L4C's to the ISI GS13's, red is the fit from the HEPI L4C's to the ISI. The design approach is exactly the same as I talked about in my alog 18045.
I also have Y and Z feedforward working on the SRC HAMs. I attach performance plots (taken at the same time as the plots from my main post). These have been running on HAM4 for a little while (sometime after ER7 ended), but I never got around to doing the alog and I was a little more organized when I installed them on HAM5 today. First plot is Y, second is Z. Active measurement is with FF on, reference is FF off. Again, we really need a cavity to say if these are good enough, but I leave them running for now.
I've looked at X, RX and RZ, but RX and RZ show low coherence and X looks... messy, see last plot.
That was quick! Looking good. Thanks.
J. Kissel, J. Warner Some additional information and/or a "current status:" ISIs HAM2 and HAM3 do not have any ST0 / HEPI L4C feed-forward running. ISIs HAM4 and HAM5 have Y, Z, and RY ST0 L4C (not HEPI L4C) feed-forward running. (HAM6 is currently vented and the ISI and HEPI are locked.) The HAM4 and HAM5 filters, for Y, Z, and RY live in FMs 2, 3, and 4 respectively. The gain for all DOFs on both HAMs is 0.5. Norna's designing / modelling how adding blades between the HSTS's lowest stages will improve performance in the SUS's vertical displacement. The input motion for the SUS's suspension point in vertical is composed of the ISI's center of mass moving in Z, RX, and RY (see T1100617). She noticed from the results Jim posted (T1500289), that at 25-30 [Hz], the input V motion was dominated by RX / RY of the table. So, among other ways to improve the performance at these frequencies (see them discussed in SWG aLOG 11327), Jim tried improving the RY DOFs today -- and won! Nice work, as always, Jim!
There was a problem with HAM5 at the time I took this data. I've taken new measurements from HAM4, see alog 19343. Conclusions remains the same, I think, but the data is cleaner.
Committed the change to svn and restarted all of the code. Burtrestored to 6:10 this morning.
J. Oberling, E. Merilh
We swapped the oplev laser for ETMx; power cycling the laser did not improve its behavior. Old laser SN 197, new laser SN 106-1. The old laser will be bench tested to see if we can find out what's wrong and if there's anything we can do about it here (possible return to MicroLaser)
We installed the 50lb lead vibration absorbers on the ITMx and ITMy oplev receiver piers. The ITMx oplev did not need to be realigned after the installation; we did however realign the ITMy oplev after installation. All lead vibration absorbers are now installed at LHO (ETMx, ETMy, ITMx, ITMy).
Added 262 channels. Still 707 channels unmonitored since restart of end X TwinCAT code.
Dave restarted the gateway and the channels have reconnected.
Calum & Kate
Finished unwrapping and inspecting all 26 panels of black glass. 100% of the parts made it in one piece and all of the coatings look good. This is great news! The panels are dusty, smudgy, and streaky; and will need to be cleaned (this was expected). The plan is to use a methanol rinse followed by drag wipping. 24/26 pieces of glass were rinsed 2x, so we're about halfway through the cleaning effort. Currently using 3 large cleanroom tables, but we'll need at least one more for prep work.
Two points of note for LLO:
1) The following parts were packaged between 2 sheets of float glass:
D1500054-101 & 102
D1500055-101 & 102
It was a good idea to protect the oddly shaped parts, but care should be taken when opening them because a couple pieces of the float (packaging) glass had chips and cracks and these were spread around the wrapping. Again these did their job and protected the black glass (which was in good shape) just a heads up.
2) Some of the parts are double packed in the bubble wrap. Again caution when opening.
All of the black glass at LLO was unwrapped today and laid out on a flow bench in the optics lab for inspection. Upon initial inspection for damage, there were no obvious chips or dings in any of the glass. The odd shaped pieces were in great shape with no abnormalities around the edges due to being sandwiched between glass for packing (the float glass was even flawless). Tomorrow we will check the coatings and begin the cleaning process. I will leave it to the inspection crew to record tomorrow but there were a few minor spot flaws in the coating on about 3 pieces.
I set up an accelerometer on the beam tube and measured the accelerations as I simulated the tapping that I observed during cleaning, and my tapping experiment mentioned here: https://alog.ligo-wa.caltech.edu/aLOG/index.php?callRep=19038. Examination of the time series indicated that accelerations during typical taps reached about 1 m/s^2. I suspect that some taps reached 1g. The figure shows spectra for metal vs. fist taps. The above link notes that I was unable to produce glitches while hitting the beam tube with my fist. The fist and metal taps both had about the same maximum acceleration of 1 m/s^2 (ambient acceleration levels are about 4 orders of magnitude lower), so the source of the difference in liberating the particles is probably not acceleration. Instead, it may be the change in curvature of the beam tube, which would be expected to be greater at higher frequencies. The responses from metal taps in figure 1 peak at about 1000 Hz while the fist taps peak at about 100 Hz. These results are consistent with a hypothesis that the metal oxide particles are liberated by fracture associated with changes in curvature rather than simple vertical acceleration.
When I was producing glitches in DARM for the link above, I noticed that we did not get glitches every metal tap but every several metal taps. I tried to quantify this by making many individual taps at several locations along the beam tube. Unfortunately, we lost lock with the first loud glitch and I did not get a chance to repeat this before the vent. Nevertheless, it would be good for DetChar to look for smaller glitches at the time of the taps given below. Allow a 1 second window centered around the times given below for my tap timing uncertainty. I tapped once every ten seconds, starting at ten seconds after the top of the minute so that there were six taps per minute.
UTC times, all on June 14
Location Y-1-8
20:37 - 20:38 every ten seconds
20:47 - 20:50 every ten seconds
Next to EY
20:55 - every ten seconds until loss of lock at 20:56:10
I don't think the IFO stayed locked for the whole time. The summary page says it lost lock at 20:48:41, and a time series of DCPD_SUM (first plot) seems to confirm that. I did a few spectrograms, and Omega scanned each 10 seconds in the second series, and the only glitch I find is a very big one at 20:48:00.5. Here is an Omega scan. The fourth tap after this one caused the lock loss. Detchar will look closer at this time to see if there are any quiet glitches. First we'll need to regenerate the Omicron triggers... they're missing around this time probably due to having too many triggers caused by the lockloss. I'm not sure why there's a discrepancy in the locked times with Robert's report.
Any chance this could be scattered light? at 1 m/s^2 and 1 kHz, it is a displacement of 25 nm, so you don't need fringe wrapping.
I think that you would expect any mechanism that does not require release of a particle to occur pretty much with every tap. These glitches dont happen with every tap.
[sus crew]
Following the in chamber work from today at end-Y we took quick TFs on the quad and the transmon. They look ok.
Since the pump won't happen before tomorrow I started matlab tfs for all DOF.
The measurement will be running for few hours.
More clue on the TMSX measurement showing a different TF than before the vent (cf log below 19246). I looked at the response from pitch and vertical drive to the individual osems (LF, RT) and it looks like something is funny with the RT osem which should have the same response as the LF one, cf light red curves below
EDIT : Actually, LF and RT osem response are superposed on the graphs (green LF lies under red RT), so their response is the same.
ETMY ant TMSY transfer functions were measured on thursday after the doors went on, with chamber at atmospheric pressure. They did not show signs of rubbing, cf the first two pdf attached showing good agreement with previous measurements.
Today, I remeasured the vertical dof, after the suspension sagged ~120um from the pressure drop, and it still looks fine, cf figures below.
ETMX and TMSX were measured today when pressure in chamber was about 3 Torrs, after the QUAD sagged by about 130um.
The second pdf attachment on the log above was supposed to show TMSY transfer functions. Attached is the correct pdf.