Attached are the current EPICS alarm level settings for each FMCS channel. These are the settings used by the alarm handler at the operator's station and may differ from those used for phone text alerts.
WP7161: Dan, Dave:
Following Dan's suggestion, the SATABOY units have been split into two non-equal parts. The first is a small QFS file system (written by CDS, read by LDAS), which will hold the framed files' MD5 check sum files*. The second is a larger ZFS file system to hold the archived raw minute trend files (written and read by CDS).
The reason for the split is to perform firmware data compression, using the ZFS compression utility, for the archived raw minute trend files. Dan has found that GZIP-LEVEL5 compression gives us the 'best bang for our buck' in terms of compression ratio and cpu loading. We are expecting a compression ration of around 7.
Once the past 6 months of archived raw minute trend data have been copied, I'll reconfigure h1nds1 to serve these data.
In Detail: the SATABOY has 12 2TB HDD. They are allocated thusly:
| number of drives | use |
| 2 | [1.8TB] mirror raid, QFS file system, MD5 files |
| 8 | [10.6TB] RAID-6, ZFS file system, gzip5-compression, Archived raw minute trend files |
| 2 | hot swap spares for above raids |
* - writing the MD5 files to this location requires a daqd code change, I have submitted ECR-E1700382
J. Kissel, T. Sadecki FRS Ticket 5058 Travis replaced the in-vacuum, 4xDB9-to-DB25, "quadrapus" cable between the OSEMs and the "seismically-responsible-suspension (SRS)" in-vac cable for the H1SUSSR2 M2 stage (see LHO aLOG 39275) in order to further investigate the problems with UL's inability to actuate. Replacing this cable has fixed the issue. I attach corroborating evidence. (1) The range-of motion test results. Where we did not see any motion during driven offsets on the UL chain yesterday after replacing the OSEM itself (LHO aLOG 39263), we now see actuation response on all M2 OSEMs (2) The single-frequency sign wave test results. Where we saw no coherence or displacement in the UL OSEM ASD yesterday, we see plenty today and it's virtually identical to the known-good LL response. (3) The full suite of M2 to M2 transfer functions. We no longer see any unexpected cross coupling between P and Y, and the response to drive in all DOFs is larger, now that we're actuating with 4 OSEMs instead of 3. We may finally close this FRS ticket! Other Notes: - Given the new quadrapus cable affects the response of all OSEM sensors on the cable, we remeasured open light currents, and updated the OSEMINF calibration infrastructure. OSEM Open Light Current OSEMINF OFFSET OSEMINF GAIN (OLC) (-1 * OLC / 2) (30000 ./ OLC) [ADC Counts] [ADC Counts] [um / um] UL 24546 -12273 1.2222 LL 19482 -9740.8 1.5399 UR 17731 -8865.4 1.692 LR 19314 -9657.2 1.5532 - The (modified) triple-acquisition driver for this stage was set to its highest actuation strength for these measurements, state 2. - Now that SR2's M2 stage is fully operational and may potentially be a globally control, we will need to balance the actuation strength by applying non-unity COILOUTF gains calculated via methods described in LHO aLOG 13203 - If we're interested in any frequency-dependent drive DOF decoupling (a. la. LHO aLOG 32503), I've now tuned this set of templates to get much better coherence than what had previously been in this SUS's SAGM2 folder (and they now store the M3 sensors such that we can export the M2-to-M3 transfer function). The data can be found here: /ligo/svncommon/SusSVN/sus/trunk/HSTS/H1/SR2/SAGM2/Data/ 2017-11-03_1816_H1SUSSR2_M2_WhiteNoise_L_0p01to50Hz.xml 2017-11-03_1816_H1SUSSR2_M2_WhiteNoise_P_0p01to50Hz.xml 2017-11-03_1816_H1SUSSR2_M2_WhiteNoise_Y_0p01to50Hz.xml - All data and updates to "plotall" scripts have been commited to the SusSVN repo in the appropriate places.
Note: I did NOT replace the SRS cable as this was not necessary. Sorry, misread Kissel's log.
After swapping the AOSEM for SR2 M2 UL earlier this week, and learning that it was not the culprit (alog 39263), I replaced the M2 stage Quadrapus cable. JeffK checked it on the fly while I was in the chamber and verified that it seems to have fixed the issue. Cable that was removed was D1000234-v4-00-903. New cable is D1000234-v4-00-S1106125.
After remounting the T240 on the BRSY table with through bolts, rather than just sitting on the table with pointed feet, we 'centered' the masses--this was Wednesday afternoon. This morning I checked again and the mass centering positions were all about 1 volt. Not terrible but above action level had these been on an ISI mounted T240. So I centered it again this morning. A couple minutes after expressing the 5v required to initiate centering, the readings were at 1 to 7 percent of 1 volt.
(Mark, Tyler, Peter, Gerardo)
The old OFI was extracted out of HAM5 using the HAM installation arm. Once out of the HAM a lift was used to lower it onto a table for temporary storage.
The new OFI was installed using the lift to position it on the HAM installation arm, then set into the HAM on top of the height adaptor. The height adaptor was not removed to maintain the aligned position. The OFI was fasten to the height adaptor and all fixing bolts were torqued, also 2 vibration absorbers were moved from the old OFI to the new one. The OFI is "locked" in place using the transport shims, and tomorrow with the new earthquake stops it will be "released" giving us an opportunity to visit its suspended alignment.
Attached is a photo of the new OFI as it was being installed, yup! There is not much room, the arm was 1/2 inch away from black glass baffles on one end, and the other end very close to the ceiling of the chamber, to move the arm out we resorted to the removal of a yoke arm and it worked like a charm!
Rakesh and I cleaned the ~ 30-50 contamination spots on XBM interior wall, a few feet away from cryo baffle, ranging in size from 1 mm diam. to 1" diam. We scraped the surface of these spots with small flat head screw drivers and a tool with a pointed edge, and collected the brown/black flakes, to be analyzed via FTIR. We wiped with IPA wipes and also tried acetone and methanol (wiped away same as IPA). The spots leave a stain on the SS wall. We are not able to remove 100% of this material with our cleaning technique. The beam tube wall is rough, so wiping is limited without creating other issues with wipe shedding. The location of these spots is two tube welds in from cryo baffle.
JPL results here: https://dcc.ligo.org/E1700405
TITLE: 11/02 Day Shift: 15:00-23:00 UTC (08:00-16:00 PST), all times posted in UTC STATE of H1: Planned Engineering LOG: Richard reports Cheryl is in LVEA 15:39 UTC Gerardo, Apollo to HAM5 to remove old OFI, install new OFI 15:56 UTC Krishna to end X, BRS upgrade 15:59 UTC Peter to HAM5 to see if Gerardo needs help, if he doesn't then to optics lab 16:59 UTC Jim and TJ to HAM2, install baffles, then TJ to HAM3 and Jim to balance ISI 17:15 UTC Ed to end X to swap out coil drivers 17:20 UTC Hugh taking equipment to Jim in LVEA 17:29 UTC Hugh back Travis to HAM4 17:50 UTC Betsy to HAM4 18:17 UTC Ed to CER to take picture of labels, then back to end X 18:21 UTC Ed back from CER 19:11 UTC Travis back from HAM4 19:19 UTC Ed back 21:02 UTC Travis, Chandra, Rakesh: x-arm BM, cleaning vacuum tube walls 21:50 UTC Gerardo to HAM5, Peter to optics lab, then HAM5 22:06 UTC Jim and TJ out of HAM2 for remainder of day 22:25 UTC Terry M. to squeezer bay to take inventory of equipment 22:38 UTC Travis, Chandra and Rakesh done
Apollo and a Mitsubishi factory rep were out yesterday to look at the H-2 HVAC system. After many hours of head scratching by both, the Mitsubishi rep THINKS the system possibly has a small leak. We will evacuate the entire system, one bank at a time, pressure test and reinstall the proper amount of refrigerant.
While Chandra and Rakesh were cleaning the X beamtube, I snuck away to HAM4 to install the SR2 AR HWSY Hartmann baffle. The new black glass version of the baffle (D1600009-v3) is now installed, dogged, and torqued.
J. Kissel FRS Ticket 5058 After Betsy and Travis replaced the physical OSEM itself yesterday, I tried using the OSEM to drive the suspension. Still no dice. See attachments for proof. (1) An actuation range test (similar to that from LHO aLOG 13256), where the COILOUTF bank OFFSETs are used to drive the complete DAC range (~100k cts) and the response is monitored in the corresponding OSEMs. While LL, UR, and LR show plenty of signs of life -- still nothing from UL. (2) An awggui, 1.45 Hz, sine-wave excitation into the UL and LL COILOUTF banks, where again, the response is monitored by the corresponding OSEM. While UL excitation shows nothing, an LL excitation shows up in both the UL and LL sensors. (3) "Traditional" health check of an M2 to M2 suite of transfer functions (hoping for similar confirmation of weird stuff in LHO aLOG 13262). Not nearly as obvious that things are weird from the individual OSEM traces, but one can clearly see L and P resonances coupling in the Y transfer function, when one definitely should not -- especially since the SUS has been confirmed to be free via M1-to-M1 transfer functions (see LHO aLOG 39265). Notes: - I restored the EUL2OSEM matrix to it's nominal, fully, functional HSTS values (the L2UL and L2LR elements had been zeroed, and the L2LL and L2UR elements had been doubled, so as to avoid using UL in a longitudinal excitation, but to still get an excitation.) - For these measurements, I changed the coil driver configuration from its lowest noise configuration (state 3) to its highest range configuration (state 2).
J. Kissel After Betsy and Travis "restored" (+5 mm) the position of SR2 (LHO aLOG 39240), and they've unlocked the suspension, I've done cursory M1 to M1 transfer function to check that the suspension is free of rubbing. SR2 is clear of rubbing. Good jorb!
SR2 M2 UL OSEM actuator is still unresponsive after OSEM swap HAM5 OFI has been swapped Koji here next Tuesday Y28 IP: waiting for parts Work in SQZ bay next week. Laser hazard at height. HAM2 ISI is balanced Sheila reports LLO also has damage to black glass in HAM6
The ETMX ISI Coil Drivers were replaced with the newly modified versions (E1100821v-1/E1300535v-1/temp rst switch). Also, the HWWD cables were terminated and connected.
I've updated the medm screen accordingly
The h1asc, h1ascimc and h1sqzwfs models were updated to the most recent DAQ channel assignment. Some non-functional extra stuff has been removed from h1ascimc. Where necessary cables were moved on the ADC chassis.
WP7161: Dan, Dave:
h1fw1 is running again, writing frame files to its new E18. First file was written at 16:18 PDT this afternoon.
The two SATABOYS (originally used as a pair by h1ldasgw1) have been split, one per ldas-gateway machine.
Because both NDS servers are serving h1ldasgw0's framed data (data acquired since 10/18), Dan is building h1ldasgw0's SATABOY first and will populate its raw minute trend area with the latest backup (May-Oct 2017) first. He estimates this file copy will take about 8 hours, so will be available to nds in the morning.
The SATABOYs store two types of files: archived raw minute trend files and MD5 check sum files for GWF framed files (both full and trend) written by the frame writer.
The sataboy will be exported by the ldasgw as /sataboy-0 and /sataboy-1 for the two systems. The directory structure under this mount point is:
/sataboy-n/fchksums/full* (contains directories with 5digit-GPS name, same as /frames/full)
/sataboy-n/fchksums/trend/second (contains directories with 5digit-GPS name, same as /frames/trend/second)
/sataboy-n/fchksums/trend/minute (contains directories with 5digit-GPS name, same as /frames/trend/minute)
/sataboy-n/minute_raw (contains one directory per archived data block, with names minute_raw_10-digit-GPS)
Note: for now we are not creating the /frames/science directory, this was removed when the commissioning/science frame distinction was abandoned.
correction, the path the the archived raw minute trend data is:
/sataboy-0/frames/trend/minute_raw/minute_raw_1192382538
Dan has recovered all the files in this area, I'll add this to h1nds1's configuration.
But first....
we noticed that the archived minute trends were actually too big to fit on the SATABOY uncompressed. We have two options:
1. Keep the SATABOY all QFS and i) manually compress the trends, meaning ii) changing the DAQ code to uncompress files when needed.
2. Dan suggests splitting the SATABOY into two partitions, one small QFS for MD5 files, the second a large ZFS file system with firmware compression built-in.
We mulled this around and decided on Dan's suggestion. He has done some further investigation to determine the best compression algorithm for our application. He also found that only 2TB is needed to store all the archived min trend data taken so far in compressed files, leaving plenty of room left in the 11TB file system for future data.
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.
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?
