Displaying reports 45081-45100 of 84879.Go to page Start 2251 2252 2253 2254 2255 2256 2257 2258 2259 End
Reports until 16:09, Friday 09 March 2018
H1 General
cheryl.vorvick@LIGO.ORG - posted 16:09, Friday 09 March 2018 - last comment - 16:51, Friday 09 March 2018(40937)
Shift Summary:

State of H1:

Activity Detail:

Images attached to this report
Comments related to this report
cheryl.vorvick@LIGO.ORG - 16:19, Friday 09 March 2018 (40938)
  • 00:18 Janson and Ed out of the PSL
cheryl.vorvick@LIGO.ORG - 16:51, Friday 09 March 2018 (40939)
  • 00:51 Chandra heading to MY
H1 SUS
travis.sadecki@LIGO.ORG - posted 15:38, Friday 09 March 2018 (40936)
ETMy pre-First Contact charge measurement and First Contact application

Today, Betsy and I embarked on the final First Contact cleaning of the new ETMy.  We started by taking a charge measurement with a handheld electrometer (although we didn't hold it in our hand, we used a mount specifically made for it mounted to the AERM side of the Quad lower structure).  Since the new AERM has a hole in the middle, we had questions about where to mount the electrometer.  We attempted to contact Calum from the end station, but ran into the usual working-at-the-end-station issues i.e. no GC WiFi to use WiFi calling from cell phones, no cell signal, and we were unable to locate TeamSpeak on the workstation.  Using the landline phone in these situations is often impractical since we are usually fully garbed in which case you are supposed to stay in cleanrooms and the phone is located on the other side of the beamtube.  After driving back to the corner station, we learned that the workstation does have TeamSpeak installed, but needed to be accessed via command line and there was no microphone/speaker anyways.  

We then measured the charge in 5 locations (center, upper right, upper left, lower right, lower left) and found that all 5 locations were ~10 volts.  We'll remeasure these after First Contact removal/TopGun blowoff.  We then sprayed/painted on the First Contact layer onto the HR surface of the ETM.  We'll let the paint dry and continue with chamber closeout activities on Monday.

H1 TCS (TCS)
cheryl.vorvick@LIGO.ORG - posted 15:26, Friday 09 March 2018 (40935)
TCS QPDs dark offsets

I set the TCSX QPD dark offsets earlier today, but not TCSY QPDs offsets, and on both TCSX and TCSY QPD A and B sums I put an offset of 3 to keep the sum above zero, normal sums are around 10K counts.

Images attached to this report
H1 CDS (VE)
david.barker@LIGO.ORG - posted 14:00, Friday 09 March 2018 (40932)
Rate-Of-Change MEDM added to Vacuum pull down on SITEMAP

In support of the CP4 bake-out, I've created a temporary Rate-Of-Change (ROC) medm and linked it as the last item on the VE pull-down on the SITEMAP. It is calculating the ROC for a CP3 thermocouple, which is actually located at CP4. When the 1-HOUR measurement exceeds 1.0degC/hour in either direction, the gray rectangle turns RED, indicating a cell phone alarm has been issued.

Note, ROC also calculates the LN2 consumption rate of EY-CP7-Dewar as a test channel (consumption is about 1% dewar capacity per day).

Images attached to this report
H1 CDS
david.barker@LIGO.ORG - posted 13:50, Friday 09 March 2018 - last comment - 14:22, Friday 09 March 2018(40931)
GUARD_OVERVIEW MEDM updated

I have a script check_guardian_nodes_against_medm_screen which reports: nodes which exist but are not on MEDM screen, nodes which are on MEDM screen which do not exist. It produced one report: CS_BRS on the overview but does not exist. I have removed this node from the MEDM file.

Note: INJ_TRANS is white on the overview, Jamie is working on restarting this node.

Comments related to this report
jameson.rollins@LIGO.ORG - 14:22, Friday 09 March 2018 (40934)

The INJ_TRANS node can not be started, for unknown reasons.  However, the h1guardian0 host is apparently suffering from some sort of NFS lockup having to do with the injection machine, which presumably explains what we're seeing.  Dave is on the case.  Once this issue is resolved, the INJ_TRANS node should be able to be restarted with the following commands:

$ guardctrl create INJ_TRANS
$ guardctrl start INJ_TRANS

 

H1 CDS (DAQ)
david.barker@LIGO.ORG - posted 13:13, Friday 09 March 2018 (40930)
offload of raw minute trends from h1tw1 started

WP7399

The process of offloading raw minute trend files from h1tw0 to the DAQ SATABOYS has been started. The first part of the procedure was to switch writing the current data to a new directory on h1tw1 and adding the directory which contains the last 6 months of data to the NDS archive_raw_minute_dirs list. This was done and both NDS were restarted at noon.

The next step is to use h1fw1 to copy of files from h1tw1's SSD RAID over to the SATABOY RAID (a fully compressed ZFS specifically built to hold archived raw minute). I started this process at 12:52 PST. Note that this transfer uses ionice to reduce this transfer's impact on the frame writing.

H1 PSL
jeffrey.bartlett@LIGO.ORG - posted 11:37, Friday 09 March 2018 (40926)
PSL Chiller Water Use 2015 to 2018
Posted below are plots for the PSL Chiller water usage for the past 2.5 years. 

   Water usage in the Crystal chiller appears to be constant between 300ml and 100ml per week. It should be noted water is not added every 7 days, but as it is needed and per the operator's FAMIS task. The average is one week between top offs. The water usage in the Diode chiller is not tracked as it's reservoir is much larger and only needs occasional attention. 

Service timeline of the two chiller:    

   The chiller known as Gromit (S/N Crystal 64150, Diode 63793)was in service from May 2015 until May 2016. It was put into backup for annual maintenance rotation.  

   The chiller known as Wallace (S/N Crystal 44801, Diode 44807) was in service from May 2016 until September 2016. It was put into backup for service due to Crystal chiller trips. The faulty Crystal chiller controller was replace. 

   The Chiller known as Gromit was in service from September 2016 until February 2018. It was put into backup for annual maintenance rotation. 

   The Chiller known as Wallace is in service as of February 2018.  
    
Non-image files attached to this report
LHO VE
chandra.romel@LIGO.ORG - posted 09:19, Friday 09 March 2018 - last comment - 17:20, Friday 09 March 2018(40922)
CP4 bake

The CP4 enclosure temperature ramp is slowing down and the heater has been running at 100% for the last day. I've been increasing the temp of the GN2 flowing into CP4 so it's not a heat sink. I'm also trying to increase flow by increasing head pressure of Dewar (valve is wide open).

Images attached to this report
Comments related to this report
chandra.romel@LIGO.ORG - 11:09, Friday 09 March 2018 (40924)

Heaters controls still buggy. Heater ran at 100% all night with no significant increase in air temp. When I visited mid-Y this morning, I found it holding at temperature (setpoint 120C, actual air temps in 90s), so I rebooted the system. Heater now running at 34% and temps recovering (TC#1 reads 81C). New setpoint is 130C with 10C overlimit. 

GN2 temp holding steady at 125C. No change yet in head pressure of Dewar after yesterday's change to economizer valve. Flow fluctuates between 30-40 scfhx100.

Bubba turned chiller off to allow VEA to warm up. devil

bubba.gateley@LIGO.ORG - 11:36, Friday 09 March 2018 (40927)
By request from Chandra, I have shut the chiller down at Mid-Y to see if that helps maintain temperature on the bake out. I will continue to monitor the space temps.
chandra.romel@LIGO.ORG - 14:22, Friday 09 March 2018 (40933)

CP4 LN2 consumption is high ~5.4%/day. Three day trend attached, comparing CP4 to CP5. We have a truck delivery scheduled for Tuesday.

Images attached to this comment
chandra.romel@LIGO.ORG - 17:20, Friday 09 March 2018 (40941)

Current temps (degC):

TC1:  92.9

TC2:  80.6

TC3:  59.6

TC4:  78.4

GV11 air:  85

Heater output:  41%

GN2 gas regen temp: 124

GN2 pipe temp into enclosure:  85.6

GN2 exhaust pipe temp out of enclosure:  <75

RGA valve flange temp: 107

No change on the Dewar head pressure; still reads 12 psig at top and 10 psi next to pressure relief valve

GN2 flow ~ 40 scfhx100

Foreline pressure on turbo has increased from 2.4e-2 Torr to 3.2e-2 Torr since this morning

VEA is warm. Certain areas of enclosure insulation are warm, particularly where the velcro flap overlays the adjacent panel. In some cases the 4" thick panels don't butt up to each other so there are losses through the thin overlap.

LHO VE
chandra.romel@LIGO.ORG - posted 09:04, Friday 09 March 2018 - last comment - 10:57, Friday 09 March 2018(40920)
Y arm pressures

Here is another snapshot of Y-arm pressures over five days. We don't see a response in Y2 from changes in CP4 temperature, but Y1 side trends closely with CP4. GV11 (nearer to mid-station) has an outer o-ring leak in gate, but we evacuated this annulus and valved out. GV12 (Y2 boundary valve) has both inner and outer o-ring leaks on gate - also evacuated and valved out.

When BSC6 was replaced with spool at mid-Y several years ago, GV11 was exposed to air and the spool was not baked after installation (was it baked at factory?), so we expect outgassing from these components during the CP4 bake, but the sharp cuffs in Y1 pressure are not what we would predict with temperature changes in steel.

CP4 air temp trend over five days in enclosure is also attached.

Images attached to this report
Comments related to this report
john.worden@LIGO.ORG - 10:57, Friday 09 March 2018 (40923)

The replacement spool was baked at GNB but not after installation. The same is true for the MC tubes in the LVEA which were part of the same procurement for aLIGO.

LHO FMCS (VE)
chandra.romel@LIGO.ORG - posted 19:53, Thursday 08 March 2018 - last comment - 11:51, Friday 09 March 2018(40919)
compressed air failed and fixed at corner station

Kyle and I replaced a bad solenoid valve on the compressed air drying tower skid outside after getting alarms 'after hours'. Loss of compressed air caused the safety valves on the three turbo stations to close and thus spin down turbos. It also caused GV 6,8 to sag. After we regained compressed air we spun turbos back up, but YBM turbo is being difficult and keeps shutting itself down due to vibration (a known issue). We tried all the tricks with bypass valve and air admittance to load rotors. We'll let it spin 100% down tonight and try again tomorrow. I closed all three turbo isolation gate valves in a timely manner so the corner should not have been affected from back streaming. Pressure rose for a period while turbos were valved out. I didn't have time to check on in-vacuum high voltage equipment - don't think anything was turned on.

FYI: we did not replace the solenoid portion of the valve at the drying tower.

Comments related to this report
chandra.romel@LIGO.ORG - 11:51, Friday 09 March 2018 (40929)

YMB turbo spun back up today with no troubles or tricks. Foreline setpoint back to 5e-2 Torr.

H1 GRD
jameson.rollins@LIGO.ORG - posted 18:00, Thursday 08 March 2018 (40918)
Guardian upgrade aborted; system back to normal

The guardian upgrade has been completely aborted, due to the unexplained segfaults described in elog thread 40765 .  The entire guardian system is back to the exact same configuration as it was two weeks ago (guardian 1.0.3, h1guardian0 ubuntu12).  All nodes are up and running nominally.

h1guardian1 has been left in place to run demon excision tests: 20 fake guardian nodes are running under valgrind in the hope of catching a crash that would point to the problem.  These tests should not affect interferometer operation in any way.

H1 SUS
betsy.weaver@LIGO.ORG - posted 15:46, Thursday 08 March 2018 - last comment - 11:39, Friday 09 March 2018(40908)
EY converging on closeout finally

After ~3 days of ground loop hunting, fixing, breaking, fixing as well as a relocking of the ISI, we finally are getting good results on the 18 DOF transfer functions for all 3 suspended chains in BSC10 (ETMY main, ETMY reaction, and TMS).

Attached are results of the TMS.  Peaks from today overlap peaks from previous closeout sessions.

Kissel has cast an eye on these and calls them good.

Will post the ETM set shortly.

Next up:  First contact and electrometer optic readings, chamber clean-out, then closeup!

Non-image files attached to this report
Comments related to this report
betsy.weaver@LIGO.ORG - 15:53, Thursday 08 March 2018 (40912)

Also, attached is the latest set of ETMY and TMSY spectra after all of the ground loop work.  Combs are gone.

Images attached to this comment
betsy.weaver@LIGO.ORG - 11:39, Friday 09 March 2018 (40928)

Attached are the ETMY M0 and R0 chain transfer functions taken yesterday.  The 2.5Hz noise is showing itself again on the Transverse DOF TFs just a bit - maybe related to the ISI being locked again.  No knobs to turn for it so we're going with it for now.

Non-image files attached to this comment
H1 CAL (CAL)
aaron.viets@LIGO.ORG - posted 11:38, Wednesday 21 February 2018 - last comment - 11:39, Friday 09 March 2018(40631)
Improved High-pass Filter in gstlal calibration pipeline

After a lot of experimentation, I have found a way to improve the attenuation of frequencies below 9 Hz in the calibration by 1-2 orders of magnitude, without significantly increasing the computational cost or latency of the pipeline. Here is a list of what I've changed and what I've kept the same:

Of all the things I tried, this is what worked the best. Reasons I did not make this even better include:

Several plots are attached to show the new features. The first 5 plots are the frequency responses and comparisons to the ideal models for each of the filters used. The last 3 plots are comparisons of C01 data with data produced using the new filters. The attenuation is better by about 1-2 orders of magnitude, and there is just a very small amount of ripple added below 20 Hz.

Images attached to this report
Comments related to this report
aaron.viets@LIGO.ORG - 06:22, Thursday 01 March 2018 (40780)

I have made some additional improvement in the high-pass filtering in the DCS filters. The additional changes I made were:

  • Addition of a separate high-pass filter in the inverse sensing path before the inverse sensing filter. This also uses Matlab's least squares FIR filter, firls(). The cutoff frequency used is still 9 Hz, although I experimented with other cutoff frequencies. The filter is designed to have a response that drops to zero at 5 Hz and below. The length of this filer is currently set to 0.75 seconds.
  • Shortened inverse sensing filter to 0.75 seconds. The inverse sensing filter was previously 1 second in length. Since DARM_ERR is filtered at 16 kHz, the total amount of filtering in this path (now increased from 1s to 1.5s) needs to be kept manageable.
  • The actuation filter and the high-pass filter before it are now both 3 seconds in length.
  • In addition to the filers themselves, I have added code that writes the transfer functions corresponding to the combined effect of all filters applied to each path (inverse sensing and actuation). These are included in the filters files, so that they cannot be incorrectly paired with the wrong filters. In the DCS filters files, the names of these numpy arrays are invsens_filt_tf, tst_filt_tf, and pumuim_filt_tf.  In the GDS filters files, the names are: res_corr_tf and ctrl_corr_tf.
  • I also added a numpy array in the filters files that contains the filters' approximated response function. In both DCS and GDS filters files, this is called filters_response_function. In the GDS case, this gives only the portion of the response function that is applied by the GDS filters, not including the front end.

A similar set of plots is included, with several additions:

  •  I have implemented a new test of the filters that combines all the filters in the inverse sensing and actuation paths to show how well they approximate the model response function. A larger-than-expected error shows up above 1kHz where the contribution from the actuation filters drops to zero. I'm not yet sure why this is, but I'm not too concerned since it does not show up in the other response function plots, described next
  • I have also used a modified version of Maddie's response function plotting script to make plots of the response function as derived from the transfer function between DARM_ERR and DeltaL_free, and compare this to the model response function. (These are the last 3 files.) Errors from 10 Hz to 5 kHz look comparable to what they were before these changes. Note the small ~2% error just above 1kHz - this is due to the fact that the actuation is downsampled to 2 kHz in the gstlal calibration pipeline. At ~1kHz, the TST stage actuation still contributes a few percent to the total strain, leading to this ~2% error when it gets lost in downsampling. Notice also the few % error just above 10 Hz. There is a similar feature in the filters response function plot (described above), and in the PUM/UIM stage actuation filter.

It's also worthwhile to remind ourselves of the list of reasons why we wanted to improve this filter/what we wanted to improve:

  • Search groups prefer aggressively high-passed data. Hopefully this is sufficient, as doing much better would significantly increase computational cost.
  • Apparently the noise below 10 Hz has added to the difficulty of the data-cleaning effort. (?)
  • It is ideal, when data goes public, that people don't find anything that could be mistaken for something significant below 10 Hz.
  • There may sometimes be a need to model the high-pass filters in the gstlal calibration pipeline. Although common IIR filter representations like Butterworth, Chebyshev, and elliptic filters can be implemented as FIR filters, they are generally not the most effective. It takes a lot of taps to get a good filter; so it is more effective to use a different method (like minimizing the integrated squared error) to get the best filter we can for the lowest computational cost. Thus, the solution I propose to this problem is to use the transfer function that I have added into the filters files.
  • There has been concern about the error around 10 Hz seen in the inverse sensing filter in these GDS filters and similar ones. GDS filters I've produced with the new high-pass filter do not show this behavior. However, as noted above the PUM/UIM stage filter does seem to introduce ~1% error just above 10 Hz. It is not clear whether this is related to high-pass filtering, but it is worth investigating.
Images attached to this comment
aaron.viets@LIGO.ORG - 11:39, Friday 09 March 2018 (40925)

After further investigation, I've found that the the noted ~1% errors in the PUM/UIM stage filters just above 10 Hz are most likely due to notches in the actuation models at those frequencies, and do not seem to be affected by the high-pass filtering. One way to get rid of those errors is to remove the time-domain Tukey window from the filters. However, this generates a lot of noise in the spectrum due to the fact that the filters do not fall off smoothly.

I also found that the "shelf" seen at low frequency in the ASDs (the noise from DC to ~0.25 Hz) may be an artifact of the relatively low frequency resolution (I used 3-second FFTs, so 0.33 Hz resolution) in the calculation of the ASDs. I have produced another ASD from the same data using 64-second FFTs averaged over 12 hours. The "shelf" is not seen here. I also investigated the possibility that this is a DC component (in which case it would still be present in the new ASD I plotted, but not shown due to the higher resolution). I added a feature the the gstlal calibration pipeline that allows the option to remove a DC component from the data before filtering it. The method is to simply downsample the input data to 16 Hz (with high-quality anti-aliasing), take a running average of 16 seconds, and then upsample (with high-quality anti-imaging) and subtract the result from the input data. This can be done with zero latency by shifting the timestamps becuase the phase of a DC component is zero regardless of timestamp shifts. The result of removing the DC component before filtering was indistinguishable from not removing it, implying that this is not a DC component.

The attached plot shows a high-resolution spectrum comparison of C01 data to data produced using the new high-pass filters.  There appears to be a line present around 3 Hz.  The small differences between C01 and the new DCS data above 10 Hz are due to the fact that the kappas were not applied in producing the new data (I used the same data to produce the comparison to the modeled response function, which requires not applying the kappas).

Images attached to this comment
Displaying reports 45081-45100 of 84879.Go to page Start 2251 2252 2253 2254 2255 2256 2257 2258 2259 End