David.M, Jenne.D

Today I set up a further 13 L4Cs in the LVEA, this time they are much more spread out than last week so watch out for them around the LVEA. This means that now all of the sensors in the array except for one have been fixed on the floor. (This last L4C is right in the middle of the path on the first corner near the beam splitter chamber). All of the L4Cs have the foam box coolers taped down on top of them which should make it obvious that they are there. I'm going to finish the cables and neaten everything up one morning this week so hopefully there wont be any problematic tripping hazards. The numbering scheme has been updated so now the previous scheme is invalid. Once I finish connecting all of the sensors I will make a new post with the updated scheme and an updated map.

SUS PI code change WP6018

Carl, Terra, Jim, Dave:

New code was installed for h1susitmpi, h1omc, h1susprocpi, h1susetmxpi, h1susetmypi. The model changes went in normally, but the DAQ restart was problematic. The data concentrator error'ed on duplicate channels for H1:SUS-PI_PROC_COMPUTE_MODE9_PLL_SIG_OUT. This was surprising as I had ran my script to check for duplicates prior to the DAQ restart. We reconfigured the DAQ sans h1susprocpi to get the DAQ running again while we investigated the problem. Jim found the problem, in the sys/common/models/PLL_MASTER.mdl file, a testpoint part was named SIG_OUT in addition to a filter module at that level which was named SIG, and the filtermodule has a testpoint also called SIG_OUT. This common part had 32 such duplicates, MODE9 was just the first to be reported.

Terra fixed the models, we restarted h1susprocpi, reintroduced it to the DAQ and restarted the DAQ.

I extended the script check_daq_channel_list_for_duplications.bsh to check both INI files and PAR files.

DAQ Restarts

Jim, Dave:

h1tw0 has become fragile lately (not so h1tw1). We discovered that if we restart the DAQ while h1tw0 is in the midst of writing the raw minute files, this can corrupt the file system requiring an fsck to fix. Today we were careful to only restart the DAQ while h1tw1 was inbetween file writes. This has worked and h1tw0 has not crashed.

In two of today's DAQ restarts we needed to restart the mx-stream on a handfull of frontends.

GDS code upgrade WP6012

Jim:

New GDS code was installed, details in Jim's alog.

New LSC code

Jenne, Dave:

Jenne's new h1lsc code was installed. This added some channels to the commissioning frame (eight channels at 2048Hz).

Radio receiver spectrum analyser work

Carlos, Jordan:

The RF analyser was attached to the FLIR camera windows server, code was installed and tested.

New DAQ frame writer WP6016

Carlos, Dave, Jonathan, Jim:

we installed a new frame writer called h1fw2. It is a standard front end computer using a spare Myricom 10GE card. New SFP and RAM (48GB) were purchased for the unit. This is a dual boot machine (Ubuntu 12 and Debian 8). It has a 1TB internal HDD which we are using for testing. Jim and Jonathan did some Deb8 work on it. We determined 48GB is not sufficient for it to write all the frame types.

As the system is currently configured:

h1fw0 is writing commissioning and science frames (no trends). It is now 100% stable, has been running for 6 days.

h1fw1 is writing all frames. It is unstable, restarting on average every 2 hours.

h1fw2 is writing commissioning and science frames (no trends) to its local disk.

All three have been running for about two hours now. I've extended the DAQ overview MEDM to show all three and check their frames are identical. It would be good to run three writers for O2, if the frames were not identical a trio of writers could indicate which is the incorrect frame.

Installed new version of GDS tools, gds-2.17.1.3-2 for Ubuntu 12, Ubuntu 14, and SL6 which provides some minor changes to the control room tools as follows:

Bugzilla 1027 - Remove the ability of 'diag' to clear all test points on all models. This would clear CW injections if used.

Bugzilla 1017 - foton removes extra spaces and newlines from design strings when writing files.

Bugzilla 961 - For diaggui swept sine analysis, if the user uses the sweep point editor to manually enter sweep points, diaggui will now work if the number of points in the analysis is less than the number of points specified in the editor.

Bugzilla 628 - For awggui, implemented saving and restoring of configurations, and implemented statistics and configuration menu items.

    Swapped out the PSL in-line filters in the chiller room. The new filters are 1.0um pleated; replacing 0.5um blown-matt surface filters. The new filters are higher flow with less back pressure. 

   The original filters were causing the operational pressure to rise and were lowering the coolant flow through the system. The posted plots show after the filter change the PSL cooling pressures did drop and the various flows increased. After replacing the manifold (see aLOG #28652) we were able to adjust the pressure regulators in the PSL to bring the line pressure below 4.5 bar. 

   Will continue to monitor flows and pressures until satisfied all is well.       

Since replacing the crystal chiller flow sensor did not fix the problem with the laser tripping out,
we replaced the water manifold located under the PSL table.  Attached are two traces from when the
chiller tripped out.  Since the power meter circuit tripped before the front end circuit, this suggested
that the problem really was with the power meter flow sensor rather than the chiller (see attached
plots).

    The pressure regulators on the manifold were adjusted to give a front end flow rate of 1.7 lpm,
the power meter circuit 1.5 lpm and the laser heads 0.6 lpm as indicated by the Beckhoff PC.  Note
that the flow for head 4 is different at 0.5 lpm, although head 4 has always been a bit odd of late.
 - 4 bar for the MOPA circuit
 - 4.46 bar for the power meter circuit
 - 4.35 bar foe the laser heads circuit

    It is possible that there is a slow leak at the bottom of the power meter flow sensor.  We will be
monitoring the crystal chiller water level over the next few days to see if indeed there is a leak.

    Laser restarted.  Things seem to be okay for now, at least.


JeffB/Jason/Peter

   Checked the HEPI L4C WD saturations per FAMIS task #7046. All green, all counts were zero.  

Ran power and network cabling for the new ITM cameras that are to be installed. Cables were pulled from the X and Y manifold spool into the beer garden. This required dressing cables around BSC1, BSC2, and BSC3.

JimW, JeffK, HughR

Around 1900 utc, the pressure dropped and the servo drive went to max; from afar, this looks like a fluid level trip.  Jeff went to the end station and found that the front panel red light was still on indicating it was not a fluid level trip.  Opening the controller panel to access the VFD revealed the OU3 error indicator.  Last aLog with this problem found with quick search was at EndY July 2015.  Maybe it is a warmer weather problem.  Brought control servo output to 0, reset VFD to clear the error and then brought things back under servo control, around 2200utc.  Jeff noted the fluid levels were same as before--no fluid problems.

TITLE: 07/26 Day Shift: 15:00-23:00 UTC (08:00-16:00 PST), all times posted in UTC
STATE of H1: Commissioning
INCOMING OPERATOR: Travis
SHIFT SUMMARY:  Down most of the shift for maintenance
LOG:

MarcP/HughR

DeIsolated the platform to investigate the concerns on the Coil Driver.  Running an sine excitation into the H2 OUTF, things looked fine until the I_INMON reached about 50-60 counts; this occurred with an excitation of 2500 counts.  At that point, the I_INMON reversed direction and went very large (340cts.)  Looking at the actual platform motion though, this was not happening to the Actuator.  This is similar to what we observed in the second attachment of 28621. It never was observed to do anything crazier than that though such as suddenly driving the platform off to tripping.

Next step was to disconnect the output from the coil driver and confirming that what we saw on the monitors was what was going out, even though looking at the response of the platform, it was moving in a nice sinusoidal pattern and not abruptly reversing when the current hit 60 counts.  About that time is when Marc noticed that the -15V led was not illuminated on the coil driver chassis.  He pulled the coil driver and found the SG7915 Voltage regulator was producing -2V rather than -15V.

Pulled coil driver S1103341 and replaced with S1600116.  This unit had the hardware watchdog power supply enable circuitry so that enabling voltage was patched over from ITMY.

The ISI reisolated first attempt.  Took the platform back to Isolated Damped and again ran the sine (0.05Hz) until the I_INMON was surpassing ~75cts.  No clipping/flipping/scaling seen on the I_INMON signal.  Attached is this after picture, sadly the ugly before picture may be lost as we had frame writer issues during the morning and afternoon.

Jenne, Chris Whittle

I verified that the ITM oplevs will most likely be insufficient for taking charge measurements; we will need to rely on DARM. See the attached spectra, made with an excitation at various frequencies and amplitude 130k cts. Dotted reference lines were set with no excitations, solid lines show the response to the excitation in the bottom axes.

I also noticed that some of the MEDM outputs for L3 of the ITMs are incorrect. Two of the USER MODEL DAC OUTPUT (H1:FEC-30_DAC_OUTPUT_3_6, H1:FEC-30_DAC_OUTPUT_3_7) read 0 when a voltage should be present. The ANALOG SWITCH lights and quadrant VMON channels are left-right flipped relative to the control switches (i.e. flipping UL shows a reading in UR). I also had to remind myself that I should always use the longitudinal channel (rather than pitch or yaw, which will attempt a differential excitation and give zero output) when exciting ITMs.

(Chandra, Gerardo)

Removed and replaced the AIP for BSC8, no issues encountered.

An aux cart was used to pump down the system from 17:10 to 21:50 utc.

AIP system is running on its own, and maintaining pressure (system back to nominal).

Lowered LLCV from 21% to 20% after CP3 Dewar fill. Exhaust pressure was spotted at 1.4 psi.

In response to Keita's alog (here) I changed the whitening gain and number of active filters on the ITMx, ITMy, and ETMx optical levers.  They are now set as outlined in the 2nd table in Keita's alog.  I also enabled the corresponding de-whitening filters in the oplev filter medm screens (ITMy and ETMx only, as these were the only ones that had additional whitening filters enabled) and accepted the changes in SDF.

I took spectra of each segement of the QPD for each TM oplev, both before and after the de-whitening filters (channels labeled IN1 are before de-whitening, channels labeled OUT are after de-whitening) as well as spectra of the pitch and yaw signals of each oplev..  To my knowledge, ETMx and ETMy look as they are supposed to.  On the other had, the ITMx and ITMy QPD spectra do not look right to me.  When I took the spectra there were ongoing investigations into ITMx ISI coil driver issues and ITM charge measurements (ie, the optics were moving); also, the oplev lasers for both ITMx and ITMy oplevs are unstabilized lasers, sitting on the LVEA floor.  All of these could be causing issues with the measurements; they should be re-taken once things have quieted down and see if there are differences.  If there are no differences, I fear we may have made things worse for the ITMs.  There also appears to be a comb in all of the ITMy spectra.  I think this is caused by the laser glitching; as soon as I have a stabilized laser ready for install this laser is getting replaced.

This completes WP #6020.

Had bagged entire RGA assembly previously -> Removed 1.5" O-ring valve (redundant valve in series with 1.5" UHV valve) and installed turbo in its place.  Backed turbo with leak detector.  Opened 1.5" UHV valve to combine detector with RGA volume.  Helium line penetrated bag at top while O2 sensor (with internal pump) penetrated bag at bottom.  No flow meter on helium but set to "significant" flow rate.  O2% fell from 20% to 1.6% over 10 minutes.  No leaks detected with helium baseline holding @ 1.2 x 10-9 torr*l/sec or so throughout the helium application -> Once convinced that no leaks were present, I closed the 1.5" UHV valve and "cracked" the isolation valve of the external calibrated helium leak and observed the expected response; thus demonstrating that the mass spec. was sampling the test port during testing.  

Installed 5 of 6 heat tapes on RGA assembly in preparation of baking it out at the next available opportunity.

Note to self: The isolation valves for the Nitrogen and Krypton calibration gases were closed during this testing so the two "factory" double-sided mini-conflat joints did not get tested.  Also, I noticed after shutting down and decoupling the leak detector etc. that the factory 2.75" CFF joint between the RGA analyzer and its protective nipple showed a crescent shaped gap.  All of the joints tested in this excercise (12 or 13?) where ones that I bolted and are "metal-to-metal" and won't change with with baking.  This sole gappy joint could leak following a thermo cycle so I will "cinch" it up and leak check it along with the two double sided joints that I missed before baking.

J. Kissel

We're still struggling to get past the Parametric Instability Phoenix (e.g. LHO aLOG 28600), so we haven't had much IFO time / patience to debug ESD bias sign flipping. As such, the charge, effective bias voltage, and actuation strength continue to change slowly. Again (see last week's report in LHO aLOG 28523), ETMX is charging about twice as fast as it has between the prior two flips, so its accumulated charge will begin to get excessive sooner than ETMY.

I'll keep pushing for a debug of the bias flipping, but we've got higher priorities with the IFO stability at the moment, and the change from charge is not out of control or ridiculous. Yet. 

I swapped the oplev laser for the ETMy optical lever in order to address the problem noted by Sheila here.  The laser will need 4-6 hours to come to thermal equillibrium.

The SN of the new laser is 130-1.  This completes WP #6013.

Executive summary: 

* Good news - as expected, the 16-Hz comb due to the OMC length dither is gone (at least at this sensitivity level)
* Bad news - low-frequency 1-Hz combs remain, and some new low-frequency combs & lines have appeared 

Some details:

 I initially looked at 15 hours of 30-minute FScan DELTAL_EXTERNAL SFTs (30 SFTs) generated during ER9 and was aghast at how bad the low-frequency spectrum looked, with a pervasive 0.485308-Hz comb ranging up to its 446th harmonic at 216.4 Hz, but when I exclude the three hours of SFTs when the 2-second ALS- glitches were present, things don't look quite so bad (see figure 1 for a sample without removal and figure 4 with removal). I dewhiten according to the new 6-pole / 6-zero, 0.3 / 30 Hz algorithm.
 The infamous 16-Hz comb due to the OMC length dither tracked down and killed here is gone (at least at this sensitivity level and these SFT statistics). As a result the high-frequency band (up to 2 kHz) is remarkably smooth with only violin modes and sporadic isolated artifacts.
 The 1-Hz comb with 0.5-Hz offset remains pervasive, but other prior 1-Hz or near-1-Hz combs with different offsets (e.g., 0.25 Hz) are not strong.
 On the other hand, there is a new near-1-Hz comb (0.996798-Hz spacing) visible to its 204th harmonic at ~203.3 Hz.
 There is also a new near-2-Hz comb (1.999951-Hz spacing) visible on approximate odd-integer-Hz frequencies, starting from ~9 Hz and visible up to ~175 Hz. This is likely the same 2-Hz comb reported in May by Bryn Pearlstone (which Ansel Neunzert kindly reminded me about today). 
 There is a "new" 56.8406-Hz comb visible to its 11th harmonic at ~625.25 Hz, which in hindsight I can see was buried in the O1 spectrum (I overlooked the pattern and indicated the teeth as isolated lines). This time the pattern was strong enough to jump out at me and to jog my memory that this comb was seen in  H2 1-arm data in 2012 in both the arm feedback channel and a quiet sensor-noise-dominated OSEM channel. This seemed to indicate a DAQ system problem at the time. I can see from O1 NoEMi line lists that this comb is pervasive in ISI, SUS and PEM channels at the corner station and both end stations.
 The old "K" comb-on-comb (0.088425-Hz fine comb attached to teeth of a coarse 76.3235-Hz comb) has more 11 more fine teeth visible on the lowest-frequency coarse-tooth comb.
 The old calibration line at 35.9 Hz has been moved to 35.3 Hz. The new excitation lines at 33.7 and 34.7 Hz are easily visible, but not as strong as the primary calibration lines. I found these changes documented here.
 There are sporadic new isolated lines here and there (indicated in line list - see below)
 There is a "crab-killer" broad bump centered at about 58.6 Hz which degrades sensitivity in the Crab Pulsar band of interest (~59.3 Hz). On the other hand, the whole noise floor is elevated w.r.t. O1, anyway. So it may be premature to worry about the bump.


Figure 1 - spectrum for 50-100 Hz when the 3-hour 2-second-glitches stretch is included (~0.5 Hz lines marked with 'h' for 'half')
Figure 2 - 0-2000 Hz (removing 3-hour bad stretch from here on)
Figure 3 - 20-50 Hz sub-band 
Figure 4 - 50-100 Hz sub-band 
Figure 5 - 100-200 Hz sub-band
Figure 6 - 1300-1400 Hz sub-band (illustration of how clean the high-frequency band is)

Also attached are a larger set of zipped sub-band spectra and a lines list (excluding the bad 3-hour stretch). Note that because the statistics here are two orders of magnitude smaller than used for the full O1 run report, I am not yet removing lines seen then that may yet re-emerge with more accumulated post-O1 data. So many of the line labels in these figures are buried in the noise fuzz for now.

Line label codes in figures:

b - Bounce mode (quad suspension)
r - Roll mode (quad suspension)
Q - Quad violin mode and harmonics
B - Beam splitter violin mode and harmonics
C - Calibration lines
M - Power mains (60 HZ)
O - 1-Hz comb (0.5-Hz offset)
o - weaker 1-Hz and near-1-Hz combs (various offsets, including zero)
H - 99.9989-Hz comb
J - 31.4127 and 31.4149-Hz combs
K - 0.088425-Hz comb-on-comb
t - 1.999951-Hz, 2.07412-Hz and 2.07423-Hz combs
D - 56.8406-Hz comb
x - single line (not all singlets in the vicinity of quad violin modes are marked, given the known upconversion)