Displaying reports 64721-64740 of 83254.Go to page Start 3233 3234 3235 3236 3237 3238 3239 3240 3241 End
Reports until 13:49, Tuesday 09 June 2015
H1 AOS (AOS)
darkhan.tuyenbayev@LIGO.ORG - posted 13:49, Tuesday 09 June 2015 (19026)
Pcal line frequencies have been swapped
Sudarshan, Darkhan,

We have swapped Pcal line frequencies (EX <--> EY) and plan to keep them this way until the end of the ER7.

Before swapping we had Pcal lines at following frequencies:
PCALX at 33.1 Hz and 534.7 Hz
PCALY at 36.7 Hz and 540.7 Hz

For the rest of ER7 we will have lines at:
PCALX at 36.7 Hz and 540.7 Hz
PCALY at 33.1 Hz and 534.7 Hz

SDF_OVERVIEW monitors have been updated accordingly.
H1 General
nutsinee.kijbunchoo@LIGO.ORG - posted 13:00, Tuesday 09 June 2015 (19007)
Owl Shift Summary

00:00 Jim left the interferometer locked for me!

            EY dust monitor went off. > 0.3 u has 914.3 counts/ft^3, >0.5 u has 57.1 counts/ft^3

2:42 Lock loss

3:00 AS 90 too low. Adjusted BS yaw did the job.

3:11 Lock loss at BOUNCE_VIOLIN_MODE_DAMPING. Redo the initial alignment.

3:20 LSC-TR_X Not flashing. Realigned SR2, SR3, and PR2 pitch and yaw.

04:30 Locking at LSC_FF. Intent bit switched to Undisturbed. Guardian worked fine at LOWNOISE_ESD_ETMY step (I was told that it might not work properly). I think it worked at BOUNCE_VIOLIN_MODE_DAMPING as well (after running the code by hand I accidentally let the Guardian run through this state. It didn't lose lock).

6:06 Intent bit switched to Commissioning. Get ready for the hardware injection (scheduled to start at 1117890580 GPS time)

6:09 Injection started

6:13 Injection finished. Intent bit switched to Undisturbed.

6:17 Intent bit switched to Commissioning. Another injection scheduled to start at 1117891250 GPS time. Same injection with gain increased.

6:24 Injection finished. Intent bit switched to Undisturbed.

8:00 Handling off the ifo to Jeff.

Images attached to this report
LHO General (CAL, DetChar, GRD, INJ)
vernon.sandberg@LIGO.ORG - posted 12:29, Tuesday 09 June 2015 (19024)
State of ER7 Data Taking

ER7 Data Taking started 2015 June 3 at 14:00:00 pdt, 21:00:00 utc, 1117400416 gps.
As of this morning, 2015 June 9, we have accumulated approximately 33 hours of "analysis-ready" coincident data between LHO and LLO.  H1 has collected approximately 77 hours of analysis-ready data.  L1 has collected approximately 37 hours of analysis-ready data.  We have approximately 5 days left in the run plan for ER7.

At the beginning of ER7 Data Taking, H1 was configured and calibrated for operation at ~17 W of input power.  Over the weekend its input power was raised to 24 W.  This resulted in a few percent error in the calibration and operating configuration.  We have restored the input power for H1 back to 17 W and will operate it in this configuration for the remainder of ER7.  This is to deliver data to the analysis groups from a known characterization of the detector.


Where we are with regard the JRPC ER7 page (https://wiki.ligo.org/LSC/JRPComm/EngRun7):
Requirements
Detectors
Stable and reliable locking of H1 and L1 in configurations that could plausibly serve in an observing run
Best effort to have similar sensitivities, but no requirement stated
State reporting by Guardian and ODC
Calibrated h(t) channel (see T1300950 for O1 requirements)
    Expect L1 calibration accuracy of 20% amplitude & 10-20deg phase from 10 Hz to 2kHz. Aiming for 20% amplitude and 20 deg phase from 2kHz to 5 kHz.
    Expect H1 calibration accuracy within a factor of 2 in amplitude; no phase requirement.  - delivered 2015 June 2
Sufficient automation to be controllable by operators - achieved, guardian is working well
Hardware injections  - hardware and software installed, injections have been carried out and confirmed by analysis groups
Blind Injections Implementation and Testing
approximately 7 days of data taking - in progress, the most stringent is the CBC coincidence requirement of 48 hours, of which we have 33 hours to date

Requirements checklist for ending the run:

CBC:
    Would like >2 days coincident science data
    Lock periods >4 hours benficial for CBC detchar investigations
    (Request) Test H1 and L1 coherent HW injections

CW:
    CW hardware injections for at least one interferometer
    More than 75 hours of L1 DC-readout data and more than 50 hours of H1 DC-readout data

Stochastic:
    Carry out and recover a stochastic injection.

Burst:
    Would like >2 days coincident science data
    Test EM follow-up infrastructure (EM Processor, PE codes, ...) with coherent HW injection in H1 and L1.


Detailed progress in acheiving these goals is discussed every day at 1:00 pm pdt at the JRPC ER7 Run Status meeting on teamspeak JRPC channel, during the period of the run.


 

H1 CDS (DAQ)
david.barker@LIGO.ORG - posted 12:26, Tuesday 09 June 2015 (19023)
CDS maintenance Summary

09:55PDT h1oaf - all filter coefficients loaded

10:14PDT cdsegw0 - epics gateway between H1FE and H1SLOW VLANs restarted to permit h1guardian0 connection to h1ecatx1 (which was restarted)

10:25PDT h1sush2a - restart all models to perform a DAC-AUTOCAL

10:30PDT h1sush2b - restart all models to perform a DAC-AUTOCAL

10:34PDT h1sush34 - restart all models to perform a DAC-AUTOCAL

10:43PDT h1broadcast0 - reboot to clear potential network error

11:50PDT h1susb123 -  restart all models to perform a DAC-AUTOCAL

Other than h1broadcast0, no DAQ restart today.

H1 PSL
edmond.merilh@LIGO.ORG - posted 12:11, Tuesday 09 June 2015 (19021)
Weekly DBB/ISS scans
Non-image files attached to this report
H1 PSL
thomas.shaffer@LIGO.ORG - posted 12:09, Tuesday 09 June 2015 (19022)
ISS Diffracted Power

Diffracted power was up to ~9.3%, brought it back down to 6.7% with a refsignal of -2.06V

LHO General
thomas.shaffer@LIGO.ORG - posted 12:04, Tuesday 09 June 2015 - last comment - 16:14, Tuesday 09 June 2015(19013)
Ops Maintenance Log

809 - Richard to both ends

809 - Jeff B to LVEA then to ends setting up dust mons

811 - Christina fork lifting to OSB receiving and opening door

814 - Rick to manifolds on both arms

820 - Kyle to EY

823 - Jodi to LVEA to put signs up, then to MY

826 - Christina/Karen to EY to clean

827 - Beam tube cleaning start

832 - Robert to EY to move coils

832 - Patrick to restart EX Beckhoff

835 - Jodi and Rick out of LVEA

838 - Andres to LVEA to move parts around

845 EX Beckhoff back up

853 - Fil/Peter K to LVEA

900 - Kingsoft on site for RO work

905 - Praxair truck on site

907 - Fil/Peter out of LVEA

909 - Jodi leaving MY

917 - Andres out

921 - Gerardo to LVEA for wrenches

923 - Mitch to ends for serial number hunt

927 - Karen/Christina leaving EY for EX

928 - Gerardo out and to EY

947 - Robert out of LVEA

1000 - Praxair truck #2 on site

1006 - Daniel to EY to look at TCS setup

1010 - Richard back fomr Ends

1020 - Robert to LVEA

1020 - Karen/ Christina leaving EX

1020 - Fil to EY

1027 - Ed to CER

1036 - Ed out

1040 - RIchard to EY

1049 - Rick LVEA fit check

1052 - Daniel back, for a moment

1057 - Richard to LVEA looking at Cosmic Ray Detector

1105 - Christina/Karen to LVEA

1107 - Patrick restarting PEMEY

1128 - Mitch back

1128 - Daniel back

1133 - Jeff B back

Comments related to this report
jeffrey.bartlett@LIGO.ORG - 16:14, Tuesday 09 June 2015 (19032)
Log for second half of the day:

11:48 Beam Tube cleaning crew breaking for lunch
12:00 Start both dust monitors at End-Y
12:00 Kyle – Back from End-X – Note: Fan and power supply running while turbo pump spins down
12:27 Bubba & Gerardo – Back from End-Y 
13:35 Beam tube cleaning restarted HNWX2
14:48 Kyle – Going to End-X to shut off turbo pump fans and power supply
15:16 Kyle – Back from End-X
15:30 Beam cleaning team done for the day
H1 TCS
daniel.sigg@LIGO.ORG - posted 11:41, Tuesday 09 June 2015 (19020)
EY ring heater hooked up for charge measurements

The ring heater for ETMY was disconnected from the chassis. The power of the chassis was already off, since we were not using it. A special cable which shorts all ring heater segments together was connected to the output of an SR560. The SR560 ground was connected to the ESD driver ground, while its input is driven by the PEM DAC (H1:PEM-EY_GDS_1_EXC). A drive of 12000 counts corresponds to about 1.8Vpp.

H1 CDS
patrick.thomas@LIGO.ORG - posted 11:12, Tuesday 09 June 2015 (19017)
end Y weather station IOC restarted
Got disconnected as part of dust monitor work at end Y. Burtrestored.
H1 INJ (CAL, DetChar)
jeffrey.kissel@LIGO.ORG - posted 10:32, Tuesday 09 June 2015 (19015)
Updated Hardware Injection's Inverse Actuation Filter Turned ON
J. Kissel

In the H1:CAL-INJ_HARDWARE and H1:CAL-INJ_BLIND filter banks, I've turned ON the updated inverse actuation filter for ER7 (which lives in FM2 of both banks), turned OFF the mini-run filter (which *still* lives in FM1) and accepted the changes in the SDF system. See LHO aLOG 18997 for design details of the new filter.
H1 CAL (DetChar)
jeffrey.kissel@LIGO.ORG - posted 10:02, Tuesday 09 June 2015 - last comment - 11:02, Tuesday 09 June 2015(19012)
Lock Segments at 23W (and therefore calibration should be used with caution)
J. Kissel

Over the weekend, Evan, Stefan and Kiwamu has explored running the IFO at 24 [W] request PSL input power (see e.g. LHO aLOG 18923) instead of 17 [W] for which the interferometer had been calibrated (see LHO aLOGs 18769 and 18813). Because we do not yet have automatic optical gain scaling built into the IFO's control system, the calibration will be incorrect for the following science segments:
Seg Num GPS Start       GPS End         Duration [s] UTC Start             UTC End
1	1117601338	1117665437	64099        Jun 06 2015 04:48:42  Jun 06 2015 22:37:01
2	1117667359	1117702258	34899        Jun 06 2015 23:09:03  Jun 07 2015 08:50:42
3       1117709888	1117743019	33131        Jun 07 2015 10:57:52  Jun 07 2015 20:10:03
4	1117748054	1117773188	15134        Jun 07 2015 21:33:58  Jun 08 2015 04:32:52
5	1117803358	1117814235	10877        Jun 08 2015 12:55:42  Jun 08 2015 15:56:59
6	1117814313	1117815464	1151         Jun 08 2015 15:58:17  Jun 08 2015 16:17:28
7	1117829201	1117833161	3960         Jun 08 2015 20:06:25  Jun 08 2015 21:12:25
---
                        Total Time      Uptime@23[W] Single IFO Duty Factor During These Segments
                        64.40 hr        45.27 hr     70.3% 

Offline optical gain calculations are being made by the GDS calibration pipeline, but they are not being applied directly since this is the first time they've been calculated. However, evidence still suggests that LHO's DARM coupled cavity pole frequency (i.e. the single-pole approximation to the interferometer's response to gravitational waves / displacement noise) is still a moving target, so the calibration error (not uncertainty, but actual error) may not only just be a scale factor, but a frequency-dependent error. We should* have enough information from PCAL and DARM calibration lines to make an estimate of how the frequency dependence is changing over time.

*"should" is still "in principle;" we have not yet finished the commissioning of processing PCAL / DARM calibration lines to a point where we can determine at what precision the 6 lines will be able to determine the optical transfer function. This work is on-going.
Comments related to this report
kiwamu.izumi@LIGO.ORG - 10:47, Tuesday 09 June 2015 (19014)

"Incorrect" sounds too strong to me.

I would say it was incorrect only in the sense that the cavity pole frequency was uncertain which is the case not only for the 24 W configuration but also for the 17 W. Otherwise we believe that the calibration had remained valid both in GDS and CAL-CS at 24 W (though, rememeber CAL-CS has not fully updated to the equivalent of GDS, alog 1880 and hence the descrepancy between them). The OMC has  a power-scaling functionality (alog 18470) and therefore, ideally it does not change the optical gain as we change the PSL power. As for the cavity pole frequency, the Pcal lines should be able to tell us how stable it has been.

As reported in alog 18293, the optical gain seemed to have dropped by 4% in this particualr lock according to the Pcal line at 540 Hz. Sudartian is currently analyzing the Pcal trend, but it seems that the optical gain typically changes by 4-5 % in every lock stretch probably due to different OMC error gain (which is computed in every RF->OMC transition) and perhaps different alignment somewhere. We compensated it by increasing OMC-READOUT_ERR_GAIN by 4 % at the beggining of this particular lock and therefore we thought the calibration was good assuming the cavity pole stayed at the same frequency, 355 Hz.

daniel.hoak@LIGO.ORG - 11:02, Tuesday 09 June 2015 (19016)DetChar

I suspect there is a lingering source of error in the gain of the OMC-DCPD --> DARM_IN1 path.  This may be due to the initial gain-matching calculation between DCPD_SUM and RF-DARM, but it could also be due a scaling error as we adjust the overall gain during the power-up step.  We initially set the gain at a DARM offset of ~40pm, but as we power up to 23W we reduce the offset to ~15pm.  The current gain-scaling calculation that Kiwamu links to does not account for the small static DARM offset that we have observed (it's a fraction of a picometer, see here).  I will post a note about this today -- the overall effect should be very small, but may account for the ~4% change that we have observed.  (If this is the source of the gain error it will be proportional to DARM offset, which is the same as power level since we change both at the same time.)

H1 CDS
patrick.thomas@LIGO.ORG - posted 08:47, Tuesday 09 June 2015 (19010)
restarted h1ecatx1
Biweekly crash recovery. Burtrestored to 06/08/2015 00:10.
LHO General
thomas.shaffer@LIGO.ORG - posted 08:13, Tuesday 09 June 2015 - last comment - 08:21, Tuesday 09 June 2015(19008)
Ops Report

Out of Science mode.

I flipped the intent bit because with Tuesday maintenance comes lots of noise.

Comments related to this report
thomas.shaffer@LIGO.ORG - 08:21, Tuesday 09 June 2015 (19009)

Lock broke, we will keep it this way till the maintenance period is over or until we hear otherwise.

H1 INJ (DetChar, INJ)
peter.shawhan@LIGO.ORG - posted 07:43, Tuesday 09 June 2015 - last comment - 14:01, Tuesday 09 June 2015(19006)
First test of detchar 'safety' injections
Peter Shawhan, Andy Lundgren, Nutsinee Kijbunchoo

We did a first -- and successful! -- test of the "detchar" or "safety" hardware injections shortly after 6:00 PDT this morning, at the time recommended by Jeff (work permit 5262).

The detchar injections are a sequence of loud sine-gaussians at a range of frequencies, primarily intended to check for couplings from the GW strain channel to auxiliary channels.  (See https://dcc.ligo.org/LIGO-G1500713 .)  For now, at least, we are using a set of 14 frequencies logarithmically spaced from 30 Hz to 2000 Hz, each injected at 3 different amplitudes to try to get target SNR values, spaced 5 seconds apart.  Here is the full list with times relative to the start time of the injection:
Matlab> GenerateSGSequence('H1','H1_ASD_at_1117710916.txt');
__time__   __freq__   __SNR__    __AMP__
    0.50       30.0      25.0    2.22e-20
    5.50       41.4      25.0    7.54e-21
   10.50       57.2      25.0    2.86e-21
   15.50       79.1      25.0    1.72e-21
   20.50      109.2      25.0    1.52e-21
   25.50      150.9      25.0     1.7e-21
   30.50      208.4      25.0    1.97e-21
   35.50      287.9      25.0    2.92e-21
   40.50      397.7      25.0    3.73e-21
   45.50      549.3      25.0    5.42e-21
   50.50      758.8      25.0    6.95e-21
   55.50     1048.2      25.0     1.1e-20
   60.50     1447.9      25.0    1.71e-20
   65.50     2000.0      25.0    2.68e-20
   70.50       30.0      50.0    4.44e-20
   75.50       41.4      50.0    1.51e-20
   80.50       57.2      50.0    5.71e-21
   85.50       79.1      50.0    3.44e-21
   90.50      109.2      50.0    3.03e-21
   95.50      150.9      50.0    3.41e-21
  100.50      208.4      50.0    3.94e-21
  105.50      287.9      50.0    5.85e-21
  110.50      397.7      50.0    7.47e-21
  115.50      549.3      50.0    1.08e-20
  120.50      758.8      50.0    1.39e-20
  125.50     1048.2      50.0     2.2e-20
  130.50     1447.9      50.0    3.41e-20
  135.50     2000.0      30.0    3.22e-20
  140.50       30.0     100.0    8.88e-20
  145.50       41.4     100.0    3.02e-20
  150.50       57.2     100.0    1.14e-20
  155.50       79.1     100.0    6.87e-21
  160.50      109.2     100.0    6.06e-21
  165.50      150.9     100.0    6.81e-21
  170.50      208.4     100.0    7.87e-21
  175.50      287.9     100.0    1.17e-20
  180.50      397.7     100.0    1.49e-20
  185.50      549.3     100.0    2.17e-20
  190.50      758.8     100.0    2.78e-20
  195.50     1048.2     100.0    4.41e-20
  200.50     1447.9      75.0    5.12e-20
  205.50     2000.0      30.0    3.22e-20
The file, on h1hwinj, is /data/scirun/O1/HardwareInjection/Details/config/Burst/Waveform/detchar_1117890580_3_H1.txt . With H1 running in good low-noise mode, Nutsinee switched the intent bit to 'commissioning' and we first injected the sequence starting at 1117890580 with an overall scale factor of 0.25 -- so the target SNRs/amplitudes are a factor of 4 smaller than in the table above. Nutsinee didn't see anything obvious appearing in the live spectrum initially, but Andy looked at Omicron output afterward and say that it had picked up at least some of the louder signals. We then injected the sequence again starting at 1117891250, this time with an overall scale factor of 1.0 . Nutsinee saw the signals clearly peak up in the live spectrogram, and Andy's quick check with Omicron showed many signals found with large SNR. The interferometer appeared to handle the injections fine, staying in lock. Afterward (and also in between the two injections), Nutsinee set the intent bit back to 'science'. Note: In the future, we expect detchar safety injections such as these to be marked with the DetChar bit in the CAL-INJ_ODC bitmask, but for the test today we treated it as a burst injection -- it will be marked in ODC (and GDS-CALIB_STATE) as a burst injection, and should produce ODC-INJECTION_BURST segments in the DQ segment database.
Comments related to this report
andrew.lundgren@LIGO.ORG - 12:01, Tuesday 09 June 2015 (19019)DetChar, INJ
I've done a few checks of the injections. The first attachment is the spectrum before the first injections were started compared to the spectrum just after the last one finished. The spectrum is the same before as after, so I don't think anything got rung up. Maybe we can check the violin modes more carefully. There was a fairly big glitch two minutes later (Omega scan) but I don't think it was related.

The other four attachments are the injections of the first round of the injection set, done at normal gain. These are meant to have SNR of about 25, but that varies with the spectrum. Most look fine. However, the injections at 1 kHz and above are not correct. They look to be anti-aliased down, or maybe there's a saturation or something wrong with the actuation. We'll check our code to see if there's something wrong with the file we generated.
Images attached to this comment
peter.shawhan@LIGO.ORG - 14:01, Tuesday 09 June 2015 (19028)DetChar, INJ
When Andy presented this on the ER7 call and talked about the higher-frequency injections not appearing correctly, Jeff asked if we were hitting the software limit at +-200 counts.  That limit had been set based on some CBC injection studies; we don't really know the level at which unavoidable saturation in the software or hardware chain would set in.  Duncan M quickly confirmed that the H1:CAL-INJ_HARDWARE_OUT_DQ channel was hitting +-200 for some of the injections.  I took a look too and estimated what SNR value hits that software limit:
 At 549 Hz,  SNR=80  hits 200 counts
   759 Hz   SNR=33
  1048 Hz   SNR=10.4
  1448 Hz   SNR<6.25  (saturated even for the weakest one we injected)
  2000 Hz   SNR<6.25  (saturated even for the weakest one we injected)
So this tells us how much that (currently rather arbitrary) software limit would need to be relaxed to put in larger-SNR injections at those higher frequencies, if it's important to do so.
H1 ISC
evan.hall@LIGO.ORG - posted 16:18, Saturday 06 June 2015 - last comment - 17:31, Thursday 11 June 2015(18939)
Sum, null, and residual of OMC DCPDs

Using two hours of undisturbed data from last night's 66 Mpc lock, I repeated Den's sum/null stream analysis in order to see if we have a similar 1/f1/2 excess in our residual.

I took the OMC sum/null data (calibrated into milliamps), undid the effect of the DARM OLTF in order to get an estimate for the freerunning OMC current, and then scaled by the DARM optical gain (3.5 mA/pm, with a pole at 355 Hz) to get the equivalent freerunning DARM displacement. The residual is then the quadrature difference between the sum and null ASDs.

The attachment shows the sum, null, and residual ASDs, along with the anticipated coating Brownian noise from GWINC. [Just to be clear: the "sum" trace on this plot corresponds to our usual freerunning DARM estimate, although in this case it comes purely from the error signal rather than a combination of the error and control signals.]

If there is some kind of excess 1/f1/2 noise here, it is not yet large enough to dominate the residual. Right now it looks like the residual is at least a factor of 2.2 higher than the expected coating noise at all frequencies. We already know some of this is intensity noise.

The other thing to note here is that we are evidently not completely dominated by shot noise above 1 kHz.

Non-image files attached to this report
Comments related to this report
evan.hall@LIGO.ORG - 15:51, Sunday 07 June 2015 (18959)

I repeated this on a lock stretch from 2015-06-07 00:00:00Z to 02:00:00Z, but the result is pretty much the same. The best constraint we can put on coating noise right now from the residual is about a factor of 2.2 higher than the GWINC prediction. I also think the residual is not yet clean enough in this frequency band to make an inference about its spectral shape.

I tried increasing the CARM gain by 3 dB to see if the residual would decrease, but it does not (except maybe round 6 kHz; see the attached dtt pdf). So this broadband excess in the sum may not be frequency noise.

Non-image files attached to this comment
evan.hall@LIGO.ORG - 14:09, Tuesday 09 June 2015 (19027)

There is an error in the above plots.

Only the DCPD sum should be corrected by the DARM OLTF to get the equivalent freerunning noise. The DCPD null should not be corrected. To refer to noise to DARM displacement, however, all these quantities must be corrected by the DARM cavity pole.

This time I've included the DCPD dark noise (sum of A and B), also not corrected by the loop gain.

Non-image files attached to this comment
evan.hall@LIGO.ORG - 17:31, Thursday 11 June 2015 (19077)

A few more corrections and additions:

  • These plots use median averaging. As is widely known, this biases the estimate of the ASD downward by a factor of sqrt(ln(4)). This is now corrected in the new attachment.
  • I looked at the 540 Hz pcal line in order to get a tighter value for the optical gain; it is 3.85 mA/pm. I am still assuming a DARM pole of 355 Hz, which is what is currently installed in the DARM calibration.
  • The shot noise as predicted by GWINC lines up fairly well with the DCPD null stream, with minimal additional tuning of the of the parameters required. Input power is 24.2 W, with 88% transmission efficiency of the IMC. SRM transmissivity is 37%, DCPD quantum efficiency is 85%. The round-trip arm losses are set at 84 ppm, which is what I found previously was required to achieve a recycling gain of 40 W/W. Loss at the beamsplitter is 500 ppm, excess SRC loss (the "TCS loss") is 0, and SRC modematching is perfect, which are the defaults in IFOModel. Of course, we should get a better handle on these numbers and then actually verify that the GWINC shot noise estimate still agrees with the null. For now, it is just a weak indicator that we roughly understand the shot noise level.
  • The apparent low-frequency excess in the null stream (<30 Hz) seems roughly consistent with the expected contribution from dark noise that Dan and I measured a few months ago. Since Koji has retuned by hand the digital compensation of the DCPDs, ideally we should measure this again.
  • Some extra plots (cross spectrum and coherence of DCPDs A and B) and parameters file attached in zip.
Non-image files attached to this comment
H1 DetChar
kiwamu.izumi@LIGO.ORG - posted 18:01, Friday 05 June 2015 - last comment - 10:00, Tuesday 09 June 2015(18918)
unidentified DARM glitches

Stefan, Kiwamu,

In this morning, DARM had many numbers of glitches which were visible in the DARM spectrum as wide band noise. We looked at various channels to see what caused the glitches, but we were not able to identify them.

We would like to get some help from the detchar people. Could you guys please look for a cause of the DARM glitches ?

The lock stretch which had a high glitch rate is the one starting at 2015-06-05 17:17 -sh to 18:00 -ish UTC. I attach an example time series of the glitches shown in OMC-DCPD A and B. We know that some of the loud ones were so large that they saturated the ADCs of the OMC DCPD.

Note that in the same lock stretch, we changed the DARM offset multiple times which changed the amount of the carrier light resonating in OMC. We do not think our activity with the DARM offset caused the high glitch rate.

Images attached to this report
Comments related to this report
stefan.ballmer@LIGO.ORG - 18:04, Friday 05 June 2015 (18919)
Here is also a DARM spectrum and time series, as well as the summary page range graph. The glitches occur in the short science segment just before 18h.
Images attached to this comment
thomas.massinger@LIGO.ORG - 11:32, Saturday 06 June 2015 (18932)DetChar, ISC

We need to do some more thorough follow-up, but I can give some quick feedback that might give some hints. The initial signs seem to suggest that the problem might be due to input pointing glitches or alignment fluctuations in the PRC.

The loudest glitches in that short science segments were coincident with ASC-REFL_A_RF9_I_PIT_OUT_DQ, which looks like it was being used as the error signal for INP1 and PRC2 loops, feeding back onto IM4 and PR2. The corresponding YAW channel was also significant, but not quite as much so. We also saw ASC-REFL_B_RF9_I_PIT_OUT_DQ as somewhat significant, which looks like it was being used in both the INP1, INP2, and PRC2 loops and feeding back on IM4 and PR2.

kiwamu.izumi@LIGO.ORG - 10:00, Tuesday 09 June 2015 (19011)

So, we now start believing that these loud glitches were related to the cleaning activity on the X arm vacuum tube (alog 18992). Here I show glitch wave forms in time series from three glitch events (out of many) that were observed in this past Friday, 5th of June.

Typically the glitches were very fast and I am guessing that the glitch itself happens on a time scale of 10 ms or maybe less. Usually the OMC DC signals or the DARM error follows with a relatively slow oscillation with a period of roughly 100 msec which I believe is an impulse response of the DARM control. All the three events showed a power drop in the carrier light everywhere ( TRX, TRY and POP) indicating that the power recycling gain dropped simultaneously. For some reason POP_A_LF showed slower power drop which I do not understand. Also, in all three events that I looked at, the OMC DCPDs showed small fluctuation roughly 20 ms before the big transient happens.

 

1. 2015-06-05 17:49 UTC

(This one contains two glitch events apart only by roughly 200 msec)

2. 2015-06-05 15:51 UTC

3. 015-06-05 17:55 UTC

 

4. High passed version of glitch event 1

(all the time series are high-passed with zpk([0], [40], 1) ). You can see a glitchy behavior in REFL WFS (as reported by TJ) as well as TRX QPD  (and a little bit in TRY QPD).

Images attached to this comment
Displaying reports 64721-64740 of 83254.Go to page Start 3233 3234 3235 3236 3237 3238 3239 3240 3241 End