Displaying reports 54901-54920 of 84690.Go to page Start 2742 2743 2744 2745 2746 2747 2748 2749 2750 End
Reports until 13:49, Tuesday 18 October 2016
H1 DCS (CDS, DCS)
gregory.mendell@LIGO.ORG - posted 13:49, Tuesday 18 October 2016 - last comment - 15:55, Wednesday 19 October 2016(30626)
DMT calibration updated to gstlal-calibration 1.0.6-2.el7
Work Permit Number: 6252

The DMT calibration has been updated to gstlal-calibration 1.0.6-2.el7. Because of dependencies GDS was also updated to: gds-2.17.10-2.

John Zweizig has restarted the DMT monitors.
 

Comments related to this report
jeffrey.kissel@LIGO.ORG - 15:55, Wednesday 19 October 2016 (30675)CAL, CDS, DAQ, DCS
Tagging CAL.
H1 ISC (OpsInfo)
cheryl.vorvick@LIGO.ORG - posted 13:07, Tuesday 18 October 2016 - last comment - 14:04, Tuesday 18 October 2016(30624)
ALS Shutter Control Map

The medm SYS_CUST_SHUTTER_SUMMARY.adl shows the ALS shutters, but the names are wrong.  Attached is a map of what each shutter did today.

Images attached to this report
Comments related to this report
daniel.sigg@LIGO.ORG - 14:04, Tuesday 18 October 2016 (30627)

I guess we should file a FRS for EY. Controller channel 1 is unworkable for a while.

H1 DCS (CDS, DCS)
gregory.mendell@LIGO.ORG - posted 12:58, Tuesday 18 October 2016 (30623)
DCS has switch to archiving the larger H1_R frames under the CDS "full" directories

DCS verified all H1_R frames were copied from the CDS "science" directories into the LDAS archive up to the GPS endTime 1160847040.

LDAS has started copying the new larger H1_R frames from the CDS "full" directories, with the first larger H1_R frame with the "full" channel list starting from 1160854656.

H1 ISC
keita.kawabe@LIGO.ORG - posted 12:37, Tuesday 18 October 2016 (30622)
H1 BRDF quite similar to L1

Hiro asked me about LHO BRDF measurements like LLO (https://alog.ligo-la.caltech.edu/aLOG/index.php?callRep=28662).

Using numbers measured by Vinny (https://dcc.ligo.org/T1600085) when the arm power was about 100kW back in January, the corresponding BRDF numbers are:

  Power on OPLEV Distance BRDF
ITMX 2.4uW 33m 2.6E-4/sr
ITMY 3.9uW 33m 4.2e-4/sr
ETMX 11.8uW 5.6m 3.7e-5/sr
ETMY 8.9uW 5.6m 2.8e-5/sr

There's no evidence that this changes with power: alog 28449

H1 DetChar (DetChar, ISC, PSL)
gabriele.vajente@LIGO.ORG - posted 09:15, Tuesday 18 October 2016 (30618)
Coherences during the last lock

I ran a BruCo scan of last night's lock (GPS 1160787977 + 600s). The full report is available here. As pointed out by Sheila et al, the low frequency region (below 100 Hz) doesn't show much coherence with anything (low coherence with MICH/SRCL, fig 1 and 2, a bit with angular controls, fig 3 and 4, but lower than usual.)

In the jitter region, there are the usual coherences with IMC WFS and signals. However, I found interesting coherences with a few more channels in this region

I'm not sure what to make of all those coherences, since coupling through intensity or frequency noises were almost ruled out...

Finally, the DBB channels are not available in the science frames that are read by BruCo, so I separately computed the coherence with the DBB QPDs. Figure 12 shows the usual coherence with the DBB_QPD_1QY signal.

Images attached to this report
LHO General
patrick.thomas@LIGO.ORG - posted 08:12, Tuesday 18 October 2016 (30617)
Ops Owl Shift Summary
Jenne and Sheila concluded that the noise in the auxiliary length loops was keeping the IFO from locking on DRMI and had me set it to down for the night.

07:15 UTC Paused at PRMI_LOCKED for Jenne and Sheila
07:43 UTC Set to down for Jenne
07:45 UTC Starting initial alignment
08:24 UTC Initial alignment done
09:24 UTC Set ISC_LOCK guardian node to DOWN for the night
13:42 UTC Peter to H2 PSL enclosure and transitioning LVEA to laser safe
13:56 UTC Peter done
14:09 UTC Bubba to LVEA (WP 6254)
14:30 UTC Portable toilet service through gate
LHO General
patrick.thomas@LIGO.ORG - posted 06:57, Tuesday 18 October 2016 (30616)
LVEA is laser safe
Peter has transitioned the LVEA to laser safe.
H1 ISC (ISC)
jenne.driggers@LIGO.ORG - posted 02:22, Tuesday 18 October 2016 - last comment - 11:40, Tuesday 18 October 2016(30614)
Weirdo noise in aux length loops - alignment??

We're really struggling to acquire DRMI lock. It looks like our aux length loops suddenly have way more noise than they did before our last long lock stretch.  We're not at all sure why this is, but may want to look into it more, in case it hints at why we have more noise in the aux loops now than we did before we did the grouting / realignment in April. We can lock PRMI, but it is very noisy, and if we try to improve the buildups the noise gets worse.

We had a nice long lock, but then struggled to relock.  Nutsinee did an initial alignment, during which we decided to move IM2 and IM3 closer to their nominal positions, in acknowledgement of the warnings that have been on DiagMain lately.  However, we still couldn't aquire lock, so started to look at the noise.

Sheila and I found a time from earlier today (17Oct2016 16:03:00 UTC) where we were locked on PRMI for a few minutes, and saw that the MICH and PRCL noise was quite good.  In the attached screenshot that time is labeled "10+ hours ago".  When we first caught the PRMI, we had noise that looked like the "really bad" time in the screenshot.  This is more than 2 orders of magnitude worse than the quiet time for MICH between 10Hz-200Hz.  For PRCL the noise is only worse below about 150Hz, but it is still egregious.  By moving the alignment of the recycling cavity mirrors and the input steering mirrors, we could reduce the noise to the third set of traces, at the cost of losing at least a third or so of our sideband buildup. 

Thinking that this could be somehow related to our restoration of the IM2 and IM3 positions, we restored all suspensions (except RMs and OMs) to their witness or oplev values from 14 hours ago.  Patrick then did a careful initial alignment, but unfortunately our noise is still the same.  We can acquire PRMI but not DRMI.  At this point we're going to leave things as-is for now, and look into it again tomorrow after maintenence. 

We wonder though if this is a clue as to how / why we have so much extra noise in our aux length loops since April.

Images attached to this report
Comments related to this report
gabriele.vajente@LIGO.ORG - 11:40, Tuesday 18 October 2016 (30621)

Not sure if it's useful, but a BruCo scan for PRCL found large coherence with BS ISI signals, see some examples in the attached plots.

Similar scan for MICH shows even larger coherence, up to high frequency.

Images attached to this comment
H1 ISC
sheila.dwyer@LIGO.ORG - posted 01:31, Tuesday 18 October 2016 (30581)
Jitter noise again

Sheila, Jenne, Daniel

  1. The beam jitter seen by the IMC WFS became worse below 100 Hz as soon as the HPO was turned on, and has stayed similar since. The jitter at 100 Hz isn't much worse than it used to be. 
  2. Today Jenne and I redid a few white noise injections for MICH, SRCL, and jitter from the IMC PZT. The aux loop noise seems to be low enough that it is not our main problem.
  3. We don't think that the main coupling of HPO jitter noise to DARM is through lock point errors on the refl diode.

More about the jitter measurements:

Jenne, Daniel and I made two types of jitter measurements this afternoon, first exciting the IMC PZT and making a projection using IMC WFS DC, then exciting IM4 and making projections using REFL WFS.  The jitter measurements in the attached noise budget are based on the IMC PZT measurements, the IM4 ones are not included, because we don't believe that the REFL WFS noise floor is jitter, so these measurements were more like upper limits. The HPO jitter is in a gouy phase more similar to the one we excited using IM4 we believe, while the PZT excitations are in a gouy phase more simliar to the peaks from structures on the PSL table. 

For both types of measurements, we wanted to see if it is plausible that the coupling mechanism to DARM is through the REFL diode.  To do this we measured transfer functions to both the REFL control signal and to DARM.  When we are exciting the IMC PZT, we cause sensor noise in the IMC loop which gets supressed by the CARM loop, so measuring the coupling to DARM CONTROL and multiplying by the previously measured REFL control to DARM coupling causes us to overestimate the coupling to DARM.  For the IM4 excitation, we injected a line at 150 Hz, because we had to make a rather large injection in DARM to see it in REFL control.  Using the REFL control signal to estimate the coupling to DARM we underestimate the coupling by about a factor of 5.  This means that at least in the gouy phase that we excite with IM4 (which we think is similiar to the gouy phase where the broadband HPO jitter shows up), the main coupling of jitter noise to DARM is not through lock point errors on the REFL diode. 

Images attached to this report
H1 AOS
nutsinee.kijbunchoo@LIGO.ORG - posted 00:02, Tuesday 18 October 2016 (30613)
Ops EVE shift summary

TITLE: 10/17 Eve Shift: 23:00-07:00 UTC (16:00-00:00 PST), all times posted in UTC
STATE of H1: Lock Aquisition
INCOMING OPERATOR: Patrick
SHIFT SUMMARY: We had trouble locking DRMI. ISI BS ST2 CPs looked noisy but they weren't the cause of the problem. Noise eater acted up once or twice. Jenne and Sheila working on the alignment to reduce some excess noise.

Images attached to this report
H1 TCS
nutsinee.kijbunchoo@LIGO.ORG - posted 23:37, Monday 17 October 2016 (30612)
TCSY chiller top off

The water was at 5.6 cm when I went out. I added ~500 ml of water and the level indicator went all the way to the top. I noticed the water had a hard time making it's way down the filter and indeed the filter was puffed up from the bottom -- just like what Jason has seen before (alog30351). I took out the filter to let the indicator fall to it's true reading and added ~1250mL of water (total -- without filter in place). This brought the indicator from 5.6cm to 8.9cm. I put the filter back in and closed the cover very carefully so it doesn't push the metal filter on the side.

H1 ISC
kiwamu.izumi@LIGO.ORG - posted 19:09, Monday 17 October 2016 (30610)
Various out-of-loop sensors for frequency noise

Daniel, Evan, Keita, Kiwamu,

We checked the level of frequency noise at various out-of-loop equivalent sensors and then projected them to DARM to see if they make sense at all.

If we accept the projected noises, it is unlikely that frequency noise is the limiting noise source in the 200 - 1 kHz band.


[Various out-of-loop sensors for freq. noise]

We wanted to know the out-of-loop stability of frequency noise. We measured frequency noise transfer functions for the following sensors relative to REFL9I.

To do this, we excited one of the inputs of the summing node board with broad band noise from 100 Hz to 4 kHz. The relative transfer functions between REFL 9I and these sensors were found to be almost flat as expected. See the upper left panel of the third attachment for the flatness. In the reset of this report, the following scaler values will be used and we do not use the actual measured transfer functions.

We then converted the sensor spectra (taken when the interferometer was in low-noise) by using the above values to (uncalibrated) frequency noise as seen in REFL9I. The below shows (uncalibrated) frequency noise estimated by these sensors.

Good agreement is seen above 3 kHz where all the sensors see the loop-gain-limited frequency noise. For POPs, they are found to be limited by shot noise as expected at frequencies below 2 kHz or so, except that POP 9 sees some extra frequency noise in the jitter band (200 Hz- 1kHz). Since the coherence is not low below 50 Hz, we should not believe the spectra below 50 Hz or so.

[Projection to DARM]

The below plot shows projections of frequency noises to DARM using the different sensors. The coupling transfer function of REFL9I -> DARM was once measured by exciting the same excitation point as the above measurement. We confirmed that the coupling grows proportionally to frequency (29893). Also, see the upper middle panel in the third attachment for the coupling transfer function. For noise projection, I have used a simplified transfer function of 1e-5 x ( f /700Hz) [DARM meters / REFL9I counts]. Since all the out-of-loop sensors are already calibrated to equivalent of REFL 9I digital counts, all of them are just propagated to DARM by multiplying the same coupling transfer functions.

Again, the projection below 50 Hz is not trustable because of low coherence in the measurements. High frequency excess in DARM above 4 kHz seems to explainable by the frequency noise -- all the projections more or less agree with DARM. In the jitter band, 200 Hz - 1 kHz, the closest projection was given by POP 9I which showed some acoustic type structure. Although POP9I is still not high enough to entirely explain what we see in DARM. Moreover, the peak structure seen in POP 9I do not quite match the ones in DARM. Probably those structures in POP 9I are likely some kind of sensing noise.

In any case, if we believe this plot, frequency noise does not seem to be limiting the current DARM in the 200 Hz - 1 kHz band.

Images attached to this report
H1 CDS
david.barker@LIGO.ORG - posted 17:46, Monday 17 October 2016 (30609)
All models compiled against RCG2.3

WP6251 RCG3.2 upgrade.

In preparation for the RCG3.2 upgrade I have compiled all 106 models against it. I did not install the new code, this was just a check that all models compile against the new system. I took the opportunity to rebuild the H1.ipc file (current has 5544 lines, new has 5096 lines).

Procedure was:

create new build area /opt/rtcds/lho/h1/rtbuild-3.2

save H1.ipc to archive/H1.ipc.17oct2016 and empty H1.ipc

do first round of compiles (make -i World) to fully populate H1.ipc (many compiles abort on ipc error)

do second round of compiles to actually compile each model (took 49 minutes)

check that all error.log files are empty (indeed they are)

save the new H1.ipc into archive/H1.ipc.rcg3_2

restore original H1.ipc file (in case any models are restarted tonight)

H1 CDS (CDS, ISC, PSL, SUS)
jeffrey.kissel@LIGO.ORG - posted 17:38, Monday 17 October 2016 - last comment - 18:49, Monday 17 October 2016(30608)
Cleared PEM, ITM, PSL ISS, and CS ECAT1PLC1 of NOT INIT and NOT FOUND Channels in SDF System
J. Kissel

After taking a look at the SDF overview screen, I noted a plethora of yellow lights indicative of many channels not found or not initialized because of front-end model changes. As such, I've initialized and monitored all channels not initialized, and I've updated all (currently in use; see attachment) reference files to rid them of channels that no longer exist. The affected sub-systems are:
PEM EX, PEM EY
PSL ISS, and
CS ECAT1PLC1
Images attached to this report
Comments related to this report
jenne.driggers@LIGO.ORG - 18:49, Monday 17 October 2016 (30611)

[Sheila, Jenne, JeffK]

With the IFO in Down after a nice lock, we have accepted all of the SDF diffs (in monitored and not monitored channels), so that we'll reboot tomorrow in a much-closer-to-good state. 

H1 ISC (CAL, ISC)
evan.hall@LIGO.ORG - posted 14:05, Sunday 16 October 2016 - last comment - 17:53, Monday 17 October 2016(30573)
DARM contrast defect in full lock

I wanted to find out how much contrast defect light we have in DARM at the moment. It seems to be about 2.0(5) mA at the moment. Since we run with 20 mA of total photocurrent, this implies a homodyne angle that is mistuned by about 6° away from the nominal value of 90°. I did not check how stable it is over the course of several hours.

To measure the contrast defect, I watched the height of 332 Hz pcal line in DARM while varying the dc offset.

Non-image files attached to this report
Comments related to this report
evan.hall@LIGO.ORG - 19:55, Sunday 16 October 2016 (30575)

Also, I found that the DARM residual is microseism-dominated at 50 W of input power (the current blrms is about 0.5 µm/s). So I turned on a boost in FM6 of LSC-OMC_DC. We should incorporate this into the DARM filter modules.

jeffrey.kissel@LIGO.ORG - 17:53, Monday 17 October 2016 (30600)CAL
Expanding more on Evan's methods here:

Optical gain values in [mA/pm] were obtained by taking the magnitude of the transfer function at 331.9 [Hz] between H1:CAL-PCALY_RX_PD_OUT_DQ (pre-calibrated into [m] / zpk([],[1,1],1)) and H1:OMC-DCPD_SUM_OUT_DQ (pre-calibrated into [mA] to ~10% accuracy).

Total light on the OMC DCPD values in [mA] were pulled directly from H1:OMC-DCPD_SUM_OUT_DQ (again, pre-calibrated into [mA]).

The DARM DC offset was varied by adjusting the "fringe offset" or H1:OMC-READOUT_X0_OFFSET (pre-calibrated into [pm] to ~20-30% accuracy). This EPICs record can be found on the "IFO DC READOUT" sub-screen (called OMC_DC_READOUT.adl) of the OMC_CONTROL.adl overview screen. The nominal value is 10.65623 [pm], and to obtain the above data Evan varied the DARM DC offset from 6 to 13 in 1 [pm] increments.

     zeta = homodyne angle [rad] = arccot( contrast defect [mA] / total light on DCPDs [mA] )

where the contrast defect [mA] is the y intercept of the parabola.

The subsequent IFO optical gain vs. DC power on the DCPDs was then fit (by-eye) to blind/simple quadratic function with a DC offset. to arrive at the answer.

From Evan's presentation G1601599, which nicely distills the famous-yet-cryptic 2001 Buonnano&Chen paper, the response of a DRFPMI interoferometer using detuned resonant sideband extraction can be parametrized into a pair of complex poles (for the optical spring, at frequency |p| and quality factor Q), a pair of real poles (for the coupled cavity, or "RSE" pole, at frequency xi) and zero, at frequency z, which can potentially (and typically does for low detuning) cancel one of the RSE poles: 
     dP                    1 + i f / z 
     -- = g * ---------------------------------------           (5)
     dL       (1 + if/|p|Q + (f/|p|)^2) - (xi / f)^2
The zero, in his presentation, is composed of the following fundamental parameters,
                 cos(phi + zeta) - r_s cos(phi - zeta)
      z = f_a * ------------------------------------------      (8)
                 cos(phi + zeta) + r_s cos(phi - zeta)
where f_a is the arm cavity pole frequency (assumed to be the same for both arms), phi is the SRC detuning phase, and zeta is the homedyne angle.

One of the outputs of the above measurement, is that, if the homodyne angle, zeta, is consistently 90 +/- 6 [deg], then we can used Eq. (8) to simply fix the zero frequency in the overall IFO response (5), assuming the arm cavity pole frequency and SRC detuning phase also remain constant. This would reduce the parameter space over which the calibration group would have to MCMC in fits to measurements of the overall response (e.g. LHO aLOG 28302).

However, 
(1) This is, again, *one* measurement of the homodyne angle, zeta. We're going to have to measure it multiple times, and quantify the uncertainty in the estimate better, to make sure that we're confident it stays there.
(2) The SRC detuning phase, phi, and the arm cavity pole frequency, f_a, also need measuring with quantifiable uncertainty. These are also parameters believed to be fixed, but the question is always to what level. f_a has been measured before to be ~83 Hz, using several techniques (e.g. LHO aLOG 7054), but rarely with quantified uncertainty. Further, those measurements are typically taken of a single cavity, and there is worry that the pole frequency may change a bit in the full IFO due to different spot centering*. The detuning phase "can be determined by the spring frequency."
To me, this is quickly going down a rabbit hole of another independent MCMC parameter estimation fitting regime, but I'm still quite ignorant on the topic.

*word on the street is that LLO has a technique, once in full lock, of "kicking the SRM fast enough" such that full IFO remains locked but simple as an PRFPMI. I couldn't find an aLOG on it, and these discussions with Evan today were the first I'd heard of it. 

Worth exploring!
Images attached to this comment
gabriele.vajente@LIGO.ORG - 16:50, Monday 17 October 2016 (30606)

Doing a real least square fit gives different results, depending on what you assume

  1. If we require the minimum of the curve to be at z=0 (meaning that we have a good calibration of the optical gain zero), give a contrast defect of 1.6 mA. Sum of residuals is 1.3 mA^2
  2. If we allow the most generic second order polynomial, the fit is better (sum of residuals is 0.68 mA^2), but the minimum is at optical gain equal to 0.8 mA/pm and the contract defect is larger, 4.3 mA
Images attached to this comment
H1 ISC
evan.hall@LIGO.ORG - posted 11:44, Saturday 15 October 2016 - last comment - 10:56, Tuesday 18 October 2016(30558)
Sideband content of REFL LF does not make sense

Summary

Daniel points out that the behavior of REFL LF during the 9 MHz modulation depth reduction does not make sense:

One possible explanation is that the 9 MHz depth is a factor of 3 lower than we think it is. However, based on single-bounce OMC tests (described below), this seems to not be the case. So the discrepancy remains unexplained.

Details

For the OMC test, I first turned up the modulation depth by 3 dB (the slider value is normally 16.8 dB during lock acquisition, so I turned it to 19.8 dB).

Then I locked the OMC on the carrier, and then each of the 9 MHz sidebands, and recorded the following data:

Frequency

PSL power (W)

OMCR A sum (ct)

OMC trans sum(mA)

Carrier 9.8 600 <0.01
82 14.6
USB 9 47.2 2930 0.01
2860 1.07
LSB 9 47.7 2920 0.01
2880 1.07

I assign an uncertainty of 10% to the OMCR and OMC trans sum values. The OMC visibility is not perfect here, but we can nonetheless roughly infer the modulation index. If the carrier measurement had been done at 47 W, we would have seen 70.6 mA of sum photocurrent. Since Psb/Pc ≈ Γ2/4, this implies Γ = 0.25 rad during this measurement. This implies a value of Γ = 0.17 rad during normal lock acquisition. This is within 30% of the old value measured with the PSL OSA (0.22 rad). In other words, we are not missing a factor of 3 in the modulation depth, so the behavior of REFL LF during lock acquisition does not make sense.

Comments related to this report
evan.hall@LIGO.ORG - 14:00, Saturday 15 October 2016 (30560)

I am attaching more time series for what happens during 9 MHz modulation depth reduction.

The ~0.8% increase in the transmitted arm powers suggests a modulation depth during lock acquisition of about 0.13 rad. With this modulation depth, we'd expect a change of 2.0 mW on REFL LF during the reduction (instead we see 0.54 mW).

Images attached to this comment
evan.hall@LIGO.ORG - 21:18, Sunday 16 October 2016 (30577)

I made the following power measurements at 1.9 W:

RF9 RF45 REFL LF (mW) AS LF (mW)
16.8 23.2 0.315 69.7
13.8 23.2 0.271 68.5
13.8 20.2 0.236 49.1

I made the following measurements at 44 W, after reaching some kind of thermal equilibrium:

RF9 RF45 REFL LF (mW) AS LF (mW)
16.8 23.2 3.55 545
13.8 23.2 3.71 575
13.8 20.2 4.20 823

Note that (somewhat confusingly) REFL LF is calibrated into milliwatts on the diode itself, while AS LF appears to be calibrated into milliwatts exiting the AS port (i.e., before OM1).

We can use the REFL LF measurements to infer the carrier and sideband content both at 1.9 W and at 44 W. Here we assume the modulation depths have their nominal lock-acquisition values (16.8 dB for 9 MHz and 23.2 dB for 45 MHz, which based on old OSA measurements correspond to 0.22 rad and 0.28 rad of modulation depth). Additionally, we can scale the 1.9 W measurements to infer what we should see at 44 W, all other things being equal.

  9 MHz (mW) 45 MHz (mW) Carrier (mW) Total (mW)
1.9 W, from measurement 0.088 0.070 0.157 0.315
44 W, from measurement 0.64 0.84 2.55 4.02
44 W, scaled from 2 W 2.04 1.62 3.64

7.30

Note the large 9 MHz discrepancy from the power-up.

evan.hall@LIGO.ORG - 10:56, Tuesday 18 October 2016 (30620)

I copied the RF slider values for the 44 W measurement wrong out of my lab notebook, so here is the corrected table:

RF9 RF45 REFL LF AS LF
10.8 20.2 3.55 545
13.8 20.2 3.71 575
13.8 22.2 4.20 823

The algebra and resulting numerical values for the PD sideband content were done correctly, though.

H1 CAL (DetChar)
jeffrey.kissel@LIGO.ORG - posted 17:27, Friday 14 October 2016 - last comment - 10:14, Tuesday 18 October 2016(30548)
PCALY OFS Glitching; Not Related to CAL Line Changes
J. Kissel, D. MacLeod

Duncan had noticed that Omicron triggers for the H1 PCAL Y RX PD (H1:CAL-PCALY_RX_PD_OUT_DQ) had failed on Oct 13 02:51 UTC (Oct 12 18:51 PDT) because it was receiving too many triggers. 

Worried that it might have been a result of the recent changes in calibration line amplitudes (LHO aLOG 30476) or the restoration of the 1083.7 kHz line (LHO aLOG 30499), I've trended the output of the optical follower servo, making sure that it has not saturated, and/or is not constantly glitching.

Attached is a 3 day and 30 day trend.

There is indeed a feature in the trend at Oct 13 02:51 UTC, but it is uncorrelated in time with the two changes mentioned above. Indeed, the longer trend shows that the OFS has been glitching semi-regularly for at least 30 days. I'll have Detchar investigate whether any of these correspond with heightened period of glitching in DARM, but as of yet, I'm not sure we can say that this glitching in a problem.
Images attached to this report
Comments related to this report
shivaraj.kandhasamy@LIGO.ORG - 09:38, Monday 17 October 2016 (30589)DetChar

The number of glitches seems to be definitely large and seeing them in OFS indicate it is real (and will be seen in DARM). Since Pcal interaction to DARM (at LHO) is oneway i.e, DARM is not expected to influence Pcal, it is probably originating in Pcal. At LLO we have seen glitches in Pcal when there were issues with power supplies (a-log LLO 21430), so it might be good to check those possibilities.

evan.goetz@LIGO.ORG - 10:14, Tuesday 18 October 2016 (30619)CAL, CDS, DetChar
Evan G., Darkhan T., Travis S.

We investigated these glitches in the y-end PCAL OFS PD more deeply and can fully explain all of the deviations. The excursions either due to DAQ restarts, line changes by users (including manual oscillator restarts, or by request to make transfer function measurements), shuttering the PCAL laser, or maintenance activities. See the attached 35 day trend of the excitation channel, shutter status, and OFS PD output (trends for both the 16 kHz and 16 Hz channels).

What sets the limits on Omicron triggers? Should Omicron be set to allow a higher number of triggers for Pcal?
Images attached to this comment
H1 CDS (Lockloss)
sheila.dwyer@LIGO.ORG - posted 01:04, Wednesday 12 October 2016 - last comment - 17:11, Tuesday 18 October 2016(30439)
lockloss tool not working

 Possibly after some changes made durring maintence, the lockloss tool stopped working. I can use lockloss plot, but not select. 

sheila.dwyer@opsws4:~/Desktop/Locklosses$ lockloss -c channels_to_look_at_TR_CARM.txt select

Traceback (most recent call last):
  File "/ligo/cds/userscripts/lockloss", line 403, in <module>
    args.func(args)
  File "/ligo/cds/userscripts/lockloss", line 254, in cmd_select
    selected = select_lockloss_time(index=args.index, tz=args.tz)
  File "/ligo/cds/userscripts/lockloss", line 137, in select_lockloss_time
    times = list(get_guard_lockloss_events())[::-1]
  File "/ligo/cds/userscripts/lockloss", line 112, in get_guard_lockloss_events
    for t in guardutil.nds.find_transitions(GRD_LOCKING_NODE, t0, t1):
  File "/ligo/apps/linux-x86_64/guardian-1.0.3/lib/python2.7/site-packages/guardutil/nds.py", line 32, in find_transitions
    for buf in conn.iterate(t0, t1, [channel]):
RuntimeError: Requested data were not found.
Comments related to this report
sheila.dwyer@LIGO.ORG - 02:19, Tuesday 18 October 2016 (30615)

After noticing LLO alog 28710 I tried to svn up the lockloss script (we're at rev 14462 now), but I still get the same error when I try to use select

jameson.rollins@LIGO.ORG - 17:11, Tuesday 18 October 2016 (30643)

The problem at LLO is totally different and unrelated.

The exception you're seeing is from an NDS access failure.  The daq NDS1 server is saying that it can't find the data that is being requested.  This can happen if you request data too recent in the past.  It also used to happen because of gaps in the NDS1 lookback buffer, but those should have been mostly fixed.

Right now the lockloss tool is looking for all lock loss events from 36 hours ago to 1 second ago.  The 1 second ago part could be the problem, if that's too soon for the NDS1 server to handle.  But my testing has indicated that 1 second in the past should be sufficient for the data to be available.  In other words I've not been able to recreate the problem.

In any event, I changed the look-back to go up to only two seconds in the past.  Hopefully that fixes the issue.

Displaying reports 54901-54920 of 84690.Go to page Start 2742 2743 2744 2745 2746 2747 2748 2749 2750 End