Day Shift: 15:00- 23:00UTC (8am-4pm PDT)
Today's Activities:
J. Kissel, T. Sadecki, B. Weaver Same story for ITMY as was ITMX. Transfer functions look fabulous, with no evidence of mechanical flaws. Let's push things forward! Excellent work, team QUAD!
Noticed this swing in PSL table North temperatures.
Also seen in AOM power, and slightly in IMC power in (though IMC power in is low, at 60mW).
Rotation stage has not been moved, and PMC Trans drop is reason we are at 60mW into HAM1.
Depending on what beam quality is needed for work on the SRC that's coming up, temperatures may need to be stabilized in the PSL, to stabilize power.
This looks somewhat similar to what we saw this last March with the AC causing swings in the PSL temp even though it was off (alogs 34497, 34586, 34642, 34673, and 34686. Final resolution was to turn the ACs off at the breaker box.). To my knowledge, the PSL AC units at LHO are only used to keep the HEPA fans from spiking the temperature when they are turned on when a PSL incursion is required and to keep the enclosure comfortable for those working inside, not to keep the interior enclosure temperature tightly controlled. Remember, the HEPA fans and AC units are turned completelly OFF, with the make-up air set to 20%, when the LHO PSL enclosure is in Science Mode (like during an observing run). In addition, the environmental controls have been ON since we swapped the aging NPRO at the beginning of the vent, so that could be contributing to the observed temperature swings.
In light of this, I have transitioned the PSL enclosure back to Science Mode (and turned the ACs off at the breaker box, which has been standard LHO procedure since the above linked March incident). I will let things stabilize over the weekend and re-evaluate the temperature on Monday.
I will also take a look at tweaking the beam alignment into the PMC on Monday, once temperatures have stabilized. This will require turning the picomotor driver in the HAM2 area ON; this driver was turned OFF for safety reasons while the corner station was being vented to atmosphere.
J. Kissel, T. Sadecki, B. Weaver Betsy and Travis have finished up and are happy with new ITMX after BRD / NMBD installation yesterday (see 39239), so I grabbed a full suite of transfer functions to make sure the suspension is as expected in detail. Attached are the results. The message: both chains of the suspension look virtually identical to the prior build; they look spectacular. If anything, I'm a little sad about the first Vertical mode (at 0.55 Hz) showing up in Transverse / Roll on the Reaction Chain (R0), where it has not before, but I'm confident this is simply exceptionally large vertical motion from the SUS being in air polluting the sensors' response. The coherence at those resonance points is minimal at best. There's otherwise no evidence of anything mechanically awry. We should definitely proceed with replacing the QUAD's stiffening sleeve and go forward with IFO alignment.
Today, Travis swapped out the problematic AOSEM (FRS Ticket 5058)
| OLD (S/N 232) WAS | NEW (S/N 594) IS | |
| OLV | 24,100 | 26,600 |
| OFFSET | 12,056 | 13,300 |
| GAIN | 1.244 | 1.128 |
A quick check of suspension freedom, we did a top stage V and L TF which showed reasonably placed peaks. A full suite is likely up next, as well as a check of actuation (maybe falls out with TFs).
WP7161: Dan, Dave:
Today we are upgrading the second frame writer system (h1fw1/h1ldasgw1) from SATABOY-RAID to E18-RAID.
Remember that we had upgraded the fw0 system back on 18th October, that system has been accumulating full and second trend data since that time. The default NDS is h1nds1, so this change was transparent to the control room.
Today's change will be more intrusive to the control room. In preparation for the upgrade, I have reconfigured h1nds1 (default NDS) to mount h1ldasgw0:/frames-0 file system. The nds was down for about 10 minutes while this was done.
We will now power down h1fw1 and h1ldasgw1, disconnect the two SATA-BOYS, connect the E-18. Build a file system on the E-18. Connect one of the SATA-BOYS and build a file system on it customized to its function as a raw-minute-trend archive server.
h1nds0 (guardian's NDS) is unaffected by today's work.
Attached are screenshot for BSC & HAM CPS spectra. Nothing notable for high frequencies.
Fairly quiet so far. (although the useism has taken a step up in last 18hrs & we continue to have sizable EQs over last few hours).
LVEA Zone Temperature StripTool looks fairly normal/flat around 20.1degC for last 43hrs.
Went through most of the Ops Checksheet with nothing to note.
On the CDS Overview, the edcu is red (this is due to BRS work).
DOE Ground Water Services was on site yesterday morning to perform annual testing of our well. I had to manually run the well for ~ an hour which is longer than I expected and as a result, I overfilled the well tank. There is a high level alarm sounding in the maintenance building but it is nothing to be concerned with, the annoying alarm will silence when the level drops.
IO alignment is complete, until final check, and until after a fix for IM2 and IM4:
Other IO changes to the HAM2 payload:
I've updated the BSC-ISI model in the repo and it is ready for installation. - HAM-ISI model is still pending (should be very soon).
Following requests from Jim, Sheila, et al, this change will update the BSC-ISI watchdog to make the ISI more robust during earthquakes. We have changed the model to increase the hold-the-damping-on-even-if-stuff-is-saturating time from 3 to 60 seconds.
The updated model is in the userapps repo at SVN revision 16398
Installation instructions and more technical details are in technical note T1700481.
The approved ECR is E1700367
and the FRS is 9309
I've not pulled work permits.
-Brian
[Spelling Ed from DAY Ops Shift duties so he can join IO Team for HAM2 activities.]
Day's Activities:
This afternoon, Travis and I finished moving the SR2 into it's new position 5mm closer to the BS (+Y). We had to jockey dog clamps and pushers to do this, attempting to hold the pointing of the suspension as close to it's previous condition as possible. Of course, we will realign this suspension ~next week when we run the PSL beam through the corner from PR to SR and everything inbetween. (We need to resuspend the SR2 and check for health via TFs first, as well as fix the SR2 UL M2 AOSEM, and finish HAM3 and elliptical baffle builds.)
While on HAM4, I reseated the 4" HWS mirror/mount that I moved last week, and we removed all tools and misc hardware lingering from the HAM4 work thus far.
Knock on wood that today was our final day of tedious alignment of the ITMX - we managed to get the suspension free of all mechanical interference points, while simultaneously having it point to the center of the OPLEV (with only ~30 and 120 urad of P and Y bias slider help), with all 20 AOSEMs centered in their range.
We need to rerun the full suite of TFs, but wish us luck!
Betsy, Travis
Re-terminating of the Y2-8 ion pump connector work will continue tomorrow. Had issues with connecting one of the safety interlock connections.
Hugh, Jim, Krishna
This is regarding the idea of placing a seismometer on the BRS-Y platform in order to improve coherence and hence tilt-subtraction. The brief summary is that we found excess low-frequency noise in the seismometer when it was placed on the table on BRS-Y. Hugh had attempted to reduce the noise by adding thermal insulation to the table and the instrument. The last alog on this is 35426.
In the recent data I looked at, this excess noise looks non stationary - it seems to get worse with elevated wind. This suggests it is likely not thermal. The seismometer data shows that the table has much higher motion in the 10-100 Hz as compared to the ground. Since the seismometer isn't held securely on the table, it is possible this excess high-frequency motion is causing it to move ever so slightly, which could look like excess low-frequency noise (step changes). We are attempting to mount the seismometer securely to the table using M10X1.0mm threaded rods and holes to be machined into the table. Results and plots will be posted in a few days.
How is the table secured to the ground?
The table on which the BRS sits, is sitting on three legs, not sure if these are hard point or rubber mount... Good question, Krishna?
J. Kissel
Taking the data from this morning's aLOG as my target frequencies, I've tuned BRD S/Ns 015 and 016 to match the highest vertical (a.k.a bounce) and roll mode frequencies of the newly suspended H1 SUS ITMX. Results are attached and tabulated below:
'Target [Hz]' 'BRD S/N' 'Mean Fit Freq. [Hz]' '% Diff [%]'
'9.806' '015' '9.853' '0.49'
'' '016' '9.812' '0.066'
'' '' '' ''
'13.927' '015' '14.033' '0.76'
'' '016' '13.926' '0.009'
Setup for measurement is as described in the HAM ISI TMDs (see 38741) using corroborating evidence from both the laser vibrometer and a primitive shadow sensor setup. To calculate the above "Mean Fit Frequency," I used a least square's minimization with a Lorentzian seed function,
fit(f) = (1/Q)^2 ./((f - f0).^2 + (1/Q)^2) + C
to fit both sensors' data to obtain the measured frequency with the noise, and then took the mean of the two sensors' results.
Betsy and Travis are installing these BRDs as I type.
It appears that some process variables are taking on values with characters that do not conform to JSON: Oct 18 11:10:12 conlog-master conlogd[7334]: terminate called after throwing an instance of 'sql::SQLException' Oct 18 11:10:12 conlog-master conlogd[7334]: what(): Invalid JSON text: "Invalid escape character in string." at position 44 in value for column 'events.data'. Oct 18 11:41:52 conlog-master conlogd: Server started. prefix: 'H1:CDS-CONLOG_' database: 'conlog' max inserts: 500 max time: 30 keep alive period: 30 time source: 0 create_messages: 1 Oct 18 11:59:32 conlog-master conlogd[8524]: terminate called after throwing an instance of 'sql::SQLException' Oct 18 11:59:32 conlog-master conlogd[8524]: what(): Invalid JSON text: "Invalid escape character in string." at position 44 in value for column 'events.data'. Oct 18 12:19:34 conlog-master conlogd: Server started. prefix: 'H1:CDS-CONLOG_' database: 'conlog' max inserts: 500 max time: 30 keep alive period: 30 time source: 0 create_messages: 1 Oct 18 12:34:12 conlog-master conlogd[9092]: terminate called after throwing an instance of 'sql::SQLException' Oct 18 12:34:12 conlog-master conlogd[9092]: what(): Invalid JSON text: "Invalid escape character in string." at position 44 in value for column 'events.data'. The same error repeats at each loading of the channel list.
Restarted the MySQL server with the general query log enabled to log the SQL query causing the crash. Restarted conlog. Crash did not occur on restart this time. Will leave log enabled for now.