Displaying reports 55541-55560 of 83084.Go to page Start 2774 2775 2776 2777 2778 2779 2780 2781 2782 End
Reports until 17:40, Sunday 10 July 2016
H1 ISC
stefan.ballmer@LIGO.ORG - posted 17:40, Sunday 10 July 2016 (28313)
First look at integrated PR3, PR2 and PRM camera intensity during power-up

I wanted to look at the digital camera integrated intensities of all PRM optics during the power increase, in an attempt to find lost power.

First step: find a camera exposure setting that does not saturate at 40W:

H1:VID-CAM13_EXP 3000   (PRM)
H1:VID-CAM08_EXP 1000 (PR2)
H1:VID-CAM14_EXP 1000 (PR3)

I already recorded the corresponding sum signals during the first attempt (UTC Jul 10 23:50 - Jul 11 00:30), but had to adjust the exposure settings along the ways. The interesting sum signals are:

H1:VID-CAM13_SUM
H1:VID-CAM08_SUM
H1:VID-CAM14_SUM
 

Once at 40W, I noticed that PR3 shows quite a bit off overspilling light below PR3 (and some above, but not on the side). By moving the H1:ASC-POP_A_PIT_OFFSET from the nominal 0.36 to 0.55, I was indeed able to reduce the total light seen by the PR3 baffle camera by 32%. At the same time the recycling gain and arm transmitted power went up, but only by 2% (PR GAIN from 28.4 to 29.0 / TR_X_NORM from 1080 to 1102). There is more going on than this...

 

=============================

 

Along the way I kept loosing the FSS lock. Not sure what changed this week, so I won't debug this one.

Images attached to this report
H1 General
nutsinee.kijbunchoo@LIGO.ORG - posted 22:59, Saturday 09 July 2016 - last comment - 02:54, Sunday 10 July 2016(28310)
Finally locked at NLN

Intent bit set at 05:30 UTC. PI modes are not well damped but they're controlled for now. There are few weird things I noticed about some of the PI modes:

 

 

As I was writing this alog, the ifo went DOWN because of ETM bounce mode (not sure which ETM, possibly both). I didn't put them on my StripTool since I was assume only ITMX has problem. Huge mistake...

Images attached to this report
Comments related to this report
nutsinee.kijbunchoo@LIGO.ORG - 00:26, Sunday 10 July 2016 (28311)

Locked again at NLN. Intent bit switched to Undisturbed at 07:22 UTC. I'm going to stick around a bit to keep an eye for the bounce mode and PI. PI modes are somewhat under control. Bounce and Roll modes seem pretty well damped at this point.

 

Hence a beautful ending of ER9.

Images attached to this comment
nutsinee.kijbunchoo@LIGO.ORG - 02:54, Sunday 10 July 2016 (28312)
The IFO lost lock and relocked itself after I came home so the intent bit is no longer set. It would be nice to have a way to set the intent bit remotely.
H1 General
nutsinee.kijbunchoo@LIGO.ORG - posted 17:05, Saturday 09 July 2016 - last comment - 20:17, Saturday 09 July 2016(28306)
Lockloss 23:42 UTC

ITMX bounce mode was ringing up so I flipped the sign of the gain. Unfortunately I accidentally flipped the wrong gain (instead of ITMX Bounce I flipped ITMX Roll). Likely caused ITMY Roll to ring up and blew the lock.

Images attached to this report
Comments related to this report
nutsinee.kijbunchoo@LIGO.ORG - 19:00, Saturday 09 July 2016 (28308)

Lockloss again due to ETMY PI 15009 Hz rung up.

This time I tried to catch the mode early before power up. I was able to damp it just fine using -60deg -10 gain. However, the mode jumped when the IFO entered COIL_DRIVER (at about -22 mins) and never ring down. I thought I was able to damp it with opposite gain (-12 min) but it rung up shortly after.

Images attached to this comment
nutsinee.kijbunchoo@LIGO.ORG - 20:17, Saturday 09 July 2016 (28309)DetChar

3:07 UTC Lockloss at COIL_DRIVER

PR gain and SRC seems unstable.  I called Jenne and this seems to be a problem of SRM not following the rest of the SRC (that I didn't know I should be moving). Guardian didn't seems to know that it has lost lock and wouldn't move to DOWN. This happened twice now. I had to requst DOWN manually.  This is already a known problem. Nevermind.

 

There was another lockloss at INCREASE_POWER (02:14 UTC) that I didn't alog. Now that I lost lock around the same place it's becoming a pattern so I thought I would mentioned.

Images attached to this comment
H1 SUS (CDS, ISC, Lockloss)
jeffrey.kissel@LIGO.ORG - posted 13:26, Saturday 09 July 2016 - last comment - 06:37, Monday 11 July 2016(28304)
SUS ETMX ESD Driver Power Supply Found OFF
J. Warner, R. Schofield, (J. Kissel remotely)

Jim called me this morning around 10a PT informing me that the ETMX ESD was unresponsive, preventing any lock re-acquisition. We eventually found that one leg of the HV power supply to the HV ESD driver at EX was off; unknown as to why. I reminded Jim how to restart it, then the ESD driver came back to live as normal after hitting the ON/OFF button on the HV ESD driver itself (no need to disconnect/reconnect any cables this time).

Diagnosis timeline:
I logged in an found that the HV monitor channels were all zeroes in the bottom right corner of the SUS ETMX overview, even though the digital request was the usual large bias and linearization voltages on the signal quadrants. I also noticed that because these monitor channels were reading zeros, the ISC_LOCK guardian -- which was in the DOWN state -- was hammering the remote ON/OFF button (I thought we fixed this??). After requesting that the ISC_LOCK just CHILL (i.e. pausing the guardian node), I waited a bit to let the HV ESD driver's internal mirco-processor relax then tried to remotely restarted it again. 
No dice. 
I advised Jim to head down to EX so we could debug together there (he'd gone with Robert). He went immediately to the VEA to try the ol' plug-un-plug cable trick, and found that the physical ON/OFF button did nothing, and that some indicator lights had shown that a leg of the 430 V input was red / dark. So, "we" went out to the entry foyer where the two HV power supplies live, and he found one off. We turned it back on --
 - Flip the rocker switch up to ON (wait for boot cycle to complete)
 - On the keypad, type
    - VSET > 430 ([V] for the amount of output voltage) > Enter
    - ISET > 80 ([mA] for the internal current limit) > Enter
    - Output ON/OFF
and then Jim went back out of the floor, the ESD HV driver looked much more lively, so he hit the button and the box came to live and I saw the voltage monitor channels go to their usual values. 

The only thing I can think of that trips the HV power supplies for the ESDs is the vacuum system (and when it does, it usually trips both), so I did a cursory vacuum system check on the EX overview screen, and didn't see anything crazy (i.e. I saw a bunch of green lights, and both vacuum Pirani gauges were sitting happily at ~1e-9 Torr. We'll debug more on Monday when I don't have to use the fragile remote connection to CDS.
Comments related to this report
richard.mccarthy@LIGO.ORG - 06:37, Monday 11 July 2016 (28315)
The Vacuum interlock is tied to both power supplies with the same relay so this is probably not the cause.  These supplies have very sensitive protection circuits and we are not really using the supplies for what they were designed for so it was probably a single supply protection circuit trip do to some loading transient.
H1 CAL
jeffrey.kissel@LIGO.ORG - posted 10:51, Saturday 09 July 2016 (28301)
PCALX Long Duration Sweep Frequency moved to 3501.3
J. Kissel (Remotely)

I've taken the lock-loss opportunity to move the frequency of super-kHz calibration line we're using on PCALX to map out the high-frequency sensing function (like was done in O1; see e.g. LHO aLOG 24843) from 3001.3 to 3501.3 Hz. Same amplitude of excitation that Evan used yesterday when restoring the line after hardware injections (39322 [ct]; see LHO aLOG 28297). The settings changes have been accepted in the h1calex SDF system under both the safe and OBSERVE.snaps.
H1 General
vernon.sandberg@LIGO.ORG - posted 09:29, Saturday 09 July 2016 (28300)
H1 Lost Lock 1hr 23 m into owl shift

Lost lock and went to the Down state at 1152087840 GPS, July 09, 2016 01:23:43 PDT,  08:23:43 UTC. 

H1 DetChar (DetChar, ISC)
andrew.lundgren@LIGO.ORG - posted 01:52, Saturday 09 July 2016 - last comment - 21:03, Sunday 10 July 2016(28299)
Spectrum deteriorating due to glitches
Around 5:45 UTC, DARM started to glitch about every two seconds. The period is not exactly 2 seconds (I think it's just a little bit longer) but it does look pretty regular. I checked that the Pcal spectra look fine, so that's not the problem.

Attached is the change in the DARM spectrum. I wanted to use GDS-CALIB_STRAIN, but I get something that looks like it has dynamic range issues. We need to look into why that's not working. In addition, I'm attaching a Omega scan of the glitches.
Images attached to this report
Comments related to this report
shivaraj.kandhasamy@LIGO.ORG - 12:44, Saturday 09 July 2016 (28303)CAL

Andy, could you elobrate (probably with some examples) of what dynamic range issues you are having with GDS-CALIB_STRAIN? We have recently switched to double precision numbers to get rid of whitening/dewhitening and also there were a few filter changes. It would be nice to make sure that there are no problems on that side.

andrew.lundgren@LIGO.ORG - 14:30, Saturday 09 July 2016 (28305)CAL
When I take a spectrum of GDS-CALIB_STRAIN, it looks like the first plot. This looks like an issue with spectral leakage from too much low frequency. The time series has a very large low-frequency component around 10^-12 (second plot). It used to be around 10^-18 (third plot), and not so much low frequency.

I'm sure the plot could be fixed by detrending and using the right window, or at worst high passing, but it would be preferable not to have such a big low-frequency component, unless it's useful for something.
Images attached to this comment
keith.riles@LIGO.ORG - 21:03, Sunday 10 July 2016 (28314)DetChar
I'm still working my way throughout the ER9 run-averaged spectrum
to compile a detailed line / comb list, but one artifact that jumps out
at me is a strong 0.4853-Hz comb I haven't seen before, visible from
its 19th harmonic at about 9.2 Hz to its 316th harmonic at about 153.4 Hz.
This is likely related to the periodic glitches Andy found.

There is also a new near-1-Hz comb (spacing = 0.9968 Hz), visible from
its 21st harmonic at about 20.9 Hz to its 204th harmonic at about 203.3 Hz.
This is a higher harmonic than I've seen before, despite having many fewer
FScan SFTs to work with than in O1 (hence having a fuzzier noise floor to
pick out harmonics from).

Details and plots to come...
H1 General
patrick.thomas@LIGO.ORG - posted 00:12, Saturday 09 July 2016 (28298)
Ops Evening Summary
Started shift in observing mode at 40 W with Michael L. and Evan G. running injections

23:25 UTC nds0 crashed. The IMC_LOCK guardian node went into error thus taking us out of observing mode. The IFO stayed locked. nds0 restarted. Keita and Sheila changed something in the IMC_LOCK guardian code that fixed the error. I set the intent bit back to observing.
01:06 UTC Injections done. Strange moving bump appeared in DARM around 110 Hz. Bump rang done.
01:07 UTC Out of observing to let Jeff K. measure DARM open loop gain.
01:48 UTC Jeff K. done with measurements
01:50 UTC Back to observing
03:56 - 04:30 UTC Stepped out of control room

The IFO has remained in observing mode without issues since the last entry. The only thing to note is approximately seven ETMY saturations. I am leaving the site now.
H1 CAL (ISC)
jeffrey.kissel@LIGO.ORG - posted 19:46, Friday 08 July 2016 - last comment - 12:10, Friday 05 August 2016(28296)
DARM OLG TF and PCAL2DARM TFs Again -- Signs Pointing to Moving SRC Detuning Optical Spring
J. Kissel, E. Goetz

We've taken another DARMOLG TF and PCAL2 DARM transfer function in order to see if / how the SRC Detuning Optical (Anti-)Spring is changing from lock-stretch to lock-stretch. The bad (but not necessarily unexpected) news: it looks like the optical (anti-)spring frequency is moving around. One can tell by looking at the lowest frequency data points in the .pdf attachments. The model has a spring frequency of 9.381 Hz and both measurements are divided by it to form the residuals on the right column of subplots. Note also that Kiwamu and Craig's more sophisticated parametrization for the optical spring (which includes some Q between in the anti-spring poles, see LHO aLOG 28274) is not yet included. Jul 1 data points are ~ +15% discrepant in magnitude, where as Jul 09 data points are ~ +25%. 

More thoughts on this (what to do about it, how to track it, tests to try and control / reduce it) after the weekend. 

The pre-processed sensing function has been attached here, such that whomever gets to it first, can reproduce the fit using Craig's code from LHO aLOG 28274.

Data sets live here:
${CalSVN}/trunk/Runs/PreER9/H1/Measurements/DARMOLGTFs/2016-07-09_H1_DARM_OLGTF_4to1200Hz_SRCTuned.xml
${CalSVN}/trunk/Runs/PreER9/H1/Measurements/PCAL/2016-07-09_H1_PCAL2DARMTF_4to1200Hz_SRCTuned.xml
Images attached to this report
Non-image files attached to this report
Comments related to this report
craig.cahillane@LIGO.ORG - 12:40, Saturday 09 July 2016 (28302)CAL
C. Cahillane, K. Izumi

See DCC T1600278 for an updated document on the sensing function detuning.

I've taken the new ER9 sensing measurement from July 9th and plotted it next to the July 1st measurement for comparison, and done a fit on the July 9th measurement as well.

Plot 1 shows July 9th and July 1st Sensing measurements at LHO.  The detuning is visibly different for both measurements.

Plot2 shows the July 9th fit.  The fitting parameters are copied below.  Plot 3 shows the fitting parameter cornerplot.

 July 9st Parameters
=====================
Optical gain = 8.998599e+05 +/- 1.095765e+03 [cnts/m]
Cavity pole = 3.206019e+02 +/- 8.580968e-01 [Hz]
Time delay = 2.218270e+01 +/- 5.364895e-01 [usec]
Spring frequency = 8.304667e+00 +/- 6.061604e-02 [Hz]
Spring Inverse Q = 5.107011e-02 +/- 6.784018e-03


The original July 1st parameter fits from aLOG 28274 are reprinted here for convenience:

 July 1st Parameters
=====================
Optical gain = 9.124805e+05 +/- 8.152381e+02 [cnts/m]
Cavity pole = 3.234361e+02 +/- 5.545748e-01 [Hz]
Time delay = 5.460838e+00 +/- 3.475198e-01 [usec]
Spring frequency = 9.975837e+00 +/- 5.477828e-02 [Hz]
Spring Inverse Q = 1.369124e-01 +/- 3.522990e-03


There is a difference of 1.67 Hz in the optical spring frequency.
This represents a detuning phase difference of 0.316 degrees:
July 1st Detuning Phase = 1.027 deg
July 7th Detuning Phase = 0.711 deg

Images attached to this comment
evan.hall@LIGO.ORG - 12:10, Friday 05 August 2016 (28899)

TF from DCPD sum to DARM IN1 at 2016-07-09 01:00:00 is 2.96e-7 ct/mA. Therefore, the peak optical gain (above the antispring, below the DARM pole) is 3.0 mA/pm for this lock stretch.

During O1, the peak optical gain was 3.2 mA/pm. However, this was for 95 kW of circulating power and 20 mA of dc readout photocurrent. For ER9, these numbers are instead 130 kW and 15 mA. Therefore, the naive expectation for the ER9 optical gain would be 3.2*sqrt(130/95)*sqrt(15/20) = 3.2 mA/pm, rather than the 3.0 mA/pm that was observed.

In terms of DARM shot noise, 3.2 mA/pm with 20 mA of dc photocurrent (the O1 situation) amounts to a shot noise of 2.5e-20 m/rtHz in the bucket. 3.0 mA/pm of with 15 mA of dc photocurrent (the ER9 situation) amounts to a shot noise of 2.3e-20 m/rtHz in the bucket; i.e., an improvement of less than 10 % over O1. This agrees roughly with Kiwamu's shot noise analysis.

H1 CAL (CAL, INJ)
evan.goetz@LIGO.ORG - posted 19:41, Friday 08 July 2016 (28297)
Long duration Pcal high frequency injection at 3001.3 turned off and then back on

For the hardware injection testing during ER9, the long duration pcal line was turned off at GPS time 1152055000. It was then turned back on at 1152067170.

It remains running at 3001.3 Hz.

H1 ISC (OpsInfo)
ross.kennedy@LIGO.ORG - posted 19:16, Friday 08 July 2016 (28293)
ER9 PI damping

Sheila, Ross

We've put together a couple of screens for monitoring PI. The dtt shows a few spectrums of regions where PI may ring up and there is also a striptool which has rms monitors of some of the more problematic of the modes. These are stored in the /ligo/home/ops/Templates/ folder and are under dtt and StripTool PI_monitoring_ER9.

If any of these modes become unstable it should be visible in the RMS monitor screen. You can then get to the damping filter for that mode by going to the from the PI medm screens which are split into each test mass. There are overview screens for either QPDs or OMC. Most of these modes are damped using OMC signal at the moment apart from the 15541Hz ETMX mode and the 15542Hz ETMY mode which are damped using QPD signals. An example damping filter for the 15541 ETMX mode is attached in the third image. The damping filter settings may need to be changed if a line is ringing up i.e. the phase can be changed from +60 degrees to -60 degrees. Also increasing the gain may help to damp a mode if it is particularly rung up (around 100 magnitude). Right now the filter settings seem to keep the modes stable.

There is also a PI wiki page which is useful for identifying which modes  relate to which test mass. 

Images attached to this report
H1 PSL
keita.kawabe@LIGO.ORG - posted 19:15, Friday 08 July 2016 - last comment - 11:29, Monday 11 July 2016(28294)
PSL ISS 2nd loop MEDM madness

Summary:

As reported before (28236), ISS 2nd loop MEDM screen appears as if it sometimes doesn't agree with reality. Turns out that it never truly agreed with reality. For example, in the first attachment, both SERVO ON/OFF indicator and additional 20 dB gain indicator are red while these are ON.

I was bothered enough to investigate and found that the MEDM screen has numerous nonsense logic and that the guardians are not written MEDM-friendly. I made a quick dirty fix for MEDM as well as guardians.

What was wrong:

Before going into details, you need to know that ALL of PSL 2nd loop I/O that are binary in nature is done via 16 bit DAC (don't ask me why). The output of DAC is sent to optical coupler via a resistor (see e.g. D1300439). To make anything ON, you want some large positive voltage to drive the LED in the coupler. To make anything OFF, you want to send sufficiently small (e.g. zero-ish) voltage or negative voltage.

As you can easily guess, one of the problems is the lack of convention. People sometimes send +32000 and other times +32700 to make the same thing ON. Sometimes -32000 and other times 0 to turn it OFF.

On top of that, there are many bugs in MEDM screen such that color indicators check some nonsense bits that never change, value set on pressing button but changed to a different number on releasing the button, that kind of things.

What was done:

I changed most everything in MEDM as well as IMC_LOCK and lsclibrary such that:

  1. OFF is 0 so MEDM switch graphics using "if zero" and "if not zero" works correctly,
  2. ON is 32000 for the sake of consistency but the color indicators check if the value is positive (instead of looking at some specific bit).

It seems as if it's working for now.

Madness example:

Just as an example. Manually pressing CHANGE PDs button could have made you believe that you selected PD1-4 when PD5-8 (3rd loop) was selected in reality.

In the second attachment, you can see that the CHANGE PDs "1-4" button sent 32000 (40V-ish differential) when pressed, but then 1 (less than 1 mV) when released.

PD1-4 is selected with large positive voltage (or ON or HIGH or whatever), otherwise PD5-8 is selected.

When you manually pressed and released "1-4",  the DAC output momentarilly went +40V differential, but immediately went down to some tiny voltage, so PD5-8 was selected in the end.

But the switch graphics was implemented assuming that non-zero output means PD1-4. Since the DAC output was 1 after pressing the "1-4" button, the graphics showed that PD1-4 was connected instead of 5-8. The PD indicator color box didn't help either as it checked the bit 2 of the DAC output, and it only turned to orange (CH5-8) only when DAC output was 32700.

The story was different for guardian as it used +32000 and -32000 for PD1-4 and PD5-8, respectively. When guardian did something, it looked as if PD1-4 was selected no matter what.

Images attached to this report
Comments related to this report
keita.kawabe@LIGO.ORG - 11:29, Monday 11 July 2016 (28321)

Addendum:

"The story was different for guardian as it used +32000 and -32000 for PD1-4 and PD5-8, respectively. When guardian did something, it looked as if PD1-4 was selected no matter what."

The above was incorrect, it turns out that the MEDM screen PD14/PD58 graphics happened to agree with reality when the guardian was doing it.

ISC_LOCK lets IMC_LOCK handle most of the 2nd loop board switching except for closing the third loop (i.e. selecting PD5-8) when ISC_LOCK bypasses IMC_LOCK and uses lockISS in ISC_library to send 0 to DAC. MEDM looked correct.

When selecting PD1-4, ISC_LOCK uses IMC_LOCK which sends +32000 to the DAC and again the graphics looked correct.

H1 ISC (Lockloss, OpsInfo)
sheila.dwyer@LIGO.ORG - posted 17:42, Friday 08 July 2016 - last comment - 19:13, Friday 08 July 2016(28292)
please watch ITMX bounce

Our first lockloss from 40 Watts today (2016-07-08 19:36:59  ISC_LOCK  NOMINAL_LOW_NOISE -> LOCKLOSS)  was caused by bounce modes.  ITMX bounce mode rang up ( I don't know why).  After this rang up I turned off all the bounce mode damping (because of confusion about which mode it was) which caused all the modes to grow and break the lock. 

This lock I have been watching and the settings we used damped the ITMX mode well when we first locked, and it has not rung up at all.  My advice to operators would be to keep open the StripTool (/ligo/home/ops/BOUNCE_DAMPING.stp).  If ITMX starts ringing up open up the damping filters (sitemap> sus> BOUCNE_ROLL>DAMPING filters)  and try a different phase for ITMX by turning on or off some of the filters like +60, -60 ect.  If it starts damping that's good, if it starts ringing up faster because of your change you can use a negative gain with that phase. 

Comments related to this report
patrick.thomas@LIGO.ORG - 19:13, Friday 08 July 2016 (28295)
There does not appear to be a file named BOUNCE_DAMPING.stp at /ligo/home/ops/. I found /ligo/home/ops/Templates/StripTool/BOUNCE_DAMPING.stp.
Displaying reports 55541-55560 of 83084.Go to page Start 2774 2775 2776 2777 2778 2779 2780 2781 2782 End