Displaying reports 65341-65360 of 83105.Go to page Start 3264 3265 3266 3267 3268 3269 3270 3271 3272 End
Reports until 12:48, Tuesday 05 May 2015
H1 SUS
betsy.weaver@LIGO.ORG - posted 12:48, Tuesday 05 May 2015 - last comment - 12:52, Tuesday 05 May 2015(18244)
Update to SUS status screen

After the guardian states were rekeyed during the March SUS guardian revamping (alog 17259), the SUS_GUARDIAN_STATES_OVERVIEW_CUST.adl screen has been incorrectly displaying the SUS GRD status.  Today I fixed this and now the status lights accurately represent what state the SUS GRD is in.

Images attached to this report
Comments related to this report
betsy.weaver@LIGO.ORG - 12:52, Tuesday 05 May 2015 (18247)

Note, here's is the address of the medm file:

/opt/rtcds/userapps/release/sus/common/medm

H1 CDS
david.barker@LIGO.ORG - posted 12:48, Tuesday 05 May 2015 (18245)
CDS Maintenance Summary

ALS build against RCG2.9.2 [WP5183]

Jeff, Jim:

h1alse[x,y] models were built against RCG Tag2.9.2 and restarted. No DAQ restart was required. RCG version number on the GDS_TP screens is 4002 for this build.

DAQ reconfiguration [WP5184]

Jeff, Jim, Dave:

The DAQ was restarted at the following local times: 07:24, 07:25, 09:58, 11:39

The first two restarts were to apply the new INI files if they had been updated (they had not). The first raised DAQ errors on certain front ends, the second was to see if they could be cleared.

The third was to apply the new H1BROADCAST.ini and H1EDCU_HWS.ini files. Again certain front ends needed their mx-streams restarted.

It was then found that dataviewer would not show any fast channels in the signal selection list, and the slow channels were not quite correct. Jim tracked this down to a badly formed line in my updated H1EDCU_HWS.ini file. I have forgotten to put a close-square-bracket at the end of one channel. This was corrected and the fourth DAQ restart applied the fix (this time no frontends were DAQ glitched).

Take home message, always run inicheck on new ini files.

Guardian Reboots:

Jamie, Betsy, Jeff, Dave:

we rebooted the h1guardian0 machine twice this morning. First was to see what the load averages start with after a reboot (answer, 7 after 1 hour running). The second was to apply Jamies newer version of guardian.

prior version (guardian, ezca) = 1390,443

new version = 1445:474

 

 

H1 SEI
jim.warner@LIGO.ORG - posted 12:33, Tuesday 05 May 2015 - last comment - 13:31, Tuesday 05 May 2015(18243)
DARM and EX/Y ISI St1 blends

On Saturday, I was able to get some data on the effect of different blend filters on DARM.  It looks like we probably don't want to be using the 45mhz blends, or they need some re-working to reduce their low frequency performance. The attached plots are DARM  from 2 lock stretches on Saturday. This is the CAL CS DELTAL spectra, which Jeff helped  me calibrate, hopefully he'll explain in a comment. Blue traces are both end stations with 45mhz blends, orange traces are both end stations with 90 mhz blends, black is the ground. Ground was pretty similar between the 2 cases, range was similar, though slightly higher with the 90mhz blend, possibly better alignment? First plot is .01 hz to 3 hz, where most of the action is, the second plot is 1hz to 100hz.

The first plot  shows the 90 mhz blend does as well as the 45mhz blend down to .3 hz, then does a factor of several worse until ~50mhz, where the gain peaking on the 45mhz blend causes more motion.  Above 1 hz the 90mhz blend shows more RMS, I'm not sure of the cause, but there are features visible in the second plot at about 8-15hz that I don't understand. But they are probably not due to the blend change.

Images attached to this report
Comments related to this report
jeffrey.kissel@LIGO.ORG - 13:31, Tuesday 05 May 2015 (18248)CAL, DetChar, ISC, SEI
The method for calibrating the CAL-DELTAL_EXTERNAL_DQ DARM spectrum and getting it "right" around and below 10 [Hz]:
(1) undo the 5 zeros at 1 [Hz], 5 poles at 100 [Hz] whitening DAQ filter LHO aLOG 16702 as one would normally do for this channel at all frequencies.
(2) compensate for the digital UIM control filter (FM1 & 2, "int" and "lowboost", two poles at 0 [Hz], two zeros at 0.1 and 0.3 [Hz]) that we don't replicate in the CAL-CS actuation path because of numerical precision noise. (See LHo aLOG 17528)

That means, in DTT, one has to apply the following calibration filter:
Gain: 0.03
Poles: 1,1,1,1,1, 0, 0
Zeros: 100,100,100,100,100, 0.3, 0.1
where the gain of (exactly) 0.03 is to normalize the z:p = ([0.3 0.1] : [0 0]) filter necessary for getting the actuation at low frequencies correct in step (2) -- i.e. 
prod(2*pi*[0.3 0.1]) / (2*pi)^2 = 0.03

Why (2) works:
Remember that DELTAL_EXTERNAL is the sum of the calibrated DARM_ERR and DARM_CTRL channels,
DELTAL_EXTERNAL = (1 / C) * DARM_ERR + A * DARM_CTRL
where C is the sensing function (i.e. the IFO's "test mass DARM displacement sensor" calibration) and A is the actuation function (i.e. the ETMY transfer function). A dominates this sum below the DARM UGF at ~40 [Hz]. As such, well below 40 [Hz],
DELTAL_EXTERNAL ~ A * DARM_CTRL.
Since we're using hierarchical feed back to ETMY, where the UIM/TST or L1/L3 cross-over frequency is ~1 [Hz], then well below *that*,
DELTAL_EXTERNAL ~ A_{uim} * DARM_CTRL,
i.e. the total calibration for DELTAL_EXTERNAL "well" below 1 [Hz] is dominated by how accurately we reproduce / calibrate / model the UIM actuation path. Since the UIM digital filters we've intentionally left out in CAL-CS have frequency content below ~0.5 [Hz], they're simply "missing" from the calibration of DELTAL_EXTERNAL, and we can, offline, just multiply all of DARM by these filters, and get the "right" answer.

This being said, *all* calibration below 10 [Hz] still should be treated with some skepticism, because we have little-to-no precision measurements of the scale factor, DARM OLGTF frequency dependence, and/or TST/UIM cross-over frequency in this band (and we don't plan on making any). I could say it's "within a factor of two," because I think we've done everything right, but I have no measured proof to bound the uncertainty quantitatively. 

Above 10 [Hz], the latest estimate of precision and accuracy are described in detail in LHO aLOG 18186.
H1 GRD (GRD, SEI, SYS)
jeffrey.kissel@LIGO.ORG - posted 11:38, Tuesday 05 May 2015 - last comment - 13:13, Tuesday 05 May 2015(18240)
ISI HAM3 Guardian Fails to Advance Past
J. Kissel, D. Barker, B. Weaver

After the first reboot of the guardian machine this morning, all SEI chambers except HAM3 came up as expected: the SEI manager and ISI / HPI subordinates are coded to be smart enough to figure out what state the platforms are actually in and restore to that state upon initialization. HAM3's ISI subordinate did not. I was able to identify it because the HAM3 SEI manager was complaining that it's subordinate's request had changed. The solution was to simply by-hand change the request to HIGH_ISOLATED.

No big problem here, just want to start recording the outcomes of reboots so we can address any systematic issues. Note this did *not* happen on the second guardian machine reboot today.
Images attached to this report
Comments related to this report
jeffrey.kissel@LIGO.ORG - 11:58, Tuesday 05 May 2015 (18241)
This also happened for HEPI HAM1, at least after the second reboot. BUT this may be because he's unique in that it doesn't have a SEI chamber manager telling him where to go, not because of any errant code.

I've manually moved the requested state to ROBUST_ISOLATED, which is where the platform was already.
jameson.rollins@LIGO.ORG - 13:13, Tuesday 05 May 2015 (18249)

These are two totally different issues.  The HPI_HAM1 issue is just because it doesn't have an initial request state defined.  I think Hugh has now fixed that.

H1 AOS (SUS)
kiwamu.izumi@LIGO.ORG - posted 10:42, Tuesday 05 May 2015 (18237)
oplev calibration on ETMX and ETMY

Jason, Kiwamu,

We revisted the calibration of the oplev on ETMX and ETMY which showed calibration error of a factor of a few (alog 18218). In fact, they alll had underestimated the suspension angle by roughtly a factor of two. Here is a summary table of the calibration factors:

  old calibration [urad/cnts] new calibration [urad/cnts]
ETMX PIT 81.2 222.5
ETMX YAW 115.2 263.4
ETMY PIT 77.94 172.2
ETMY YAW 53.55 115.4

We also updated the SDF so that these new values are already reflected. Note that the number I updated yesterday was not accurate enough (alog 18218) since I was using the misaligned ETMX. We calibrated it again with the aligned suspension. I attach the measurement data nad fitting codes as a zip file.

Non-image files attached to this report
H1 ISC
filiberto.clara@LIGO.ORG - posted 10:30, Tuesday 05 May 2015 - last comment - 11:03, Tuesday 05 May 2015(18238)
QPD Whitening Filter Chassis Replaced - EY
Replaced QPD Whitening Filter Chassis S1101595 with S1101628. Keita reported 900 count DC offset on segment 2. 
Comments related to this report
richard.mccarthy@LIGO.ORG - 11:03, Tuesday 05 May 2015 (18239)
Looks like the spring influx of wildlife has had ramifications on our IFO.  More testing will be done but looks like mice may have contributed to the problem with the whitening chassis.  An opAmp was covered in corrosion and other problems on the board looked like a mouse outhouse.  We have cleaned and disinfected the chassis and are waiting for it to dry before doing more tests.
See attached photo
Non-image files attached to this comment
H1 SEI
hugh.radkins@LIGO.ORG - posted 10:02, Tuesday 05 May 2015 - last comment - 12:22, Tuesday 05 May 2015(18235)
HEPI Pump Stations Pressures shown little coherence with IFO control signals during run

Similar to yesterday's plot but I've added MICH SRCL & PRCL

See the attached three panel for all the three building Pressures coherence to trhe IFO control signals.

Corner Station had coherence approaching 0.7 with Mich at ~20mHz, everything else is less.

Images attached to this report
Comments related to this report
hugh.radkins@LIGO.ORG - 12:22, Tuesday 05 May 2015 (18242)

Scanning through coherence plots from the LVEA pressure to individual platforms and DOFs finds some continuous coherence to the HPI BS RZ.  See it on the upper right panel of the attached graph.  The thin dark green is the current coherence and still not as bad as the pale thick lighter green reference line from before our controller tweeking back in Jan/Feb.  However, there is a fair swath of non zero area from a few mHz to 100mHz.  The same area where we see some coherence with MICH.

So why is the BS the most coherent.  While the pump servo does get its signal from the pressure sensors at the BS, I'm more suspicious about the very large constant drive the Z DOF on the BS is currently applied by HEPI.  When the Pump Stations are off, the BS HEPI sags so low that some of the vertical IPS are out of their linear range.  This requires the DC BIAS to be almost 400um for the Z DOF.  Maybe this gives us some Z to somethin-mich-is-sensitive-to coupling.  It is on our wish list to lift this up with the HEPI Mechanical Springs.

Images attached to this comment
H1 CDS
james.batch@LIGO.ORG - posted 09:57, Tuesday 05 May 2015 (18234)
Replaced command line nds tools, dataviewer
WP #5164

Replaced dataviewer and command line nds tools to remove warning message about communication protocol version being unexpected.
H1 CDS
james.batch@LIGO.ORG - posted 09:28, Tuesday 05 May 2015 (18233)
GDS tools updated for Ubuntu 12 control room computers.
WP #5170

Update control room GDS tools to version 2.16.17.2-1, includes awgstream (compiled against new gds libraries, no code change).

This change fixes printing to files in diaggui and foton, gives the user the ability to set very small numbers in awggui, fixes a minor bug in allowed sample rates in foton. 

For the more obscure changes, foton can be used for non-aLIGO filter development involving non-standard sample rates (using a command line option).  In diag and diaggui, multiple broadcast addresses can now be specified as a comma-separated list in the LIGO_RT_BCAST environment variable.  Also in awggui, awgstream, diag and diaggui, setting testpoints can be restricted to specific models.
H1 ISC
peter.fritschel@LIGO.ORG - posted 09:22, Tuesday 05 May 2015 (18231)
SRC alignment controls: H1 vs L1

Comparison between the control channels used for the signal recycling cavity (SRC) alignment, H1 and L1:

 

  DoF Sensor Controlled optic
H1 SRC1 AS_B RF36I SRM
SRC2 AS_C DC SR2 & SRM
L1 SRC1 AS_C DC SR2
SRC2 AS_A RF36I SRM

Both IFOs use a AS port, 36 MHz WFS to control SRM alignment, though H1 uses WFS B and L1 uses WFS A. I don't know if this difference is arbitraty or reflects some real difference in sensing. Both IFOs use the AS port QPD, AS_C, to control the alignment of SR2, though H1 also feeds this signal to the SRM, to decouple the action of this loop (SRC2) from the SRC1 loop.

The other thing to notice is that the DoF (degree-of-freedom) naming between the H1 and L1 is swapped. This is just unfortunate and should be fixed.

H1 CDS (DAQ, ISC, SEI)
jeffrey.kissel@LIGO.ORG - posted 07:04, Tuesday 05 May 2015 - last comment - 08:45, Tuesday 05 May 2015(18223)
Beginning CDS Maintenance
J. Kissel

Plan for the morning:
- Recompile, reinstall, and restart BSC HPI models to absorb changes that were a residual from the HAM model updates
- Install ALS EX and EY models, which have been compiled against the tagged release of RCG 2.9.2 (it had only been compiled against the branch to date)
- Restart the frame builder / DAQ / h1cd0 to absorb new TCS Beckhoff channels and the updated channel list from the new BSC HEPI template.

Bringing all IFO guardians to DOWN and IMC guardian to OFFLINE, and bringing BSC Chambers to OFFLINE.
Comments related to this report
jeffrey.kissel@LIGO.ORG - 07:51, Tuesday 05 May 2015 (18224)
I've successfully installed and restarted ALSEX and EY, and successfully compiled, installed and restarted all BSC HEPIs. All chambers are back online, and I've confirmed that the IFO can reach the DRMI_LOCKED ISC_LOCK guardian state.

Sadly, the Framebuilder wasn't so happy with its restart. I tried twice, but the result is the same failure mode: the following front-ends show "02xbad" status:
h1sush56

h1susauxb123
h1susauxh2
h1susauxh34
h1susauxh56

h1asc0

h1susex

h1pemmx0
Note that all of these models are (at least superficially) unrelated to BSC HEPIs and ALS EX/EY.
I've reached the limits of my debugging abilities for the frame builder. I'll have to wait for the pros to deal with this issue.
Images attached to this comment
jeffrey.kissel@LIGO.ORG - 08:45, Tuesday 05 May 2015 (18229)
J. Kissel, J. Batch

The 02xbad error message seems to have been a result of a common occurrence -- a restart of the frame builder glitches the mx_stream process on some front ends. The first thing to try is to log on to the front end, and restart the mx_stream porcess, by running the command
sudo /etc/start_streamers.sh


Jim performed this command on all of the errant front-ends, and the bad DAQ status has cleared. 

Also -- he informed me that even installing the ALS models while the RCG is pointing to a different version will overwrite some necessary stuff and render the compilation against RCG 2.9.2 will cause badness. Jim changed the build machine's pointers briefly back to 2.9.2, recompiled and reinstalled the h1alsex and h1alsey models and I restarted them. All seems clear, and h1build pointers have been reverted back to RCG 2.9.1.
H1 PSL (PSL)
jason.oberling@LIGO.ORG - posted 15:39, Monday 04 May 2015 - last comment - 09:01, Tuesday 05 May 2015(18215)
PSL Diode Chiller Interlock Trips

Summary of the PSL trips from 2015-5-1 to 2015-5-3 during the LHO mini run.  Every instance of the PSL tripping was due to the same interlock, H1:PSL-IL_DCHILFLOW, tripping with no apparent loss in coolant flow for the diode chiller, H1:PSL-OSC_DCHILFLOW.  The first three trips on 2015-5-3 were during the long interlock trip that Nutsinee reported in alog 18187.  Data for the other PSL trips over the last 10 days have been reported in alogs 18083 and 18134.  All times UTC.

Images attached to this report
Comments related to this report
jason.oberling@LIGO.ORG - 09:01, Tuesday 05 May 2015 (18230)

Submitted bug report #1057

Displaying reports 65341-65360 of 83105.Go to page Start 3264 3265 3266 3267 3268 3269 3270 3271 3272 End