[Betsy, Koji]

We brought the OMC to the bonding lab for inspection. We found some of the EP30-2 joints between the main glass breadboard and the invar mounting brackets showed sign of delamination. Dennis, Calum, and Garilyn have been notified and are woking on the counteraction.

Attachment 1: 40% delamination. This piece is holding one side of a balance mass holding bracket.

Attachment 2: 80% delamination. This piece is holding one side of a balance mass holding bracket.

Attachment 3: 40% delamination. This piece is holding one side of a balance mass holding bracket.

Attachment 4: 80% delamination and this piece is supporting one of the DCPD housing at the bottom side.

Attachment 5: 30% delamination and this piece is supporting the other DCPD housing at the bottom side.

Kyle, Gerardo

Upon being notified of the upcoming (unscheduled) vent of HAM6 on Monday, we thought that it would be prudent to run the Corner Station purge air supply sooner rather than later do demonstrate its readiness.  Though this unit is well maintained and hasn't had functional issues of late, it is 20 years old now and we no longer assume that it won't develop issues while sitting idle.  As such, we found that it tripped off a few minutes after startup with the alarm "2nd STAGE SUCTION OVER TEMPERATURE".  Restarted and same problem etc ->  The water lines supplying the intercooler were colder than ambient suggesting chilled water flow to the components of interest (Yes John the booster pump is on!) -> The displayed temperature of interest was intermittently alternating between an expected value and a bogus high value which resulted in the shut down response -> We switched the terminations between the 2nd stage suction RTD and discharge RTD and noted that the problem did not follow the temperature sensing device but rather remained "2nd STAGE SUCTION OVER TEMPERATURE" -> Gerardo noticed that when the bogus 2nd stage suction temperature value was occurring, that all of the other displayed temperatures also changed to the same value suggesting a logic and/or common connection issue.  Correspondence with Roger's Machinery (original equipment provider) revealed that the Siemens PLC unit used in our Kobelco had known issues that could sometimes be resolved by lifting then re-landing the wires (of which there were many!) on its terminal strips -> We did this and the unit seems to be happy now -> We are leaving it run over night but isolated from the LVEA so as to reduce air demand and minimize loading cycles. 

All of the Roger's Machinery field service technicians are booked solid through this weekend but I will be updating them at 0800 tomorrow morning as an emergency service call isn't out of the question should we need it.  

Jenne, David M, Jim, Nutsinee, David B:

As part of the NGN signal problem investigation, at 13:46 PDT this afternoon we power cycled the IO Chassis for h1oaf0 (which runs the h1ngn model). Sequence was: stop models, power down h1oaf0, power cycle IO Chassis (powered down for at least 30 secs), powered up h1oaf0.

The TCS chillers did trip out soon after the power down, Nutsinee recovered them.

 Attached are trends for 45 days of HEPI pressure signals. All corner station signals look pretty similar. To my the EX signals look somewhat noisier than EY, but I think this is a know issue. This closes FAMIS task 4522.

14:42 UTC Jeff B. to LVEA to check clean rooms near HAM6
14:50 UTC Jeff B. back
15:04 UTC Jeff B. to OSB optics lab
15:09 UTC Jeff B. back
15:16 UTC David M. to LVEA to tape down cables
15:21 UTC PRMI locked, aligned BS in YAW. PRMI to DRMI transition failed.
15:26 UTC DRMI locked
15:27 UTC lock loss in DRMI locked
15:41 UTC Stopped at ENGAGE_SOFT_LOOPS
16:35 UTC Rich A. to HAM6
16:52 UTC Rich A. back
17:10 UTC David M. back
17:13 UTC Filiberto and Dave M. to LVEA to check NN array
17:32 UTC Filiberto and Dave M. back
17:38 UTC Bubba to mechanical rooms in mid stations to work on fans (WP 6011)
18:20 UTC Kyle and Gerardo to LVEA to start purge air compressor (WP 6027)
18:53 UTC Filiberto to LVEA to untrip ITM ESD HV power supply
19:05 UTC Jim W. adding state to SEI guardian
19:09 UTC Rich A. walking around LVEA
19:51 UTC Rich A. back
19:55 UTC Filiberto to LVEA to start pulling cable (WP 6028)
20:04 UTC Rich A. to observation deck and driving down arm
20:41 UTC Corey to optics lab
20:45 UTC Jenne and Jeff B. to look at seismometers in LVEA
20:46 UTC Kiwamu to ISCT6 to realign OMC REF camera
20:47 UTC Gerardo to LVEA to look for viewport protector
20:48 UTC Dave B. powercycling h1oaf
21:03 UTC Dave B. done
21:11 UTC Gerardo back
21:13 UTC Nutsinee to LVEA to turn TCS lasers back on
21:22 UTC Nutsinne back
21:37 UTC Kiwamu back
21:49 UTC Kiwamu back to table
22:26 UTC Filiberto done

WP 6026

I powered h1conlog1-master and h1conlog1-replica off.

The disks were almost at capacity. I will remove and give them to LDAS to archive.

Unfortunately this means that there is no Conlog until the next version is installed.

Attached are screenshots for the past 7 days optical ever trends for PIT, YAW, and SUM.

This completes FAMIS 4686

The positive HV power supply for the ITM ESD was found in the off position. Unit most likely tripped, this is something we have seen at the end stations. Unit was powered on and the output settings were set to V = 430V, I = 80mA. Time unit was power back on ~12:00PM.

Jim and I tested for the minimal data which can be sent from a 64kHz model to the DAQ. We used x1ioppsl0 as the test model.

Background: When we installed the first SUS PI model on H1 last year the users wished to write two of the channels to the DAQ at 2kHz, this  caused runtime errors. I fixed the errors by adding two other channels at the full 64kHz rate, similar to what RCG does if there are no DAQ channels selected. Since it is not possible to set acquire=0, I set the data to zero to maximize compression.

Rolf mentioned that the rule of two channels at full rate has been removed. To see what the minimum rate is, I created a DAQ block on x1ioppsl0 and tried various combinations of one and two channels at various rates.

The mimimum DAQ configuration is one channel at 8192Hz. If the data content on MX is 4096 or less, the model will not run and the dmesg error "DAQ size too small" is shown. This is also true if two 2048Hz channels are selected, as was the case with the PI model. We suspect adding a third 2kHz channel would have avoided the problem.

Because acquire=1 will be selected for the 8kHz channel, the trick of ensuring the data is zero should be used to minimize impact on the frame size.

The BRS-Y has been continuing it's (already known) drift toward the end of its light sensor. So, some time we should probably turn the sensor correction off on Friday. I have added a state to do this in the SEI_CONF guardian, called WINDY_NO_BRSY. Krishna and Michael are already planning on coming over to address this on Tuesday.

There is a test for both BRSes in the Diag guardian node, so we should either wait for the notification for BRSY to come up or make the change last thing Friday night. If commissioners or operators don't want to risk an ISI trip, there is no problem with making the switch right now.

It should be noted that since both BRSes have been installed, this drift has been the only issue effecting the robustness of the BRS. Otherwise, we have been runing them as part of our nominal configuration for a couple months now.

Hugh, Evan

Over the course of several locks, we moved the HAM4 HEPI in the y direction by several hundred microns in order to see the interferometer behavior at 2 W with the SRC locked on different fringes.

For a 1.1 mm shift in the HEPI position (i.e., a 2.2 mm shift in the one-way SRC length), there is no discernible trend in the rf sideband buildups or in the DARM pole frequency.

We would like to repeat this test with SR2 offsets as well.

So the user might be more quickly alerted to an issue with the Fluid system making problems for platform isolating.  This is also alarmed in the alarm handler system.

Attached is a snap of the HEPI and BSC & HAM ISI overviews with the OK/NOT OK widget circled.  If these lights are not green, HEPI Isolation may not happen likely with Actuator Watchdog trips.

Edited files have been commited to the svn.

David.M, Filiberto.C

Yesterday I was looking at the NN array output channels to check everything was working and noticed that the 7th NN channel (H1:NGN-CS_L4C_Z_7_OUT) was producing a noisy output about 3 orders of magnitude higher than expected. I thought potentially the L4C might be busted, so I went into the LVEA this morning and swapped it out for another one that we tested earlier (L41429). The problem remained even with the new sensor and also even when the sensor was unplugged. We went into the CER to diagnose where the problem was. Turning off the L4C interface chassis and the AA chassis both didn't fix the problem, which seems to indicate that the large noise level in this channel is caused by a problem in the I/O Chassis.

We have a serious issue with the OMC. Even after a day of trying, we are unable to resonate a 00 mode.

David McManus, Jenne Driggers

IMPORTANT: The channel numbers which correspond to locations of the L4Cs have been changed since previous posts, see the updated table and map below and ignore information in previous posts.

When i reference channel numbers in this post I mean the channels H1:NGN-CS_L4C_Z_#_OUT where # is the channel number

After today 29 of the 30 L4Cs have been fixed to the floor and connected to cds. Each sensor on the floor is positioned inside the foam coolers as in previous posts, the boxes are now clearly labelled with the channel number of the L4C as shown in the first picture (with sensor 25). There are now proper threaded connections between each sensor and cable which prevent the cables from being pulled out.

The map attached to this post shows the locations of all sensors in the array, and their channel numbers in cds. L4C number 1 is the only one which is not currently placed because it is right in the middle of a busy and narrow walkway. 

The attached table shows which L4C serial numbers correspond to which channels and also which channel this serial number used during the calibration huddle. Note that because all 30 sensors could not be plugged in during the huddle certain channels were used for different sensors at different times. For this reason this table includes the start date and end date for when this L4C was attached to the channel listed during the huddle.

The other pictures attached show areas where cable protectors are now layed out in the LVEA to stop people tripping on cables.

David.M, Jenne.D

Yesterday I set up the sensors for the Newtonian noise L4C array in the beer garden. There are 31 sensors there in total (30 for the array and 1 spare), I arranged them in a huddle beneath the stairs near the STS-2. 20 of them are plugged into the two chassis located in the beer garden which correspond to the first 20 L4C channels. The other chassis is located external to the beer garden next to HAM2, I only connected two sensors to this rack because of a lack of long cables. The channels with these two sensors are L4C channels 26 and 30. I've attached a table which states which serial number L4C is connected to which channel for reference. Also attached are a photo of the current sensor huddle as well as an initial plot of the sensor spectrums calibrated to the STS-2 (thick black line).

The sensors themselves are each only touching the floor (despite what it looks like in the photo), although each wire touches many other wires and don't have any proper strain relief yet. The sensors currently being recorded are the ones more closely huddled together in the photo. The ones which are seperated slightly off to the left are the currently unrecorded L4Cs.

I had a look at lock loss times and their durations during O1 (only lock losses from nominal low noise). I've had a brief look at a couple of the physical environment channels (H1:PEM-EY_WIND_ROOF_WEATHER_MPH for wind and H1:ISI-GND_STS_ITMY_Z_BLRMS_100M_300M for seismic) to see how they are correlated to these lock losses. There are a few plots I've attached here below. All of the data for these plots are mean minute trends

Plots:

Duty_cycle_noncumulative.pdf  - This is a 3D plot showing the duty cycle for different wind and seismic bins (percentiles)
Duty_cycle_cumulative.pdf   - This is a 3D plot showing the duty cycle when the wind or seismic behaviour is greater than or equal to the given percentiles 
Downtime_wind_seis.pdf  - This is a 3D column plot showing the integrated 'downtime' that results from a lock loss in the given wind and seismic bins (percentiles)
lock_losses.pdf  - This plot shows the number of lock losses per percentile bins, surf (matlab) makes it look a bit weird. 

I've also attached lock_losses.txt which is a list of the times in GPS when the lock losses occur (first column) and their duration in seconds (second column). The durations and loss times are only to the nearest minute unfortunately since I used minute trend data.

Percentiles.txt contains the wind (first row) and seismic (second row) channel values that correspond to 5% intervals starting from the 0th percentile (0,5,10...). These are for the mean minute trends though which are much lower than the maximum minute trends.