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.
Updated C:SlowControls on h1ecatc1, h1ecatx1 and h1ecaty1 to latest revision in svn. Restarted all TwinCAT code. Required multiple restarts. Burtrestored all to 6:10 this morning. A number of channels at end X have not yet reconnected. WP 5298.
Everything operating as expected. ISI also nominal.
From Ed's summary yesterday, assumed to be the same, since no emails about changing to Laser Hazard:
We are currently LASER SAFE in the corner and the ends. PSL is shuttered, CO2 LASERs are OFF. End station Viewports and tables are closed and locked. Not sure about the on/off statues of the ALS.
Timeline - Last night:
Timeline - This morning:
I had forgotten to mention the Pcal LASERs.
With a mix of old, really old, & non-functioning, I went ahead and replaced all H1 door handles and installed them such that all of these tables and the TCS tables are consistent (i.e. door handle opens the same way). I gave a pile of keys to Richard (who will probably pass on to Peter K, LSO). All tables are currently locked.
Calum, Matt, Kate
The floors around HAM6 were so spotless you could eat off of them. Thank you Karen and Christina!!!
A 4th cleanroom was added onto the current setup, along with 2 tables. We finished rinsing the last 2 panels with methanol. Drag wiped both uncoated and coated side of each panel at least 2x, and then added hardware.
Particle counts:
Particle Size (μm) | |||||||||
0.3 | 0.5 | 0.7 | 1.0 | 2.0 | 5.0 | Humidity | Temp | Notes | |
1:30 PM | 10 | 0 | 0 | 0 | 10 | 0 | 30% | 75 F | starting work |
3:35 PM | 30 | 10 | 0 | 20 | 0 | 0 | 35% | 71 F | |
4:30 PM | 0 | 0 | 10 | 0 | 0 | 0 | 37% | 70 F | before break |
5:17 PM | 30 | 0 | 0 | 0 | 0 | 0 | 37% | 70 F | after break |
6:29 PM | 0 | 0 | 0 | 0 | 20 | 10 | 35% | 69 F | end of day |
A while ago there was a request for representative spectra of current HAM ISI performance at LHO. I posted a number of documents like pngs, ascii data files and DTT xmls to T1500289 in the DCC. I've now posted a similar document for the ETMX BSC-ISI at T1500318. The data is from about 8 AM on June 11, during ER7, and it's not exhaustive, but useful for a quick snapshot of the BSC's current performance.
Forgot to mention: all plots are calibrated in nm/nrad.
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.